Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO
On Wed, Mar 31, 2010 at 8:33 PM, Ralf Wildenhues wrote:
> * Richard Guenther wrote on Wed, Mar 31, 2010 at 11:02:39AM CEST:
>> On Tue, Mar 30, 2010 at 8:52 PM, Ralf Wildenhues wrote:
>> > 1) Autoconf-generated configure tests often fake the prototype of some
>> > function; e.g., AC_CHECK_FUNC([func]) uses
>> > char func();
>> >
>> > and tries to link that. Using this is undefined according to C99, if
>> > func has a different actual prototype, and when all system libraries are
>> > LTO'ed, gcc -flto may even detect this kind of inconsistency and could
>> > act accordingly (nasal demons and such).
>>
>> I suppose autoconf cannot do this for C++ functions then, because
>> of mangling issues?
>
> Correct. For C++ libraries, it is more typical to just write a complete
> test source and AC_COMPILE_IFELSE or AC_LINK_IFELSE it.
>
> FWIW, there is an Autoconf patch pending to allow AC_CHECK_DECL with
> declarations given by the user (in order to support overloaded
> basename, for example).
>
>> Note that the only thing GCC with LTO might do here is to issue
>> a diagnostic (which of course might confuse the configure script),
>> but we cannot really reject such programs (as such errors are
>> unfortunately very common) and thus defer any problems to
>> link- and/or runtime.
>
> That's almost exactly the kind of semantics I would like to see.
> Can we get this documented in the manual? Something like this.
> Note that it would explicitly contradict one of the design goals
> listed in lto.pdf, which is that conflicting declarations might
> provoke an error; so really GCC developers should make a conscious
> design decision here.
>
>
> * 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 2226cad..85f9c5f 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -7294,6 +7294,12 @@ 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), it might produce a warning, but
> +this fact alone will not cause an access to an object to be optimized
> +away.
> +
> 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,
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).
Richard.
>
> (In practice, Autoconf does not support -Werror at configure time; this
> issue only reinforces that.)
>
>> > b) The symbols 'func' and 'variable' likely have the wrong prototypes,
>> > i.e., elsewhere, they might be declared as
>> >
>> > void func(int, double);
>> > double variable[42];
>> >
>> > instead. I haven't come across any actual issues with this yet, except
>> > now LTO may rightfully complain about it.
>>
>> Same issue as above. We try to handle it - there might be bugs
>> in the current implementation of LTO though.
>
> Bugs are no problem as long as they are acknowledged as such. I desire
> future compatibility, i.e., being fairly certain autotools don't regress
> just because of a good improvement in some other tool. Dealing with
> existing cruft is abundant in autotools.
>
>> > Question is, what can we do about this? We could ensure to never pass
>> > -flto or -fwhopr to the compilation of the libtool symfile object, and
>> > remove it from some or all link tests done in configure. That's ugly.
>> > Would that even be sufficient though? Conversely, would GCC developers
>> > be willing to agree that, when GCC detects such inconsistencies, it
>> > wouldn't take adverse advantage of it (e.g., by turning off LTO in this
>> > case, or similar)?
>> >
>> > Other possibilities for Autoconf would be to work toward a new set of
>> > checking macros (or extensions of current one) where the configure.ac
>> > author passes a full prototype for each function to check (Autoconf
>> > could keep a list of known prototypes for often-checked functions).
>> > I'm not sure how to fix the libtool symfile in a C99-conforming way.
>>
>> I'd say wait and see. What would be nice to have is a few
Bootstrap failures on i386-pc-solaris2.10
Hi.
My builds on my X86 solaris box have failed since yesterday, and
I've just found bug 43615 in Bugzilla which indicates a different
but similar issue for an x86-64 build.I'm running Solaris 10 on an
older Dell box with a Pentium4 chip, and have been building
gcc with the '--disable-multilib' argument for quite some time.
Here's the config info from the last build which worked:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/i386-pc-solaris2.10/4.5.0/lto-wrapper
Target: i386-pc-solaris2.10
Configured with: /home/ahaas/gnu/gcc.git/configure
--prefix=/export/home/arth/local --enable-languages=c,c++,objc,fortran
--disable-nls --with-gmp=/export/home/arth/local
--with-mpfr=/export/home/arth/local --enable-checking=release --enable-threads
--with-gnu-as --with-as=/export/home/arth/local/bin/as --with-gnu-ld
--with-ld=/export/home/arth/local/bin/ld --disable-multilib
--disable-libstdcxx-pch --enable-objc-gc --build=i386-pc-solaris2.10
--with-arch=pentium4 --with-tune=pentium4
Thread model: posix
gcc version 4.5.0 20100330 (experimental) (GCC)
Here's the last bits of today's build log - the '--disable-multilib' configure
option should have skipped the 'amd64' stuff below ...
config.status: executing default commands
Adding multilib support to Makefile in /home/ahaas/gnu/gcc.git/libgcc
multidirs=amd64
with_multisubdir=
Running configure in multilib subdirs amd64
pwd: /export/home/arth/gnu/gcc-0401/i386-pc-solaris2.10/libgcc
Running configure in multilib subdir amd64
pwd: /export/home/arth/gnu/gcc-0401/i386-pc-solaris2.10
mkdir amd64
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /export/home/arth/local/bin/ginstall -c
checking for gawk... gawk
checking build system type... i386-pc-solaris2.10
checking host system type... i386-pc-solaris2.10
checking for i386-pc-solaris2.10-ar...
/export/home/arth/local/i386-pc-solaris2.10/bin/ar
checking for i386-pc-solaris2.10-lipo... lipo
checking for i386-pc-solaris2.10-nm... /export/home/arth/gnu/gcc-0401/./gcc/nm
checking for i386-pc-solaris2.10-ranlib...
/export/home/arth/local/i386-pc-solaris2.10/bin/ranlib
checking for i386-pc-solaris2.10-strip...
/export/home/arth/local/i386-pc-solaris2.10/bin/strip
checking whether ln -s works... yes
checking for i386-pc-solaris2.10-gcc...
/export/home/arth/gnu/gcc-0401/./gcc/xgcc
-B/export/home/arth/gnu/gcc-0401/./gcc/
-B/export/home/arth/local/i386-pc-solaris2.10/bin/
-B/export/home/arth/local/i386-pc-solaris2.10/lib/ -isystem
/export/home/arth/local/i386-pc-solaris2.10/include -isystem
/export/home/arth/local/i386-pc-solaris2.10/sys-include -m64
checking for suffix of object files... configure: error: in
`/export/home/arth/gnu/gcc-0401/i386-pc-solaris2.10/amd64/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[2]: *** [configure-stage1-target-libgcc] Error 1
make[2]: Leaving directory `/export/home/arth/gnu/gcc-0401'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/export/home/arth/gnu/gcc-0401'
make: *** [bootstrap-lean] Error 2
The 'config.log' file from the 'i386-pc-solaris2.10/amd64/libgcc' directory
fails with errors regard the x86-64 instructions ...
configure:3211: checking for suffix of object files
configure:3233: /export/home/arth/gnu/gcc-0401/./gcc/xgcc
-B/export/home/arth/gnu/gcc-0401/./gcc/
-B/export/home/arth/local/i386-pc-solaris2.10/bin/
-B/export/home/arth/local/i386-pc-solaris2.10/lib/ -isystem
/export/home/arth/local/i386-pc-solaris2.10/include -isystem
/export/home/arth/local/i386-pc-solaris2.10/sys-include -m64 -c -g -O2
conftest.c >&5
conftest.c:1:0: error: CPU you selected does not support x86-64 instruction set
conftest.c:1:0: error: CPU you selected does not support x86-64 instruction set
configure:3237: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3251: error: in
`/export/home/arth/gnu/gcc-0401/i386-pc-solaris2.10/amd64/libgcc':
configure:3254: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
My builds on a sparc-sun-solaris2.10 from yesterday worked fine - on
this machine GCC does _not_ use the '--disable-multilib' configuration
switch. This mornings build has just started.
My thanks to everyone working on GCC.
Art Haas
Re: Bootstrap failures on i386-pc-solaris2.10
On Thu, Apr 1, 2010 at 7:14 AM, Art Haas wrote:
> Hi.
>
> My builds on my X86 solaris box have failed since yesterday, and
> I've just found bug 43615 in Bugzilla which indicates a different
> but similar issue for an x86-64 build.I'm running Solaris 10 on an
> older Dell box with a Pentium4 chip, and have been building
> gcc with the '--disable-multilib' argument for quite some time.
>
> Here's the config info from the last build which worked:
>
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/i386-pc-solaris2.10/4.5.0/lto-wrapper
> Target: i386-pc-solaris2.10
> Configured with: /home/ahaas/gnu/gcc.git/configure
> --prefix=/export/home/arth/local --enable-languages=c,c++,objc,fortran
> --disable-nls --with-gmp=/export/home/arth/local
> --with-mpfr=/export/home/arth/local --enable-checking=release
> --enable-threads --with-gnu-as --with-as=/export/home/arth/local/bin/as
> --with-gnu-ld --with-ld=/export/home/arth/local/bin/ld --disable-multilib
> --disable-libstdcxx-pch --enable-objc-gc --build=i386-pc-solaris2.10
> --with-arch=pentium4 --with-tune=pentium4
> Thread model: posix
> gcc version 4.5.0 20100330 (experimental) (GCC)
>
> Here's the last bits of today's build log - the '--disable-multilib' configure
> option should have skipped the 'amd64' stuff below ...
>
> config.status: executing default commands
> Adding multilib support to Makefile in /home/ahaas/gnu/gcc.git/libgcc
> multidirs=amd64
> with_multisubdir=
> Running configure in multilib subdirs amd64
> pwd: /export/home/arth/gnu/gcc-0401/i386-pc-solaris2.10/libgcc
> Running configure in multilib subdir amd64
> pwd: /export/home/arth/gnu/gcc-0401/i386-pc-solaris2.10
> mkdir amd64
> configure: creating cache ./config.cache
> checking for --enable-version-specific-runtime-libs... no
> checking for a BSD-compatible install... /export/home/arth/local/bin/ginstall
> -c
> checking for gawk... gawk
> checking build system type... i386-pc-solaris2.10
> checking host system type... i386-pc-solaris2.10
> checking for i386-pc-solaris2.10-ar...
> /export/home/arth/local/i386-pc-solaris2.10/bin/ar
> checking for i386-pc-solaris2.10-lipo... lipo
> checking for i386-pc-solaris2.10-nm... /export/home/arth/gnu/gcc-0401/./gcc/nm
> checking for i386-pc-solaris2.10-ranlib...
> /export/home/arth/local/i386-pc-solaris2.10/bin/ranlib
> checking for i386-pc-solaris2.10-strip...
> /export/home/arth/local/i386-pc-solaris2.10/bin/strip
> checking whether ln -s works... yes
> checking for i386-pc-solaris2.10-gcc...
> /export/home/arth/gnu/gcc-0401/./gcc/xgcc
> -B/export/home/arth/gnu/gcc-0401/./gcc/
> -B/export/home/arth/local/i386-pc-solaris2.10/bin/
> -B/export/home/arth/local/i386-pc-solaris2.10/lib/ -isystem
> /export/home/arth/local/i386-pc-solaris2.10/include -isystem
> /export/home/arth/local/i386-pc-solaris2.10/sys-include -m64
> checking for suffix of object files... configure: error: in
> `/export/home/arth/gnu/gcc-0401/i386-pc-solaris2.10/amd64/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.
> make[2]: *** [configure-stage1-target-libgcc] Error 1
> make[2]: Leaving directory `/export/home/arth/gnu/gcc-0401'
> make[1]: *** [stage1-bubble] Error 2
> make[1]: Leaving directory `/export/home/arth/gnu/gcc-0401'
> make: *** [bootstrap-lean] Error 2
>
> The 'config.log' file from the 'i386-pc-solaris2.10/amd64/libgcc' directory
> fails with errors regard the x86-64 instructions ...
>
> configure:3211: checking for suffix of object files
> configure:3233: /export/home/arth/gnu/gcc-0401/./gcc/xgcc
> -B/export/home/arth/gnu/gcc-0401/./gcc/
> -B/export/home/arth/local/i386-pc-solaris2.10/bin/
> -B/export/home/arth/local/i386-pc-solaris2.10/lib/ -isystem
> /export/home/arth/local/i386-pc-solaris2.10/include -isystem
> /export/home/arth/local/i386-pc-solaris2.10/sys-include -m64 -c -g -O2
> conftest.c >&5
> conftest.c:1:0: error: CPU you selected does not support x86-64 instruction
> set
> conftest.c:1:0: error: CPU you selected does not support x86-64 instruction
> set
> configure:3237: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "GNU C Runtime Library"
> | #define PACKAGE_TARNAME "libgcc"
> | #define PACKAGE_VERSION "1.0"
> | #define PACKAGE_STRING "GNU C Runtime Library 1.0"
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
> | /* end confdefs.h. */
> |
> | int
> | main ()
> | {
> |
> | ;
> | return 0;
> | }
> configure:3251: error: in
> `/export/home/arth/gnu/gcc-0401/i386-pc-solaris2.10/amd64/libgcc':
> configure:3254: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.
>
> My builds on a sparc-sun-solaris2.10 from yesterday worked fine - on
> this machine GCC does _not_ use the '--disable-multilib' configuration
> switch. This mornings build has just started.
>
> My th
Re: Bootstrap failures on i386-pc-solaris2.10
Hi Art, > My builds on my X86 solaris box have failed since yesterday, and > I've just found bug 43615 in Bugzilla which indicates a different > but similar issue for an x86-64 build.I'm running Solaris 10 on an > older Dell box with a Pentium4 chip, and have been building > gcc with the '--disable-multilib' argument for quite some time. > > Here's the config info from the last build which worked: > > $ gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/i386-pc-solaris2.10/4.5.0/lto-wrapper > Target: i386-pc-solaris2.10 > Configured with: /home/ahaas/gnu/gcc.git/configure > --prefix=/export/home/arth/local --enable-languages=c,c++,objc,fortran > --disable-nls --with-gmp=/export/home/arth/local > --with-mpfr=/export/home/arth/local --enable-checking=release > --enable-threads --with-gnu-as --with-as=/export/home/arth/local/bin/as > --with-gnu-ld --with-ld=/export/home/arth/local/bin/ld --disable-multilib > --disable-libstdcxx-pch --enable-objc-gc --build=i386-pc-solaris2.10 > --with-arch=pentium4 --with-tune=pentium4 > Thread model: posix > gcc version 4.5.0 20100330 (experimental) (GCC) > > Here's the last bits of today's build log - the '--disable-multilib' configure > option should have skipped the 'amd64' stuff below ... The --disable-multilib option has been broken by a recent patch. This is a known bug and will hopefully be fixed soon. Configuring with --with-arch=pentium4 --with-tune=pentium4 is wrong and doesn't work in the general case, as you've discovered, since it breaks the 64-bit support. You just didn't notice the problem before due to --disable-multilib. Use --with-arch_32=pentium4 --with-tune_32=pentium4 instead, or simply update to current mainline: my patch to default the i?86-*-solaris2* configurations to pentium4 just went in. As for the other configure options: --enable-threads is superfluous, it's the default. What are you trying to achieve with --disable-libstdcxx-pch? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: State of the mercurial mirror
Thomas, > The mercurial mirror of the gcc repository, at http://gcc.gnu.org/hg/gcc has > been broken for months. and the contact listed there does not answer > emails. unfortunately true, I've asked the same question quite some time ago. > Can somebody here at least remove those misleading pages..? ... or replace it with hints for converting the svn repo to hg. I'm doing this myself for quite some time, and apart from a few caveats, it works just fine. From my experience, hg is vastly superior to git, which is simply a usability nightmare, as Dan Berlin discovered when he worked on setting up the hg mirror. > Also, i would volunteer to fix this, and even to maintain the mirror. Is this > the right place to ask ? I don't even know if that's something that would be > well accepted. Any interest for this ? It would certainly be good to keep this working and promote it, especially if this could be a complete conversion of the svn repo, not trunk only. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
RE: Bootstrap failures on i386-pc-solaris2.10
I'll update my repo shortly and replace the '--with-arch' and '--with-tune' arguments as you suggest. As for the '--disable-libstdcxx-pch' argument, I had build problems months ago and this argument fixed the problem, although now looking at the configure script for libstdc it looks like the correct argument should be '--enable-libstdcxx-pch=no' if it is to be used. The '--enable-threads' argument is another configuration option I added long ago as well. The script which configures and starts my GCC builds needs some cleanup ... Thanks. Art Haas -Original Message- From: Rainer Orth [mailto:r...@cebitec.uni-bielefeld.de] Sent: Thursday, April 01, 2010 9:25 AM To: Arthur Haas Cc: gcc@gcc.gnu.org Subject: Re: Bootstrap failures on i386-pc-solaris2.10 Hi Art, > My builds on my X86 solaris box have failed since yesterday, and > I've just found bug 43615 in Bugzilla which indicates a different > but similar issue for an x86-64 build.I'm running Solaris 10 on an > older Dell box with a Pentium4 chip, and have been building > gcc with the '--disable-multilib' argument for quite some time. > > Here's the config info from the last build which worked: > > $ gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/i386-pc-solaris2.10/4.5.0/lto-wrapper > Target: i386-pc-solaris2.10 > Configured with: /home/ahaas/gnu/gcc.git/configure > --prefix=/export/home/arth/local --enable-languages=c,c++,objc,fortran > --disable-nls --with-gmp=/export/home/arth/local > --with-mpfr=/export/home/arth/local --enable-checking=release > --enable-threads --with-gnu-as --with-as=/export/home/arth/local/bin/as > --with-gnu-ld --with-ld=/export/home/arth/local/bin/ld --disable-multilib > --disable-libstdcxx-pch --enable-objc-gc --build=i386-pc-solaris2.10 > --with-arch=pentium4 --with-tune=pentium4 > Thread model: posix > gcc version 4.5.0 20100330 (experimental) (GCC) > > Here's the last bits of today's build log - the '--disable-multilib' configure > option should have skipped the 'amd64' stuff below ... The --disable-multilib option has been broken by a recent patch. This is a known bug and will hopefully be fixed soon. Configuring with --with-arch=pentium4 --with-tune=pentium4 is wrong and doesn't work in the general case, as you've discovered, since it breaks the 64-bit support. You just didn't notice the problem before due to --disable-multilib. Use --with-arch_32=pentium4 --with-tune_32=pentium4 instead, or simply update to current mainline: my patch to default the i?86-*-solaris2* configurations to pentium4 just went in. As for the other configure options: --enable-threads is superfluous, it's the default. What are you trying to achieve with --disable-libstdcxx-pch? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Bootstrap failures on i386-pc-solaris2.10
"H.J. Lu" writes: > It may be related to > > http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01483.html No, it's not, quite the contrary. For one, Art did his build before this patch went in, second, as explained in the message, I've been careful to only set with_arch_32 and with_tune_32. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: State of the mercurial mirror
Thomas Capricelli writes: > The mercurial mirror of the gcc repository, at > http://gcc.gnu.org/hg/gcc has been broken for months. and the > contact listed there does not answer emails. > > Can somebody here at least remove those misleading pages..? If there is concensus here to remove this obsolete mirror, we can remove it instantly. If there is a volunteer to maintain it, we can probably let her try too. - FChE
Re: State of the mercurial mirror
In data giovedì 01 aprile 2010 16:29:12, Rainer Orth ha scritto: > works just fine. From my experience, hg is vastly superior to git, > which is simply a usability nightmare, as Dan Berlin discovered when he > worked on setting up the hg mirror. I completely agree, but my point was not to start a war git vs mercurial :-) > > Also, i would volunteer to fix this, and even to maintain the mirror. Is > > this the right place to ask ? I don't even know if that's something that > > would be well accepted. Any interest for this ? > > It would certainly be good to keep this working and promote it, > especially if this could be a complete conversion of the svn repo, not > trunk only. I could try to do this. I've converted several repositories, and created mirrors for several projects too. Most of them private/closed source (i'm working as a consultant). I did the migration svn->mercurial for the project eigen, and it was not possible (or very very hard) to do the same for git at this time, because eigen was part of the very big KDE svn repository. ref: http://www.freehackers.org/thomas/2009/05/18/feedback-about-converting-eigen2-to-mercurial/ (btw, eigen is also the source of several template-related bug reports for g++, :-) Thomas -- Thomas Capricelli http://www.freehackers.org/thomas
RE: Bootstrap failures on i386-pc-solaris2.10
By updating to the lastest code in the trunk, and removing the '--with-arch' and '--with-tune' options from my configuration, I've successfully built the latest GCC code. I'll be removing the '--disable-multilib' option from my build configuration now also. Thanks. Art Haas -Original Message- From: Rainer Orth [mailto:r...@cebitec.uni-bielefeld.de] Sent: Thursday, April 01, 2010 9:25 AM To: Arthur Haas Cc: gcc@gcc.gnu.org Subject: Re: Bootstrap failures on i386-pc-solaris2.10 Hi Art, > My builds on my X86 solaris box have failed since yesterday, and > I've just found bug 43615 in Bugzilla which indicates a different > but similar issue for an x86-64 build.I'm running Solaris 10 on an > older Dell box with a Pentium4 chip, and have been building > gcc with the '--disable-multilib' argument for quite some time. > > Here's the config info from the last build which worked: > > $ gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/i386-pc-solaris2.10/4.5.0/lto-wrapper > Target: i386-pc-solaris2.10 > Configured with: /home/ahaas/gnu/gcc.git/configure > --prefix=/export/home/arth/local --enable-languages=c,c++,objc,fortran > --disable-nls --with-gmp=/export/home/arth/local > --with-mpfr=/export/home/arth/local --enable-checking=release > --enable-threads --with-gnu-as --with-as=/export/home/arth/local/bin/as > --with-gnu-ld --with-ld=/export/home/arth/local/bin/ld --disable-multilib > --disable-libstdcxx-pch --enable-objc-gc --build=i386-pc-solaris2.10 > --with-arch=pentium4 --with-tune=pentium4 > Thread model: posix > gcc version 4.5.0 20100330 (experimental) (GCC) > > Here's the last bits of today's build log - the '--disable-multilib' configure > option should have skipped the 'amd64' stuff below ... The --disable-multilib option has been broken by a recent patch. This is a known bug and will hopefully be fixed soon. Configuring with --with-arch=pentium4 --with-tune=pentium4 is wrong and doesn't work in the general case, as you've discovered, since it breaks the 64-bit support. You just didn't notice the problem before due to --disable-multilib. Use --with-arch_32=pentium4 --with-tune_32=pentium4 instead, or simply update to current mainline: my patch to default the i?86-*-solaris2* configurations to pentium4 just went in. As for the other configure options: --enable-threads is superfluous, it's the default. What are you trying to achieve with --disable-libstdcxx-pch? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Optimizing floating point *(2^c) and /(2^c)
On 03/31/2010 11:25 AM, Vincent Lefevre wrote: On 2010-03-31 11:04:03 +0200, Marc Glisse wrote: IMHO this transformation mostly makes sense for the -ffinite-math-only case where you can replace: "put a constant and multiply/divide" by "put a constant and add/sub" and never care about extracting the exponent, overflowing, or anything else. And in that case, it does look like a nice optimization. I suppose that this could be interesting only if a same register can be seen as a FP one and an integer one (for the addition on the exponent field), hoping that mixing both kinds of operations won't stall the pipeline. Indeed, this is a problem on Intel chips looking at the definition of TARGET_SSE_TYPELESS_STORES (search for X86_TUNE_SSE_TYPELESS_STORES in config/i386/i386.c). Paolo
Re: Bootstrap failures on i386-pc-solaris2.10
* Rainer Orth wrote on Thu, Apr 01, 2010 at 04:24:40PM CEST: > The --disable-multilib option has been broken by a recent patch. This > is a known bug and will hopefully be fixed soon. Should be fixed now with r157916 which reverts the offending commit. Apologies for the breakage. Cheers, Ralf
Re: Idea for Google Summer Code : C Compiler for EFI Byte Code implement in gcc
Hello Tristan
I think the main issue is that EFI C dialect is not ANSI-C
compliant: the size of pointer is determined
at the run-time and therefore the layout of the structure is not
static. Gcc doesn't support this model.
I have read the sizeof and VLA in C99
I found a example:
EXAMPLE 3 In this example, the size of a variable-length array is
computed and returned from a function:
#include
size_t fsize3(int n)
{
char b[n+3]; // variable length array
return sizeof b; // execution time sizeof
}
int main()
{
size_t size;
size = fsize3(10); // fsize3 returns 13
return 0;
}
And I found some information with gcc about VLA
(http://gcc.gnu.org/c99status.html)
Does it means that gcc support layout of structure is not static??
thanks
yi-hong
Re: Where can I put the optimization of got for arm back end at?
On 28/03/10 15:45, Carrot Wei wrote: > Hi > > The detailed description of the optimization is at > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129. This is an ARM > specific optimization. > > This optimization uses one less register (the register hold the GOT > base), to get this beneficial the ideal place for it should be before > register allocation. > > Usually expand pass generates instructions to load global variable's > address from GOT entry for each access of the global variable. Later > cse/gcse passes can remove many of them. In order to precisely model > the cost, this optimization should be put after some cse/gcse passes. > > So what is the best place for this optimization? Is there any existed > pass can be enhanced with this optimization? Or should I add a new > pass? The obvious place is machine-dependent reorg, which is a very late pass. Andrew.
Re: Diego Novillo appointed Plugins Reviewer
On Wed, Mar 31, 2010 at 15:13, David Edelsohn wrote: > Please update your listing in the MAINTAINERS file. Thanks. I've updated MAINTAINERS and also added Le-Chun who should've been there long ago. 2010-04-01 Diego Novillo * MAINTAINERS (Plugin): Add myself and Le-Chun Wu. Index: MAINTAINERS === --- MAINTAINERS (revision 157924) +++ MAINTAINERS (working copy) @@ -266,6 +266,8 @@ Fortran Janus Weil ja...@gcc.gnu.org Graphite Daniel Berlin dber...@dberlin.org Graphite Tobias Grosser gros...@fim.uni-passau.de Graphite Sebastian Pop sebastian@amd.com +Plugin Diego Novillo dnovi...@google.com +Plugin Le-Chun Wu l...@google.com register allocationPeter Bergner berg...@vnet.ibm.com register allocationVladimir Makarovvmaka...@redhat.com register allocationKenneth Zadeck zad...@naturalbridge.com
Re: State of the mercurial mirror
Thomas Capricelli writes: > The mercurial mirror of the gcc repository, at > http://gcc.gnu.org/hg/gcc has been broken [...] Or rather, it has gotten stale. I started up update process that should, very very slowly, let it catch up with the present day. If that completes in reasonable time, maybe I'll keep it running. I seem to recall that the reason it was turned off was because the time neeed to update the hg repository (via hgpullsvn) was longer than the mean time between checkins into the svn repository. If that's true and unfixable, that's madness. - FChE
Re: Where can I put the optimization of got for arm back end at?
On Thu, Apr 1, 2010 at 8:10 PM, Andrew Haley wrote: > On 28/03/10 15:45, Carrot Wei wrote: >> Hi >> >> The detailed description of the optimization is at >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129. This is an ARM >> specific optimization. >> >> This optimization uses one less register (the register hold the GOT >> base), to get this beneficial the ideal place for it should be before >> register allocation. >> >> Usually expand pass generates instructions to load global variable's >> address from GOT entry for each access of the global variable. Later >> cse/gcse passes can remove many of them. In order to precisely model >> the cost, this optimization should be put after some cse/gcse passes. >> >> So what is the best place for this optimization? Is there any existed >> pass can be enhanced with this optimization? Or should I add a new >> pass? > > The obvious place is machine-dependent reorg, which is a very late pass. Yes, and after register allocation, i.e. too late for Guozhi. Basically there is no place right now to stuff a pass like that. Question is: Is this optimization really, reallyreallyreally so target specific that a target-independent pass is not the better option? Ciao! Steven
Unexpected output constraints
I'm debugging a Thumb-2 glibc build failure on trunk for
arm-none-linux-gnueabi. I believe it's from Richard Earnshaw's
2010-02-01 patch for TLS patterns, which includes this:
(define_insn "tls_load_dot_plus_four"
[(set (match_operand:SI 0 "register_operand" "=l,r")
(mem:SI (unspec:SI [(match_operand:SI 1 "register_operand" "+l,r")
(const_int 4)
(match_operand 2 "" "")]
UNSPEC_PIC_BASE)))]
It's that "+" on the second operand. It should just be "&", and I
think that will fix the failure (I'll test it shortly). But I'm
looking at what reload does before the failure.
The failing insn is 104, in this sequence:
(insn 103 79 175 2 delta/in7c.i:50 (set (reg/f:SI 217)
(const:SI (unspec:SI [
(symbol_ref:SI ("*.LANCHOR0") [flags 0x1a2])
(const_int 3 [0x3])
(const (unspec:SI [
(const_int 3 [0x3])
] 21))
(const_int 4 [0x4])
] 20))) 658 {*thumb2_movsi_insn} (nil))
...
(insn 104 102 107 11 delta/in7c.i:50 (set (reg:SI 203)
(mem:SI (unspec:SI [
(reg/f:SI 217)
(const_int 4 [0x4])
(const_int 3 [0x3])
] 4) [0 S4 A32])) 659 {tls_load_dot_plus_four} (nil))
For #104, reg_equiv_constant[217] is set to the (const) from #103.
And because r217 is marked as in-out from tls_load_dot_plus_four,
the reload is RELOAD_READ_WRITE. If the operand is an output, then
it can't be correct to replace it with a constant. We ICE
trying to emit (set (const) (reg)).
It seems to me that the problem is marking a register in the RHS of a
set as an output constraint. The reg becomes function_invariant_p and
chaos ensues.
Is this right? If so, is there somewhere that should assert if an
operand's constraint is marked as an output, but not somewhere that
the RTL allows modification of the operand?
--
Daniel Jacobowitz
CodeSourcery
Re: Unexpected output constraints
On 04/01/2010 10:54 PM, Daniel Jacobowitz wrote: > I'm debugging a Thumb-2 glibc build failure on trunk for > arm-none-linux-gnueabi. I believe it's from Richard Earnshaw's > 2010-02-01 patch for TLS patterns, which includes this: > > (define_insn "tls_load_dot_plus_four" > [(set (match_operand:SI 0 "register_operand" "=l,r") > (mem:SI (unspec:SI [(match_operand:SI 1 "register_operand" "+l,r") > (const_int 4) > (match_operand 2 "" "")] >UNSPEC_PIC_BASE)))] > > It's that "+" on the second operand. It should just be "&", and I > think that will fix the failure (I'll test it shortly). That can't be right, "&" only makes sense for outputs. [...] > It seems to me that the problem is marking a register in the RHS of a > set as an output constraint. Yes. There was a similar bug for tls_load_dot_plus_eight recently. In this case it seems that operand 1 is in fact both read and written by the pattern, so the pattern should be something like [(set (match_operand:SI 0 "register_operand" "=l,r") (mem:SI (unspec:SI [(match_dup 1) (const_int 4) (match_operand 2 "" "")] UNSPEC_PIC_BASE))) (clobber (match_operand:SI 1 "register_operand" "+&l,&r"))] That's untested however. Bernd
Re: Unexpected output constraints
On Fri, Apr 02, 2010 at 12:06:28AM +0100, Bernd Schmidt wrote: > On 04/01/2010 10:54 PM, Daniel Jacobowitz wrote: > > I'm debugging a Thumb-2 glibc build failure on trunk for > > arm-none-linux-gnueabi. I believe it's from Richard Earnshaw's > > 2010-02-01 patch for TLS patterns, which includes this: > > > > (define_insn "tls_load_dot_plus_four" > > [(set (match_operand:SI 0 "register_operand" "=l,r") > > (mem:SI (unspec:SI [(match_operand:SI 1 "register_operand" "+l,r") > > (const_int 4) > > (match_operand 2 "" "")] > >UNSPEC_PIC_BASE)))] > > > > It's that "+" on the second operand. It should just be "&", and I > > think that will fix the failure (I'll test it shortly). > > That can't be right, "&" only makes sense for outputs. Yeah, suitable juggling in match_scratch was what I really needed: (define_insn "tls_load_dot_plus_four" [(set (match_operand:SI 0 "register_operand" "=l,r") (mem:SI (unspec:SI [(match_operand:SI 1 "register_operand" "l,r") (const_int 4) (match_operand 2 "" "")] UNSPEC_PIC_BASE))) (clobber (match_scratch:SI 3 "=&1,&1"))] > > It seems to me that the problem is marking a register in the RHS of a > > set as an output constraint. > > Yes. There was a similar bug for tls_load_dot_plus_eight recently. In > this case it seems that operand 1 is in fact both read and written by > the pattern, so the pattern should be something like > > [(set (match_operand:SI 0 "register_operand" "=l,r") > (mem:SI (unspec:SI [(match_dup 1) > (const_int 4) > (match_operand 2 "" "")] >UNSPEC_PIC_BASE))) >(clobber (match_operand:SI 1 "register_operand" "+&l,&r"))] Is there a reason to prefer one of these forms over the other? match_scratch / match_dup always make me ask that question :-) -- Daniel Jacobowitz CodeSourcery
Re: Unexpected output constraints
On 04/01/2010 11:08 PM, Daniel Jacobowitz wrote: > (define_insn "tls_load_dot_plus_four" > [(set (match_operand:SI 0 "register_operand" "=l,r") > (mem:SI (unspec:SI [(match_operand:SI 1 "register_operand" "l,r") > (const_int 4) > (match_operand 2 "" "")] >UNSPEC_PIC_BASE))) >(clobber (match_scratch:SI 3 "=&1,&1"))] That doesn't work either, a matching constraint has to be an input. Also, legitimize_tls_address is calling it with the same reg for both operands, which is going to lead to tears if they're both outputs. So, maybe simply (define_insn "tls_load_dot_plus_four" [(set (match_operand:SI 0 "register_operand" "=l,r") (mem:SI (unspec:SI [(match_operand:SI 1 "register_operand" "0,0") (const_int 4) (match_operand 2 "" "")] UNSPEC_PIC_BASE)))] but on the other hand maybe it's best to find whoever wrote the pattern and ask them what's going on. Bernd
gcc-4.5-20100401 is now available
Snapshot gcc-4.5-20100401 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100401/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 157933 You'll find: gcc-4.5-20100401.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20100401.tar.bz2 C front end and core compiler gcc-ada-4.5-20100401.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20100401.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20100401.tar.bz2 C++ front end and runtime gcc-java-4.5-20100401.tar.bz2 Java front end and runtime gcc-objc-4.5-20100401.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20100401.tar.bz2The GCC testsuite Diffs from 4.5-20100325 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Unexpected output constraints
On Fri, Apr 02, 2010 at 12:27:33AM +0100, Bernd Schmidt wrote: > That doesn't work either, a matching constraint has to be an input. i386 uses this, so I figure it's OK. > Also, legitimize_tls_address is calling it with the same reg for both > operands, which is going to lead to tears if they're both outputs. Hrm. Yeah, those really should be two pseudos. I'll fix that. -- Daniel Jacobowitz CodeSourcery
question about copy right assignment form
Hello, May I know where or whom should I contact to obtain the copyright assignment form? I want to contribute some code to gcc so I think having these forms in place earlier would be a good idea. Another question is I am working full time for a software company and the job is irrelevant to compiler development. I spend my spare time with gcc so I don't think the company owns my work but I am not sure.. In this case, should I also obtain and sign the employer disclaimer form? Thanks! ~Michael Han
Re: Where can I put the optimization of got for arm back end at?
This is really a good question! Consider the requirement of this optimization. 1. There should be at least 2 methods to load a global variable's address from GOT. Usually it means using different relocation types. 2. By default all global variables access use the same one method. 3. In some cases (less than X global variables access) method A is better, in other cases method B is better. With these constraints a simplify_GOT optimization pass is applicable. But these constraints are too weak. The new optimization pass nearly can do nothing except a call to target specific hook. I suspect such a pass is acceptable. We can also add more constraints: 4. If we can restrict method A as following: first load the base address of GOT into a register pic_reg, then the real global variable's address is loaded as load offset_reg, the offset from GOT base to the GOT entry load address, [pic_reg + offset_reg] With this constraint the new pass knows there is a special register pic_reg, it can look for and count all usage of pic_reg. If all usages are method A and the count is more than the target specific threshold, then the usages can be rewritten as method B. The method detection and rewritten should be target specific. I don't know how other targets handle global address access with -fpic. And how many targets satisfy these 4 constraints. thanks Guozhi On Fri, Apr 2, 2010 at 4:31 AM, Steven Bosscher wrote: > On Thu, Apr 1, 2010 at 8:10 PM, Andrew Haley wrote: >> On 28/03/10 15:45, Carrot Wei wrote: >>> Hi >>> >>> The detailed description of the optimization is at >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129. This is an ARM >>> specific optimization. >>> >>> This optimization uses one less register (the register hold the GOT >>> base), to get this beneficial the ideal place for it should be before >>> register allocation. >>> >>> Usually expand pass generates instructions to load global variable's >>> address from GOT entry for each access of the global variable. Later >>> cse/gcse passes can remove many of them. In order to precisely model >>> the cost, this optimization should be put after some cse/gcse passes. >>> >>> So what is the best place for this optimization? Is there any existed >>> pass can be enhanced with this optimization? Or should I add a new >>> pass? >> >> The obvious place is machine-dependent reorg, which is a very late pass. > > Yes, and after register allocation, i.e. too late for Guozhi. > > Basically there is no place right now to stuff a pass like that. > Question is: Is this optimization really, reallyreallyreally so target > specific that a target-independent pass is not the better option? > > Ciao! > Steven >
Re: State of the mercurial mirror
In data giovedì 01 aprile 2010 21:13:20, Frank Ch. Eigler ha scritto: > > The mercurial mirror of the gcc repository, at > > http://gcc.gnu.org/hg/gcc has been broken [...] > > Or rather, it has gotten stale. I started up update process that > should, very very slowly, let it catch up with the present day. If > that completes in reasonable time, maybe I'll keep it running. I seem > to recall that the reason it was turned off was because the time neeed > to update the hg repository (via hgpullsvn) was longer than the mean > time between checkins into the svn repository. If that's true and > unfixable, that's madness. I dont know what hgpullsvn is (a script of yours?). But a typical mirror is pretty fast to sync, especially if both repositories are local (same hard disk or at least same computer). The initial import can take some time, mainly because of svn (not hg). I have a local mirror here (only for gcc trunk, and only starting at rev 156000) and a warm sync (just after a sync was done, there's nothing to actually sync, this measures the overhead) takes 0.628u 0.164s 0:07.48 I think 99% of this is spent in network communication between my computer and gcc svn server. ++ Thomas
