[Bug fortran/49586] New: Multiple initialization with DATA: Warning and initialization order

[burnus at gcc dot gnu.org]

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

   Summary: Multiple initialization with DATA: Warning and
initialization order
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
Depends on: 49540


Follow up to PR 49540.

gfortran - as some other compilers - allows multiple initialization in DATA
statements.

Expected:
- Warn - at least with -Wall - if multiple initialization occur
  (Currently, only -pedantic warns and -std=f* prints an error)
- Check whether the current initialization makes sense
  I think the version of gfortran 4.1 + the commercial compilers makes most
  sense.


For the test case below, the result is (* = warns by default):

- g95, NAG: Error because of multiple initialization

- gfortran 4.1 (!), ifort, sunf90, pathf90*, openf90*, pgf90:
4, 5, 5, 5, 5,  5, 5, 5, 5, 5,  5, 5, 5, 5, 5,  5, 5, 5, 5, 5,  5, 5, 5, 5, 6

- gfortran 4.6 and 4.7:
4, 5, 5, 5, 5,  1, 2, 2, 2, 3,  5, 5, 5, 5, 5,  5, 5, 5, 5, 5,  5, 5, 5, 5, 6

- gfortran 4.3, 4.4 and 4.5:
4, 3, 3, 3, 3,  3, 3, 3, 3, 3,  3, 3, 3, 3, 3,  3, 3, 3, 3, 3,  3, 3, 3, 3, 6


  program pr49540_2
common /a/ i(5,5)
data i(1:5,2) /1, 3 * 2, 3/
data i /4, 23 * 5, 6/
print '(5(5(i0:", "):" "))', i
  end

[Bug c++/36159] C++ compiler should issue a warning with missing new operator

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||sergey.v.maslov at intel
   ||dot com

--- Comment #9 from H.J. Lu  2011-06-30 04:50:54 
UTC ---
*** Bug 49585 has been marked as a duplicate of this bug. ***

[Bug c++/49585] need a warning about new/malloc returning unsufficiently aligned memory

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
Version|unknown |4.7.0
 Resolution||DUPLICATE

--- Comment #1 from H.J. Lu  2011-06-30 04:50:54 
UTC ---
Dup.

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

[Bug c++/49585] New: need a warning about new/malloc returning unsufficiently aligned memory

[sergey.v.maslov at intel dot com]

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

   Summary: need a warning about new/malloc returning
unsufficiently aligned memory
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sergey.v.mas...@intel.com


Consider the following test case:

#define alignement 64

struct test {
public:
  int toto[100] __attribute__((aligned(alignement)));
};

int main () {
test* t = new test();
printf("%ld\n",(unsigned long)(&(t->toto[0])) % alignement);
return 0;
}

This program typically prints a non-zero value, whereas customers would
actually expect 0. This is due to default "new" (presumably doing malloc) only
gurantees 16 byte alignment.

Compiler should detect when a default new operator is used to allocate
unsufficiently aligned memory, and issue a relevent user diagnostics.

BTW, this issues can cause severe stability problems in AVX compilation, where
32-byte is the typical requirement for 256-bit AVX data types.

[Bug lto/48384] lto, linker-plugin and optimization clutter the stack trace

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #7 from Ian Lance Taylor  2011-06-30 00:53:59 
UTC ---
I just committed a fix for this problem in the gold development sources.

[Bug tree-optimization/38752] [4.3 Regression] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4817

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||

--- Comment #5 from Andrew Pinski  2011-06-29 
23:13:01 UTC ---
This testcase was never added to the trunk.

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Jason Merrill  2011-06-29 
22:28:46 UTC ---
Fixed for real this time, hopefully.

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

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  2011-06-29 
22:28:18 UTC ---
Author: jason
Date: Wed Jun 29 22:28:15 2011
New Revision: 175674

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175674
Log:
PR c++/49216
* init.c (build_new_1): Pass {} down to build_vec_init.
(build_vec_init): Handle it.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-value.C
trunk/gcc/testsuite/g++.dg/cpp0x/initlist53.C
trunk/gcc/testsuite/g++.old-deja/g++.ext/arrnew2.C

[Bug c++/49003] [C++0x][DR 1207] decltype in member function's trailing return type should deduce constness of *this

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  2011-06-29 
22:20:26 UTC ---
Created attachment 24642
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24642
patch for 4.6

I've been pretty free about applying non-regression fix patches to the 4.6
branch, but I think now that 4.6.1 has gone out I'm going to be more
conservative.  But here's a patch against the 4.6 branch if you want to apply
it locally.

[Bug c++/49003] [C++0x][DR 1207] decltype in member function's trailing return type should deduce constness of *this

[zeratul976 at hotmail dot com]

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

--- Comment #6 from Nathan Ridge  2011-06-29 
21:50:06 UTC ---
Thanks Jason! Is there any chance of getting this into 4.6.2?

[Bug lto/48725] 4.6.0 fails to link p7zip 9.20.1 with LTO and gold

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||ian at airs dot com
 Resolution||WORKSFORME

--- Comment #7 from Ian Lance Taylor  2011-06-29 21:30:23 
UTC ---
As noted on the gold bug report
http://sourceware.org/bugzilla/show_bug.cgi?id=12695, I have not been able to
recreate the problem with gold.

However, any problem here is clearly a gold problem, and I don't see any reason
to keep this gcc bug report open.

[Bug c++/49003] [C++0x][DR 1207] decltype in member function's trailing return type should deduce constness of *this

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  2011-06-29 
21:20:14 UTC ---
Implemented for 4.7.

[Bug c++/49003] [C++0x][DR 1207] decltype in member function's trailing return type should deduce constness of *this

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2011-06-29 
21:19:35 UTC ---
Author: jason
Date: Wed Jun 29 21:19:31 2011
New Revision: 175671

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175671
Log:
DR 1207
PR c++/49003
* cp-tree.h (struct saved_scope): Add x_current_class_ptr,
x_current_class_ref.
(current_class_ptr, current_class_ref): Use them.
* decl.c (build_this_parm): Handle getting the class type.
* parser.c (cp_parser_late_return_type_opt): Set up 'this'
for use within the trailing return type.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/trailing6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/pr45908.C

[Bug middle-end/47653] [4.6/4.7 Regression] gcc.c-torture/execute/930614-2.c FAILs with -fstack-check=generic -fgraphite-identity

[spop at gcc dot gnu.org]

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

--- Comment #7 from Sebastian Pop  2011-06-29 21:18:09 
UTC ---
Patch http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02283.html

[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]

[jsg at openbsd dot org]

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

--- Comment #12 from Jonathan Gray  2011-06-29 21:17:31 
UTC ---
The problem appears to be in the "fixed" version of string.h

before:

#ifndef NULL
#ifdef  __GNUG__
#define NULL__null
#else
#define NULL((void *)0)
#endif
#endif

after:

#ifndef NULL
#ifdef  __GNUG__
#define NULL__null
#else
#define NULL 0
#endif
#endif

fixincludes seems to be busted.

--- /usr/include/string.h   Sat Jun 25 19:55:15 2011
+++ /home/jsg/src/obj461/./prev-gcc/include-fixed/string.h  Wed Jun 29
01:33:27 2011
@@ -1,3 +1,12 @@
+/*  DO NOT EDIT THIS FILE.
+
+It has been auto-edited by fixincludes from:
+
+   "/usr/include/string.h"
+
+This had to be done to correct non-standard usages in the
+original, manufacturer supplied header file.  */
+
 /* $OpenBSD: string.h,v 1.21 2011/04/06 11:39:42 miod Exp $*/
 /* $NetBSD: string.h,v 1.6 1994/10/26 00:56:30 cgd Exp $   */

@@ -47,7 +56,7 @@ typedef   __size_tsize_t;
 #ifdef __GNUG__
 #defineNULL__null
 #else
-#defineNULL((void *)0)
+#define NULL 0
 #endif
 #endif

bizarrely the same block in stddef.h is left alone by fixincludes

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  2011-06-29 
21:14:55 UTC ---
> ISTM that DOM considering those two accesses equivalent, even though they had
> different types is arguably incorrect behaviour.

The accesses themselves have the same type, since they are strictly identical.
The problem is the type of the LHS, which is incompatible between the 2 cases.

> I have vague memories that we played things a little fast and loose with types
> of memory loads.  ie, if the destination had type T1, but the field reference
> had type T2 and we knew that T1 and T2 were the same size, then we'd change 
> the
> type of the field reference to T1 and avoid the typecast from T2 to T1.  IIRC
> we did this in the gimplifier.

After tuplification, DOM records the type of the LHS of assignment statements
as the type of the expression.  And then it tests the compatibility of these
types.
This is problematic because you can have non-compatible types on the LHS and
RHS of assignment statements, if the conversion RHS->LHS is deemed useless,
e.g. for pointers.  See types_compatible_p and useless_type_conversion_p in
tree-ssa.c.

[Bug tree-optimization/49460] g++: Internal error: Segmentation fault (program cc1plus) using -O2 or -O3

[rjarrett at mathworks dot com]

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

--- Comment #4 from Roger Jarrett  2011-06-29 
21:13:49 UTC ---
Confirmed  -fno-tree-pre worked around the issue using the  initial source 
--Roger

[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]

[jsg at openbsd dot org]

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

--- Comment #11 from Jonathan Gray  2011-06-29 21:01:45 
UTC ---
There is some problem with the gcc headers it would seem, placing #include
 at the start of lto-plugin.c the correct definition of NULL gets
picked up.  I am still trying to figure out where exactly the problem is but
grep shows at least:

gcc/tsystem.h:#define NULL 0
gcc/system.h:#define NULL 0
libiberty/getopt1.c:#define NULL 0
libiberty/argv.c:#define NULL 0

[Bug bootstrap/49415] [4.7 Regression] Revision 175071 fails to bootstrap on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from Dominique d'Humieres  2011-06-29 
20:54:45 UTC ---
This pr has been fixed by revision 175110. Closing.

[Bug target/49421] [arm] suboptimal choice of working regs

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.29 20:47:18
 CC||ramana at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  2011-06-29 
20:47:18 UTC ---
confirmed -

[Bug c++/46170] [4.4/4.5 Regression] g++ wrongly rejects pointer-to-member in template arguments

[fang at csl dot cornell.edu]

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

--- Comment #29 from David Fang  2011-06-29 
20:21:52 UTC ---
re-ping for backport?

[Bug rtl-optimization/49230] please provide workaround for setjmp/longjmp in mingw32

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #10 from Kai Tietz  2011-06-29 20:20:21 
UTC ---
Please stop to reopen this bug. It isn't related to gcc at all. I just rebuild
a gcc 4.7 (trunk) version for i686-w64-mingw32 and test passes as expected
(with crash after trying to leave main function).
This issue is related to mingw.org's header-set and handling of setjmp.  As I
mentioned before, this is caused by a missing (undocumented) argument for
setjmp. You disassembly of this function shows that msvcrt's setjmp function
tries to read this hidden argument and just by accident it is here the place of
ebp.
See on msdn the user-comment about setjmp.

[Bug objc/48109] Objective-C class defs/refs are lost under LTO on Darwin for ABI0/1

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

  Attachment #23655|0   |1
is obsolete||
 AssignedTo|unassigned at gcc dot   |iains at gcc dot gnu.org
   |gnu.org |

--- Comment #9 from Iain Sandoe  2011-06-29 20:08:33 
UTC ---
Created attachment 24641
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24641
updated to trunk @175628.

this patch posted to GCC-patches:

http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02268.html

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|FIXED   |

--- Comment #4 from Jason Merrill  2011-06-29 
20:07:08 UTC ---
Indeed, it only passes on linux because malloc returns zeroed memory.

[Bug c++/47700] Warning for C casts in C++

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME

--- Comment #12 from Manuel López-Ibáñez  2011-06-29 
20:00:25 UTC ---
WORKSFORME using -Wold-style-cast. 

The rest of the discussion is bike-shedding that can go into g...@gcc.gnu.org.
Suggestions for improving the manual should be sent directly to gcc-patches as
patches.

[Bug pch/49579] Document how to use PCH with Automake

[olafvdspek at gmail dot com]

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

--- Comment #4 from Olaf van der Spek  2011-06-29 
19:59:57 UTC ---
Aren't 1 and 2 the same thing?
I'm not sure what 3 is, but it's about a Hello World example using AM and PCH.

[Bug bootstrap/49584] [4.4.7 regression] bootstrap failure on m68k-linux: segfault compiling _muldi3

[mikpe at it dot uu.se]

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

--- Comment #2 from Mikael Pettersson  2011-06-29 
19:52:35 UTC ---
(In reply to comment #1)
> This is stage 1 though.

Hmm, strange.

> > I'll try a new bootstrap with r175603 reverted.
> 
> How do you build the stage 1 compiler?  With optimization enabled?

Just 'make bootstrap' with no other options.

I just noticed a possible mistake in my previous bootstrap attempt; I'll redo
everything from scratch and post an update tomorrow.

[Bug c++/49575] OpenMP has a problem with -funroll-loops

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-06-29 
19:49:47 UTC ---
With firstprivate of course you get a copy of the variable, but it is still a
variable.  The *.omp_fn* function which is created from the #omp parallel
region will load it from parameter's structure and use it:
  k = .omp_data_i->k;
...
  D.1646 = (double) k;
  i.33 = i + (long double) D.1646;
  temp.34 = pow (D.1646, 2.0e+0);
  i.36 = i.33 + (long double) temp.34;
  temp.37 = pow (D.1646, 3.0e+0);
  i.39 = i.36 + (long double) temp.37;
  temp.40 = pow (D.1646, 4.0e+0);
  i.42 = i.39 + (long double) temp.40;
  temp.43 = pow (D.1646, 5.0e+0);
...
but as it doesn't look at the caller, k is variable for it.  Without -fopenmp,
ccp propagates the 0.7 value to k uses and we end up with:
  i.32 = i + 6.999555910790149937383830547332763671875e-1;
  i.33 = i.32 + 4.89935607064571740920655429363250732421875e-1;
  i.34 = i.33 + 3.42916067139338338165543973445892333984375e-1;
  i.35 = i.34 + 2.400523492277830882812850177288055419921875e-1;
  i.36 = i.35 + 1.6806999416644413940957747399806976318359375e-1;
  i.37 = i.36 + 1.17648996194066653742993366904556751251220703125e-1;
  i.38 = i.37 + 8.235429636440151107308338396251201629638671875e-2;
...
because gcc saw pow (0.7, 2.0e+0), pow (0.7, 3.0e+0); etc. and constant folded
that.  So, there aren't any pow calls without -fopenmp (wonder why nothing
folded even the additions with -ffast-math though).  Now, if with -fopenmp we
do an interprodecural optimization so that .omp_data_i->k loads in the callee
are replaced with what constant value has been stored into that field after
constant propagation is performed in the caller, we can again constant
propagate the 0.7 down into the pow calls and constant fold them.
Of course the testcase doesn't make any sense this way, but the constant
propagation accross the parallel region boundary could help real-world OpenMP
programs too.

[Bug c++/47700] Warning for C casts in C++

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.06.29 19:45:04
 Ever Confirmed|0   |1

--- Comment #11 from Jonathan Wakely  2011-06-29 
19:45:04 UTC ---
why is this still open?  please change the summary to something relevant, since
the requested option exists

[Bug pch/49579] Document how to use PCH with Automake

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.06.29 19:42:53
 Ever Confirmed|0   |1

--- Comment #3 from Jonathan Wakely  2011-06-29 
19:42:53 UTC ---
Please clarify the request, are you requesting documentation on how to tell
Automake to generate PCH for a program? use PCH while compiling a program?
Install PCH alongside a library's headers?

[Bug c++/49575] OpenMP has a problem with -funroll-loops

[sailorweb2 at hotmail dot com]

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

--- Comment #2 from Duncan  2011-06-29 19:38:00 
UTC ---
I am new to OpenMP so I do not know the details, but as far as I know, variable
k is defined as firstprivate, so each thread will have an independent local
copy. Why does it need defining constant or declaring it in the body of the
parallel region even though it is defined firstprivate? Won't firstprivate
automatically define a local copy of k in the body of the parallel region?

[Bug rtl-optimization/49230] please provide workaround for setjmp/longjmp in mingw32

[jojelino at gmail dot com]

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

--- Comment #8 from gee  2011-06-29 19:37:35 UTC ---
Created attachment 24640
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24640
preprocessed source and generated code

verbose log

i686-pc-mingw32-gcc -O4 -mfpmath=sse -march=native -mtune=native -mthreads
-mstackrealign -g3 -Wextra -Wno-unused-parameter -Wno-parentheses
-Wno-long-long -Wno-missing-field-initializers -Werror=pointer-arith
-Werror=write-strings -Werror=declaration-after-statement
-Werror=implicit-function-declaration -include ruby/config.h -include
ruby/missing.h -fvisibility=hidden -DRUBY_EXPORT   -I.
-I.ext/include/i386-mingw32 -I./include -I. -I/usr/include/w32api -o eval.o -c
eval.c -save-temps -v
Using built-in specs.
COLLECT_GCC=i686-pc-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-mingw32/4.7.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ./configure --config-cache --prefix=/usr
--enable-win32-registry --enable-threads=win32 --enable-languages=c,c++,lto
--with-win32-nlsapi=unicode --enable-tls --disable-bootstrap
--target=i686-pc-mingw32 --enable-shared --enable-interpreter
--disable-sjlj-exceptions --enable-gomp
Thread model: win32
gcc version 4.7.0 20110622 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-O4' '-mfpmath=sse' '-march=native' '-mtune=native'
'-mthreads' '-mstackrealign' '-g3' '-Wextra' '-Wno-unused-parameter'
'-Wno-parentheses' '-Wno-long-long' '-Wno-missing-field-initializers'
'-Werror=pointer-arith' '-Werror=write-strings'
'-Werror=declaration-after-statement' '-Werror=implicit-function-declaration'
'-include' 'ruby/config.h' '-include' 'ruby/missing.h' '-fvisibility=hidden'
'-D' 'RUBY_EXPORT' '-I' '.' '-I' '.ext/include/i386-mingw32' '-I' './include'
'-I' '.' '-I' '/usr/include/w32api' '-o' 'eval.o' '-c' '-save-temps' '-v'
 /usr/libexec/gcc/i686-pc-mingw32/4.7.0/cc1.exe -E -quiet -v -I . -I
.ext/include/i386-mingw32 -I ./include -I . -I /usr/include/w32api -dD -D_MT -D
RUBY_EXPORT -include ruby/config.h -include ruby/missing.h eval.c -march=core2
-mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp
-mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -mno-sse4.2 -msse4.1
--param l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=2048 -mtune=core2 -mfpmath=sse -mthreads -mstackrealign -Wextra
-Wno-unused-parameter -Wno-parentheses -Wno-long-long
-Wno-missing-field-initializers -Werror=pointer-arith -Werror=write-strings
-Werror=declaration-after-statement -Werror=implicit-function-declaration
-fvisibility=hidden -g3 -fworking-directory -O4 -fpch-preprocess -o eval.i
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-mingw32/4.7.0/../../../../i686-pc-mingw32/sys-include"
ignoring duplicate directory "."
#include "..." search starts here:
#include <...> search starts here:
 .
 .ext/include/i386-mingw32
 ./include
 /usr/include/w32api
 /usr/lib/gcc/i686-pc-mingw32/4.7.0/include
 /usr/lib/gcc/i686-pc-mingw32/4.7.0/include-fixed
 /usr/lib/gcc/i686-pc-mingw32/4.7.0/../../../../i686-pc-mingw32/include
End of search list.
COLLECT_GCC_OPTIONS='-O4' '-mfpmath=sse' '-march=native' '-mtune=native'
'-mthreads' '-mstackrealign' '-g3' '-Wextra' '-Wno-unused-parameter'
'-Wno-parentheses' '-Wno-long-long' '-Wno-missing-field-initializers'
'-Werror=pointer-arith' '-Werror=write-strings'
'-Werror=declaration-after-statement' '-Werror=implicit-function-declaration'
'-include' 'ruby/config.h' '-include' 'ruby/missing.h' '-fvisibility=hidden'
'-D' 'RUBY_EXPORT' '-I' '.' '-I' '.ext/include/i386-mingw32' '-I' './include'
'-I' '.' '-I' '/usr/include/w32api' '-o' 'eval.o' '-c' '-save-temps' '-v'
 /usr/libexec/gcc/i686-pc-mingw32/4.7.0/cc1.exe -fpreprocessed eval.i
-march=core2 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm
-mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -mno-sse4.2
-msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=2048 -mtune=core2 -quiet -dumpbase eval.c -mfpmath=sse -mthreads
-mstackrealign -auxbase-strip eval.o -g3 -O4 -Wextra -Wno-unused-parameter
-Wno-parentheses -Wno-long-long -Wno-missing-field-initializers
-Werror=pointer-arith -Werror=write-strings -Werror=declaration-after-statement
-Werror=implicit-function-declaration -version -fvisibility=hidden -o eval.s
GNU C (GCC) version 4.7.0 20110622 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.7.0 20110622 (experimental), GMP version
5.0.0, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.7.0 20110622 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.7.0 20110622 (experimental), GMP version
5.0.0, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: b98a9904da950a3b4c2a13878d133f7f
COLLECT_GCC_OPTIONS='-O4' '-mfpmath=sse' '-march=native' '-mtune=native'
'-mthreads' '-mstackr

[Bug pch/49576] Option to suggest headers for addition to PCH

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  2011-06-29 
19:35:52 UTC ---
It's not about being smart enough, most gcc devs have plenty of things to work
on so if you want to convince someone yours is worth implementing you should
spend a few minutes describing the feature properly (who will benefit? what is
the benefit? give a small example program and explain how it would behave with
the feaature etc.)

If the person requesting a new feature doesn't care enough to spend time
describing it clearly why should someone else spend far more time thinking
about it and implementing it?

I'm just trying to give you advice to improve the chance of someone
implementing this - feel free to ignore it, but don't be surprised if the
request gets ignored too.

[Bug rtl-optimization/49230] please provide workaround for setjmp/longjmp in mingw32

[jojelino at gmail dot com]

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

gee  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #7 from gee  2011-06-29 19:35:20 UTC ---
(In reply to comment #3)
> As register ebp is used by gcc as internal frame-register. Even if you are
> specifying -fomit-frame-pointer as option, the main function will still have a
> frame-pointer setup. Also ebp-register is a callee-saved register, which means
> its use as local-register variable is in general nothing wise to do.

maybe the following could be counterexample.
this code is from gcc 200622.
ebp may be not internal frame pointer.
so in this case setjmp can store invalid ebp.
nlg_notify dereferences ebp,causing sigsegv
not only it don't use framepointer, but also it doesn't restore framepointer

LFE104:
.p2align 4,,15
.globl_rb_ensure
.def_rb_ensure;.scl2;.type32;.endef
_rb_ensure:
LFB105:
.loc 2 727 0 is_stmt 1
.cfi_startproc
LVL835:
pushl%ebx
LCFI228:
.cfi_def_cfa_offset 8
.cfi_offset 3, -8
subl$120, %esp
LCFI229:
.cfi_def_cfa_offset 128
LBB566:
.loc 2 731 0
movl_ruby_current_thread, %eax
LBE566:
.loc 2 729 0
movl$4, 32(%esp)
LVL836:
LBB567:
.loc 2 731 0
movl$0, 100(%esp)
movl%eax, %edx
movl%eax, 28(%esp)
LVL837:
movl152(%eax), %eax
movl%eax, 108(%esp)
leal36(%esp), %eax
movl%eax, 152(%edx)
.loc 2 732 0
movl%eax, (%esp)
call__setjmp
LVL838:
testl%eax, %eax
movl%eax, %ebx
LVL839:
jeL733
.loc 2 735 0
movl108(%esp), %eax
LVL840:
movl28(%esp), %edx
movl%eax, 152(%edx)
LBE567:
.loc 2 738 0
movl140(%esp), %eax
movl%eax, (%esp)
call*136(%esp)
LVL841:
.loc 2 740 0
movl_ruby_current_thread, %eax
movl%ebx, 4(%esp)
movl152(%eax), %eax
movl%eax, (%esp)
call_longjmp
LVL842:
.p2align 4,,10
L733:
LBB568:
.loc 2 733 0
movl132(%esp), %eax
movl%eax, (%esp)
call*128(%esp)
LVL843:
.loc 2 735 0
movl28(%esp), %edx
.loc 2 733 0
movl%eax, 32(%esp)
.loc 2 735 0
movl108(%esp), %eax
movl%eax, 152(%edx)
LBE568:
.loc 2 738 0
movl140(%esp), %eax
movl%eax, (%esp)
call*136(%esp)
LVL844:
.loc 2 741 0
movl32(%esp), %eax
.loc 2 742 0
addl$120, %esp
LCFI230:
.cfi_def_cfa_offset 8
popl%ebx
LCFI231:
.cfi_def_cfa_offset 4
.cfi_restore 3
LVL845:
ret
.cfi_endproc
LFE105:
.p2align 4,,15
.globl_rb_frame_this_func
.def_rb_frame_this_func;.scl2;.type32;.endef
_rb_frame_this_func:
LFB108:
.loc 2 791 0
.cfi_startproc
.loc 2 792 0
movl_ruby_current_thread, %eax
movl16(%eax), %eax
jmp_frame_func_id
LVL846:
.cfi_endproc
LFE108:

[Bug bootstrap/49555] libjava fails to configure if --enable-symvers=gnu or --enable-symvers=sun

[bryanhundven at gmail dot com]

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

--- Comment #8 from Bryan Hundven  2011-06-29 
19:30:42 UTC ---
Created attachment 24639
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24639
libjava-version_script-consistency.diff

[Bug bootstrap/49555] libjava fails to configure if --enable-symvers=gnu or --enable-symvers=sun

[bryanhundven at gmail dot com]

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

--- Comment #7 from Bryan Hundven  2011-06-29 
19:30:03 UTC ---
(In reply to comment #6)
> > I had a discussion with Yann E. Morin, and it sounds like this option was
> > ported forward from the legacy options in Dan Kegel's crosstool.
> >
> > The questions I am asking should be:
> >
> > * Should this ever (for any platform) be set manually? Or should this 
> > always be
> > an 'automatic' setting?
> 
> Except for the (experimental) gnu vs. gnu-versioned-namespace
> distinction in libstdc++-v3, I don't believe so.  We had a case where
> --disable-symvers/--enable-symvers=no was necessary as a workaround, but
> otherwise I'd prefer users to leave this alone.  Unfortunately, the
> configure checks in different target libraries are currently
> inconsistent.  I hope to get back to this at some point, though.

Ok. Thanks for the explanation!

> > * Isn't it inconsistent that every component checks for 'gnu*' and 'sun',
> > except for libjava?
> 
> In a way, it is, except that it matters for those components, but not
> for libjava.  But the check should be for gnu and sun alone,
> gnu-versioned-namespace is probably wrong here.
> 
> > Yann is currently retesting the sh4 build without --enable-symvers=gnu set 
> > to
> > see if it still needs it. If it does not, then he will remove it completely,
> > otherwise it should be target specific in crosstool-ng and not for all 
> > targets.
> 
> Excellent, thanks for checking this.
> 
> Rainer

So, Yann found that sh4 did not need this option anymore, and he has since
removed the --enable-symvers option from the build:

http://crosstool-ng.org/hg/crosstool-ng/rev/b24ead1a5947

So now we just let gcc figure it out.

As for the inconsistent check in libjava and the previous change to remove
enable-symvers from ct-ng in mind, this can probably be resolved as invalid
unless you'd like to just add gnu|sun to the
libjava_cv_anon_version_script=yes;; case. (attaching patch to give an
example).

wrt all of the extra configuration options, it would be very appreciated if in
another thread we could discuss some of them. I'm sure a lot of the options we
have for building binutils and gcc are ported forward from the older crosstool
scripts and aren't needed anymore. My theory on that has been: if it ain't
broke, don't fix it
...until now.

[Bug regression/49572] [4.4 Regression]: gcc.dg/tree-ssa/20030709-2.c scan-tree-dump-times cddce2 ".rtmem" 0

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #6 from Jeffrey A. Law  2011-06-29 19:26:53 
UTC ---
ISTM that DOM considering those two accesses equivalent, even though they had
different types is arguably incorrect behaviour.

I have vague memories that we played things a little fast and loose with types
of memory loads.  ie, if the destination had type T1, but the field reference
had type T2 and we knew that T1 and T2 were the same size, then we'd change the
type of the field reference to T1 and avoid the typecast from T2 to T1.  IIRC
we did this in the gimplifier.

Is that part of the problem here?

[Bug c++/49003] [C++0x][DR 1207] decltype in member function's trailing return type should deduce constness of *this

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug bootstrap/49584] [4.4.7 regression] bootstrap failure on m68k-linux: segfault compiling _muldi3

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.29 19:20:15
 CC||ebotcazou at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Eric Botcazou  2011-06-29 
19:20:15 UTC ---
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make[3]: *** [_muldi3.o] Error 1
> make[3]: Leaving directory
> `/mnt/scratch/objdir44/m68k-unknown-linux-gnu/libgcc'
> make[2]: *** [all-stage1-target-libgcc] Error 2
> make[2]: Leaving directory `/mnt/scratch/objdir44'
> make[1]: *** [stage1-bubble] Error 2
> make[1]: Leaving directory `/mnt/scratch/objdir44'
> make: *** [all] Error 2
> 
> The previous weekly snapshot, 4.4-20110621, bootstrapped fine.
> 
> I wasn't able to reproduce the error with 4.4-20110628 is built as a cross
> hosted on i686-linux, so I suspect a miscompilation in stage2 or stage3.

This is stage 1 though.

> I'll try a new bootstrap with r175603 reverted.

How do you build the stage 1 compiler?  With optimization enabled?

[Bug rtl-optimization/36884] ifcvt poor optimization

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.29 19:13:14
 CC||gjl at gcc dot gnu.org
  Component|middle-end  |rtl-optimization
 Ever Confirmed|0   |1
  Known to fail||4.6.1

--- Comment #3 from Georg-Johann Lay  2011-06-29 
19:13:14 UTC ---
I see same output like Andy in 4.6.1 and trunk.

Also played around with avr_rtx_costs in trunk, but that does not help; only
fix is -fno-if-conversion.

[Bug bootstrap/49584] New: [4.4.7 regression] bootstrap failure on m68k-linux: segfault compiling _muldi3

[mikpe at it dot uu.se]

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

   Summary: [4.4.7 regression] bootstrap failure on m68k-linux:
segfault compiling _muldi3
   Product: gcc
   Version: 4.4.7
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@it.uu.se


gcc-4.4-20110628 fails to bootstrap on m68k-linux:

Checking multilib configuration for libgcc...
make[3]: Entering directory
`/mnt/scratch/objdir44/m68k-unknown-linux-gnu/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
/mnt/scratch/objdir44/./gcc/xgcc -B/mnt/scratch/objdir44/./gcc/
-B/mnt/scratch/install44/m68k-unknown-linux-gnu/bin/
-B/mnt/scratch/install44/m68k-unknown-linux-gnu/lib/ -isystem
/mnt/scratch/install44/m68k-unknown-linux-gnu/include -isystem
/mnt/scratch/install44/m68k-unknown-linux-gnu/sys-include -g -O2 -O2  -g -O2
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wcast-qual -Wold-style-definition  -isystem ./include  -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I.
-I../.././gcc -I/mnt/scratch/gcc-4.4-20110621/libgcc
-I/mnt/scratch/gcc-4.4-20110621/libgcc/.
-I/mnt/scratch/gcc-4.4-20110621/libgcc/../gcc
-I/mnt/scratch/gcc-4.4-20110621/libgcc/../include  -DHAVE_CC_TLS -o _muldi3.o
-MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/mnt/scratch/gcc-4.4-20110621/libgcc/../gcc/libgcc2.c \
  -fvisibility=hidden -DHIDE_EXPORTS
In file included from /mnt/scratch/gcc-4.4-20110621/libgcc/../gcc/tsystem.h:44,
 from /mnt/scratch/gcc-4.4-20110621/libgcc/../gcc/libgcc2.c:29:
/mnt/scratch/objdir44/./gcc/include/stddef.h:149: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_muldi3.o] Error 1
make[3]: Leaving directory
`/mnt/scratch/objdir44/m68k-unknown-linux-gnu/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory `/mnt/scratch/objdir44'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir44'
make: *** [all] Error 2

The previous weekly snapshot, 4.4-20110621, bootstrapped fine.

I wasn't able to reproduce the error with 4.4-20110628 is built as a cross
hosted on i686-linux, so I suspect a miscompilation in stage2 or stage3.

I'll try a new bootstrap with r175603 reverted.

[Bug pch/49576] Option to suggest headers for addition to PCH

[olafvdspek at gmail dot com]

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

--- Comment #8 from Olaf van der Spek  2011-06-29 
19:01:53 UTC ---
/usr/include was just an example and not the main point of this feature
request.
I expect GCC devs to be smart enough to pick the best implementation of a
certain request themselves.

[Bug middle-end/47654] [4.6/4.7 Regression] gcc.dg/vect/no-section-anchors-vect-outer-4h.c FAILs with -floop-block

[spop at gcc dot gnu.org]

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

--- Comment #8 from Sebastian Pop  2011-06-29 18:44:55 
UTC ---
Patch set containing the work around and the fix
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02261.html

[Bug pch/49576] Option to suggest headers for addition to PCH

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  2011-06-29 
18:41:33 UTC ---
And how do I do that?

It would be better to do it for system dirs, not /usr/include, which would also
work for cross compilers where the sysroot is not under /usr

(this is what I mean about needing to clearly describe your desired semantics,
or nothing will happen)

[Bug c++/49575] OpenMP has a problem with -funroll-loops

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||openmp
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2011-06-29 
18:40:42 UTC ---
The problem isn't that the loop isn't unrolled, it is unrolled just fine.
The problem is that ompexp pass runs too early, no CCP is performed before
that, so it isn't able to figure out that k is constant in the loop unless you
explicitly say so or unless you declare it in the body of the parallel region.
We currently expand omp before SSA, while CCP needs SSA, but not sure what
kinds of issues could cause the pass reordering.
Alternative to reshuffling the passes would be to do some kind of OpenMP IPA
optimization, if constant/gimple invariant values are stored into the omp_data
structure, we could modify both the caller not to store them and callees to
replace all reads from that with the invariant.

[Bug pch/49576] Option to suggest headers for addition to PCH

[olafvdspek at gmail dot com]

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

--- Comment #6 from Olaf van der Spek  2011-06-29 
18:31:52 UTC ---
> why should they be excluded because they're not under /usr/include?

Because unless you tell GCC, GCC won't know they're good candidates.

[Bug pch/49576] Option to suggest headers for addition to PCH

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-06-29 
18:26:01 UTC ---
My company installs libraries under /foo/third-party and /foo/releases, those
files don't change, why should they be excluded because they're not under
/usr/include?

If you want a new feature you need to clearly explain the semantics you want.
Noone's going to take time to specify and implement a vague enhancement request
without clear semantics.

[Bug rtl-optimization/49114] Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const_int)))

[pthaugen at gcc dot gnu.org]

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

--- Comment #14 from Pat Haugen  2011-06-29 
18:21:23 UTC ---
Working fine now, thx.

[Bug tree-optimization/49583] New: Reloading stack operands in the wrong order, so needs to insert fxch

[sgunderson at bigfoot dot com]

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

   Summary: Reloading stack operands in the wrong order, so needs
to insert fxch
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sgunder...@bigfoot.com


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

Hi,

It seems that when generating x87 code, GCC sometimes reloads items from the
stack in the wrong order, and then goes to great lengths to swap them around. I
have an example with six loads and six fxch instructions, but attached is a
minimal example. Compiling with "gcc version 4.6.1 (Debian 4.6.1-1)" as
follows:

pannekake:~> gcc-4.6 -m32 -Wall -O2 -march=pentium3 -c fxch.c

The odd sequence is around this:

  41:d9 44 24 48  flds   0x48(%esp)
  45:dd 5c 24 08  fstpl  0x8(%esp)
  49:dd 14 24 fstl   (%esp)
  4c:d9 5c 24 10  fstps  0x10(%esp)
  50:e8 fc ff ff ff   call   51 
  55:d9 5c 24 1c  fstps  0x1c(%esp)
  59:d9 44 24 1c  flds   0x1c(%esp)
  5d:d9 44 24 10  flds   0x10(%esp)
  61:d9 c9fxch   %st(1)
  63:d9 1c b7 fstps  (%edi,%esi,4)
  66:46   inc%esi
  67:39 eecmp%ebp,%esi

In particular, why did it use fstps immediately followed by flds of the same
value? And if it really wants to reload (in my more complex example, it really
needs to), why not just do the loads in the right order from the start instead
of doing the fxch?

[Bug pch/49576] Option to suggest headers for addition to PCH

[olafvdspek at gmail dot com]

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

--- Comment #4 from Olaf van der Spek  2011-06-29 
18:12:24 UTC ---
Suppose your app has 10557 include directives. What do you add to your PCH?

Why /usr/include? Because these headers are unlikely to change, so they're a
good candidate for PCH.

[Bug c++/49568] [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to link on Tru64 UNIX

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.29 18:09:33
 CC||hubicka at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Jason Merrill  2011-06-29 
18:09:33 UTC ---
Confirmed, we shouldn't be emitting ~B because it's not needed.  Probably
introduced by r173517,

2011-05-06  Jan Hubicka  

* cgraph.c (cgraph_add_thunk): Create real function node instead
of alias node; finalize it and mark needed/reachale; arrange visibility
to be right and add it into the corresponding same comdat group list.
...

[Bug rtl-optimization/49230] please provide workaround for setjmp/longjmp in mingw32

[jojelino at gmail dot com]

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

--- Comment #6 from gee  2011-06-29 18:08:34 UTC ---
> $ gcc -v
i'm sorry to attach invalid gcc -v. this is proper one.
$ i686-pc-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=i686-pc-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-mingw32/4.7.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ./configure --config-cache --prefix=/usr
--enable-win32-registry --enable-threads=win32 --enable-languages=c,c++,lto
--with-win32-nlsapi=unicode --enable-tls --disable-bootstrap
--target=i686-pc-mingw32 --enable-shared --enable-interpreter
--disable-sjlj-exceptions --enable-gomp
Thread model: win32
gcc version 4.7.0 20110622 (experimental) (GCC)

[Bug rtl-optimization/49230] please provide workaround for setjmp/longjmp in mingw32

[jojelino at gmail dot com]

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

gee  changed:

   What|Removed |Added

  Known to work||4.6.0
  Known to fail||4.7.0

--- Comment #5 from gee  2011-06-29 18:07:14 UTC ---
and expected bar didn't show up
as it sigsegvs in msvcrt!nlg_notify

[Bug target/18145] Do not emit __do_copy_data or __do_clear_bss if .data or .bss is empty.

[eric.weddington at atmel dot com]

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

Eric Weddington  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug rtl-optimization/49230] please provide workaround for setjmp/longjmp in mingw32

[jojelino at gmail dot com]

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

--- Comment #4 from gee  2011-06-29 18:03:24 UTC ---
Created attachment 24637
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24637
generated asm with i686-pc-mingw32-gcc testsetjmp.c -S -s

> I compiled program with 4.6.0 gcc using mingw-w64 as runtime, and I get a 
> crash
yes this testcase crashes at epilogue of main if gcc doesn't do anything
but in latest gcc trunk, it doesn't work as expected. 
sorry. i forgot to say gcc version
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.7.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: ./configure --config-cache --prefix=/usr
--disable-win32-registry --enable-threads=win32 --enable-languages=c,c++,lto
--with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared
--disable-sjlj-exceptions --enable-gomp
Thread model: win32
gcc version 4.7.0 20110622 (experimental) (GCC)
and i attached asm code latest gcc trunk generated
i used i686-pc-mingw32-gcc testsetjmp.c -S -s to generate .s file.
 . please ld using attached asm file.
and i expect you and i get same result.
D:\cygwin\tmp>i686-pc-mingw32-gcc testsetjmp.s

D:\cygwin\tmp>a
start
foobar 10
foobar 9
foobar 8
foobar 7
foobar 6
foobar 5
foobar 4
foobar 3
foobar 2
foobar 1
foobar 0
(jit debugger message dialog shows)

[Bug bootstrap/45248] Stage 3 bootstrap comparison failure (powerpc-darwin8)

[fang at csl dot cornell.edu]

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

--- Comment #15 from David Fang  2011-06-29 
18:02:48 UTC ---
This bug can probably be closed.  --with-dwarf2 has been working for quite a
while.
http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg02820.html

[Bug bootstrap/49582] configure-target-libquadmath fail on powerpc-darwin8

[fang at csl dot cornell.edu]

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

--- Comment #1 from David Fang  2011-06-29 
17:57:34 UTC ---
My 32b-only powerpc arch is a G4, which really should have multilib disabled
for most components.  I couldn't find an option to
--disable-libquadmath-multilib.

[Bug c++/49272] [4.7 Regression] FAIL: g++.old-deja/g++.jason/rfg10.C (test for errors, line 11)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed|2011-06-25 00:00:00 |2011.06.29 17:39:46
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Jason Merrill  2011-06-29 
17:39:46 UTC ---
Should pass now.

[Bug c++/49272] [4.7 Regression] FAIL: g++.old-deja/g++.jason/rfg10.C (test for errors, line 11)

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2011-06-29 
17:38:58 UTC ---
Author: jason
Date: Wed Jun 29 17:38:53 2011
New Revision: 175659

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175659
Log:
PR c++/49272
* g++.old-deja/g++.jason/rfg10.C: Accept other overflow error too.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.old-deja/g++.jason/rfg10.C

[Bug pch/49576] Option to suggest headers for addition to PCH

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-06-29 
17:34:11 UTC ---
If your program has:
  #include "everything.h"
  #include 
and you have a PCH for everything.h.gch then something.h should be added to
everything.h

Isn't that easy enough?


I don't understand why only headers under /usr/include would be potentially
added, that's not the only use case for PCH

[Bug pch/49576] Option to suggest headers for addition to PCH

[olafvdspek at gmail dot com]

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

--- Comment #2 from Olaf van der Spek  2011-06-29 
17:32:02 UTC ---
So why exactly can't this be done?

[Bug rtl-optimization/49230] please provide workaround for setjmp/longjmp in mingw32

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Kai Tietz  2011-06-29 17:30:41 
UTC ---
Well, this test-file helps pretty much to see your problem.
As you didn't mentioned, which options you are specifying to gcc on
complilation, I assumed that you were using -fomit-frame-pointer and -O1. But
well, as described later, it doesn't really matters much here.

As register ebp is used by gcc as internal frame-register. Even if you are
specifying -fomit-frame-pointer as option, the main function will still have a
frame-pointer setup. Also ebp-register is a callee-saved register, which means
its use as local-register variable is in general nothing wise to do.

I compiled program with 4.6.0 gcc using mingw-w64 as runtime, and I get a crash
when main-function exits.  This is to be expected, as epilogue for main is

 movl %ebp, %esp
 pop  %ebp
 ret

but output looks as expected:

$ ./tst.exe
start
foobar 10
foobar 9
foobar 8
foobar 7
foobar 6
foobar 5
foobar 4
foobar 3
foobar 2
foobar 1
foobar 0
bar

So I mark this bug as invalid. If for you the code crashes by using mingw.org,
well then file a report to them.  This is for sure no gcc issue.

Regards,
Kai

[Bug bootstrap/49582] New: configure-target-libquadmath fail on powerpc-darwin8

[fang at csl dot cornell.edu]

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

   Summary: configure-target-libquadmath fail on powerpc-darwin8
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: f...@csl.cornell.edu
  Host: powerpc-apple-darwin8
Target: powerpc-apple-darwin8
 Build: powerpc-apple-darwin8


With release 4.6.1, on powerpc-darwin8, I get a build failure during
libquadmath.

Configuring with:
 --prefix=%p/lib/gcc4.6 --mandir=%p/share/man --infodir=%p/lib/gcc4.6/info
 --enable-languages=c,c++,fortran,lto,objc,obj-c++,java
 --with-gmp=%p --with-libiconv-prefix=%p --with-ppl=%p --with-cloog=%p
--with-mpc=%p --with-system-zlib
 --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.6 --enable-cloog-backend=isl --with-dwarf2
--disable-libjava-multilib

(where %p=/sw)

My build log shows:

Adding multilib support to Makefile in ../../../gcc-4.6
.1/libquadmath
multidirs=ppc64
with_multisubdir=
Running configure in multilib subdirs ppc64
pwd:
/Volumes/Mercedes2/sw/src/fink.build/gcc46-4.6.1-1000/darwin_objdir/powerpc
-apple-darwin8.11.0/libquadmath
Running configure in multilib subdir ppc64
pwd:
/Volumes/Mercedes2/sw/src/fink.build/gcc46-4.6.1-1000/darwin_objdir/powerpc
-apple-darwin8.11.0
no
checking for strerror... yes
checking for strsignal... yes
checking for sysconf... yes
checking for sysctl... configure: creating cache ./config.cache
checking build system type... yes
powerpc-apple-darwin8.11.0
checking host system type... checking for sysmp... powerpc-apple-darwin8.11.0
checking target system type... powerpc-apple-darwin8.11.0
checking for a BSD-compatible install... /sw/bin/ginstall -c
checking whether build environment is sane... no
checking for table... yes
yes
checking for a thread-safe mkdir -p... /sw/bin/gmkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... checking for times... yes
checking for --enable-version-specific-runtime-libs... no
checking for style of include used by make... GNU
checking for powerpc-apple-darwin8.11.0-gcc...
/Volumes/Mercedes2/sw/src/fink.bu
ild/gcc46-4.6.1-1000/darwin_objdir/./gcc/xgcc
-B/Volumes/Mercedes2/sw/src/fink.b
uild/gcc46-4.6.1-1000/darwin_objdir/./gcc/
-B/sw/lib/gcc4.6/powerpc-apple-darwin
8.11.0/bin/ -B/sw/lib/gcc4.6/powerpc-apple-darwin8.11.0/lib/ -isystem
/sw/lib/gc
c4.6/powerpc-apple-darwin8.11.0/include -isystem
/sw/lib/gcc4.6/powerpc-apple-da
rwin8.11.0/sys-include  -m64
yes
checking for wait3... checking for C compiler default output file name... yes
checking for wait4... a.out
checking whether the C compiler works... configure: error: in
`/Volumes/Mercedes
2/sw/src/fink.build/gcc46-4.6.1-1000/darwin_objdir/powerpc-apple-darwin8.11.0/pp
c64/libquadmath':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
yes
checking whether basename is declared... make[1]: ***
[configure-target-libquadm
ath] Error 1
make[1]: *** Waiting for unfinished jobs

(apologies if output is jumbled from parallel make)

The -m64 on a 32b-only arch is likely the issue.

Is libquadmath supported on 32b?  If so, how can we eliminate the -m64 from the
build?

[Bug debug/49364] [4.7 regressions] Empty .debug_abbrev sections confuse SGI nm

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-06-29 
17:28:45 UTC ---
Created attachment 24636
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24636
gcc47-pr49364.patch

Ugh, broken vendor tools.
Anyway, does the following patch fix it?  There is no need to emit
the .debug_abbrev section at all in that case...

[Bug c++/49554] [4.7 Regression] [C++0x] lambda capture causes "cannot call member function ... without object"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  2011-06-29 
17:26:50 UTC ---
Fixed.

[Bug c++/49520] [C++0x] using-declaration and operator&& confuses constexpr

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  2011-06-29 
17:26:03 UTC ---
Fixed.

[Bug pch/49576] Option to suggest headers for addition to PCH

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-06-29 
17:25:32 UTC ---
I don't think this can be done really.  Because of the way PCH works and the
way you are supposed to use PCH.  That is you are supposed to have a header
file which just includes many other headers and that is the PCH.

[Bug c++/49520] [C++0x] using-declaration and operator&& confuses constexpr

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-06-29 
17:15:20 UTC ---
Author: jason
Date: Wed Jun 29 17:15:16 2011
New Revision: 175658

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175658
Log:
PR c++/49520
* semantics.c (constexpr_fn_retval): Handle CLEANUP_POINT_EXPR here.
(massage_constexpr_body): Not here.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-using2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.def
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/49554] [4.7 Regression] [C++0x] lambda capture causes "cannot call member function ... without object"

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-06-29 
17:15:11 UTC ---
Author: jason
Date: Wed Jun 29 17:15:06 2011
New Revision: 175657

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175657
Log:
PR c++/49554
* semantics.c (lambda_proxy_type): New.
(build_capture_proxy): Use it.
* cp-tree.h (DECLTYPE_FOR_LAMBDA_PROXY): New.
* pt.c (tsubst) [DECLTYPE_TYPE]: Use them.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-template3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/49230] please provide workaround for setjmp/longjmp in mingw32

[jojelino at gmail dot com]

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

--- Comment #2 from gee  2011-06-29 17:08:41 UTC ---
Created attachment 24635
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24635
testcase

i hope it would be helpful
GNU gdb (GDB) 7.3.50.20110610-cvs
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
For bug reporting instructions, please see:
...

warning: the current range check setting does not match the language.


warning: the current type check setting does not match the language.

Whether backtraces should continue past the entry point of a program is off.
Reading symbols from /tmp/a...done.
(gdb) r
Starting program: /tmp/a
[New Thread 9616.0x1628]

Program received signal SIGSEGV, Segmentation fault.
0x77b66502 in msvcrt!_abnormal_termination ()
   from /cygdrive/c/WINDOWS/system32/msvcrt.dll
(gdb) bt
#0  0x77b66502 in msvcrt!_abnormal_termination ()
   from /cygdrive/c/WINDOWS/system32/msvcrt.dll
#1  0x77b6ac67 in strerror () from /cygdrive/c/WINDOWS/system32/msvcrt.dll
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) disassemble
Dump of assembler code for function msvcrt!_abnormal_termination:
   0x77b664cf <+0>: xor%eax,%eax
   0x77b664d1 <+2>: mov%fs:0x0,%ecx
   0x77b664d8 <+9>: cmpl   $0x77b66424,0x4(%ecx)
   0x77b664df <+16>:jne0x77b664f1 
   0x77b664e1 <+18>:mov0xc(%ecx),%edx
   0x77b664e4 <+21>:mov0xc(%edx),%edx
   0x77b664e7 <+24>:cmp%edx,0x8(%ecx)
   0x77b664ea <+27>:jne0x77b664f1 
   0x77b664ec <+29>:mov$0x1,%eax
   0x77b664f1 <+34>:ret
   0x77b664f2 <+35>:push   %ebx
   0x77b664f3 <+36>:push   %ecx
   0x77b664f4 <+37>:mov$0x77b919b0,%ebx
   0x77b664f9 <+42>:jmp0x77b66505 
   0x77b664fb <+44>:push   %ebx
   0x77b664fc <+45>:push   %ecx
   0x77b664fd <+46>:mov$0x77b919b0,%ebx
=> 0x77b66502 <+51>:mov0x8(%ebp),%ecx
   0x77b66505 <+54>:mov%ecx,0x8(%ebx)
   0x77b66508 <+57>:mov%eax,0x4(%ebx)
   0x77b6650b <+60>:mov%ebp,0xc(%ebx)
   0x77b6650e <+63>:push   %ebp
---Type  to continue, or q  to quit---q
Quit

[Bug c/49379] warning from Mac OS X linker alignment lost for -ftree-vectorize optimization

[d.g.gorbachev at gmail dot com]

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

--- Comment #7 from Dmitry Gorbachev  
2011-06-29 17:07:50 UTC ---
See also bug 48127.

[Bug fortran/49540] [4.6/4.7 Regression] Memory-hog with large DATA stmt

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.29 16:54:35
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #10 from Jakub Jelinek  2011-06-29 
16:54:35 UTC ---
Created attachment 24634
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24634
gcc47-pr49540.patch

Untested fix, which reintroduces repeat field.

[Bug target/47715] [x32] TLS doesn't work

[hjl at gcc dot gnu.org]

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

--- Comment #11 from hjl at gcc dot gnu.org  2011-06-29 
16:39:50 UTC ---
Author: hjl
Date: Wed Jun 29 16:39:45 2011
New Revision: 175654

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175654
Log:
Promote argument before checking non-legitimate constant.

2011-06-29  H.J. Lu  

PR middle-end/47715
* calls.c (precompute_register_parameters): Promote the function
argument before checking non-legitimate constant.

Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/calls.c

[Bug rtl-optimization/49114] Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const_int)))

[uweigand at gcc dot gnu.org]

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

--- Comment #13 from Ulrich Weigand  2011-06-29 
16:24:28 UTC ---
(In reply to comment #10)
> Created attachment 24633 [details]
> A patch to restore bootstrap

Huh, sorry for the duplicate patch ... I hadn't seen yours.

[Bug rtl-optimization/49114] Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const_int)))

[uweigand at gcc dot gnu.org]

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

--- Comment #12 from Ulrich Weigand  2011-06-29 
16:19:14 UTC ---
Author: uweigand
Date: Wed Jun 29 16:19:08 2011
New Revision: 175652

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175652
Log:
PR rtl-optimization/49114
* reload.c (push_reload): Define in_subreg_loc and out_subreg_loc
only if LIMIT_RELOAD_CLASS to avoid -Werror build breaks.

Modified:
trunk/gcc/reload.c

[Bug rtl-optimization/49114] Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const_int)))

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  2011-06-29 16:17:38 
UTC ---
(In reply to comment #9)
> Trunk now fails to build on PPC with the following:
> 
> /home/gccbuild/gcc_trunk_anonsvn/gcc/gcc/reload.c: In function ‘push_reload’:
> /home/gccbuild/gcc_trunk_anonsvn/gcc/gcc/reload.c:926:28: error: variable
> ‘out_subreg_loc’ set but not used [-Werror=unused-but-set-variable]
> /home/gccbuild/gcc_trunk_anonsvn/gcc/gcc/reload.c:926:8: error: variable
> ‘in_subreg_loc’ set but not used [-Werror=unused-but-set-variable]

Can you try the patch I uploaded?

[Bug rtl-optimization/49114] Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const_int)))

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  2011-06-29 16:17:03 
UTC ---
Created attachment 24633
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24633
A patch to restore bootstrap

[Bug c++/49520] [C++0x] using-declaration and operator&& confuses constexpr

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.29 16:09:03
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug tree-optimization/49539] [4.7 regression] ICE building gnattools

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.7.0   |4.6.2

--- Comment #9 from Eric Botcazou  2011-06-29 
16:07:36 UTC ---
Thanks for reporting the problem.

[Bug tree-optimization/49539] [4.7 regression] ICE building gnattools

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  2011-06-29 
16:04:51 UTC ---
Author: ebotcazou
Date: Wed Jun 29 16:04:47 2011
New Revision: 175651

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175651
Log:
PR tree-optimization/49539
* tree-ssa-forwprop.c (can_propagate_from): Check for abnormal SSA
names by means of stmt_references_abnormal_ssa_name.
(associate_plusminus): Call can_propagate_from before propagating
from definition statements.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/tree-ssa-forwprop.c

[Bug tree-optimization/49539] [4.7 regression] ICE building gnattools

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  2011-06-29 
16:03:00 UTC ---
Author: ebotcazou
Date: Wed Jun 29 16:02:56 2011
New Revision: 175650

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175650
Log:
PR tree-optimization/49539
* tree-ssa-forwprop.c (can_propagate_from): Check for abnormal SSA
names by means of stmt_references_abnormal_ssa_name.
(associate_plusminus): Call can_propagate_from before propagating
from definition statements.
(ssa_forward_propagate_and_combine): Remove superfluous newline.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug rtl-optimization/49114] Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const_int)))

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot
   ||gnu.org, uweigand at gcc
   ||dot gnu.org

--- Comment #9 from Pat Haugen  2011-06-29 
15:58:57 UTC ---
Trunk now fails to build on PPC with the following:

/home/gccbuild/gcc_trunk_anonsvn/gcc/gcc/reload.c: In function ‘push_reload’:
/home/gccbuild/gcc_trunk_anonsvn/gcc/gcc/reload.c:926:28: error: variable
‘out_subreg_loc’ set but not used [-Werror=unused-but-set-variable]
/home/gccbuild/gcc_trunk_anonsvn/gcc/gcc/reload.c:926:8: error: variable
‘in_subreg_loc’ set but not used [-Werror=unused-but-set-variable]

[Bug c++/49554] [4.7 Regression] [C++0x] lambda capture causes "cannot call member function ... without object"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.29 15:56:40
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug c/49581] New: [trans-mem] save/restore of thread-local data in nested txns is missing

[torvald at gcc dot gnu.org]

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

   Summary: [trans-mem] save/restore of thread-local data in
nested txns is missing
   Product: gcc
   Version: trans-mem
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: torv...@gcc.gnu.org


Created attachment 24632
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24632
test case

In the attached test case, stores to x[5] and x[6] in the nested txn do not get
rolled back. This happens if the nested txn is restarted by the TM runtime
library, or if the nested txn is aborted via __transaction_cancel.

[Bug target/49423] [arm] internal compiler error: in push_minipool_fix

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.29 15:35:12
 CC||ramana at gcc dot gnu.org
 Ever Confirmed|0   |1
  Known to fail||4.6.0, 4.6.1

--- Comment #5 from Ramana Radhakrishnan  2011-06-29 
15:35:12 UTC ---
doesn't seem to occur on 4.5 branch or on trunk. 

Ramana

[Bug rtl-optimization/49230] please provide workaround for setjmp/longjmp in mingw32

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #1 from Kai Tietz  2011-06-29 15:16:49 
UTC ---
Hmm, I can't confirm this. Do you have a testcase for this?
As far as I know has msvcrt's setjmp function an hidden argument, which should
be for 32-bit NULL.  This might be here the real issue.

[Bug tree-optimization/49580] SPEC2006 GCC benchmark build failure when run with autopar

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.29 15:07:38
 AssignedTo|unassigned at gcc dot   |razya at il dot ibm.com
   |gnu.org |
 Ever Confirmed|0   |1

[Bug target/48385] x86-64: Tail call recursion optimization with -mcmodel=large can generate invalid assembly (immediate operand illegal with absolute jump)

[martin at decky dot cz]

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

Martin Decky  changed:

   What|Removed |Added

Version|4.6.0   |4.6.1

--- Comment #1 from Martin Decky  2011-06-29 15:01:46 
UTC ---
The bug is still present in GCC 4.6.1.

[Bug pch/49579] Document how to use PCH with Automake

[olafvdspek at gmail dot com]

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

--- Comment #2 from Olaf van der Spek  2011-06-29 
14:46:00 UTC ---
I kinda agree, but:
Automake (and CMake) devs say they don't know how to properly support PCHs. So
maybe GCC devs could help them and ensure end users can use this feature of
GCC.

[Bug pch/49579] Document how to use PCH with Automake

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-06-29 
14:39:28 UTC ---
I think this should be an automake bug rather than a GCC one.

[Bug tree-optimization/49580] New: SPEC2006 GCC benchmark build failure when run with autopar

[razya at il dot ibm.com]

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

   Summary: SPEC2006 GCC benchmark build failure when run with
autopar
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ra...@il.ibm.com
CC: rakd...@gcc.gnu.org
  Host: power7 linux
Target: power7 linux
 Build: power7 linux


Compilation of reload1.c fails:

gcc -c -o reload1.o -DSPEC_CPU -DNDEBUG -I.  -fpeel-loops -funroll-loops
-fno-tree-vectorize -fno-vect-cost-model -fdump-tree-vect-details
-ftree-parallelize-loops=8 -fdump-tree-parloops-details -O3 
-falign-functions=16 -falign-loops=32 -m64  -ffast-math -O3 -mrecip=rsqrt
-fpeel-loops -funroll-loops -fno-tree-vectorize -fno-vect-cost-model
-fdump-tree-vect-details -ftree-parallelize-loops=8
-fdump-tree-parloops-details -greload1.c
reload1.c: In function ‘forget_old_reloads_1’:
reload1.c:4095:1: internal compiler error: in gsi_insert_seq_nodes_after, at
gimple-iterator.c:251
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The failure happens while parallellizing, in gimple_duplicate_sese_tail():

new_rhs = fold_build2 (MINUS_EXPR, TREE_TYPE (gimple_cond_rhs (cond_stmt)),
   gimple_cond_rhs (cond_stmt),
   build_int_cst (TREE_TYPE (gimple_cond_rhs
(cond_stmt)), 1));

if (TREE_CODE (gimple_cond_rhs (cond_stmt)) == SSA_NAME)
  {
iters_bb = gimple_bb (SSA_NAME_DEF_STMT (gimple_cond_rhs (cond_stmt)));
for (gsi1 = gsi_start_bb (iters_bb); !gsi_end_p (gsi1); gsi_next
(&gsi1))
  if (gsi_stmt (gsi1) == SSA_NAME_DEF_STMT (gimple_cond_rhs
(cond_stmt)))
break;

new_rhs = force_gimple_operand_gsi (&gsi1, new_rhs, true,
   
NULL_TREE,false,GSI_CONTINUE_LINKING);
  }

In this case, iters_bb contains the defining stmt for 
gimple_cond_rhs (cond_stmt), which is a gimple_phi stmt.
Therefore, iterating the stmts of iters_bb will not find the defining stmt
and the iterator for force_gimple_operand_gsi (&gsi1, new_rhs, true,...)
 will be NULL.

One solution could be to check whether the defining stmt is a gimple_phi stmt,
and handle that correctly.
However, there's one other case that is still not covered, that is if the
definition 
of gimple_cond_rhs (cond_stmt) is default_def (in which case iters_bb will be
NULL causing segmentation fault)

Instead of covering these two missing cases, it seems simpler and more elegant
to insert the stmt generated by force_gimple_operand_gsi (&gsi1, new_rhs,
true..) to the loop's preheader instead of inserting ti to iters_bb (the RHS of
the cond stmt is already defined before entering the loop, therefore can be
changed at the preheader)

Please assign this bug to me.
Thank you.

[Bug pch/49579] New: Document how to use PCH with Automake

[olafvdspek at gmail dot com]

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

   Summary: Document how to use PCH with Automake
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: pch
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olafvds...@gmail.com


PCH is a useful feature, but using it with automake isn't trivial. Could you
document how to use it?

[Bug c++/45923] constexpr diagnostics, more more

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill  2011-06-29 
14:35:03 UTC ---
Author: jason
Date: Wed Jun 29 14:34:58 2011
New Revision: 175646

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175646
Log:
PR c++/45923
* class.c (explain_non_literal_class): New.
(finalize_literal_type_property): Call it.
* cp-tree.h: Declare it.
* semantics.c (ensure_literal_type_for_constexpr_object): Call it.
(is_valid_constexpr_fn): Likewise.
(massage_constexpr_body): Split out from...
(register_constexpr_fundef): ...here.
(is_instantiation_of_constexpr): New.
(expand_or_defer_fn_1): Leave DECL_SAVED_TREE alone in that case.
(explain_invalid_constexpr_fn): New.
(cxx_eval_call_expression): Call it.
(potential_constant_expression_1): Likewise.  Avoid redundant errors.
* method.c (process_subob_fn): Diagnose non-constexpr.
(walk_field_subobs): Likewise.
(synthesized_method_walk): Don't shortcut if we want diagnostics.
(explain_implicit_non_constexpr): New.
(defaulted_late_check): Use it.
* call.c (build_cxx_call): Remember location.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-diag3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/class.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/method.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-diag1.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ex1.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-friend.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-incomplete2.C

[Bug libffi/46660] cls_double_va.c, cls_longdouble_va.c FAIL on IRIX 6.5

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-06-29 13:39:32 UTC ---
> This caused:
>
> FAIL: libffi.call/cls_double_va.c -O0 -W -Wall output pattern test, is 7.0
> FAIL: libffi.call/cls_double_va.c -O2 -fomit-frame-pointer output pattern 
> test,
> is 7.0
> FAIL: libffi.call/cls_double_va.c -O2 output pattern test, is 7.0
> FAIL: libffi.call/cls_double_va.c -O3 output pattern test, is 7.0
> FAIL: libffi.call/cls_double_va.c -Os output pattern test, is 7.0
> FAIL: libffi.call/cls_longdouble_va.c -O0 -W -Wall output pattern test, is 7.0
> FAIL: libffi.call/cls_longdouble_va.c -O2 -fomit-frame-pointer output pattern
> test, is 7.0
> FAIL: libffi.call/cls_longdouble_va.c -O2 output pattern test, is 7.0
> FAIL: libffi.call/cls_longdouble_va.c -O3 output pattern test, is 7.0
> FAIL: libffi.call/cls_longdouble_va.c -Os output pattern test, is 7.0
>
> on Linux/x86.

Already fixed:

http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02227.html

Rainer

[Bug libffi/46660] cls_double_va.c, cls_longdouble_va.c FAIL on IRIX 6.5

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  2011-06-29 13:37:45 
UTC ---
(In reply to comment #1)
> Author: ro
> Date: Wed Jun 29 07:31:05 2011
> New Revision: 175618
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175618
> Log:
> PR libffi/46660
> * testsuite/libffi.call/cls_double_va.c: xfail dg-output on
> mips-sgi-irix6*.
> * testsuite/libffi.call/cls_longdouble_va.c: Likewise.
> 
> Modified:
> trunk/libffi/ChangeLog
> trunk/libffi/testsuite/libffi.call/cls_double_va.c
> trunk/libffi/testsuite/libffi.call/cls_longdouble_va.c

This caused:

FAIL: libffi.call/cls_double_va.c -O0 -W -Wall output pattern test, is 7.0
FAIL: libffi.call/cls_double_va.c -O2 -fomit-frame-pointer output pattern test,
is 7.0
FAIL: libffi.call/cls_double_va.c -O2 output pattern test, is 7.0
FAIL: libffi.call/cls_double_va.c -O3 output pattern test, is 7.0
FAIL: libffi.call/cls_double_va.c -Os output pattern test, is 7.0
FAIL: libffi.call/cls_longdouble_va.c -O0 -W -Wall output pattern test, is 7.0
FAIL: libffi.call/cls_longdouble_va.c -O2 -fomit-frame-pointer output pattern
test, is 7.0
FAIL: libffi.call/cls_longdouble_va.c -O2 output pattern test, is 7.0
FAIL: libffi.call/cls_longdouble_va.c -O3 output pattern test, is 7.0
FAIL: libffi.call/cls_longdouble_va.c -Os output pattern test, is 7.0

on Linux/x86.

[Bug other/49578] New: Profiling: call graph table overflows on Solaris.

[a153dmw at warme dot net]

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

   Summary: Profiling: call graph table overflows on Solaris.
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a153...@warme.net


Created attachment 24631
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24631
Patch to increase max num edges in profile call graph under Solaris.

The Solaris implementation of profiling (-pg option) links in a
special gmon.o file that defines the mcount() routine, and related
functions.  (On Solaris, mcount() does not reside in libc.so, so
GCC must provide its own implementation.)

This implementation of mcount() creates linked lists of nodes
using an "unsigned short" as the link field to the next node.
This places a hard limit of 65533 edges in the call graph of any
program that is profiled -- a limitation that is easily exceeded
by modern programs.

The attached patch (made to the gcc-4.6.1 distribution) replaces
the pertinent "unsigned short" fields with "unsigned int", and
eliminates the upper bound when dynamically allocating the
"tos" table.  This enables profiling of large programs under
Solaris.

David Warme, Ph.D.
Principal Computer Scientist
Group W, Inc.
Fairfax, VA  22031
USA

[Bug target/43725] Poor instructions selection, scheduling and registers allocation for ARM NEON intrinsics

[siarhei.siamashka at gmail dot com]

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

--- Comment #6 from Siarhei Siamashka  
2011-06-29 13:35:13 UTC ---
Created attachment 24630
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24630
test.c

Attached a slightly updated testcase, which can demonstrate unnecessary spills
to stack even with more recent versions of gcc as explained in comment 2
earlier (just slightly increased the number of uses for X() macro)

[Bug rtl-optimization/48155] Reload doesn't handle subreg properly

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  2011-06-29 
13:34:25 UTC ---
Author: hjl
Date: Wed Jun 29 13:34:20 2011
New Revision: 175638

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175638
Log:
Add *lea_0_x32 to support addresses with complex expressions.

2011-06-28  H.J. Lu  

PR target/48155
* config/i386/i386.md (*lea_0_x32): New.
* config/i386/predicates.md (pointer_register_operand): Likewise.

Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/config/i386/i386.md
branches/x32/gcc/config/i386/predicates.md

[Bug rtl-optimization/49114] Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const_int)))

[hjl at gcc dot gnu.org]

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

--- Comment #8 from hjl at gcc dot gnu.org  2011-06-29 
13:33:25 UTC ---
Author: hjl
Date: Wed Jun 29 13:33:23 2011
New Revision: 175637

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175637
Log:
Remove SUBREG_LOC member from struct replacement.

2011-06-28  Ulrich Weigand  

PR rtl-optimization/49114
* reload.c (struct replacement): Remove SUBREG_LOC member.
(push_reload): Do not set it.
(push_replacement): Likewise.
(subst_reload): Remove dead code.
(copy_replacements): Remove assertion.
(copy_replacements_1): Do not handle SUBREG_LOC.
(move_replacements): Likewise.
(find_replacement): Remove dead code.  Use reload_adjust_reg_for_mode.
Detect subregs via recursive descent instead of via SUBREG_LOC.

Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/reload.c

[Bug rtl-optimization/49114] Reload failed to handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const_int)))

[hjl at gcc dot gnu.org]

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

--- Comment #7 from hjl at gcc dot gnu.org  2011-06-29 
13:32:42 UTC ---
Author: hjl
Date: Wed Jun 29 13:32:40 2011
New Revision: 175636

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175636
Log:
Don't handle (set reg:X (plus:X (subreg:X (reg:Y) 0) (const_int)))

2011-06-27  H.J. Lu  

PR rtl-optimization/49114
* reload1.c (gen_reload): Don't handle
(set reg:X (plus:X (subreg:X (reg:Y) 0) (const_int))).

Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/reload1.c