[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)

[zimmerma+gcc at loria dot fr]

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

--- Comment #11 from Paul Zimmermann  2010-10-22 
06:56:20 UTC ---
(In reply to comment #10)
> You can use -fno-errno-math if you don't want errno to be set, then there will
> be no calls to sqrtf and all 3 calls should at least when optimizing evaluate
> in extended precision.

indeed with -fno-math-errno I get three identical results on a 64-bit Core 2
with gcc 4.4.4:


tarte% cat bug.c
#include 
#include 

float x=(float) 2.0;
int main() {
  printf ("%.10f\n%.10f\n%.10f\n",sqrtf(x),sqrtf(x),sqrtf(x));
  return 0;
}
tarte% gcc -mfpmath=387 bug.c -lm
tarte% ./a.out 
1.4142135382
1.4142135382
1.4142135624

tarte% gcc -mfpmath=387 -fno-math-errno bug.c -lm
tarte% ./a.out 
1.4142135624
1.4142135624
1.4142135624

However setting errno should not have side effects on the results.

Paul

[Bug c/46116] Allow passing of anonymous aggregates when signature matches

[robert.staudinger at gmail dot com]

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

--- Comment #2 from Rob Staudinger  
2010-10-22 06:04:04 UTC ---
(In reply to comment #1)
> Did you see the first warning message:
[...]

Yes and I did not like it much either, because in my book the idea of an
anonymous declaration is that it's only valid in a restricted scope.

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #25 from Jeffrey Walton  2010-10-22 
05:52:07 UTC ---
Created attachment 22112
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22112
Test for Load/Unload Crash

Attached is a test program similar to the program posted on
http://gcc.gnu.org/ml/gcc-help/2010-10/msg00272.html.

This program was modified and ignores shared objects which were known to crash
on a load/unload sequence so the audit could be completed. In total, over
***250*** libraries failed the simple load/unload test.

An alarming number of security libraries made the list. What if those security
libraries were being used by SELinux and an attacker knew he could take out the
subsystem because the development team or packager did not RTFM and observe
ODR?

I deeply and sincerely believe that software authors and packagers need GCC's
help on this. RTFM is not cutting it.

Jeffrey Walton

/usr/lib/debug/lib/libcrypto.so.0.9.8
/usr/lib/debug/lib/libssl.so.0.9.8
/usr/lib/debug/usr/lib/libcrypto++.so.8.0.0
/usr/lib/debug/usr/lib/ssl/engines/lib4758cca.so
/usr/lib/debug/usr/lib/ssl/engines/libaep.so
/usr/lib/debug/usr/lib/ssl/engines/libatalla.so
/usr/lib/debug/usr/lib/ssl/engines/libcapi.so
/usr/lib/debug/usr/lib/ssl/engines/libchil.so

[Bug target/45946] ICE: in extract_insn, at recog.c:2127 when using _Decimal128 with -Os -fno-omit-frame-pointer

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org 2010-10-22 04:56:45 UTC ---
Author: uros
Date: Fri Oct 22 04:56:41 2010
New Revision: 165801

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165801
Log:
PR target/45946
* config/i386/i386.md (*pushti2): New insn pattern.
(pushti2 splitter): New insn splitter.

testsuite/ChangeLog:

PR target/45946
* gcc.target/i386/pr45946.c: New test.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr45946.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/i386/i386.md
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/45720] [4.6 regression] Revision 164367 miscompiled SPEC CPU 2K

[vladimir.a.kharchenko at intel dot com]

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

--- Comment #6 from Vladimir Kharchenko  2010-10-22 04:28:46 UTC ---
Quick investigation of 450.soplex failure shows that Segmentation fault is in
line 966 (file factor.cc). When I recompiled this file without the option
"-ffast=math", test passed.

[Bug tree-optimization/46126] [4.6 Regression] Revision 165777 failed to build 254.gap in SPEC CPU 2K

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug tree-optimization/46126] [4.6 Regression] Revision 165777 failed to build 254.gap in SPEC CPU 2K

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2010-10-22 04:07:09 
UTC ---
[...@gnu-35 delta]$ cat pr46126.c
 typedef struct TypHeader {
 struct TypHeader * * ptr;
 unsigned char type;
 } * TypHandle;
 extern TypHandle (* EvTab[81]) ( TypHandle hd );
 TypHandle FunApplyRel ( TypHandle hdCall )
 {
 TypHandle hdApp;
 TypHandle * ptApp;
 long lp;
 long lc;
 hdApp = ((long)(((TypHandle*)((hdCall)->ptr))[1])&1 ?
(((TypHandle*)((hdCall)->ptr))[1]) : (*
EvTab[(((long)(((TypHandle*)((hdCall)->ptr))[1]) & 1) ? 1 :
TypHandle*)((hdCall)->ptr))[1])->type))])TypHandle*)((hdCall)->ptr))[1])));
 ptApp = ((TypHandle*)((hdApp)->ptr));
 ptApp[1] = ((TypHandle) (((long)(lp) << 2) + 1));
 ptApp[2] = ((TypHandle) (((long)(lc) << 2) + 1));
 }
[...@gnu-35 delta]$ /export/gnu/import/rrs/165777/usr/bin/gcc -S pr46126.c -O3
-funroll-loops -ffast-math
pr46126.c: In function \u2018FunApplyRel\u2019:
pr46126.c:6:12: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[...@gnu-35 delta]$

[Bug tree-optimization/46126] New: [4.6 Regression] Revision 165777 failed to build 254.gap in SPEC CPU 2K

[hjl.tools at gmail dot com]

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

   Summary: [4.6 Regression] Revision 165777 failed to build
254.gap in SPEC CPU 2K
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: i...@il.ibm.com


On Linux/x86-64, revision 165777:

http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00963.html

caused:

gcc -c -o costab.o   -DSPEC_CPU2000_LP64 -DSYS_IS_USG -DSYS_HAS_IOCTL_PROTO
-DSYS_HAS_TIME_PROTO -DSYS_HAS_SIGNAL_PROTO -DSYS_HAS_CALLOC_PROTO
-DSYS_HAS_READ_PROTO-O3 -funroll-loops -ffast-math   costab.c
costab.c: In function 'FunApplyRel':
costab.c:145:17: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
specmake[3]: *** [costab.o] Error 1

[Bug debug/46123] [4.5/4.6 Regression] ICE: in output_aranges, at dwarf2out.c:11531 with -feliminate-dwarf2-dups -g

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.22 02:15:03
 CC||ccoutant at gcc dot gnu.org
   Target Milestone|--- |4.5.2
Summary|ICE: in output_aranges, at  |[4.5/4.6 Regression] ICE:
   |dwarf2out.c:11531 with  |in output_aranges, at
   |-feliminate-dwarf2-dups -g  |dwarf2out.c:11531 with
   ||-feliminate-dwarf2-dups -g
 Ever Confirmed|0   |1

--- Comment #2 from H.J. Lu  2010-10-22 02:15:03 
UTC ---
It is caused by revision 151185:

http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00868.html

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #24 from Jeffrey Walton  2010-10-22 
01:59:34 UTC ---
Hi Jonathan,

(In reply to comment #16)
> (In reply to comment #13)
> > 
> > [SNIP]
> 
> There are a number of options for making sure the global is private to the
> library, thus avoiding multiple definitions of the same object when two copies
> of the code are linked to.
>
> ...
> 
> * You can put it in an anonymous namespace.
Would namespaces be via dlmopen? (I've been trying to figure out how a c++
namespace could help, but I think I went down a rabbit hole).

http://linux.die.net/include/dlfcn.h:
/* Like `dlopen', but request object to be allocated in a new namespace. */
extern void *dlmopen (Lmid_t __nsid, __const char *__file, int __mode);

Jeff

[Bug other/46125] New: -mcmodel=large doesn't work

[liwei79 at gmail dot com]

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

   Summary: -mcmodel=large doesn't work
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: liwe...@gmail.com


Hi,

I am working on huge object files and I am glad to see that gcc
supports -mcmodel=large now. However, my experiment even doesn't work
because of relocation problem in crtbeginS.o

My Source file: t.c
#include 
extern int foo(int argc, char **argv);
void *pv1[1024]={(void*)foo,};
char a[2147483658] = {1, 2 };
char b[2147483658] = {2, 3 };
void *pv2[1024]={(void*)foo,};

int foo(int argc, char **argv)
{
printf("%d", a[2147483657]);
printf("%d", b[2147483657]);
return 0;
}

Command line:
gcc -mcmodel=large -fPIC -shared t.c -o t.so

Error:
/gcc4.5.1/lib/gcc/x86_64-unknown-linux-gnu/4.5.1/crtbeginS.o: In
function `__do_global_dtors_aux':
crtstuff.c:(.text+0x3): relocation truncated to fit: R_X86_64_PC32
against `.bss'
crtstuff.c:(.text+0x37): relocation truncated to fit: R_X86_64_PC32
against `.bss'
crtstuff.c:(.text+0x57): relocation truncated to fit: R_X86_64_PC32
against `.bss'
crtstuff.c:(.text+0x62): relocation truncated to fit: R_X86_64_PC32
against `.bss'
crtstuff.c:(.text+0x6d): relocation truncated to fit: R_X86_64_PC32
against `.bss'

Could someone help me figure out the problem? I am using RH5 64bit. My gcc is
compiled with all default configuration. 

Thanks,
Wei

[Bug middle-end/45720] [4.6 regression] Revision 164367 miscompiled SPEC CPU 2K

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  2010-10-22 00:28:51 
UTC ---
With SPEC CPU 2006, revision 165771 gave me:

1. 64bit using-O3 -funroll-loops -ffast-math:

  Running 450.soplex ref peak lnx32e-gcc default

450.soplex: copy 0 non-zero return code (exit code=0, signal=11)

  Running 481.wrf ref peak lnx32e-gcc default

481.wrf: copy 0 non-zero return code (exit code=0, signal=11)

2. 32bit using -O3 -funroll-loops -msse2 -mfpmath=sse -ffast-math:  

  Running 481.wrf ref peak lnx32-gcc default

481.wrf: copy 0 non-zero return code (exit code=0, signal=11)

[Bug rtl-optimization/46114] [4.6 regression] g++ SEGV when built with gld on Solaris 10+/x86

[bernds at gcc dot gnu.org]

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

--- Comment #6 from Bernd Schmidt  2010-10-21 
23:33:47 UTC ---
I'm assuming you run the testcase on Solaris? Can you provide good/bad assembly
output?

[Bug debug/46123] ICE: in output_aranges, at dwarf2out.c:11531 with -feliminate-dwarf2-dups -g

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

Summary|ICE: in output_aranges, at  |ICE: in output_aranges, at
   |dwarf2out.c:11531 with  |dwarf2out.c:11531 with
   |-feliminate-dwarf2-dups -g  |-feliminate-dwarf2-dups -g
   |and lambda function |

--- Comment #1 from Zdenek Sojka  2010-10-21 23:27:52 
UTC ---
The same ICE happens with g++.old-deja/g++.other/mangle3.C:
$ gcc g++.old-deja/g++.other/mangle3.C -g -feliminate-dwarf2-dups
g++.old-deja/g++.other/mangle3.C:42:1: internal compiler error: in
output_aranges, at dwarf2out.c:11531
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

That testcase doesn't use lambdas, so it probably isn't lambda-specific.

[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #26 from John David Anglin  2010-10-21 
23:07:28 UTC ---
Fixed.

[Bug java/46059] internel compiler error when compiling libjava/gnu/awt/LightweightRedirector.java with -finline-functions

[baryluk at smp dot if.uj.edu.pl]

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

--- Comment #2 from Witold Baryluk  2010-10-21 
23:06:00 UTC ---
gcc 4.5.1 with the same options compiled on this machine without problems.

[Bug c++/46124] New: 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

[zsojka at seznam dot cz]

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

   Summary: 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
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


- testcase2.C -
void foo() { [] () -> void (); }
---

Compiler output:
$ gcc testcase2.C -std=c++0x
testcase2.C: In function 'void foo()':
testcase2.C:1:29: error: 'operator()' declared as function returning a function
testcase2.C:1:29: internal compiler error: tree check: expected var_decl or
function_decl, have error_mark in cp_parser_lambda_declarator_opt, at
cp/parser.c:7817
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165768 - crash
r153685 - crash
4.4 r165754 - doesn't recognise lambdas

[Bug debug/46123] New: ICE: in output_aranges, at dwarf2out.c:11531 with -feliminate-dwarf2-dups -g and lambda function

[zsojka at seznam dot cz]

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

   Summary: ICE: in output_aranges, at dwarf2out.c:11531 with
-feliminate-dwarf2-dups -g and lambda function
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 22111
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22111
reduced testcase

Compiler output (trunk):
$ gcc -feliminate-dwarf2-dups -g -std=c++0x pr46123.C 
pr46123.C:8:1: internal compiler error: in output_aranges, at dwarf2out.c:11531
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Compiler output (4.5):
$ gcc -feliminate-dwarf2-dups -g -std=c++0x pr46123.C 
pr46123.C:8:1: internal compiler error: in output_pubnames, at
dwarf2out.c:10887
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r165768 - crash
4.5 r165781 - crash
4.4 r165754 - doesn't recognise lambdas

[Bug c++/46117] [4.6 Regression] ICE: SIGSEGV in add_function_candidate (call.c:1630) on invalid typename usage

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  2010-10-21 
21:52:58 UTC ---
Fixed.

[Bug c++/46117] [4.6 Regression] ICE: SIGSEGV in add_function_candidate (call.c:1630) on invalid typename usage

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  
2010-10-21 21:51:56 UTC ---
Author: paolo
Date: Thu Oct 21 21:51:50 2010
New Revision: 165794

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165794
Log:
/cp
2010-10-21  Paolo Carlini  

PR c++/46117
* call.c (add_function_candidate): Don't use TREE_VALUE on null
parmnode.

/testsuite
2010-10-21  Paolo Carlini  

PR c++/46117
* g++.dg/parse/crash57.C: New.

Added:
trunk/gcc/testsuite/g++.dg/parse/crash57.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/46122] PROTECTED check too strict

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||domob at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2010-10-21 
21:41:52 UTC ---
Untested patch.

Daniel, what do you think? Is such a check also needed elsewhere in
gfc_check_vardef_context (e.g. for the PURE check)?

--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4400,7 +4400,7 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer,
const char* context)
 }

   /* PROTECTED and use-associated.  */
-  if (sym->attr.is_protected && sym->attr.use_assoc)
+  if (sym->attr.is_protected && sym->attr.use_assoc && check_intentin)
 {
   if (pointer && is_pointer)
{

[Bug preprocessor/46110] Precompiled headers: GCC fails to properly locate include files

[aleksey.covacevice at gmail dot com]

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

--- Comment #2 from Aleksey Covacevice  
2010-10-21 21:31:14 UTC ---
Richard, thanks for the reply.

Actually the documentation states that other preprocessor directives (such as
"#define"s) can appear before the include line that would include the PCH.
Nevertheless, that is not really the case. In fact it also states that only a
single precompiled header can be used in a particular compilation, and I think
the symptom must be somewhat related to this.

I believe this must be a bug, because even if GCC couldn't use a PCH for any
reason previously stated, it should ignore it and use the original include
file, which in this scenario it can be properly found in the search path.

Thanks again,
Alek

[Bug other/46104] Linker error "cannot find -liberty"

[mmitchel at gcc dot gnu.org]

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

Mark Mitchell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mmitchel at gcc dot gnu.org
 Resolution||INVALID

--- Comment #1 from Mark Mitchell  2010-10-21 
21:30:39 UTC ---
This is a packaging question about CodeSourcery's products; it has no relevance
to FSF GCC.

[Bug fortran/46122] New: PROTECTED check too strict

[burnus at gcc dot gnu.org]

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

   Summary: PROTECTED check too strict
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


gfortran rejects valid
  %
references, cf. "OK 3" and "OK 4" below.

The test case was created by Jared Ahern and the issue was reported to
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/6a866eb893ad8473

Note: The OK/Invalid lines are according to my understanding; no guarantee that
those are correct.


MODULE amod
   IMPLICIT NONE
   TYPE foo
  INTEGER :: i = 4
  INTEGER, POINTER :: j => NULL()
   END TYPE foo
   TYPE(foo), SAVE, PROTECTED :: a
   TYPE(foo), SAVE, PROTECTED, POINTER :: b
   INTEGER, SAVE, PROTECTED :: i = 5
   INTEGER, SAVE, PROTECTED, POINTER :: j => NULL()
contains
  subroutine alloc()
allocate(b,j)
  end subroutine alloc
END MODULE amod

PROGRAM test
   USE amod
   IMPLICIT NONE
   INTEGER, TARGET :: k
   TYPE(foo), TARGET :: c
   k = 2   ! local
   c%i = 9 ! local

   call alloc()

   ! In parentheses: compiler gives error for that line
   ! gfortran 4.6/Oct, g95 Aug 2010, NAG 5.1, ifort 11.1,
   ! pathf95 3.2.99, PGI 10.5 (compiles without error), crayftn 
   i = k! Invalid 1  (gfortran  NAG  g95  ifort  pathf95  cray)
   j => k   ! Invalid 2  (gfortran   g95  ifort  pathf95  cray)
   j = 3! OK 1   (ifort  pathf95  cray)
   a = c! Invalid 3  (gfortran  NAG  g95  ifort  pathf95  cray)
   a%i = k  ! Invalid 4  (gfortran  NAG  g95  ifort  pathf95  cray)
   a%j => k ! Invalid 5  (gfortran  NAG  g95  ifort  pathf95  cray)
   a%j = 5  ! OK 2   (   g95  ifort  pathf95  cray)
   b => c   ! Invalid 6  (gfortran   g95  ifort  pathf95  cray)
   b%i = k  ! OK 3   (gfortranifort   [bug]   cray)
   b%j => k ! OK 4   (gfortran   g95  ifort   [bug]   cray)
   b%j = 5  ! OK 5   (ifort   [bug]   cray)

END PROGRAM test

[Bug rtl-optimization/46114] [4.6 regression] g++ SEGV when built with gld on Solaris 10+/x86

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  2010-10-21 20:57:42 UTC ---
> --- Comment #4 from H.J. Lu  2010-10-21 20:41:06 
> UTC ---
> Can you try
>
> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01858.html

Doesn't make a difference unfortunately.

Thanks.
Rainer

[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  2010-10-21 
20:55:58 UTC ---
fsqrt insn is always used, and if the result is NaN, it calls library sqrtf
function so that errno is set correctly.  The (conditional) call causes (some
of) the values to be forced into stack and thus rounded to IEEE single
precision, if they aren't forced into stack, they will have long double
precision.
You can use -fno-errno-math if you don't want errno to be set, then there will
be no calls to sqrtf and all 3 calls should at least when optimizing evaluate
in extended precision.

[Bug target/45946] ICE: in extract_insn, at recog.c:2127 when using _Decimal128 with -Os -fno-omit-frame-pointer

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org 2010-10-21 20:42:13 UTC ---
Author: uros
Date: Thu Oct 21 20:42:09 2010
New Revision: 165787

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165787
Log:
PR target/45946
* config/i386/i386.md (*pushti2): New insn pattern.
(pushti2 splitter): New insn splitter.
(*push2): Macroize insn pattern from *push{di,ti}2 using
DWI mode iterator.

testsuite/ChangeLog:

PR target/45946
* gcc.target/i386/pr45946.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr45946.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md

[Bug rtl-optimization/46114] [4.6 regression] g++ SEGV when built with gld on Solaris 10+/x86

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #4 from H.J. Lu  2010-10-21 20:41:06 
UTC ---
Can you try

http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01858.html

[Bug rtl-optimization/46114] [4.6 regression] g++ SEGV when built with gld on Solaris 10+/x86

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.21 20:36:21
 Ever Confirmed|0   |1

--- Comment #3 from Rainer Orth  2010-10-21 20:36:21 UTC 
---
I could reproduce the bug with the attached testcase (go.c with main,
pr46114.c reduced from g++spec.c).

Compile with

% gcc -O2 -o go go.c pr46114.c

After the culprit patch, the program prints

opt_index = 902 arg = 8049253 value = 1 lang_mask = 65536 decoded = 1
opt_index = 902 arg = 8049264 value = 1 lang_mask = 65536 decoded = 804a90c
opt_index = 1019 arg = 0 value = 1 lang_mask = 65536 decoded = 804a938

i.e. decoded (a pointer) is invalid.  Before, one gets

opt_index = 902 arg = 8049273 value = 1 lang_mask = 65536 decoded = 804a900
opt_index = 902 arg = 8049284 value = 1 lang_mask = 65536 decoded = 804a92c
opt_index = 1019 arg = 0 value = 1 lang_mask = 65536 decoded = 804a958

The bug is extremely sensitive to the details of the input, so I didn't try
to reduce it further.

Please fix, this is really ugly and makes gcc with gld completely useless.

[Bug rtl-optimization/46114] [4.6 regression] g++ SEGV when built with gld on Solaris 10+/x86

[ro at gcc dot gnu.org]

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

--- Comment #2 from Rainer Orth  2010-10-21 20:32:47 UTC 
---
Created attachment 22110
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22110
miscompiled part of the test

[Bug rtl-optimization/46114] [4.6 regression] g++ SEGV when built with gld on Solaris 10+/x86

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  2010-10-21 20:31:57 UTC 
---
Created attachment 22109
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22109
main program of testcase

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #23 from Jeffrey Walton  2010-10-21 
19:52:12 UTC ---
Hi Jonathan,

[Sorry about the top post].

I'm going to wrap up my request, and hope you and the GCC team will find that
-Wglobal-variable would be useful under some circumstances.

When you and the team examine the merits of the request, remember that we [the
dumb users] probably did not know about the finer details of the interactions
between shared objects, global objects with destructors (is this c++
specific?), multiple processes, RTLD_GLOBAL, the ABI, and ODR. If we were
aware, we probably would not have made the mistake in the first place.



The GCC team is probably tired of seeing questions about this issue. So a
warning to reduce list chatter might be warranted.



Your points about when the warning should be issued are valid. But the warning
would be incredibly useful when a "perfect storm" rises (interactions between
shared objects, global objects with destructors, multiple processes,
RTLD_GLOBAL, the ABI, and ODR.).

I feel history has shown that users and distribution packagers have gotten it
wrong too often and too easily.



RTFM is great, but I can't help but feel, "what manual should I read" since
searching for "shared object crash" and "SO crash" returned the phone book with
no real useful information.

Once you pointed out the missing references and pieces, everything fell into
place (and I will never make the mistakes again).



Wei Dai only provided a static archive of Crypto++. The library was being
packaged as a shared object by distributions because of a rule somewhere that
that required a system provided library.

The first sign of an issue for Crypto++ was a mailing list post titled, "Errors
with multiple loading cryptopp as shared lib on Linux". So Crypto++ was
actually collateral damage.



The next project to get pinged was Tahoe Least-Authoritative File System (Tahoe
LAFS), which used Crypto++. Zooko Wilcox-O'Hearn, one of the project's leads,
build bot alerted him of the issue. So Tahoe LAFS was also collateral damage.

===

Finally, crashes due to this issue degrade the user experience, so the user is
the ultimate loser (and not just collateral damage).

Jeffrey Walton
Baltimore, MD, US

==

(In reply to comment #0)
> Feature reqeust only. Not a bug.
> 
> C++ shared objects are an interesting beast under certain circumstances (many
> times, the shared object acts like a generic C module). Interesting includes:
> * C++ module
> * Shared object
> * Shared object throws an exception which will cross module boundaries
> * Shared object opened with RTLD_GLOBAL
> * Shared object has global objects with destructors
> 
> Lots have been said about C++ exceptions, RTTI, type equality for the
> 'catch(const Exception&)', and RTLD_GLOBAL (versus RTLD_LOCAL) [1,2,3,4,5].
> 
> When a module meets the above compile and runtime requirements, a crash can
> occur in global objects with destructors when more than one process loads and
> subsequently unloads a shared object.
> 
> A switch to warn of global variables in a compilation unit would be very
> helpful for those who are aware of the issue (and the circumstances to
> encounter the issue). It appears that GCC does not supply such a switch [6].
> 
> The switch would be useful for module writers since its not always feasible to
> 'hand audit' all project files. And a warning would be exetremely useful for
> package maintainers who don't write the module - they simply fixup the code 
> and
> package it for a distribution.
> 
> Perhaps -Wglobal-variable?
> 
> Jeffrey Walton
> Baltimore, MD, US
> 
> [1] Minimal GCC/Linux shared lib + EH bug example,
> http://gcc.gnu.org/ml/gcc/2002-05/msg00866.html
> [2] dlopen and placing exception body in .cpp file,
> http://gcc.gnu.org/ml/gcc-help/2010-08/msg00290.html
> [3] Comparing types across SOs (sic),
> http://groups.google.com/group/cryptopp-users/browse_thread/thread/eb815f228db50380
> [4] Errors with multiple loading cryptopp as shared lib on Linux,
> http://groups.google.com/group/cryptopp-users/browse_thread/thread/68fbc22e8c6e2f48
> [5] RTLD_GLOBAL and libcryptopp.so crash,
> http://groups.google.com/group/cryptopp-users/browse_thread/thread/7eae009a4e02e726
> [6] Audit Use of Global Variables in C++ Shared Object (GCC Warning?), 
> GCC-Help
> mailing list, October, 2010 [not yet indexed].

[Bug rtl-optimization/45966] Incorrect combiner transformation.

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from Bernd Schmidt  2010-10-21 
19:38:31 UTC ---
Fixed.

[Bug bootstrap/46121] New: [4.6 regression] LTO bootstrap failed

[hjl.tools at gmail dot com]

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

   Summary: [4.6 regression] LTO bootstrap failed
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 165780 failed to bootstrap with LTO:

http://gcc.gnu.org/ml/gcc-regression/2010-10/msg00249.html

Revision 165748 is OK.

[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)

[zimmerma+gcc at loria dot fr]

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

--- Comment #9 from Paul Zimmermann  2010-10-21 
19:26:11 UTC ---
(In reply to comment #8)

> You really should use hex float to see the diferences.  I bet it is just the
> final digit of the hex float that is different and only by one.  This is
> actually ok IIRC.

see comment 5. (Moreover the sqrt function must return correct rounding
according
to IEEE 754, thus even a difference of 1 ulp is *not* ok.)

Paul Zimmermann

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[pinskia at gcc dot gnu.org]

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

--- Comment #22 from Andrew Pinski  2010-10-21 
18:54:26 UTC ---
(In reply to comment #20)
> I'd forgotten the search was even there - I might suggest removing it, since
> it's apparently not indexed anything this month, and probably much longer

The search issue was just fixed.

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #21 from Jeffrey Walton  2010-10-21 
18:49:49 UTC ---
(In reply to comment #19)
> Oh, I never use the search, it's always been useless
> 
> just click on the first month in the list,
> http://gcc.gnu.org/ml/gcc-help/2010-10/ shows the messages in date order, they
> appear almost immediately

:)

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  2010-10-21 
18:47:03 UTC ---
I'd forgotten the search was even there - I might suggest removing it, since
it's apparently not indexed anything this month, and probably much longer

[Bug bootstrap/46018] [4.6 Regression] Bootstrap fails on i386-pc-solaris2.10

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  2010-10-21 18:42:22 
UTC ---
Can you try

http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01858.html

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[redi at gcc dot gnu.org]

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

--- Comment #19 from Jonathan Wakely  2010-10-21 
18:41:20 UTC ---
Oh, I never use the search, it's always been useless

just click on the first month in the list,
http://gcc.gnu.org/ml/gcc-help/2010-10/ shows the messages in date order, they
appear almost immediately

[Bug driver/46113] collect2.exe not passing through @FILE response argument to linker

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andrew Pinski  2010-10-21 
18:39:49 UTC ---
See PR 45749 for more on this issue.

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

[Bug driver/45749] Response file unwrapped between collect2.exe and ld.exe

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ben.combrink at gmail dot
   ||com

--- Comment #10 from Andrew Pinski  2010-10-21 
18:39:49 UTC ---
*** Bug 46113 has been marked as a duplicate of this bug. ***

[Bug c/46115] Feature request: anonymous functions (complementing anon aggregates)

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2010-10-21 
18:38:31 UTC ---
This sounds like C++ lambda functions.

Second,  I think this is a bad idea for C.

[Bug c/46116] Allow passing of anonymous aggregates when signature matches

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|minor   |enhancement

--- Comment #1 from Andrew Pinski  2010-10-21 
18:36:28 UTC ---
Did you see the first warning message:
t.c:6:11: warning: anonymous struct declared inside parameter list [enabled by
default]
t.c:6:11: warning: its scope is only this definition or declaration, which is
probably not what you want [enabled by default]

[Bug middle-end/46120] [4.6 regression] g++.dg/ipa/ivinline-?.C

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC|mjambor at suse dot cz  |jamborm at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jamborm at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from Martin Jambor  2010-10-21 
18:03:10 UTC ---
Hm... mine.

[Bug middle-end/46120] [4.6 regression] g++.dg/ipa/ivinline-?.C

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||mjambor at suse dot cz
   Target Milestone|--- |4.6.0

--- Comment #1 from H.J. Lu  2010-10-21 17:50:46 
UTC ---
It is caused by revision 165780:

http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00966.html

[Bug rtl-optimization/45865] [4.6 Regression] ifcvt/crossjump failed to mark return jump

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2010-10/msg01858.htm
   ||l

--- Comment #12 from H.J. Lu  2010-10-21 17:47:33 
UTC ---
A patch is posed at

http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01858.html

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #18 from Jeffrey Walton  2010-10-21 
17:37:15 UTC ---
(In reply to comment #13)
> Hi Jonathon,
> 
> (In reply to comment #10)
> > you realise you can wait and it will show up?
> > http://gcc.gnu.org/ml/gcc-help/2010-10/msg00248.html
> I've been known to be impatient at times :/
Slightly off topic, but spot on for my impatience. Before I submitted this
request, I sent an email to the gcc-help list titled, "Audit Use of Global
Variables in C++ Shared Object (GCC Warning?)"

Three days later and no search results from http://gcc.gnu.org/ml/gcc-help/. It
begs the question, what interface/web page are you using to retrieve archived
messages so quickly?

(To duplicate my results, paste the title into the search box and click search.
Don't use quotes).

[Bug c++/46024] g++.dg/warn/miss-format-1.C FAILs on Solaris 8 and 9

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.4.6, 4.5.2, 4.6.0
 Resolution||FIXED
   Target Milestone|--- |4.4.6

--- Comment #5 from Rainer Orth  2010-10-21 17:26:16 UTC 
---
Fixed for 4.4.6, 4.5.2, 4.6.0.

[Bug c++/46024] g++.dg/warn/miss-format-1.C FAILs on Solaris 8 and 9

[ro at gcc dot gnu.org]

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

--- Comment #4 from Rainer Orth  2010-10-21 17:23:29 UTC 
---
Author: ro
Date: Thu Oct 21 17:23:24 2010
New Revision: 165783

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165783
Log:
fixincludes:
Backport from mainline:
2010-10-20  Rainer Orth  

PR c++/46024
* inclhack.def (solaris_sys_va_list): New fix.
* fixincl.x: Regenerate.
* tests/base/sys/va_list.h: New test.

gcc/testsuite:
Backport from mainline:
2010-10-20  Rainer Orth  

PR c++/46024
* g++.dg/warn/miss-format-1.C: Enclose dg-error target list in braces.

2010-08-04  Daniel Gutson  

* g++.dg/warn/miss-format-1.C: Update line number.

2010-05-03  Rainer Orth  

* g++.dg/warn/miss-format-1.C (bar): xfail dg-warning on
alpha*-dec-osf*.

Added:
branches/gcc-4_4-branch/fixincludes/tests/base/sys/va_list.h
Modified:
branches/gcc-4_4-branch/fixincludes/ChangeLog
branches/gcc-4_4-branch/fixincludes/fixincl.x
branches/gcc-4_4-branch/fixincludes/inclhack.def
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/warn/miss-format-1.C

[Bug c++/46024] g++.dg/warn/miss-format-1.C FAILs on Solaris 8 and 9

[ro at gcc dot gnu.org]

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

--- Comment #3 from Rainer Orth  2010-10-21 17:13:34 UTC 
---
Author: ro
Date: Thu Oct 21 17:13:25 2010
New Revision: 165782

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165782
Log:
fixincludes:
Backport from mainline:
2010-10-20  Rainer Orth  

PR c++/46024
* inclhack.def (solaris_sys_va_list): New fix.
* fixincl.x: Regenerate.
* tests/base/sys/va_list.h: New test.

gcc/testsuite:
Backport from mainline:
2010-10-20  Rainer Orth  

PR c++/46024
* g++.dg/warn/miss-format-1.C: Enclose dg-error target list in braces.

2010-08-04  Daniel Gutson  

* g++.dg/warn/miss-format-1.C: Update line number.

2010-05-03  Rainer Orth  

* g++.dg/warn/miss-format-1.C (bar): xfail dg-warning on
alpha*-dec-osf*.

Added:
branches/gcc-4_5-branch/fixincludes/tests/base/sys/va_list.h
Modified:
branches/gcc-4_5-branch/fixincludes/ChangeLog
branches/gcc-4_5-branch/fixincludes/fixincl.x
branches/gcc-4_5-branch/fixincludes/inclhack.def
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/warn/miss-format-1.C

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #17 from Jeffrey Walton  2010-10-21 
16:59:55 UTC ---
(In reply to comment #16)
> (In reply to comment #13)
> > 
> > Good point: here's what I would recommend: common sense. Myself, Alexey, a
> > number of packagers across the globe, and untold others have performed this 
> > ODR
> > violation. Since you know more about the subject matter than me (I would 
> > like
> > to think of you as a SME - subject matter expert), what would you recommend 
> > so
> > that folks like myself, Alexey, distribution packagers, and others don't go
> > shooting ourselves in the foot?
> 
> There are a number of options for making sure the global is private to the
> library, thus avoiding multiple definitions of the same object when two copies
> of the code are linked to.
> 
> * You can make the global object have static linkage.
> 
> * You can put it in an anonymous namespace.
> 
> * You can give it non-global visibility.
For completeness, Crypto++ used:

GlobalVariable& GetGlobalVariable()
{
static GlobalVariable globalVariable;
return globalVariabl
}

And Vladimir Simonov recommended
(http://gcc.gnu.org/ml/gcc-help/2010-10/msg00256.html):
-fvisibility=hidden

Lots of good mechanisms. Unfortunately, it's not readily apparent when they
need to be used by whom. I think GCC could be of great assistance to the
average developer and packager.

You (and most likely other folks at GCC) clearly understand the problem. Can
you help us with a reasonable warning to 'save us from ourselves'? After all, a
warning can be turned of or ignored. But if a warning does not exist, it does
not help at all :/

Jeff

[Bug c++/46117] [4.6 Regression] ICE: SIGSEGV in add_function_candidate (call.c:1630) on invalid typename usage

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|paolo.carlini at oracle dot |
   |com |
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #2 from Paolo Carlini  2010-10-21 
16:58:26 UTC ---
I have a patch.

[Bug middle-end/46120] New: [4.6 regression] g++.dg/ipa/ivinline-?.C

[hjl.tools at gmail dot com]

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

   Summary: [4.6 regression] g++.dg/ipa/ivinline-?.C
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/ia32, revision 165780 gave

FAIL: g++.dg/ipa/ivinline-1.C scan-ipa-dump inline "B::foo[^\n]*inline copy in
int main"
FAIL: g++.dg/ipa/ivinline-2.C scan-ipa-dump inline "B::foo[^\n]*inline copy in
int main"
FAIL: g++.dg/ipa/ivinline-3.C scan-ipa-dump inline "B::foo[^\n]*inline copy in
int main"
FAIL: g++.dg/ipa/ivinline-4.C scan-ipa-dump inline "B::foo[^\n]*inline copy in
int main"
FAIL: g++.dg/ipa/ivinline-5.C scan-ipa-dump inline "B::foo[^\n]*inline copy in
int main"
FAIL: g++.dg/ipa/ivinline-6.C scan-ipa-dump inline "B::foo[^\n]*inline copy in
int main"
FAIL: g++.dg/ipa/ivinline-8.C scan-ipa-dump inline "B::bar[^\n]*inline copy in
int main"
FAIL: g++.dg/ipa/ivinline-8.C scan-ipa-dump inline "B::foo[^\n]*inline copy in
int main"


Revision 165771 is OK.

[Bug middle-end/45720] [4.6 regression] Revision 164367 miscompiled SPEC CPU 2K

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  2010-10-21 16:28:24 
UTC ---
As of revision 165771, I still got

With runspec -c lnx-i686-gcc.cfg -n 1 -l -o asc -I all -T peak

*** Miscompare of ref.out, see
/export/gnu/import/svn/gcc-test/spec/2000/i686/spec/benchspec/CINT2000/254.gap/run/0002/ref.out.mis

Error: 1x254.gap

With runspec -c lnx-x86_64-gcc.cfg -n 1 -l -o asc -I all -T peak

*** Miscompare of crafty.out, see
/export/gnu/import/svn/gcc-test/spec/2000/x86_64/spec/benchspec/CINT2000/186.crafty/run/0002/crafty.out.mis

*** Miscompare of inp.out, see
/export/gnu/import/svn/gcc-test/spec/2000/x86_64/spec/benchspec/CFP2000/200.sixtrack/run/0002/inp.out.mis

Error: 1x186.crafty 1x200.sixtrack

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  2010-10-21 
16:24:18 UTC ---
(In reply to comment #13)
> 
> Good point: here's what I would recommend: common sense. Myself, Alexey, a
> number of packagers across the globe, and untold others have performed this 
> ODR
> violation. Since you know more about the subject matter than me (I would like
> to think of you as a SME - subject matter expert), what would you recommend so
> that folks like myself, Alexey, distribution packagers, and others don't go
> shooting ourselves in the foot?

There are a number of options for making sure the global is private to the
library, thus avoiding multiple definitions of the same object when two copies
of the code are linked to.

* You can make the global object have static linkage.

* You can put it in an anonymous namespace.

* You can give it non-global visibility.


(In reply to comment #15)
> (In reply to comment #11)
> > also, I'm not "the GCC team" and I don't speak for anyone else
> 
> My apologies. I made the leap that you were part of the team due to your email
> address.

This is Free Software, I'm just one contributor among many, I don't speak for
"the team"

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #15 from Jeffrey Walton  2010-10-21 
16:15:38 UTC ---
(In reply to comment #11)
> also, I'm not "the GCC team" and I don't speak for anyone else

My apologies. I made the leap that you were part of the team due to your email
address.

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #14 from Jeffrey Walton  2010-10-21 
16:13:36 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > Hi Johnathon,
> > (In reply to comment #5)
> > > oh, and I only see one process invovled there ... I'm still confused 
> > > about the
> > > claim that more than one process is involved...
> > My bad - the image only depicts one process. However, the first thing main()
> > does is a fork to get two processes in play.
> 
> [SNIP]
> 
> I'm probably taking this enhancement request wy off-topic, I just want to
> convince myself you're not wasting time asking for a warning that won't help
> prevent user error

I don't believe this is way of topic considering the number of folks who seem
to have a need for the assistance from GCC (including packagers/maintainers).
See comment 13 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097#c13).

Jeff

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #13 from Jeffrey Walton  2010-10-21 
16:10:41 UTC ---
Hi Jonathon,

(In reply to comment #10)
> you realise you can wait and it will show up?
> http://gcc.gnu.org/ml/gcc-help/2010-10/msg00248.html
I've been known to be impatient at times :/

> That, like your case, is an ODR violation, and like your example static.cpp 
> was
> not compiled with -fPIC
Ah! I was not aware I was violating anything :/ And the packagers were probably
not aware they were violating anything (but I can't speak for them).

> In response to your reply to him, I really don't think a warning about global
> variables is suitable for -Wall!
Agreed.

> could you be a bit less vague about what exactly you want the warning to do?
> 
> should it only warn about globally visible objects in shared libraries?
> that wouldn't help that case, where the problematic global is in static.o,
> which isn't compiled with -fPIC or -shared, so the warning would have to come
> from the linker when static.o is linked to dynamic1.o or dynamic2.o

Good point: here's what I would recommend: common sense. Myself, Alexey, a
number of packagers across the globe, and untold others have performed this ODR
violation. Since you know more about the subject matter than me (I would like
to think of you as a SME - subject matter expert), what would you recommend so
that folks like myself, Alexey, distribution packagers, and others don't go
shooting ourselves in the foot?

[Bug middle-end/46119] New: -fsplit-stack -fstack-protector-all - code crashes when passing large struct via stack

[zsojka at seznam dot cz]

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

   Summary: -fsplit-stack -fstack-protector-all - code crashes
when passing large struct via stack
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 22108
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22108
reduced testcase

Output:
$ gcc -fsplit-stack -fstack-protector-all pr46119.c
$ ./a.out 
Segmentation fault

Tested revisions:
r165768 - fail

[Bug fortran/45319] [4.5 Regression] FAIL: libgomp.fortran/vla4.f90

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from John David Anglin  2010-10-21 
15:53:25 UTC ---
I agree.

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  2010-10-21 
15:28:05 UTC ---
I'm not on gcc-help, but I assume Alexey's looking at this report now ...

> I would expect that TWO different instances of the global variable would
> be created in TWO different shared libraries - maybe with name mangling.

No, the compiler can't just add random mangling to symbols, that would mean the
linker can't find symbols!

If you want those objects to be distinct, put them in distinct namespaces
(possibly anonymous namespaces) to disambiguate them, as mentioned at
http://gcc.gnu.org/faq.html#dso
Otherwise you have an ODR violation due to two definitions of the same object.

[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

--- Comment #8 from Richard Guenther  2010-10-21 
15:28:01 UTC ---
Created attachment 22107
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22107
patch

Bootstrapped, tested and SPEC CPU 2006 tested.

I don't like it too much (it's really a FE hack we put in place that haunts
us now ...).

Deferred installing to stage3 or later (--enable-checking=release will
get you an equivalent solution).

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  2010-10-21 
15:22:03 UTC ---
also, I'm not "the GCC team" and I don't speak for anyone else

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2010-10-21 
15:16:48 UTC ---
you realise you can wait and it will show up?
http://gcc.gnu.org/ml/gcc-help/2010-10/msg00248.html
That, like your case, is an ODR violation, and like your example static.cpp was
not compiled with -fPIC

In response to your reply to him, I really don't think a warning about global
variables is suitable for -Wall!

could you be a bit less vague about what exactly you want the warning to do?

should it only warn about globally visible objects in shared libraries?
that wouldn't help that case, where the problematic global is in static.o,
which isn't compiled with -fPIC or -shared, so the warning would have to come
from the linker when static.o is linked to dynamic1.o or dynamic2.o

[Bug c/45834] Redundant inter-loop edges in DDG

[meibf at gcc dot gnu.org]

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

--- Comment #8 from meibf at gcc dot gnu.org 2010-10-21 15:16:05 UTC ---
Author: meibf
Date: Thu Oct 21 15:16:01 2010
New Revision: 165781

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165781
Log:
2010-10-21  Bingfeng Mei  

PR c/45834
* alias.c (true_dependence_1): Remove obsolete check for QImode.
(may_alias_p): Ditto.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/alias.c

[Bug c++/46097] Switch to warn of global variables in a C++ shared object

[noloader at gmail dot com]

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

--- Comment #9 from Jeffrey Walton  2010-10-21 
15:04:44 UTC ---
(In reply to comment #4)
> I had a look at Cryptopp-SO-Test-1.zip
> 
> building on 32-bit I can reproduce a segfault
> 
> it doesn't build on 64-bit at all:
> 
> 1) you can insert a pointer into an ostream without casting to int (and if you
> insist on casting, do it to a type that has the same size as a pointer!)
> 
> 2) that makefile doesn't compile dsotest-1.o and dsotest-2.o with -fPIC
> 
> To get it build I had to edit the code and the makefile, and after doing so it
> doesn't crash. And with the same changes, it doesn't crash on 32-bit either.
> 
> So are you sure this isn't just user error?
> 
> I can see some value in the warning you want, but it's not going to help if 
> you
> don't use the compiler correctly (maybe I'm being unfair and you're using it
> correctly for 32-bit, but my first instinct is that if it fails to build for a
> different target then *something* is wrong!)
Another person just got bit by the C++ global/shared object bug. See "Global
variable in static library - double free or corruption error" by Alexey
Skidanov. It so 'fresh' that it has not been indexed yet - so I can't provide a
link.

[Bug tree-optimization/45875] [4.6 Regression] ice in gimple_fold_obj_type_ref_known_binfo with -O2

[jamborm at gcc dot gnu.org]

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

--- Comment #14 from Martin Jambor  2010-10-21 
14:35:05 UTC ---
Author: jamborm
Date: Thu Oct 21 14:34:58 2010
New Revision: 165780

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165780
Log:
2010-10-21  Martin Jambor  

PR tree-optimization/45875
* tree.c (get_binfo_at_offset): Remove initial zero offset test.

* testsuite/g++.dg/ipa/pr45875.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr45875.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug target/46098] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2100 with -msse3 -ffloat-store and __builtin_ia32_loadupd()

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #2 from Michael Matz  2010-10-21 14:33:15 
UTC ---
Well, that's a problem of the target.  The pattern that is supposed to match
is:

(define_insn "_movu"
  [(set (match_operand:SSEMODEF2P 0 "nonimmediate_operand" "=x,m")
(unspec:SSEMODEF2P
  [(match_operand:SSEMODEF2P 1 "nonimmediate_operand" "xm,x")]
  UNSPEC_MOVU))]
  "SSE_VEC_FLOAT_MODE_P (mode)
   && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
  ...

So, the predicates are nonimmediate_operand for both.  The additional
matching condition is that not both arguments are memory.  They are here,
hence nothing matches.  But if this is the only pattern that could match
the RTL code then the builtin expander has the obligation to create patterns
that are matchable.  But that's not what ix86_expand_special_args_builtin is
doing here.

In particular it detects that nargs=1, klass=load, memory=0.  That means the
first (and only) argument has to be memory.  Nothing is said about the target.
The routine then proceeds to not change the target, because:

  if (klass == store)
...
  else
{
  arg_adjust = 0;
  if (optimize
  || target == 0
  || GET_MODE (target) != tmode
  || !insn_p->operand[0].predicate (target, tmode))
target = gen_reg_rtx (tmode);
}

target is
  (mem/c/i:V2DF (plus:DI (reg/f:DI 54 virtual-stack-vars)
(const_int -16 [0xfff0])) [0 D.2706+0 S16 A128])
The target _does_ match the predicate, hence no change occurs.
Furthermore in the loop over arguments:

  for (i = 0; i < nargs; i++)
{
  if (last_arg_constant && (i + 1) == nargs)
...
  else
{
  if (i == memory)
{
  /* This must be the memory operand.  */
  op = gen_rtx_MEM (mode, copy_to_mode_reg (Pmode, op));
  gcc_assert (GET_MODE (op) == mode
  || GET_MODE (op) == VOIDmode);
}
  ...
}

Here we would explicitely construct a memory argument, even if it isn't
already, irrespective if the predicate matches or not.  Hence, no
matter what this does it will end up with a pattern where target and
argument are both MEM.  This is never matchable --> boom.

I don't know enough about the intention of the ix86_builtin expanders
to suggest where to fix this.  One alternative seems to be to adjust
the pattern to only accept register_operand in the destination (which also
means removing one alternative and the matching condition).

Another alternative would be only removing the !(MEM && MEM) part of the
matching condition, because reload will fix up the non-matching constraints.

The third alternative would be to fix ix86_expand_special_args_builtin to
emit the correct patterns from the start.

Whatever is done, it probably also needs to be done for some other patterns.

FWIW the second alternative would look like so:
Index: config/i386/sse.md
===
--- config/i386/sse.md  (revision 165503)
+++ config/i386/sse.md  (working copy)
@@ -412,8 +412,7 @@ (define_insn "_movu"
(unspec:SSEMODEF2P
  [(match_operand:SSEMODEF2P 1 "nonimmediate_operand" "xm,x")]
  UNSPEC_MOVU))]
-  "SSE_VEC_FLOAT_MODE_P (mode)
-   && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
+  "SSE_VEC_FLOAT_MODE_P (mode)"
   "movu\t{%1, %0|%0, %1}"
   [(set_attr "type" "ssemov")
(set_attr "movu" "1")

and fixes the bug.

[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 #21 from Tobias Burnus  2010-10-21 
14:04:12 UTC ---
(In reply to comment #20)
> I fail to reproduce the ICE with today's r165769. Hans, are you still getting
> this error?

Frankly, I already got lost in comment 12 with regards to which version shows
the bug and which doesn't.

In light of comment 15 (cf. excerpt below) and given that there was no useful
output with valgrind, I would suggest to close this PR as WORKSFORME. If the
error re-appears, one can open a new PR. Hans, would it be OK to close the bug?

(In reply to comment #15)
> Revision 20100928 compiles my code, so it's fine for me now. But I have got
> huge tables of use statements in my modules and I continue to get this error
> message, when I forget to explicitly "use" the whole tree of modules.
> 
> It also might has been a coincidence that the error disappeared when I renamed
> kind.f90 to kinds.f03. I did the same for 20100928, and it didn't work. But
> mentioning all modules works for 20100928.

[Bug debug/46118] New: g++.dg/torture/pr46111.C: -fcompare-debug failure

[zsojka at seznam dot cz]

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

   Summary: g++.dg/torture/pr46111.C: -fcompare-debug failure
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


As Richard mentioned in PR46111 comment #1, the testcase fails with
-fcompare-debug:

$ gcc -O -ftree-parallelize-loops=2 pr46111.C -fcompare-debug
gcc: error: pr46111.C: -fcompare-debug failure

Testcase is the same as for PR46111:
http://gcc.gnu.org/bugzilla/attachment.cgi?id=22103

Tested revisions:
r165768 - fail
4.5.1 - fail

[Bug c++/46117] [4.6 Regression] ICE: SIGSEGV in add_function_candidate (call.c:1630) on invalid typename usage

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #1 from Paolo Carlini  2010-10-21 
14:01:22 UTC ---
parmnode becomes null, and setting viable = 0 in that case too, appears to
avoid the Segmentation fault.

[Bug tree-optimization/46052] [4.6 Regression] ICE: in emit_move_insn, at expr.c:3386 with -ftree-vectorize

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||irar at il dot ibm.com
 Resolution||FIXED

--- Comment #3 from Ira Rosen  2010-10-21 13:45:59 UTC 
---
Fixed.

[Bug tree-optimization/46049] [4.6 Regression] ICE: in expand_widen_pattern_expr, at optabs.c:522 with -ftree-vectorize

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Ira Rosen  2010-10-21 13:44:32 UTC 
---
Fixed.

[Bug c++/46117] [4.6 Regression] ICE: SIGSEGV in add_function_candidate (call.c:1630) on invalid typename usage

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2010.10.21 13:44:05
 Ever Confirmed|0   |1

[Bug tree-optimization/46052] [4.6 Regression] ICE: in emit_move_insn, at expr.c:3386 with -ftree-vectorize

[irar at gcc dot gnu.org]

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

--- Comment #2 from irar at gcc dot gnu.org 2010-10-21 13:37:05 UTC ---
Author: irar
Date: Thu Oct 21 13:36:56 2010
New Revision: 165777

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

PR tree-optimization/46049
PR tree-optimization/46052
* tree-vectorizer.h (enum stmt_vec_info_type): Add new value for
shift.
(vect_get_slp_defs): Add arguments.
* tree-vect-loop.c (vect_create_epilog_for_reduction): Pass scalar
operands to vect_get_slp_defs.
(vectorizable_reduction): Fix comment, pass scalar operands to
vect_get_slp_defs.
* tree-vect-stmts.c (vect_get_vec_def_for_operand): Use operand's
type to determine number of units in the created vector.
(vect_get_vec_defs): Pass scalar operands to vect_get_slp_defs.
(vectorizable_conversion): Fix comment.
(vectorizable_shift): New function.
(vectorizable_operation): Move code that handles shifts to
vectorizable_shift.
(vectorizable_type_demotion): Fix comment, pass scalar operands to
vect_get_slp_defs.
(vectorizable_type_promotion, vectorizable_store): Likewise.
(vectorizable_condition): Fix comment.
(vect_analyze_stmt): Call vectorizable_shift.
(vect_transform_stmt): Likewise.
* tree-vect-slp.c (vect_get_constant_vectors): Add new argument.
Use it as the operand to create vectors for, except reduction
initial definition and store.  Use operands type.
(vect_get_slp_defs): Add new arguments.  Pass them to
vect_get_constant_vectors.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr46049.c
trunk/gcc/testsuite/gcc.dg/vect/pr46052.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-slp.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree-vectorizer.h

[Bug tree-optimization/46049] [4.6 Regression] ICE: in expand_widen_pattern_expr, at optabs.c:522 with -ftree-vectorize

[irar at gcc dot gnu.org]

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

--- Comment #2 from irar at gcc dot gnu.org 2010-10-21 13:37:07 UTC ---
Author: irar
Date: Thu Oct 21 13:36:56 2010
New Revision: 165777

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

PR tree-optimization/46049
PR tree-optimization/46052
* tree-vectorizer.h (enum stmt_vec_info_type): Add new value for
shift.
(vect_get_slp_defs): Add arguments.
* tree-vect-loop.c (vect_create_epilog_for_reduction): Pass scalar
operands to vect_get_slp_defs.
(vectorizable_reduction): Fix comment, pass scalar operands to
vect_get_slp_defs.
* tree-vect-stmts.c (vect_get_vec_def_for_operand): Use operand's
type to determine number of units in the created vector.
(vect_get_vec_defs): Pass scalar operands to vect_get_slp_defs.
(vectorizable_conversion): Fix comment.
(vectorizable_shift): New function.
(vectorizable_operation): Move code that handles shifts to
vectorizable_shift.
(vectorizable_type_demotion): Fix comment, pass scalar operands to
vect_get_slp_defs.
(vectorizable_type_promotion, vectorizable_store): Likewise.
(vectorizable_condition): Fix comment.
(vect_analyze_stmt): Call vectorizable_shift.
(vect_transform_stmt): Likewise.
* tree-vect-slp.c (vect_get_constant_vectors): Add new argument.
Use it as the operand to create vectors for, except reduction
initial definition and store.  Use operands type.
(vect_get_slp_defs): Add new arguments.  Pass them to
vect_get_constant_vectors.


Added:
trunk/gcc/testsuite/gcc.dg/vect/pr46049.c
trunk/gcc/testsuite/gcc.dg/vect/pr46052.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree-vect-slp.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree-vectorizer.h

[Bug tree-optimization/45875] [4.6 Regression] ice in gimple_fold_obj_type_ref_known_binfo with -O2

[jamborm at gcc dot gnu.org]

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

--- Comment #13 from Martin Jambor  2010-10-21 
13:06:20 UTC ---
I have just posted a patch fixing the original issue reported in this
bug to the mailing list:

http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01822.html

[Bug fortran/46007] wrong code for SHAPE in a scalarized loop

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Thomas Koenig  2010-10-21 
13:05:55 UTC ---
Fixed on trunk and 4.5.  Closing.

[Bug fortran/46007] wrong code for SHAPE in a scalarized loop

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  2010-10-21 
13:02:15 UTC ---
Author: tkoenig
Date: Thu Oct 21 13:02:09 2010
New Revision: 165773

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165773
Log:
2010-10-21  Thomas Koenig  

PR fortran/46007
Backport from trunk
* m4/shape.m4 (shape_'rtype_kind`):  Use variable for rank.
Allocate return array if unallocated.
* generated/shape_i4.c:  Regenerated.
* generated/shape_i8.c:  Regenerated.
* generated/shape_i16.c:  Regenerated.

2010-10-21  Thomas Koenig  

PR fortran/46007
Backport from trunk
* gfortran.dg/shape_5.f90:  New test case.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/shape_5.f90
Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/libgfortran/ChangeLog
branches/gcc-4_5-branch/libgfortran/generated/shape_i16.c
branches/gcc-4_5-branch/libgfortran/generated/shape_i4.c
branches/gcc-4_5-branch/libgfortran/generated/shape_i8.c
branches/gcc-4_5-branch/libgfortran/m4/shape.m4

[Bug fortran/45319] [4.5 Regression] FAIL: libgomp.fortran/vla4.f90

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #3 from Tobias Burnus  2010-10-21 
12:57:16 UTC ---
*ping*

(In reply to comment #2)
> Does this still occur?

I tried to find those failures in the last hppa test result - but I could not.

Currently, I only see failures due to PR45505 and a -O3
gfortran.dg/forall_7.f90 failure in the last hppa2.0w-hp-hpux11.11 run.

Thus, I am inclined to close this PR as RESOLVE - WORKSFORME. Comments?

[Bug c++/46117] New: [4.6 Regression] ICE: SIGSEGV in add_function_candidate (call.c:1630) on invalid typename usage

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: SIGSEGV in
add_function_candidate (call.c:1630) on invalid
typename usage
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 22106
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22106
reduced testcase

Compiler output:
$ gcc pr46117.C 
pr46117.C:3:15: error: expected nested-name-specifier before 'int'
pr46117.C:3:15: error: two or more data types in declaration of 'parameter'
pr46117.C:8:3: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


valgrind output:
testcase.C:3:13: error: expected nested-name-specifier before 'int'
testcase.C:3:13: error: two or more data types in declaration of 'parameter'
==24080== Invalid read of size 2
==24080==at 0x4A8823: add_function_candidate (call.c:1630)
==24080==by 0x4A58B3: add_candidates (call.c:4254)
==24080==by 0x4AB8A3: build_new_method_call (call.c:6528)
==24080==by 0x5BBB24: locate_fn_flags (method.c:826)
==24080==by 0x5BEEB5: synthesized_method_walk (method.c:1183)
==24080==by 0x5BF839: implicitly_declare_fn (method.c:1433)
==24080==by 0x5C0ACA: lazily_declare_fn (method.c:1634)
==24080==by 0x5C5354: lookup_fnfields_1 (search.c:1360)
==24080==by 0x5C8653: lookup_field_r (search.c:1032)
==24080==by 0x5C5918: dfs_walk_all (search.c:1542)
==24080==by 0x5C5A97: lookup_member (search.c:1206)
==24080==by 0x5C5CCA: lookup_fnfields (search.c:1288)
==24080==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==24080== 
testcase.C:8:3: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Full backtrace is quite long, so I am posting just this reduced one

Tested revisions:
r165768 - crash
r163636 - crash
r161659 - OK

[Bug c/46116] New: Allow passing of anonymous aggregates when signature matches

[robert.staudinger at gmail dot com]

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

   Summary: Allow passing of anonymous aggregates when signature
matches
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: robert.staudin...@gmail.com


Created attachment 22105
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22105
anon-aggregate-stack.c

It would be nice if GCC allowed passing of anonymous aggregates if their
signatures match.

Currently, judging from the error message, it seems like no attempt is being
made at finding out if the anonymous types would match.

anon-aggregate-stack.c:15: error: incompatible type for argument 1 of ‘f’
anon-aggregate-stack.c:6: note: expected ‘struct ’ but argument is
of type ‘struct ’

[Bug c/46115] New: Feature request: anonymous functions (complementing anon aggregates)

[robert.staudinger at gmail dot com]

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

   Summary: Feature request: anonymous functions (complementing
anon aggregates)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: robert.staudin...@gmail.com


It would be great if GCC would consider addition of anonymous functions along
the lines of anonymous aggreates, i.e. deferring the formal parameters from the
preceding cast expression.

Example:

void (*func_ptr)(int) = (void (*)(int i)) { printf ("%i", i); };

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

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #20 from janus at gcc dot gnu.org 2010-10-21 12:28:23 UTC ---
I fail to reproduce the ICE with today's r165769. Hans, are you still getting
this error? (If you do, maybe you can try to get a backtrace with gdb. Btw,
what architecture/OS are you on?)

valgrind shows me a couple of memory leaks, but no invalid memory accesses.

[Bug c/45834] Redundant inter-loop edges in DDG

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #7 from Zdenek Sojka  2010-10-21 12:27:11 
UTC ---
(In reply to comment #1)
>   /* We cannot use aliases_everything_p to test MEM, since we must look
>  at MEM_ADDR, rather than XEXP (mem, 0).  */
>   if (GET_MODE (mem) == QImode || GET_CODE (mem_addr) == AND)
> return 1;
> 

Just out of curiosity, I tried compiling gcc without these four lines.
Bootstrap at x86_64-linux went fine, regression test with the same results as
clean trunk.

stage3 .o files weren't the same (compared to clean trunk). Those I had a look
at, have small differences in scheduling and register allocation.

[Bug fortran/46007] wrong code for SHAPE in a scalarized loop

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  2010-10-21 
12:25:23 UTC ---
Author: tkoenig
Date: Thu Oct 21 12:25:12 2010
New Revision: 165770

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165770
Log:
2010-10-21  Thomas Koenig  

PR fortran/46007
* m4/shape.m4 (shape_'rtype_kind`):  Use variable for rank.
Allocate return array if unallocated.
* generated/shape_i4.c:  Regenerated.
* generated/shape_i8.c:  Regenerated.
* generated/shape_i16.c:  Regenerated.

2010-10-21  Thomas Koenig  

PR fortran/46007
* gfortran.dg/shape_5.f90:  New test case.


Added:
trunk/gcc/testsuite/gfortran.dg/shape_5.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/shape_i16.c
trunk/libgfortran/generated/shape_i4.c
trunk/libgfortran/generated/shape_i8.c
trunk/libgfortran/m4/shape.m4

[Bug rtl-optimization/46114] New: [4.6 regression] g++ SEGV when built with gld on Solaris 10+/x86

[ro at gcc dot gnu.org]

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

   Summary: [4.6 regression] g++ SEGV when built with gld on
Solaris 10+/x86
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ber...@codesourcery.com
  Host: i386-pc-solaris2.1[01]
Target: i386-pc-solaris2.1[01]
 Build: i386-pc-solaris2.1[01]


When I recently tried to bootstrap mainline on Solaris 11 (and later 10)/x86
with CVS gas and gld, many C++ testcases failed.  It turned out that g++
SEGVs like this:

% g++ gcc.o
Segmentation Fault

It crashes like this:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
generate_option (opt_index=902, arg=0x8074535 , 
value=1, lang_mask=65536, decoded=0x1)
at /var/gcc/reghunt/trunk/gcc/opts-common.c:862
862   decoded->arg = arg;
(gdb) where
#0  generate_option (opt_index=902, arg=0x8074535 , 
value=1, lang_mask=65536, decoded=0x1)
at /var/gcc/reghunt/trunk/gcc/opts-common.c:862
#1  0x0805a9cb in lang_specific_driver (in_decoded_options=0x80474d8, 
in_decoded_options_count=0x80474dc, in_added_libraries=0x8093744)
at /var/gcc/reghunt/trunk/gcc/cp/g++spec.c:324
#2  0x0804c764 in process_command (decoded_options_count=2, 
decoded_options=0x8093ff8) at /var/gcc/reghunt/trunk/gcc/gcc.c:3597
#3  0x08052f9a in main (argc=2, argv=0x8047664)
at /var/gcc/reghunt/trunk/gcc/gcc.c:6214

i.e. decoded is invalid.  After searching around for a binutils change that
caused this, it turned out that the problem only happens when gas and gld
are in use, but also with gas/gld 2.20.1.  A gcc reghunt identified the
following patch as the culprit:

2010-09-23  Bernd Schmidt  

PR rtl-optimization/44374
* basic-block.h (enum bb_flags): Add BB_MODIFIED.
* df-core.c (df_set_bb_dirty): Set it.
* ifcvt.c (find_memory): Remove function.
(dead_or_predicable): Use can_move_insns_across.
* df.h (can_move_insns_across): Declare function.
* cfgcleanup.c (block_was_dirty): New static variable.
(try_crossjump_bb, try_forward_edges): Test BB_MODIFIED flag rather
than df_get_bb_dirty.
(try_head_merge_bb): New static function.
(try_optimize_cfg): Call it.  Call df_analyze if block_was_dirty
is set.
* df-problems.c: Include "target.h"
(df_simulate_find_uses): New static function.
(MEMREF_NORMAL, MEMREF_VOLATILE): New macros.
(find_memory, find_memory_store): New static functions.
(can_move_insns_across): New function.
* Makefile.in (df-problems.o): Update dependencies.

I've not yet identified the mis-compilation caused.

[Bug fortran/46060] [F03] procedure pointer component referenced without argument list

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from janus at gcc dot gnu.org 2010-10-21 11:35:05 UTC ---
Fixed with r165769. Closing.

Thanks for the report, Stephen!

[Bug fortran/46060] [F03] procedure pointer component referenced without argument list

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org 2010-10-21 11:31:58 UTC ---
Author: janus
Date: Thu Oct 21 11:31:55 2010
New Revision: 165769

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165769
Log:
2010-10-21  Janus Weil  

PR fortran/46060
* match.h (gfc_matching_ptr_assignment): New global variable to indicate
we're currently matching a (non-proc-)pointer assignment.
* decl.c (match_pointer_init): Set it.
* match.c (gfc_match_pointer_assignment): Ditto.
* primary.c (matching_actual_arglist): New global variable to indicate
we're currently matching an actual argument list.
(gfc_match_actual_arglist): Set it.
(gfc_match_varspec): Reject procedure pointer component calls with
missing argument list.


2010-10-21  Janus Weil  

PR fortran/46060
* gfortran.dg/proc_ptr_comp_25.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_25.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/match.h
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog

[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

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Richard Guenther  2010-10-21 
11:11:18 UTC ---
Fixed.

[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

--- Comment #10 from Richard Guenther  2010-10-21 
11:10:45 UTC ---
Author: rguenth
Date: Thu Oct 21 11:10:41 2010
New Revision: 165768

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165768
Log:
2010-10-21  Richard Guenther  
Michael Matz  

PR tree-optimization/45764
* tree-vect-data-refs.c (vect_compute_data_ref_alignment):
Adjust initial misalignment for negative DR_STEP.
(vect_find_same_alignment_drs): Two DRs with different DR_STEP
do not have the same alignment over the whole iteration domain.

* gcc.dg/torture/pr45764.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr45764.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug tree-optimization/46111] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'mem_ref' in take_address_of, at tree-parloops.c:336 with -ftree-parallelize-

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther  2010-10-21 
10:39:52 UTC ---
Fixed.

[Bug tree-optimization/46111] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'mem_ref' in take_address_of, at tree-parloops.c:336 with -ftree-parallelize-

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2010-10-21 
10:38:55 UTC ---
Author: rguenth
Date: Thu Oct 21 10:38:51 2010
New Revision: 165765

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165765
Log:
2010-10-21  Richard Guenther  

PR tree-optimization/46111
* tree-parloops.c (take_address_of): Re-organize for MEM_REF.

* g++.dg/torture/pr46111.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr46111.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-parloops.c

[Bug driver/46113] New: collect2.exe not passing through @FILE response argument to linker

[ben.combrink at gmail dot com]

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

   Summary: collect2.exe not passing through @FILE response
argument to linker
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ben.combr...@gmail.com


Created attachment 22104
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22104
execution of g++ and collect2.exe during spring.exe linking

I'm building the Spring engine project (version 0.82.6.1) and using GCC 4.5.0-2
with CMake 2.8.2.

Spring has so many objects that it exceeds the 32k limit on windows argument
passing so the @FILE option is required.

The g++ front-end is properly passing the response file to collect2.exe.
See "g++_exec.txt" in the zip attachment.
However collect2.exe terminates with message:
   "collect2: CreateProcess: No such file or directory"

I executed the collect2 commandline with -debug to see what's going on.
See "collect2_exec.txt" in the attached zip.

One can clearly see the response file
"CMakeFiles\engine-default.dir\objects1.rsp"
being passed to collect2.exe but then it expands it into a full commandline
when it executes ld.exe...this causes the command execution to fail.

The variable HAVE_GNU_LD had been defined.

[Bug middle-end/45720] [4.6 regression] Revision 164367 miscompiled SPEC CPU 2K

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  2010-10-03 
05:41:44 UTC ---
Author: hjl
Date: Sun Oct  3 05:39:32 2010
New Revision: 164914

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164914
Log:
Disallow negative steps in vectorizer.

gcc/

2010-10-02  H.J. Lu  

PR tree-optimization/45720
PR tree-optimization/45764
* tree-vect-data-refs.c (vect_analyze_data_ref_access):
Don't accept backwards consecutive accesses.
(vect_create_data_ref_ptr): Disallow negative steps.

* tree-vect-stmts.c (vectorizable_store): Allow negative steps.
(perm_mask_for_reverse): Removed.
(reverse_vec_elements): Likewise.
(vectorizable_load): Don't hanle negative steps.

gcc/testsuite/

2010-10-02  H.J. Lu  

PR tree-optimization/45720
PR tree-optimization/45764
* g++.dg/torture/pr45764.C: New.

* gcc.dg/vect/pr43432.c: Xfail.
* gcc.dg/vect/vect-114.c: Likewise.
* gcc.dg/vect/vect-15.c: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr45764.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr43432.c
trunk/gcc/testsuite/gcc.dg/vect/vect-114.c
trunk/gcc/testsuite/gcc.dg/vect/vect-15.c
trunk/gcc/tree-vect-data-refs.c
trunk/gcc/tree-vect-stmts.c

--- Comment #3 from Richard Guenther  2010-10-21 
10:03:49 UTC ---
Likely a dup of PR45764 which has all the analysis.

[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

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

--- Comment #9 from Richard Guenther  2010-10-21 
10:01:10 UTC ---
Testing a patch.

[Bug c/46112] internal compiler error

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #1 from Mikael Pettersson  2010-10-21 
09:43:04 UTC ---
Confirmed on i686-pc-linux-gnu (msp430 doesn't seem to be a supported target in
upstream gcc).

> cat pr46112.c
static char e1_mylongtag[100] = {[0 ... (100 -1)]=" "};
> objdir/gcc/xgcc -Bobjdir/gcc -S pr46112.c
pr46112.c:1:1: internal compiler error: in pop_init_level, at c-typeck.c:6930
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
> objdir/gcc/xgcc -Bobjdir/gcc -v
Reading specs from objdir/gcc/specs
COLLECT_GCC=objdir/gcc/xgcc
COLLECT_LTO_WRAPPER=objdir/gcc/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /tmp/gcc-4.6-20101016/configure
--prefix=/home/mikpe/pkgs/linux-x86/gcc-4.6.0
--with-gmp=/home/mikpe/pkgs/linux-x86/gmp-4.3.2
--with-mpfr=/home/mikpe/pkgs/linux-x86/mpfr-2.4.2
--with-mpc=/home/mikpe/pkgs/linux-x86/mpc-0.8.2 --disable-plugin --disable-lto
--disable-nls --disable-shared --disable-libmudflap --enable-threads=posix
--enable-checking=release --enable-languages=c
Thread model: posix
gcc version 4.6.0 20101016 (experimental) (GCC)

ICEs every gcc from 4.6 down to 3.2.3, but 2.95.3 works.

Given the source I'm guessing this is ice-on-invalid-code.

[Bug tree-optimization/46111] [4.6 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'mem_ref' in take_address_of, at tree-parloops.c:336 with -ftree-parallelize-

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2010.10.21 09:35:45
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2010-10-21 
09:35:45 UTC ---
Mine.  It's also a -g vs. -g0 problem btw, but that's a different story.

[Bug c++/46103] [c++0x] moving from std::array copies the elements

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Paolo Carlini  2010-10-21 
09:32:12 UTC ---
Ok, let's add Jason in CC.