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

glen herrmannsfeldt <gah@ugcs.caltech.edu>
Mon, 18 May 2009 22:47:28 +0000 (UTC)

          From comp.compilers

Related articles
[9 earlier articles]
Re: behavior-preserving optimization in C, was compiler bugs cdg@nullstone.com (Christopher Glaeser) (2009-05-12)
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-13)
Re: behavior-preserving optimization in C, was compiler bugs dnovillo@acm.org (Diego Novillo) (2009-05-15)
Re: behavior-preserving optimization in C, was compiler bugs cdg@nullstone.com (Christopher Glaeser) (2009-05-15)
Re: behavior-preserving optimization in C, was compiler bugs mcintosh@cup.hp.com (Nathaniel McIntosh) (2009-05-16)
Re: behavior-preserving optimization in C, was compiler bugs pertti.kellomaki@tut.fi (Pertti Kellomaki) (2009-05-18)
Re: behavior-preserving optimization in C, was compiler bugs gah@ugcs.caltech.edu (glen herrmannsfeldt) (2009-05-18)
Re: behavior-preserving optimization in C, was compiler bugs torbenm@pc-003.diku.dk (2009-05-19)
Re: behavior-preserving optimization in C, was compiler bugs torbenm@pc-003.diku.dk (2009-05-19)
Re: behavior-preserving optimization in C, was compiler bugs gneuner2@comcast.net (George Neuner) (2009-05-19)
Re: behavior-preserving optimization in C, was compiler bugs bobduff@shell01.TheWorld.com (Robert A Duff) (2009-05-19)
Re: behavior-preserving optimization in C, was compiler bugs bobduff@shell01.TheWorld.com (Robert A Duff) (2009-05-19)
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-21)
[12 later articles]
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: Mon, 18 May 2009 22:47:28 +0000 (UTC)
Organization: California Institute of Technology, Pasadena
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, debug
Posted-Date: 19 May 2009 07:50:28 EDT

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


Post a followup to this message

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