Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| From: | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
| Newsgroups: | comp.compilers |
| Date: | Thu, 21 May 2009 18:46:15 GMT |
| Organization: | Institut fuer Computersprachen, Technische Universitaet Wien |
| References: | 09-04-072 09-04-086 09-05-010 09-05-022 09-05-028 09-05-038 09-05-039 09-05-050 09-05-055 09-05-065 09-05-069 09-05-073 |
| Keywords: | optimize |
| Posted-Date: | 21 May 2009 20:15:37 EDT |
Nathaniel McIntosh <mcintosh@cup.hp.com> writes:
[double definition of a symbol in two different files]
>I would in fact argue, however, that the compiler is doing the
>programmer a favor by causing the program to crash when compiled with
>optimization. My reasoning: while there is some pain up front for the
>application writer (e.g. he/she has to track down the reason for the
>crash when optimization is turned on), the good news is that the
>programming error is caught early (e.g. in the lab, during the
>compiler evaluation process), as opposed to "lurking" in the code and
>turning up only later at some much less pleasant time. The point here
>being that programming errors of this sort can just as easily be
>converted from latent problems to actual crashes by source code
>modifications as opposed to optimization.
Well, in that case, if the test suite produces a crash when the
optimizer modifies the behaviour, it will most likely also produce a
crash when the source code is changed in a way that affects this.
OTOH, if the test suite does not catch this when the source code is
changed, it will probably not catch it when the optimizer changes
behaviour either; and as a result the optimizer bug may unveil itself
later at some much less pleasant time without any source code change
being involved. That's exactly the reason why optimizers should not
change the behaviour of working programs.
>I think most programmers given a choice would prefer to find out about
>programming errors such as these as soon as possible-- having a
>compiler that covers them up (in some sense) only postpones the pain,
>it doesn't eliminate it.
Right, but the optimizer is not the right tool for that purpose; and
it's certainly not as soon as possible. The linker is a much better
place for this particular case, as others have suggested. And indeed,
with your example GNU ld 2.15 on IA-32 says:
[b3:~/tmp:21583] gcc foo.o bar.o
/usr/bin/ld: Warning: alignment 4 of symbol `x' in bar.o is smaller than 8 in foo.o
/usr/bin/ld: Warning: size of symbol `x' changed from 8 in foo.o to 4 in bar.o
- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/
Return to the
comp.compilers page.
Search the
comp.compilers archives again.