Re: behavior-preserving optimization in C, was compiler bugs

Nathaniel McIntosh <mcintosh@cup.hp.com> wrote:
(snip)


< Anecdote from my own personal experience as a compiler writer: at one
< point while working on an optimization to improve data cache behavior
< for C/C++ programs, I ran into an application (let's call it
< "Application T") containing the following code (greatly simplified):


< foo.c bar.c
< ----- -----
< ... ...
< double x; int x = 0;
< ... int garbage;
< ...


< Most C compilers will compile these two modules without complaint;
< when you link foo.o and bar.o into an executable, the "strong"
< definition of "x" from bar.o is favored over the "weak" definition in
< foo.o, and you wind up with a final "x" entity that is 4 bytes in size
< (assuming an ILP32 compilation model), not 8 bytes.


I am not so sure what you mean by "strong" and "weak" (*), but yes
many linkers treat initialized data different from uninitialized
data. Among others, that is the reason for BLOCK DATA in Fortran.


The OS/360 (and successor) linker does take initialized (CSECT)
over uninitialized (COM), but requires that the CSECT be at
least as large as the COM. I believe that there is an error
message for it, though I am not sure that I ever tried it.


(big snip)


< 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.


That has always been one of the reasons I use for promoting big-endian
byte ordering. If you pass the address of a little endian value of
the wrong size, it has a good chance of working for many values. A
wrong sized big-endian value passed by address has a much smaller
chance of working.


(*) The OS/360 linker, and I believe others, have a weak external
reference that won't pull something in from a library if it isn't
otherwise needed, but will generate the proper reference if it is
otherwise loaded. (EXTRN vs WXTRN)


< [I'd rather use a linker that diagnoses type mismatches. It's not
< exactly a new idea; I know one that did that in 1976. -John]


Well, type would be nice, but it should at least check size. Type
will be a problem for union (C) and EQUIVALENCE (Fortran), though I
suppose you could turn off type checking only for those cases.


-- glen

Return to the comp.compilers page.
Search the comp.compilers archives again.