[Bug target/52898] SH Target: Inefficient DImode comparisons

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  2012-04-12 06:59:47 
UTC ---
(In reply to comment #4)
> 
> I would propose to deprecate -mcbranchdi and -mcmpeqdi and hard-code the
> 'enabled' behavior, i.e. remove all the non-mcbranchdi and non-mcmpeqdi code
> paths in the back end code (and fixing the fails of course ...)

Sorry, what I rather meant is: deprecate -mcbranchdi and -mcmpeqdi,
simplify/unify the code for those in the back end in order to implement some
reasonable default behavior without the need for -m options.

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

 CC||torvald at gcc dot gnu.org

--- Comment #25 from torvald at gcc dot gnu.org 2012-04-12 08:24:16 UTC ---
If we make an ABI switch at some point, should we move over to relying just on
atomics and the libatomic fallbacks (assuming/hoping libatomic exists by then)?

Also, refcounting in basic_string has bugs too.  Do you see other areas of
libstdc++ that could use a review of the synchronization bits?

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

[redi at gcc dot gnu.org]

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

--- Comment #26 from Jonathan Wakely  2012-04-12 
08:30:17 UTC ---
(In reply to comment #25)
> If we make an ABI switch at some point, should we move over to relying just on
> atomics and the libatomic fallbacks (assuming/hoping libatomic exists by 
> then)?

Yes, unfortunately neither an ABI switch nor libatomic is not going to happen
in the short term, the priority right now is to fix this regression in 4.7.0

I hope to get time in the next few days to partially revert the acinclude.m4
changes that cause _GLIBCXX_ATOMIC_BUILTINS to rely on 8-byte CAS, but I'd like
to hear from Benjamin first.

> Also, refcounting in basic_string has bugs too.  Do you see other areas of
> libstdc++ that could use a review of the synchronization bits?

std::locale also uses atomics for refcounting.

[Bug libstdc++/52942] [4.7 Regression] using std::ref with a std::unordered_map fails to compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|c++ |libstdc++
   Severity|major   |normal

--- Comment #3 from Jonathan Wakely  2012-04-12 
08:40:06 UTC ---
unordered_map derives privately from its template _ExtractKey parameter which
is _Select1st and provides argument_type.

If G++ checked access control in SFINAE situations I believe the code would
work, as __has_argument_type would not report an access failure, unfortunately
that isn't implemented in G++

[Bug libstdc++/52942] [4.7 Regression] using std::ref with a std::unordered_map fails to compile

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-04-12 
08:46:04 UTC ---
The solution would be to follow the same pattern as the other containers:

template
struct Cont
{
struct Impl : B
   { 
   A* data;
   };
   Impl impl;
};

instead the hash tables are more like:

template
struct Impl : A, B
{ };

template
struct Cont : Impl
{ };

which means Cont inherits all the members of A and B (including typedefs and
potentially virtual functions)

[Bug libstdc++/52942] [4.7 Regression] using std::ref with a std::unordered_map fails to compile

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||bkoz at redhat dot com,
   ||fdumont at gcc dot gnu.org

--- Comment #5 from Paolo Carlini  2012-04-12 
09:03:45 UTC ---
I see, thanks. Then, short term shall we just change the derivation to public
(with a comment)? Then, in mainline either somebody will do the sfinae bits
(even me ;) I mean to seriously look into it), or something else can be
changed. Seems a good way forward.

[Bug libstdc++/52942] [4.7 Regression] using std::ref with a std::unordered_map fails to compile

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2012-04-12 
09:06:59 UTC ---
Or for the hash tables, which have lots of template parameters, it would be
even better to use std::tuple to get the EBO benefits

[Bug c/52936] [4.8 Regression] Assertion failure in pointer_diff

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Richard Guenther  2012-04-12 
09:07:52 UTC ---
.

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

[Bug libstdc++/52942] [4.7 Regression] using std::ref with a std::unordered_map fails to compile

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  2012-04-12 
09:08:33 UTC ---
(In reply to comment #5)
> I see, thanks. Then, short term shall we just change the derivation to public

Hmm, that might be ok ... it would be the least invasive change, certainly

[Bug c/52549] [4.8 Regression] ice in pointer_diff

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||aph at gcc dot gnu.org

--- Comment #3 from Richard Guenther  2012-04-12 
09:07:53 UTC ---
*** Bug 52936 has been marked as a duplicate of this bug. ***

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

  Known to fail||4.7.0

--- Comment #27 from Alan Modra  2012-04-12 09:18:38 
UTC ---
I took a look at libstdc++.so use of exchange_and_add on powerpc 32-bit.  There
seems to be a lot of places where it appears, even before Benjamin's change,
ie. r184109.

Uses of exchange_and_add common to both r184109 and r186130, the latter patched
with http://gcc.gnu.org/bugzilla/attachment.cgi?id=27094 to get
_GLIBCXX_ATOMIC_BUILTINS enabled on powerpc.

_ZNKSt15basic_stringbufIcSt11char_traitsIcESaIcEE3strEv
_ZNKSt15basic_stringbufIwSt11char_traitsIwESaIwEE3strEv
_ZNKSt18basic_stringstreamIcSt11char_traitsIcESaIcEE3strEv
_ZNKSt18basic_stringstreamIwSt11char_traitsIwESaIwEE3strEv
_ZNKSt19basic_istringstreamIcSt11char_traitsIcESaIcEE3strEv
_ZNKSt19basic_istringstreamIwSt11char_traitsIwESaIwEE3strEv
_ZNKSt19basic_ostringstreamIcSt11char_traitsIcESaIcEE3strEv
_ZNKSt19basic_ostringstreamIwSt11char_traitsIwESaIwEE3strEv
_ZNKSt7collateIcE10do_compareEPKcS2_S2_S2_
_ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEE8overflowEi
_ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEED0Ev
_ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEED1Ev
_ZNSt15basic_stringbufIwSt11char_traitsIwESaIwEE8overflowEj
_ZNSt15basic_stringbufIwSt11char_traitsIwESaIwEED0Ev
_ZNSt15basic_stringbufIwSt11char_traitsIwESaIwEED1Ev
_ZNSt18basic_stringstreamIcSt11char_traitsIcESaIcEED0Ev
_ZNSt18basic_stringstreamIcSt11char_traitsIcESaIcEED1Ev
_ZNSt18basic_stringstreamIcSt11char_traitsIcESaIcEED2Ev
_ZNSt18basic_stringstreamIwSt11char_traitsIwESaIwEED0Ev
_ZNSt18basic_stringstreamIwSt11char_traitsIwESaIwEED1Ev
_ZNSt18basic_stringstreamIwSt11char_traitsIwESaIwEED2Ev
_ZNSt19basic_istringstreamIcSt11char_traitsIcESaIcEED0Ev
_ZNSt19basic_istringstreamIcSt11char_traitsIcESaIcEED1Ev
_ZNSt19basic_istringstreamIcSt11char_traitsIcESaIcEED2Ev
_ZNSt19basic_istringstreamIwSt11char_traitsIwESaIwEED0Ev
_ZNSt19basic_istringstreamIwSt11char_traitsIwESaIwEED1Ev
_ZNSt19basic_istringstreamIwSt11char_traitsIwESaIwEED2Ev
_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED0Ev
_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED1Ev
_ZNSt19basic_ostringstreamIcSt11char_traitsIcESaIcEED2Ev
_ZNSt19basic_ostringstreamIwSt11char_traitsIwESaIwEED0Ev
_ZNSt19basic_ostringstreamIwSt11char_traitsIwESaIwEED1Ev
_ZNSt19basic_ostringstreamIwSt11char_traitsIwESaIwEED2Ev
_ZStlsIdcSt11char_traitsIcEERSt13basic_ostreamIT0_T1_ES6_RKSt7complexIT_E
_ZStlsIdwSt11char_traitsIwEERSt13basic_ostreamIT0_T1_ES6_RKSt7complexIT_E
_ZStlsIfcSt11char_traitsIcEERSt13basic_ostreamIT0_T1_ES6_RKSt7complexIT_E
_ZStlsIfwSt11char_traitsIwEERSt13basic_ostreamIT0_T1_ES6_RKSt7complexIT_E
_ZStlsIgcSt11char_traitsIcEERSt13basic_ostreamIT0_T1_ES6_RKSt7complexIT_E
_ZStlsIgwSt11char_traitsIwEERSt13basic_ostreamIT0_T1_ES6_RKSt7complexIT_E

Use of exchange_and_add only in r184109
r186130 with patch appears to neither use exchange_and_add or atomics in these
functions.  (I say appears because I only looked for direct calls.)
_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE16_M_extract_floatES3_S3_RSt8ios_baseRSt12_Ios_IostateRSs
_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRd
_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRe
_ZNKSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRf
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE16_M_extract_floatES3_S3_RSt8ios_baseRSt12_Ios_IostateRSs
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRd
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRe
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRf
_ZNKSt9money_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE6do_getES3_S3_bRSt8ios_baseRSt12_Ios_IostateRSs
_ZNKSt9money_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE6do_getES3_S3_bRSt8ios_baseRSt12_Ios_IostateRe
_ZNKSt9money_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_bRSt8ios_baseRSt12_Ios_IostateRSbIwS2_SaIwEE
_ZNKSt9money_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_bRSt8ios_baseRSt12_Ios_IostateRe
_ZNKSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_bRSt8ios_basece
_ZNKSt9money_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES3_bRSt8ios_basewe
_ZNSt16__numpunct_cacheIcE8_M_cacheERKSt6locale
_ZNSt16__numpunct_cacheIwE8_M_cacheERKSt6locale
_ZNSt18__moneypunct_cacheIwLb0EE8_M_cacheERKSt6locale
_ZNSt18__moneypunct_cacheIwLb1EE8_M_cacheERKSt6locale

[Bug other/52944] [4.5/4.6 Regression] __builtin_object_size(..., 1) no longer returns (size_t)-1 for consecutive flexible/zero-length array members

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Richard Guenther  2012-04-12 
09:20:37 UTC ---
It works as expected.  buf[] is not made magically flexible by tail[].  Why
does the code not simply use

struct stct {
int i;
union {
short k;
char buf[0];
};
};

?

Btw, With GCC 4.7 you get 96 ... which is similar conservative as -1.
But zero is certainly correct and expected.

[Bug tree-optimization/52943] [4.7/4.8 Regression] likely wrong code bug caused by predictive commoning

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-12
  Component|c   |tree-optimization
  Known to work||4.6.3
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.1
Summary|likely wrong code bug   |[4.7/4.8 Regression] likely
   ||wrong code bug caused by
   ||predictive commoning
 Ever Confirmed|0   |1
  Known to fail||4.7.0

--- Comment #1 from Richard Guenther  2012-04-12 
09:23:11 UTC ---
Confirmed.  Predictive commoning again.

[Bug tree-optimization/52943] [4.7/4.8 Regression] likely wrong code bug caused by predictive commoning

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-04-12 
09:24:48 UTC ---
(compute_affine_dependence
  stmt_a: D.1717_2 = a[3];
  stmt_b: a[b.0_15] = D.1719_4;
(subscript_dependence_tester
(analyze_overlapping_iterations
  (chrec_a = 3)
  (chrec_b = {3, +, -1}_1)
(analyze_siv_subscript
)
  (overlap_iterations_a = no dependence
)
  (overlap_iterations_b = no dependence
)
)
(dependence classified: scev_known)
)
) -> no dependence

Obviously wrong.

[Bug libstdc++/52942] [4.7/4.8 Regression] using std::ref with a std::unordered_map fails to compile

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.1
Summary|[4.7 Regression] using  |[4.7/4.8 Regression] using
   |std::ref with a |std::ref with a
   |std::unordered_map fails to |std::unordered_map fails to
   |compile |compile

[Bug other/52937] [4.8 Regression] ICE in several cpu2006 benchmarks with -fprofile-use (assert in get_loop_body)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

--- Comment #1 from Richard Guenther  2012-04-12 
09:28:53 UTC ---
Hmpf.  Can you isolate the pass that causes this with

Index: gcc/passes.c
===
*** gcc/passes.c.orig   2012-03-16 15:13:32.0 +0100
--- gcc/passes.c2012-03-16 15:14:17.0 +0100
*** execute_function_todo (void *data)
*** 1732,1737 
--- 1732,1741 
  verify_gimple_in_cfg (cfun);
if (flags & TODO_verify_flow)
  verify_flow_info ();
+   if (current_loops
+   /* Between IRA and reload loops are broken but preserved.  */
+   && (cfun->curr_properties & PROP_loops))
+ verify_loop_structure ();
if (current_loops && loops_state_satisfies_p (LOOP_CLOSED_SSA))
  verify_loop_closed_ssa (false);
if (flags & TODO_verify_rtl_sharing)

?

[Bug middle-end/52939] [4.7/4.8 Regression] ice in gimple_get_virt_method_for_binfo with -O3

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-12
  Component|c++ |middle-end
 CC||jamborm at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|ice in  |[4.7/4.8 Regression] ice in
   |gimple_get_virt_method_for_ |gimple_get_virt_method_for_
   |binfo with -O3  |binfo with -O3
   Target Milestone|--- |4.7.1
  Known to fail||4.7.0, 4.8.0

--- Comment #1 from Richard Guenther  2012-04-12 
09:31:34 UTC ---
Confirmed.  Possibly a regression.

[Bug libstdc++/52942] [4.7/4.8 Regression] using std::ref with a std::unordered_map fails to compile

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  2012-04-12 
09:33:14 UTC ---
Uhm, short term, I like even better just not using _Select1st *at all*, have an
implementation detail in the hashtable header itself not deriving from
unary_function. Isn't that a bit redundant but cleaner?

[Bug testsuite/52945] New: FAIL: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O* -flto *

[dominiq at lps dot ens.fr]

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

 Bug #: 52945
   Summary: FAIL: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble,
-O* -flto *
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: hubi...@gcc.gnu.org, ia...@gcc.gnu.org
  Host: x86_64-apple-darwin10
Target: x86_64-apple-darwin10
 Build: x86_64-apple-darwin10


On x86_64-apple-darwin10 the test gcc.dg/lto/pr52634* introduced in revision
186252 fails:

FAIL: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O0 -flto
-flto-partition=none 
UNRESOLVED: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link -O0
-flto -flto-partition=none 
UNRESOLVED: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o execute -O0
-flto -flto-partition=none 
FAIL: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O2 -flto
-flto-partition=none 
UNRESOLVED: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link -O2
-flto -flto-partition=none 
UNRESOLVED: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o execute -O2
-flto -flto-partition=none 
FAIL: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O0 -flto
-flto-partition=1to1 
UNRESOLVED: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link -O0
-flto -flto-partition=1to1 
UNRESOLVED: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o execute -O0
-flto -flto-partition=1to1 
FAIL: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O2 -flto
-flto-partition=1to1 
UNRESOLVED: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link -O2
-flto -flto-partition=1to1 
UNRESOLVED: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o execute -O2
-flto -flto-partition=1to1 
FAIL: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O0 -flto 
UNRESOLVED: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link -O0
-flto 
UNRESOLVED: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o execute -O0
-flto 
FAIL: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O2 -flto
UNRESOLVED: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o link -O2
-flto
UNRESOLVED: gcc.dg/lto/pr52634 c_lto_pr52634_0.o-c_lto_pr52634_1.o execute -O2
-flto

The failure is

Executing on host: /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ 
-fno-diagnostics-show-caret  -O0 -flto -flto-partition=none   -c  -m32 -o
c_lto_pr52634_0.o /opt/gcc/work/gcc/testsuite/gcc.dg/lto/pr52634_0.c   
(timeout = 300)
PASS: gcc.dg/lto/pr52634 c_lto_pr52634_0.o assemble, -O0 -flto
-flto-partition=none
Executing on host: /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/ 
-fno-diagnostics-show-caret  -O0 -flto -flto-partition=none   -c  -m32 -o
c_lto_pr52634_1.o /opt/gcc/work/gcc/testsuite/gcc.dg/lto/pr52634_1.c   
(timeout = 300)
/opt/gcc/work/gcc/testsuite/gcc.dg/lto/pr52634_1.c:2:12: error: only weak
aliases are supported in this configuration
/opt/gcc/work/gcc/testsuite/gcc.dg/lto/pr52634_1.c:2:12: error: only weak
aliases are supported in this configuration
compiler exited with status 1

This test should probably skipped on platforms that are not supporting weak
aliases.

[Bug fortran/52864] [4.6/4.7/4.8 Regression] Assignment to pointer component for INTENT(IN) dummy argument

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2012-04-12 
09:52:03 UTC ---
Regarding the original issue (comment 0): The patch has been submitted to
http://gcc.gnu.org/ml/fortran/2012-04/msg00058.html

 * * *

(In reply to comment #2)
> Here's a somewhat different example, but I think it exposes the same
> underlying bug.

Thanks for the bug report!

While the bug is language wise related, it is rather different in terms of the
compiler: It's not a regression and the bug is in a completely different file.

Untested draft patch:

--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -2807,3 +2823,6 @@ compare_parameter_intent (gfc_symbol *formal, gfc_expr
 {
-  if (actual->symtree->n.sym->attr.pointer && !formal->attr.pointer)
+  if (gfc_expr_attr (actual).pointer
+  && ((formal->ts.type == BT_CLASS && formal->attr.class_ok
+  && !CLASS_DATA (formal)->attr.class_pointer)
+ || (formal->ts.type != BT_CLASS && !formal->attr.pointer)))
 return 1;

[Bug libstdc++/52942] [4.7/4.8 Regression] using std::ref with a std::unordered_map fails to compile

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  2012-04-12 
09:56:54 UTC ---
... or ;) in C++11 mode, have _Select1st and _Identity not deriving from
unary_function. Should work, very, very simple patch, and in any case the
latter is deprecated in C++11, we really want to see it around as little as
possible.

[Bug testsuite/52945] FAIL: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O* -flto *

[hubicka at ucw dot cz]

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

--- Comment #1 from Jan Hubicka  2012-04-12 09:56:44 UTC 
---
Indeed, it should be tested only when weak aliases are supposed. There is some
dg trick for that...

[Bug libstdc++/52942] [4.7/4.8 Regression] using std::ref with a std::unordered_map fails to compile

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2012-04-12 
10:04:51 UTC ---
where else is _Select1st used?  Does it need argument_type and result_type
defined?  It doesn't matter if they come from unary_function, but it might
matter that they're defined, and if they need to be there then the bug will
still exist

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

[redi at gcc dot gnu.org]

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

--- Comment #28 from Jonathan Wakely  2012-04-12 
10:06:38 UTC ---
all those uses in streams and facets are (I believe) from std::locale

[Bug target/47230] [4.6 Regression] gcc fails to bootstrap on alpha in stage2 with "relocation truncated to fit: GPREL16 against ..."

[mikpe at it dot uu.se]

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

--- Comment #18 from Mikael Pettersson  2012-04-12 
10:09:32 UTC ---
It seems to be triggered(*) by Uros' PR46533 patch in r166999:
http://gcc.gnu.org/viewcvs?view=revision&revision=166999

Repeat-by:
1. have cross tools to alpha-linux hosted on e.g. x86, mine has binutils-2.20.1
2. build gcc-4.6 r166998 as cross to alpha-linux
3. used the above to cross-build a linux-3.3.0 kernel, this works for me
4. repeat steps 2 and 3 with gcc-4.6 r166999, gcc builds ok but the kernel
build fails with the usual 'relocation truncated to fit: GPREL16 against ...'
errors

In my cross environment gcc 4.7 and 4.8 also fail to build a linux kernel, but
4.5.3 and 4.4.7 work.

(*) Presumably gcc triggers a bug in ld.

[Bug libstdc++/52839] double free or corruption running tr1/.../default_weaktoshared.exe

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC|bkoz at gcc dot gnu.org |bkoz at redhat dot com

--- Comment #29 from Jonathan Wakely  2012-04-12 
10:09:10 UTC ---
pinging Benjamin (at an address that doesn't exclude bugzilla CC mails) ;)

[Bug libstdc++/52942] [4.7/4.8 Regression] using std::ref with a std::unordered_map fails to compile

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  2012-04-12 
10:14:15 UTC ---
Only in a few places in the associative, to instantiate _Rb_tree, but the
nested types are not used at all, afaics. And, well, if (in the near future) we
figure out some sort of nested types can be useful to have for such extensions,
we can still have with a different name.

So far the obvious patch appears to work pretty well. I'm completing
regtesting.

[Bug target/47230] [4.6 Regression] gcc fails to bootstrap on alpha in stage2 with "relocation truncated to fit: GPREL16 against ..."

[ubizjak at gmail dot com]

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

--- Comment #19 from Uros Bizjak  2012-04-12 10:24:36 
UTC ---
(In reply to comment #18)
> It seems to be triggered(*) by Uros' PR46533 patch in r166999:
> http://gcc.gnu.org/viewcvs?view=revision&revision=166999

I don't think that this patch has anything to do with GPREL16. The patch fixes
relocation on functions, where you have problems with symbol relocations.

> Repeat-by:
> 1. have cross tools to alpha-linux hosted on e.g. x86, mine has 
> binutils-2.20.1
> 2. build gcc-4.6 r166998 as cross to alpha-linux
> 3. used the above to cross-build a linux-3.3.0 kernel, this works for me
> 4. repeat steps 2 and 3 with gcc-4.6 r166999, gcc builds ok but the kernel
> build fails with the usual 'relocation truncated to fit: GPREL16 against ...'
> errors

Just stick -Wl,--no-relax somewhere. This is standard practice to build a
kernel.

[Bug libstdc++/52942] [4.7/4.8 Regression] using std::ref with a std::unordered_map fails to compile

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini  2012-04-12 
10:27:16 UTC ---
Created attachment 27139
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27139
Draft I'm testing

[Bug libfortran/52537] slow trim function

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  2012-04-12 
10:47:36 UTC ---
For this particular case,

if (trim(a) == '') 

could be simplified to

if (len_trim(a) == 0)

Probably best done via front-end optimization.

[Bug c/52946] New: Unable to define a Block variable

[lunfis at gmx dot de]

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

 Bug #: 52946
   Summary: Unable to define a Block variable
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lun...@gmx.de


when defining a 'block' variable using valid syntax (test.c):

#include 

int main (int argc, const char * argv[]) {  

  int (^myBlock)(int) = ^(int num) {
  return num;
  };

  printf("Result is %d\n", myBlock(3));

  return 0;  
}  

"gcc test.c" gives error message: "test.c:5:8: error: expected identifier or
‘(’ before ‘^’ token"

This compiles and executes correctly with gcc 4.2.

[Bug other/52937] [4.8 Regression] ICE in several cpu2006 benchmarks with -fprofile-use (assert in get_loop_body)

[wschmidt at linux dot vnet.ibm.com]

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

--- Comment #2 from wschmidt at linux dot vnet.ibm.com 2012-04-12 11:39:37 UTC 
---
Sure, I'll get that information today.

On Thu, 2012-04-12 at 09:28 +, rguenth at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52937
> 
> Richard Guenther  changed:
> 
>What|Removed |Added
> 
>Target Milestone|--- |4.8.0
> 
> --- Comment #1 from Richard Guenther  2012-04-12 
> 09:28:53 UTC ---
> Hmpf.  Can you isolate the pass that causes this with
> 
> Index: gcc/passes.c
> ===
> *** gcc/passes.c.orig   2012-03-16 15:13:32.0 +0100
> --- gcc/passes.c2012-03-16 15:14:17.0 +0100
> *** execute_function_todo (void *data)
> *** 1732,1737 
> --- 1732,1741 
>   verify_gimple_in_cfg (cfun);
> if (flags & TODO_verify_flow)
>   verify_flow_info ();
> +   if (current_loops
> +   /* Between IRA and reload loops are broken but preserved.  */
> +   && (cfun->curr_properties & PROP_loops))
> + verify_loop_structure ();
> if (current_loops && loops_state_satisfies_p (LOOP_CLOSED_SSA))
>   verify_loop_closed_ssa (false);
> if (flags & TODO_verify_rtl_sharing)
> 
> ?
>

[Bug tree-optimization/52943] [4.7/4.8 Regression] likely wrong code bug caused by predictive commoning

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-04-12 
11:39:12 UTC ---
Author: rguenth
Date: Thu Apr 12 11:38:47 2012
New Revision: 186374

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186374
Log:
2012-04-12  Richard Guenther  

PR tree-optimization/52943
* tree-chrec.h (chrec_is_positive): Remove.
* tree-scalar-evolution.c (chrec_is_positive): Move ...
* tree-data-ref.c (chrec_is_positive): ... here.  Make static.
Return false for a constant zero instead of negative.
(analyze_siv_subscript_cst_affine): Handle zero difference
in the initial condition explicitely.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr52943.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chrec.h
trunk/gcc/tree-data-ref.c
trunk/gcc/tree-scalar-evolution.c

[Bug c++/16233] unhelpful error message when "template" is omitted

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2005-06-26 02:27:01 |2012-04-12 11:50
  Known to fail||4.7.0

--- Comment #5 from Jonathan Wakely  2012-04-12 
11:50:39 UTC ---
reconfirming as still present in current releases

[Bug bootstrap/52947] New: [4.7 Regression] bootstrap fails due to wrong include search path composition

[rai...@emrich-ebersheim.de]

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

 Bug #: 52947
   Summary: [4.7 Regression] bootstrap fails due to wrong include
search path composition
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rai...@emrich-ebersheim.de


native x86_64-w64-mingw32 bootstrap using --with-sysroot
This used to work for the 4.6 series.

../../src/gcc-4.7.0/configure
--prefix=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0
--with-gnu-as
--with-as=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/bin/as
--with-gnu-ld
--with-ld=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/bin/ld
--build=x86_64-w64-mingw32
--enable-languages=c,ada,c++,fortran,java,lto,objc,obj-c++
--with-gmp-include=/SCRATCH/tmp.pzGXGetUXT/install/include
--with-gmp-lib=/SCRATCH/tmp.pzGXGetUXT/install/lib64
--with-mpfr-include=/SCRATCH/tmp.pzGXGetUXT/install/include
--with-mpfr-lib=/SCRATCH/tmp.pzGXGetUXT/install/lib64
--with-mpc-include=/SCRATCH/tmp.pzGXGetUXT/install/include
--with-mpc-lib=/SCRATCH/tmp.pzGXGetUXT/install/lib64
--with-ppl-include=/SCRATCH/tmp.pzGXGetUXT/install/include
--with-ppl-lib=/SCRATCH/tmp.pzGXGetUXT/install/lib64
--with-cloog-include=/SCRATCH/tmp.pzGXGetUXT/install/include
--with-cloog-lib=/SCRATCH/tmp.pzGXGetUXT/install/lib64
--with-local-prefix=/opt/devel/tec/devel/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0
--enable-libgomp --enable-fully-dynamic-string --disable-multilib
--enable-checking=release --disable-werror --with-sysroot=/x86_64-w64-trunk
--with-host-libstdcxx='-Wl,-Bstatic,-lstdc++,-Bdynamic'

gcc 4.7.0 bootstrap fails during configuration in libgcc:

checking how to run the C preprocessor... /lib/cpp
configure: error: in
`/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/x86_64-w64-mingw32/libgcc':
configure: error: C preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.
gmake[2]: *** [configure-stage1-target-libgcc] Error 1
gmake[2]: Leaving directory `/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0'
gmake: *** [all] Error 2 


config.log in libgcc shows:

configure:3893: checking how to run the C preprocessor
configure:3924: /SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/./gcc/xgcc
-B/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/./gcc/
-L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/lib
-L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/mingw/lib
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/include
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/mingw/include
-B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/bin/
-B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/lib/
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/include
-isystem
/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.0/x86_64-w64-mingw32/sys-include
   -E  conftest.c
In file included from
D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/gcc/include-fixed/syslimits.h:7:0,
 from
D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/gcc/include-fixed/limits.h:34,
 from conftest.c:10:
D:/msys/SCRATCH/tmp.pzGXGetUXT/gcc-4.7.0/gcc-4.7.0/gcc/include-fixed/limits.h:169:61:
error: no include path in which to search for limits.h
configure:3924: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h.  */
| #ifdef __STDC__
| # include 
| #else
| # include 
| #endif
|  Syntax error 


further analysis shows that the include search path composition is wrong.
For gcc-4.6.3 stage1 xgcc the search path is as follows:

nicht vorhandenes Verzeichnis
»d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.6.3/x86_64-w64-mingw32/include«
wird ignoriert
nicht vorhandenes Verzeichnis
»d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.6.3/mingw/include«
wird ignoriert
nicht vorhandenes Verzeichnis
»d:/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.6.3/x86

[Bug libstdc++/52942] [4.7/4.8 Regression] using std::ref with a std::unordered_map fails to compile

[paolo at gcc dot gnu.org]

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

--- Comment #13 from paolo at gcc dot gnu.org  
2012-04-12 12:18:15 UTC ---
Author: paolo
Date: Thu Apr 12 12:18:06 2012
New Revision: 186375

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186375
Log:
2012-04-12  Paolo Carlini  

PR libstdc++/52942
* include/bits/stl_function.h (_Identity, _Select1st, _Select2nd):
In C++11 mode do not derive from std::unary_function.
* include/ext/functional (identity, select1st, select2nd): Adjust.
* testsuite/23_containers/unordered_map/requirements/52942.cc: New.
* testsuite/23_containers/unordered_set/requirements/52942.cc: Likewise.

Added:
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_map/requirements/52942.cc
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/requirements/52942.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_function.h
trunk/libstdc++-v3/include/ext/functional

[Bug libstdc++/52942] [4.7/4.8 Regression] using std::ref with a std::unordered_map fails to compile

[paolo at gcc dot gnu.org]

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

--- Comment #14 from paolo at gcc dot gnu.org  
2012-04-12 12:18:33 UTC ---
Author: paolo
Date: Thu Apr 12 12:18:23 2012
New Revision: 186376

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186376
Log:
2012-04-12  Paolo Carlini  

PR libstdc++/52942
* include/bits/stl_function.h (_Identity, _Select1st, _Select2nd):
In C++11 mode do not derive from std::unary_function.
* include/ext/functional (identity, select1st, select2nd): Adjust.
* testsuite/23_containers/unordered_map/requirements/52942.cc: New.
* testsuite/23_containers/unordered_set/requirements/52942.cc: Likewise.

Added:
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/unordered_map/requirements/52942.cc
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/unordered_set/requirements/52942.cc
Modified:
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/include/bits/stl_function.h
branches/gcc-4_7-branch/libstdc++-v3/include/ext/functional

[Bug libstdc++/52942] [4.7/4.8 Regression] using std::ref with a std::unordered_map fails to compile

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #15 from Paolo Carlini  2012-04-12 
12:19:31 UTC ---
Done.

[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  2012-04-12 
12:21:04 UTC ---
Jeffrey, please commit and close the PR. Thanks.

[Bug libstdc++/52702] [C++11] std::is_trivially_destructible is missing

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-12
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.8.0
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2012-04-12 
12:22:10 UTC ---
Ok, thanks.

[Bug c++/50359] poor error message for an undeclared identifier in constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-12
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2012-04-12 
12:23:38 UTC ---
Confirmed. Clang doesn't do much better, but EDG is very good:


"ComeauTest.c", line 8: error: identifier "undeclared" is undefined
  Foo::Foo(undeclared)
   ^

"ComeauTest.c", line 8: error: no instance of overloaded function "Foo::Foo"
matches
  the specified type
  Foo::Foo(undeclared)
   ^

[Bug c++/48396] Undeclared library types accepted in namespace std

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-12
 Ever Confirmed|0   |1

[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-12
 Ever Confirmed|0   |1

--- Comment #5 from Richard Guenther  2012-04-12 
12:28:55 UTC ---
Ping?

[Bug c++/44283] bad error recovery for explicit template instantiation in wrong namespace

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-04-12 
12:35:07 UTC ---
(In reply to comment #0)
> namespace NS
> {
> typedef int X;
> 
> template void f(X f, T t) { }
> }
> 
> template void f(X, int); // (1)
> 
> template void f(int, char);  // (2)


Clang does very well for this:

t.cc:8:15: error: explicit instantiation of 'f' does not refer to a function
template, member function, member
  class, or static data member
template void f(X, int); // (1)
  ^
t.cc:10:15: error: explicit instantiation of 'f' does not refer to a function
template, member function,
  member class, or static data member
template void f(int, char);  // (2)
  ^
2 errors generated.



> If the invalid instantiation is for a class template the diagnostic is fine:
> 
> namespace NS
> {
> template struct S;
> }
> 
> template struct S;
> 
> bug2.cc:6:17: error: 'S' is not a template
> bug2.cc:6:19: error: 'X' was not declared in this scope
> bug2.cc:6:17: error: explicit instantiation of non-template type 'S'


Clang is similar:

t.cc:6:19: error: use of undeclared identifier 'X'
template struct S;
  ^
t.cc:6:17: error: explicit instantiation of non-template struct 'S'
template struct S;
^
2 errors generated.



> namespace NS
> {
> template void g() { }
> }
> 
> template void g<0>();
> 
> bug3.cc:6:15: error: variable or field 'g' declared void
> bug3.cc:6:16: error: expected ';' before '<' token


Clang is not much better here:

t.cc:6:16: error: expected ';' after top level declarator
template void g<0>();
   ^
1 error generated.



EDG's diagnostics are still the best for these examples.

[Bug c++/17122] Unable to compile friend operator within template

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  2012-04-12 
12:44:13 UTC ---
Are any of the examples in this PR actually valid?

I think G++ is correct to reject them.

foo ::operator+ is parsed the same as foo::operator+ so still finds the member
function, the parentheses prevent that.

[Bug tree-optimization/52943] [4.7/4.8 Regression] likely wrong code bug caused by predictive commoning

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-04-12 
12:50:30 UTC ---
Author: rguenth
Date: Thu Apr 12 12:50:22 2012
New Revision: 186377

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186377
Log:
2012-04-12  Richard Guenther  

PR tree-optimization/52943
* tree-chrec.h (chrec_is_positive): Remove.
* tree-scalar-evolution.c (chrec_is_positive): Move ...
* tree-data-ref.c (chrec_is_positive): ... here.  Make static.
Return false for a constant zero instead of negative.
(analyze_siv_subscript_cst_affine): Handle zero difference
in the initial condition explicitely.

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

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr52943.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/tree-chrec.h
branches/gcc-4_7-branch/gcc/tree-data-ref.c
branches/gcc-4_7-branch/gcc/tree-scalar-evolution.c

[Bug tree-optimization/52943] [4.7/4.8 Regression] likely wrong code bug caused by predictive commoning

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Richard Guenther  2012-04-12 
12:50:54 UTC ---
Fixed.

[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'

[fabien at gcc dot gnu.org]

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

--- Comment #6 from fabien at gcc dot gnu.org 2012-04-12 12:50:31 UTC ---
(In reply to comment #5)
> Ping?

I haven't yet finished the investigation. Something is broken in c++11 mode,
the parsing of Solvable in "using sat::Solvable::bool_type;" is failing in
c++11 mode, debug_tree() is crashing while debugging it.

[Bug libstdc++/52699] infinite loop generated with -O0

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-12
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.7.1
 Ever Confirmed|0   |1

--- Comment #6 from Paolo Carlini  2012-04-12 
12:52:50 UTC ---
Looks like something is wrong in the operator()() code vs 26.5.4.3.

[Bug bootstrap/52947] [4.7/4.8 Regression] bootstrap fails due to wrong include search path composition

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org
   Target Milestone|--- |4.7.1
Summary|[4.7 Regression] bootstrap  |[4.7/4.8 Regression]
   |fails due to wrong include  |bootstrap fails due to
   |search path composition |wrong include search path
   ||composition

--- Comment #1 from Richard Guenther  2012-04-12 
12:57:39 UTC ---
I remember Kai did surgery in this place.  Did you identify a patch that caused
this regression?  My bet would be

2011-03-25  Kai Tietz  

* collect2.c (write_c_file_stat): Handle backslash
as right-hand directory separator.
(resolve_lib_name): Use IS_DIR_SEPARATOR instead of
checking just for slash.
* coverage.c (coverage_init): Use IS_ABSOLUTE_PATH
instead of checking for trailing slash.
* gcc.c (record_temp_file): Use filename_cmp instead
of strcmp.
(do_spec_1): Likewise.
...

[Bug c++/17122] Unable to compile friend operator within template

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #14 from Manuel López-Ibáñez  2012-04-12 
13:05:16 UTC ---
(In reply to comment #13)
> Are any of the examples in this PR actually valid?
> 
> I think G++ is correct to reject them.
> 
> foo ::operator+ is parsed the same as foo::operator+ so still finds the member
> function, the parentheses prevent that.

Maybe g++ is correct to reject them, but the diagnostics printed are awful.
They are actually worse than saying:

error: Something is wrong somewhere, Please fix it.

template
class foo;  

template
void operator+(int, foo); 

template
void operator-(int, foo); 

template
class foo   
{   
public: 
  void operator+(int){} 
  friend void operator+<>(int, foo);//eliminating <> generates warning to add 
//them  
  friend void operator-(int, foo);//eliminating <> generates warning to add 
//them  

};  
template
void operator+(int, foo){}

template
void operator-(int, foo){}

int main()  
{   
  foo inst; 
  inst+1;   
  1+inst;   
};

pr17122.C:15:23: error: declaration of ‘operator+’ as non-function
   friend void operator+<>(int, foo);//eliminating <> generates warning to add 
   ^
pr17122.C:15:23: error: expected ‘;’ at end of member declaration
   friend void operator+<>(int, foo);//eliminating <> generates warning to add 
   ^
pr17122.C:15:24: error: expected unqualified-id before ‘<’ token
   friend void operator+<>(int, foo);//eliminating <> generates warning to add 
^
pr17122.C:17:33: warning: friend declaration ‘void operator-(int, foo)’
declares a non-template function [-Wnon-template-friend]
   friend void operator-(int, foo);//eliminating <> generates warning to add 
 ^
pr17122.C:17:33: note: (if this is not what you intended, make sure the
function template has already been declared and add <> after the function name
here) 
   friend void operator-(int, foo);//eliminating <> generates warning to add 
 ^

[Bug libstdc++/52699] infinite loop generated with -O0

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  2012-04-12 
13:09:39 UTC ---
And the problem seems pretty clear: we have computations like:

  __s0 = result_type(1) << __w0;

with __w0 which can be 32, result_type 32 bits, thus definitely we aren't
handling a mathematical 2^32, as we should per 26.5.4.3. A fix should be
relatively easy.

[Bug target/52932] AVX2 intrinsic _mm256_permutevar8x32_ps has wrong parameter type

[kirill.yukhin at intel dot com]

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

--- Comment #5 from Yukhin Kirill  2012-04-12 
13:52:26 UTC ---
(In reply to comment #2)
> Created attachment 27133 [details]
> Proposed patch
> 
> Kirill, can you please test proposed patch on AVX2 target?

Uros, I've slightly updated your patch: idx and vector were intermixed.
Attached.
It passes AVX2 testing now

K

[Bug target/52932] AVX2 intrinsic _mm256_permutevar8x32_ps has wrong parameter type

[kirill.yukhin at intel dot com]

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

--- Comment #4 from Yukhin Kirill  2012-04-12 
13:51:26 UTC ---
Created attachment 27140
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27140
Updated patch

[Bug fortran/52916] [4.8 Regression] 481.wrf in SPEC CPU 2006 failed to build

[izamyatin at gmail dot com]

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

--- Comment #5 from Igor Zamyatin  2012-04-12 
13:55:54 UTC ---
With this patch 481.wrf is ok

[Bug target/52932] AVX2 intrinsic _mm256_permutevar8x32_ps has wrong parameter type

[ubizjak at gmail dot com]

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

--- Comment #6 from Uros Bizjak  2012-04-12 13:56:39 
UTC ---
(In reply to comment #5)

> > Kirill, can you please test proposed patch on AVX2 target?
> 
> Uros, I've slightly updated your patch: idx and vector were intermixed.
> Attached.
> It passes AVX2 testing now

Thanks, I will commit the attached patch to mainline and 4.7 branches.

[Bug c++/17122] Unable to compile friend operator within template

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  2012-04-12 
14:07:00 UTC ---

> pr17122.C:17:33: warning: friend declaration ‘void operator-(int, foo)’
> declares a non-template function [-Wnon-template-friend]
>friend void operator-(int, foo);//eliminating <> generates warning to add 
>  ^
> pr17122.C:17:33: note: (if this is not what you intended, make sure the
> function template has already been declared and add <> after the function name
> here) 
>friend void operator-(int, foo);//eliminating <> generates warning to add 
>  ^

Well at least this warning is correct.  For operator- it's 100% correct.  It
causes a problem for operator+ because that clashes with the name of a member
function, so the hint is right but not sufficient to tell you how to make the
code compile, because there's still another error.  You also need to prevent
name lookup from finding the member with the same name.


The example can be reduced to this, replacing operators with named functions:

template 
struct foo;

template 
void f(int, foo) { }

template 
void g(int, foo) { }

template 
struct foo
{
  void f(int) {}

  friend void f<>(int, foo);

  friend void g(int, foo);
};

The warning about 'g' is correct.  The error for 'f' is different now, giving
the "declared void" instead of "as non-function"

[Bug target/49448] arm-tab-linux-gnu-eabi enableds big endian when it should not

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw  2012-04-12 
14:11:37 UTC ---
Author: rearnsha
Date: Thu Apr 12 14:11:33 2012
New Revision: 186379

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186379
Log:
PR target/49448
* config.gcc (arm*-*-linux*): Use an unambiguous pattern for
detecting big-endian triplets.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config.gcc

[Bug target/49448] arm-tab-linux-gnu-eabi enableds big endian when it should not

[rearnsha at gcc dot gnu.org]

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

--- Comment #5 from Richard Earnshaw  2012-04-12 
14:11:53 UTC ---
Author: rearnsha
Date: Thu Apr 12 14:11:49 2012
New Revision: 186380

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186380
Log:
PR target/49448
* config.gcc (arm*-*-linux*): Use an unambiguous pattern for
detecting big-endian triplets.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config.gcc

[Bug testsuite/52948] New: UNRESOLVED: selfassign.c|dumb_plugin.c) in gcc/g++, one_time_plugin.c in gcc, and dumb_plugin.c in g++

[dominiq at lps dot ens.fr]

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

 Bug #: 52948
   Summary: UNRESOLVED: selfassign.c|dumb_plugin.c) in gcc/g++,
one_time_plugin.c in gcc, and dumb_plugin.c in g++
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: davi...@gcc.gnu.org, hjl.to...@gmail.com


Following revision 186342 one gets the following failures:

UNRESOLVED: selfassign.c compilation, -I.
-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite
-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite/../../gcc
-I/export/gnu/import/git/gcc-test-intel64corei7/bld/gcc/testsuite/g++/../../../gcc

-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite/../../include
-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite/../../libcpp/include
 
-I/export/gnu/import/git/gcc-test-intel64corei7/bld/gcc/testsuite/g++/../../../intl
-O -DIN_GCC -fPIC -shared
UNRESOLVED: dumb_plugin.c compilation, -I.
-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite
-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite/../../gcc
-I/export/gnu/import/git/gcc-test-intel64corei7/bld/gcc/testsuite/g++/../../../gcc

-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite/../../include
-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite/../../libcpp/include
 
-I/export/gnu/import/git/gcc-test-intel64corei7/bld/gcc/testsuite/g++/../../../intl
 -DIN_GCC -fPIC -shared

UNRESOLVED: selfassign.c compilation, -I.
-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite
-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite/../../gcc
-I/export/gnu/import/git/gcc-test-intel64corei7/bld/gcc/testsuite/gcc/../../../gcc

-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite/../../include
-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite/../../libcpp/include
 
-I/export/gnu/import/git/gcc-test-intel64corei7/bld/gcc/testsuite/gcc/../../../intl
-O -DIN_GCC -fPIC -shared
UNRESOLVED: one_time_plugin.c compilation, -I.
-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite
-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite/../../gcc
-I/export/gnu/import/git/gcc-test-intel64corei7/bld/gcc/testsuite/gcc/../../../gcc

-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite/../../include
-I/export/gnu/import/git/gcc-test-intel64corei7/src-trunk/gcc/testsuite/../../libcpp/include
 
-I/export/gnu/import/git/gcc-test-intel64corei7/bld/gcc/testsuite/gcc/../../../intl
 -DIN_GCC -fPIC -shared

AFAICT TODO_dump_func should be removed from the tests.

[Bug target/49448] arm-tab-linux-gnu-eabi enableds big endian when it should not

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.4

--- Comment #6 from Richard Earnshaw  2012-04-12 
14:16:43 UTC ---
Fixed in 4.5.4, 4.6.4 4.7 and trunk

[Bug testsuite/52945] FAIL: gcc.dg/lto/pr52634 c_lto_pr52634_1.o assemble, -O* -flto *

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2012-04-12 
14:26:04 UTC ---
> Indeed, it should be tested only when weak aliases are supposed. There is some
> dg trick for that...

Which one between '/* { dg-require-alias "" } */' and '/* { dg-require-weak ""
} */'?
Note also that I don't have any write access.

[Bug testsuite/52948] UNRESOLVED: selfassign.c in gcc/g++, one_time_plugin.c in gcc, and dumb_plugin.c in g++

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|UNRESOLVED: |UNRESOLVED: selfassign.c in
   |selfassign.c|dumb_plugin.c) |gcc/g++, one_time_plugin.c
   |in gcc/g++, |in gcc, and dumb_plugin.c
   |one_time_plugin.c in gcc,   |in g++
   |and dumb_plugin.c in g++|

--- Comment #1 from Dominique d'Humieres  2012-04-12 
14:27:10 UTC ---
Cleaned the summary.

[Bug target/45053] libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc

[rhabarber1848 at web dot de]

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

rhabarber1848 at web dot de changed:

   What|Removed |Added

 CC||rhabarber1848 at web dot de

--- Comment #10 from rhabarber1848 at web dot de 2012-04-12 14:42:55 UTC ---
This bug is still present in 4.7.0.

[Bug c++/17122] Unable to compile friend operator within template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||tkapela at poczta dot fm

--- Comment #16 from Jonathan Wakely  2012-04-12 
14:55:08 UTC ---
*** Bug 30431 has been marked as a duplicate of this bug. ***

[Bug c++/30431] failure to check for visible declaration of friend function to template class

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #5 from Jonathan Wakely  2012-04-12 
14:55:08 UTC ---
(In reply to comment #4)
> Something is wrong with the friend lookup after a member of the same name is
> encountered. After seeing the class member f (either data member or member
> function), gcc forgets that the template function f is in the current
> namespace. 

Nothing is wrong, it just finds 'f' in the class scope so doesn't look in the
enclosing namespace.  That's how name lookup works in classes.


> Bug 17122 is a duplicate, but did not see any activity in 1 year.

Yes, and like PR 17122  the code is invalid and G++ is right to reject it, but
the diagnostic could be improved.

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

[Bug c/52862] [4.5/4.6/4.7/4.8 Regression] ICE convert_to_pointer, at convert.c:50

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-04-12 
15:00:25 UTC ---
I'm testing

Index: convert.c
===
--- convert.c   (revision 186373)
+++ convert.c   (working copy)
@@ -44,11 +44,6 @@ convert_to_pointer (tree type, tree expr
   if (TREE_TYPE (expr) == type)
 return expr;

-  /* Propagate overflow to the NULL pointer.  */
-  if (integer_zerop (expr))
-return force_fit_type_double (type, double_int_zero, 0,
- TREE_OVERFLOW (expr));
-
   switch (TREE_CODE (TREE_TYPE (expr)))
 {
 case POINTER_TYPE:

at least I don't see why 0 is special - for example why we should allow
conversion of a COMPLEX_CST or VECTOR_CST to a pointer.

[Bug libstdc++/52604] mt allocator crashes on multi-threaded

[laurent.alfonsi at st dot com]

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

--- Comment #9 from Laurent Aflonsi  2012-04-12 
15:05:25 UTC ---
Paolo,

I ve discovered that the encoding of M_key is encoded differently for each
thread-implementation. On pthread implementation M_key is an integer, whereas
on others it is pointers. So, in pthread 0 is a legal thread key: So zeroing
M_key and testing if(M_key) is simply wrong.

The M_thread_freelist zeroing seems legal and is enough to avoid the above
valgrind error. I am now testing with this fix only:

--- libstdc++-v3/src/mt_allocator.cc   
+++ libstdc++-v3/src/mt_allocator.cc   
@@ -47,7 +47,8 @@
   if (_M_thread_freelist_array)
 {
   __gthread_key_delete(_M_key);
   ::operator delete(static_cast(_M_thread_freelist_array));
+  _M_thread_freelist = NULL;
 }
 }
   };


It seems to be on each thread-implementation to handle deleted keys and it is
well handled on pthread.

Laurent.

[Bug c/52549] [4.8 Regression] ice in pointer_diff

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Guenther  2012-04-12 
15:06:10 UTC ---
Mine.

[Bug other/52937] [4.8 Regression] ICE in several cpu2006 benchmarks with -fprofile-use (assert in get_loop_body)

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from William J. Schmidt  2012-04-12 
15:06:23 UTC ---
My apologies.  This is occurring in some instrumentation code I added for
testing, and doesn't occur with the unmodified trunk compiler.  I should have
checked that first, but was misled because it looked like similar problems
we've seen recently from the loop changes.

So, take the day off. ;)

[Bug middle-end/52939] [4.7/4.8 Regression] ice in gimple_get_virt_method_for_binfo with -O3

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Jambor  2012-04-12 
15:10:50 UTC ---
Well, what happens is that the target of devirtualization which is
loaded from the VMT is:


constant 0>

I'll investigate why.

[Bug c/52862] [4.5/4.6/4.7/4.8 Regression] ICE convert_to_pointer, at convert.c:50

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

[Bug other/52944] [4.5/4.6 Regression] __builtin_object_size(..., 1) no longer returns (size_t)-1 for consecutive flexible/zero-length array members

[vapier at gentoo dot org]

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

Mike Frysinger  changed:

   What|Removed |Added

  Known to work||4.4.7
  Known to fail||4.5.3, 4.6.3

--- Comment #2 from Mike Frysinger  2012-04-12 
15:13:25 UTC ---
if you look at the tftp example, you'd see that your proposed struct does not
work.  the protocol needs two flexible array members at different starting
points.

the 96 isn't conservative in this case, it's correct.  i declared a buffer of
100 bytes, so buf[0] can cover 96 bytes (as the leading integer is 32bits).  is
there a "simplish" patch that could be backported to the 4.5/4.6 branches for
that ?

thinking a bit more, the requirements can probably be pulled off with more
anonymous unions/structs like so:

struct tftphdr {
short opcode;
union {
struct {
union {
unsigned short tu_block;
short tu_code;
};
char tu_data[0];
};
char tu_stuff[0];
} __attribute__ ((__packed__));
} __attribute__ ((__packed__));

[Bug c++/52949] New: decltype too sensitive to order of declarations?

[akim.demaille at gmail dot com]

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

 Bug #: 52949
   Summary: decltype too sensitive to order of declarations?
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: akim.demai...@gmail.com


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

I am not sure of myself on this one.  I have read a preversion of the standard
(and I checked n2343 too), and I did not find anything very clear about this. 
I do understand that the "rich" version might require some dependency
resolution in full generality, but then again, I have not found the restriction
spelled out in the standard.  The only restriction I spotted is the case of
overloaded functions.  I apologize if this is the expected behavior.

In the following example, the first use of decltype fails because it does not
see the member_ definition, which is right after it.  The second decltype
passes.


$ g++-mp-4.7 --version
g++-mp-4.7 (GCC) 4.7.0
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++-mp-4.7 -std=c++11 foo.cc
foo.cc:3:27: error: 'member_' was not declared in this scope
foo.cc:3:27: error: 'member_' was not declared in this scope
foo.cc: In function 'int main()':
foo.cc:12:5: error: 'struct Vector' has no member named 'val1'

$ g++-mp-4.8 --version
g++-mp-4.8 (GCC) 4.8.0 20120408 (experimental)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++-mp-4.8 -std=c++11 foo.cc
foo.cc:3:27: error: 'member_' was not declared in this scope
foo.cc:3:27: error: 'member_' was not declared in this scope
foo.cc: In function 'int main()':
foo.cc:12:5: error: 'struct Vector' has no member named 'val1'

[Bug testsuite/52948] [4.8 Regression] UNRESOLVED: selfassign.c in gcc/g++, one_time_plugin.c in gcc, and dumb_plugin.c in g++

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-12
   Target Milestone|--- |4.8.0
Summary|UNRESOLVED: selfassign.c in |[4.8 Regression]
   |gcc/g++, one_time_plugin.c  |UNRESOLVED: selfassign.c in
   |in gcc, and dumb_plugin.c   |gcc/g++, one_time_plugin.c
   |in g++  |in gcc, and dumb_plugin.c
   ||in g++
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2012-04-12 
15:21:19 UTC ---
Confirmed.

[Bug other/52944] [4.5/4.6 Regression] __builtin_object_size(..., 1) no longer returns (size_t)-1 for consecutive flexible/zero-length array members

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-04-12 
15:28:10 UTC ---
(In reply to comment #2)
> if you look at the tftp example, you'd see that your proposed struct does not
> work.  the protocol needs two flexible array members at different starting
> points.

Ah, indeed.  Now when inspecting your description closer.

---
with tftp, the packet is described by:
struct tftphdr {
short opcode;
union {
unsigned short tu_block;
short tu_code;
char tu_stuff[0];
};
char th_data[];
};

when opcode is 1, the rest of the packet is a C string.  i.e. the buffer:
char x[] = { 1, 0, 'f', 'i', 'l', 'e', '\0', };
opcode = 1, tu_stuff = "file"

when opcode is 3 though, the tu_block field will be a number, and the rest of
the data will be in th_data.  i.e. the buffer:
char x[] = { 2, 0, 3, 0, <8KiB>, };
opcode = 2, tu_block = 3, th_data = 8KiB
---

So

struct tftphdr {
short opcode;
union {
struct opcode_3 {
   unsigned short tu_block;
   char th_data[];
} opcode3;
short tu_code;
char tu_stuff[0];
};
};

would work.  At least

struct stct {
int i;
union {
struct {
short k;
char tail[];
} x;
char buf[0];
};
};
char buf[100];
main()
{
  struct stct *foo = (void *)buf;
  printf("%i\n", __builtin_object_size(foo->buf, 1));
  printf("%i\n", __builtin_object_size(foo->x.tail, 1));
}

produces the expected 96, 94 values?

> the 96 isn't conservative in this case, it's correct.  i declared a buffer of
> 100 bytes, so buf[0] can cover 96 bytes (as the leading integer is 32bits).  
> is
> there a "simplish" patch that could be backported to the 4.5/4.6 branches for
> that ?

No, and it's only because optimization triggers and we get to see buf[] here.
Otherwise you'd get still zero.

> thinking a bit more, the requirements can probably be pulled off with more
> anonymous unions/structs like so:
> 
> struct tftphdr {
> short opcode;
> union {
> struct {
> union {
> unsigned short tu_block;
> short tu_code;
> };
> char tu_data[0];
> };
> char tu_stuff[0];
> } __attribute__ ((__packed__));
> } __attribute__ ((__packed__));

I don't see how this would avoid the issue for __builtin_object_size
(foo->...tu_data) though.

[Bug bootstrap/52947] [4.7/4.8 Regression] bootstrap fails due to wrong include search path composition

[rai...@emrich-ebersheim.de]

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

--- Comment #2 from Rainer Emrich  2012-04-12 
15:36:11 UTC ---
(In reply to comment #1)
> I remember Kai did surgery in this place.  Did you identify a patch that 
> caused
> this regression?  My bet would be
> 
> 2011-03-25  Kai Tietz  
> 
> * collect2.c (write_c_file_stat): Handle backslash
> as right-hand directory separator.
> (resolve_lib_name): Use IS_DIR_SEPARATOR instead of
> checking just for slash.
> * coverage.c (coverage_init): Use IS_ABSOLUTE_PATH
> instead of checking for trailing slash.
> * gcc.c (record_temp_file): Use filename_cmp instead
> of strcmp.
> (do_spec_1): Likewise.
> ...

To be honest, I don't know. I tried native bootstrapping on x86_64-w64-mingw32
at the beginning of last year but gave up due to the issues found. Lately I
managed to bootstrap the 4.6 series with some manual intervention even ada
included.
There are still issues, one of them is really fundamental, but that's a
different story.

Btw. the PATH composition for --with-local-prefix is messed up the same way.

[Bug libstdc++/52604] mt allocator crashes on multi-threaded

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #10 from Paolo Carlini  2012-04-12 
15:36:52 UTC ---
Ok, thanks. Please let us know how it goes.

[Bug other/52944] [4.5/4.6 Regression] __builtin_object_size(..., 1) no longer returns (size_t)-1 for consecutive flexible/zero-length array members

[vapier at gentoo dot org]

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

--- Comment #4 from Mike Frysinger  2012-04-12 
15:42:49 UTC ---
(In reply to comment #3)

wouldn't it though ?  there's still a top level union there surrounding all the
members.  so flattening it, i'd get three choices:
 - th_block; th_data
 - th_code; th_data
 - th_stuff

the problem before was that it was a union followed by th_data

testing locally with gcc-4.6.2, i get the object sizes of:
 - -O0: th_data:-1 th_stuff:-1
 - -O[s123]: th_data:96 th_stuff:98

[Bug c++/52949] decltype too sensitive to order of declarations?

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Jonathan Wakely  2012-04-12 
15:59:51 UTC ---
The name member_ isn't in scope until it's declared, this is nothing to do with
decltype.

[Bug c++/52949] decltype too sensitive to order of declarations?

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-04-12 
16:12:15 UTC ---
this is no different to;

struct Vector
{
  static const int i = sizeof(member_);   // error
  int member_;
  static const int j = sizeof(member_);   // ok
};

[Bug tree-optimization/18589] could optimize FP multiplies better

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from William J. Schmidt  2012-04-12 
16:15:24 UTC ---
Author: wschmidt
Date: Thu Apr 12 16:15:13 2012
New Revision: 186384

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

2012-04-12  Bill Schmidt  

PR tree-optimization/18589
* tree-ssa-reassoc.c (reassociate_stats): Add two fields.
(operand_entry): Add count field.
(add_repeat_to_ops_vec): New function.
(completely_remove_stmt): Likewise.
(remove_def_if_absorbed_call): Likewise.
(remove_visited_stmt_chain): Remove feeding builtin pow/powi calls.
(acceptable_pow_call): New function.
(linearize_expr_tree): Look for builtin pow/powi calls and add operand
entries with repeat counts when found.
(repeat_factor_d): New struct and associated typedefs.
(repeat_factor_vec): New static vector variable.
(compare_repeat_factors): New function.
(get_reassoc_pow_ssa_name): Likewise.
(attempt_builtin_powi): Likewise.
(reassociate_bb): Call attempt_builtin_powi.
(fini_reassoc): Two new calls to statistics_counter_event.

gcc/testsuite:

2012-04-12  Bill Schmidt  

PR tree-optimization/18589
* gcc.dg/tree-ssa/pr18589-1.c: New test.
* gcc.dg/tree-ssa/pr18589-2.c: Likewise.
* gcc.dg/tree-ssa/pr18589-3.c: Likewise.
* gcc.dg/tree-ssa/pr18589-4.c: Likewise.
* gcc.dg/tree-ssa/pr18589-5.c: Likewise.
* gcc.dg/tree-ssa/pr18589-6.c: Likewise.
* gcc.dg/tree-ssa/pr18589-7.c: Likewise.
* gcc.dg/tree-ssa/pr18589-8.c: Likewise.
* gcc.dg/tree-ssa/pr18589-9.c: Likewise.
* gcc.dg/tree-ssa/pr18589-10.c: Likewise.



Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-10.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-7.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-8.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr18589-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug tree-optimization/18589] could optimize FP multiplies better

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #10 from William J. Schmidt  
2012-04-12 16:16:50 UTC ---
Fixed.

[Bug c/52946] Unable to define a Block variable

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|major   |enhancement

--- Comment #1 from Andrew Pinski  2012-04-12 
16:19:35 UTC ---
Blocks are not part of GNU GCC at all.
The support for them was not submitted upstream by Apple or reimplemented by
anyone else.

[Bug tree-optimization/52734] [4.7/4.8 Regression] Incorrect optimization of uClibc sbrk()

[vries at gcc dot gnu.org]

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

--- Comment #15 from vries at gcc dot gnu.org 2012-04-12 16:25:28 UTC ---
Created attachment 27142
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27142
pr52734.2.patch

Another tentative patch. Also not precise, but a simpler approach.

Now testing.

[Bug libstdc++/52604] mt allocator crashes on multi-threaded

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  2012-04-12 
16:29:32 UTC ---
In mainline, for x86_64-linux, the below patchlet indeed avoids the valgrind
errors and passes make check, make check-performance.

Index: src/c++98/mt_allocator.cc
===
--- src/c++98/mt_allocator.cc(revision 186374)
+++ src/c++98/mt_allocator.cc(working copy)
@@ -48,6 +48,7 @@
 {
   __gthread_key_delete(_M_key);
   ::operator delete(static_cast(_M_thread_freelist_array));
+  _M_thread_freelist = 0;
 }
 }
   };

[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables

[skunk at iskunk dot org]

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

Daniel Richard G.  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #36 from Daniel Richard G.  2012-04-12 
16:28:36 UTC ---
My sysadmin recently upgraded the troublesome AIX 5.3 machine in question, and
this has made the linker issues go away. The minimal test case now passes, and
I can compile and link programs again without any workarounds. This is true
both for GCC 4.5.1 (same build as in the original report), and the older GCC
2.9 bundled with the system.

I'll provide the same patch-level information as Paul Pryor did earlier:

$ oslevel -s
5300-12-05-1140

$ ls -l /usr/bin/ld
lrwxrwxrwx1 bin  bin  15 Dec 02 2004  /usr/bin/ld ->
/usr/ccs/bin/ld
$ ls -l /usr/ccs/bin/ld
-r-xr-xr-x1 bin  bin   38942 Aug 09 2011  /usr/ccs/bin/ld

$ lslpp -h bos.rte.bind_cmds
  Fileset Level Action   Status   Date Time
  
Path: /usr/lib/objrepos
  bos.rte.bind_cmds
  5.3.0.0   COMMIT   COMPLETE 12/02/04 17:04:24
  5.3.0.1   COMMIT   COMPLETE 12/06/04 11:52:51
 5.3.0.30   COMMIT   COMPLETE 09/30/10 10:04:35
 5.3.0.40   COMMIT   COMPLETE 10/01/10 11:02:18
 5.3.0.53   COMMIT   COMPLETE 10/01/10 14:15:17
 5.3.0.65   COMMIT   COMPLETE 10/05/10 09:48:48
  5.3.7.5   COMMIT   COMPLETE 10/06/10 10:04:03
  5.3.8.6   COMMIT   COMPLETE 10/07/10 08:13:13
  5.3.9.7   COMMIT   COMPLETE 10/08/10 08:33:35
 5.3.10.4   COMMIT   COMPLETE 10/14/10 10:35:13
 5.3.11.4   COMMIT   COMPLETE 10/15/10 23:31:34
 5.3.12.1   COMMIT   COMPLETE 10/16/10 00:05:56
 5.3.12.4   COMMIT   COMPLETE 04/03/12 12:34:21

$ lslpp -i bos.rte.bind_cmds
Vendor
  Fileset   CodeProduct Id  Feature Id  Package Name
  
Path: /usr/lib/objrepos
  bos.rte.bind_cmds 5.3.0.0
5765-E6200  bos


I will be happy to provide additional details about the configuration of this
system if anyone needs it.

There does not appear to be anything left to do here as far as GCC is
concerned, so I'm marking this bug as invalid. If anyone feels differently,
feel free to change it back.

[Bug inline-asm/49611] Inline asm should support input/output of flags

[scovich at gmail dot com]

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

--- Comment #3 from Ryan Johnson  2012-04-12 16:39:32 
UTC ---
FYI: based on a discussion from quite some time ago [1], it seems that the
Linux kernel folks would be "tickled pink" to have this feature, and discussed
several potential ways to implement it.

[1] http://lkml.indiana.edu/hypermail/linux/kernel/0111.2/0256.html

[Bug libstdc++/52950] New: --enable-symvers=gnu-versioned-namespace exports symbol twice.

[pluto at agmk dot net]

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

 Bug #: 52950
   Summary: --enable-symvers=gnu-versioned-namespace exports
symbol twice.
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net


for the cross gcc build, the libstdc++.so.7 export symbols twice.
with and without versioning, e.g.:

$ readelf -sW (cross).../libstdc++.so.7 |grep Znwm
   922: 00075610   144 FUNCGLOBAL DEFAULT   12 _Znwm@@GLIBCXX_7.0
  2742: 000756a0   120 FUNCGLOBAL DEFAULT   12
_ZnwmRKSt9nothrow_t@@GLIBCXX_7.0
  1170: 000756a0   120 FUNCGLOBAL DEFAULT   12 _ZnwmRKSt9nothrow_t
  1171: 00075610   144 FUNCGLOBAL DEFAULT   12 _Znwm

the native gcc build exports symbols correctly.

$ readelf -sW /usr/lib64/libstdc++.so.7.0.0|grep Znwm
   332: 00069820   120 FUNCGLOBAL DEFAULT   12
_ZnwmRKSt9nothrow_t@@GLIBCXX_7.0
  3124: 00069790   144 FUNCGLOBAL DEFAULT   12 _Znwm@@GLIBCXX_7.0


$ (cross) x86_64-gnu-linux-g++ -v

Using built-in specs.
COLLECT_GCC=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++
COLLECT_LTO_WRAPPER=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux/lib64/gcc/x86_64-gnu-linux/4.7.1/lto-wrapper
Target: x86_64-gnu-linux
Configured with: ../configure --target=x86_64-gnu-linux --with-arch=x86-64
--prefix=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux
--with-sysroot=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux
--libdir=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux/lib64
--libexecdir=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux/lib64
--with-slibdir=/remote/src/home/builder/toolchain.svn/trunk/sysroot/x86_64-gnu-linux/lib64
--with-gmp-include=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/include
--with-gmp-lib=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/lib
--with-mpfr-include=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/include
--with-mpfr-lib=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/lib
--with-mpc-include=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/include
--with-mpc-lib=/remote/src/home/builder/toolchain.svn/trunk/x86_64-gnu-linux/gcc-math-runtime/lib
--disable-multilib --enable-nls --disable-libgomp --disable-libmudflap
--disable-libssp --disable-libquadmath --disable-libitm --enable-tls
--enable-libstdcxx-allocator=new --enable-extern-template
--enable-libstdcxx-time=rt --enable-libstdcxx-threads --disable-libstdcxx-pch
--disable-lto --disable-plugin --enable-c99 --enable-long-long
--enable-linux-futex --enable-threads=posix --enable-shared --with-pic
--enable-gold --enable-__cxa_atexit --enable-languages=c,c++
--enable-checking=release --enable-symvers=gnu-versioned-namespace
--with-long-double-128 --disable-cld --disable-bootstrap
Thread model: posix
gcc version 4.7.1 20120406 (prerelease) (GCC)

[Bug middle-end/52939] [4.7/4.8 Regression] ice in gimple_get_virt_method_for_binfo with -O3

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  2012-04-12 
17:05:01 UTC ---
Created attachment 27143
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27143
Simple testcase

This should be a simpler testcase.  What happens is that we are
attempting to devirtualize call to a virtual method introduced in a
descendant but with an ancestor which does not have it.  I suppose
this is OK if the call is never executed in run-time.

Dealing with this situation in gimple_get_virt_method_for_binfo would
be easy, but perhaps we want fold_ctor_reference to return NULL is it
is requested to fold an expression from beyond the provided
constructor?

[Bug target/52932] AVX2 intrinsic _mm256_permutevar8x32_ps has wrong parameter type

[ubizjak at gmail dot com]

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

--- Comment #7 from Uros Bizjak  2012-04-12 17:07:56 
UTC ---
Created attachment 27144
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27144
Even more updated patch

Patch that also fixes vpermd insn.

[Bug target/52932] AVX2 intrinsic _mm256_permutevar8x32_ps has wrong parameter type

[ubizjak at gmail dot com]

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

--- Comment #8 from Uros Bizjak  2012-04-12 17:10:31 
UTC ---
(In reply to comment #5)

> Uros, I've slightly updated your patch: idx and vector were intermixed.

The same cure should be applied to vpermd insn. Fortunately, this allowed us to
vectorize vpermps and vpermd patterns.

Please also note that avx2-vpermd-2.c test also had switched operands to
_mm256_permutevar8x32_epi32.

[Bug target/52775] Change default for using FCFID instruction

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  2012-04-12 
17:10:38 UTC ---
Author: meissner
Date: Thu Apr 12 17:10:27 2012
New Revision: 186387

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186387
Log:
[gcc]
2012-04-11  Michael Meissner  

PR target/52775
* config/rs6000/rs6000.h (TARGET_FCFID): Add TARGET_PPC_GPOPT to
the list of options to enable the FCFID instruction.
(TARGET_EXTRA_BUILTINS): Adjust comment.

[gcc/testsuite]
2012-04-11  Michael Meissner  

PR target/52775
* gcc.target/powerpc/pr52775.c: New file.



Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr52775.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.h
trunk/gcc/testsuite/ChangeLog

[Bug target/52932] AVX2 intrinsic _mm256_permutevar8x32_ps has wrong parameter type

[uros at gcc dot gnu.org]

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

--- Comment #9 from uros at gcc dot gnu.org 2012-04-12 18:37:47 UTC ---
Author: uros
Date: Thu Apr 12 18:37:42 2012
New Revision: 186388

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186388
Log:
PR target/52932
* config/i386/avx2intrin.h (_mm256_permutevar8x32_ps): Change second
argument type to __m256i.  Update call to __builtin_ia32_permvarsf256.
* config/i386/sse.md (UNSPEC_VPERMVAR): New.
(UNSPEC_VPERMSI, UNSPEC_VPERMSF): Remove.
(avx2_permvarv8sf, avx2_permvarv8si): Switch operands 1 and 2.
(avx2_permvar): Macroize insn from avx2_permvarv8sf and
avx2_permvarv8si using VI4F_256 mode iterator.
* config/i386/i386.c (bdesc_args) <__builtin_ia32_permvarsf256>:
Update builtin type to V8SF_FTYPE_V8SF_V8SI.
(ix86_expand_vec_perm): Update calls to gen_avx2_permvarv8si and
gen_avx2_permvarv8sf.
(expand_vec_perm_pshufb): Ditto.

testsuite/ChangeLog:

PR target/52932
* gcc.target/i386/avx2-vpermps-1.c (avx2_test): Use __m256i type for
second function argument.
* gcc.target/i386/avx2-vpermps-2.c (init_permps): Update declaration.
(calc_permps): Update declaration.  Calculate result correctly.
(avx2_test): Change src2 type to union256i_d.
* gcc.target/i386/avx2-vpermd-2.c (calc_permd): Calculate result
correctly.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/avx2intrin.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx2-vpermd-2.c
trunk/gcc/testsuite/gcc.target/i386/avx2-vpermps-1.c
trunk/gcc/testsuite/gcc.target/i386/avx2-vpermps-2.c

[Bug c/52946] Unable to define a Block variable

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #2 from Manuel López-Ibáñez  2012-04-12 
18:39:56 UTC ---
Which means that this is a proprietary non-portable extension by Apple. It
doesn't work with other compilers except Apple's. You should really not use it.

[Bug c++/46400] g++ Segmentation Fault on heavily templated project.

[bergner at gcc dot gnu.org]

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

--- Comment #13 from Peter Bergner  2012-04-12 
19:16:16 UTC ---
Created attachment 27145
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27145
Test case from EMAN2

Here's yet another test case that fails (on powerpc64-linux) and is fixed on
mainline with Jakub's patch.  However, we encountered this using GCC 4.6. 
Jakub, is it possible to backport your patch to FSF 4.6?

I looked at backporting the patch myself, but I'm not really sure what all that
GC magic macro stuff is doing to feel confident in backporting it myself.


bergner@bns:~/gcc/BUGS>
/home/bergner/gcc/install/gcc-fsf-mainline-r175389/bin/g++ -m64 -mcpu=power7
-O0 -ffast-math -fPIC -S libpyEMData2.ii 
bergner@bns:~/gcc/BUGS> echo $?
0
bergner@bns:~/gcc/BUGS>
/home/bergner/gcc/install/gcc-fsf-mainline-r175388/bin/g++ -m64 -mcpu=power7
-O0 -ffast-math -fPIC -S libpyEMData2.ii 
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/52951] New: internal compiler error with c++11 initializer lists and C arrays

[drwowe at yahoo dot com]

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

 Bug #: 52951
   Summary: internal compiler error with c++11 initializer lists
and C arrays
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: drw...@yahoo.com


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

The following trivial snippet produces "internal compiler error: Segmentation
fault".  Tested with 4.7.0 and 4.6.3 on two different architectures.

g++-4.7 -c -std=c++11 test.cc

 test.cc:
#include 
std::pair foo = {1, {2} };




g++-4.7 -v
Using built-in specs.
COLLECT_GCC=g++-4.7
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --program-suffix=-4.7
Thread model: posix
gcc version 4.7.0 (GCC)

[Bug testsuite/52948] [4.8 Regression] UNRESOLVED: selfassign.c in gcc/g++, one_time_plugin.c in gcc, and dumb_plugin.c in g++

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2012-04-12 
20:54:35 UTC ---
Indeed, removing the lines

 TODO_dump_func/* todo_flags_finish */

fixes the PR (I don't have write permissions).

[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment

[jyasskin at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey Yasskin  2012-04-12 
20:59:14 UTC ---
Author: jyasskin
Date: Thu Apr 12 20:59:09 2012
New Revision: 186391

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186391
Log:
Fix PR52822 (stable_partition move-assigns object to itself) by
scanning for the first value that doesn't match the predicate before
starting to rearrange values.

2012-04-03   Jeffrey Yasskin  

PR libstdc++/52822
* include/bits/stl_algo.h (__find_if_not): Expose in
C++98 mode.
(__find_if_not_n): Like __find_if_not, but works on and updates a
counted range instead of a bounded range.
(stable_partition): Guarantee !__pred(*__first) in call to
__stable_partition_adaptive() or __inplace_stable_partition().
(__stable_partition_adaptive): Use new precondition to avoid
moving/copying objects onto themselves.  Guarantee new
precondition to recursive calls.
(__inplace_stable_partition): Use new precondition to simplify
base case, remove __last parameter.  Guarantee new precondition to
recursive calls.
* testsuite/25_algorithms/stable_partition/moveable.cc (test02):
Test a sequence that starts with a value matching the predicate.
* testsuite/25_algorithms/stable_partition/pr52822.cc:
Test vectors, which have a destructive self-move-assignment.

Added:
trunk/libstdc++-v3/testsuite/25_algorithms/stable_partition/pr52822.cc
  - copied, changed from r186389,
trunk/libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_algo.h
trunk/libstdc++-v3/testsuite/25_algorithms/stable_partition/moveable.cc

[Bug target/52775] Change default for using FCFID instruction

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  2012-04-12 
21:00:17 UTC ---
Author: meissner
Date: Thu Apr 12 21:00:07 2012
New Revision: 186392

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186392
Log:
[gcc]
2012-04-12  Michael Meissner  

Backport from mainline
2012-04-12  Michael Meissner  

PR target/52775
* config/rs6000/rs6000.h (TARGET_FCFID): Add TARGET_PPC_GPOPT to
the list of options to enable the FCFID instruction.
(TARGET_EXTRA_BUILTINS): Adjust comment.

[gcc/testsuite]
012-04-12  Michael Meissner  

Backport from mainline
2012-04-12  Michael Meissner  

PR target/52775
* gcc.target/powerpc/pr52775.c: New file.


Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/powerpc/pr52775.c
  - copied unchanged from r186389,
trunk/gcc/testsuite/gcc.target/powerpc/pr52775.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/rs6000/rs6000.h
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog