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

Hans-Peter Diettrich <DrDiettrich1@aol.com>
Mon, 25 May 2009 09:13:09 +0200

          From comp.compilers

Related articles
[22 earlier articles]
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-21)
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-21)
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-21)
Re: behavior-preserving optimization in C, was compiler bugs bear@sonic.net (Ray) (2009-05-21)
Re: behavior-preserving optimization in C, was compiler bugs Jan.Vorbrueggen@thomson.net (=?ISO-8859-15?Q?Jan_Vorbr=FCggen?=) (2009-05-22)
Re: behavior-preserving optimization in C, was compiler bugs gneuner2@comcast.net (George Neuner) (2009-05-24)
Re: behavior-preserving optimization in C, was compiler bugs DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-05-25)
Re: behavior-preserving optimization in C, was compiler bugs anton@mips.complang.tuwien.ac.at (2009-05-25)
Re: behavior-preserving optimization in C, was compiler bugs ian@airs.com (Ian Lance Taylor) (2009-05-25)
Re: behavior-preserving optimization in C, was compiler bugs gneuner2@comcast.net (George Neuner) (2009-05-25)
Re: behavior-preserving optimization in C, was compiler bugs DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-05-29)
Re: behavior-preserving optimization in C, was compiler bugs dave.thompson2@verizon.net (David Thompson) (2009-06-15)
| List of all articles for this month |

From: Hans-Peter Diettrich <DrDiettrich1@aol.com>
Newsgroups: comp.compilers
Date: Mon, 25 May 2009 09:13:09 +0200
Organization: Compilers Central
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 09-05-087 09-05-110
Keywords: optimize, linker
Posted-Date: 25 May 2009 05:07:36 EDT

George Neuner schrieb:


> A problem occurs when there are multiple definitions in separate
> files. Technically, by the standards, there can be only 1 definition
> of a name at top level ... all other references to the name, including
> any forward references to the name in the same file, *must* be
> "extern" declarations.
[...]
> Every compiler complained about multiple definitions of 'x' when all
> the definitions were strong - ie. when 'x' was initialized in both
> files.
5B
How does a compiler know about other files?


I assume that the definitions were in the same compilation unit, i.e. in
the header files included by both source files. Otherwise it's a matter
of object file formats and linkers, what will happen with multiple
definitions of the same symbol in multiple object files.




> However, if either definition was weak, I was able to build an
> executable. When both definitions were weak, however, some of the
> compilers produced optimized executables with NO storage at all
> allocated for the name 'x'.


What's "NO" storage? A NULL address output by printf?


> I know this isn't a C forum and nobody (including me) cares much to
> debate what is right or wrong about C. But for the sake of a
> discussion about compilers, how would you handle the situation if it
> were up to you?


IMO this topic is an excellent exercise in the semantics of programming
languages. When an executable file can be linked from multiple
compilation units, the language specification also should include the
expected behaviour of the linker. When no type information is stored in
the object files, a linker only can overlay multiple definitions of the
same symbol, with the maximum allocation request.


I dunno about specific C++ specs, but when there also the names of
variables are mangled, the symbol definitions for variables of different
type would look different to the linker. Also namespace names should be
preserved, somehow.


In Delphi (OPL) or other languages a (public) symbol can have an
qualified name, consisting of the unit name and identifier, and the
compiler will only produce accordingly qualified references to external
symbols.


DoDi



Post a followup to this message

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