[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[nightstrike at gmail dot com]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot
   ||com

--- Comment #20 from nightstrike  2012-06-22 
02:44:36 UTC ---
Give this:
http://thread.gmane.org/gmane.comp.gcc.help/41456

Will further work happen on this PR, Jason?

[Bug fortran/42954] [4.5/4.6/4.7/4.8 regression] TARGET_*_CPP_BUILTINS issues with gfortran

[nightstrike at gmail dot com]

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

--- Comment #20 from nightstrike  2012-06-22 
02:05:45 UTC ---
As we're in 4.8 now, consider this a friendly ping :)

[Bug debug/49888] VTA: -O2 -g variable value changes, it does not change in the source

[aoliva at gcc dot gnu.org]

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

--- Comment #6 from Alexandre Oliva  2012-06-22 
01:33:27 UTC ---
Author: aoliva
Date: Fri Jun 22 01:33:21 2012
New Revision: 188869

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188869
Log:
PR debug/53671
PR debug/49888
* var-tracking.c (vt_init_cfa_base): Drop redundant recording of
CFA base.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c

--- Comment #7 from Alexandre Oliva  2012-06-22 
01:33:50 UTC ---
Author: aoliva
Date: Fri Jun 22 01:33:46 2012
New Revision: 188870

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188870
Log:
PR debug/53671
PR debug/49888
* var-tracking.c (vt_initialize): Record initial offset between
arg pointer and stack pointer.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c

--- Comment #8 from Alexandre Oliva  2012-06-22 
01:34:13 UTC ---
Author: aoliva
Date: Fri Jun 22 01:34:05 2012
New Revision: 188871

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188871
Log:
PR debug/53671
PR debug/49888
* var-tracking.c (vt_get_canonicalize_base): New.
(vt_canonicalize_addr, vt_stack_offset_p): New.
(vt_canon_true_dep): New.
(drop_overlapping_mem_locs): Use vt_canon_true_dep.
(clobber_overlaping_mems): Use vt_canonicalize_addr.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c

[Bug debug/53671] [4.8 Regression] Many guality test failures

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  2012-06-22 
01:33:26 UTC ---
Author: aoliva
Date: Fri Jun 22 01:33:21 2012
New Revision: 188869

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188869
Log:
PR debug/53671
PR debug/49888
* var-tracking.c (vt_init_cfa_base): Drop redundant recording of
CFA base.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c

--- Comment #5 from Alexandre Oliva  2012-06-22 
01:33:50 UTC ---
Author: aoliva
Date: Fri Jun 22 01:33:46 2012
New Revision: 188870

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188870
Log:
PR debug/53671
PR debug/49888
* var-tracking.c (vt_initialize): Record initial offset between
arg pointer and stack pointer.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c

--- Comment #6 from Alexandre Oliva  2012-06-22 
01:34:12 UTC ---
Author: aoliva
Date: Fri Jun 22 01:34:05 2012
New Revision: 188871

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188871
Log:
PR debug/53671
PR debug/49888
* var-tracking.c (vt_get_canonicalize_base): New.
(vt_canonicalize_addr, vt_stack_offset_p): New.
(vt_canon_true_dep): New.
(drop_overlapping_mem_locs): Use vt_canon_true_dep.
(clobber_overlaping_mems): Use vt_canonicalize_addr.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c

[Bug debug/53671] [4.8 Regression] Many guality test failures

[aoliva at gcc dot gnu.org]

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

--- Comment #4 from Alexandre Oliva  2012-06-22 
01:33:26 UTC ---
Author: aoliva
Date: Fri Jun 22 01:33:21 2012
New Revision: 188869

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188869
Log:
PR debug/53671
PR debug/49888
* var-tracking.c (vt_init_cfa_base): Drop redundant recording of
CFA base.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c

[Bug debug/49888] VTA: -O2 -g variable value changes, it does not change in the source

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  2012-06-22 
01:30:23 UTC ---
Author: aoliva
Date: Fri Jun 22 01:30:16 2012
New Revision: 188868

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188868
Log:
PR debug/53671
PR debug/49888
* alias.c (memrefs_conflict_p): Improve handling of AND for
alignment.

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

[Bug debug/53671] [4.8 Regression] Many guality test failures

[aoliva at gcc dot gnu.org]

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

--- Comment #3 from Alexandre Oliva  2012-06-22 
01:30:21 UTC ---
Author: aoliva
Date: Fri Jun 22 01:30:16 2012
New Revision: 188868

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188868
Log:
PR debug/53671
PR debug/49888
* alias.c (memrefs_conflict_p): Improve handling of AND for
alignment.

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

[Bug target/53682] [4.7/4.8 Regression] ICE in cselib_lookup (SEGV) on i586-linux-gnu

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  2012-06-22 
01:29:33 UTC ---
Author: aoliva
Date: Fri Jun 22 01:29:28 2012
New Revision: 188866

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188866
Log:
PR debug/53682
* cselib.c (promote_debug_loc): Don't crash on NULL argument.

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

[Bug c++/53651] [4.7/4.8 Regression] [C++11] seg fault when specifying using decltype(...)::method

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jason Merrill  2012-06-20 
07:22:39 UTC ---
Author: jason
Date: Wed Jun 20 07:22:34 2012
New Revision: 188813

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188813
Log:
PR c++/53651
* name-lookup.c (constructor_name_p): Don't try to look at the
name of a DECLTYPE_TYPE.

Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/decltype37.C
Modified:
branches/gcc-4_7-branch/gcc/cp/ChangeLog
branches/gcc-4_7-branch/gcc/cp/name-lookup.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

--- Comment #5 from Jason Merrill  2012-06-22 
00:35:48 UTC ---
Fixed for 4.7.2.

[Bug c/53702] [4.8 Regression] ICE with -Wall and nested functions and unused typedef

[meadori at gcc dot gnu.org]

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

meadori at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||meadori at gcc dot gnu.org
 Resolution||FIXED

--- Comment #5 from meadori at gcc dot gnu.org 2012-06-21 20:48:08 UTC ---
Fix committed.  Thanks for the report!

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  2012-06-21 
20:32:48 UTC ---
> Well, it did!-) The patch even fixed the PR (no regression with -m32, further
> testing in progress).

Testing finished without anything to report.

> I wonder if 
>
> -  if (!skip_nested)
> +  if (!subscript && !skip_nested)
>
> would not be enough?

Forget it! It does not work.

[Bug c/53702] [4.8 Regression] ICE with -Wall and nested functions and unused typedef

[meadori at gcc dot gnu.org]

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

--- Comment #4 from meadori at gcc dot gnu.org 2012-06-21 20:20:36 UTC ---
Author: meadori
Date: Thu Jun 21 20:20:30 2012
New Revision: 188860

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188860
Log:
PR c/53702

* c-decl.c (c_push_function_context): Restore the behavior to reuse
the language function allocated for -Wunused-local-typedefs.
(c_pop_function_context): If necessary, clear the language function
created in c_push_function_context.  Always clear out the
x_cur_stmt_list field of the restored language function.

testsuite/
* gcc.dg/Wunused-local-typedefs.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/Wunused-local-typedefs.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug ada/53747] New: Rep clause on index type makes 'access of aliased component an error when renaming

[georggcc at googlemail dot com]

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

 Bug #: 53747
   Summary: Rep clause on index type makes 'access of aliased
component an error when renaming
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: georg...@googlemail.com


Given the package spec

package Aliasing is

   type I is ('a', 'b', 'c');
   for I use (11, 22, 33);  --!

   type T is range 1 .. 10;
   type Ary is array (I) of aliased T;
   type Ptr is access constant T;

   Vs : Ary;
   Nm : T renames Vs('b');
   X : Ptr := Nm'Access;

end Aliasing;

then only if the line marked --! is commented, the unit is fine.
Otherwise,

$ gnatmake -gnatwa -gnatv aliasing.ads
gcc -c -gnatwa -gnatv aliasing.ads

GNAT 4.8.0 20120621 (experimental)
Copyright 1992-2012, Free Software Foundation, Inc.

Compiling: aliasing.ads (source file time stamp: 2012-06-21 19:52:03)

==Error messages for source file: aliasing.ads
--Line numbers from file: aliasing.ada (starting at line 1)
12.X : Ptr := Nm'Access;
  |
>>> prefix of "Access" attribute must be aliased

 15 lines: 1 error

I'd think this is an incorrect diagnosis.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/Users/bauhaus/mine/libexec/gcc/x86_64-apple-darwin11.4.0/4.8.0/lto-wrapper
Target: x86_64-apple-darwin11.4.0
Configured with: /Users/bauhaus/src/gcc/configure --prefix=/Users/bauhaus/mine
--disable-nls --disable-multilib --disable-libstdcxx-pch
--enable-languages=c,ada,c++
Thread model: posix
gcc version 4.8.0 20120621 (experimental) (GCC) 

$ sw_vers 
ProductName:Mac OS X
ProductVersion:10.7.4
BuildVersion:11E53

[Bug fortran/39654] ABI bug: FTELL intrinsic function not capable of large files

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Janne Blomqvist  2012-06-21 19:53:06 
UTC ---
Fixed, closing.

[Bug ada/50048] "cc1: note: obsolete option -I- used, please use -iquote instead" during bootstrap

[nightstrike at gmail dot com]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot
   ||com

--- Comment #1 from nightstrike  2012-06-21 
19:16:14 UTC ---
This is still a problem for 4.8.0.  Offending lines are around line 270:


# Specify the directories to be searched for header files.
# Both . and srcdir are used, in that order,
# so that tm.h and config.h will be found in the compilation
# subdirectory rather than in the source directory.
INCLUDES = -I- -I. -I.. -I$(srcdir)/ada -I$(srcdir) -I$(srcdir)/../include

ADA_INCLUDES = -I- -I. -I$(srcdir)/ada

[Bug fortran/39654] ABI bug: FTELL intrinsic function not capable of large files

[jb at gcc dot gnu.org]

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

--- Comment #8 from Janne Blomqvist  2012-06-21 18:47:06 
UTC ---
Author: jb
Date: Thu Jun 21 18:47:01 2012
New Revision: 188858

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188858
Log:
PR 39654 FTELL intrinsic function return type.

frontend ChangeLog:

2012-06-21  Janne Blomqvist  

PR fortran/39654
* iresolve.c (gfc_resolve_ftell): Fix result kind and use new
library function.


library ChangeLog:

2012-06-21  Janne Blomqvist  

PR fortran/39654
* io/intrinsics.c (ftell2): New function.
* gfortran.map (_gfortran_ftell2): Export function.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/iresolve.c
trunk/libgfortran/ChangeLog
trunk/libgfortran/gfortran.map
trunk/libgfortran/io/intrinsics.c

[Bug c++/53745] [C++11] Poor diagnostic for ill-formed narrowing conversion in enumerator initializer

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2012-06-21
 Resolution|INVALID |
Summary|Bitshifted value (1 << 31)  |[C++11] Poor diagnostic for
   |within enumerator class is  |ill-formed narrowing
   |calculated incorrectly  |conversion in enumerator
   |during compilation. |initializer
 Ever Confirmed|0   |1

--- Comment #3 from Jonathan Wakely  2012-06-21 
17:51:43 UTC ---
Re-opening since the diagnostic could be better, the value is not "too large",
the problem is with the sign, not the magnitude.

enum E : unsigned long long { e = -1 };

e.cc:1:26: error: enumerator value -1 is too large for underlying type
'unsigned long long'

Clang gives a more accurate diagnostic, though not necessarily more helpful if
you don't know what a narrowing conversion is:

e.cc:1:25: error: enumerator value evaluates to -1, which cannot be narrowed to
type 'unsigned long long' [-Wc++11-narrowing]

[Bug lto/53746] [lto] segfault in std::vector::__base_ctor

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #1 from Markus Trippelsdorf  
2012-06-21 17:12:52 UTC ---
Just in case you haven't read it already.
 http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction#Reducing_LTO_bugs
might be helpful.

[Bug target/16331] x86-64 inline asm register constraints insufficient WRT ABI

[gcc at kalvdans dot no-ip.org]

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

Christian Häggström  changed:

   What|Removed |Added

 CC||gcc at kalvdans dot
   ||no-ip.org

--- Comment #16 from Christian Häggström  
2012-06-21 17:11:11 UTC ---
Can this bug be closed as it works with gcc 3.3.6 as expressed in comment #6?
Otherwise, please state again clearly what is still broken since it is hard to
follow the discussion.

[Bug lto/53746] New: [lto] segfault in std::vector::__base_ctor

[vincenzo.innocente at cern dot ch]

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

 Bug #: 53746
   Summary: [lto] segfault in  std::vector::__base_ctor
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


this is a place holder pending the production of a "reasonable size" test-case

I have a library (just one out of 2000!) in which I get a segfault at runtime
in constructing a vector (data member of class).
the library is made out of 10 compilation units

from the stack trace below it seems that a "0" pointer is passed as "target" of
a memmove

the code involved (main + "host"-constructor) is few lines long BUT
the difficulty in reducing the whole library in a test-case is that it works
with -flto-partition=1to1
if I "cat" all 10 compilation units in a single one
if I delete 5 of the compilation units (almost at random, besides the one
containing the code where the crash occurs)
if I ADD the following trivial compilation unit (not sure the content
matters...)
cat a1.cc 
#include 
std::vector a1(std::vector v, int a) {
  v.push_back(a); return v;
}

so to reproduce the crash a "lot" of other code need to be present and in a
given configuration 
I'll try at least to reduce the dependencies from external libraries, still it
will take time.

any suggesting on how to proceed in the debug process (or involve any of you)
is appreciated

"segfault"

Breakpoint 2, 0x003a4f679580 in memmove () from /lib64/libc.so.6
#0  0x003a4f679580 in memmove () from /lib64/libc.so.6
#1  0x2aac3b89 in __copy_m (__result=0x0, __last=,
__first=0xfbc000)
at
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algobase.h:366
#2  std::vector::__base_ctor (this=0xfbc238, __x=)
at
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algobase.h:384
#3  0x2aad619a in HybridClusterAlgo::HybridClusterAlgo (this=0xfbc100,
eb_str=, step=, ethres=,
eseed=, xi=, 
useEtForXi=, ewing=, v_chstatus=, posCalculator=..., dynamicEThres=, eThresA=, eThresB=, 
severityToExclude=..., excludeFromCluster=false) at
/build/vin/bug/CMSSW_6_0_0_pre7/src/RecoEcal/EgammaClusterAlgos/src/HybridClusterAlgo.cc:38
#4  0x00404f8b in main (s=) at
/build/vin/bug/CMSSW_6_0_0_pre7/src/RecoEcal/EgammaClusterAlgos/test/HybridClusterTest.cpp:63

"runs"

Breakpoint 2, 0x003a4f679580 in memmove () from /lib64/libc.so.6
#0  0x003a4f679580 in memmove () from /lib64/libc.so.6
#1  0x2aabe0e5 in std::__copy_move::__copy_m (__first=,
__last=, __result=0xfbc2b0)
at
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algobase.h:366
#2  0x2aac699c in std::vector::__base_ctor (this=0xfbc238, __x=...)
at
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/bits/stl_algobase.h:384
#3  0x2aad740a in HybridClusterAlgo::HybridClusterAlgo (this=0xfbc100,
eb_str=, step=, ethres=,
eseed=, xi=, 
useEtForXi=, ewing=, v_chstatus=, posCalculator=..., dynamicEThres=, eThresA=, eThresB=, severityToExclude=..., 
excludeFromCluster=false) at
/build/vin/bug/CMSSW_6_0_0_pre7/src/RecoEcal/EgammaClusterAlgos/src/HybridClusterAlgo.cc:38
#4  0x00404f8b in main (s=) at
/build/vin/bug/CMSSW_6_0_0_pre7/src/RecoEcal/EgammaClusterAlgos/test/HybridClusterTest.cpp:63

[Bug c++/53646] Surprising effects of cxx11 vs cxx98 ABI compatibility

[matz at gcc dot gnu.org]

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

--- Comment #21 from Michael Matz  2012-06-21 15:32:07 
UTC ---
(In reply to comment #20)
> certainty.  But it wouldn't have helped me that much further.  I still would 
> have had to find out which functions were causing the wild write in order
> to say with confidence that this is really the cause for the problem, and
> not something like a normal program error.

To expand on that: I had to do so because this particular std::list isn't part
of any external API of the libraries in question, it's not passed around
or returned, it's purely an internal implementation detail.  Our wiki page
makes it sound as if only using the problematic types in the external API
is an issue.  That is not the case, it's already just _using_ these types
that's problematic.

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

[adrian.m.smith at gmail dot com]

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

Adrian Smith  changed:

   What|Removed |Added

 CC||adrian.m.smith at gmail dot
   ||com

--- Comment #3 from Adrian Smith  2012-06-21 
15:27:49 UTC ---
"As mentioned in the thread to the list you need to compile crtstuff.c with
-mcmodel=large also."

Can someone add a link to the thread? I have googled for it but this bug report
keeps on coming up. I am not too familiar with gcc development so don't know
which list is being talked about.

I too have a program which requires > 2GB of compiled code on x86-64 and get
the errors from "crtstuff.c". But where is it, how do I recompile it?

[Bug c++/53646] Surprising effects of cxx11 vs cxx98 ABI compatibility

[matz at gcc dot gnu.org]

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

--- Comment #20 from Michael Matz  2012-06-21 15:25:59 
UTC ---
As I stumbled over this problem complex recently already I had a hunch that it
might again be a 11/98 mixture.  Having the symbols would have made that a
certainty.  But it wouldn't have helped me that much further.  I still would 
have had to find out which functions were causing the wild write (after all,
an 11/98 mixture in itself is not the problem, the library authors for
instance might have controlled their exports) in order to say with confidence
that this is really the cause for the problem, and not something like a
normal program error.

Of course if the implementation of PR 53673 would make it so, that such
programs can't even be link edited or if so, then at least not be run (the
dynamic linker could throw an error for instance) then this problem wouldn't
have turned up.  OTOH, that's fairly unforgiving and could still be worked
around by the user by for instance specifically hiding such magic symbol.
(Although, if he's able to hide that magic symbol he should also be able to
hide all the other reexported libstdc++ symbols).

I btw. wonder if all these weak symbols of libstdc++, that right now
are reexported by default, shouldn't get hidden visibility.  Would make
(non-inlined) calls faster, and avoid the cross-c++-std-domain resolving
leading to this problem.  At least on targets that support visibility.

[Bug rtl-optimization/53706] [4.8 Regression] Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)

[ubizjak at gmail dot com]

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

--- Comment #12 from Uros Bizjak  2012-06-21 15:23:51 
UTC ---
(In reply to comment #10)
> Patch that fixes all valgrind issues, but I have no idea if it is OK or not:

The patch doesn't pass the bootstrap.

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  2012-06-21 
15:07:58 UTC ---
> [*] Carefully crafted with love and patience, using the ancestral methods and
> tools available to the windows users (i.e. Notepad.exe).
> In other words, the patch may not apply cleanly.

Well, it did!-) The patch even fixed the PR (no regression with -m32, further
testing in progress).

I wonder if 

-  if (!skip_nested)
+  if (!subscript && !skip_nested)

would not be enough?

Note that there is a temporary that is not needed if I am not mistaken:

[macbook] f90/bug% gfc pr53732.f90 -Warray-temporaries
pr53732.f90:8.18:

arr(1, :, :, :) = sum(arr, dim=1, mask=(arr(:,:,:,:) > 0d0))
  1
Warning: Creating array temporary at (1)

a(k)=sum(a) can be scalarized as

do i=lb,ub
if (i /= k) a(k) = a(k)+a(i)
end do

Thanks for the quick patch.

[Bug c++/53646] Surprising effects of cxx11 vs cxx98 ABI compatibility

[redi at gcc dot gnu.org]

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

--- Comment #19 from Jonathan Wakely  2012-06-21 
14:46:22 UTC ---
Do you have an opinion on PR 53673 ?
Would having those symbols make debugging such problems easier, or did you
already know there was a mix of c++98 and c++11 objects and the difficult part
was identifying exactly where the problem happened?

[Bug fortran/53694] [OOP] GENERIC type-bound procs should be available without part-ref syntax

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  2012-06-21 
14:39:32 UTC ---
Actually, I am no longer sure that this PR is valid - nor is Richard Maine in
c.l.f. Janus seems to have the same doubts, if I read comment 5 correctly.

The standard seems to make a distinction between 'generic type-bound procedure'
and 'generic procedure name'.

[Bug c++/53646] Surprising effects of cxx11 vs cxx98 ABI compatibility

[matz at gcc dot gnu.org]

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

--- Comment #18 from Michael Matz  2012-06-21 14:36:29 
UTC ---
Just today I had to debug another crash in our package management code.
This time a c++98 library picked up a std::list operator= from a c++11
library resulting in a crash.  See
  https://bugzilla.novell.com/show_bug.cgi?id=767666

It was all quite non-obvious, as many libraries and packages are involved
and it's not easy to find out what the problematic symbol resolution is.
This may be an intended ABI breakage in c++11 mode (the std::list change I
mean), but it has all the same problems as the unintended bug in std::pair.

[Bug c++/53741] ICE on lambda calling static template member function with explicit template argument specification

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2012-06-21 14:31:02 UTC ---
The test case works in gcc 4.8.0 20120610 (experimental)

[Bug c++/53745] Bitshifted value (1 << 31) within enumerator class is calculated incorrectly during compilation.

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-06-21 
13:36:24 UTC ---
The initializer must be converted constant expression of type unsigned long, so
by my reading it's ill-formed because (1<<31) has type int and is negative so
requires a narrowing conversion to unsigned long.

[Bug c++/53745] Bitshifted value (1 << 31) within enumerator class is calculated incorrectly during compilation.

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

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

Andreas Schwab  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andreas Schwab  2012-06-21 13:35:26 
UTC ---
1<<31 is an expression of type int, and overflows when int has 32 bits.  This
is independent of the context of its use.  You should write 1UL<<31 instead.

[Bug rtl-optimization/53706] [4.8 Regression] Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)

[uweigand at gcc dot gnu.org]

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

Ulrich Weigand  changed:

   What|Removed |Added

 CC||uweigand at gcc dot gnu.org

--- Comment #11 from Ulrich Weigand  2012-06-21 
13:18:53 UTC ---
I'm seeing what appears to be a similar issue bootstrapping powerpc64:

*** glibc detected ***
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus: corrupted
double-linked list: 0x11afd980 ***
=== Backtrace: =
/lib64/power6x/libc.so.6[0x80f2ff9bd0]
/lib64/power6x/libc.so.6[0x80f2ffba4c]
/lib64/power6x/libc.so.6(cfree-0x117fc8)[0x80f2ffc050]
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus(_Z16empty_alloc_poolP14alloc_pool_def-0xd186ac)[0x1035da6c]
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus(_Z15free_alloc_poolP14alloc_pool_def-0xd18638)[0x1035daf8]
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus[0x109b81dc]
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus(_Z22variable_tracking_mainv-0x6e1734)[0x109cd57c]
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus(_Z16execute_one_passP8opt_pass-0xa1248c)[0x1067f7cc]
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus(_Z17execute_pass_listP8opt_pass-0xa1203c)[0x1067fc34]
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus(_Z17execute_pass_listP8opt_pass-0xa12024)[0x1067fc4c]
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus(_Z17execute_pass_listP8opt_pass-0xa12024)[0x1067fc4c]
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus[0x103e4ea8]
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus(_Z7compilev-0xc935c4)[0x103e7474]
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus(_Z25finalize_compilation_unitv-0xc92e84)[0x103e7bcc]
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus(_Z28cp_write_global_declarationsv-0xeb57fc)[0x101b5414]
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus[0x1074b894]
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus(_Z11toplev_mainiPPc-0x94c944)[0x1074da44]
/home/uweigand/fsf/gcc-head-build-ppu/./prev-gcc/cc1plus(main-0x436788)[0x10c8d4b0]
/lib64/power6x/libc.so.6[0x80f2f99d34]
/lib64/power6x/libc.so.6(__libc_start_main-0x176cf0)[0x80f2f99fd0]

[Bug c++/53745] New: Bitshifted value (1 << 31) within enumerator class is calculated incorrectly during compilation.

[sbgccbug at yahoo dot co.uk]

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

 Bug #: 53745
   Summary: Bitshifted value (1 << 31) within enumerator class is
calculated incorrectly during compilation.
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sbgcc...@yahoo.co.uk


When compiling an 'enum class' (-std=c++0x) that uses bit-shifted values, the
result of "1 << 31" is calculated incorrectly, resulting in -0x8000
(*negative* 2^31) rather than the correct result of 0x8000:

// *** BEGIN EXAMPLE CODE (main.cpp) ***

enum class EnumTest : unsigned long int
{
   A = 1 << 30,
   B = 1 << 31
};

int main()
{
   return 0;
}

// *** END EXAMPLE CODE ***

// *** BEGIN gcc-4.6.1 OUTPUT ***

main.cpp|4|error: enumerator value -0x08000 is too large for
underlying type ‘long unsigned int’|

// *** END gcc-4.6.1 OUTPUT ***

[Bug tree-optimization/53726] [4.8 Regression] aes test performance drop for eembc_2_0_peak_32

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME

--- Comment #21 from H.J. Lu  2012-06-21 12:55:33 
UTC ---
(In reply to comment #18)
> > string/memory functions in libc can be much faster than the ones generated
> > by GCC unless the size is very small, PR 43052.
> 
> Yes.  The question is what is "very small" and how can we possibly
> detect "very small".  For this testcase we can derive an upper bound
> of the size, which is 8, but the size is not constant.  I think unless
> we know we can expand the variable-size memcpy with, say, three
> CPU instructions inline there is no reason to not call memcpy.

It is OK to call memcpy if the size isn't constant.

> 
> Which would leave us to inline expanding the case of at most 2 byte
> memcpy.  Of course currently there is no way to record an upper
> bound for the size (we do not retain value-range information - but
> we of course should).

It is nice to have.  We can open another bug for this.

[Bug middle-end/53688] [4.8 Regression] 191.fma3d in SPEC CPU 2000 miscompiled

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||matz at gcc dot gnu.org
 Resolution||FIXED

--- Comment #5 from Michael Matz  2012-06-21 12:52:18 
UTC ---
Fixed.

[Bug tree-optimization/53726] [4.8 Regression] aes test performance drop for eembc_2_0_peak_32

[hjl.tools at gmail dot com]

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

--- Comment #20 from H.J. Lu  2012-06-21 12:50:21 
UTC ---
(In reply to comment #19)
> 
> I rechecked there is no regression without static on Sundy Bridge nor Atom.

Great.  Please verify that -static isn't used on eembc and SPEC
CPU 2000/2006 runs.

[Bug fortran/53732] [4.7/4.8 Regression] "mismatching comparison operand types" on compile

[mikael at gcc dot gnu.org]

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

--- Comment #5 from Mikael Morin  2012-06-21 
12:48:51 UTC ---
Created attachment 27686
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27686
"shot in the dark" patch[*]

[*] Carefully crafted with love and patience, using the ancestral methods and
tools available to the windows users (i.e. Notepad.exe).
In other words, the patch may not apply cleanly.

[Bug tree-optimization/53726] [4.8 Regression] aes test performance drop for eembc_2_0_peak_32

[vbyakovl23 at gmail dot com]

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

--- Comment #19 from Vladimir Yakovlev  2012-06-21 
12:46:11 UTC ---
(In reply to comment #13)
> (In reply to comment #10)
> > I've tried without static. Runtimes is still the same.
> 
> It doesn't match what I saw.  On Atom D510:
> 
> /export/gnu/import/git/gcc-regression/master/188261/usr/bin/gcc -ansi -O3
> -ffast-math -msse2 -mfpmath=sse -m32   -march=atom m.c test.c -o new
> time ./new
> ./new  58.46s user 0.00s system 99% cpu 58.479 total
> /export/gnu/import/git/gcc-regression/master/188259/usr/bin/gcc -ansi -O3
> -ffast-math -msse2 -mfpmath=sse -m32   -march=atom m.c test.c -o old
> time ./old
> ./old  58.38s user 0.00s system 99% cpu 58.490 total

I rechecked there is no regression without static on Sundy Bridge nor Atom.

[Bug middle-end/38756] 107t.ivopts introduces pointer truncation

[bigotp at acm dot org]

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

--- Comment #5 from Peter A. Bigot  2012-06-21 12:24:38 
UTC ---
Yes, that's where it happens.  Your proposal makes sense; I've just been trying
to avoid changing existing behavior on "normal" platforms.

I'll give the unconditional solution a try on the next regression suite run.

[Bug middle-end/53688] [4.8 Regression] 191.fma3d in SPEC CPU 2000 miscompiled

[matz at gcc dot gnu.org]

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

--- Comment #4 from Michael Matz  2012-06-21 12:18:31 
UTC ---
Author: matz
Date: Thu Jun 21 12:18:23 2012
New Revision: 188852

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188852
Log:
PR middle-end/53688
* builtins.c (get_memory_rtx): Always build an all-aliasing MEM_REF
with correct size.

testsuite/
* gcc.c-torture/execute/pr53688.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr53688.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/53743] ICE when compiling firefox with PGO and LTO

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org, rth at gcc dot
   ||gnu.org

--- Comment #7 from Richard Guenther  2012-06-21 
12:13:57 UTC ---
With checking enabled on the top of the branch I get

/home/ioctl/ff-build-semilto/src/mozilla-release/xpcom/string/src/nsSubstring.cpp:
In member function 'void
nsACString_internal::Replace(nsACString_internal::index_type,
nsACString_internal::size_type, const char_type*,
nsACString_internal::size_type)':
/home/ioctl/ff-build-semilto/src/mozilla-release/xpcom/string/src/nsSubstring.cpp:339:104:
note: correcting inconsistent profile data
In file included from
/home/ioctl/ff-build-semilto/src/mozilla-release/xpcom/string/src/nsSubstring.cpp:325:0:
/home/ioctl/ff-build-semilto/src/mozilla-release/xpcom/string/src/nsTSubstring.cpp:
In member function 'bool nsAString_internal::Equals(const char_type*) const':
/home/ioctl/ff-build-semilto/src/mozilla-release/xpcom/string/src/nsTSubstring.cpp:618:3:
error: EDGE_CROSSING incorrectly set across same section
/home/ioctl/ff-build-semilto/src/mozilla-release/xpcom/string/src/nsTSubstring.cpp:618:3:
error: missing barrier after block 5

Breakpoint 1, internal_error (gmsgid=0x171fe90 "verify_flow_info failed")
at /space/rguenther/src/svn/gcc-4_7-branch/gcc/diagnostic.c:843
843   va_start (ap, gmsgid);

(gdb) p *pass
$1 = {type = RTL_PASS, name = 0x1743680 "pro_and_epilogue", gate = 0x0, 
  execute = 0xbc939f , sub = 0x0, 
  next = 0x1d53d80 , static_pass_number = 209, 
  tv_id = TV_THREAD_PROLOGUE_AND_EPILOGUE, properties_required = 0, 
  properties_provided = 0, properties_destroyed = 0, 
  todo_flags_start = 524296, todo_flags_finish = 394242}

[Bug middle-end/38756] 107t.ivopts introduces pointer truncation

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  
2012-06-21 12:12:24 UTC ---
On Thu, 21 Jun 2012, bigotp at acm dot org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38756
> 
> --- Comment #3 from Peter A. Bigot  2012-06-21 
> 12:04:34 UTC ---
> commit af66de00843896ad5d2980952994b31cadbf8421
> Author: Peter A. Bigot 
> Date:   Thu Jun 21 06:35:44 2012 -0500
> 
> Anticipatory patch for PR middle-end/38756
> 
> Do not truncate to size_type when adding the step factor to a pointer.
> 
> diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c
> index 0693c21..f8372fd 100644
> --- a/gcc/tree-ssa-loop-ivopts.c
> +++ b/gcc/tree-ssa-loop-ivopts.c
> @@ -6199,6 +6199,11 @@ rewrite_use_nonlinear_expr (struct ivopts_data *data,
>step = cand->iv->step;
>ctype = TREE_TYPE (step);
>utype = TREE_TYPE (cand->var_after);
> +  if (TYPE_PRECISION (ctype) < TYPE_PRECISION (utype))
> +   {
> + ctype = generic_type_for (utype);
> + step = fold_convert (ctype, unshare_expr (step));
> +   }
>if (TREE_CODE (step) == NEGATE_EXPR)
> {
>   incr_code = MINUS_EXPR;

So the truncation happens here?

  /* Otherwise, add the necessary computations to express
 the iv.  */
  op = fold_convert (ctype, cand->var_before);
  comp = fold_convert (utype,
   build2 (incr_code, ctype, op,
   unshare_expr (step)));

I think it makes sense to do the computation in
generic_type_for (utype) anyways - even if that truncates the
step.  Because we truncate to utype anyways.

Thus

  type = generic_type_for (utype);
  op = fold_convert (type, cand->var_before);
  comp = fold_convert (utype,
   fold_build2 (incr_code, type, op,
fold_convert (type, unshare_expr 
(step;

unconditionally.

[Bug middle-end/38756] 107t.ivopts introduces pointer truncation

[bigotp at acm dot org]

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

--- Comment #3 from Peter A. Bigot  2012-06-21 12:04:34 
UTC ---
commit af66de00843896ad5d2980952994b31cadbf8421
Author: Peter A. Bigot 
Date:   Thu Jun 21 06:35:44 2012 -0500

Anticipatory patch for PR middle-end/38756

Do not truncate to size_type when adding the step factor to a pointer.

diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c
index 0693c21..f8372fd 100644
--- a/gcc/tree-ssa-loop-ivopts.c
+++ b/gcc/tree-ssa-loop-ivopts.c
@@ -6199,6 +6199,11 @@ rewrite_use_nonlinear_expr (struct ivopts_data *data,
   step = cand->iv->step;
   ctype = TREE_TYPE (step);
   utype = TREE_TYPE (cand->var_after);
+  if (TYPE_PRECISION (ctype) < TYPE_PRECISION (utype))
+   {
+ ctype = generic_type_for (utype);
+ step = fold_convert (ctype, unshare_expr (step));
+   }
   if (TREE_CODE (step) == NEGATE_EXPR)
{
  incr_code = MINUS_EXPR;

[Bug middle-end/38756] 107t.ivopts introduces pointer truncation

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-06-21 
12:01:14 UTC ---
I can't see where you would place this change from looking at the function.

[Bug middle-end/38756] 107t.ivopts introduces pointer truncation

[bigotp at acm dot org]

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

Peter A. Bigot  changed:

   What|Removed |Added

 CC||bigotp at acm dot org

--- Comment #1 from Peter A. Bigot  2012-06-21 11:34:15 
UTC ---
I confirm this in 4.7.0.  It's due to rewrite_use_nonlinear_expr() not checking
whether TYPE_PRECISION(ctype) < TYPE_PRECISION(utype) before doing the pointer
adjustment in ctype and converting back to utype.

Something like this fixes it in my case:

  if (TYPE_PRECISION (ctype) < TYPE_PRECISION (utype))
{
  ctype = generic_type_for (utype);
  step = fold_convert (ctype, unshare_expr (step));
}

[Bug other/53742] bad assembler output when compiling with LTO and PGO

[ioctl at yandex dot ru]

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

--- Comment #9 from ioctl at yandex dot ru 2012-06-21 10:07:44 UTC ---
(In reply to comment #8)
> Surely not using -freorder-blocks-and-partition will fix this?

Yes, it fixes.

>The actual
> bug should not be LTO or PGO related.

Without profile data and with -freorder-blocks-and-partition assembler eats
file silently.

If to build ff without -flto on first cycle with -fprofile-generate, and then
build without -flto on the second pass, this problem also disappears.


I have builded ff before from the same sources with the same configuration, but
without LTO. And there was no such problem.


So, it seems problem appears in case when use profile data with key
-freorder-blocks-and-partition. At that, profile must be generated by programm
builded with LTO.

[Bug gcov-profile/53744] New: gcov version oscillates between 407* and 407p on branches

[rguenth at gcc dot gnu.org]

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

 Bug #: 53744
   Summary: gcov version oscillates between 407* and 407p on
branches
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


The GCOV version oscillates because it includes the development phase for
some weird reason.  That makes it extremely annoying to use profile-feedback
data to track down bugs.  The version does not include the patch-level version,
so I see no reason to include the development phase.

[Bug c++/53743] ICE when compiling firefox with PGO and LTO

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2012-06-21 
09:47:20 UTC ---
Confirmed on input1 with

> /space/rguenther/install/gcc-4.7.1/bin/g++ -c t.ii 
> -freorder-blocks-and-partition -fno-exceptions -std=gnu++0x  -fprofile-use 
> -fprofile-correction -O2 -m32   

removing -freorder-blocks-and-partition causes the bug to vanish.

[Bug other/53742] bad assembler output when compiling with LTO and PGO

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2012-06-21 
09:35:16 UTC ---
Surely not using -freorder-blocks-and-partition will fix this?  The actual
bug should not be LTO or PGO related.

[Bug debug/53740] [4.8 Regression] --enable-checking=yes,rtl bootstrap failure with ada

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug other/53742] bad assembler output when compiling with LTO and PGO

[ioctl at yandex dot ru]

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

--- Comment #7 from ioctl at yandex dot ru 2012-06-21 09:27:46 UTC ---
I have two ld: GNU and GOLD.
Problem appears before ld call, but with such gcc keys ld GOLD must be called.

It version is GNU gold (GNU Binutils 2.22.0.20120323) 1.11.

[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris & Linux)

[windward at gmx dot com]

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

--- Comment #4 from Martin  2012-06-21 09:25:21 UTC ---
( And the "different story" is bug 53731...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53731 )

[Bug c++/53743] ICE when compiling firefox with PGO and LTO

[ioctl at yandex dot ru]

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

--- Comment #5 from ioctl at yandex dot ru 2012-06-21 09:23:18 UTC ---
Created attachment 27685
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27685
full gcc -v   output for source 2

[Bug other/53742] bad assembler output when compiling with LTO and PGO

[ioctl at yandex dot ru]

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

--- Comment #6 from ioctl at yandex dot ru 2012-06-21 09:22:36 UTC ---
GNU assembler version 2.22.0 (i686-pc-linux-gnu) using BFD version (GNU
Binutils) 2.22.0.20120323

[Bug c++/53743] ICE when compiling firefox with PGO and LTO

[ioctl at yandex dot ru]

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

--- Comment #4 from ioctl at yandex dot ru 2012-06-21 09:21:16 UTC ---
Created attachment 27684
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27684
Profile data 2

[Bug c++/53743] ICE when compiling firefox with PGO and LTO

[ioctl at yandex dot ru]

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

--- Comment #3 from ioctl at yandex dot ru 2012-06-21 09:19:51 UTC ---
Created attachment 27683
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27683
Preprocessed source 2

[Bug c++/53743] ICE when compiling firefox with PGO and LTO

[ioctl at yandex dot ru]

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

--- Comment #2 from ioctl at yandex dot ru 2012-06-21 09:17:34 UTC ---
Created attachment 27682
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27682
full gcc -v   output

[Bug c++/53743] ICE when compiling firefox with PGO and LTO

[ioctl at yandex dot ru]

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

--- Comment #1 from ioctl at yandex dot ru 2012-06-21 09:15:54 UTC ---
Created attachment 27681
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27681
Profile data 1

[Bug c++/53743] New: ICE when compiling firefox with PGO and LTO

[ioctl at yandex dot ru]

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

 Bug #: 53743
   Summary: ICE when compiling firefox with PGO and LTO
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: io...@yandex.ru


Created attachment 27680
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27680
Preprocessed source 1

$ LANG=C c++ -c -fPIC  -fno-rtti -march=prescott -mtune=prescott -mfpmath=sse
-msse2 -msse3 -O2 -fstack-protector --param=ssp-buffer-size=4 -flto
-fuse-linker-plugin -freorder-blocks-and-partition -fno-exceptions
-fno-strict-aliasing -std=gnu++0x -pthread -g -fprofile-use
-fprofile-correction -O3 -fomit-frame-pointer nsSubstring.cpp

...

nsTSubstring.cpp:618:3: internal compiler error: in cfg_layout_merge_blocks, at
cfgrtl.c:2838
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

When building without profile data usage, all OK.

The same problem appears for another source file (I will attach it too).

[Bug other/53742] bad assembler output when compiling with LTO and PGO

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  2012-06-21 
09:12:50 UTC ---
What version of binutils are you using?  Also are you using gold or GNU ld?

[Bug other/53742] bad assembler output when compiling with LTO and PGO

[ioctl at yandex dot ru]

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

--- Comment #4 from ioctl at yandex dot ru 2012-06-21 09:07:18 UTC ---
Created attachment 27679
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27679
Assembler output that rejected by as

[Bug other/53742] bad assembler output when compiling with LTO and PGO

[ioctl at yandex dot ru]

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

--- Comment #3 from ioctl at yandex dot ru 2012-06-21 09:05:36 UTC ---
Created attachment 27678
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27678
Full c++ console output

[Bug other/53742] bad assembler output when compiling with LTO and PGO

[ioctl at yandex dot ru]

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

--- Comment #2 from ioctl at yandex dot ru 2012-06-21 09:04:20 UTC ---
Created attachment 27677
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27677
Profile data

[Bug other/53742] bad assembler output when compiling with LTO and PGO

[ioctl at yandex dot ru]

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

--- Comment #1 from ioctl at yandex dot ru 2012-06-21 09:03:45 UTC ---
Created attachment 27676
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27676
Preprocessed source

[Bug other/53742] New: bad assembler output when compiling with LTO and PGO

[ioctl at yandex dot ru]

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

 Bug #: 53742
   Summary: bad assembler output when compiling with LTO and PGO
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: io...@yandex.ru


LANG=C c++ -c -v -fPIC  -fno-rtti -march=prescott -mtune=prescott -mfpmath=sse
-msse2 -msse3 -fstack-protector --param=ssp-buffer-size=4 -flto
-fuse-linker-plugin -O3 -freorder-blocks-and-partition -pthread -g
-fprofile-use -fprofile-correction -fomit-frame-pointer String.cpp

...


String.s: Assembler messages:
String.s:5667: Error: invalid operands (.text.hot and .text sections) for `-'
String.s:5669: Error: invalid operands (.text.hot and .text sections) for `-'


String.cpp is from the firefox 12.

Problem appears only when using profile information.

Full output with -v and -save-temps is too long, so, I will attach it.

[Bug c++/53741] New: ICE on lambda calling static template member function with explicit template argument specification

[lunow at math dot hu-berlin.de]

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

 Bug #: 53741
   Summary: ICE on lambda calling static template member function
with explicit template argument specification
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lu...@math.hu-berlin.de


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

Attached is a testcase ICEing on 4.6.3 and 4.7.1.
This bug is related to bug 52183 and bug 51494.

GCC 4.6.3 Output:
C:\dev\projects\compiler test>gcc -std=c++0x gcc_test4.cpp
gcc_test4.cpp: In lambda function:
gcc_test4.cpp:8:7:   instantiated from 'X::foo(T) [with T = int]::'
gcc_test4.cpp:8:5:   instantiated from 'void X::foo(T) [with T = int]'
gcc_test4.cpp:15:10:   instantiated from here
gcc_test4.cpp:8:11: internal compiler error: in push_class_level_binding, at
cp/name-lookup.c:2833
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

GCC 4.7.1 Output:
C:\dev\projects\compiler test>gcc -std=c++0x gcc_test4.cpp
gcc_test4.cpp: In instantiation of 'X::foo(T) [with T = int]::':
gcc_test4.cpp:8:7:   required from 'struct X::foo(T) [with T =
int]::'
gcc_test4.cpp:8:5:   required from 'void X::foo(T) [with T = int]'
gcc_test4.cpp:15:10:   required from here
gcc_test4.cpp:8:11: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/53726] [4.8 Regression] aes test performance drop for eembc_2_0_peak_32

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  
2012-06-21 08:46:11 UTC ---
On Wed, 20 Jun 2012, hjl.tools at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53726
> 
> --- Comment #17 from H.J. Lu  2012-06-20 15:36:09 
> UTC ---
> (In reply to comment #16)
> > But I am not sure if a good library implementation shouldn't be always
> > preferable to a byte-wise copy.  We could, at least try to envision a way
> > to retain and use the knowledge that the size is at most 8 when expanding
> > the memcpy (with AVX we could use a masked store for example - quite fancy).
> 
> string/memory functions in libc can be much faster than the ones generated
> by GCC unless the size is very small, PR 43052.

Yes.  The question is what is "very small" and how can we possibly
detect "very small".  For this testcase we can derive an upper bound
of the size, which is 8, but the size is not constant.  I think unless
we know we can expand the variable-size memcpy with, say, three
CPU instructions inline there is no reason to not call memcpy.

Thus if the CPU could do

  tem = unaligned-load-8-bytes-from-src-and-ignore-faults;
  mask = generate mask from size
  store-unaligned-8-bytes-with-maxk

then expanding the memcpy call inline would be a win I suppose.
AVX has VMASKMOV, but I'm not sure using that for sizes <= 16
bytes is profitable?  Note that from the specs
of VMASKMOV it seems the memory operands need to be aligned and
the mask does not support byte-granularity.

Which would leave us to inline expanding the case of at most 2 byte
memcpy.  Of course currently there is no way to record an upper
bound for the size (we do not retain value-range information - but
we of course should).

[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  2012-06-21 
08:23:56 UTC ---
*** Bug 53713 has been marked as a duplicate of this bug. ***

[Bug libstdc++/53713] undefined reference with -brtl

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Jonathan Wakely  2012-06-21 
08:23:56 UTC ---
dup

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

[Bug rtl-optimization/53706] [4.8 Regression] Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418)

[ubizjak at gmail dot com]

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

--- Comment #10 from Uros Bizjak  2012-06-21 07:33:34 
UTC ---
Patch that fixes all valgrind issues, but I have no idea if it is OK or not:

--cut here--
Index: var-tracking.c
===
--- var-tracking.c  (revision 188848)
+++ var-tracking.c  (working copy)
@@ -9126,11 +9126,7 @@ vt_emit_notes (void)
   dataflow_set_destroy (&cur);

   if (MAY_HAVE_DEBUG_INSNS)
-{
-  free_alloc_pool (loc_exp_dep_pool);
-  loc_exp_dep_pool = NULL;
-  htab_delete (dropped_values);
-}
+htab_delete (dropped_values);

   emit_notes = false;
 }
@@ -9797,6 +9793,8 @@ vt_finalize (void)

   if (MAY_HAVE_DEBUG_INSNS)
 {
+  free_alloc_pool (loc_exp_dep_pool);
+  loc_exp_dep_pool = NULL;
   free_alloc_pool (valvar_pool);
   VEC_free (rtx, heap, preserved_values);
   cselib_finish ();
--cut here--

[Bug c++/53727] ICE when compiling firefox with PGO and LTO (not OOM)

[ioctl at yandex dot ru]

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

--- Comment #9 from ioctl at yandex dot ru 2012-06-21 07:29:52 UTC ---
Created attachment 27674
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27674
Profile data from comment 7

[Bug c++/53727] ICE when compiling firefox with PGO and LTO (not OOM)

[ioctl at yandex dot ru]

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

--- Comment #8 from ioctl at yandex dot ru 2012-06-21 07:28:16 UTC ---
Created attachment 27673
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27673
Preprocessed source from comment 7

[Bug c++/53727] ICE when compiling firefox with PGO and LTO (not OOM)

[ioctl at yandex dot ru]

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

--- Comment #7 from ioctl at yandex dot ru 2012-06-21 07:25:46 UTC ---
The same problem with other file from ff 12:

LANG=C c++ -o nsPluginHost.o -c -fPIC -fno-rtti -march=prescott -mtune=prescott
-mfpmath=sse -msse2 -msse3 -O2 -fstack-protector --param=ssp-buffer-size=4
-flto -fuse-linker-plugin -O3 -freorder-blocks-and-partition -fno-exceptions
-fno-strict-aliasing -std=gnu++0x -pthread -pipe -g -fprofile-use
-fprofile-correction -Wcoverage-mismatch -O3 -fomit-frame-pointer -pthread
nsPluginHost.cpp
/home/ioctl/ff-build-semilto/src/mozilla-release/dom/plugins/base/nsPluginHost.cpp:
In member function 'nsPluginHost::ReadPluginInfo()':
/home/ioctl/ff-build-semilto/src/mozilla-release/dom/plugins/base/nsPluginHost.cpp:2984:1:
internal compiler error: in create_pseudo_cfg, at dwarf2cfi.c:2735
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.