[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[boschmann at tp1 dot physik.uni-siegen.de]

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

--- Comment #11 from Hans-Werner Boschmann  2010-09-30 07:37:46 UTC ---
So it works with 4.6.0 20100924, but it still doesn't work with 4.6.0 20100921.
Unfortunately, I cannot use the latest revision, until bug 45746 is fixed.
Plus, I assume that the error message will show up in later revisions again.

[Bug c++/45829] Unary minus on static const class variable triggering linker error

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  2010-09-30 
08:10:39 UTC ---
(In reply to comment #8)
> 
> But -a (or 0.0-a) is not a constant expression, so having an in-class
> initializer seems suspicious, couldn't we warn at least?

Eh?  It could be used in a constant expression in a different translation unit.

> What happens if the
> definition is initialized to a different value?

Please read 9.4.2 again

4. ... The member shall still be defined in a name-space scope if it is used in
the program and the namespace scope definition SHALL NOT CONTAIN AN
INITIALIZER.

[Bug c/45054] [4.6 Regression] struct-by-value-1.c fail.

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Iain Sandoe  2010-09-30 08:24:05 
UTC ---
thanks Bernd, 
that is fixed.

[Bug libstdc++/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[potswa at mac dot com]

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

David Krauss  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #1 from David Krauss  2010-09-30 08:28:01 
UTC ---
Well, that's almost certainly my fault, because that patch directly implements
that testcase. However

[Bug libstdc++/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[potswa at mac dot com]

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

--- Comment #2 from David Krauss  2010-09-30 08:30:09 
UTC ---
Well, that's almost certainly my fault, because that patch directly implements
that testcase. However, I can't reproduce it, even after updating and
rebuilding the compiler.

I'm new here, so… I suppose I need to figure out how to use that trace file
next.

[Bug objc/45842] New: New obj(c-c++) failures

[dominiq at lps dot ens.fr]

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

   Summary: New obj(c-c++) failures
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: nicola.p...@meta-innovation.com, ia...@gcc.gnu.org
  Host: x86_64-apple-darwin10.4
Target: x86_64-apple-darwin10.4
 Build: x86_64-apple-darwin10.4


All the failures in the following lists are new but for objc.dg/headers.m and
objc.dg/no-extra-load.m.

=== objc tests ===

Schedule of variations:
unix/-m32
unix/-m64

Running target unix/-m32
FAIL: objc.dg/const-str-12b.m -fnext-runtime (test for excess errors)
FAIL: objc.dg/encode-3.m -fnext-runtime (test for excess errors)
FAIL: objc.dg/encode-7-next-64bit.m -fnext-runtime (test for excess errors)
FAIL: objc.dg/encode-7-next-64bit.m -fnext-runtime execution test
FAIL: objc.dg/encode-7-next.m -fnext-runtime (test for excess errors)
FAIL: objc.dg/encode-7-next.m -fnext-runtime execution test
FAIL: objc.dg/headers.m -fnext-runtime (test for excess errors)
FAIL: objc.dg/no-extra-load.m -fnext-runtime (test for excess errors)
ERROR: objc.dg/no-extra-load.m: error executing dg-final: couldn't open
"no-extra-load.s": no such file or directory
FAIL: objc.dg/proto-qual-1.m -fnext-runtime execution test
FAIL: objc.dg/threedotthree-abi-1.m -fnext-runtime execution test
FAIL: objc.dg/type-size-2.m -fnext-runtime (test for excess errors)
XPASS: objc.dg-struct-layout-encoding-1/t026_main.m execution test

=== objc Summary for unix/-m32 ===

# of expected passes4170
# of unexpected failures11
# of unexpected successes1
# of expected failures6
# of unresolved testcases1
# of unsupported tests31

Running target unix/-m64
FAIL: objc.dg/const-str-12b.m -fnext-runtime (test for excess errors)
FAIL: objc.dg/encode-3.m -fnext-runtime (test for excess errors)
FAIL: objc.dg/encode-7-next-64bit.m -fnext-runtime (test for excess errors)
WARNING: objc.dg/encode-7-next-64bit.m -fnext-runtime compilation failed to
produce executable
FAIL: objc.dg/encode-7-next.m -fnext-runtime (test for excess errors)
WARNING: objc.dg/encode-7-next.m -fnext-runtime compilation failed to produce
executable
FAIL: objc.dg/headers.m -fnext-runtime (test for excess errors)
FAIL: objc.dg/method-20b.m -fnext-runtime (test for excess errors)
WARNING: objc.dg/method-20b.m -fnext-runtime compilation failed to produce
executable
FAIL: objc.dg/no-extra-load.m -fnext-runtime (test for excess errors)
ERROR: objc.dg/no-extra-load.m: error executing dg-final: couldn't open
"no-extra-load.s": no such file or directory
FAIL: objc.dg/threedotthree-abi-1.m -fnext-runtime execution test
FAIL: objc.dg/type-size-2.m -fnext-runtime (test for excess errors)
XPASS: objc.dg-struct-layout-encoding-1/t026_main.m execution test

=== objc Summary for unix/-m64 ===

# of expected passes2850
# of unexpected failures9
# of unexpected successes1
# of expected failures55
# of unresolved testcases1
# of unsupported tests36

=== objc Summary ===

# of expected passes7020
# of unexpected failures20
# of unexpected successes2
# of expected failures61
# of unresolved testcases2
# of unsupported tests67
/opt/gcc/build_w/gcc/xgcc  version 4.6.0 20100930 (experimental) [trunk
revision 164743p2] (GCC) 


=== obj-c++ tests ===

Schedule of variations:
unix/-m32
unix/-m64

Running target unix/-m32
WARNING: obj-c++.dg/lookup-2.mm -fgnu-runtime compilation failed to produce
executable
WARNING: obj-c++.dg/try-catch-2.mm -fgnu-runtime compilation failed to produce
executable
WARNING: obj-c++.dg/try-catch-9.mm -fgnu-runtime compilation failed to produce
executable
FAIL: obj-c++.dg/const-str-12.mm -fnext-runtime (test for excess errors)
FAIL: obj-c++.dg/encode-3.mm -fnext-runtime execution test

=== obj-c++ Summary for unix/-m32 ===

# of expected passes1280
# of unexpected failures2
# of expected failures3
# of unsupported tests18

Running target unix/-m64
WARNING: obj-c++.dg/lookup-2.mm -fgnu-runtime compilation failed to produce
executable
WARNING: obj-c++.dg/try-catch-2.mm -fgnu-runtime compilation failed to produce
executable
WARNING: obj-c++.dg/try-catch-9.mm -fgnu-runtime compilation failed to produce
executable
FAIL: obj-c++.dg/const-str-12.mm -fnext-runtime (test for excess errors)
FAIL: obj-c++.dg/encode-3.mm -fnext-runtime execution test
FAIL: obj-c++.dg/method-22.mm -fnext-runtime (test for excess errors)
WARNING: obj-c++.dg/method-22.mm -fnext-runtime compilation failed to produce
executable
FAIL: obj-c++.dg/method-23.mm -fnext-runtime (test for excess errors)
WARNING: obj-c++.dg/method-23.mm -fnext-runtime compilation failed to 

[Bug target/45790] [4.6 Regression] rs6000 builtin vs LTO

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  
2010-09-30 08:45:26 UTC ---
On Wed, 29 Sep 2010, pinskia at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45790
> 
> Andrew Pinski  changed:
> 
>What|Removed |Added
> 
>   Component|lto |target
>Host|powerpc-apple-darwin9   |
>   Build|powerpc-apple-darwin9   |
> 
> --- Comment #4 from Andrew Pinski  2010-09-29 
> 17:08:53 UTC ---
> >lto1: fatal error: target specific builtin not available
> 
> PowerPC has the hook implemented, why is it failing for powerpc-darwin then?

Because

  else if (fclass == BUILT_IN_MD)
{
  result = targetm.builtin_decl (fcode, true);
  if (!result || result == error_mark_node)
fatal_error ("target specific builtin not available");

appearantly the ppc backends lazy construction doesn't work?  Or
target specific flags are not properly set (or recorded and
re-instantiated at link time).

Sth to investigate.

[Bug objc/45842] New obj(c-c++) failures

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.09.30 08:48:20
   date||
 Ever Confirmed|0   |1

--- Comment #1 from Iain Sandoe  2010-09-30 08:48:20 
UTC ---
thanks for reporting, 
we're working through resolving the fallout of merging new functionality.

[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058

[abel at gcc dot gnu.org]

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

--- Comment #10 from Andrey Belevantsev  2010-09-30 
08:50:14 UTC ---
Are you sure you have applied the right patch?  With the patch from comment #7,
the test doesn't fail for me, and moreover there is no assert on line 7077. 
I'm attaching the patch to make sure that it's not garbled by inlining in the
message.

[Bug libstdc++/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|paolo.carlini at oracle dot |
   |com |

--- Comment #3 from Paolo Carlini  2010-09-30 
09:10:09 UTC ---
Please David and Hans-Peter, collaborate a bit on this, I can imagine David
needs details because the problem can't be reproduced on many widespread
targets, like Darwin or Linux. Indeed, the filebuf code has been changed, but
only in the generic parts, thus I would really try to sort out first possible
issues like code generation (what happens if the library is built -O0 instead
of -O2?), undefined behavior (eg, uninitialized data) in the testcase itself,
hidden dependency on target details in the testcase (eg, BUFSIZ), etc, because
it seems highly unlikely to me that the generic code per se is incorrect,
basing on this specific fail on this specific target only. By the way, is the
first time one of the filebuf testcases fails unexpectedly on cris-axis-elf? I
remember something puzzling in the past...

[Bug objc/36580] ICE at -O2 and above (with strict aliasing) with invalid Objective-C code.

[nicola at gcc dot gnu.org]

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

Nicola Pero  changed:

   What|Removed |Added

 CC||nicola at gcc dot gnu.org

--- Comment #1 from Nicola Pero  2010-09-30 09:15:26 
UTC ---
This works (does not generate an internal compiler error) with both GCC 4.1 and
GCC 4.6.  I tried compiling with 'gcc -O3 test.m -lobjc'.

Do you have any other details on how to reproduce it ?

Thanks

[Bug bootstrap/45612] [4.6 regression] Reference to undefined label building libada on Solaris 2/SPARC

[hainque at adacore dot com]

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

--- Comment #17 from hainque at adacore dot com  
2010-09-30 09:23:25 UTC ---
ro at gcc dot gnu.org wrote:
> Eric, Olivier,

> could you please have a look at Jan's question in Comment #6?  This
> bug currently breaks Ada bootstrap on Solaris 2/SPARC and hampers my
> Solaris testing.

 I'll see if I can get at something with a cross (faster to build), but
 please don't give up other tracks as I have very limited bandwidth for
 this right now.

 Olivier

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[burnus at gcc dot gnu.org]

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

--- Comment #12 from Tobias Burnus  2010-09-30 
09:24:49 UTC ---
(In reply to comment #11)
> So it works with 4.6.0 20100924, but it still doesn't work with 4.6.0 
> 20100921.
> Unfortunately, I cannot use the latest revision, until bug 45746 is fixed.

Actually, I am confused: From that comment it sounds as if 20100921 does not
have the bug 45746 - but it has been reported using 20100921 and a comment by
Dominique indicates that it never worked with GCC 4.5/4.6 but it only worked
for a while on the fortran-dev branch.


> Plus, I assume that the error message will show up in later revisions again.

Any reason why you think that this will be the case?


(In reply to comment #0)
> I use the actual GNU Fortran (GCC) 4.6.0 20100928. But it already happened,
> that the bug disappeared and appeared again.

Such bugs are usually an indication for not properly initialized memory.
Especially when it happens, it helps if one can try valgrind on the file:

  valgrind `gfortran -v 2>&1  | grep f951`

Memory related errors tend to show up only on few machines and in irregular
patterns, which makes finding them difficult.

[Bug objc/45842] New obj(c-c++) failures

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  2010-09-30 09:40:14 
UTC ---
Author: iains
Date: Thu Sep 30 09:40:11 2010
New Revision: 164747

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164747
Log:

PR objc/45842
* objc.dg/threedotthree-abi-1.m: Only apply at m32.
* objc.dg/const-str-3.m: Correct header for memcpy.
* objc.dg/const-str-7.m: Likewise.
* objc.dg/method-20b.m: Provide an implementation of Object.
Adjust XFAIL for m64 NeXT runtime.
* objc.dg/const-str-12b.m: Use mapped data types Darwin >= 9.
* objc.dg/encode-3.m: Correct line ordering, provide header for 
sprintf.
* objc.dg/encode-7-next.m: Only run for 32bit.
* objc.dg/encode-7-next-64bit.m: Only run for 64bit.
* objc.dg/type-size-2.m: Provide an implementation of Object.
Ajust headers.
* obj-c++.dg/const-str-7.mm: Correct header for memcpy.
* obj-c++.dg/const-str-12.mm: Use mapped data types Darwin >= 9.
* obj-c++.dg/method-23.mm: Provide an implementation of Object.
Adjust XFAIL for m64 NeXT runtime.
* obj-c++.dg/method-22.mm: Likewise.
* obj-c++.dg/threedotthree-abi-1.mm: Only apply at m32.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/objc.dg/const-str-12b.m
trunk/gcc/testsuite/objc.dg/const-str-3.m
trunk/gcc/testsuite/objc.dg/const-str-7.m
trunk/gcc/testsuite/objc.dg/encode-3.m
trunk/gcc/testsuite/objc.dg/encode-7-next-64bit.m
trunk/gcc/testsuite/objc.dg/encode-7-next.m
trunk/gcc/testsuite/objc.dg/method-20b.m
trunk/gcc/testsuite/objc.dg/threedotthree-abi-1.m
trunk/gcc/testsuite/objc.dg/type-size-2.m

[Bug libstdc++/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[potswa at mac dot com]

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

--- Comment #4 from David Krauss  2010-09-30 09:52:48 
UTC ---
Ah, I didn't even notice the target line before.

This is unbuffered I/O, which can be challenging to the codecvt. But this isn't
a failure I would anticipate. If the codecvt fails, there should be an
exception; if it succeeds, the result is cached so the second sgetc() returns
the same result. (Thus, it's not *really* unbuffered.)

I don't see how the patch could change this particular behavior. Definitely
need that trace. And I presume I'll need to upgrade gdb to use it. Which
entails building GDB for that architecture from source, on my machine?

Or do you guys happen to have a setup I can ssh into? :v)

[Bug rtl-optimization/45813] [4.4/4.5 Regression] alias analysis problem with -mthumb

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||alias, wrong-code
 Target|ARM/Thumb   |arm-elf, arm-linux-gnueabi
 Status|UNCONFIRMED |NEW
   Last reconfirmed|2010-09-28 09:17:33 |2010.09.30 09:56:46
   date||
   Target Milestone|--- |4.4.5
Summary|alias analysis problem ?|[4.4/4.5 Regression] alias
   ||analysis problem with
   ||-mthumb
 Ever Confirmed|0   |1

--- Comment #11 from Richard Guenther  2010-09-30 
09:56:46 UTC ---
Thus, confirmed.

[Bug objc/45842] New obj(c-c++) failures

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther  2010-09-30 
10:00:35 UTC ---
Fixed I guess.

[Bug libstdc++/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #5 from Paolo Carlini  2010-09-30 
10:08:57 UTC ---
Challenging to the codecvt?!? Isn't this a *char* testcase?

[Bug fortran/45748] [4.5/4.6 Regression] -fimplicit-none failures when using intrinsic MAX

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4
  Known to fail||

[Bug middle-end/45758] [4.6 Regression] ICE in expr_invariant_in_loop_p

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/45764] [4.6 Regression] wrong code -O2 vs -O3 (problem in vectorizer???)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug objc/45842] New obj(c-c++) failures

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  2010-09-30 10:14:23 
UTC ---
Sendinggcc/testsuite/obj-c++.dg/const-str-12.mm
Sendinggcc/testsuite/obj-c++.dg/const-str-7.mm
Sendinggcc/testsuite/obj-c++.dg/method-22.mm
Sendinggcc/testsuite/obj-c++.dg/method-23.mm
Sendinggcc/testsuite/obj-c++.dg/threedotthree-abi-1.mm
Transmitting file data .
Committed revision 164748.



well,  these remain to be fixed (and are being worked on):

ObjC/M32
FAIL: objc.dg/encode-7-next.m -fnext-runtime (test for excess errors)
FAIL: objc.dg/encode-7-next.m -fnext-runtime execution test
FAIL: objc.dg/no-extra-load.m -fnext-runtime (test for excess errors)

FAIL: objc.dg/proto-qual-1.m -fnext-runtime execution test
FAIL: objc.dg/threedotthree-abi-1.m -fnext-runtime execution test

ObjC/M64
FAIL: objc.dg/encode-7-next-64bit.m -fnext-runtime (test for excess errors)

ObjC++/m32/m64:

FAIL: obj-c++.dg/encode-3.mm -fnext-runtime execution test

[Bug libstdc++/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[potswa at mac dot com]

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

--- Comment #6 from David Krauss  2010-09-30 10:15:56 
UTC ---
(In reply to comment #5)
> Challenging to the codecvt?!? Isn't this a *char* testcase?

Oh, my bad. I thought constraint_filebuf included that automatically. Guess
not. I've got codecvts on the brain right now.

So yeah, there's really nothing remarkable at all about this testcase. Quite a
random failure.

Are you still CC'd here Paolo?

[Bug tree-optimization/45781] [4.6 Regression] GCC incorrectly puts function in .text.unlikely

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||build
  Known to work||4.5.1

--- Comment #1 from Richard Guenther  2010-09-30 
10:19:00 UTC ---
The decision is reasonable (I suppose partial inlining will inline the
if (!init) case) as the function is called exactly once then and thus
should be optimized for size and put into a separate section.

The question is thus, why does that break IA64 bootstrap?

If IA64 doesn't support .text.unlikely it should define
UNLIKELY_EXECUTED_TEXT_SECTION_NAME appropriately.

[Bug rtl-optimization/45788] [4.6 Regression] -fwhole-program causes ICE error: BB 3 can not throw but has an EH edge

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin10.4.0

--- Comment #7 from Richard Guenther  2010-09-30 
10:22:14 UTC ---
Works for me on x86_64-linux.

[Bug fortran/45794] [4.6 Regression] ICE: Segmentation fault in gfc_conv_procedure_call

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug bootstrap/45796] [4.6 regression] make targets info-gcc, dvi-gcc etc. should work from unbuilt configured tree

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2010-09-30 
10:24:25 UTC ---
Did it really work in 4.5?  Thus, why's this a regression?

[Bug libstdc++/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  2010-09-30 
10:24:49 UTC ---
After this message I will not be in CC anymore. I'm sorry, I'm getting too many
distracting messages and cannot help much here anyway, at least not at this
time.

[Bug bootstrap/45801] [4.6 regression] powerpc64-linux bootstrap comparison failure

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||build
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2010.09.30 10:25:29
   date||
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2010-09-30 
10:25:29 UTC ---
Please try with current trunk.

[Bug tree-optimization/45830] [4.4/4.5/4.6 Regression] Code+rodata increase with -ftree-switch-conversion

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug driver/45703] [4.6 regression] --help -v no longer shows linker help

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |4.6.0

[Bug bootstrap/45700] [4.5/4.6 Regression] --enable-checking=fold bootstrap failures

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||build, ice-checking
   Priority|P3  |P2
   Target Milestone|--- |4.5.2

[Bug tree-optimization/45656] [4.6 Regression]: gfortran.dg/forall_4.f90 -O3, wrong code with -g

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |4.6.0

--- Comment #11 from Richard Guenther  2010-09-30 
10:34:55 UTC ---
looks like non-target specific.

[Bug target/42159] unwinding issues on darwin

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

Summary|[4.4/4.5/4.6] app SIGABRTs  |unwinding issues on darwin
   |after a trivial nested  |
   |throw/stack unwinding   |
  Known to fail||

--- Comment #23 from Richard Guenther  2010-09-30 
10:37:10 UTC ---
I suppose this is all "user" errors which might be avoided by some more
target-os specific specs magic.

[Bug target/45843] New: [4.3/4.4/4.5/4.6 Regression] __builtin_va_arg overwrites into adjacent stack location

[jakub at gcc dot gnu.org]

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

   Summary: [4.3/4.4/4.5/4.6 Regression] __builtin_va_arg
overwrites into adjacent stack location
   Product: gcc
   Version: 4.3.6
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: gcc-bugs@gcc.gnu.org, hubi...@gcc.gnu.org,
hjl.to...@gmail.com, m...@gcc.gnu.org,
era...@google.com
Depends on: 44575
  Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
 Build: x86_64-unknown-linux-gnu


+++ This bug was initially created as a clone of Bug #44575 +++

This is a variation of the same problem where __builtin_va_arg overwrites into
adjacent stack location [Not sure if I should reopen this bug or file a new
one]:

$ cat vararg.cc

#include 
#include 
struct S933 { struct{struct{}b[6];union{}c[7];}a;char d;char e; };

struct S933 arg;
void check933va (int z, ...) {
  char c;
  va_list ap;
  __builtin_va_start(ap,z);
  c = 'a';
  arg = __builtin_va_arg(ap,struct S933);
  if (c != 'a')
abort();

}
int main() {
  struct S933 s933;
  check933va (1, s933);
}

$ ./trunk-g++  -O0  vararg.cc && ./a.out
Aborted

./trunk-g++ is GNU C++  version 4.6.0 20100924 (experimental)
(x86_64-unknown-linux-gnu)

The relevant portion of the gimple is below:
  D.2773_4 = ap.reg_save_area;
  D.2774_5 = ap.gp_offset;
  D.2775_6 = (long unsigned int) D.2774_5;
  int_addr.1_7 = D.2773_4 + D.2775_6;
  addr.0_8 = &va_arg_tmp.3;
  D.2777_9 = addr.0_8 + 8;
  D.2778_10 = MEM[(long unsigned int *)int_addr.1_7];
  *D.2777_9 = D.2778_10;<--- Bad move

The move to address D.2777_9 is the problem

For this struct type, construct_container returns the following:

(parallel:BLK [
(expr_list:REG_DEP_TRUE (reg:DI 0 ax)
(const_int 8 [0x8]))
])

The destination of the move is at offset 8 (INTVAL (XEXP (slot, 1))) of the
temporary created. The size of the temp (sizeof(S933)) is 15 bytes and the move
is in DI mode. I think the problem is the check  if (prev_size + cur_size >
size) doesn't really check if the destination is overwritten.

[Bug target/45843] [4.3/4.4/4.5/4.6 Regression] __builtin_va_arg overwrites into adjacent stack location

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.09.30 10:45:21
   date||
 Ever Confirmed|0   |1

[Bug target/45843] [4.3/4.4/4.5/4.6 Regression] __builtin_va_arg overwrites into adjacent stack location

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Target|x86_64-unknown-linux-gnu|x86_64-linux
  Known to work||3.4.6
   Host|x86_64-unknown-linux-gnu|
   Target Milestone|--- |4.3.6
  Known to fail||4.3.5, 4.4.4, 4.5.1, 4.6.0
  Build|x86_64-unknown-linux-gnu|

[Bug target/45843] [4.3/4.4/4.5/4.6 Regression] __builtin_va_arg overwrites into adjacent stack location

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/45819] [4.5 Regression] unexpected unaligned access to volatile int

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.5.2

[Bug c/32511] [4.4/4.5/4.6 regression] GCC rejects inline+weak function

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2
 AssignedTo|rguenth at gcc dot gnu.org  |unassigned at gcc dot
   ||gnu.org

--- Comment #10 from Richard Guenther  2010-09-30 
11:00:53 UTC ---
This bug has turned into a different one.  Not working on it.

In future please open new bugs instead of re-opening them and changing
them into sth completely different.

[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to fail||

[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058

[zsojka at seznam dot cz]

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

--- Comment #12 from Zdenek Sojka  2010-09-30 11:03:51 
UTC ---
Yes, sorry, I applied correct patch, but pasted assert from unpatched r164716:

The correct assert is:

$ FLAGS="-O1 -freorder-blocks -fschedule-insns2 -funswitch-loops
-fselective-scheduling2 -fsel-sched-pipelining -funroll-all-loops"
$ x86_64-pc-linux-gnu-gcc $FLAGS pr45352-8.c 
pr45352-8.c: In function 'foo':
pr45352-8.c:15:1: internal compiler error: in
reset_sched_cycles_in_current_ebb, at sel-sched.c:7095
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I am now bootstrapping with the patch from comment #11, I will let you know if
there is any difference.

Thanks

[Bug target/39725] [4.5/4.6 Regression][cond-optab] MIPS pessimizations on floating-point

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #5 from Richard Guenther  2010-09-30 
11:05:35 UTC ---
Nobody cares.  Dropping to P4 based on mips-linux status.

[Bug target/40959] [4.3/4.4/4.5/4.6 regression] FreeBSD/ia64 build fails: No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4
  Known to work||
  Known to fail||

--- Comment #22 from Richard Guenther  2010-09-30 
11:07:04 UTC ---
ia64-freebsd is neither primary nor secondary.

[Bug libstdc++/40974] [4.3/4.4/4.5/4.6 Regression] cannot build gcc-4.4.1: fenv_t has not been declared

[rguenth at gcc dot gnu.org]

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

--- Comment #50 from Richard Guenther  2010-09-30 
11:09:47 UTC ---
So, is this fixed anywhere?

[Bug debug/45447] ICE with `-g -femit-struct-debug-baseonly'

[qiyao at gcc dot gnu.org]

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

Yao Qi  changed:

   What|Removed |Added

 CC||qiyao at gcc dot gnu.org
  Known to fail||

--- Comment #2 from Yao Qi  2010-09-30 11:12:42 UTC 
---
Here is the patch http://gcc.gnu.org/ml/gcc-patches/2010-09/msg02349.html

[Bug target/41156] [4.4/4.5/4.6 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #38 from Richard Guenther  2010-09-30 
11:13:44 UTC ---
The conclusion seems to be WONTFIX (or NOT-A-BUG).  Getting it off the
serious regressions radar.

[Bug fortran/42954] [4.5/4.6 regression] TARGET_*_CPP_BUILDINS issues with gfortran

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug tree-optimization/43959] [4.6 Regression] FAIL: gcc.dg/torture/builtin-cproj-1.c -O1 (test for excess errors)

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Guenther  2010-09-30 
11:19:52 UTC ---
(In reply to comment #18)
> Subject: Re:  [4.6 Regression] FAIL: gcc.dg/torture/builtin-cproj-1.c  -O1 
> (test for excess errors)
> 
> > Ah.  The following fixes it for me on a cross.  Can you bootstrap & regtest 
> > and
> > install it?  It's pre-approved if it works for you.
> 
> Will test and install if successful.

Ping?

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[MichieldeB at aim dot com]

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

--- Comment #10 from Michiel  2010-09-30 11:23:58 
UTC ---
To get to know what a formula does, I usually compute some examples. When doing
so, I was warned, but ignored them and that was stupid.

There are however also warnings that are stupid. I now think of setting an
integer to -2147483648. 2147483648 is too large for an integer and it is good
that the compiler warns you. Unfortunately, the compiler ignores the context of
2147483648 and thus warns for -2147483648 as well. A similar argument applies
for setting an unsigned to a value in the range 2147483648 to 4294967295. 

On the other hand, setting an unsigned to a negative value does not give any
warning. Setting an unsigned to e.g. -1 is totally unnecessary, since you can
write ~0 instead, which is also preferable.

[Bug target/45325] [4.6 Regression] target attribute doesn't work with -march=i586

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||accepts-invalid,
   ||ice-on-invalid-code
 Target||i?86-*-*
   Priority|P3  |P2
 CC||meissner at gcc dot gnu.org
  Component|middle-end  |target
  Known to work||

--- Comment #10 from Richard Guenther  2010-09-30 
11:32:34 UTC ---
Target bug.  ix86_valid_target_attribute_p should reject "sse" if that
changes the mode of any type.  Thus, declaring the testcase as-is invalid.

The same issue is at least latent with 4.5, making this P2.

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[sch...@linux-m68k.org]

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

--- Comment #11 from Andreas Schwab  2010-09-30 11:33:54 
UTC ---
-1 works for any integer type, ~0 only works for unsigned (int|short|char).

[Bug bootstrap/45381] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: error: AltiVec argument passed to unprototyped function

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug rtl-optimization/45394] [4.6 regression] gnat fails to build on s390, trunk 20100918

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||aoliva at gcc dot gnu.org

[Bug middle-end/45505] [4.6 Regression] gfortran.dg/pr25923.f90

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1
  Component|fortran |middle-end

[Bug ada/45568] [4.6 Regression] stack overflow (or erroneous memory access) building gnattools

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug rtl-optimization/45570] [4.6 Regression] ICE: in cfg_preds_1, at sel-sched-ir.c:4584

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug libstdc++/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[hp at gcc dot gnu.org]

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

--- Comment #8 from Hans-Peter Nilsson  2010-09-30 
11:46:47 UTC ---
(In reply to comment #4)
> Or do you guys happen to have a setup I can ssh into? :v)

Nominally, you *could* repeat my findings with a cross-compiler setup as
described by  but using that to
investigate an execution failure might be a bit too challenging for a newcomer.

In my autotester using that kind of setup, this failure is a regression. There
are certainly other failures (for different reasons; bugs/shortcomings in
newlib, bugs in the test-cases etc.), but this one is a *regression*.  I guess
from the earlier comments, your patch is rather exposing another issue, not the
direct cause.  The trace I mentioned (I'll try to get to it this week) will
show me at least the sequence of basic libc or system operations were used
(seek, read, etc.) and I hope then you, by knowing the code around the patch,
can help me by telling whether a specific call is sane or bogus, so we can
pinpoint the failing code.  No, the trace can't be used with gdb, but only
because that's a feature that's not yet been implemented. ;-)

[Bug target/45585] [4.6 Regression] ICE on powerpc-apple-darwin9 for gfortran.dg/transfer_simplify_2.f90 with -O2 -m64

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target|powerpc-apple-darwin9   |powerpc64-*-*,
   ||powerpc-apple-darwin9
   Priority|P3  |P1
 CC||meissner at gcc dot gnu.org

[Bug lto/45586] [4.6 Regression] ICE non-trivial conversion at assignment

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||ice-checking
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |

--- Comment #7 from Richard Guenther  2010-09-30 
11:49:44 UTC ---
Mine.

[Bug bootstrap/45658] [4.6 regression] Comparison failure in gcc/ada/ali.o on Solaris 2/SPARC

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #7 from Richard Guenther  2010-09-30 
11:52:13 UTC ---
Please try to re-confirm or close as fixed.

[Bug tree-optimization/45844] New: FAIL: gfortran.dg/vect/pr45714-b.f -O (internal compiler error)

[dominiq at lps dot ens.fr]

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

   Summary: FAIL: gfortran.dg/vect/pr45714-b.f  -O  (internal
compiler error)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: i...@il.ibm.com
  Host: powerpc-apple-darwin9
Target: powerpc-apple-darwin9
 Build: powerpc-apple-darwin9


When compiled with -O3 -m64 -mcpu=power7 -ffast-math -mveclibabi=mass the test
gfortran.dg/vect/pr45714-b.f gives the following ICE:

[karma] f90/bug% gfc -c -O3 -m64 -mcpu=power7 -ffast-math -mveclibabi=mass
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/vect/pr45714-b.f
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/vect/pr45714-b.f: In function
'MAIN__':
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/vect/pr45714-b.f:25:0: error:
insn does not satisfy its constraints:
(insn 39 141 33 2 (set (reg:V2DF 108 v31 [orig:162 vect_cst_.14 ] [162])
(vec_duplicate:V2DF (mem/u/c/i:DF (lo_sum:DI (reg:DI 2 r2)
(const:DI (unspec:DI [
(symbol_ref/u:DI ("*LC1") [flags 0x2])
] 50))) [2 S8 A64])))
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/vect/pr45714-b.f:14 873
{vsx_splat_v2df}
 (nil))
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/vect/pr45714-b.f:25:0: internal
compiler error: in reload_cse_simplify_operands, at postreload.c:402

The test has been introduced at revision 164420.

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  2010-09-30 
11:56:41 UTC ---
And the warnings you mention are of course reasonable, -2147483648 in C/C++
is the integer constant 2147483648 (which doesn't fit into int), which is
afterwards negated, you should write -2147483647-1, and you should be using
4294967295U if you want an unsigned int constant.

[Bug lto/45667] [4.6 Regression] ICE: verify_stmts failed: type mismatch in address expression with -flto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||ice-checking
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Richard Guenther  2010-09-30 
11:58:51 UTC ---
Mine.

[Bug target/45693] [4.6 regression] All Tru64 UNIX EH tests fail

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug target/45701] [4.6 Regression] Fail to prefer using r3 for padding a push/pop multiple to 8-byte alignment

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c/45831] 0 = 10 (with -O0, 0 = 0 with -O1, but 10 = 10 expected)

[manu at gcc dot gnu.org]

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

--- Comment #13 from Manuel López-Ibáñez  2010-09-30 
12:12:17 UTC ---
(In reply to comment #10)
> To get to know what a formula does, I usually compute some examples. When 
> doing
> so, I was warned, but ignored them and that was stupid.
> 
> There are however also warnings that are stupid. I now think of setting an
> integer to -2147483648. 2147483648 is too large for an integer and it is good
> that the compiler warns you. Unfortunately, the compiler ignores the context 
> of
> 2147483648 and thus warns for -2147483648 as well. A similar argument applies
> for setting an unsigned to a value in the range 2147483648 to 4294967295. 
> 
> On the other hand, setting an unsigned to a negative value does not give any
> warning. Setting an unsigned to e.g. -1 is totally unnecessary, since you can
> write ~0 instead, which is also preferable.

See: http://gcc.gnu.org/wiki/NewWconversion#Frequently_Asked_Questions

Please search also the C FAQs, your answers are there. We cannot change how C
works, even if it seems counter-intuitive at first glance.

If you find another specific problem, please open a new PR with a complete
testcase and expected/obtained output.

[Bug lto/45721] [4.6 Regression] ICE: in function_and_variable_visibility, at ipa.c:673 with -flto

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/45732] [4.6 Regression] ICE: in bit_value_unop, at tree-ssa-ccp.c:1861 at -O1

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/45743] [4.6 Regression] gfortran.dg/whole_file_3.f90 ICE: verify_stmts failed: invalid conversion in gimple call with -finline-small-functions

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||ice-checking
   Priority|P3  |P1

[Bug libstdc++/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug lto/45702] [4.6 Regression] New LTO test failures

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Guenther  2010-09-30 
12:22:41 UTC ---
Author: rguenth
Date: Thu Sep 30 12:22:33 2010
New Revision: 164749

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164749
Log:
2010-09-30  Richard Guenther  

PR testsuite/45702
* gcc.dg/debug/pr41893-1.c: Adjust.
* gcc.dg/pr30762-1.c: Likewise.
* gcc.dg/pr31529-1.c: Likewise.
* gcc.dg/pr34457-1.c: Likewise.
* gcc.dg/pr34668-1.c: Likewise.
* gcc.dg/pr43557-1.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/debug/pr41893-1.c
trunk/gcc/testsuite/gcc.dg/pr30762-1.c
trunk/gcc/testsuite/gcc.dg/pr31529-1.c
trunk/gcc/testsuite/gcc.dg/pr34457-1.c
trunk/gcc/testsuite/gcc.dg/pr34668-1.c
trunk/gcc/testsuite/gcc.dg/pr43557-1.c

[Bug rtl-optimization/45394] [4.6 regression] gnat fails to build on s390, trunk 20100918

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  2010-09-30 
13:00:38 UTC ---
For the records, I have a reduced testcase and a patch.  ETA is next week.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[boschmann at tp1 dot physik.uni-siegen.de]

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

--- Comment #13 from Hans-Werner Boschmann  2010-09-30 13:03:09 UTC ---
(In reply to comment #12)
> Actually, I am confused: From that comment it sounds as if 20100921 does not
> have the bug 45746 - but it has been reported using 20100921 and a comment by
> Dominique indicates that it never worked with GCC 4.5/4.6 but it only worked
> for a while on the fortran-dev branch.

You are right about this, I'm switching back and forth in the version of gcc
and got lost.


But I have run valgrind now. It was the first time, so I don't understand the
result. Is it somehow the fault of my hardware/OS? Here is the output:


valgrind --leak-check=full /opt/gcc-trunk/bin/gfortran -ffree-form
-ffree-line-length-0 -I. -L.  -c common.f03 -o common.o
==31832== Memcheck, a memory error detector 
==31832== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.   
==31832== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info 
==31832== Command: /opt/gcc-trunk/bin/gfortran -ffree-form -ffree-line-length-0
-I. -L. -c common.f03 -o common.o  
==31832==   
common.f03:27.22:   

  use arguments_module
  1
Interner Fehler bei (1):
mio_component_ref(): Component not found
==31832==   
==31832== HEAP SUMMARY: 
==31832== in use at exit: 32,209 bytes in 82 blocks
==31832==   total heap usage: 268 allocs, 186 frees, 49,388 bytes allocated
==31832==  
==31832== 1 bytes in 1 blocks are definitely lost in loss record 2 of 70   
==31832==at 0x4C234E7: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==by 0x41FC38: xcalloc (xmalloc.c:162)   
==31832==by 0x40DE7F: main (gcc.c:6993) 
==31832==   
==31832== 4 bytes in 1 blocks are possibly lost in loss record 4 of 70  
==31832==at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==by 0x41FBF7: xmalloc (xmalloc.c:147)   
==31832==by 0x41DA2D: concat (concat.c:159) 
==31832==by 0x407090: driver_handle_option (gcc.c:3729) 
==31832==by 0x410A37: handle_option (opts-common.c:673) 
==31832==by 0x410B7C: read_cmdline_option (opts-common.c:812)   
==31832==by 0x40580E: process_command (gcc.c:4177)  
==31832==by 0x40C63C: main (gcc.c:6593) 
==31832==   
==31832== 15 bytes in 1 blocks are definitely lost in loss record 10 of 70  
==31832==at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==by 0x41FBF7: xmalloc (xmalloc.c:147)   
==31832==by 0x4025D5: save_string (gcc.c:7322)  
==31832==by 0x40B3AB: handle_braces (gcc.c:6093)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x40B455: handle_braces (gcc.c:6096)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x40B455: handle_braces (gcc.c:6096)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x40A25A: do_spec_2 (gcc.c:4554)
==31832==by 0x40A282: do_self_spec (gcc.c:4619) 
==31832==by 0x40ABCE: do_option_spec (gcc.c:4608)   
==31832==   
==31832== 18 bytes in 1 blocks are definitely lost in loss record 16 of 70  
==31832==at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==by 0x41FBF7: xmalloc (xmalloc.c:147)   
==31832==by 0x4025D5: save_string (gcc.c:7322)  
==31832==by 0x40B3AB: handle_braces (gcc.c:6093)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x40B455: handle_braces (gcc.c:6096)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x40B455: handle_braces (gcc.c:6096)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x4097A4: do_spec_1 

[Bug tree-optimization/43959] [4.6 Regression] FAIL: gcc.dg/torture/builtin-cproj-1.c -O1 (test for excess errors)

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #20 from dave at hiauly1 dot hia.nrc.ca 2010-09-30 13:13:05 UTC ---
> > > Ah.  The following fixes it for me on a cross.  Can you bootstrap & 
> > > regtest and
> > > install it?  It's pre-approved if it works for you.
> > 
> > Will test and install if successful.
> 
> Ping?

It works.  Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
I was going to install it  when I get a chance, but I got side tracked
on other problems.

Dave

[Bug c++/45845] New: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE regressed on darwin

[howarth at nitro dot med.uc.edu]

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

   Summary: g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE
regressed on darwin
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


Between r164716 and r164731, a regression in the g++ test suite appeared on
both powerpc-apple-darwin9 and x86_64-apple-darwin10.

FAIL: g++.dg/pubtypes.C scan-assembler "A0"+[ \\t]+[#;@]+[
\\t]+external name

[Bug c++/45845] g++.dg/ext/visibility/anon6.C scan-assembler 1BIiE1cE regressed on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #3 from Jack Howarth  2010-09-30 
13:47:26 UTC ---
Caused by...

Author: rguenth
Date: Wed Sep 29 13:59:08 2010
New Revision: 164719

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164719
Log:
2010-09-29  Richard Guenther  

* tree.h (SCOPE_FILE_SCOPE_P): New macro.
(DECL_FILE_SCOPE_P): Use it.
(TYPE_FILE_SCOPE_P): New macro.

cp/
* cp-tree.h (CP_DECL_CONTEXT): Check DECL_FILE_SCOPE_P.
(CP_TYPE_CONTEXT): Similar.
(FROB_CONTEXT): Frob global_namespace to the global
TRANSLATION_UNIT_DECL.
* decl.c (cxx_init_decl_processing): Build a TRANSLATION_UNIT_DECL,
set DECL_CONTEXT of global_namespace to it.
(start_decl): Use CP_DECL_CONTEXT and test TYPE_P
instead of zeroing context.
(cp_finish_decl): Use DECL_FILE_SCOPE_P.
(grokfndecl): Likewise.
(start_preparsed_function): Likewise.
* name-lookup.c (maybe_push_decl): Use DECL_NAMESPACE_SCOPE_P.
(namespace_binding): Use SCOPE_FILE_SCOPE_P.
* pt.c (template_class_depth): Use CP_TYPE_CONTEXT.
(is_specialization_of_friend): Use CP_DECL_CONTEXT.
(push_template_decl_real): Likewise.
(tsubst_friend_class): Likewise.  Adjust context comparisons.
(instantiate_class_template): Use CP_TYPE_CONTEXT.
(tsubst): Do not substitute into TRANSLATION_UNIT_DECL.
* cxx-pretty-print.c (pp_cxx_nested_name_specifier): Use
SCOPE_FILE_SCOPE_P.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

[burnus at gcc dot gnu.org]

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

--- Comment #14 from Tobias Burnus  2010-09-30 
13:48:15 UTC ---
(In reply to comment #13)
> But I have run valgrind now. It was the first time, so I don't understand the
> result. Is it somehow the fault of my hardware/OS? Here is the output:

> valgrind --leak-check=full /opt/gcc-trunk/bin/gfortran -ffree-form
> -ffree-line-length-0 -I. -L.  -c common.f03 -o common.o

You did not do what I wrote. I wrote:

  valgrind `gfortran -v 2>&1  | grep f951`

you did

  valgrind gfortran ...

Thus you are testing a completely different program! "gcc", "gfortran" etc. are
only "drivers" which call the actual compiler, which is named "cc1", "f951",
... (That is also the reason why C programs can be compiled with "gfortran
foo.c" as this then calls "cc1" rather than "f951".)

To find out the command line arguments to the real compiler 'f951', one can
compile using the option "-v" which shows the parts which are called. The line
of interest is the one which is calling "f951".


> ==31832== 1 bytes in 1 blocks are definitely lost in loss record 2 of 70   
> ==31832== 4 bytes in 1 blocks are possibly lost in loss record 4 of 
etc.

That only tells that some memory has not been freed and is possibly/definitely
lost. That should not happen, but usually just means that gfortran uses more
memory as it should (and which is then only freed by the operating system if
one returns). -- In some cases  (cf. e.g. Bug 45793) those indicate a true
error which have to be fixed. (But one usually should also try to fix normal
memory issues.)

I was more looking for warnings such as:
  ==27731== Invalid read of size 8
which indicate that there is an error (e.g. uninitialized variable or pointer).

[Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int

[anemo at mba dot ocn.ne.jp]

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

--- Comment #8 from Atsushi Nemoto  2010-09-30 
13:59:34 UTC ---
(In reply to comment #0)
> The PR 42956 bugzilla shows same fix was applied to both 4.5.0 and 4.4.4,
> but they behave differently on this test case.
> 
> Comparing patches for 4.4 branch and 4.5, I see the latter contains two more
> changes for gimplify.c:
> A STRIP_NOP line and lines starting with "/* *(foo *)&complexfoo => __real__
> complexfoo */" comment.

In the first place, why PR 42956 fixes are different for 4.4 and 4.5?
The commit logs are same, but actual changes for gimplify.c were differ.

Is that "two more changes" are not bugfix but improvement?

[Bug tree-optimization/45704] [4.5 Regression] load byte instruction is used for volatile int

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  
2010-09-30 14:14:13 UTC ---
On Thu, 30 Sep 2010, anemo at mba dot ocn.ne.jp wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45704
> 
> --- Comment #8 from Atsushi Nemoto  2010-09-30 
> 13:59:34 UTC ---
> (In reply to comment #0)
> > The PR 42956 bugzilla shows same fix was applied to both 4.5.0 and 4.4.4,
> > but they behave differently on this test case.
> > 
> > Comparing patches for 4.4 branch and 4.5, I see the latter contains two more
> > changes for gimplify.c:
> > A STRIP_NOP line and lines starting with "/* *(foo *)&complexfoo => __real__
> > complexfoo */" comment.
> 
> In the first place, why PR 42956 fixes are different for 4.4 and 4.5?
> The commit logs are same, but actual changes for gimplify.c were differ.
> 
> Is that "two more changes" are not bugfix but improvement?

Yes.

[Bug fortran/45828] [4.6 Regression] No default initialization of derived type members?

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |janus at gcc dot gnu.org
   |gnu.org |

--- Comment #5 from janus at gcc dot gnu.org 2010-09-30 14:48:17 UTC ---
(In reply to comment #3)
> the problem seems to be in expr.c (called from resolve.c:
> resolve_allocate_expr())
> 
> [...]
> 
> if a derived type has a derived type component it only checks whether
> that components components have default initializers, not the component
> itself.

Right. To fix it I propose the following patch (not regtested yet):

Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 164461)
+++ gcc/fortran/expr.c(working copy)
@@ -3662,21 +3662,18 @@ gfc_has_default_initializer (gfc_symbol *der)

   gcc_assert (der->attr.flavor == FL_DERIVED);
   for (c = der->components; c; c = c->next)
-if (c->ts.type == BT_DERIVED)
-  {
-if (!c->attr.pointer
- && gfc_has_default_initializer (c->ts.u.derived))
-  return true;
-  }
-else
-  {
-if (c->initializer)
-  return true;
-  }
+{
+  if (c->ts.type == BT_DERIVED && !c->attr.pointer
+  && gfc_has_default_initializer (c->ts.u.derived))
+return true;
+  if (c->initializer)
+return true;
+}

   return false;
 }

+
 /* Get an expression for a default initializer.  */

 gfc_expr *

[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[sebastian.hu...@embedded-brains.de]

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

--- Comment #32 from Sebastian Huber  
2010-09-30 15:36:02 UTC ---
Which target milestone do you intend for a fix?  It is still present in 4.6.0
20100925.

[Bug fortran/39427] F2003: Procedures with same name as types/type constructors

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #20 from Tobias Burnus  2010-09-30 
15:49:37 UTC ---
(In reply to comment #19)
> Could someone please comment on the relevance (or lack thereof) of the
> component being public in the example I submitted?

This issue was solved off list/PR. The question was how to interpret the
following, where [F2008's] R455 defines a "structure-constructor":

"C496 (R455) If derived-type-spec is a type name that is the same as a generic
name, the component-spec-list shall not be a valid actual-arg-spec-list for a
function reference that is resolvable as a generic reference to that name
(12.5.5.2)."

My interpretation is that this only disallows structure constructors, i.e.,
that generic functions have a higher precedence than structure constructors.
Thus, one can always override a constructor by a generic function. (And I do
not see how private components could alter the interpretation of C496 - even if
one reads it differently.)

F2008 also has the following note, which supports the overriding
interpretation:

"NOTE 4.58   The form 'name(...)' is interpreted as a generic
function-reference if possible; it is interpreted as a structure-constructor
only if it cannot be interpreted as a generic function-reference."

[Bug c/32511] [4.4/4.5/4.6 regression] GCC rejects inline+weak function

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill  2010-09-30 
16:01:01 UTC ---
I don't see it as different at all; I am arguing that the initial bug report
was not actually a bug, and that the patch should be reverted.

[Bug bootstrap/42628] ICE during bootstrap when compiling several libsupc++ files: original tree changed by fold

[aanisimov at inbox dot ru]

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

Artem Anisimov  changed:

   What|Removed |Added

 CC||aanisimov at inbox dot ru

--- Comment #10 from Artem Anisimov  2010-09-30 
16:35:06 UTC ---
  4.6 trunk fails too. Building rev. 164569 fails with the following error:

../../../../gcc-current/libstdc++-v3/libsupc++/dyncast.cc: In function 'void*
__cxxabiv1::__dynamic_cast(const void*, const __cxxabiv1::__class_type_info*,
const __cxxabiv1::__class_type_info*, ptrdiff_t)':
../../../../gcc-current/libstdc++-v3/libsupc++/dyncast.cc:86:1: internal
compiler error: fold check: original tree changed by fold
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

  GCC was configured with these options:

../gcc-current/configure --prefix=/home/artem/testing/gcc46 --enable-shared
--enable-bootstrap --enable-languages=c,c++ --enable-threads=posix
--enable-checking=release --with-system-zlib --disable-libunwind-exceptions
--enable-__cxa_atexit --enable-libssp --with-gnu-ld --with-lto --disable-nls
--verbose --with-arch=athlon64 --target=x86_64-slackware-linux
--build=x86_64-slackware-linux --host=x86_64-slackware-linux --disable-multilib
--enable-checking=all

[Bug bootstrap/42628] ICE during bootstrap when compiling several libsupc++ files: original tree changed by fold

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  2010-09-30 
16:42:41 UTC ---
That's PR45700.

[Bug tree-optimization/45781] [4.6 Regression] GCC incorrectly puts function in .text.unlikely

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  2010-09-30 
16:44:17 UTC ---
IA-64 seems to be fine with unlikely section at least at our periodic tester
setup, otherwise SPEC2000 FDO testing would break. So it might be specific for
ia64 HP-UX and in that case indeed correct fix is to simply define cold and hot
sections to be .text sections (or fix it at binutils side) for HP-UX IA-64 (and
possibly PA target too).

What I am confused about is how partial inlining affect placement of
init_target_chars. If it was because function got partially inlined, the wrong
call would be named init_target_chars.part.XXX and it is not.

It is possible that partial inlining affect profile in some of the callers and
then it might be some bug in profile updating, so I would like to see a
testcase.
x.c in the PR is truncated and when i compile builtins.c from my GCC tree
(x86-64) I do not get init_target_chars in unlikely function.
For some funny reason I however get gimple_rewrite_call_expr. All uses of it
are preceeded by very many exists from the function that makes them appear
cold. Funny but probably not harmful.

Honza

[Bug c++/45845] g++.dg/pubtypes.C scan-assembler "A\\\\\\\\0"+[ \\t]+[#;@]+[\\t]+external name

[howarth at nitro dot med.uc.edu]

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

--- Comment #4 from Jack Howarth  2010-09-30 
17:02:29 UTC ---
The failing testcase was introduced with the proposed patch...

http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00438.html

that added the ability to generate the DWARF pubtypes section on Darwin
architectures (or any other architecture that defines DEBUG_PUBTYPES_SECTION).

[Bug target/45837] [4.6 Regression] Global options changes on Sept. 29th, breaks powerpc linux64 build

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0
Summary|Global options changes on   |[4.6 Regression] Global
   |Sept. 29th, breaks powerpc  |options changes on Sept.
   |linux64 build   |29th, breaks powerpc
   ||linux64 build

[Bug bootstrap/45801] [4.6 regression] powerpc64-linux bootstrap comparison failure

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||45837

--- Comment #2 from Andrew Pinski  2010-09-30 
17:09:35 UTC ---
(In reply to comment #1)
> Please try with current trunk.

Well PR 45837 shows a different failure instead.

[Bug lto/45810] 40% slowdown when using LTO for a single-file program

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  
2010-09-30 17:28:19 UTC ---
(In reply to comment #8)
> Using -fno-inline-functions, the program recovers the speed of the no-LTO
> version.

This does not work on powerpc-apple-darwin9:

[karma] lin/test% gfc -Ofast -funroll-loops -fwhole-program -g fatigue.f90
[karma] lin/test% time a.out > /dev/null
15.942u 0.052s 0:16.54 96.6%0+0k 2+1io 40pf+0w
[karma] lin/test% gfc -Ofast -funroll-loops -fwhole-program -g -flto
fatigue.f90
[karma] lin/test% time a.out > /dev/null
20.330u 0.063s 0:21.06 96.8%0+0k 0+2io 0pf+0w
[karma] lin/test% gfc -Ofast -funroll-loops -fwhole-program -g -flto
-fno-inline-functions fatigue.f90
[karma] lin/test% time a.out > /dev/null
20.678u 0.063s 0:21.33 97.1%0+0k 0+2io 0pf+0w
[karma] lin/test% gfc -Ofast -funroll-loops -fwhole-program -g -flto
-finline-limit=600 fatigue.f90
[karma] lin/test% time a.out > /dev/null
10.903u 0.036s 0:11.30 96.7%0+0k 0+2io 0pf+0w

[Bug web/45846] New: Partial attachments in bugzilla

[jakub at gcc dot gnu.org]

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

   Summary: Partial attachments in bugzilla
   Product: gcc
   Version: 4.3.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


When downloading
http://gcc.gnu.org/bugzilla/attachment.cgi?id=21915
with wget or elinks, only 666 bytes are downloaded, while when viewing the same
in mozilla, it has 1710 bytes.
When doing
telnet gcc.gnu.org 80
GET /bugzilla/attachment.cgi?id=21915 HTTP/1.1
Host: gcc.gnu.org

I get:
HTTP/1.1 200 OK
Date: Thu, 30 Sep 2010 17:35:13 GMT
Server: Apache/2.0.52 (Red Hat)
Content-disposition: inline; filename="bug-45837.patch01"
Content-length: 666
Vary: Accept-Encoding
Content-Type: text/plain; name="bug-45837.patch01"; charset=

and then 1710 bytes of the file, so it seems to be a bugzilla bug.

[Bug web/45846] Partial attachments in bugzilla

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.09.30 17:38:57
   date||
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2010-09-30 
17:38:57 UTC ---
I have been noticing this too.

[Bug tree-optimization/45781] [4.6 Regression] GCC incorrectly puts function in .text.unlikely

[sje at cup dot hp.com]

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

--- Comment #3 from Steve Ellcey  2010-09-30 17:41:36 
UTC ---
(In reply to comment #1)
> The decision is reasonable (I suppose partial inlining will inline the
> if (!init) case) as the function is called exactly once then and thus
> should be optimized for size and put into a separate section.

But when I compile with -O2, partial inlining doesn't inline anything.
All the calls still exist as they are in the code.  Actually, the only
reason I can see for moving init_target_chars to .text.unlikely is that
there are 3 'early returns' in fold_builtin_snprintf_chk that could prevent
the execution from ever getting to the init_target_chars call.  Maybe that is
why GCC put it in .text.unlikely.

Very strange, I added:

tree rewrite_call_expr() { return 0; }

to my test case and recompiled to see if this new code went into .text.unlikely
but for some reason that caused everything (including init_target_chars)
to be put into .text.

> 
> The question is thus, why does that break IA64 bootstrap?
> 
> If IA64 doesn't support .text.unlikely it should define
> UNLIKELY_EXECUTED_TEXT_SECTION_NAME appropriately.

Yes, I think I need to define this for IA64 HP-UX.

[Bug bootstrap/45700] [4.5/4.6 Regression] --enable-checking=fold bootstrap failures

[aldyh at gcc dot gnu.org]

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

--- Comment #1 from Aldy Hernandez  2010-09-30 
17:47:19 UTC ---
If we call build[1-5] just to call protected_set_expr_location next, then by
all means, use build[1-5]_loc and be done with it.

Ideally we should strive to set location information if we know it, so I think
Jakub's second approach of setting the locus if different (with a copy_node) is
a good one.  However, if memory usage goes up too much, perhaps we should
re-think this, or ignore the locus as suggested.

Re: [Bug tree-optimization/45781] [4.6 Regression] GCC incorrectly puts function in .text.unlikely

[Jan Hubicka]

Hi, please, can you add the testcase to PR?  I guess problem might be that as 
the function is split and then
inlined back together the profile gets confused...

Honza

[Bug tree-optimization/45781] [4.6 Regression] GCC incorrectly puts function in .text.unlikely

[hubicka at ucw dot cz]

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

--- Comment #4 from Jan Hubicka  2010-09-30 17:47:39 UTC 
---
Hi, please, can you add the testcase to PR?  I guess problem might be that as
the function is split and then
inlined back together the profile gets confused...

Honza

[Bug bootstrap/45658] [4.6 regression] Comparison failure in gcc/ada/ali.o on Solaris 2/SPARC

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #8 from Rainer Orth  2010-09-30 17:50:18 UTC 
---
Works again as of rev. 164749.

[Bug tree-optimization/45781] [4.6 Regression] GCC incorrectly puts function in .text.unlikely

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  2010-09-30 
18:21:29 UTC ---
I think I am hitting instance of PR45846.  I get just part of the testcase:
typedef union tree_node *tree;
struct tree_exp { tree operands[1]; };
union tree_node { struct tree_exp exp; };
static unsigned char init_target_chars (void);
static unsigned long long target_newline;



tree rewrite_call_expr()
{
return 0;
}

tree fold_builtin_snprintf_chk (tree exp)
{
tree len, fmt;
if (exp->exp.operands[0] < 5)