[Bug middle-end/49220] New: ICE in create_pre_exit, at mode-switching.c:401

[rmansfield at qnx dot com]

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

   Summary: ICE in create_pre_exit, at mode-switching.c:401
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rmansfi...@qnx.com
  Host: x86_64-linux-gnu
Target: sh4-unknown-linux-gnu
 Build: x86_64-linux-gnu


Created attachment 24389
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24389
preprocessed source

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: sh4-unknown-linux-gnu
Configured with: ../configure --target=sh4-unknown-linux-gnu
--prefix=/home/ryan/x-tools/sh4-unknown-linux-gnuc
--with-local-prefix=/home/ryan/x-tools/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sys-root
--disable-multilib
--with-sysroot=/home/ryan/x-tools/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sys-root
--with-newlib --enable-threads=no --disable-shared --enable-__cxa_atexit
--disable-nls --enable-symvers=gnu --enable-languages=c
--enable-target-optspace --enable-checking --disable-libmudflap
--disable-libssp
Thread model: single
gcc version 4.7.0 20110529 (experimental) [trunk revision 174391] (GCC) 
$ ./xgcc -B. ~/ice.i -O2
/home/ryan/ice.i: In function 'func4':
/home/ryan/ice.i:25:1: internal compiler error: in create_pre_exit, at
mode-switching.c:401
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug libstdc++/49219] New: [c++0x] comparing unordered containers illegally require key compare

[roman at binarylife dot net]

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

   Summary: [c++0x] comparing unordered containers illegally
require key compare
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ro...@binarylife.net


$ cat test.cpp 
#include 
#include 
struct K {
//  bool operator!=(K const&)const;
//  bool operator==(K const&)const;
};
struct H { std::size_t operator()(K const&)const; };
struct E { bool operator()(K const&,K const&)const; };
extern std::unordered_set a;
extern std::unordered_map b;
extern std::unordered_multiset c;
extern std::unordered_multimap d;
bool af=(a==a);
bool bf=(b==b);
bool cf=(c==c);
bool df=(d==d);

$ g++ -c -std=c++0x test.cpp
... failure

Each of "bool xf=(x==x);" require "bool K::operator!=(K const&)const" and/or
"bool K::operator==(K const&)const". The provided E type should be used for key
compare.

[Bug tree-optimization/49218] New: Incorrect optimization of a 'for' loop creates an infinite loop

[perso...@e-maxx.ru]

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

   Summary: Incorrect optimization of a 'for' loop creates an
infinite loop
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: perso...@e-maxx.ru


Created attachment 24388
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24388
The program reads a number, and then it should output it back. After incorrect
optimization, however, the program hangs up

The following small program hangs up if compiled under gcc 4.6 with -O2.

The program reads a number (it can be any number, '5' for example), and then it
performs some silly for-loop, and then it should output the same number.

In gcc 4.6 with -O2, however, the program hangs up without outputting anything.
It looks like the loop (which can be doing less that 10 operations in reality)
is 'optimized' into an infinite loop.

[Bug tree-optimization/49217] New: Wrong optimization of code

[perso...@e-maxx.ru]

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

   Summary: Wrong optimization of code
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: perso...@e-maxx.ru


Created attachment 24387
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24387
The program demostrating the bug (should return 0 if OK, but throws in case of
wrong optimization)

A bug in gcc 4.6.0 optimizer leads to incorrect program flow.

It looks like this exact bug is difficult to reproduce in small program, so the
attached program is a result of my minimization.

The bug requires quite complex environment: recursive function, std::vector,
std::vector::iterator, zeroing the global array, unreachable 'else'.

Though, I think, the main idea of the program is not so difficult: we call
DFS(0), it calls DFS(1), and as a result both 0 and 1 are marked as visited, so
the number of calls of DFS() from main() is equal to one. But in g++ 4.6.0 with
-O2 that's not true (it looks like DFS(0) never calls DFS(1), but that's my
hypothesis).

Inserting cerr or cout into some places of DFS makes the program work fine.

[Bug c++/49105] [C++0x][SFINAE] ICE during list-initialization of rvalue-references to const

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||wsf at fultondesigns dot
   ||co.uk

--- Comment #5 from Jason Merrill  2011-05-29 
00:45:29 UTC ---
*** Bug 44920 has been marked as a duplicate of this bug. ***

[Bug c++/44920] [C++0x] const rvalue cast results in internal compiler error

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||DUPLICATE
   Target Milestone|--- |4.6.1
  Known to fail||

--- Comment #2 from Jason Merrill  2011-05-29 
00:45:29 UTC ---
Fixed for 4.6.1.

*** This bug has been marked as a duplicate of bug 49105 ***

[Bug c++/47687] [C++0x] Crash on a lambda returning a lambda (using std::function)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||wb at fnal dot gov

--- Comment #5 from Jason Merrill  2011-05-29 
00:43:57 UTC ---
*** Bug 45167 has been marked as a duplicate of this bug. ***

[Bug c++/45167] [C++0x] lambda+template="Internal error: Segmentation fault (program cc1plus)"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Jason Merrill  2011-05-29 
00:43:57 UTC ---
Fixed for 4.7.0.

*** This bug has been marked as a duplicate of bug 47687 ***

[Bug c++/47277] [C++0x] pseudo destructor code that cause an internal compiler error with std=gnu++0x

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.6.1

--- Comment #7 from Jason Merrill  2011-05-29 
00:39:37 UTC ---
ICE fixed for 4.6.1, error improved for 4.7.0.

[Bug c++/46124] [C++0x] ICE: tree check: expected var_decl or function_decl, have error_mark in cp_parser_lambda_declarator_opt, at cp/parser.c:7817 on invalid lambda function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0

--- Comment #3 from Jason Merrill  2011-05-29 
00:38:51 UTC ---
Fixed for 4.7.0.

[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  
2011-05-28 22:29:00 UTC ---
> Might be best to revert the patch for now?

Especially in the light of comment #3:

> Ugh.  I do not have time to deal with this problem at the moment.

Anyway I did not wait and I have done it on my platforms (x86_64-apple-darwin10
and powerpc-apple-darwin9).

[Bug libstdc++/49215] [4.7 Regression] FAIL: 20_util/pointer_traits/pointer_to.cc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #2 from Jonathan Wakely  2011-05-28 
22:26:08 UTC ---
fixed http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg03243.html

[Bug c++/46124] [C++0x] ICE: tree check: expected var_decl or function_decl, have error_mark in cp_parser_lambda_declarator_opt, at cp/parser.c:7817 on invalid lambda function

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-05-28 
22:01:44 UTC ---
Author: jason
Date: Sat May 28 22:01:38 2011
New Revision: 174386

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174386
Log:
PR c++/46124
* parser.c (cp_parser_lambda_expression): Improve error recovery.
(cp_parser_lambda_declarator_opt): Likewise.  Return bool.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-syntax1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/47277] [C++0x] pseudo destructor code that cause an internal compiler error with std=gnu++0x

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  2011-05-28 
22:01:32 UTC ---
Author: jason
Date: Sat May 28 22:01:28 2011
New Revision: 174385

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174385
Log:
PR c++/47277
* parser.c (cp_parser_pseudo_destructor_name): Commit to parse
after we see the ~.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/enum18.C

[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.05.28 21:44:52
 AssignedTo|unassigned at gcc dot   |tkoenig at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #8 from Thomas Koenig  2011-05-28 
21:44:52 UTC ---
Which test cases still fail, and which ones are fixed?

It is a bit unclear from the log...(In reply to comment #7)
> So what is the status of this defect?   It would appear to be "will not fix".

The status is more like "Nobody hasn't gotten a round tuit"...

Looking at the original test case, this now fails because the
public statement for == does not pick up the interface for .eq.
This can be seen from the module dump.

If you remove the "private", or use "interface operator(.eq.)", then
it works.  Hmm...

This patch

Index: decl.c
===  
--- decl.c  (revision 173754)
+++ decl.c  (working copy)   
@@ -6478,9 +6478,24 @@   
case INTERFACE_INTRINSIC_OP: 
  if (gfc_current_ns->operator_access[op] == ACCESS_UNKNOWN) 
{
+ gfc_intrinsic_op same_op;  
+
+ same_op = INTRINSIC_NONE;  
+
  gfc_current_ns->operator_access[op] =  
(st == ST_PUBLIC) ? ACCESS_PUBLIC : ACCESS_PRIVATE;  
+
+ if (op == INTRINSIC_EQ)
+   same_op = INTRINSIC_EQ_OS;   
+ else if (op == INTRINSIC_EQ_OS)
+   same_op = INTRINSIC_EQ;  
+
+ if (same_op != INTRINSIC_NONE) 
+   gfc_current_ns->operator_access[same_op] =   
+ (st == ST_PUBLIC) ? ACCESS_PUBLIC : ACCESS_PRIVATE;
+
}
+
  else   
{
  gfc_error ("Access specification of the %s operator at %C has "

seems to fix the bug.  It doesn't fix all cases, because it only
looks at == and .eq. and not at the other operators, but the principle
appears to be sound.

Let's see if we can get this fixed for 4.7.

[Bug c++/49216] New: [C++0x][Regression] ICE on compiling new-expression with braced-init-list for arrays

[gintensubaru at gmail dot com]

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

   Summary: [C++0x][Regression] ICE on compiling new-expression
with braced-init-list for arrays
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gintensub...@gmail.com


int main() {
  new int[1]{};
}


This code becomes ICE on following versions :

4.6.0
4.6-20110527
4.7-20110523


Here's the error message ( on gcc-4.6.0 ) :

$ g++ -std=c++0x bug.cc
bug.cc: In function 'int main()':
bug.cc:2:15: internal compiler error: in gimplify_init_constructor, at
gimplify.c:3973
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c/49207] Instruction scheduling error in GCC mips cross-compiler

[hanib at ece dot ubc.ca]

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

--- Comment #4 from hanib at ece dot ubc.ca 2011-05-28 21:21:40 UTC ---
(In reply to comment #3)
> I think you have an aliasing problem in your code.

The code I am compiling is the Perlbench benchmark from SPEC-CPU2006. If I
compile the code for an Intel machine using -O2 there is no problem. This
problem only appears when I use the GCC MIPS cross-compiler with the -O2
switch. I also traced through the code and the sequence of these two
instructions should be reversed.

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[dominiq at lps dot ens.fr]

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

--- Comment #24 from Dominique d'Humieres  
2011-05-28 21:15:44 UTC ---
(In reply to comment #23)
> Here is an updated patch: ...

It passes my tests. Thanks.

Just one question:

+  if (q)
+associate_integer_pointer (p, q);

What happens if q==0?

[Bug target/45345] In function `mips16_build_function_stub' undefined reference to `ASM_OUTPUT_DEF'

[rsandifo at gcc dot gnu.org]

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
2011-05-28 21:16:17 UTC ---
(In reply to comment #6)
> No -- as in this, this isn't unused, ought not be deprecated.
> You mentioned 32bit mips/a.out -- sure, maybe that is unused.
>   I assume a.out is almost unused across the board.
> But 64bit mips/elf is used.
> 
> Now, granted, OpenBSD I believe is sticking back with gcc 4.2?3/GPL2 so
> probably doesn't care what you do with 4.5.

Well, this isn't about 4.5, it's about 4.7.  And the idea
is that 4.7 will still accept mips*-*-openbsd* when configured
with --enable-obselete.  (Although that's only a technicality
given that the port doesn't build.)

But if OpenBSD are sticking with 4.2, someone else needs to
do the work to fix it for mainline, and to be prepared to
continue to care for it going forward.  There's no point
keeping a port that doesn't build for year after year.

> But surely Linux is using mips64/elf and probably also mips32/elf?
> (and Irix, if it is still supported)

Sure, but they do all the things that an ELF port should do.
As you note in comment #2, OpenBSD doesn't.  This is not about
deprecating MIPS on ELF.

> There is pretty recent hardware development here, you know, Loongson.

Again, I'm not sure what you mean.  What bearing does Loongson
have on the OpenBSD port?

Loongson as an _architecture_ is of course supported, and people
are happily using on GNU/Linux.  But as with all these things
the reason that Loongson is a supported architecture is that
people have been prepared to submit patches for it and fix bugs.

Richard

[Bug middle-end/49210] [4.7 regression] verify_gimple fails building ada/einfo.o at -O3

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.28 21:12:50
 CC||ebotcazou at gcc dot
   ||gnu.org
Version|unknown |4.7.0
   Target Milestone|--- |4.7.0
Summary|verify_gimple fails |[4.7 regression]
   |building ada/einfo.o at -O3 |verify_gimple fails
   ||building ada/einfo.o at -O3
 Ever Confirmed|0   |1

--- Comment #1 from Eric Botcazou  2011-05-28 
21:12:50 UTC ---
Yep.  I'm going to reduce it into a testcase for gnat.dg.

[Bug bootstrap/49209] unresolved references to fatal() while linking xgcc and cpp

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.05.28 21:07:21
 CC||ebotcazou at gcc dot
   ||gnu.org
Summary|Solaris10/SPARC: gcc.c has  |unresolved references to
   |unresolved references to|fatal() while linking xgcc
   |fatal() while linking xgcc  |and cpp
   |and cpp |
 Ever Confirmed|0   |1
  Build||sparc-sun-solaris2.10

--- Comment #1 from Eric Botcazou  2011-05-28 
21:07:21 UTC ---
> I just tried to bootstrap gcc-4.6.0 on Solaris10 and got this:

GCC is known to bootstrap flawlessly on this platform, so this is unexpected.

> I fixed this by copying the fatal() from gcc/errors.c to gcc/diagnostic.c.
> However, it is not clear to me why the link succeeds on Debian Lenny (x64) and
> fails on Solaris10.

Yes, please find out where this reference to 'fatal' comes from.

> I also recognized that there is some code duplication in diagnostic.c and
> errors.c, maybe they're candidates for a cleanup?

See the comment at the beginning of the errors.c file.

[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on x86_64-apple-darwin10

[gerald at pfeifer dot com]

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

Gerald Pfeifer  changed:

   What|Removed |Added

 CC||gerald at pfeifer dot com

--- Comment #9 from Gerald Pfeifer  2011-05-28 
20:46:20 UTC ---
This also kills the bootstrap on amd64-unknown-freebsd8.2 (though not
i386-...):

In file included from ../.././gcc/gthr-default.h:1:0,
 from /scratch/tmp/gerald/gcc-HEAD/libgcc/../gcc/gthr.h:160,
 from
/scratch/tmp/gerald/gcc-HEAD/libgcc/../gcc/unwind-dw2.c:37
:
/scratch/tmp/gerald/gcc-HEAD/libgcc/../gcc/gthr-posix.h:118:1: internal
compiler
 error: tree check: expected tree that contains 'common' structure, have
'identi
fier_node' in assemble_alias, at varasm.c:5789


Might be best to revert the patch for now?

[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  2011-05-28 
20:42:16 UTC ---
This also caused all the ICE on regress (ppc-darwin9, see
http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg03217.html ).

[Bug libstdc++/49215] [4.7 Regression] FAIL: 20_util/pointer_traits/pointer_to.cc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.05.28 20:35:30
 AssignedTo|unassigned at gcc dot   |redi at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug libstdc++/49215] [4.7 Regression] FAIL: 20_util/pointer_traits/pointer_to.cc

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-05-28 
20:34:00 UTC ---
should be fixed at 174384

[Bug libstdc++/49215] New: [4.7 Regression] FAIL: 20_util/pointer_traits/pointer_to.cc

[hjl.tools at gmail dot com]

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

   Summary: [4.7 Regression] FAIL:
20_util/pointer_traits/pointer_to.cc
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 174383 gave

FAIL: 20_util/pointer_traits/pointer_to.cc (test for excess errors)

Revision 174380 is OK.

[Bug libfortran/49214] New: [4.7 Regression] Broken pipe in backtrace for x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

   Summary: [4.7 Regression] Broken pipe in backtrace for
x86_64-apple-darwin10
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: fxcoud...@gcc.gnu.org, j...@gcc.gnu.org


Since some time -fbacktrace is enabled by default in gfortran, leading to
outputs such as

[macbook] f90/bug% a.out
 ú!@wxyzMú!@wxyzM
   5.2054160474760624E-145 @wx  31353
   3.1415901184082031  wxyz 77

Backtrace for this error:
  + 0   libgfortran.3.dylib 0x00014840
_gfortrani_show_backtrace + 32
  + 1   a.out   0x00010d7f MAIN__ + 9
  + 2   a.out   0x00010db7 main + 54
  + 3   a.out   0x00010838 start + 52
  + 4   ??? 0x0001 0x0 + 1
Abort

Since revision 174030, on x86_64-apple-darwin10 they have been replaced with

[macbook] f90/bug% a.out
 ú!@wxyzMú!@wxyzM
   5.2054160474760624E-145 @wx  31353
   3.1415901184082031  wxyz 77

Backtrace for this error:
 #0  /Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out[0x13B77]
in  at Broken pipe

AFAIU the changes in libgfortran/runtime/backtrace.c, this has to be expected
since the pipe support seems to have been removed. I would not have bothered
too much if I dis not have a nasty side effect when the run time error is of
the kind

a.out(22437) malloc: *** error for object 0x414c: pointer being
freed was not allocated
*** set a breakpoint in malloc_error_break to debug

or

Assertion failed: (GFC_DESCRIPTOR_RANK (a) == 2 || GFC_DESCRIPTOR_RANK (b) ==
2), function matmul_r8, file ../../../work/libgfortran/generated/matmul_r8.c,
line 91.

In which case the OSX the executable enter in a weird state after having
triggered the OSX crash reporter: the executable eats half of the CPU time on
each core in the system state and a duplicate between parentheses appears. So
far the only solution I have found is to 'kill -9' the executable.
Not suitable for automatic testing. Note that compiling with -fno-stacktrace
does not help.

[Bug target/45345] In function `mips16_build_function_stub' undefined reference to `ASM_OUTPUT_DEF'

[jay.krell at cornell dot edu]

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

--- Comment #6 from Jay  2011-05-28 19:47:42 UTC 
---
No -- as in this, this isn't unused, ought not be deprecated.
You mentioned 32bit mips/a.out -- sure, maybe that is unused.
  I assume a.out is almost unused across the board.
But 64bit mips/elf is used.

Now, granted, OpenBSD I believe is sticking back with gcc 4.2?3/GPL2 so
probably doesn't care what you do with 4.5.

But surely Linux is using mips64/elf and probably also mips32/elf?
(and Irix, if it is still supported)
There is pretty recent hardware development here, you know, Loongson.

I must have been referring to the email thread or the duplicate mail.

[Bug c++/49196] GCC 4.2.1 [FreeBSD] segfaults with certain use of void typedefs with debugging symbols

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2011-05-28 
19:45:35 UTC ---
(In reply to comment #2)
> (who do not want to update to a GPLv3 GCC release).

Boy, this is the most insane (and funny, because I don't care much about
FreeBSD anyway) thing I learned over the last few months. Thanks Richard.

[Bug target/45345] In function `mips16_build_function_stub' undefined reference to `ASM_OUTPUT_DEF'

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
2011-05-28 19:38:10 UTC ---
(In reply to comment #4)
> No -- this is mips64. OpenBSD uses it -- loongson.

Sorry, what are you saying "no" to?  To be clear,
by "the port", I meant mips*-*-openbsd*.  There's
no separate mips64*-*-openbsd* configuration.

[Bug target/45345] In function `mips16_build_function_stub' undefined reference to `ASM_OUTPUT_DEF'

[jay.krell at cornell dot edu]

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

--- Comment #4 from Jay  2011-05-28 19:20:51 UTC 
---
No -- this is mips64. OpenBSD uses it -- loongson.

[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent

[neil.n.carlson at gmail dot com]

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

--- Comment #7 from neil.n.carlson at gmail dot com 2011-05-28 18:14:04 UTC ---
So what is the status of this defect?   It would appear to be "will not fix".

[Bug fortran/49213] New: [OOP] gfortran rejects structure constructor expression

[neil.n.carlson at gmail dot com]

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

   Summary: [OOP] gfortran rejects structure constructor
expression
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: neil.n.carl...@gmail.com


In the following program type-compatible variables are used as an expression in
a structure constructor for an allocatable CLASS(S) component.  In the first
case a TYPE(S) variable is used, and in the second a TYPE(S2), where S2 extends
S.

The program compiles with nagfor 5.2 and (reportedly) with the cray compiler,
but gfortran rejects the code with the error messages:

  Tobj = T(Sobj)
   1
Error: Can't convert TYPE(s) to CLASS(s) at (1)

  Tobj = T(S2obj)
   1
Error: Can't convert TYPE(s2) to CLASS(s) at (1)

===

>From the F2008 standard:

"For a nonpointer component, the declared type and type parameters of the
component and expr shall conform in the same way as for a variable and expr in
an intrinsic assignment statement (7.2.1.2) [...]" (4.5.10p2)

"if the variable is polymorphic it shall be type compatible with expr; [...]"
(7.2.1.2p1(4))

Also 4.5.10 p6 applies to allocatable components.

===

program main

  type :: S
integer :: n
  end type
  type(S) :: Sobj

  type, extends(S) :: S2
integer :: m
  end type
  type(S2) :: S2obj

  type :: T
class(S), allocatable :: x
  end type
  type(T) :: Tobj

  Sobj = S(1)
  Tobj = T(Sobj)

  S2obj = S2(1,2)
  Tobj = T(S2obj)

end program

[Bug fortran/49103] [4.6/4.7 Regression] local variables exchange values / wrong code with -O3

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  
2011-05-28 17:56:56 UTC ---
(In reply to comment #9)
> My understanding is: It's a middle-end bug, which got exposed by Rev. 169083,
> but which can occur also with other C, C++ or Fortran code.

> A proper fix will presumably 4.7 only as it should be rather invasive; cf.
> Michael's patch at http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02029.html
> which also should fix PR 39604?

I have reinstalled revision 169083 along with Michael's patch at
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02029.html and this indeed fix
this PR. Further testing in progress.

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #23 from janus at gcc dot gnu.org 2011-05-28 17:47:39 UTC ---
(In reply to comment #22)
> [macbook] f90/bug% gfc
> /opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_proc_12.f90
> f951: internal compiler error: Segmentation fault

Thanks for checking, Dominique. Here is an updated patch:

Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(revision 174380)
+++ gcc/fortran/module.c(working copy)
@@ -2356,14 +2356,10 @@ mio_component_ref (gfc_component **cp, gfc_symbol
   if (sym->components != NULL && p->u.pointer == NULL)
 {
   /* Symbol already loaded, so search by name.  */
-  for (q = sym->components; q; q = q->next)
-if (strcmp (q->name, name) == 0)
-  break;
+  q = gfc_find_component (sym, name, true, true);

-  if (q == NULL)
-gfc_internal_error ("mio_component_ref(): Component not found");
-
-  associate_integer_pointer (p, q);
+  if (q)
+associate_integer_pointer (p, q);
 }

   /* Make sure this symbol will eventually be loaded.  */
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 174380)
+++ gcc/fortran/symbol.c(working copy)
@@ -1996,7 +1996,7 @@ gfc_find_component (gfc_symbol *sym, const char *n
 {
   gfc_component *p;

-  if (name == NULL)
+  if (name == NULL || sym == NULL)
 return NULL;

   sym = gfc_use_derived (sym);

[Bug ada/49212] New: targparm.ad[bs]: Runtime Library Exception in spec but not corresponding body

[ludo...@ludovic-brenta.org]

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

   Summary: targparm.ad[bs]: Runtime Library Exception in spec but
not corresponding body
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ludo...@ludovic-brenta.org


In gcc/gcc/ada, I just noticed that targparm.ads has the Runtime Library
Exception but targparm.adb does not.  This has been the case since:

2005-12-05  Doug Rupp  
* targparm.ads: Add special exception to license.

Is this intentional? If not, I suggest removing the Runtime Library Exception
from the spec, since this unit is not part of the run-time library libgnat.

-- 
Ludovic Brenta.

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[dominiq at lps dot ens.fr]

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

--- Comment #22 from Dominique d'Humieres  
2011-05-28 16:38:18 UTC ---
If I did not do any mistake, the patch in comment #21 fixes this PR (AFAICT),
but cause the following regression (on x86_64-apple-darwin10 with -m32):

[macbook] f90/bug% gfc
/opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_proc_12.f90
f951: internal compiler error: Segmentation fault

The backtrace is

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00a8
gfc_find_component (sym=,
name=0x7fff5fbfcda0 "e", noaccess=0 '\0', silent=0 '\0') at
../../work/gcc/fortran/symbol.c:2004
2004  for (p = sym->components; p; p = p->next)
(gdb) bt
#0  gfc_find_component (sym=, name=0x7fff5fbfcda0 "e", noaccess=0 '\0', silent=0 '\0') at
../../work/gcc/fortran/symbol.c:2004
#1  0x000100072378 in gfc_match_varspec (primary=0x141d19c00,
equiv_flag=, sub_flag=0
'\0', ppc_arg=1 '\001') at ../../work/gcc/fortran/primary.c:1913

[Bug middle-end/49201] [4.7 Regression] ice in tree_add_const_value_attribute

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  2011-05-28 16:30:32 
UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > Please provide full command line option.
> 
> g++ -g attachment.cpp ?

Please try revision 174380.

[Bug fortran/49112] [4.6/4.7 Regression] [OOP] Missing type-bound procedure, "duplicate save" warnings and internal compiler error

[jwmwalrus at gmail dot com]

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

--- Comment #8 from John  2011-05-28 16:28:15 UTC 
---
(In reply to comment #5)
> (In reply to comment #4)
> > SAVE can be either a statement or an attribute.  When it's statement, it
> > affects all the variables within the containing unit
> 
> Yes, of course. I completely forgot about this possibility.
> 
> Btw, the code in comment #3 works with gfortran 4.5, so it is in fact a
> regression.
> 
> 
> > The standard also allows the confirmation, as an attribute, of the SAVE at 
> > the
> > module level, so, for a "triple save" example:
> > 
> > module t1_mod
> > save
> > 
> > type :: t1
> > integer :: dummy = 0
> > end type
> > 
> > type(t1), save :: a = t1(2), b = t1(3)
> > end type

Sorry, it should have been "end module"

> > 
> > 
> > Which also triggers a duplicate save warning.
> 
> This is at best a "double save", and I think the (F08) standard forbids it:
> 
> C580 (R553) If a SAVE statement with an omitted saved entity list appears in a
> scoping unit, no other appearance of the SAVE attr-spec or SAVE statement is
> permitted in that scoping unit.
> t
> So I think in this case gfortran correctly complains about a "Duplicate SAVE
> attribute".

Ups... I completely forgot about that constraint (I must have been thinking
about section 5.3.16, which mentions an implicit SAVE statement for modules,
and that one can be explicitly confirmed).  So yes, it's at best an extension
to the standard.  Intel's and Sun's compilers complain about it:

...:~$ ifort -stand -c t1.f90 
t1.f90(8): warning #7652: The F2003 standard says that the SAVE attribute is
invalid since there is an occurrence of a SAVE statement with an omitted
save-entity-list in the same scoping unit.   [SAVE]
type(t1), save :: a = t1(2), b = t1(3)

...:~$ sunf95 -ansi -c t1.f90 

type(t1), save :: a = t1(2), b = t1(3)
  ^
"t1.f90", Line = 8, Column = 15: ANSI: The Fortran standard requires a SAVE
statement with no saved-entity-list to be the only SAVE in the scoping unit.



One thing about the original code, is that the "duplicate save" warning is
being issued for an entity with the PARAMETER attribute ---so the SAVE at the
scoping unit shouldn't even affect it, since the entity is not really a
variable.

[Bug libfortran/48982] libgfortran on sysv never uses fpsetmask

[nicolai.stange at zmaw dot de]

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

--- Comment #6 from Nicolai Stange  2011-05-28 
15:48:41 UTC ---
> Can you test whether this works on 4.6?
Works like a charm with gcc-4.6.0 release (without any diffs applied).

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #21 from janus at gcc dot gnu.org 2011-05-28 15:23:22 UTC ---
Improved patch, makes the original test case work:

Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(revision 174380)
+++ gcc/fortran/module.c(working copy)
@@ -2356,14 +2356,10 @@ mio_component_ref (gfc_component **cp, gfc_symbol
   if (sym->components != NULL && p->u.pointer == NULL)
 {
   /* Symbol already loaded, so search by name.  */
-  for (q = sym->components; q; q = q->next)
-if (strcmp (q->name, name) == 0)
-  break;
+  q = gfc_find_component (sym, name, true, true);

-  if (q == NULL)
-gfc_internal_error ("mio_component_ref(): Component not found");
-
-  associate_integer_pointer (p, q);
+  if (q)
+associate_integer_pointer (p, q);
 }

   /* Make sure this symbol will eventually be loaded.  */
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 174380)
+++ gcc/fortran/symbol.c(working copy)
@@ -1996,14 +1996,11 @@ gfc_find_component (gfc_symbol *sym, const char *n
 {
   gfc_component *p;

-  if (name == NULL)
+  if (name == NULL || sym == NULL)
 return NULL;
-
+  
   sym = gfc_use_derived (sym);

-  if (sym == NULL)
-return NULL;
-
   for (p = sym->components; p; p = p->next)
 if (strcmp (p->name, name) == 0)
   break;

[Bug c++/47589] [4.3/4.4 Regression] internal compiler error: Segmentation fault

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  2011-05-28 
15:22:30 UTC ---
*** Bug 47588 has been marked as a duplicate of this bug. ***

[Bug c++/47588] internal compiler error: Segmentation fault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Jonathan Wakely  2011-05-28 
15:22:30 UTC ---
dup

*** This bug has been marked as a duplicate of bug 47589 ***

[Bug c++/47588] internal compiler error: Segmentation fault

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-05-28 
15:20:42 UTC ---
*** Bug 47587 has been marked as a duplicate of this bug. ***

[Bug c++/47587] internal compiler error: Segmentation fault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Jonathan Wakely  2011-05-28 
15:20:42 UTC ---
dup

*** This bug has been marked as a duplicate of bug 47588 ***

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[burnus at gcc dot gnu.org]

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

--- Comment #20 from Tobias Burnus  2011-05-28 
15:12:26 UTC ---
Valgrind shows:
==9238== Invalid read of size 8
==9238==at 0x55AFD9: gfc_use_derived (symbol.c:1942)
==9238==by 0x55B126: gfc_find_component (symbol.c:2002)
==9238==by 0x55B24A: gfc_find_component (symbol.c:2015)
==9238==by 0x520B40: mio_ref (module.c:2359)

In gfc_use_derived, sym == NULL - thus, it is not surprising that
sym->components gives an ICE.

The bug seems to be in gfc_find_component where the order of sym == NULL and
gfc_use_derived seems to be reverted:

--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -2000,9 +2000,9 @@ gfc_find_component (gfc_symbol *sym, const char *name,
 return NULL;

-  sym = gfc_use_derived (sym);
-
   if (sym == NULL)
 return NULL;

+  sym = gfc_use_derived (sym);
+
   for (p = sym->components; p; p = p->next)
 if (strcmp (p->name, name) == 0)

 * * *

If one combines both patches, all reduced test cases work (comment 8, comment
11 and comment 13) and also the segfault is gone. However, in the last file of
the compilation series, one now gets:

gyre_lanr.f90:6.19:

  use gyre_lanr_bvp
   1
Interner Fehler bei (1):
mio_component_ref(): Component not found

 * * *

Note: For that ICE, the flag -std=f2003 is crucial. If I compile
gyre_lanr_bvp.f90 without it, I do not get an ICE. I have not checked whether
that's by chance (memory layout or similar).

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

--- Comment #19 from janus at gcc dot gnu.org 2011-05-28 15:05:50 UTC ---
(In reply to comment #18)
> With the patch in comment #17, the "mio_component_ref(): Component not found"
> are gone, but compiling  gyre_lanr.f90 in the original code gives a
> segmentation fault:

Right. Some pieces were missing in your backtrace, here is a complete one:

Program received signal SIGSEGV, Segmentation fault.
0x0055a828 in gfc_use_derived (sym=0x0) at
/home/jweil/gcc47/trunk/gcc/fortran/symbol.c:1942
1942  if (sym->components != NULL || sym->attr.zero_comp)
(gdb) bt
#0  0x0055a828 in gfc_use_derived (sym=0x0) at
/home/jweil/gcc47/trunk/gcc/fortran/symbol.c:1942
#1  0x0055aa1b in gfc_find_component (sym=0x0, name=0x7fffd530
"n_e", noaccess=0 '\000', silent=0 '\000') at
/home/jweil/gcc47/trunk/gcc/fortran/symbol.c:2002
#2  0x0055aac4 in gfc_find_component (sym=0x1ae7fe0,
name=0x7fffd530 "n_e", noaccess=0 '\000', silent=0 '\000') at
/home/jweil/gcc47/trunk/gcc/fortran/symbol.c:2015
#3  0x0050d039 in mio_component_ref (cp=0x1aea0b8, sym=0x1ae7fe0) at
/home/jweil/gcc47/trunk/gcc/fortran/module.c:2359

[Bug c++/47587] New: internal compiler error: Segmentation fault

[LpSolit at netscape dot net]

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

   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: maxim.yegorush...@gmail.com


g++ crashing consistently on the attached (preprocessed) source.

$ /usr/bin/g++ -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.5 20101112 (Red Hat 4.4.5-2) (GCC) 

$ /usr/bin/g++ -c -o
/home/yegorm/depot1/cmm/prj_ledger_dev/build/Linux-x86_64-64.g++-debug/obj/infra/demux/unit_test.o
-m64 -I/home/yegorm/depot1/cmm/prj_ledger_dev/include
-I/home/yegorm/depot1/cmm/prj_ledger_dev/include/Linux-x86_64-64.g++
-I/opt/atm/gcc-4.1-64/include/tzcode2009i
-I/apps/infra/3rd-party/gcc-4.4-64/libxml2-2.7.7/include/libxml2
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GLIBCXX_USE_C99_MATH
-D__STDC_FORMAT_MACROS -pipe  -g
-I/apps/infra/3rd-party/gcc-4.4-64/boost-1_42/include
-I/apps/infra/3rd-party/gcc-4.4-64/qt-4.6.3/include
-I/opt/atm/gcc-4.1-64/include/oapi-17.2
-I/apps/infra/3rd-party/gcc-4.4-64/hdf5-1.8.5/include
-I/apps/infra/3rd-party/gcc-4.4-64/matio-1.3.4/include
-I/apps/infra/3rd-party/gcc-4.4-64/gdbm-1.8.3/include -Wall -Wextra
-Wno-parentheses -Wno-missing-field-initializers -Wno-unused-parameter
-Winit-self -Wcast-align -Wmissing-include-dirs -Wpointer-arith -Wwrite-strings
-Wno-non-virtual-dtor -Wno-multichar -Wno-ignored-qualifiers -march=native
-fdiagnostics-show-option -fno-strict-aliasing -Werror=return-type
-Werror=format-extra-args  -fmessage-length=0 -falign-functions   -MD -MP -MF
/home/yegorm/depot1/cmm/prj_ledger_dev/build/Linux-x86_64-64.g++-debug/obj/infra/demux/unit_test.d
/home/yegorm/depot1/cmm/prj_ledger_dev/src/infra/demux/unit_test.cc

In file included from
/home/yegorm/depot1/cmm/prj_ledger_dev/src/infra/demux/unit_test.cc:1:
/home/yegorm/depot1/cmm/prj_ledger_dev/src/infra/demux/demux.h: In constructor
'atm::demux::TaggedFd::TaggedFd() [with EventTag =
::FdTag, Derived = ::DemuxTestClient]':
/home/yegorm/depot1/cmm/prj_ledger_dev/src/infra/demux/unit_test.cc:49:  
instantiated from here
/home/yegorm/depot1/cmm/prj_ledger_dev/src/infra/demux/demux.h:325: internal
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccfLB5zA.out file, please attach this to
your bugreport.

[Bug c++/47588] New: internal compiler error: Segmentation fault

[LpSolit at netscape dot net]

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

   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: maxim.yegorush...@gmail.com


g++ crashing consistently on the attached (preprocessed) source.

$ /usr/bin/g++ -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.5 20101112 (Red Hat 4.4.5-2) (GCC) 

$ /usr/bin/g++ -c -o
/home/yegorm/depot1/cmm/prj_ledger_dev/build/Linux-x86_64-64.g++-debug/obj/infra/demux/unit_test.o
-m64 -I/home/yegorm/depot1/cmm/prj_ledger_dev/include
-I/home/yegorm/depot1/cmm/prj_ledger_dev/include/Linux-x86_64-64.g++
-I/opt/atm/gcc-4.1-64/include/tzcode2009i
-I/apps/infra/3rd-party/gcc-4.4-64/libxml2-2.7.7/include/libxml2
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GLIBCXX_USE_C99_MATH
-D__STDC_FORMAT_MACROS -pipe  -g
-I/apps/infra/3rd-party/gcc-4.4-64/boost-1_42/include
-I/apps/infra/3rd-party/gcc-4.4-64/qt-4.6.3/include
-I/opt/atm/gcc-4.1-64/include/oapi-17.2
-I/apps/infra/3rd-party/gcc-4.4-64/hdf5-1.8.5/include
-I/apps/infra/3rd-party/gcc-4.4-64/matio-1.3.4/include
-I/apps/infra/3rd-party/gcc-4.4-64/gdbm-1.8.3/include -Wall -Wextra
-Wno-parentheses -Wno-missing-field-initializers -Wno-unused-parameter
-Winit-self -Wcast-align -Wmissing-include-dirs -Wpointer-arith -Wwrite-strings
-Wno-non-virtual-dtor -Wno-multichar -Wno-ignored-qualifiers -march=native
-fdiagnostics-show-option -fno-strict-aliasing -Werror=return-type
-Werror=format-extra-args  -fmessage-length=0 -falign-functions   -MD -MP -MF
/home/yegorm/depot1/cmm/prj_ledger_dev/build/Linux-x86_64-64.g++-debug/obj/infra/demux/unit_test.d
/home/yegorm/depot1/cmm/prj_ledger_dev/src/infra/demux/unit_test.cc

In file included from
/home/yegorm/depot1/cmm/prj_ledger_dev/src/infra/demux/unit_test.cc:1:
/home/yegorm/depot1/cmm/prj_ledger_dev/src/infra/demux/demux.h: In constructor
'atm::demux::TaggedFd::TaggedFd() [with EventTag =
::FdTag, Derived = ::DemuxTestClient]':
/home/yegorm/depot1/cmm/prj_ledger_dev/src/infra/demux/unit_test.cc:49:  
instantiated from here
/home/yegorm/depot1/cmm/prj_ledger_dev/src/infra/demux/demux.h:325: internal
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccfLB5zA.out file, please attach this to
your bugreport.

[Bug middle-end/48984] [4.7 Regression] Many testsuite failures

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #7 from John David Anglin  2011-05-28 
15:00:55 UTC ---
Also get
FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times dom1 "x[^ ]* & y" 1
on hppa2.0w-hp-hpux11.11.

[Bug web/49109] bugzilla's patch viewer sometimes hides file headers

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |LpSolit at netscape dot net
   |gnu.org |

--- Comment #2 from Frédéric Buclin  2011-05-28 
14:58:42 UTC ---
I upgraded PatchReader to 0.9.6, which has this problem fixed.

@Andreas, if you don't like the patch viewer, don't use it. But it's definitely
useful.

[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #3 from John David Anglin  2011-05-28 
14:55:40 UTC ---
Also fails on hppa*-*-hpux*.

[Bug target/49211] MMIX: Code generation broken, when using global variables

[n...@script-solution.de]

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

Nils Asmussen  changed:

   What|Removed |Added

   Severity|normal  |blocker

[Bug target/49211] New: MMIX: Code generation broken, when using global variables

[n...@script-solution.de]

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

   Summary: MMIX: Code generation broken, when using global
variables
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: n...@script-solution.de
  Host: Ubuntu on x86_64
Target: MMIX
 Build: gcc-4.6.0 with binutils-2.21


Created attachment 24386
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24386
Contains the object-file and the executable

I hope it is no missunderstanding, but as it seems, the code generation is
wrong when using global variables (I'm wondering because it is such a basic
thing).

For example, take the following C file:

struct foo {
int x,y;
};

static struct foo f;
static int x;

static void func1(int *i) {
}
static void func2(struct foo *pf) {
}

int main(void) {
int a;
f.x = 0;
f.y = 1;
x = 2;
func1(&x);
func1(&a);
func2(&f);
return 0;
}


I'm using the following commands to build the executable:
$ mmix-elf-escape-gcc -o test.o -c test.c
$ mmix-elf-escape-gcc -nostdlib -o test test.o

The disassembly for the main-function is:

0040 :
  40:27fefe10 subu $254,$254,16
  44:affdfe08 stou $253,$254,8
  48:23fdfe10 addu $253,$254,16
  4c:fe04 get $0,rJ
  50:e301 setl $1,0x0
  54:ab01fe00 sttu $1,$254,0
  58:e3010001 setl $1,0x1
  5c:ab01fe04 sttu $1,$254,4
  60:e3010002 setl $1,0x2
  64:ab01fe08 sttu $1,$254,8
  68:2303fe08 addu $3,$254,8
  6c:f302ffe5 pushj $2,0 <_start.>
  70:f604 put rJ,$0
  74:2701fd0c subu $1,$253,12
  78:c1030100 set $3,$1
  7c:f302ffe1 pushj $2,0 <_start.>
  80:f604 put rJ,$0
  84:2303fe00 addu $3,$254,0
  88:f302ffe6 pushj $2,20 
  8c:f604 put rJ,$0
  90:e300 setl $0,0x0
  94:8dfdfe08 ldo $253,$254,8
  98:23fefe10 addu $254,$254,16
  9c:f801 pop 1,0


That means, the code expects, that f is located at $254, offset 0. But $254 is
the frame-pointer according to
http://www.bitrange.com/mmix/mmixfest-2001/mmixabi.html. The example shows a
few other usages, that are wrong for the same reason. Note that it is correct
for the local variable.

For the case that it helps, I've attached the object file and the executable.

I hope that the fix is easy. It would be really nice to know shortly how to
resolve that, because before that, I think one can't do anything useful with
gcc for MMIX :/

[Bug bootstrap/49195] [4.7 Regression] Error building libgcc for powerpc64 since r174305

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #8 from William J. Schmidt  2011-05-28 
14:41:40 UTC ---
Verified that powerpc64 bootstraps cleanly this morning.  Thanks, Richard!

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres  
2011-05-28 14:27:18 UTC ---
With the patch in comment #17, the "mio_component_ref(): Component not found"
are gone, but compiling  gyre_lanr.f90 in the original code gives a
segmentation fault:

[macbook] bug/pr47601% gfc -c gyre_lanr.f90
f951: internal compiler error: Segmentation fault

The backtrace is

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00a8
gfc_use_derived (sym=0x0) at ../../work/gcc/fortran/symbol.c:1942
1942  if (sym->components != NULL || sym->attr.zero_comp)
(gdb) bt
#0  gfc_use_derived (sym=0x0) at ../../work/gcc/fortran/symbol.c:1942
#1  0x00010009f007 in gfc_find_component (sym=, name=0x7fff5fbfd220 "n_e", noaccess=0 '\0',
silent=0 '\0') at ../../work/gcc/fortran/symbol.c:2002
#2  0x0001 in ?? ()

[Bug middle-end/49201] [4.7 Regression] ice in tree_add_const_value_attribute

[dcb314 at hotmail dot com]

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

--- Comment #2 from dcb  2011-05-28 14:26:00 UTC ---
(In reply to comment #1)
> Please provide full command line option.

g++ -g attachment.cpp ?

[Bug middle-end/49210] New: verify_gimple fails building ada/einfo.o at -O3

[aoliva at gcc dot gnu.org]

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

   Summary: verify_gimple fails building ada/einfo.o at -O3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aol...@gcc.gnu.org
CC: rgue...@gcc.gnu.org


The patch for bug 48989 regressed BUILD_CONFIG=bootstrap-O3 ada builds on i686-
and x86_64-linux-gnu.  While building stage2 we hit this error:

../../gcc/ada/einfo.adb: In function ‘Einfo.Is_String_Type.Part’:
../../gcc/ada/einfo.adb:6377:4: error: invalid conversion in gimple call
boolean

einfo__b___XDLU_0__1

# .MEM_50 = VDEF <.MEM_49>
iftmp.45_26 = einfo.is_string_type.part (id_1(D));

+===GNAT BUG DETECTED==+
| 4.7.0 20110528 (experimental) [trunk revision
8219ad7:2a33c3d:4b51a1cd8cb5f4ff6a659aa55ce963497a624bd3] (x86_64-pc-linux-gnu)
GCC error:|
| verify_gimple failed |
| Error detected around ../../gcc/ada/einfo.adb:6377:4 |

[Bug tree-optimization/49199] [4.7 Regression] ICE: in vect_create_epilog_for_reduction at tree-vect-loop.c:3445 with -O -fno-tree-scev-cprop -ftree-vectorize -funswitch-loops

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.28 14:18:51
 CC||irar at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2011-05-28 14:18:51 
UTC ---
It is caused by revision 173856:

http://gcc.gnu.org/ml/gcc-cvs/2011-05/msg00635.html

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[janus at gcc dot gnu.org]

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

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 #17 from janus at gcc dot gnu.org 2011-05-28 13:43:23 UTC ---
(In reply to comment #16)
> Janus, you know type extension better than me. Does one now needs to do:
>   if (!p && sym->attr.extension)
> {
>   p = search (sym->components->ts.u.derived)
>   if (!p && sym->components->ts.u.derived->attr.extension)
> p = search (sym->components->ts.u.derived->...)
> 
> or is this the wrong method?

Yes, sounds good. Also that's exactly what 'gfc_find_component' does, so I'd
propose the following patch:


Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(revision 174030)
+++ gcc/fortran/module.c(working copy)
@@ -2356,9 +2356,7 @@ mio_component_ref (gfc_component **cp, gfc_symbol
   if (sym->components != NULL && p->u.pointer == NULL)
 {
   /* Symbol already loaded, so search by name.  */
-  for (q = sym->components; q; q = q->next)
-if (strcmp (q->name, name) == 0)
-  break;
+  q = gfc_find_component (sym, name, false, false);

   if (q == NULL)
 gfc_internal_error ("mio_component_ref(): Component not found");


This fixes the test case, but is not regtested.

[Bug middle-end/49201] [4.7 Regression] ice in tree_add_const_value_attribute

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.05.28 13:13:00
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2011-05-28 13:13:00 
UTC ---
Please provide full command line option.

[Bug c++/49196] GCC 4.2.1 [FreeBSD] segfaults with certain use of void typedefs with debugging symbols

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #2 from Richard Guenther  2011-05-28 
13:07:46 UTC ---
Report to the FreeBSD people (who do not want to update to a GPLv3 GCC
release).

[Bug tree-optimization/49199] [4.7 Regression] ICE: in vect_create_epilog_for_reduction at tree-vect-loop.c:3445 with -O -fno-tree-scev-cprop -ftree-vectorize -funswitch-loops

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug c/49200] Segmentation fault in vect_is_slp_reduction

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Richard Guenther  2011-05-28 
12:59:24 UTC ---
.

*** This bug has been marked as a duplicate of bug 49087 ***

[Bug tree-optimization/49087] crash in vect_is_slp_reduction

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #4 from Richard Guenther  2011-05-28 
12:59:24 UTC ---
*** Bug 49200 has been marked as a duplicate of this bug. ***

[Bug middle-end/49201] [4.7 Regression] ice in tree_add_const_value_attribute

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Component|c++ |middle-end
   Target Milestone|--- |4.7.0
Summary|ice in  |[4.7 Regression] ice in
   |tree_add_const_value_attrib |tree_add_const_value_attrib
   |ute |ute

[Bug tree-optimization/49203] missed-optimization: useless expressions not moved out of loop

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-05-28 
12:57:19 UTC ---
(In reply to comment #1)
> Looks like LIM is only able to hoist invariants rather than push down
> invariants.  It can push down invariant stores though.

Indeed.  code-sinking (in tree-ssa-sink.c) would be able to fix this
but it is run before loop store motion.

[Bug bootstrap/49208] bootstrap fails on OpenBSD/i386

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Richard Guenther  2011-05-28 
12:54:25 UTC ---
.

*** This bug has been marked as a duplicate of bug 49190 ***

[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on x86_64-apple-darwin10

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||jsg at openbsd dot org

--- Comment #7 from Richard Guenther  2011-05-28 
12:54:25 UTC ---
*** Bug 49208 has been marked as a duplicate of this bug. ***

[Bug bootstrap/49209] New: Solaris10/SPARC: gcc.c has unresolved references to fatal() while linking xgcc and cpp

[nicolai.stange at zmaw dot de]

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

   Summary: Solaris10/SPARC: gcc.c has unresolved references to
fatal() while linking xgcc and cpp
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nicolai.sta...@zmaw.de


Hi everybody,

I just tried to bootstrap gcc-4.6.0 on Solaris10 and got this:

gcc   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H
-Wl,-R/sw/solaris10/gcc/libelf-0.8.13/lib
-Wl,-R/sw/solaris10/gcc/cloog_ppl-0.15.11/lib
-Wl,-R/sw/solaris10/gcc/ppl-0.11.2/lib -Wl,-R/sw/solaris10/gcc/mpc-0.8.2/lib
-Wl,-R/sw/solaris10/gcc/mpfr-3.0.0/lib -Wl,-R/sw/solaris10/gcc/gmp-5.0.1/lib -o
cpp gcc.o opts-common.o gcc-options.o diagnostic.o pretty-print.o input.o vec.o
ggc-none.o \

gcc   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H
-Wl,-R/sw/solaris10/gcc/libelf-0.8.13/lib
-Wl,-R/sw/solaris10/gcc/cloog_ppl-0.15.11/lib
-Wl,-R/sw/solaris10/gcc/ppl-0.11.2/lib -Wl,-R/sw/solaris10/gcc/mpc-0.8.2/lib
-Wl,-R/sw/solaris10/gcc/mpfr-3.0.0/lib -Wl,-R/sw/solaris10/gcc/gmp-5.0.1/lib -o
xgcc gcc.o opts-common.o gcc-options.o diagnostic.o pretty-print.o input.o
vec.o ggc-none.o \
  gccspec.o intl.o prefix.o version.o  ../libcpp/libcpp.a
./../intl/libintl.a  ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
mv -f Tcollect2 collect2
gcc   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H
-Wl,-R/sw/solaris10/gcc/libelf-0.8.13/lib
-Wl,-R/sw/solaris10/gcc/cloog_ppl-0.15.11/lib
-Wl,-R/sw/solaris10/gcc/ppl-0.11.2/lib -Wl,-R/sw/solaris10/gcc/mpc-0.8.2/lib
-Wl,-R/sw/solaris10/gcc/mpfr-3.0.0/lib -Wl,-R/sw/solaris10/gcc/gmp-5.0.1/lib -o
cpp gcc.o opts-common.o gcc-options.o diagnostic.o pretty-print.o input.o vec.o
ggc-none.o \
  cppspec.o intl.o prefix.o version.o  ../libcpp/libcpp.a
./../intl/libintl.a  ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
Undefined   first referenced
 symbol in file
fatal   gcc.o
ld: fatal: Symbol referencing errors. No output written to xgcc
collect2: ld returned 1 exit status
gmake[4]: *** [xgcc] Error 1
gmake[4]: *** Waiting for unfinished jobs
Undefined   first referenced
 symbol in file
fatal   gcc.o
ld: fatal: Symbol referencing errors. No output written to cpp
collect2: ld returned 1 exit status
gmake[4]: *** [cpp] Error 1
rm gcc.pod
gmake[4]: Leaving directory
`/tmp/xas/build/gcc_gcc_4.6.0_default_gcc_32/build/gcc'

I fixed this by copying the fatal() from gcc/errors.c to gcc/diagnostic.c.
However, it is not clear to me why the link succeeds on Debian Lenny (x64) and
fails on Solaris10.

I also recognized that there is some code duplication in diagnostic.c and
errors.c, maybe they're candidates for a cleanup?

Best wishes

Nicolai

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #16 from Tobias Burnus  2011-05-28 
12:32:11 UTC ---
(In reply to comment #13)
>   type :: matching 
>  integer :: N = -999
>   end type
>   type, extends(matching) :: ellipse
>   end type

> type(ellipse), intent(in) :: e
> complex, dimension(e%N) :: a2n

Thus, when loading the expression, one needs to resolve e%N. One thus calls
module.c's mio_component_ref which does (on reading the .mod):

  if (sym->components != NULL && p->u.pointer == NULL)
{
  /* Symbol already loaded, so search by name.  */
  for (q = sym->components; q; q = q->next)
if (strcmp (q->name, name) == 0)
  break;

The comparison by name fails for extended types:

(gdb) p sym->components->name
$11 = 0x2cec33b0 "matching"
(gdb) p sym->components->next
$12 = (struct gfc_component *) 0x0

Thus: Not found. However, one has:

(gdb) p sym->attr.extension 
$13 = 1
(gdb) p sym->components->ts.u.derived->name
$14 = 0x2cec33b0 "matching"
(gdb) p sym->components->ts.u.derived->components->name
$15 = 0x2cde3fa8 "n"

Janus, you know type extension better than me. Does one now needs to do:
  if (!p && sym->attr.extension)
{
  p = search (sym->components->ts.u.derived)
  if (!p && sym->components->ts.u.derived->attr.extension)
p = search (sym->components->ts.u.derived->...)

or is this the wrong method?

[Bug bootstrap/49190] [4.7 Regression] Bootstrap failure at revision 174286 on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  2011-05-28 
12:16:38 UTC ---
PR49208 is likely a duplicate of this PR.

[Bug bootstrap/49208] bootstrap fails on OpenBSD/i386

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  2011-05-28 
12:15:53 UTC ---
This looks like a duplicate of pr49190.

[Bug libstdc++/49174] numeric_limits template is a struct not a class

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2011-05-28 
12:13:06 UTC ---
Besides which, we *are* following it to the letter, see 1.9 [intro.execution]
paragraph 1 and the accompanying footnote

5) This provision is sometimes called the “as-if” rule, because an
implementation is free to disregard any requirement of this
International Standard as long as the result is as if the requirement had been
obeyed, as far as can be determined from the
observable behavior of the program. For instance, an actual implementation need
not evaluate part of an expression if it can
deduce that its value is not used and that no side effects affecting the
observable behavior of the program are produced.


If there's an observable difference then it's a problem, otherwise it's
irrelevant.

[Bug bootstrap/49208] New: bootstrap fails on OpenBSD/i386

[jsg at openbsd dot org]

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

   Summary: bootstrap fails on OpenBSD/i386
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@openbsd.org


gcc svn fails to bootstrap on OpenBSD/i386 -current:
configured via

../gcc/configure --prefix=/usr/gcc --program-transform-name=s,^,e, \
--disable-nls \
--disable-checking \
--with-system-zlib \
--disable-libmudflap \
--disable-libgomp \
--disable-tls \
--with-as=/usr/bin/as \
--with-ld=/usr/bin/ld \
--with-gnu-ld \
--with-gnu-as \
--enable-threads=posix \
--enable-wchar_t \
--disable-lto \
--enable-languages=c,c++ \
--with-gmp=/usr/local \
--with-mpfr=/usr/local


/home/jsg/src/obj/./gcc/xgcc -B/home/jsg/src/obj/./gcc/
-B/usr/gcc/i386-unknown-openbsd4.9/bin/  B/usr/gcc/i386-unknown-openbsd4.9/lib/
-isystem /usr/gcc/i386-unknown-openbsd4.9/include -isyste 
/usr/gcc/i386-unknown-openbsd4.9/sys-include-g -O2 -O2  -g -O2 -DIN_GCC  
-W -Wall -Wwrite- trings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./i clude  -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector   -I. -I.
-I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/.
-I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include-o
unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep  fexceptions -c
../../../gcc/libgcc/../gcc/unwind-dw2.c 
In file included from ../.././gcc/gthr-default.h:1:0,
 from ../../../gcc/libgcc/../gcc/gthr.h:160,
 from ../../../gcc/libgcc/../gcc/unwind-dw2.c:37:
../../../gcc/libgcc/../gcc/gthr-posix.h:118:1: internal compiler error: tree
check: expected tre  that contains 'common' structure, have 'identifier_node'
in assemble_alias, at varasm.c:5789

$ cat stage_current
stage1

$ ./gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=./gcc/xgcc
Target: i386-unknown-openbsd4.9
Configured with: ../gcc/configure --prefix=/usr/gcc
--program-transform-name='s,^,e,' --disable-nls --disable-checking
--with-system-zlib --disable-libmudflap --disable-libgomp --disable-tls
--with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gnu-ld --with-gnu-as
--enable-threads=posix --enable-wchar_t --disable-lto --enable-languages=c,c++
--with-gmp=/usr/local --with-mpfr=/usr/local
Thread model: posix
gcc version 4.7.0 20110528 (experimental) (GCC)

[Bug libstdc++/49174] numeric_limits template is a struct not a class

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  2011-05-28 
12:01:49 UTC ---
(In reply to comment #6)
> What's so bad about following the ISO specification to the letter?

Because it makes absolutely no difference except to those who maintain the
code, and we've expressed our preference - why do you care?

libstdc++ is the GCC standard library, not clang's, so the fact someone else's
compiler doesn't like it is not our problem

[Bug target/43995] internal compiler error: Segmentation fault on Mips64 crossbuild of ext2progs

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.05.28 11:35:13
 CC||rsandifo at gcc dot gnu.org
  Component|middle-end  |target
 AssignedTo|unassigned at gcc dot   |rsandifo at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug target/44944] g++ segfault with -fvisibility-inlines-hidden -O2 -fno-exceptions -fPIC

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||rsandifo at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #7 from rsandifo at gcc dot gnu.org  
2011-05-28 11:33:14 UTC ---
Same as PR43995

*** This bug has been marked as a duplicate of bug 43995 ***

[Bug middle-end/43995] internal compiler error: Segmentation fault on Mips64 crossbuild of ext2progs

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 CC||graham.gower at gmail dot
   ||com

--- Comment #9 from rsandifo at gcc dot gnu.org  
2011-05-28 11:33:14 UTC ---
*** Bug 44944 has been marked as a duplicate of this bug. ***

[Bug target/45541] Internal error (killed) building webkit svn 65398 (loongson2f)

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE

--- Comment #8 from rsandifo at gcc dot gnu.org  
2011-05-28 11:27:05 UTC ---
Same as PR44944

*** This bug has been marked as a duplicate of bug 44944 ***

[Bug fortran/49103] [4.6/4.7 Regression] local variables exchange values / wrong code with -O3

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #9 from Tobias Burnus  2011-05-28 
11:27:55 UTC ---
(In reply to comment #8)
> I am a little bit confused by the answer:

My understanding is: It's a middle-end bug, which got exposed by Rev. 169083,
but which can occur also with other C, C++ or Fortran code.

A proper fix will presumably 4.7 only as it should be rather invasive; cf.
Michael's patch at http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02029.html
which also should fix PR 39604?

For 4.6 one probably needs a different, less invasive patch.

[Bug target/44944] g++ segfault with -fvisibility-inlines-hidden -O2 -fno-exceptions -fPIC

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 CC||viriketo at gmail dot com

--- Comment #6 from rsandifo at gcc dot gnu.org  
2011-05-28 11:27:05 UTC ---
*** Bug 45541 has been marked as a duplicate of this bug. ***

[Bug fortran/49103] [4.6/4.7 Regression] local variables exchange values / wrong code with -O3

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  2011-05-28 
11:08:17 UTC ---
(In reply to comment #7)

> Ugh, the problem is that first cunrolli unrolls the loop, so we get among
> other things parm.9 initialized for printing fgrades_35, then
> _gfortran_transfer_array_write from parm.9, then parm.11 initialized for
> printing fbasegrades_19, then _gfortran_transfer_array_write from
> parm.11, then again parm.9 initialized to the same values again,
> _gfortran_transfer_array_write from it, parm.11 to the same values and
> _gfortran_transfer_array_write from it.  Additionally,
> _gfortran_transfer_array_write uses ".wr" "fn spec" attribute.  Next
> comes fre (2nd), which sees the ".wr" fn spec and removes the second
> identical initialization of parm.9 and parm.11, so parm.9 is no longer
> live in two separate ranges, but also across the parm.11 initialization
> and _gfortran_transfer_array_write call from it.  And during expansion,
> we figure out that parm.9 and parm.11 are in different, non-overlapping
> blocks and thus decide to share the stack slot for both.
> 
> Appart from the ".wr" "fn spec" attribute I think there is nothing
> fortran specific and with
> struct S { largish struct };
> for (int i = 0; i < 2; i++)
>   {
> {
>   struct S a;
>   initialize a;
>   use a;
> }
> {
>   struct S b;
>   initialize b;
>   use b;
> }
>   }
> we could achieve similar effect (though, if e.g. use is a pure function,
> the second call would be deleted).  So, I'm not convinced reverting my
> patch is the right fix.  Not sure how to allow expansion to notice that
> unrolling made it impossible to share the stack slots though.  Ideas?

I am a little bit confused by the answer:

(1) Is the ".wr" "fn spec" attribute in _gfortran_transfer_array_write a
gfortran mistake?
If yes, what should be the fix?
(2) Will the C example also give a wrog code with revision 169083 reverted?

Note that I have never claimed that reverting revision 169083 is "the right
fix", but only that reverting it fixed the PR!-) Now from my limited
understanding of http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01442.html ,
r169083 looks like an optimization leading to wrong code, which is bad.

[Bug fortran/49112] [4.6/4.7 Regression] [OOP] Missing type-bound procedure, "duplicate save" warnings and internal compiler error

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org 2011-05-28 10:53:18 UTC ---
Here is a reduced test case for the ICE:


module datetime_mod

implicit none
private

type :: DateTime
contains
procedure :: getFormattedString
end type

contains

function getTimeString(dt, FMT) result(string)
character(:), allocatable :: string
class(DateTime), intent(IN) :: dt
integer, optional, intent(IN) :: FMT

string = dt%getFormattedString(2, FMT)
end function 

function getFormattedString(this, FILTER, FMT) &
result(string)
character(:), allocatable :: string
class(DateTime), intent(IN) :: this
integer, optional, intent(IN) :: FILTER, FMT

end function

end module

[Bug bootstrap/48679] [4.7 regression] bootstrap comparison failures on m68k-linux

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #8 from Mikael Pettersson  2011-05-28 
10:52:21 UTC ---
The bootstrap comparison failures were fixed by r173393:

Author: bernds
Date: Wed May  4 20:24:15 2011
New Revision: 173393

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173393
Log:
PR rtl-optimization/47612
* df-problems.c (can_move_insns_across): Don't pick a cc0 setter
as the last insn of the sequence to be moved.

which is a little unexpected since the bug it fixed (PR47612) didn't affect
m68k-linux prior to the large IRA update.

[Bug fortran/49112] [4.6/4.7 Regression] [OOP] Missing type-bound procedure, "duplicate save" warnings and internal compiler error

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.28 10:31:09
 Ever Confirmed|0   |1

--- Comment #6 from janus at gcc dot gnu.org 2011-05-28 10:31:09 UTC ---
(In reply to comment #0)
> ...:~$ gfortran -c  test_gfortran_missing_tbp.f90 
> test_gfortran_missing_tbp.f90:27.38:
> 
> string = dt%getFormattedString(0, FMT)
>   1
> Error: 'getformattedstring' at (1) is not a member of the 'datetime' structure

Here is a reduced test case for this error, which is also a regression:


module datetime_mod

implicit none

type :: DateTime
integer :: year, month, day
contains
procedure :: getFormattedString
end type

type(DateTime) :: ISO_REFERENCE_DATE = DateTime(1875, 5, 20)

contains

character function getString(dt)
class(DateTime) :: dt
getString = dt%getFormattedString()
end function 

character function getFormattedString(dt)
class(DateTime) :: dt
end function

end module

[Bug fortran/49112] [4.6/4.7 Regression] [OOP] Missing type-bound procedure, "duplicate save" warnings and internal compiler error

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|Missing type-bound  |[4.6/4.7 Regression] [OOP]
   |procedure, "duplicate save" |Missing type-bound
   |warnings and internal   |procedure, "duplicate save"
   |compiler error  |warnings and internal
   ||compiler error

--- Comment #5 from janus at gcc dot gnu.org 2011-05-28 10:03:36 UTC ---
(In reply to comment #4)
> SAVE can be either a statement or an attribute.  When it's statement, it
> affects all the variables within the containing unit

Yes, of course. I completely forgot about this possibility.

Btw, the code in comment #3 works with gfortran 4.5, so it is in fact a
regression.


> The standard also allows the confirmation, as an attribute, of the SAVE at the
> module level, so, for a "triple save" example:
> 
> module t1_mod
> save
> 
> type :: t1
> integer :: dummy = 0
> end type
> 
> type(t1), save :: a = t1(2), b = t1(3)
> end type
> 
> 
> Which also triggers a duplicate save warning.

This is at best a "double save", and I think the (F08) standard forbids it:

C580 (R553) If a SAVE statement with an omitted saved entity list appears in a
scoping unit, no other appearance of the SAVE attr-spec or SAVE statement is
permitted in that scoping unit.

So I think in this case gfortran correctly complains about a "Duplicate SAVE
attribute".

[Bug target/45541] Internal error (killed) building webkit svn 65398 (loongson2f)

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.05.28 09:49:18
 CC||rsandifo at gcc dot gnu.org
  Component|middle-end  |target
 AssignedTo|unassigned at gcc dot   |rsandifo at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #7 from rsandifo at gcc dot gnu.org  
2011-05-28 09:49:18 UTC ---
This is a mips_reorg bogosity.

[Bug target/47995] ICE of c++ in gcc-4.5.x at FrameLoader.cpp in WebKit build

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||rsandifo at gcc dot gnu.org
 Resolution||DUPLICATE
   Severity|critical|normal

--- Comment #5 from rsandifo at gcc dot gnu.org  
2011-05-28 09:48:08 UTC ---
This is the same problem as PR45541.

*** This bug has been marked as a duplicate of bug 45541 ***

[Bug middle-end/45541] Internal error (killed) building webkit svn 65398 (loongson2f)

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 CC||jipeng at broadcom dot com

--- Comment #6 from rsandifo at gcc dot gnu.org  
2011-05-28 09:48:08 UTC ---
*** Bug 47995 has been marked as a duplicate of this bug. ***

[Bug c/49207] Instruction scheduling error in GCC mips cross-compiler

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  2011-05-28 
09:32:38 UTC ---
I think you have an aliasing problem in your code.

[Bug rtl-optimization/49145] ICE in simplify_const_unary_operation, at simplify-rtx.c:1322

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.05.28 09:27:07
  Component|target  |rtl-optimization
 CC||rsandifo at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |rsandifo at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from rsandifo at gcc dot gnu.org  
2011-05-28 09:27:07 UTC ---
Testing a patch.

[Bug libstdc++/49174] numeric_limits template is a struct not a class

[fr...@kingswood-consulting.co.uk]

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

--- Comment #6 from Frank Kingswood  
2011-05-28 08:41:05 UTC ---
What's so bad about following the ISO specification to the letter?

[Bug libfortran/19155] [4.0 only] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
URL|http://gcc.gnu.org/ml/fortr |http://gcc.gnu.org/ml/gcc-p
   |an/2005-06/msg00318.html|atches/2011-05/msg02224.htm
   ||l
 CC||jb at gcc dot gnu.org
 Resolution|FIXED   |
 AssignedTo|fxcoudert at gcc dot|jb at gcc dot gnu.org
   |gnu.org |

--- Comment #27 from Janne Blomqvist  2011-05-28 
08:22:14 UTC ---
Reopening, since the EINVAL thing is causing problems on HP-UX 11.31. Assigning
to myself, patch at http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02224.html

[Bug target/45345] In function `mips16_build_function_stub' undefined reference to `ASM_OUTPUT_DEF'

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #3 from rsandifo at gcc dot gnu.org  
2011-05-28 08:11:18 UTC ---
Since the port has gone unmaintained for several years,
and hasn't been buildable for such a long time, it's now
slated for deprecation in 4.7 and removal in 4.8:

http://gcc.gnu.org/ml/gcc/2011-05/msg00262.html

[Bug c/49200] Segmentation fault in vect_is_slp_reduction

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 CC||irar at il dot ibm.com

--- Comment #1 from Ira Rosen  2011-05-28 07:54:23 UTC 
---
I think it's a duplicate of pr 49087. It was fixed on May 22, and your version
is from the day before.

[Bug java/20215] gcj does not accept classes with same name fields

[licheng.1212 at gmail dot com]

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

--- Comment #10 from licheng.1212 at gmail dot com  2011-05-28 07:45:31 UTC ---
(In reply to comment #4)
> Confirmed, the gij problem has been fixed by the patches above, this only
> leaves the java front-end 
> problem.


Why ony gij can fixed?
how about gcj??

[Bug bootstrap/49195] [4.7 Regression] Error building libgcc for powerpc64 since r174305

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #7 from rsandifo at gcc dot gnu.org  
2011-05-28 07:43:42 UTC ---
Fixed applied to trunk.

[Bug middle-end/49197] [4.7 Regression] Crash compiling arm-unknown-linux-gnueabi libgcc

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from rsandifo at gcc dot gnu.org  
2011-05-28 07:42:56 UTC ---
Same as PR49195

*** This bug has been marked as a duplicate of bug 49195 ***

[Bug bootstrap/49195] [4.7 Regression] Error building libgcc for powerpc64 since r174305

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 CC||rmansfield at qnx dot com

--- Comment #6 from rsandifo at gcc dot gnu.org  
2011-05-28 07:42:56 UTC ---
*** Bug 49197 has been marked as a duplicate of this bug. ***