how to dump tree in pt.c:tsubst?

[Larry Evans]

How does one dump the trees in pt.c:tsubst in some hunan readable 
format.  I've tried:


  struct dump_info di;
  di.stream=stderr;
  cp_dump_tree(&di, args);
  cp_dump_tree(&di, arg);
  cp_dump_tree(&di, t);

however, no ouput is produced because the TREE_CODE for each of
the 2nd args doesn't match anything in the switch statements
inside cp_dump_tree (defined in cp/dump.c).

TIA.

Re: ICE in gcc/libgcc2.c:566 (gcc trunk)

[Hanno Meyer-Thurow]

On 07 Feb 2007 15:36:14 -0800
Ian Lance Taylor <[EMAIL PROTECTED]> wrote:

> Can anybody else out there recreate this on their x86_64 system?

Not that I could not recreate the segfault but I found a way to hide the
segfault. Instead of optimizing with nocona

make \
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common" \
STAGE1_CFLAGS="-O" \
LIBPATH="/usr/lib/gcj-4.3.0_alpha20070209/lib64" \
BOOT_CFLAGS=" -O2 -mtune=nocona -march=nocona -pipe -msse3 
-mfpmath=sse" \
bootstrap

optimizing stage2/stage3 c compiler with core2 like

make \
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common" \
STAGE1_CFLAGS="-O" \
LIBPATH="/usr/lib/gcj-4.3.0_alpha20070209/lib64" \
BOOT_CFLAGS=" -O2 -mtune=core2 -march=core2 -pipe -msse3 
-mssse3 -mfpmath=sse" \
bootstrap

helps here. So, at least one can workaround this now.


Regards,
Hanno

Re: GCC 4.1.2 RC2

[Kaveh R. GHAZI]

On Fri, 9 Feb 2007, Mark Mitchell wrote:

> GCC 4.1.2 RC2 is now available from:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.2-20070208
>
> and its mirrors.
>
> The changes relative to RC1 are fixes for:
>
> 1. PR 29683: a wrong-code issue on Darwin
> 2. PR 30370: a build problem for certain PowerPC configurations
> 3. PR 29487: a build problem for HP-UX 10.10 a code-quality problem for
> C++ on all platforms
>
> If you find problems in RC2, please file them in Bugzilla.  For any
> issues which are regressions relative to 4.1.1 or 4.1.0, please alert me
> by email, referencing the Bugzilla PR number.  Please do not send me
> email before filing a PR in Bugzilla.
>
> Based on the absence of issues reported for GCC 4.1.2 RC1, I expect GCC
> 4.1.2 to be identical to these sources, other than version numbers, and
> so forth.  I intend to spin the final release early next week.
>
> Thanks,
> Mark Mitchell

Test results for sparc/sparc64 on solaris2.10 are here:
http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00422.html
http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00423.html

Comparing this to previous 4.1.x there are a few new failures:

1.  g++.dg/debug/debug9.C fails as described in PR 30649.  I believe this
is simply a mistaken testcase checkin.  If confirmed by someone, no big
deal I can remove it.

2.  g++.dg/tree-ssa/nothrow-1.C fails with -fpic/-fPIC.  This seems to be
a regression and started sometime between Oct 8 and Nov 2, 2006.  I don't
have historical test results any finer grained than that and I don't think
other solaris2 testers use -fpic/-fPIC.  Here are my posts from that time:
http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00509.html
http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00076.html

If I had to guess, I'd say it started with this checkin:

 > 2006-10-14  Richard Guenther  <[EMAIL PROTECTED]>
 >
 > PR rtl-optimization/29323
 > * decl.c (finish_function): Set TREE_NOTHROW only for
 > functions that bind local.

And as with some -fpic/-fPIC failures, there's a chance it's simply a
problem with the testcase that's incompatible with pic, not a problem with
the compiler.  If so we can adjust the testcase code or simply skip it
when using pic.

3.  gcc.c-torture/execute/20061101-1.c is a new failure at -O2 and at more
opt levels with -fpic/-fPIC, but that testcase is from November so it's
probably not a regression.

4.  gcc.dg/tree-ssa/20030714-1.c fails with -fpic/-fPIC and this one
appears to have regressed since the case is from 2003.  It started failing
between June 18 and June 22, 2006 in the 4.1.x branch:

http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg01003.html
http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg01167.html

5.  gfortran.dg/cray_pointers_2.f90 fails with -fPIC (not -fpic).  The
error message is:

ld: fatal: too many symbols require `small' PIC references:
have 4604, maximum 2048 -- recompile some modules -K PIC.
collect2: ld returned 1 exit status

This one appears to be a regression from previous 4.1.x and 4.0 where it
works.  It looks like it started between June 18 and June 22, 2006:

http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg01003.html
http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg01167.html

6.  22_locale/num_put/put/wchar_t/14220.cc fails with sparc64 -fpic/-fPIC.
The sparc32 doesn't fail.  This is a regression from the previous 4.1
release and 4.0.x.  The testsuite logfile doesn't say anything about what
failed.  It started failing sometime between Oct 8 and Nov 2, 2006, which
like #2 above has a wide gap between my historical test posts.

http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00509.html
http://gcc.gnu.org/ml/gcc-testresults/2006-11/msg00076.html


I don't know whether any of these are important enough to hold up the
release, most appear not.  Maybe Eric can comment.

Thanks,
--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: GCC 4.1.2 RC2

[Eric Botcazou]

> 1.  g++.dg/debug/debug9.C fails as described in PR 30649.  I believe this
> is simply a mistaken testcase checkin.  If confirmed by someone, no big
> deal I can remove it.

Looks bogus to me like the 2 other testcases.

> 3.  gcc.c-torture/execute/20061101-1.c is a new failure at -O2 and at more
> opt levels with -fpic/-fPIC, but that testcase is from November so it's
> probably not a regression.

This is a real failure at -O2, caused by a bad iteraction between the old loop 
optimizer and the insn cost settings in the SPARC back-end.  But it's not a 
regression in the 4.x series.  Of course it will be gone in 4.2 and later.
I wrote a patch for the back-end at some point, but the problem is really in 
the old loop optimizer.  I think we can simply mark it as XFAIL on SPARC.

> I don't know whether any of these are important enough to hold up the
> release, most appear not.

The -fpic/-fPIC failures are a little annoying but other platforms probably 
have similar glitches, so we can live with them (I personally don't test
with -fpic/-fPIC so I have only the above 2 failures in my logs).

Results on other versions of Solaris are on par with those on Solaris 10.

-- 
Eric Botcazou

Re: US Daylight Savings Time Changes

[Mark Mitchell]

David Edelsohn wrote:
>> Tom Tromey writes:
> 
> Tom> David probably knows this, but for others, Jakub and Andrew put in a
> Tom> patch for this today.  I think it is only on trunk, not any other
> Tom> branches.
> 
>   Should this be included in GCC 4.1.2?

Unfortunately, I think it's too late for that.  Java is not a major
release priority, and at this point I'm not anticipating a 4.1.2 RC3.
However, I would suggest that we apply the patch to the 4.1 branch after
4.1.2 is released, assuming that the Java maintainers are comfortable
with that.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: meaning of --enable-checking flags

[Kaveh R. GHAZI]

On Fri, 9 Feb 2007, Larry Evans wrote:

> The doc on --enable-checking at:
>
>http://gcc.gnu.org/install/configure.html
>
> contains:
>
>--enable-checking=list
>
> and implies that list may either be a category (yes,all,release,no) or a
> sequence of flags (e.g. fold,gcac,gc,valgrind); however, it doesn't
> describe what the flags mean.  Could someone do that or provide
> a link to the descriptions.

The --enable-checking values are described briefly in gcc/config.in,
here's a link for quick access:
http://gcc.gnu.org/viewcvs/trunk/gcc/config.in?revision=120315&view=markup

I think a patch adding descriptions to the docs would be an improvement.
Would you like to submit one?

Thanks,
--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: GCC 4.1.2 RC2

[Mark Mitchell]

Kaveh R. GHAZI wrote:

[Java folks: see below for check-in window for daylight savings time
patches.]

> Test results for sparc/sparc64 on solaris2.10 are here:
> http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00422.html
> http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00423.html

Thanks!

In general, I think it's too late to fix anything but the mostly truly
egregious problems at this point.  There have been lots of opportunities
to report problems in 4.1.2; at this point, I want to get it out the
door, and start pushing on 4.2.0.

> 1.  g++.dg/debug/debug9.C fails as described in PR 30649.  I believe this
> is simply a mistaken testcase checkin.  If confirmed by someone, no big
> deal I can remove it.

I think there's no question this is a bogus checkin.  I've removed the
testcase.

> 2.  g++.dg/tree-ssa/nothrow-1.C fails with -fpic/-fPIC.

This appears to be another manifestation of the problem from PR 29487
(now fixed).  Here, the compiler is again making an unreasonably
conservative assumption that will substantially penalize C++ shared
libraries: namely, that all global functions in shared libraries may be
replaced at link time, and that callers must therefore assume that they
may throw exceptions.

You are correct that this stems from Richard's patch, though that patch
made sense on its own: he used the same rules for exceptions that were
otherwise used for const/pure functions.

I think the key flaw here is that we are using binds_local_p in two
different ways.  One way is to tell us what kind of references we can
emit; for a locally bound entity we may/must use certain relocations,
etc., that we cannot with a global entity.  However, I think it's
unreasonably pessimistic to say that just because the user might use the
linker to replace a function in some way, we can't reason from the
function's behavior.  If the user doesn't state that intent explicitly
(by declaring the function weak), I think we should be free to optimize
based on the body of the function.

I think that this suggests that even the definition of
DECL_REPLACEABLE_P that I checked in is too conservative.  Perhaps the
definition should simply be "DECL_WEAK (decl) && !DECL_COMDAT (decl))";
in other words, only explicitly weak functions are replaceable from an
optimization point of view.  It was weak functions that were the
motivation for the original change.

I would certainly appreciate comments from others about this issue.

I do think this is an important issue; it would be bad for Mozilla, KDE,
etc., to suffer a significant optimization issue in going from 4.1.1 to
4.1.2.  I was pretty determined to get 4.1.2 out the door, and I really
don't want to have any functional changes between the last RC and the
actual release.  So, I feel that I have no choice but to do a 4.1.2 RC3
with a more conservative version of DECL_REPLACEABLE_P.

Therefore, if the Java folks have daylight savings time patches that
they would like to check in, please do so before Monday evening,
California time.  If these work out, we'll leave them in for 4.1.2;
otherwise, we'll back them out.  We will not do an RC4 simply to correct
problems in these patches: the choices will be only to keep the patches
checked in or to take them out entirely.

> 4.  gcc.dg/tree-ssa/20030714-1.c fails with -fpic/-fPIC and this one
> appears to have regressed since the case is from 2003. 

This looks to be at worst a minor code quality issue.

> 6.  22_locale/num_put/put/wchar_t/14220.cc fails with sparc64 -fpic/-fPIC.

This is unfortunate, but I don't see any evidence of a major blocking
issue there.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Is compare no longer enabled by default?

[H. J. Lu]

"make bootstrap" used to compare stage2 and stage3 after gcc was
bootstrapped. "make bootstrap" would abort if comparison was failed.
Now, compare stage2 and stage3 is not longer done for
"make bootstrap".  Is that intentional? I think it is a very bad
idea.


H.J.

Re: Is compare no longer enabled by default?

[H. J. Lu]

On Sun, Feb 11, 2007 at 01:00:41PM -0800, H. J. Lu wrote:
> "make bootstrap" used to compare stage2 and stage3 after gcc was
> bootstrapped. "make bootstrap" would abort if comparison was failed.
> Now, compare stage2 and stage3 is not longer done for
> "make bootstrap".  Is that intentional? I think it is a very bad
> idea.

I opened a bug:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30767


H.J.

Re: ICE in gcc/libgcc2.c:566 (gcc trunk)

[H. J. Lu]

On Sun, Feb 11, 2007 at 05:11:15PM +0100, Hanno Meyer-Thurow wrote:
> On 07 Feb 2007 15:36:14 -0800
> Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> 
> > Can anybody else out there recreate this on their x86_64 system?
> 
> Not that I could not recreate the segfault but I found a way to hide the
> segfault. Instead of optimizing with nocona
> 
>   make \
>   LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common" \
>   STAGE1_CFLAGS="-O" \
>   LIBPATH="/usr/lib/gcj-4.3.0_alpha20070209/lib64" \
>   BOOT_CFLAGS=" -O2 -mtune=nocona -march=nocona -pipe -msse3 
> -mfpmath=sse" \
>   bootstrap
> 

-mtune=nocona seems to miscompile the stage3 compiler. I got

bash-3.1$ make compare
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
Bootstrap comparison failure!
./tree-vrp.o differs
./tree-ssa-operands.o differs
./build/genpreds.o differs
./build/gengtype-yacc.o differs
./build/genattrtab.o differs
./tree-ssa-alias.o differs
./tree-eh.o differs
./tree-tailcall.o differs
./ipa-reference.o differs
./c-common.o differs
./sched-rgn.o differs
./dominance.o differs
./reload1.o differs
./tree-cfg.o differs
./flow.o differs
./fold-const.o differs
./gcc.o differs
./c-decl.o differs
./tree-ssa-dce.o differs
./bt-load.o differs
./tree-ssa-ter.o differs
./function.o differs
./ddg.o differs
./tree.o differs
./tree-ssa.o differs
./loop-unroll.o differs
./expmed.o differs
./df-scan.o differs
./tree-sra.o differs
./resource.o differs
./except.o differs
./predict.o differs
./tree-ssa-dse.o differs
./df-core.o differs
./cfgloopmanip.o differs
./calls.o differs
./real.o differs
./gcse.o differs
./bitmap.o differs
./c-pragma.o differs
./explow.o differs
./loop-invariant.o differs
./tree-object-size.o differs
./tree-ssa-structalias.o differs
./sched-deps.o differs
./tree-ssa-threadupdate.o differs
./pretty-print.o differs
./tree-pretty-print.o differs
./tree-ssa-sink.o differs
./df-problems.o differs
./tree-into-ssa.o differs
./lower-subreg.o differs
./caller-save.o differs
./loop-iv.o differs
./tree-nested.o differs
./combine.o differs
./tree-ssa-loop-ivopts.o differs
./c-parser.o differs
./cfgrtl.o differs
./tree-scalar-evolution.o differs
./tree-ssa-live.o differs
./ifcvt.o differs
./expr.o differs
./ipa-type-escape.o differs
./i386.o differs
./local-alloc.o differs
./tree-ssa-dom.o differs
./c-typeck.o differs
./bb-reorder.o differs
./tree-ssa-pre.o differs
./global.o differs
./see.o differs
./tree-ssa-loop-manip.o differs
./cfgcleanup.o differs
./cfgexpand.o differs
./tree-ssa-coalesce.o differs
./stor-layout.o differs
make: *** [compare] Error 1

when passed I BOOT_CFLAGS="-O2 -g -mtune=nocona -pipe" to bootstrap.

"make bootstrap" should have checked it. Due to a gcc regression:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30767

"make bootstrap" didn't stop when the stage3 compiler was bad.

H.J.

Pre Compiled Headers

[Brendon Costa]

Hi All,

I am coding an extension for GCC and am having some difficulty with
pre-compiled headers. I dont know if my understanding of how they work
is completely correct and so my code is getting a segfault.

I have a hook into gimplify_function_tree() and I process functions as
they pass through that function.

When compiling a PCH file, the functions being compiled will come
through gimplify_function_tree() i will process them for callgraph and
exception information (which is what my program does), and then store
references to the tree nodes I use into a GTY rooted node as a tree
chain list. This should prevent the nodes from being garbage collected
which is something I want at the moment because i re-visit all the nodes
after the compilation process has been completed (This is not the best
solution but the easiest for my situation at the moment).

In addition to preventing garbage collection of nodes i am interested in
from what i understand of the PCH mechanism, when compiling a file that
uses a PCH GCC should magically re-construct the chain of tree nodes
rooted at the GTY base. What i need to do is then look over those nodes
again after they have been reconstructed and re-process them for
callgraph and exception information (Yes i know this is not good as it
means there is duplicate processing of nodes which is what PCH files are
trying to avoid, but please ignore this fact for the moment).

So i also hook into c_common_no_more_pch() and when it is called i will
look at the tree chain and "re-calculate" the data from the nodes that
should have been recreated from the PCH engine. There seem to be tree
nodes re-created in the tree chain list, however upon trying to process
these nodes I get a segfault almost as though the pointers have been
restored by the PCH engine, but the memory they point to has not.

I am using gcc 4.0.1 on a i386 NetBSD 3.0 system.

Questions:

1) Is there a better place to hook into to know when the PCH engine has
completed reconstructing the tree nodes?

2) Is there something wrong in the way i understand the reconstruction
of data by the PCH engine? I assumed it would re-construct a full tree
hierarchy if i rooted a tree node.

Thanks,
Brendon.

Re: Is compare no longer enabled by default?

[Andreas Schwab]

"H. J. Lu" <[EMAIL PROTECTED]> writes:

> Now, compare stage2 and stage3 is not longer done for
> "make bootstrap".

Since when?  Works fine for me.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GCC 4.1.2 RC2

[Eric Botcazou]

> Therefore, if the Java folks have daylight savings time patches that
> they would like to check in, please do so before Monday evening,
> California time.  If these work out, we'll leave them in for 4.1.2;
> otherwise, we'll back them out.  We will not do an RC4 simply to correct
> problems in these patches: the choices will be only to keep the patches
> checked in or to take them out entirely.

What about the patch for PR other/27843 then?

-- 
Eric Botcazou

Re: meaning of --enable-checking flags

[Larry Evans]

On 02/11/2007 02:16 PM, Kaveh R. GHAZI wrote:

On Fri, 9 Feb 2007, Larry Evans wrote:

[snip]

describe what the flags mean.  Could someone do that or provide
a link to the descriptions.



The --enable-checking values are described briefly in gcc/config.in,
here's a link for quick access:
http://gcc.gnu.org/viewcvs/trunk/gcc/config.in?revision=120315&view=markup

I think a patch adding descriptions to the docs would be an improvement.
Would you like to submit one?

Thanks,
--Kaveh

I could, but the only thing I would do would be something like:

  The meaning of these flags can be inferred from the comments in
  gcc/config.in.

Of course, then anyone modifying gcc/config.in would have to make
sure that those comments remain there or, if they're moved somewhere
else, then http://gcc.gnu.org/install/configure.html would have to be
modified to reflect the new location.  I guess that means config.in
would also have to have a comment indicating that configure.html
depends on it.

Does this sound reasonable?

Re: GCC 4.1.2 RC2

[Mark Mitchell]

Eric Botcazou wrote:
>> Therefore, if the Java folks have daylight savings time patches that
>> they would like to check in, please do so before Monday evening,
>> California time.  If these work out, we'll leave them in for 4.1.2;
>> otherwise, we'll back them out.  We will not do an RC4 simply to correct
>> problems in these patches: the choices will be only to keep the patches
>> checked in or to take them out entirely.
> 
> What about the patch for PR other/27843 then?

It's OK with me to check that in, assuming it's been approved for
mainline and 4.2.  However, the same rules apply: I'll back it out,
rather than try to fix it, for a final release.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: meaning of --enable-checking flags

[Larry Evans]

On 02/11/2007 04:28 PM, Larry Evans wrote:
[snip]

I think a patch adding descriptions to the docs would be an improvement.
Would you like to submit one?

Thanks,
--Kaveh


I could, but the only thing I would do would be something like:

  The meaning of these flags can be inferred from the comments in
  gcc/config.in.


[snip]
I tried downloading and editying
http://gcc.gnu.org/install/configure.html; however, I soon ran into 
problems.  Attached is a diff between the original .html and the

modifications I tried.  It shows that even the comments in config.in
are confusing :(

*** configure.html  2007/02/11 22:56:59 1.1
--- configure.html  2007/02/11 23:39:58
***
*** 666,674 
  `--enable-checking=none' must be 
explicitly requested.  Disabling
  assertions will make the compiler and runtime slightly faster but
  increase the risk of undetected internal errors causing wrong code to be
! generated.
  
!  
--enable-coverage--enable-coverage=levelWith
 this option, the compiler is built to collect self coverage
  information, every time it is run.  This is for internal development
  purposes, and only works when the compiler is being built with gcc.  The
  level argument controls whether the compiler is built optimized or
--- 666,698 
  `--enable-checking=none' must be 
explicitly requested.  Disabling
  assertions will make the compiler and runtime slightly faster but
  increase the risk of undetected internal errors causing wrong code to be
! generated.
  
!  The meaning of the flags (paraphrased from 
http://gcc.gnu.org/viewcvs/trunk/gcc/config.in?revision=120315&view=markup ) 
are as follows:
!
!  assert:
!Enables assertions. This is a cheap check.
!
!  
!  fold:
!fold checked that it never destructs its argument. This
!is quite expensive.
!
!LJEvans:  This is unclear.  What is fold.  Is it a
!function?  If so, does this assure that that function never
!destructs the arguments passed through the argument list?
!If so, when would this be useful.  I guess this would only
!mean something to someone already familiar with the
!compiler.  If so, there needs to be a link to some
!documentation of fold.
!
!  
!
!  
! 
!  
! 
!  
--enable-coverage--enable-coverage=levelWith
 this option, the compiler is built to collect self coverage
  information, every time it is run.  This is for internal development
  purposes, and only works when the compiler is being built with gcc.  The
  level argument controls whether the compiler is built optimized or
***
*** 1004,1007 
  
  
  
! 
\ No newline at end of file
--- 1028,1031 
  
  
  
! 

Re: meaning of --enable-checking flags

[Gerald Pfeifer]

On Sun, 11 Feb 2007, Larry Evans wrote:

[snip]
I tried downloading and editying
http://gcc.gnu.org/install/configure.html; however, I soon ran into problems.
Attached is a diff between the original .html and the
modifications I tried.  It shows that even the comments in config.in
are confusing :(


I can't comment on the contents, but that HTML file is generated from 
our texinfo documentation; the master source for that is


 gcc/doc/install.texi

in our SVN repository.

Gerald

Re: ICE in gcc/libgcc2.c:566 (gcc trunk)

[H. J. Lu]

On Sun, Feb 11, 2007 at 01:09:40PM -0800, H. J. Lu wrote:
> On Sun, Feb 11, 2007 at 05:11:15PM +0100, Hanno Meyer-Thurow wrote:
> > On 07 Feb 2007 15:36:14 -0800
> > Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> > 
> > > Can anybody else out there recreate this on their x86_64 system?
> > 
> > Not that I could not recreate the segfault but I found a way to hide the
> > segfault. Instead of optimizing with nocona
> > 
> > make \
> > LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common" \
> > STAGE1_CFLAGS="-O" \
> > LIBPATH="/usr/lib/gcj-4.3.0_alpha20070209/lib64" \
> > BOOT_CFLAGS=" -O2 -mtune=nocona -march=nocona -pipe -msse3 
> > -mfpmath=sse" \
> > bootstrap
> > 
> 
> -mtune=nocona seems to miscompile the stage3 compiler. I got
> 

I opened a bug:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30770


H.J.

Re: gcc-4.3, glibc and AC_PROG_CC_STDC

[Paul Eggert]

I am CC'ing this message to gcc@gcc.gnu.org to give GCC developers a
heads-up on the situation.  For GCC developers: please see

for the problem with a gcc-4.3 snapshot with --std=gnu99 -O2" and
glibc wchar.h.

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> Given that there is still discussion and work on GCC for this topic
> anyway[1], I don't think Autoconf should be doing anything just yet.

Both of the solutions that Bruno suggested seem too drastic to me as
well.  I hope we can come up with something less intrusive.

Once GCC 4.3 settles down, perhaps we can work around any remaining
problems with gnulib's wchar module.

A less-appetizing possibility would be to modify AC_PROG_CC_STDC to
specify --std=gnu99 -fgnu89-extern-inline rather than plain
--std=gnu99 if 'configure' detects the problem with wchar.h, or with
any other standard include file.  Presumably this would occur only if
GCC 4.3 (or 4.4?) is used with an older glibc.  But for this case I'm
inclined to ask, along with Ralf, why GCC 4.3 doesn't apply
fixincludes to the troublesome include files.

> If the absolute header inclusion technique employed by gnulib is
> preventing the fixinclude thingy to work,

That should not be a problem.  gnulib's absolute header method should
work even when fixincludes has generated the include file.  (I haven't
tested this, though.)