This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>, Richard Guenther <richard dot guenther at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Sun, 4 Apr 2010 20:58:38 +0200
- Subject: Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO
- References: <20100330195202.GH32187@gmx.de> <h2y84fc9c001003310202y510e6bc6t68c0f474b8d9d303@mail.gmail.com> <20100331193343.GB9867@gmx.de> <h2u84fc9c001004010535hdd8bbd55v6163dcda63c4428d@mail.gmail.com> <20100404071937.GB29215@gmx.de>
On Sun, Apr 4, 2010 at 9:19 AM, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:
> [ adding gcc-patches@, dropping gcc@ and libtool@; this is
> ?<http://thread.gmane.org/gmane.comp.gcc.devel/112638/focus=112670> ]
>
> * Richard Guenther wrote on Thu, Apr 01, 2010 at 02:35:00PM CEST:
>> On Wed, Mar 31, 2010 at 8:33 PM, Ralf Wildenhues wrote:
>> > +If LTO encounters objects with C linkage declared with incompatible
>> > +types in separate translation units to be linked together (undefined
>> > +behavior according to ISO C99 6.2.7), it might produce a warning, but
>> > +this fact alone will not cause an access to an object to be optimized
>> > +away.
>
>> Well, the wording is almost ok, but
>>
>> +behavior according to ISO C99 6.2.7), a non-fatal diagnostic may
>> be issued. ?The behavior is still undefined at runtime.
>>
>> would be more precise. ?Especially accesses to conflicting
>> declarations can end up being optimized away if there's unfortunate
>> inlining so that for example with
>>
>> t1.c
>> float f;
>> t2.c
>> int f;
>>
>> ?f[int] = 1.0;
>> ?f[float] = 1;
>>
>> GCC can end up re-ordering the stores to f and thus effectively
>> optimize away one or the other.
>>
>> With function calls there's no such issue, but argument passing
>> might be completely off (obviously).
>
> OK. ?That may not be enough for Libtool, but it's enough for Autoconf.
> Not sure if your reply already was an approval (I guess as LTO
> maintainer you can approve doc patches for this). ?So, OK to commit?
Yes.
Thanks,
Richard.
> Tested 'make info pdf html'.
>
> Thanks,
> Ralf
>
> Document LTO behavior with incompatible declarations.
>
> gcc/ChangeLog:
> 2010-04-04 ?Ralf Wildenhues ?<Ralf.Wildenhues@gmx.de>
>
> ? ? ? ?* doc/invoke.texi (Optimize Options): Document that LTO
> ? ? ? ?won't remove object access purely due to incompatible
> ? ? ? ?declarations.
>
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 23a0f4a..341d1b7 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -7294,6 +7294,11 @@ regular (non-LTO) compilation. ?This means that if your build process
> ?was mixing languages before, all you need to add is @option{-flto} to
> ?all the compile and link commands.
>
> +If LTO encounters objects with C linkage declared with incompatible
> +types in separate translation units to be linked together (undefined
> +behavior according to ISO C99 6.2.7), a non-fatal diagnostic may be
> +issued. ?The behavior is still undefined at runtime.
> +
> ?If object files containing GIMPLE bytecode are stored in a library
> ?archive, say @file{libfoo.a}, it is possible to extract and use them
> ?in an LTO link if you are using @command{gold} as the linker (which,
>