[Bug target/53194] [4.8 Regression] Many x86 failures

[kirill.yukhin at intel dot com]

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

--- Comment #3 from Yukhin Kirill  2012-05-03 
07:01:37 UTC ---
Created attachment 27299
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27299
Proposed solution

[Bug target/53194] [4.8 Regression] Many x86 failures

[kirill.yukhin at intel dot com]

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

--- Comment #4 from Yukhin Kirill  2012-05-03 
07:02:50 UTC ---
(In reply to comment #3)
> Created attachment 27299 [details]
> Proposed solution

Attached patch cures failing tests

[Bug target/53194] [4.8 Regression] Many x86 failures

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-05-03
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #5 from Jakub Jelinek  2012-05-03 
07:07:23 UTC ---
Created attachment 27300
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27300
gcc48-pr53194.patch

Alternate patch, see http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00730.html

[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 #7 from Tobias Burnus  2012-05-03 
07:19:08 UTC ---
Author: burnus
Date: Thu May  3 07:18:56 2012
New Revision: 187076

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187076
Log:
2012-05-03  Tobias Burnus  

PR fortran/52864
* interface.c (compare_parameter_intent): Remove.
(check_intents): Remove call, handle CLASS pointer.
(compare_actual_formal): Handle CLASS pointer.

2012-05-03  Tobias Burnus  

PR fortran/52864
* gfortran.dg/pointer_intent_7.f90: New.
* gfortran.dg/pure_formal_3.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/pointer_intent_7.f90
trunk/gcc/testsuite/gfortran.dg/pure_formal_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug target/53201] [4.8 Regression] unrecognized command line option '-mno-lzcnt-mno-hle

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from Jakub Jelinek  2012-05-03 
07:30:18 UTC ---
Fixed.

[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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #8 from Tobias Burnus  2012-05-03 
07:41:00 UTC ---
FIXED.

The regression of comment 0 by Vladimír has been solved for the trunk (4.8) and
the 4.7/4.6 branches.

The nonregression of comment 2 by Neil has been solved for the trunk (4.8).

Thanks for the bug reports!

[Bug target/53187] ICE in arm_select_dominance_cc_mode

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #3 from Nick Clifton  2012-05-03 07:44:12 
UTC ---
Hi Jakub,

  I have tested the patch - it works and there are no regressions in the gcc
testsuite.  Thus I am happy to approve the ARM specific parts of the patch (for
the mainline and the 4.7 branch).

Cheers
  Nick

[Bug rtl-optimization/53190] CSE (?) CSEs asms

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-05-03 
07:59:40 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > (clobber (reg:QI 18 fpsr))
> > (clobber (reg:QI 17 flags))
> > 
> > 
> > It might clobber those but that is not considered an use.  So CSE is doing 
> > the
> > correct thing as there is no use based on fpsr.
> 
> The asm that depends on some unknown-to-gcc global processor state should be
> marked as volatile.
> 
> This is a bug in glibc.
> 
> As a side note, mathinline.h really needs some serious TLC, there are many
> functions that are much better implemented with gcc builtin functions, not to
> mention that x87 asm in 32bit case interferes *badly* with -mfpmath=sse.
> 
> Fortunately, there is -D__NO_MATH_INLINES, used in my projects from day one.
> 
> Really, there is no justification for mathinline.h to live, as far as gcc is
> concerned.

So you say that it's correct for CSE to CSE asm()s if they have the same
asm string and the same asm operands in case the asm is not volatile?  I was
not aware we would do that ;)  (but yes, it sounds like a reasonable thing)

[Bug c++/53206] overloaded virtual non const warning

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-05-03 
08:08:53 UTC ---
It depends what you consider a false positive.  I imagine it's 100% accurate,
but it doesn't always indicate a bug, sometimes it warns about code that
behaves exactly as intended.

If it's enabled then the manual should be updated to show one way to unhide the
virtual

struct B: public A {
  using A::f;
  void f(int);
};

[Bug rtl-optimization/53190] CSE (?) CSEs asms

[ubizjak at gmail dot com]

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

--- Comment #5 from Uros Bizjak  2012-05-03 08:15:00 
UTC ---
(In reply to comment #4)

> So you say that it's correct for CSE to CSE asm()s if they have the same
> asm string and the same asm operands in case the asm is not volatile?  I was
> not aware we would do that ;)  (but yes, it sounds like a reasonable thing)

There is nothing that prevents gcc from doing this...

BTW: fpsr is FP *status* register, an x87 CC-like internal register. This asm
should probably depend on fpcr, a FP *control* register.

In fact, there are two FP control registers, x87 and SSE one. The later is not
handled at all.

[Bug rtl-optimization/53190] CSE (?) CSEs asms

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  
2012-05-03 08:19:17 UTC ---
On Thu, 3 May 2012, ubizjak at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53190
> 
> --- Comment #5 from Uros Bizjak  2012-05-03 
> 08:15:00 UTC ---
> (In reply to comment #4)
> 
> > So you say that it's correct for CSE to CSE asm()s if they have the same
> > asm string and the same asm operands in case the asm is not volatile?  I was
> > not aware we would do that ;)  (but yes, it sounds like a reasonable thing)
> 
> There is nothing that prevents gcc from doing this...
> 
> BTW: fpsr is FP *status* register, an x87 CC-like internal register. This asm
> should probably depend on fpcr, a FP *control* register.
> 
> In fact, there are two FP control registers, x87 and SSE one. The later is not
> handled at all.

Well, the asm in glibc is simply

extern __inline __attribute__ ((__always_inline__)) long int
__attribute__ ((__nothrow__ )) lrintf (float __x)
{
  long int __res;
  __asm ("cvtss2si %1, %0" : "=r" (__res) : "xm" (__x));
  return __res;
}

thus the CLOBBERs somehow magically appear anyways it seems.

[Bug c++/53202] Copy constructor not called when starting a thread

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-05-03 
08:22:51 UTC ---
Created attachment 27301
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27301
preprocessed source

This preprocessed source was created by G++ version 4.6.3 20120306 (Red Hat
4.6.3-2)

When compiled with 4.6.3 it gives:

default ctor called, this=0x7fffba05109f
copy ctor called, this=0x7fffba051067
move ctor called, this=0x253d010
destructor called, this=0x7fffba051067
void background_hello::operator()() called, this=0x253d010
destructor called, this=0x253d010
destructor called, this=0x7fffba05109f

When the same preprocessed source is compiled with the 4.7 branch or trunk it
gives:

default ctor called, this=0x7fff8a2f7daf
move ctor called, this=0x1d56010
destructor called, this=0x7fff8a2f7d77
void background_hello::operator()() called, this=0x1d56010
destructor called, this=0x1d56010
destructor called, this=0x7fff8a2f7daf

N.B. there is only one missing constructor here, compared to two when the
original source is compiled with trunk, I guess that's due to a change in
 between 4.6 and 4.8, but the same preprocessed input should still
produce the same result with both versions, so I think that rules out library
changes being the sole cause of this bug

[Bug c++/53202] Copy constructor not called when starting a thread

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-05-03 
08:30:38 UTC ---
For that preprocessed source the difference is in the Bind_simple constructor,
for 4.6 it is:

Bind_simple::Bind_simple(const Callable&) [with Callable =
background_hello] (struct Bind_simple * const this, const struct
background_hello & callable)
{
  struct tuple * D.5382;
  struct tuple * D.5383;

  D.5382 = &this->_M_bound;
  std::tuple::tuple (D.5382, callable);
  try
{

}
  catch
{
  D.5383 = &this->_M_bound;
  std::tuple::~tuple (D.5383);
}
}

But for 4.8 it fails to initialise its member _M_bound:

Bind_simple::Bind_simple(const Callable&) [with Callable =
background_hello] (struct Bind_simple * const this, const struct
background_hello & callable)
{
  struct tuple * D.6070;

  try
{

}
  catch
{
  D.6070 = &this->_M_bound;
  std::tuple::~tuple (D.6070);
}
}

[Bug tree-optimization/53168] ICE in find_or_generate_expression, at tree-ssa-pre.c:3053

[steven at gcc dot gnu.org]

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

--- Comment #4 from Steven Bosscher  2012-05-03 
08:31:54 UTC ---
I don't remember. Did you look at the paper/thesis to see if it says anything
about this?

[Bug middle-end/53144] [4.7/4.8 Regression] PPRE infinite loop

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther  2012-05-03 
08:37:24 UTC ---
Author: rguenth
Date: Thu May  3 08:37:18 2012
New Revision: 187078

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187078
Log:
2012-05-03  Richard Guenther  

PR tree-optimization/53144
* tree-ssa-sccvn.c (vn_reference_lookup_or_insert_constant_for_pieces):
Rename to ...
(vn_reference_lookup_or_insert_for_pieces): ... this.  Properly deal
with SSA name values.
(vn_reference_lookup_3): Adjust callers.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr53144.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug rtl-optimization/53190] CSE (?) CSEs asms

[ubizjak at gmail dot com]

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

--- Comment #7 from Uros Bizjak  2012-05-03 08:39:19 
UTC ---
(In reply to comment #6)

> Well, the asm in glibc is simply
> 
> extern __inline __attribute__ ((__always_inline__)) long int
> __attribute__ ((__nothrow__ )) lrintf (float __x)
> {
>   long int __res;
>   __asm ("cvtss2si %1, %0" : "=r" (__res) : "xm" (__x));
>   return __res;
> }
> 
> thus the CLOBBERs somehow magically appear anyways it seems.

Yes, this is done in ix86_md_asm_clobbers. The reasoning is the same as for
flags reg, most asms "probably" touch both status regs anyway. This prevents
asms from being scheduled in between CC-like producer/consumer chain.

[Bug middle-end/53144] [4.7/4.8 Regression] PPRE infinite loop

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther  2012-05-03 
08:49:09 UTC ---
Author: rguenth
Date: Thu May  3 08:49:03 2012
New Revision: 187080

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187080
Log:
2012-05-03  Richard Guenther  

PR tree-optimization/53144
* tree-ssa-sccvn.c (vn_reference_lookup_or_insert_constant_for_pieces):
Rename to ...
(vn_reference_lookup_or_insert_for_pieces): ... this.  Properly deal
with SSA name values.
(vn_reference_lookup_3): Adjust callers.

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

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr53144.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/tree-ssa-sccvn.c

[Bug middle-end/53144] [4.7/4.8 Regression] PPRE infinite loop

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.7.1, 4.8.0
 Resolution||FIXED

--- Comment #11 from Richard Guenther  2012-05-03 
08:50:16 UTC ---
Fixed.

[Bug rtl-optimization/53190] CSE (?) CSEs asms

[aj at gcc dot gnu.org]

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

--- Comment #8 from Andreas Jaeger  2012-05-03 09:19:16 
UTC ---
So, how should the inline rewritten?

Adding volatile is one option:
extern __inline __attribute__ ((__always_inline__)) long int
__attribute__ ((__nothrow__ )) lrintf (float __x)
{
  long int __res;
  __asm __volatile__ ("cvtss2si %1, %0" : "=r" (__res) : "xm" (__x));
  return __res;
}

Since this is SSE code: Is there any way to clobber the SSE control register?
Any better way to write the above?

Btw. I'd like to make two changes for glibc:
* Fix the inline
* Only declare the inline when lrintf is not available as builtin. lrint was
introduce in 2003-08-28, so should be part of gcc 3.4 and therefore for GCC 3.4
and newer my patch will not use the above anymore.

[Bug c++/53206] overloaded virtual non const warning

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  2012-05-03 
09:38:13 UTC ---
So what is your opinion? Should it be enabled?

[Bug rtl-optimization/53190] CSE (?) CSEs asms

[ubizjak at gmail dot com]

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

--- Comment #9 from Uros Bizjak  2012-05-03 09:38:59 
UTC ---
(In reply to comment #8)
> So, how should the inline rewritten?
> 
> Adding volatile is one option:
> extern __inline __attribute__ ((__always_inline__)) long int
> __attribute__ ((__nothrow__ )) lrintf (float __x)
> {
>   long int __res;
>   __asm __volatile__ ("cvtss2si %1, %0" : "=r" (__res) : "xm" (__x));
>   return __res;
> }
> 
> Since this is SSE code: Is there any way to clobber the SSE control register?
> Any better way to write the above?

The insn above doesn't clobber SSE CR, but it uses it. But there is no MXCSR
reg listed in gcc ATM. I see no other way to prevent CSE or moves of these
ASMs.

> Btw. I'd like to make two changes for glibc:
> * Fix the inline
> * Only declare the inline when lrintf is not available as builtin. lrint was
> introduce in 2003-08-28, so should be part of gcc 3.4 and therefore for GCC 
> 3.4
> and newer my patch will not use the above anymore.

[Bug target/53194] [4.8 Regression] Many x86 failures

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2012-05-03 
10:12:39 UTC ---
Author: jakub
Date: Thu May  3 10:12:33 2012
New Revision: 187084

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187084
Log:
PR target/53194
* config/i386/i386-c.c (ix86_target_macros_internal): Don't
define __ATOMIC_HLE_* macros here.
(ix86_target_macros): But here, using cpp_define_formatted.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-c.c

[Bug target/53187] ICE in arm_select_dominance_cc_mode

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-05-03 
10:16:05 UTC ---
Author: jakub
Date: Thu May  3 10:16:01 2012
New Revision: 187085

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187085
Log:
PR target/53187
* config/arm/arm.c (arm_select_cc_mode): If x has MODE_CC class
mode, return that mode.

* gcc.target/arm/pr53187.c: New test.
* gcc.c-torture/compile/pr53187.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr53187.c
trunk/gcc/testsuite/gcc.target/arm/pr53187.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug target/53187] ICE in arm_select_dominance_cc_mode

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-05-03 
10:17:06 UTC ---
Author: jakub
Date: Thu May  3 10:17:02 2012
New Revision: 187086

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187086
Log:
PR target/53187
* config/arm/arm.c (arm_select_cc_mode): If x has MODE_CC class
mode, return that mode.

* gcc.target/arm/pr53187.c: New test.
* gcc.c-torture/compile/pr53187.c: New test.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/compile/pr53187.c
branches/gcc-4_7-branch/gcc/testsuite/gcc.target/arm/pr53187.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/arm/arm.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug debug/53174] [4.6/4.7/4.8 Regression] ICE in expand_debug_expr, verify_ssa failed

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-05-03 
10:18:39 UTC ---
Author: jakub
Date: Thu May  3 10:18:34 2012
New Revision: 187087

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187087
Log:
PR debug/53174
* tree-predcom.c (remove_stmt): Call reset_debug_uses on stmts being
removed.

* gcc.dg/pr53174.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr53174.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-predcom.c

[Bug debug/53174] [4.6/4.7/4.8 Regression] ICE in expand_debug_expr, verify_ssa failed

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2012-05-03 
10:19:32 UTC ---
Author: jakub
Date: Thu May  3 10:19:29 2012
New Revision: 187088

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187088
Log:
PR debug/53174
* tree-predcom.c (remove_stmt): Call reset_debug_uses on stmts being
removed.

* gcc.dg/pr53174.c: New test.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr53174.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/tree-predcom.c

[Bug target/53187] ICE in arm_select_dominance_cc_mode

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Jakub Jelinek  2012-05-03 
10:28:49 UTC ---
Fixed.

[Bug rtl-optimization/53176] [4.8 Regression] gcc.target/i386/movbe-2.c and gcc.dg/lower-subreg-1.c

[Greta.Yorsh at arm dot com]

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

Greta Yorsh  changed:

   What|Removed |Added

 CC||Greta.Yorsh at arm dot com

--- Comment #12 from Greta Yorsh  2012-05-03 
10:29:17 UTC ---
Fails on arm-none-eabi as well:
FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 "Splitting reg"

[Bug target/53194] [4.8 Regression] Many x86 failures

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2012-05-03 
10:29:55 UTC ---
Fixed.

[Bug debug/53174] [4.6 Regression] ICE in expand_debug_expr, verify_ssa failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.6/4.7/4.8 Regression]|[4.6 Regression] ICE in
   |ICE in expand_debug_expr,   |expand_debug_expr,
   |verify_ssa failed   |verify_ssa failed

--- Comment #7 from Jakub Jelinek  2012-05-03 
10:29:26 UTC ---
Fixed for 4.7+ so far.

[Bug regression/53203] [4.8 Regression]: gcc.dg/setjmp-1.c

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

Version|4.7.0   |4.8.0
   Target Milestone|--- |4.8.0

[Bug bootstrap/53200] [4.8 Regression] bootstrap broken on x86_64-apple-darwin10 at revision 187018

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug plugins/53126] gcc-4.7.0 error "gcc-ar: Cannot find plugin"

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2012-05-03 
10:40:58 UTC ---
And eventually split out the code to avoid bogus duplicates?

[Bug target/53201] [4.8 Regression] unrecognized command line option '-mno-lzcnt-mno-hle

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug tree-optimization/53198] [4.6/4.7 Regression] gcc wrongly emits "array subscript is above array bounds" for simple arrays

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-03
  Component|c   |tree-optimization
Summary|[4.6 Regression] gcc|[4.6/4.7 Regression] gcc
   |wrongly emits "array|wrongly emits "array
   |subscript is above array|subscript is above array
   |bounds" for simple arrays   |bounds" for simple arrays
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2012-05-03 
10:46:30 UTC ---
Confirmed.  This is because of loop header copying doing

:
  D.1711_8 = devices[0];
  if (D.1711_8 != 0B)
goto ;
  else
goto ;

:
  i_7 = 0;

:
  # i_9 = PHI <0(3), i_4(4)>
  i_4 = i_9 + 1;
  D.1711_3 = devices[i_4];
  if (D.1711_3 != 0B)
goto ;
  else
goto ;

thus VRP sees that the access in the loop uses indices of [1, INF] which
is out-of bounds.  In 4.8 we recognize that the loop can only run once
(because of the initializer size) and optimize the variable array access
away.

[Bug c++/53206] overloaded virtual non const warning

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2012-05-03 
10:54:09 UTC ---
I don't have a strong opinion.

In the large codebase I'm working on currently we use -Wall -Wextra but don't
use -Woverloaded-virtual (and we are aware of it, it's in a Makefile but
commented out) because it generates too much noise.  If it was in -Wall or
-Wextra we'd probably use -Wno-overloaded-virtual

But that's just one codebase and we could disable it or add using directives
everywhere if it was added to -Wextra

[Bug target/53209] New: tree check ICE: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038

[jamborm at gcc dot gnu.org]

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

 Bug #: 53209
   Summary: tree check ICE: expected tree_vec, have error_mark in
comp_template_args_with_info, at cp/pt.c:7038
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jamb...@gcc.gnu.org
CC: tmsri...@google.com
  Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu


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

Hi,

starting with revision 186789, a native i686 compiler ICEs on the
attached testcase with the following message:

--
jamborm@gcc45:~/tmp$ ~/gcc/trunk/inst/bin/g++ -g -O2 -D_GNU_SOURCE -c -fPIC
-std=gnu++11 -fno-implicit-templates  functexcept.ii

In file included from
/home/mjambor/gcc/trunk/obj/i686-pc-linux-gnu/libstdc++-v3/include/future:38:0, 
 from
/home/mjambor/gcc/trunk/src/libstdc++-v3/src/c++11/functexcept.cc:32:
/home/mjambor/gcc/trunk/obj/i686-pc-linux-gnu/libstdc++-v3/include/functional:
In member function ‘std::__regex::_StateIdT
std::__regex::_Nfa::_M_insert_accept()’:
/home/mjambor/gcc/trunk/obj/i686-pc-linux-gnu/libstdc++-v3/include/functional:2057:63:
internal compiler error: tree check: expected tree_vec, have error_mark in
comp_template_args_with_info, at cp/pt.c:7038
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
--

I'm sorry the testcase is not at all reduced but multidelta has only
managed to produce something that makes GCC run out of memory on my
i686 desktop.  I may try again over the next night.

One particular problem with this ICE is that starting with revision
186948 (a libstdc++ change), I cannot build gcc on my i686 desktop,
(which means that until this is resolved I cannot follow trunk when
doing my work!), although I do not have this problem on a i686 machine
on the compile farm (gcc45).  However, when I take the pre-processed
source to that machine, the trunk compiler ICEs there too (with the
same exact error).

The ICE has started to appear with the following commit (that is the
reason why I filed the component as target):


r186789 | tmsriram | 2012-04-25 02:08:37 +0200 (Wed, 25 Apr 2012) | 61 lines

2012-04-24  Sriraman Tallam  

This patch adds new builtins to check for cpu type and features.

* __builtin_cpu_is ("")
* __builtin_cpu_supports ("")

apart from the cpu init builtin, __builtin_cpu_init.

List of CPU names :

* "amd"
* "intel"
* "atom"
* "core2"
* "corei7"
* "nehalem"
* "westmere"   
* "sandybridge"
* "amdfam10h"  
* "barcelona"  
* "shanghai"   
* "istanbul"   
* "bdver1" 
* "bdver2" 

List of CPU features : 

* "cmov"   
* "mmx"
* "popcnt" 
* "sse"
* "sse2"   
* "sse3"   
* "ssse3"  
* "sse4.1" 
* "sse4.2" 
* "avx"

* config/i386/i386.c (build_processor_model_struct): New function.
(make_var_decl): New function.
(fold_builtin_cpu): New function.
(ix86_fold_builtin): New function.
(make_cpu_type_builtin): New function.
(ix86_init_platform_type_builtins): New function.
(ix86_expand_builtin): Expand new builtins by folding them.
(ix86_init_builtins): Make new builtins to detect CPU type.
(TARGET_FOLD_BUILTIN): New macro.
(IX86_BUILTIN_CPU_INIT): New enum value.
(IX86_BUILTIN_CPU_IS): New enum value.
(IX86_BUILTIN_CPU_SUPPORTS): New enum value.
* config/i386/i386-builtin-types.def: New function type.
* testsuite/gcc.target/builtin_target.c: New testcase.
* doc/extend.texi: Document builtins.

* libgcc/config/i386/i386-cpuinfo.c: New file.
* libgcc/config/i386/t-cpuinfo: New file.
* libgcc/config.host: Include t-cpuinfo.
* libgcc/config/i386/libgcc-glibc.ver: Version symbol __cpu_model.

[Bug tree-optimization/53185] [4.8 Regression] segmentation fault in vectorizable_load

[markus at trippelsdorf dot de]

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

--- Comment #4 from Markus Trippelsdorf  
2012-05-03 10:59:05 UTC ---
The testcase now (trunk@187082) segfaults in fold_binary_loc:

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 29611]
0x009cb27d in fold_binary_loc(unsigned int, tree_code, tree_node*,
tree_node*, tree_node*) ()
(gdb) bt
#0  0x009cb27d in fold_binary_loc(unsigned int, tree_code, tree_node*,
tree_node*, tree_node*) ()
#1  0x00b574fa in fold_build2_stat_loc(unsigned int, tree_code,
tree_node*, tree_node*, tree_node*) ()
#2  0x006e29ae in ?? ()
#3  0x00700f28 in vect_transform_stmt(gimple_statement_d*,
gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) ()
#4  0x0052a273 in vect_transform_loop(_loop_vec_info*) ()
#5  0x004ffef0 in vectorize_loops() ()

[Bug rtl-optimization/53190] CSE (?) CSEs asms

[aj at gcc dot gnu.org]

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

--- Comment #10 from Andreas Jaeger  2012-05-03 11:02:43 
UTC ---
So, should somebody file a bug against GCC that to make the SSE cr available?

[Bug plugins/53126] gcc-4.7.0 error "gcc-ar: Cannot find plugin"

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2012-05-03 
11:09:12 UTC ---
Author: jakub
Date: Thu May  3 11:09:07 2012
New Revision: 187090

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187090
Log:
PR plugins/53126
* gcc-ar.c (main): If GCC_EXEC_PREFIX is set in env,
append program name to it and pass that as first argument
to make_relative_prefix.  Always pass standard_libexec_prefix
as last argument to make_relative_prefix.  If
make_relative_prefix returns NULL, fall back to
standard_libexec_prefix.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcc-ar.c

[Bug tree-optimization/53128] [4.8 Regression] Compiler produces infinite loop on regular O2

[izamyatin at gmail dot com]

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

--- Comment #4 from Igor Zamyatin  2012-05-03 
11:09:15 UTC ---
Isn't it too aggressive from user perspective to perform such transformation
even without warning? Especially for the case when that "wrong" read is not
used later.
Sure it is dangerous anyway to make such access but at he same time it seems
this could affect lot of existing code...

[Bug plugins/53126] gcc-4.7.0 error "gcc-ar: Cannot find plugin"

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2012-05-03 
11:09:51 UTC ---
Author: jakub
Date: Thu May  3 11:09:46 2012
New Revision: 187091

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187091
Log:
PR plugins/53126
* gcc-ar.c (main): If GCC_EXEC_PREFIX is set in env,
append program name to it and pass that as first argument
to make_relative_prefix.  Always pass standard_libexec_prefix
as last argument to make_relative_prefix.  If
make_relative_prefix returns NULL, fall back to
standard_libexec_prefix.

Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/gcc-ar.c

[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

--- Comment #9 from Richard Guenther  2012-05-03 
11:23:33 UTC ---
Ping?

[Bug rtl-optimization/53190] CSE (?) CSEs asms

[ubizjak at gmail dot com]

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

--- Comment #11 from Uros Bizjak  2012-05-03 11:43:16 
UTC ---
(In reply to comment #10)
> So, should somebody file a bug against GCC that to make the SSE cr available?

Er, gcc doesn't need it, all SSE conversion builtins are implemented without
touching MXCSR. Please see lfloor and lceil implementations via
x86_expand_lfloorceil.

[Bug c++/53210] New: warning for data member initialized with itself should be in -Wall

[redi at gcc dot gnu.org]

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

 Bug #: 53210
   Summary: warning for data member initialized with itself should
be in -Wall
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


struct S {
S(int i) : j(j) { __builtin_printf("init'd to %d\n", i); }
int j;
};

The code has a typo, the mem-initializer should have been l(i)

G++ knows how to warn about the self-initialization, but only does so when
-Winit-self is used:

s.cc: In constructor 'S::S(int)':
s.cc:2:5: warning: 'S::j' is initialized with itself [-Wuninitialized]

Although the warning is enabled by -Winit-self it is reported as
-Wuninitialized (which kinda makes sense as it requires both to be active)

More importantly, I think this code should always warn. 

-Winit-self is off to avoid warnings for (questionable) code which does
   int i = i;
but there is no good reason to do that in a constructor's mem-initializer-list,
so no reason that -Wall shouldn't warn about it.

If you want 'i' to be uninitialized, simply leave it out of the
mem-initializer-list.  Adding a mem-initializer that does self-init is just
perverse.

[Bug c++/53210] warning for data member initialized with itself should be in -Wall

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-05-03 
12:29:24 UTC ---
(In reply to comment #0)
> The code has a typo, the mem-initializer should have been l(i)

Oops, typo! I meant is should have been j(i)

[Bug c++/53211] New: range-based 'for' expression of type 'const int []' has incomplete type

[i.nixman at gmail dot com]

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

 Bug #: 53211
   Summary: range-based 'for' expression of type 'const int []'
has incomplete type
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i.nix...@gmail.com


This code compiles successfully:
#include 

template
void func(Args... ) {
   const int arr[] = {1,2,3,4}; // !
   for (auto it: arr) {
  std::cout << it << std::endl;
   }
}

int main() {
   func(1,2,3,4);
}

http://liveworkspace.org/code/d7f2c44576fbf6854d113e29f976faa4

But if I change the initialization way of 'arr' like this, I get the following
error:
#include 

template
void func(Args... args) {
   const int arr[] = {args...}; // !
   for (auto it: arr) {
  std::cout << it << std::endl;
   }
}

int main() {
   func(1,2,3,4);
}

http://liveworkspace.org/code/722f90c75ea3aa56310c24fd2abeea50

> source.cpp: In function 'void func(Args ...)':
> source.cpp:6:18: error: range-based 'for' expression of type 'const int []' 
> has incomplete type

[Bug c/53212] New: cpp consumes comment after pragma

[ludo at gnu dot org]

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

 Bug #: 53212
   Summary: cpp consumes comment after pragma
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@gnu.org


Consider this program:

  int foo ()
  {
  #pragma foo bar /* this is a comment */
  }

"gcc -C -E the-file.c" consumes the comment, whereas it should leave it as is.

[Bug c++/53210] warning for data member initialized with itself should be in -Wall

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-03
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Manuel López-Ibáñez  2012-05-03 
13:09:44 UTC ---
(In reply to comment #0)
> 
> Although the warning is enabled by -Winit-self it is reported as
> -Wuninitialized (which kinda makes sense as it requires both to be active)
> 
> More importantly, I think this code should always warn. 

No, it doesn't make sense. Warnings should be controlled by the same option
used to warn. This is a bug. Please, could you test this patch?

Index: gcc/cp/init.c
===
--- gcc/cp/init.c   (revision 187018)
+++ gcc/cp/init.c   (working copy)
@@ -573,8 +573,7 @@
   if (decl == error_mark_node)
 return;

-  if (warn_init_self && init && TREE_CODE (init) == TREE_LIST
-  && TREE_CHAIN (init) == NULL_TREE)
+  if (init && TREE_CODE (init) == TREE_LIST && TREE_CHAIN (init) == NULL_TREE)
 {
   tree val = TREE_VALUE (init);
   if (TREE_CODE (val) == COMPONENT_REF && TREE_OPERAND (val, 1) == member


Some testcases may need adjusting. Once tested, feel free to submit it for
approval (but I would consider it as obvious and commit it).

[Bug rtl-optimization/53176] [4.8 Regression] gcc.target/i386/movbe-2.c and gcc.dg/lower-subreg-1.c

[zadeck at naturalbridge dot com]

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

--- Comment #13 from Kenneth Zadeck  
2012-05-03 13:14:31 UTC ---
The arm is one of the architectures for which lower-subreg is harmful 
for some of the implementations.

kenny

On 05/03/2012 06:29 AM, Greta.Yorsh at arm dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176
>
> Greta Yorsh  changed:
>
> What|Removed |Added
> 
>   CC||Greta.Yorsh at arm dot com
>
> --- Comment #12 from Greta Yorsh  2012-05-03 
> 10:29:17 UTC ---
> Fails on arm-none-eabi as well:
> FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 "Splitting reg"
>

[Bug c++/53206] overloaded virtual non const warning

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez  2012-05-03 
13:15:11 UTC ---
(In reply to comment #6)
> In the large codebase I'm working on currently we use -Wall -Wextra but don't
> use -Woverloaded-virtual (and we are aware of it, it's in a Makefile but
> commented out) because it generates too much noise.  If it was in -Wall or
> -Wextra we'd probably use -Wno-overloaded-virtual

Sorry, I may be misunderstanding the purpose of the warning. Could you give an
example where the warning is just noise?

(Perhaps we should really have -W3 or -Wparanoid.)

[Bug c++/53211] range-based 'for' expression of type 'const int []' has incomplete type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-03
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2012-05-03 
13:17:27 UTC ---
Confirmed, that's a bug.

It works if the array bound is given explicitly:

   const int arr[sizeof...(Args)] = {args...};


Reduced:

template
  struct is_same { static const bool value = false; };

template
  struct is_same { static const bool value = true; };

template
void func(Args... args) {
  int arr[] = {args...};
  static_assert(is_same::value,
"complete type");
}

int main() {
   func(1,2,3,4);
}


for.cc: In instantiation of 'void func(Args ...) [with Args = {int, int, int,
int}]':
for.cc:15:16:   required from here
for.cc:10:3: error: static assertion failed: complete type
   static_assert(is_same::value,
   ^

[Bug rtl-optimization/53176] [4.8 Regression] gcc.target/i386/movbe-2.c and gcc.dg/lower-subreg-1.c

[Greta.Yorsh at arm dot com]

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

Greta Yorsh  changed:

   What|Removed |Added

 CC||ramana.radhakrishnan at arm
   ||dot com

--- Comment #14 from Greta Yorsh  2012-05-03 
13:28:42 UTC ---
This test fails because splitting doesn't happen any more after r187015 patch.
Without splitting, better code is generated in this case. 

The test
long long test (long long a, long long b) { return a | b; }
previously compiled into
orr r2, r2, r0
orr r3, r3, r1
mov r0, r2
mov r1, r3
now compiles into a better sequence, avoiding the moves:
orr r0, r0, r2
orr r1, r1, r3

I haven't yet come across an example where the patch makes things worse on arm.
Do you have any such examples?

Thanks,
Greta

[Bug c++/53206] overloaded virtual non const warning

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2012-05-03 
13:28:50 UTC ---
This is slightly contrived:

namespace library
{
struct Interface {
virtual void handle(int) = 0;
};

struct Implementation : Interface {
void handle(int i) { __builtin_printf("handled %d\n", i); }
};
}

struct Application : private library::Implementation
{
Application(int i) : id(i) { }

void handle() { Implementation::handle(id); }

int id;
};

int main()
{
Application a(1);
a.handle();
}

I don't care that Application::handle() hides Implementation::handle(int), no
user of Application needs to know about the private base class and can never
call the virtual function directly anyway.

To suppress the warning it's necessary to rename one of the functions (which
might involve changing a third-party library or breaking your clas' API) or to
add "using Implementation::handle" but that using decl *must* be private or it
allows users of Application to invoke the virtual function that is meant to be
inaccessible.

I don't object to putting it in -Wall, I'm just pointing out there are cases
where the warning is unhelpful.  I wonder if suppressing it when the hidden
virtual function is inaccessible would make snse ... I haven't thought about
all the consequences of doing that (and it still wouldn't remove all unhelpful
cases of the warning, I just can't think of all the times I've got the warning
and decided it should be ignored.)

[Bug c++/53213] New: Internal compiler error in math.h

[lbl2007 at gmx dot net]

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

 Bug #: 53213
   Summary: Internal compiler error in math.h
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lbl2...@gmx.net


Using C math functions in C++ triggers an ICE. See below for a simple example.
The problem actually occured when using math.h, the program below is a
stripped-down version of the preprocessed source.

gcc version 4.7.0 (GCC) 
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.7.0/configure --prefix=/h/local
--with-local-prefix=/h/local --with-gmp=/h/local --with-gnu-as --with-gnu-ld
--with-mpfr=/h/local --with-mpc=/h/local --with-local-prefix=/h/local
--enable-threads=posix --enable-languages=c,c++ --disable-nls


Compiler output:

$ gcc -c bug.c
bug_p.c: In function 'void f()':
bug_p.c:11:11: internal compiler error: Bus Error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

-bug.c---
extern "C" {
  extern double log (double);
  extern float __logf(float);
  extern "C++" {
float log(float __X) { return __logf(__X); }
  }
}

void f()
{
   log(2.0);
}

[Bug tree-optimization/53168] ICE in find_or_generate_expression, at tree-ssa-pre.c:3053

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2012-05-03 
14:17:32 UTC ---
I think it is because of how we do VN lookup / insert during phi_translation.
SCCVN does not guarantee availability of its lookup result, thus when
such availability is not guaranteed when we translate things we should rather
use the non-canonical expression (after all we translate expressions (sic!),
not values).

What happens is that we have (simplified)

  if (b)
{
  x_1 = a;
}
  else
{
  if (c)
for(;;)
  {
x_2 = a;
a = 0;
  }
}

and SCCVN value-numbers x_2 to x_1.  PRE sees that 'a' is ANTIC_IN in the
for (;;) block - but it's not ANTIC_OUT in the if (c) block because it
gets cleaned out there as it is translated as x_1 which is not insertable.

I think the PRE algorithm does not expect that phi_translate (ANTIC_IN (succ))
will ever return something that is _not_ valid at the ANTIC_OUT position.
But our phi-translate implementation happily causes this situation.

My suggested change to check validity of the phi_translate result at
insert time is a workaround, but it only makes this a missed optimization.

This particular case is fixed by not turning the memory reference into
a conversion on translation.

[Bug lto/53214] New: [lto]: ICE: munmap_chunk(): invalid pointer

[vincenzo.innocente at cern dot ch]

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

 Bug #: 53214
   Summary: [lto]: ICE: munmap_chunk(): invalid pointer
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
Target: x86_64-unknown-linux-gnu


when __attribute__ added to function

example reduced from real life code

cat ltoCrash.cc
#include
struct A {  
double  a(double r, int ) const  __attribute__ ((optimize(3, "fast-math")));
double b;
};

double A::a(double r, int c) const { 
   if (c<0) r = -r; 
   return b/std::sqrt(r);
}
[vocms123] /build/vin/CMSSW_6_0_X_2012-05-03-0200 $ c++ -O2 -flto -fPIC -shared
-o bha.so ltoCrash.cc
*** glibc detected ***
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto1:
munmap_chunk(): invalid pointer: 0x2b0a9558b308 ***
=== Backtrace: =
/lib64/libc.so.6(cfree+0x166)[0x3a4f6712f6]
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto1[0x4c263c]
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto1(_Z8lto_mainv+0xeeb)[0x4c544b]
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto1(_Z11toplev_mainiPPc+0xa10)[0x7f9d40]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x3a4f61d994]
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto1[0x4a5f19]
=== Memory map: 
0040-01116000 r-xp  00:15 305728764 
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto1
01116000-01121000 rw-p 00d16000 00:15 305728764 
/afs/cern.ch/user/i/innocent/w3/gcc47slc5/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto1
01121000-0127f000 rw-p 01121000 00:00 0 
0657-06631000 rw-p 0657 00:00 0  [heap]
3a4f20-3a4f21c000 r-xp  08:02 1501774   
/lib64/ld-2.5.so
3a4f41c000-3a4f41d000 r--p 0001c000 08:02 1501774   
/lib64/ld-2.5.so
3a4f41d000-3a4f41e000 rw-p 0001d000 08:02 1501774   
/lib64/ld-2.5.so
3a4f60-3a4f74d000 r-xp  08:02 1501777   
/lib64/libc-2.5.so
3a4f74d000-3a4f94d000 ---p 0014d000 08:02 1501777   
/lib64/libc-2.5.so
3a4f94d000-3a4f951000 r--p 0014d000 08:02 1501777   
/lib64/libc-2.5.so
3a4f951000-3a4f952000 rw-p 00151000 08:02 1501777   
/lib64/libc-2.5.so
3a4f952000-3a4f957000 rw-p 3a4f952000 00:00 0 
3a4fa0-3a4fa02000 r-xp  08:02 1501779   
/lib64/libdl-2.5.so
3a4fa02000-3a4fc02000 ---p 2000 08:02 1501779   
/lib64/libdl-2.5.so
3a4fc02000-3a4fc03000 r--p 2000 08:02 1501779   
/lib64/libdl-2.5.so
3a4fc03000-3a4fc04000 rw-p 3000 08:02 1501779   
/lib64/libdl-2.5.so
3a5020-3a50282000 r-xp  08:02 1501780   
/lib64/libm-2.5.so
3a50282000-3a50481000 ---p 00082000 08:02 1501780   
/lib64/libm-2.5.so
3a50481000-3a50482000 r--p 00081000 08:02 1501780   
/lib64/libm-2.5.so
3a50482000-3a50483000 rw-p 00082000 08:02 1501780   
/lib64/libm-2.5.so
2b0a9414d000-2b0a9414f000 rw-p 2b0a9414d000 00:00 0 
2b0a9414f000-2b0a945b2000 r-xp  00:15 1062144158
/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0/lib/libppl_c.so.4.0.0
2b0a945b2000-2b0a947b1000 ---p 00463000 00:15 1062144158
/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0/lib/libppl_c.so.4.0.0
2b0a947b1000-2b0a947b7000 rw-p 00462000 00:15 1062144158
/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0/lib/libppl_c.so.4.0.0
2b0a947b7000-2b0a948db000 r-xp  00:15 1062144152
/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0/lib/libppl.so.10.0.0
2b0a948db000-2b0a94adb000 ---p 00124000 00:15 1062144152
/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0/lib/libppl.so.10.0.0
2b0a94adb000-2b0a94ade000 rw-p 00124000 00:15 1062144152
/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0/lib/libppl.so.10.0.0
2b0a94ade000-2b0a94ae3000 rw-p 2b0a94ade000 00:00 0 
2b0a94ae3000-2b0a94ae7000 r-xp  00:15 1062144128
/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0/lib/libgmpxx.so.4.2.2
2b0a94ae7000-2b0a94ce6000 ---p 4000 00:15 1062144128
/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0/lib/libgmpxx.so.4.2.2
2b0a94ce6000-2b0a94ce7000 rw-p 3000 00:15 1062144128
/afs/cern.ch/cms/slc5_amd64_gcc470/external/gcc/4.7.0/lib/libgmpxx.so.4.2.2
2b0a94ce7000-2b0a94d37000 r-xp  00:15 1062

[Bug c++/53213] Internal compiler error in math.h

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  2012-05-03 
14:16:52 UTC ---
Let's add Rainer in CC.

[Bug c++/53186] [C++11] missing devirtualization for operators "final"

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  
2012-05-03 14:28:52 UTC ---
Author: paolo
Date: Thu May  3 14:28:46 2012
New Revision: 187097

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187097
Log:
/cp
2012-05-03  Paolo Carlini  

PR c++/53186
* call.c (build_over_call): Handle final member functions
and class types.
(build_new_method_call_1): Do not handle here.

/testsuite
2012-05-03  Paolo Carlini  

PR c++/53186
* g++.dg/other/final2.C: New.

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

[Bug c++/53186] [C++11] missing devirtualization for operators "final"

[paolo at gcc dot gnu.org]

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

--- Comment #6 from paolo at gcc dot gnu.org  
2012-05-03 14:32:20 UTC ---
Author: paolo
Date: Thu May  3 14:32:15 2012
New Revision: 187098

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187098
Log:
/cp
2012-05-03  Paolo Carlini  

PR c++/53186
* call.c (build_over_call): Handle final member functions
and class types.
(build_new_method_call_1): Do not handle here.

/testsuite
2012-05-03  Paolo Carlini  

PR c++/53186
* g++.dg/other/final2.C: New.

Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/other/final2.C
Modified:
branches/gcc-4_7-branch/gcc/cp/ChangeLog
branches/gcc-4_7-branch/gcc/cp/call.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug c++/53186] [C++11] missing devirtualization for operators "final"

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.8.0   |4.7.1

--- Comment #7 from Paolo Carlini  2012-05-03 
14:33:09 UTC ---
Done for mainline and 4.7.1.

[Bug lto/53214] [lto]: ICE: munmap_chunk(): invalid pointer

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||lto
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-03
 Ever Confirmed|0   |1
  Known to fail||4.7.1, 4.8.0

--- Comment #1 from Richard Guenther  2012-05-03 
14:44:30 UTC ---
Confirmed, also with 4.7.  4.6 does not support the optimized attribute.

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-05-03
  Component|tree-optimization   |lto
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #16 from Richard Guenther  2012-05-03 
14:51:29 UTC ---
At least the last testcase is because the link line misses -freg-struct-return
which changes the ABI.

This (and similar switches) would need to be added to the LTO option merging
code in lto-wrapper.c.  It would be the first case where we need to complain.

So I think this bug is invalid - but we can do better and diagnose that.

I'll put it on my TODO (if you don't beat me to it).

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi-gcc at firstfloor dot org]

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

--- Comment #17 from Andi Kleen  2012-05-03 
14:57:13 UTC ---
Hmm, my assumption was always that this option would be passed through and then
used by lto1 step. That's true  for other -f* options at least.

[Bug rtl-optimization/51771] trans-mem: abnormal edges get lost or corrupted

[luked at cs dot rochester.edu]

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

--- Comment #4 from Luke Dalessandro  2012-05-03 
15:06:57 UTC ---
Created attachment 27303
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27303
RBTree microbenchmark test case

I believe that I'm seeing this in the RSTM suite's RBTree microbenchmark as
well. It appears to be manifesting with the same symptoms as pr47530,
_ITM_commitTransaction is generated as a tail call. An abort in
_ITM_commitTransaction during multithreaded execution corrupts the stack slot
that is used to hold a "time" value.

I attached the TreeBench.ii test case so that a second, complex example of the
problem exists.

Static manifestation of bug is "jmp _ITM_commitTransaction" in asm output.

$ g++ -O3 -fgnu-tm -o /dev/stdout -S TreeBench.ii | grep _ITM_commitTransaction 
call_ITM_commitTransaction
jmp_ITM_commitTransaction
jmp_ITM_commitTransaction

Runtime manifestation is corrupted "time" output (and thus "throughput" output
as well) under multithreaded execution ("p" command line parameter) of the
optimized executable.

$ g++ -fgnu-tm -o TreeBench TreeBench.ii -lrt
$ ./TreeBench -p2
Verification: Passed
csv, ALG=gcc-tm, B=RBTree, R=34, d=1, p=2, X=0, m=256, S=1, O=1, txns=1251624,
time=101773, throughput=1251621

$ g++ -O3 -fgnu-tm -o TreeBench TreeBench.ii -lrt
$ ./TreeBench -p2
Verification: Passed
csv, ALG=gcc-tm, B=RBTree, R=34, d=1, p=2, X=0, m=256, S=1, O=1,
txns=391668795, time=1336057254755574655, throughput=0

Output from g++ -v -save-temps.

$ g++ -fgnu-tm -O3 -m64 -DSTM_INST_STM -DSTM_API_GCCTM -DSTM_CC_GCC
-DSTM_OS_LINUX -DSTM_CPU_X86 -DSTM_BITS_64 -DSTM_OPT_O3 -DSTM_WS_BYTELOG
-DSINGLE_SOURCE_BUILD -I../include -I../lib -v -save-temps TreeBench.cpp -lrt
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/localdisk/luked/pub/gcc/4.8/bin/../libexec/gcc/x86_64-redhat-linux/4.8.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../gcc-4.8/configure --prefix=/u/luked/pub/gcc/4.8
--enable-bootstrap --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa-atexit --disable-libunwind-exceptions
--enable-linker-build-id --enable-plugins --enable-lto --disable-nls
--enable-ld --enable-gold --with-gmp=/u/luked/pub/gmp-5.0.4-static
--with-mpfr=/u/luked/pub/mpfr-3.1.0-static
--with-mpc=/u/luked/pub/mpc-0.9-static
--with-ppl=/u/luked/pub/ppl-0.11.2-static
--with-cloog=/u/luked/pub/cloog-0.16.3-static --enable-cloog-backend=isl
--with-tune=generic --with-arch-32=i686 --with-gnu-ld --with-gnu-as
--with-plugin-ld=ld.gold --build=x86_64-redhat-linux
--with-host-libstdcxx='/usr/local/lib64/libstdc++.a -lm'
--enable-languages=c,c++,lto : (reconfigured) 
Thread model: posix
gcc version 4.8.0 20120502 (experimental) [trunk revision 187050] (GCC) 
COLLECT_GCC_OPTIONS='-fgnu-tm' '-O3' '-m64' '-D' 'STM_INST_STM' '-D'
'STM_API_GCCTM' '-D' 'STM_CC_GCC' '-D' 'STM_OS_LINUX' '-D' 'STM_CPU_X86' '-D'
'STM_BITS_64' '-D' 'STM_OPT_O3' '-D' 'STM_WS_BYTELOG' '-D'
'SINGLE_SOURCE_BUILD' '-I' '../include' '-I' '../lib' '-v' '-save-temps'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-pthread'

/localdisk/luked/pub/gcc/4.8/bin/../libexec/gcc/x86_64-redhat-linux/4.8.0/cc1plus
-E -quiet -v -I ../include -I ../lib -iprefix
/localdisk/luked/pub/gcc/4.8/bin/../lib/gcc/x86_64-redhat-linux/4.8.0/
-D_GNU_SOURCE -D_REENTRANT -D STM_INST_STM -D STM_API_GCCTM -D STM_CC_GCC -D
STM_OS_LINUX -D STM_CPU_X86 -D STM_BITS_64 -D STM_OPT_O3 -D STM_WS_BYTELOG -D
SINGLE_SOURCE_BUILD TreeBench.cpp -m64 -mtune=generic -march=x86-64 -fgnu-tm
-O3 -fpch-preprocess -o TreeBench.ii
ignoring nonexistent directory
"/localdisk/luked/pub/gcc/4.8/bin/../lib/gcc/x86_64-redhat-linux/4.8.0/../../../../x86_64-redhat-linux/include"
ignoring duplicate directory
"/localdisk/luked/pub/gcc/4.8/bin/../lib/gcc/../../lib/gcc/x86_64-redhat-linux/4.8.0/../../../../include/c++/4.8.0"
ignoring duplicate directory
"/localdisk/luked/pub/gcc/4.8/bin/../lib/gcc/../../lib/gcc/x86_64-redhat-linux/4.8.0/../../../../include/c++/4.8.0/x86_64-redhat-linux"
ignoring duplicate directory
"/localdisk/luked/pub/gcc/4.8/bin/../lib/gcc/../../lib/gcc/x86_64-redhat-linux/4.8.0/../../../../include/c++/4.8.0/backward"
ignoring duplicate directory
"/localdisk/luked/pub/gcc/4.8/bin/../lib/gcc/../../lib/gcc/x86_64-redhat-linux/4.8.0/include"
ignoring duplicate directory
"/localdisk/luked/pub/gcc/4.8/bin/../lib/gcc/../../lib/gcc/x86_64-redhat-linux/4.8.0/include-fixed"
ignoring nonexistent directory
"/localdisk/luked/pub/gcc/4.8/bin/../lib/gcc/../../lib/gcc/x86_64-redhat-linux/4.8.0/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 ../include
 ../lib

/localdisk/luked/pub/gcc/4.8/bin/../lib/gcc/x86_64-redhat-linux/4.8.0/../../../../include/c++/4.8.0

/localdisk/luked/pub/gcc/4.8/bin/../lib/gcc/x86_64-redhat-linux/4.8.0/../../../../include/c++/4.8.0/x86_64-redhat-linux

/localdisk/luked/pub/gcc/4.8/bin/../lib/gcc/x86_64-redhat-linux/4.8.0/../

[Bug middle-end/53106] [4.8 Regression] Benchmarks in SPEC CPU 2006 failed to build

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from William J. Schmidt  2012-05-03 
15:16:39 UTC ---
FWIW, I verified that Honza's proposed patch fixes the build problems for
483.xlancbmk and 32-bit 447.dealII on powerpc-linux.  Any ETA for getting this
committed?

Thanks,
Bill

[Bug c++/53213] Internal compiler error in math.h

[lbl2007 at gmx dot net]

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

--- Comment #2 from lbl2007 at gmx dot net 2012-05-03 15:51:06 UTC ---
The command to reproduce the error is "g++ bug.c", not "gcc bug.c"

[Bug target/53209] tree check ICE: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com
   Target Milestone|--- |4.8.0

--- Comment #1 from H.J. Lu  2012-05-03 15:56:07 
UTC ---
I think this is the same as PR 53177.

[Bug tree-optimization/53128] [4.8 Regression] Compiler produces infinite loop on regular O2

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  2012-05-03 
16:02:56 UTC ---
(In reply to comment #4)
> Isn't it too aggressive from user perspective to perform such transformation
> even without warning? Especially for the case when that "wrong" read is not
> used later.
> Sure it is dangerous anyway to make such access but at he same time it seems
> this could affect lot of existing code...

Igor, I guess the compiler only sees something like:

x = 14
if (x < 13) do_A(); else do_B();

and transform it into:

do_A();

It doesn't see that an infinite loop is generated. Now, whether there could be
an optimization pass that detects infinite loops, and warns for them, that I am
not sure, but surely it would be a nice thing to have. If someone contributed a
nice implementation, I think it will be accepted. Unfortunately, I don't think
it is in the TODO list of any current contributor.

[Bug c++/53211] range-based 'for' expression of type 'const int []' has incomplete type

[i.nixman at gmail dot com]

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

--- Comment #2 from niXman  2012-05-03 16:04:26 UTC 
---
This code also works:

#include 

template
void func(Args... args) {
   const int arr[] = {args...};
   for (int it: arr) { // !
  std::cout << it << std::endl;
   }
}

int main() {
   func(1,2,3,4);
}


I'm confused...

[Bug rtl-optimization/53176] [4.8 Regression] gcc.target/i386/movbe-2.c and gcc.dg/lower-subreg-1.c

[ubizjak at gmail dot com]

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

--- Comment #15 from Uros Bizjak  2012-05-03 16:19:04 
UTC ---
32bit x86 regressed (-O2 -mmovbe) with following testcase:

void
foo (long long i)
{
  x = __builtin_bswap64 (i);
}

from:

foo:
movbe   4(%esp), %eax
movbe   8(%esp), %edx
movl%eax, x+4
movl%edx, x
ret

to:

foo:
pushl   %ebx
movl8(%esp), %eax
movl12(%esp), %edx
movl%eax, %ebx
movl%edx, %ecx
bswap   %ebx
bswap   %ecx
movl%ebx, x+4
movl%ecx, x
popl%ebx

[Bug bootstrap/53200] [4.8 Regression] bootstrap broken on x86_64-apple-darwin10 at revision 187018

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson  2012-05-03 
16:36:17 UTC ---
Hmm.  I see nothing amiss in that generated config file.
But see if by chance it isn't the same problem as fixed by r187102.

Bad g++ warning (type-limits) for compile-time constants

[Benjamin Schug]

Hey there,

I tried to write a template that finds the smallest signed integer type  
that can represent a given number. To achieve that, I am computing boolean  
constant expressions and use them to pick the right template  
specializations. This produces multiple "comparison is always true/false  
due to limited range of data type" warnings. In this context, the warning  
does not make any sense, because the comparison it refers to is required  
to be evaluated at compile time.


You can reproduce the problem with the following code:

#include 
using std::cout;
using std::endl;

#include 
using std::numeric_limits;

/**
 * Helper for IntTypeThatFits.
 * Template parameters indicate whether the given number fits into 8, 16  
or 32

 * bits. If neither of them is true, it is assumed that it fits 64 bits.
 */
template 
struct IntTypeThatFitsHelper { };

// specializations for picking the right type
// these are all valid combinations of the flags
template<> struct IntTypeThatFitsHelper { typedef int8_t  
Result; };
template<> struct IntTypeThatFitsHelper { typedef  
int16_t Result; };
template<> struct IntTypeThatFitsHelper { typedef  
int32_t Result; };
template<> struct IntTypeThatFitsHelper { typedef  
int64_t Result; };


/// Finds the smallest integer type that can represent the given number.
template 
struct IntTypeThatFits
{
typedef typename IntTypeThatFitsHelper<
(n <= numeric_limits::max()) && (n >=  
numeric_limits::min()),
(n <= numeric_limits::max()) && (n >=  
numeric_limits::min()),
(n <= numeric_limits::max()) && (n >=  
numeric_limits::min())

>::Result Result;
};


int main (int, char**)
{
cout << "42 needs " << sizeof (IntTypeThatFits<42>::Result) << "  
bytes." << endl;
cout << "1234 needs " << sizeof (IntTypeThatFits<1234>::Result) << "  
bytes." << endl;
cout << "123456 needs " << sizeof (IntTypeThatFits<123456>::Result) <<  
" bytes." << endl;
cout << "12345678900 needs " << sizeof  
(IntTypeThatFits<12345678900>::Result) << " bytes." << endl;

}


Compile it with
g++ --std=c++0x -Wtype-limits -std=c++0x

For a more detailed discussion, see  
http://stackoverflow.com/questions/10434640/gcc-comparison-is-always-true-due-to-limited-range-of-data-type-in-template



Thanks for your time,

Benjamin Schug

[Bug lto/52605] LTO -g ICE when looking up context of VMTs of classes defined within functions

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  2012-05-03 
17:00:48 UTC ---
Author: jamborm
Date: Thu May  3 17:00:32 2012
New Revision: 187109

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187109
Log:
2012-05-03  Martin Jambor  

PR lto/52605
* dwarf2out.c (dwarf2out_decl): Only lookup die representing context
of a variable when the contect is a function.

* gcc/testsuite/g++.dg/lto/pr52605_0.C: New test.


Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/lto/pr52605_0.C
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/dwarf2out.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug lto/52605] LTO -g ICE when looking up context of VMTs of classes defined within functions

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from Martin Jambor  2012-05-03 
17:01:45 UTC ---
This should now be fixed.

[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for multi-word memory splits

[rsandifo at gcc dot gnu.org]

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
2012-05-03 17:04:49 UTC ---
Author: rsandifo
Date: Thu May  3 17:04:41 2012
New Revision: 187110

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187110
Log:
Add PR rtl-optimization/52543 to changelog.

Modified:
trunk/gcc/ChangeLog

[Bug c++/53215] New: Warn if orphaned memory is created by ignoring return value of new

[ssprog1 at gmail dot com]

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

 Bug #: 53215
   Summary: Warn if orphaned memory is created by ignoring return
value of new
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sspr...@gmail.com


The following code creates orphaned memory by ignoring the return value of new:

#include
using namespace std;

int main ( void ) {
   for (int i=0; i< 1000; i++)
   new int[1000];
   int a;
   cin >> a;

   return 0;
}

Request: g++ should report a compile-time warning message for such a memory
leak. Currently, no warning is output:

user@quant:/tmp$ g++ -Wall -Wextra MemoryLeakCheckCompilerWarning.cpp
-o MemoryLeakCheckCompilerWarning.exe
user@quant:/tmp$

[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for multi-word memory splits

[rsandifo at gcc dot gnu.org]

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
2012-05-03 17:50:20 UTC ---
lower-subreg patched committed here:

http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00011.html

[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2012-04-25 00:00:00 |2012-05-03
 Ever Confirmed|0   |1

--- Comment #9 from Manuel López-Ibáñez  2012-05-03 
17:54:37 UTC ---
Maybe related PR25137 

Confirmed by Joseph. Any help welcome!

[Bug c/53216] New: fmaf() alters rounding mode of sse2 FPU

[tydeman at tybor dot com]

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

 Bug #: 53216
   Summary: fmaf() alters rounding mode of sse2 FPU
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tyde...@tybor.com


The following code shows that the rounding mode of the sse2 FPU is altered by a
call to fmaf().

#include 
#include 
#include 

static  float res0, res1, res2, res3;
static  float half = 0.5f;

void chk( void ){
  res2 = res0 + half;/* should round down to even */
  if( res2 == res0 ){ puts("OK1"); }else{ puts("Bad1"); }
  res3 = res1 + half;/* should round up to even */
  if( res3 != res1 ){ puts("OK2"); }else{ puts("Bad2"); }
}

int main(void){

  res0 = FLT_EPSILON;
  res0++;
  res0--;
  res0 = 1.f / res0;/* even; 1/EPSILON is a magic number */
  res1 = res0 + 1.f;/* odd */

  chk();

  res2 = sinf( 1.f );/* sse2 rounding is not altered */

  chk();

  res2 = fmaf( 1.f, 1.f, 1.f );/* this messes up sse2 rounding */

  chk();

  return 0;
}


Hardware:  Intel Core 2 Duo in 32-bit mode
O.S.:  Fedora Core 17 in 32-bit mode
Compiler:  gcc 4.7.0-2
Library :  glibc 2.15-32

Compiler options: -std=gnu11 -O0 -mfpmath=sse -msse2 -fno-builtin
-frounding-math -mieee-fp -ffloat-store -fexcess-precision=standard

[Bug middle-end/53217] New: [4.8 Regression] internal compiler error: verify_ssa failed

[Joost.VandeVondele at mat dot ethz.ch]

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

 Bug #: 53217
   Summary: [4.8 Regression] internal compiler error: verify_ssa
failed
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joost.vandevond...@mat.ethz.ch

[Bug middle-end/53217] [4.8 Regression] internal compiler error: verify_ssa failed

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #1 from Joost VandeVondele  
2012-05-03 18:38:27 UTC ---
The following testcase causes an ICE with current trunk (4.8)

MODULE xc_cs1
  INTEGER, PARAMETER :: dp=KIND(0.0D0)
  REAL(KIND=dp), PARAMETER :: a = 0.04918_dp, &
  c = 0.2533_dp, &
  d = 0.349_dp
CONTAINS
  SUBROUTINE cs1_u_2 ( rho, grho, r13, e_rho_rho, e_rho_ndrho, e_ndrho_ndrho,&
   npoints, error)
REAL(KIND=dp), DIMENSION(*), &
  INTENT(INOUT)  :: e_rho_rho, e_rho_ndrho, &
e_ndrho_ndrho
DO ip = 1, npoints
  IF ( rho(ip) > eps_rho ) THEN
 oc = 1.0_dp/(r*r*r3*r3 + c*g*g)
 d2rF4 = c4p*f13*f23*g**4*r3/r * (193*d*r**5*r3*r3+90*d*d*r**5*r3 &
 -88*g*g*c*r**3*r3-100*d*d*c*g*g*r*r*r3*r3 &
 +104*r**6)*od**3*oc**4
 e_rho_rho(ip) = e_rho_rho(ip) + d2F1 + d2rF2 + d2F3 + d2rF4
  END IF
END DO
  END SUBROUTINE cs1_u_2
END MODULE xc_cs1


gfortran -O1  -ffast-math  bug.f90 
bug.f90: In function ‘cs1_u_2’:
bug.f90:7:0: error: definition in block 4 follows the use
   SUBROUTINE cs1_u_2 ( rho, grho, r13, e_rho_rho, e_rho_ndrho, e_ndrho_ndrho,&
 ^
for SSA_NAME: reassocpow.5_24 in statement:
reassocpow.5_99 = __builtin_powi (reassocpow.5_24, 2);
bug.f90:7:0: internal compiler error: verify_ssa failed
   SUBROUTINE cs1_u_2 ( rho, grho, r13, e_rho_rho, e_rho_ndrho, e_ndrho_ndrho,&

[Bug middle-end/53106] [4.8 Regression] Benchmarks in SPEC CPU 2006 failed to build

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  2012-05-03 
19:18:56 UTC ---
Author: hubicka
Date: Thu May  3 19:18:51 2012
New Revision: 187114

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

PR middle-end/53106
* ipa.c (cgraph_remove_unreachable_nodes): Fix handling of clones.

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

[Bug target/53101] Recognize casts to sub-vectors

[marc.glisse at normalesup dot org]

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

--- Comment #4 from Marc Glisse  2012-05-03 
19:19:00 UTC ---
(define_peephole2
  [(set (mem:VI8F_256 (match_operand 2))
(match_operand:VI8F_256 1 "register_operand"))
   (set (match_operand: 0 "register_operand")
(mem: (match_dup 2)))]
  "TARGET_AVX"
  [(set (match_dup 0)
(vec_select: (match_dup 1)
 (parallel [(const_int 0) (const_int
1)])))]
)

(and similar for VI4F_256) is much less hackish than the XEXP stuff. I was
quite sure I'd tested exactly this and it didn't work, but now it looks like it
does :-/

Except that following http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00197.html ,
this is not the right place to try and add such logic. That's a good thing
because it is way too fragile, another instruction can easily squeeze between
the two sets and disable the peephole.

[Bug middle-end/53093] [4.8 Regression]: tls/alias-1.c ICE, emutls

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  2012-05-03 
19:22:07 UTC ---
Author: hubicka
Date: Thu May  3 19:22:03 2012
New Revision: 187115

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

PR middle-end/53093
* tree-emutls.c (new_emutls_decl): Fix handling of aliases.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-emutls.c

[Bug libstdc++/53218] New: cmake segfaults on sparcv9

[tcallawa at redhat dot com]

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

 Bug #: 53218
   Summary: cmake segfaults on sparcv9
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tcall...@redhat.com


Attempting to run cmake causes segfaults in libstdc++ on Linux sparcv9 (32bit).
Here is the gdb backtrace from a core dump:

(gdb) bt
#0  0xf77e0d98 in __frame_dummy_init_array_entry () from /lib/libstdc++.so.6
#1  0xf7746f08 in __cxxabiv1::__cxa_get_globals () at
../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
#2  0xf7746d4c in std::uncaught_exception () at
../../../../libstdc++-v3/libsupc++/eh_catch.cc:136
#3  0xf7782c44 in ~sentry (this=0xffa86418, __in_chrg=) at
/usr/src/debug/gcc-4.7.0-20120502/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/ostream:429
#4  std::__ostream_insert > (__out=...,
__s=, __n=)
at
/usr/src/debug/gcc-4.7.0-20120502/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/bits/ostream_insert.h:112
#5  0x0001eb84 in operator<<  > (__s=0x15f598 "loading
initial cache file ", __out=...) at
/usr/lib/gcc/sparc64-redhat-linux/4.7.0/../../../../include/c++/4.7.0/ostream:533
#6  cmake::SetCacheArgs (this=this@entry=0xffa86650, args=std::vector of length
6, capacity 8 = {...}) at
/home/spot/rpmbuild/BUILD/cmake-2.8.8-rc2/Source/cmake.cxx:474
#7  0x00025234 in cmake::Run (this=0xffa86650, args=std::vector of length 6,
capacity 8 = {...}, noconfigure=) at
/home/spot/rpmbuild/BUILD/cmake-2.8.8-rc2/Source/cmake.cxx:2411
#8  0x0002bbf4 in do_cmake (ac=6, av=0xffa86854) at
/home/spot/rpmbuild/BUILD/cmake-2.8.8-rc2/Source/cmakemain.cxx:529
#9  0xf742c430 in __libc_start_main () from /lib/libc.so.6
#10 0x00016e14 in _start ()

[Bug target/53219] New: inline function erroneously clobbers %i0 register on 64 bit sparc comiple of perls regcomp.c

[martin at netbsd dot org]

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

 Bug #: 53219
   Summary: inline function erroneously clobbers %i0 register on
64 bit sparc comiple of perls regcomp.c
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@netbsd.org


gcc 4.5.3 on NetBSD/sparc64 miscompiles perl's regcomp.c file.
Inside the big Perl_re_compile() function with %i0 being "my_perl", the context
for the whole function, it inlines this tiny function:

72  PERL_STATIC_INLINE regex_charset
73  get_regex_charset(const U32 flags)
74  {
75  /* Returns the enum corresponding to the character set in 'flags'
*/
76  
77  return (regex_charset) ((flags & RXf_PMf_CHARSET) >>
_RXf_PMf_CHARSET_SHIFT);
78  }

This is the generated assembler code:

   0x4058f560 :
brnz  %g1, 0x4058f570 
   0x4058f564 :add  %l3, %g1, %l5
   0x4058f568 :clr  [ %fp + 0x66b ]
   0x4058f56c :clr  [ %fp + 0x88f ], %i0
   0x4058f574 :and  %i0, 0xe0, %g1
   0x4058f578 :srl  %g1, 5, %g1
   0x4058f57c :cmp  %g1, 1
   0x4058f580 :
be,pn   %icc, 0x40590ecc 

Note at the ==> marker, %i0 is reloaded without save before nor any restore
later. This causes a crash shortly later.

Simple test:

   perl -e '/(?{"{"})/'

[Bug libstdc++/53218] cmake segfaults on sparcv9

[tcallawa at redhat dot com]

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

--- Comment #1 from Tom Callaway  2012-05-03 
19:47:15 UTC ---
Also seeing a very similar segfault with source-highlight (same environment,
Linux/sparcv9/32bit userspace):

(gdb) bt
#0  0xf7ae0d98 in __frame_dummy_init_array_entry () from /lib/libstdc++.so.6
#1  0xf7a46f08 in __cxxabiv1::__cxa_get_globals () at
../../../../libstdc++-v3/libsupc++/eh_globals.cc:63
#2  0xf7a46d4c in std::uncaught_exception () at
../../../../libstdc++-v3/libsupc++/eh_catch.cc:136
#3  0xf7a82c44 in ~sentry (this=0xff9781e0, __in_chrg=) at
/usr/src/debug/gcc-4.7.0-20120502/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/ostream:429
#4  std::__ostream_insert > (__out=...,
__s=, __n=)
at
/usr/src/debug/gcc-4.7.0-20120502/obj-sparc64-redhat-linux/sparc64-redhat-linux/libstdc++-v3/include/bits/ostream_insert.h:112
#5  0x00013a6c in main (argc=, argv=) at
source-highlight.cc:435

[Bug c/53216] fmaf() alters rounding mode of sse2 FPU

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #1 from Marc Glisse  2012-05-03 
19:47:45 UTC ---
This looks like a glibc issue, doesn't it? Or do you see something wrong with
the code gcc produces for this example?

[Bug c++/53220] New: g++ mis-compiles compound literals

[ppluzhnikov at google dot com]

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

 Bug #: 53220
   Summary: g++ mis-compiles compound literals
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com


This appears to be a gcc-4.7 regression. Confirmed in:
g++ (GCC) 4.8.0 20120331 (experimental)
g++ (GCC) 4.8.0 20120503 (experimental)


#include 

int main()
{
  for (int *p = (int[]){ 1, 2, 3, 0}; *p; ++p) {
printf("%d\n", *p);
  }
  return 0;
}

gcc -std=c99 t2.c && ./a.out
1
2
3

gcc -std=c99 -O2 t2.c && ./a.out
1
2
3

g++ t2.c && ./a.out
1
2
3

g++ -O2 -g t2.c && ./a.out
944127552
32767

AFAICT, g++ completely removes the initializer and reads random garbage off
stack:

(gdb) disas main
Dump of assembler code for function main():
   0x00400600 <+0>: push   %rbx
   0x00400601 <+1>: sub$0x10,%rsp
   0x00400605 <+5>: mov(%rsp),%esi
   0x00400608 <+8>: mov%rsp,%rbx
   0x0040060b <+11>:test   %esi,%esi
   0x0040060d <+13>:je 0x400626 
   0x0040060f <+15>:nop
   0x00400610 <+16>:xor%eax,%eax
   0x00400612 <+18>:add$0x4,%rbx
   0x00400616 <+22>:mov$0x40071c,%edi
   0x0040061b <+27>:callq  0x400478 
   0x00400620 <+32>:mov(%rbx),%esi
   0x00400622 <+34>:test   %esi,%esi
   0x00400624 <+36>:jne0x400610 
   0x00400626 <+38>:add$0x10,%rsp
   0x0040062a <+42>:xor%eax,%eax
   0x0040062c <+44>:pop%rbx
   0x0040062d <+45>:retq   
End of assembler dump.

valgrind ./a.out
...
==13572== Conditional jump or move depends on uninitialised value(s)
==13572==at 0x40060D: main (/tmp/t2.c:5)
==13572== 
==13572== Use of uninitialised value of size 8
==13572==at 0x5625E4B: _itoa_word
(/build/buildd/eglibc-2.11.1/stdio-common/_itoa.c:195)
==13572==by 0x5628A87: vfprintf
(/build/buildd/eglibc-2.11.1/stdio-common/vfprintf.c:1616)
==13572==by 0x5631659: printf
(/build/buildd/eglibc-2.11.1/stdio-common/printf.c:35)
==13572==by 0x40061F: main (/tmp/t2.c:6)
==13572== 
==13572== Conditional jump or move depends on uninitialised value(s)
==13572==at 0x5625E55: _itoa_word
(/build/buildd/eglibc-2.11.1/stdio-common/_itoa.c:195)
==13572==by 0x5628A87: vfprintf
(/build/buildd/eglibc-2.11.1/stdio-common/vfprintf.c:1616)
==13572==by 0x5631659: printf
(/build/buildd/eglibc-2.11.1/stdio-common/printf.c:35)
==13572==by 0x40061F: main (/tmp/t2.c:6)
==13572== 
==13572== Conditional jump or move depends on uninitialised value(s)
==13572==at 0x5627ED2: vfprintf
(/build/buildd/eglibc-2.11.1/stdio-common/vfprintf.c:1616)
==13572==by 0x5631659: printf
(/build/buildd/eglibc-2.11.1/stdio-common/printf.c:35)
==13572==by 0x40061F: main (/tmp/t2.c:6)
==13572== 
==13572== Conditional jump or move depends on uninitialised value(s)
==13572==at 0x5627EF0: vfprintf
(/build/buildd/eglibc-2.11.1/stdio-common/vfprintf.c:1616)
==13572==by 0x5631659: printf
(/build/buildd/eglibc-2.11.1/stdio-common/printf.c:35)
==13572==by 0x40061F: main (/tmp/t2.c:6)
==13572== 
-16780368
==13572== Conditional jump or move depends on uninitialised value(s)
==13572==at 0x400624: main (/tmp/t2.c:5)
==13572== 
127
...

Google ref: b/6439133

[Bug c++/53220] g++ mis-compiles compound literals

[ppluzhnikov at google dot com]

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

--- Comment #1 from Paul Pluzhnikov  2012-05-03 
19:53:07 UTC ---
gcc-compiled code for reference:

(gdb) disas main
Dump of assembler code for function main:
   0x00400540 <+0>: push   %rbp
   0x00400541 <+1>: mov$0x1,%esi
   0x00400546 <+6>: mov$0x2,%ebp
   0x0040054b <+11>:push   %rbx
   0x0040054c <+12>:sub$0x18,%rsp
   0x00400550 <+16>:movl   $0x1,(%rsp)   <<===
   0x00400557 <+23>:movl   $0x2,0x4(%rsp)<<===
   0x0040055f <+31>:mov%rsp,%rbx
   0x00400562 <+34>:movl   $0x3,0x8(%rsp)<<===
   0x0040056a <+42>:movl   $0x0,0xc(%rsp)<<===
   0x00400572 <+50>:jmp0x40057d 
   0x00400574 <+52>:nopl   0x0(%rax)
   0x00400578 <+56>:mov%ebp,%esi
   0x0040057a <+58>:mov0x4(%rbx),%ebp
   0x0040057d <+61>:xor%eax,%eax
   0x0040057f <+63>:mov$0x40068c,%edi
   0x00400584 <+68>:add$0x4,%rbx
   0x00400588 <+72>:callq  0x4003b8 
   0x0040058d <+77>:test   %ebp,%ebp
   0x0040058f <+79>:jne0x400578 
   0x00400591 <+81>:add$0x18,%rsp
   0x00400595 <+85>:xor%eax,%eax
   0x00400597 <+87>:pop%rbx
   0x00400598 <+88>:pop%rbp
   0x00400599 <+89>:retq   
End of assembler dump.

[Bug libstdc++/53221] New: [C++11] basic_string lacks "copy/move constructors" with allocator

[daniel.kruegler at googlemail dot com]

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

 Bug #: 53221
   Summary: [C++11] basic_string lacks "copy/move constructors"
with allocator
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com


The library implementation of gcc 4.8.0 20120429 (experimental) misses the
following "copy/move constructors" with allocators:

basic_string(const basic_string&, const Allocator&);
basic_string(basic_string&&, const Allocator&);

These were added to the working draft with acceptance of the allocator proposal

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2554.pdf 

The following test case fails:

//---
#include 
#include 

int main()
{
  std::string s1;
  std::string s2(s1, std::allocator());
  std::string s3(static_cast(s1), std::allocator());
}
//---

[Bug libstdc++/53221] [C++11] basic_string lacks "copy/move constructors" with allocator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-05-03
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2012-05-03 
20:41:48 UTC ---
Yep, known issue - only vector has been updated to the C++11 allocator changes.
I've started doing it for vstring first, std::string will get done at some
point too.

I thought the C++11 status table in the manual listed this as missing, but it
doesn't (except under the general container requirements)

[Bug debug/51564] [4.7 Regression] ICE in force_type_die, at dwarf2out.c:19288

[matt at use dot net]

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

Matt Hargett  changed:

   What|Removed |Added

 CC||matt at use dot net

--- Comment #5 from Matt Hargett  2012-05-03 20:56:40 UTC 
---
I believe I'm hitting (what I'm pretty sure is) this with same bug GCC 4.6
trunk as well. Can you apply the patch to lto-streamer-out.c on the 4_6 branch
as well? Thanks!

In member function ‘__base_dtor ’:
lto1: internal compiler error: in force_type_die, at dwarf2out.c:21059

[Bug bootstrap/53200] [4.8 Regression] bootstrap broken on x86_64-apple-darwin10 at revision 187018

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from Dominique d'Humieres  2012-05-03 
21:03:55 UTC ---
> Hmm.  I see nothing amiss in that generated config file.
> But see if by chance it isn't the same problem as fixed by r187102.

Bootstrap succeeded at r187110. Thanks. Closing as fixed.

[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c

[martin at netbsd dot org]

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

--- Comment #1 from Martin Husemann  2012-05-03 
21:34:13 UTC ---
It occured to me that gcc would (rightfully) behave this way, if the (previous)
value in %i0 should be considered dead at this point - which might be the case,
hard to tell due to lots of macro magic [is there some way to easily check
this?].

However, in this function there is a sigsetjmp() call, and in the test case we
return to it. The standard says that non volatile automatic variables which
values changed after the setjmp() call may have the later value on return from
the longjmp - and this probably extrapolates to this type of register usage.
Since %i0 is not callee saved in sparc64, its value is restored on longjmp from
the register window shadow copy on the stack, where it has the later value (0
in the exammple).

So, how could I check this hypothesis?
Is there some attribute magic we could use to hint gcc to keep all values alive
at the setjmp call alive untill the end of the function?

[Bug target/53199] __builtin_bswap64 and __builtin_bswap32 generate errors if -mcpu=power6

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  2012-05-03 
21:47:49 UTC ---
Author: meissner
Date: Thu May  3 21:47:45 2012
New Revision: 187119

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187119
Log:
[gcc]
2012-05-03  Michael Meissner  

PR target/53199
* config/rs6000/rs6000.md (bswapdi splitters): If
-mavoid-indexed-addresses (or -mcpu=power6 which sets it by
default) is used, generate an alternate sequence that does not
depend on using indexed addressing.

[gcc/testsuite]
2012-05-03  Michael Meissner  

PR target/53199
* gcc.target/powwerpc/pr53199.c: New file.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr53199.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/51494] Legal program rejection - capturing "this" when using static method inside lambda

[luto at mit dot edu]

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

Andy Lutomirski  changed:

   What|Removed |Added

 CC||luto at mit dot edu

--- Comment #2 from Andy Lutomirski  2012-05-03 21:53:18 
UTC ---
This seems to have gotten worse in gcc 4.7.  This code is now rejected as well:

This code:

struct A
{
  static void func1() {}
};

template
struct B : public A
{
  void func2() const
  {
func3([&]{ func1(); });
  }

  template
  void func3(Func f) const
  {
  }
};

template class B;

The error is:

template_bug.cc: In instantiation of ‘B::func2() const [with T =
int]::’:
template_bug.cc:11:22:   required from ‘struct B::func2() const [with T =
int]::’
template_bug.cc:11:5:   required from ‘void B::func2() const [with T = int]’
template_bug.cc:20:16:   required from here
template_bug.cc:11:16: error: redeclaration of ‘const B* const
B::func2() const [with T = int]__this’
template_bug.cc:11:22: note: previous declaration ‘const B* const
B::func2() const [with T = int]__this’
template_bug.cc:11:16: error: redeclaration of ‘const B* const this’
template_bug.cc:11:22: error: ‘const B* const this’ previously declared
here
template_bug.cc:15:8: error: ‘void B::func3(Func) const [with Func =
B::func2() const [with T = int]::; T = int]’, declared using local
type ‘B::func2() const [with T = int]::’, is used but never
defined [-fpermissive]

Your patch fixes this test case, too.

[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit

[davem at gcc dot gnu.org]

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

--- Comment #11 from davem at gcc dot gnu.org 2012-05-03 22:19:42 UTC ---
Author: davem
Date: Thu May  3 22:19:35 2012
New Revision: 187120

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187120
Log:
Fix long double float miscompilations on sparc 64-bit.

PR target/52684
* config/sparc/sparc.c (emit_soft_tfmode_libcall): If we pass a
MEM directly into a libcall, mark it's MEM_EXPR as addressable.
(sparc_emit_float_lib_cmp): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.c

[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit

[davem at gcc dot gnu.org]

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

--- Comment #12 from davem at gcc dot gnu.org 2012-05-03 22:34:41 UTC ---
Author: davem
Date: Thu May  3 22:34:34 2012
New Revision: 187124

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187124
Log:
Fix long double float miscompilations on sparc 64-bit.

PR target/52684
* config/sparc/sparc.c (emit_soft_tfmode_libcall): If we pass a
MEM directly into a libcall, mark it's MEM_EXPR as addressable.
(sparc_emit_float_lib_cmp): Likewise.

Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/sparc/sparc.c