[Bug fortran/51218] [4.7 Regression] Potential optimization bug

[anlauf at gmx dot de]

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

--- Comment #6 from Harald Anlauf anlauf at gmx dot de 2011-11-19 08:12:01 
UTC ---
(In reply to comment #3)
 The miscompilation is triggered by -ffrontend-optimize, work-around: use
 -fno-frontend-optimize.
 Revision 171653 is dealing with the frontend optimization. If I am not
 mistaken, it is the only change dealing with frontend optimization after
 r171100, although I don't understand how this revision could cause a
 miscompilation.
 
 The crash occurs in __mo_dec_matrix_MOD_sum_vector.

Aha.  Compiling just main.f90 with -fno-frontend-optimize solves
the problem.

Thanks,
Harald

[Bug fortran/51218] [4.7 Regression] Potential optimization bug

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig tkoenig at gcc dot gnu.org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-11-19 
09:08:37 UTC ---
A few comments:

a) The call to delete_storage makes the code invalid in several
   respects

b) This function should not have been inlined (i.e. the bug not
   exposed) without the -faggressive-function-elimination flag.

c) The reason why this function call was inlined was that the
   implicit_pure attribute is set on the function.  This is
   bogus.


  /* Only eliminate potentially impure functions if the
 user specifically requested it.  */
  if (!gfc_option.flag_aggressive_function_elimination
   !(*e)-value.function.esym-attr.pure
   !(*e)-value.function.esym-attr.implicit_pure)
return 0;

(gdb) p (*e)-value.function.esym-attr.pure
$8 = 0
(gdb) p (*e)-value.function.esym-attr.implicit_pure
$9 = 1

Paul, I think you introduced the implicit_pure attribute.  Do
you have any idea why this could be set in this case?

[Bug fortran/51207] [OOP] Mark __def_init_... as FL_PARAMETER

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-19 
09:26:38 UTC ---
Author: burnus
Date: Sat Nov 19 09:26:33 2011
New Revision: 181505

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181505
Log:
2011-11-19  Tobias Burnus  bur...@net-b.de

PR fortran/51207
* class.c (gfc_find_derived_vtab): Mark __def_init as PARAMETER
and hence as TREE_READONLY; add subroutine attribute to
__copy_ procedure.

PR fortran/50640
* trans.h (GFC_DECL_PUSH_TOPLEVEL): New DECL_LANG_FLAG_7.
* trans-decl.c (gfc_get_symbol_decl): Mark __def_init and vtab
as GFC_DECL_PUSH_TOPLEVEL.
(gfc_generate_function_code): If GFC_DECL_PUSH_TOPLEVEL, push it there.
(build_function_decl): Push __copy_ procedure to the toplevel.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans.h

[Bug fortran/50640] [4.7 Regression] [OOP] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)

[burnus at gcc dot gnu.org]

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

--- Comment #24 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-19 
09:26:37 UTC ---
Author: burnus
Date: Sat Nov 19 09:26:33 2011
New Revision: 181505

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181505
Log:
2011-11-19  Tobias Burnus  bur...@net-b.de

PR fortran/51207
* class.c (gfc_find_derived_vtab): Mark __def_init as PARAMETER
and hence as TREE_READONLY; add subroutine attribute to
__copy_ procedure.

PR fortran/50640
* trans.h (GFC_DECL_PUSH_TOPLEVEL): New DECL_LANG_FLAG_7.
* trans-decl.c (gfc_get_symbol_decl): Mark __def_init and vtab
as GFC_DECL_PUSH_TOPLEVEL.
(gfc_generate_function_code): If GFC_DECL_PUSH_TOPLEVEL, push it there.
(build_function_decl): Push __copy_ procedure to the toplevel.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans.h

[Bug fortran/51207] [OOP] Mark __def_init_... as FL_PARAMETER

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-19 
09:30:05 UTC ---
FIXED on the 4.7 trunk.

[Bug fortran/50640] [4.7 Regression] [OOP] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #25 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-19 
09:31:31 UTC ---
Should be FIXED. Please reopen if it isn't.

The solution was as proposed by Michael in comment 4 - and it is a slightly
extended version of the patch in comment 22.

[Bug fortran/51218] [4.7 Regression] Potential optimization bug due to implicit_pure?

[anlauf at gmx dot de]

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

--- Comment #8 from Harald Anlauf anlauf at gmx dot de 2011-11-19 10:18:46 
UTC ---
(In reply to comment #6)
 Aha.  Compiling just main.f90 with -fno-frontend-optimize solves
 the problem.

Comparing -fdump-tree-original for main.f90 at -O0  without
and with -fno-frontend-optimize shows:

--- noopt/main.f90.003t.original2011-11-19 10:51:21.0 +0100
+++ opt/main.f90.003t.original  2011-11-19 10:52:10.0 +0100
@@ -7,6 +7,7 @@
   static struct t_vector xi = {.info=0B, .n=0, .n_s=0, .alloc_l=0,
.s={.data=0B
}};

   {
+struct t_vector __var_1;
 integer(kind=4) overflow.2;
 logical(kind=4) D.1818;
 character(kind=4) size.1;
@@ -259,14 +260,9 @@
   _gfortran_transfer_character_write (dt_parm.11, Before u:[1]{lb: 1
sz
: 1}, 9);
   _gfortran_st_write_done (dt_parm.11);
 }
-{
-  struct t_vector D.1860;
-  struct t_vector D.1859;
-
-  D.1859 = vector_times_vector (xi, wi);
-  D.1860 = vector_times_vector (xi, wi);
-  u = sum_vector (D.1859) + sum_vector (D.1860);
-}
+__var_1 = vector_times_vector (xi, wi);
+u = sum_vector (__var_1) + sum_vector (__var_1);
+L.4:;
 {
   struct __st_parameter_dt dt_parm.12;


This won't work.  The implementation of the management
of temporaries does not allow that the same instance
is used more than once.

The other case with the commented lines exchanged:

+++ opt2/main.f90.003t.original 2011-11-19 10:59:23.0 +0100
@@ -7,6 +7,7 @@
   static struct t_vector xi = {.info=0B, .n=0, .n_s=0, .alloc_l=0,
.s={.data=0B
}};

   {
+struct t_vector __var_1;
 integer(kind=4) overflow.2;
 logical(kind=4) D.1818;
 character(kind=4) size.1;
@@ -259,16 +260,14 @@
   _gfortran_transfer_character_write (dt_parm.11, Before u:[1]{lb: 1
sz
: 1}, 9);
   _gfortran_st_write_done (dt_parm.11);
 }
+__var_1 = vector_times_vector (xi, wi);
 {
   struct t_vector D.1862;
-  struct t_vector D.1860;
-  struct t_vector D.1859;

-  D.1859 = vector_times_vector (xi, wi);
-  D.1860 = vector_times_vector (xi, wi);
-  D.1862 = add_vectors (D.1859, D.1860);
+  D.1862 = add_vectors (__var_1, __var_1);
   u = sum_vector (D.1862);
 }
+L.4:;
 {
   struct __st_parameter_dt dt_parm.12;


Almost the same here, with aliasing of the arguments leading
to the slightly different crash.

[Bug fortran/51218] [4.7 Regression] Potential optimization bug due to implicit_pure?

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug fortran/51218] [4.7 Regression] Potential optimization bug due to implicit_pure?

[anlauf at gmx dot de]

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

--- Comment #9 from Harald Anlauf anlauf at gmx dot de 2011-11-19 10:35:11 
UTC ---
(In reply to comment #7)
 c) The reason why this function call was inlined was that the
implicit_pure attribute is set on the function.  This is
bogus.

Good point.

Adding:

  volatile :: xi, wi

in main solves the problem.

[Bug fortran/51218] [4.7 Regression] Potential optimization bug due to implicit_pure?

[tkoenig at netcologne dot de]

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

--- Comment #10 from tkoenig at netcologne dot de tkoenig at netcologne dot 
de 2011-11-19 10:57:23 UTC ---
Am 19.11.2011 11:18, schrieb anlauf at gmx dot de:
 This won't work.  The implementation of the management
 of temporaries does not allow that the same instance
 is used more than once.

If I understand your code, you are modifying the arguments of your 
function and evaluating that function more than once in a single
expression.  This is illegal in Fortran, so gfortran could, in
principle, do anything with it.  I would advise you to fix your code to
be standard-conforming.

Because such code is unfortunately quite common, gfortran by default
does not do such optimizations unless directed to be. The fact that
it does here nonetheless is, indeed, a bug.

[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org

--- Comment #33 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 
2011-11-19 11:30:34 UTC ---
There is also the case where no argument has been stored on the stack yet.
That's quite common for ABIs that pass arguments in registers.

[Bug middle-end/50074] [4.7 Regression] gcc.dg/sibcall-6.c execution test on x86_64 with -fPIC

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org

--- Comment #10 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 
2011-11-19 11:44:00 UTC ---
(In reply to comment #9)
 I see the same on s390x. gcc.dg/sibcall-6.c starts failing with r176042.

I also see this on Epiphany.

[Bug fortran/51218] [4.7 Regression] Potential optimization bug due to implicit_pure?

[anlauf at gmx dot de]

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

--- Comment #11 from Harald Anlauf anlauf at gmx dot de 2011-11-19 11:46:28 
UTC ---
(In reply to comment #10)
The code does memory management similar to that required by
TR15581 for allocatable DT components and allocatable function
results, but it also has to work for compilers that do not
support TR15581.  It does so by overloading everything needed.

 If I understand your code, you are modifying the arguments of your 
 function and evaluating that function more than once in a single
 expression.

The expression xi*wi allocates a temporary, which needs to
get deallocated after it was used to avoid a memory leak.
All bookkeeping is done with the temporaries.  Functions
check whether they access a variable or a temporary.
Using the temporaries is not a pure operation, which is
consistent with the way the functions are declared.

 This is illegal in Fortran, so gfortran could, in
 principle, do anything with it.

I thought that program variables are somewhat different
from temporaries created from expressions.

In Fortran 95 I do not see any standard-conforming way
for a program to access that very temporary more than once.
If the compiler decides to use it twice, bad things happen.

(Same if a compiler decided to call deallocate twice.)

 I would advise you to fix your code to
 be standard-conforming.

Do you have a suggestion without introducing a memory leak?

 Because such code is unfortunately quite common, gfortran by default
 does not do such optimizations unless directed to be. The fact that
 it does here nonetheless is, indeed, a bug.

[Bug middle-end/50074] [4.7 Regression] gcc.dg/sibcall-6.c execution test on x86_64 with -fPIC

[amylaar at gcc dot gnu.org]

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

--- Comment #11 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 
2011-11-19 12:03:28 UTC ---
Created attachment 25858
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25858
Patch to make mem_overlaps_already_clobbered_arg_p return false if no arguments
were stored on stack

This patch fixes the sibcall-6.c failure on Epiphany.

[Bug c++/50306] ambiguous templated conversion operators accepted

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-19 
12:11:05 UTC ---
Yes, I confirm the issue doesn't seem fixed neither mainline nor 4_6-branch.

[Bug bootstrap/51201] [4.7 regression] build error without Ada compiler installed

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Version|unknown |4.7.0
   Last reconfirmed||2011-11-19
  Component|ada |bootstrap
 CC||ebotcazou at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1
Summary|/bin/bash: gnatls: command  |[4.7 regression] build
   |not found   |error without Ada compiler
   ||installed
   Target Milestone|--- |4.7.0

--- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-19 
12:25:57 UTC ---
Annoying.

[Bug c++/50306] ambiguous templated conversion operators accepted

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez manu at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-19
 Ever Confirmed|0   |1

--- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-11-19 
12:46:13 UTC ---
You are right, it seems I tested the second example by mistake.

[Bug target/50493] ICE in neon_disambiguate_copy, at config/arm/arm.c:20388

[rearnsha at gcc dot gnu.org]

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

--- Comment #5 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-11-19 
13:47:40 UTC ---
Author: rearnsha
Date: Sat Nov 19 13:47:35 2011
New Revision: 181508

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181508
Log:
PR target/50493
* arm.c (neon_disambiguate_copy): Correctly handle partial overlap
of src and dest operands.

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

[Bug c++/51210] [C++11][DR 295] std::type_info works incorrectly with function types with cv-qualifier-seq

[marc.glisse at normalesup dot org]

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

Marc Glisse marc.glisse at normalesup dot org changed:

   What|Removed |Added

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

--- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2011-11-19 
13:56:43 UTC ---
Dup of PR c++/48665 ?

[Bug c++/51210] [C++11][DR 295] std::type_info works incorrectly with function types with cv-qualifier-seq

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com 
2011-11-19 13:59:18 UTC ---
I agree, this issue seems to be a DUP

[Bug c++/51194] [C++0x] ICE about template aliasing

[dodji at gcc dot gnu.org]

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

--- Comment #5 from Dodji Seketeli dodji at gcc dot gnu.org 2011-11-19 
14:07:22 UTC ---
A candidate patch has been posted to
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01979.html

[Bug lto/50490] ICE when compiling libglib2.0 with LTO, tree code 'optimization_node' is not supported in LTO streams

[reichelt at gcc dot gnu.org]

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

Volker Reichelt reichelt at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-19
 CC||reichelt at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org 2011-11-19 
14:37:32 UTC ---
I ran into the same issue.
Here's a reduced testcase that triggers the ICE when compiled with -flto:

=
__attribute__((optimize(1))) void foo() {}
=

bug.c:1:1: internal compiler error: tree code 'optimization_node' is not
supported in LTO streams
Please submit a full bug report, [etc.]

This only happens on trunk, before I get:

bug.c:1:1: sorry, unimplemented: gimple bytecode streams do not support the
optimization attribute

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[iains at gcc dot gnu.org]

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

--- Comment #16 from Iain Sandoe iains at gcc dot gnu.org 2011-11-19 14:56:09 
UTC ---
I had a quick look...

actually, I suspect that the BLKmode constraint you originally had is, in fact,
correct.

we are talking about bit fields - i.e contiguous blocks of bits - so, if memory
serves me correctly, we are not in the realm of padding rules  (but I need to
double-check the ABI doc).

so:

When BIG-Endian  !BLKMode ... you are copying the data in reverse order
(pushing the bitfield into the least significant bits of the destination) -
ergo the remaining fragment needs to be stored at the higher sub-address of
the fragmented last word.

When BE  BLKmode you are copying in ascending address order (i.e. aligning
the bits to the MS) .. ergo the remaining fragment needs to be copied to the
lower sub-address of the last fragmented word.

In saying this, of course, that does not imply that I've checked that the basic
choice is correct.

[Bug middle-end/51220] New: gcc/libquadmath/math/nanq.c:9:20: ICE: in int_mode_ for_mode, at stor-layout.c:424

[danglin at gcc dot gnu.org]

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

 Bug #: 51220
   Summary: gcc/libquadmath/math/nanq.c:9:20: ICE: in int_mode_
for_mode, at stor-layout.c:424
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11


libtool: compile:  /test/gnu/gcc/objdir/./gcc/xgcc
-B/test/gnu/gcc/objdir/./gcc/
 -B/opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.7/hppa2.
0w-hp-hpux11.11/lib/ -isystem
/opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/include
 -isystem /opt/gnu/gcc/gcc-4.7/hppa2.0w-hp-hpux11.11/sys-include
-DHAVE_CONFIG_H
 -I. -I../../../gcc/libquadmath -g -O2 -MT math/nanq.lo -MD -MP -MF
math/.deps/n
anq.Tpo -c ../../../gcc/libquadmath/math/nanq.c  -fPIC -DPIC -o
math/.libs/nanq.
o
../../../gcc/libquadmath/math/nanq.c: In function 'nanq':
../../../gcc/libquadmath/math/nanq.c:9:20: internal compiler error: in
int_mode_
for_mode, at stor-layout.c:424

-bash-3.2$ ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa2.0w-hp-hpux11.11
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as
--enable-shared --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.7
--with-gmp=/opt/gnu/gcc/gmp --enable-threads=posix --enable-debug=no
--disable-nls --disable-lto --without-cloog --without-ppl
--enable-languages=c,c++,objc,fortran,java,ada,obj-c++
Thread model: posix
gcc version 4.7.0 2018 (experimental) [trunk revision 181473] (GCC) 

Revision 181376 was ok.

[Bug fortran/51218] [4.7 Regression] Potential optimization bug due to implicit_pure?

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #12 from Steve Kargl sgk at troutmask dot apl.washington.edu 
2011-11-19 16:08:06 UTC ---
On Sat, Nov 19, 2011 at 10:57:23AM +, tkoenig at netcologne dot de wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51218
 
 --- Comment #10 from tkoenig at netcologne dot de tkoenig at netcologne dot 
 de 2011-11-19 10:57:23 UTC ---
 Am 19.11.2011 11:18, schrieb anlauf at gmx dot de:
  This won't work.  The implementation of the management
  of temporaries does not allow that the same instance
  is used more than once.
 
 If I understand your code, you are modifying the arguments of your 
 function and evaluating that function more than once in a single
 expression.  This is illegal in Fortran, so gfortran could, in
 principle, do anything with it.  I would advise you to fix your code to
 be standard-conforming.
 
 Because such code is unfortunately quite common, gfortran by default
 does not do such optimizations unless directed to be. The fact that
 it does here nonetheless is, indeed, a bug.
 

The code is also invalid because it manipulates the
pointer (not the target) of a derived-type dummy
argument with the intent(in) attribute.  The code
has at least two bugs and the PR should be closed.

[Bug fortran/51218] [4.7 Regression] Potential optimization bug due to implicit_pure?

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #13 from Steve Kargl sgk at troutmask dot apl.washington.edu 
2011-11-19 16:18:18 UTC ---
On Sat, Nov 19, 2011 at 11:46:28AM +, anlauf at gmx dot de wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51218
 
 --- Comment #11 from Harald Anlauf anlauf at gmx dot de 2011-11-19 11:46:28 
 UTC ---
 (In reply to comment #10)
 The code does memory management similar to that required by

s/does/tries to do/

 TR15581 for allocatable DT components and allocatable function
 results, but it also has to work for compilers that do not
 support TR15581.  It does so by overloading everything needed.
 
  If I understand your code, you are modifying the arguments of your 
  function and evaluating that function more than once in a single
  expression.
 
 The expression xi*wi allocates a temporary, which needs to
 get deallocated after it was used to avoid a memory leak.
 All bookkeeping is done with the temporaries.  Functions
 check whether they access a variable or a temporary.
 Using the temporaries is not a pure operation, which is
 consistent with the way the functions are declared.

*If* the compiler generates a temporary for xi*wi, the
compiler will/should generate the necessary code to
garbage collect any memory used by that temporary.

  I would advise you to fix your code to
  be standard-conforming.
 
 Do you have a suggestion without introducing a memory leak?
 

Let the compiler do its job?
Don't manipulate pointers in a non-conforming way?

[Bug target/50970] Function pointer dereferenced twice in if statement on Arm cpu

[mikpe at it dot uu.se]

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

Mikael Pettersson mikpe at it dot uu.se changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2011-11-19 
16:33:43 UTC ---
I can reproduce the bogus output on ARMv5TE with g++ 4.4/4.5/4.6/4.7. 
Optimization level and arch/tune/thumb selection doesn't seem to make any
difference.  g++ 4.7 gives the expected output on i686, sparc64, and alpha.

[Bug target/50493] ICE in neon_disambiguate_copy, at config/arm/arm.c:20388

[rearnsha at gcc dot gnu.org]

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

--- Comment #6 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-11-19 
16:47:06 UTC ---
Author: rearnsha
Date: Sat Nov 19 16:47:02 2011
New Revision: 181510

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181510
Log:
PR target/50493
* arm.c (neon_disambiguate_copy): Correctly handle partial overlap
of src and dest operands.

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

[Bug target/50493] ICE in neon_disambiguate_copy, at config/arm/arm.c:20388

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw rearnsha at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-11-19 
16:48:25 UTC ---
Fixed on trunk and 4.6 branch

[Bug fortran/51218] [4.7 Regression] Potential optimization bug due to implicit_pure?

[kargl at gcc dot gnu.org]

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

--- Comment #14 from kargl at gcc dot gnu.org 2011-11-19 17:35:20 UTC ---
Tobias,

Why did you mark this PR with the wrong-code keyword?
The code is invalid, so gfortran can generated anything
it wants.

[Bug target/50970] Function pointer dereferenced twice in if statement on Arm cpu

[mikpe at it dot uu.se]

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

--- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 2011-11-19 
17:42:53 UTC ---
Created attachment 25859
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25859
reduced test case

Reduced test case.  Running this on i686 shows a single call to func3

/mnt/scratch/install47/bin/g++ -O2 -Wall pr50970.cc ; ./a.out
TestClass::func3 from 0x8048553

but on ARM we see two calls from different locations:

/mnt/scratch/install47/bin/g++ -march=armv5te -mtune=arm10tdmi -O2 -Wall 
pr50970.cc ; ./a.out
TestClass::func3 from 0x8554
TestClass::func3 from 0x8590

Looking at the code for testFunction

void TestClass::testFunction()
{
  if ((this-*_myFunc3)() == 0)
;
}

we see not one but two indirect method calls (the blx insns):

_ZN9TestClass12testFunctionEv:
.fnstart
.LFB16:
@ args = 0, pretend = 0, frame = 16
@ frame_needed = 0, uses_anonymous_args = 0
stmfd   sp!, {r4, lr}
.save {r4, lr}
ldr r1, [r0, #4]
.pad #16
sub sp, sp, #16
tst r1, #1
ldrne   r2, [r0, r1, asr #1]
ldrne   r3, [r0, #0]
ldreq   r3, [r0, #0]
addeq   r1, r0, r1, asr #1
addne   r1, r0, r1, asr #1
ldrne   r3, [r2, r3]
mov r4, r0
mov r0, sp
blx r3
ldr r3, [sp, #0]
cmp r3, #0
beq .L14
.L7:
add sp, sp, #16
ldmfd   sp!, {r4, pc}
.L14:
ldr r1, [r4, #4]
add r0, sp, #8
tst r1, #1
ldrne   r2, [r4, r1, asr #1]
ldrne   r3, [r4, #0]
ldreq   r3, [r4, #0]
addeq   r1, r4, r1, asr #1
addne   r1, r4, r1, asr #1
ldrne   r3, [r2, r3]
blx r3
b   .L7

[Bug other/51125] FAIL: g++.dg/tm/pr45940-3.C

[patrick.marlier at gmail dot com]

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

--- Comment #5 from Patrick Marlier patrick.marlier at gmail dot com 
2011-11-19 17:42:20 UTC ---
** NOT RELATED TO BUG **
In http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00969.html, the patch shows
changes to tree-ssa-reassoc.c but not committed or part of Changelog.
But the problem is definitely not here.

Patrick.

Index: tree-ssa-reassoc.c
===
--- tree-ssa-reassoc.c.orig2011-11-07 15:56:25.0 +0100
+++ tree-ssa-reassoc.c2011-11-07 16:12:35.0 +0100
@@ -2869,6 +2869,12 @@  reassociate_bb (basic_block bb)
   rhs1 = gimple_assign_rhs1 (stmt);
   rhs2 = gimple_assign_rhs2 (stmt);

+  /* We don't want to destroy reduction like patterns
+ with reassociation, simply don't start at such
+ statements.  */
+  if (is_phi_for_stmt (stmt, rhs1) || is_phi_for_stmt (stmt, rhs2))
+continue;
+
   /* For non-bit or min/max operations we can't associate
  all types.  Verify that here.  */
   if (rhs_code != BIT_IOR_EXPR

[Bug c++/51221] New: Cross GCC for AIX fails during bootstrap process

[basil at list dot ru]

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

 Bug #: 51221
   Summary: Cross GCC for AIX fails during bootstrap process
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ba...@list.ru
  Host: x86_64-linux-gnu
Target: powerpc-ibm-aix5.2.0.0


Created attachment 25860
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25860
preprocessed file

GCC was configured with
/emc/sukhav/cross/gcc-4.6.2//configure --prefix=/emc/sukhav/cross/aix/gcc462
--with-sysroot=/emc/sukhav/cross/aix/sysroot --target=powerpc-ibm-aix5.2.0.0
--with-gnu-as --with-gnu-ld --enable-languages=c,c++

Bootstrap failes with
/emc/sukhav/cross/aix/gcc462/temp/./gcc/xgcc
-B/emc/sukhav/cross/aix/gcc462/temp/./gcc/
-B/emc/sukhav/cross/aix/gcc462/powerpc-ibm-aix5.2.0.0/bin/
-B/emc/sukhav/cross/aix/gcc462/powerpc-ibm-aix5.2.0.0/lib/ -isystem
/emc/sukhav/cross/aix/gcc462/powerpc-ibm-aix5.2.0.0/include -isystem
/emc/sukhav/cross/aix/gcc462/powerpc-ibm-aix5.2.0.0/sys-include-g -O2
-pthread -O2  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -mlong-double-128 -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector 
 -I. -I. -I../../.././gcc -I/emc/sukhav/cross/gcc-4.6.2/libgcc
-I/emc/sukhav/cross/gcc-4.6.2/libgcc/.
-I/emc/sukhav/cross/gcc-4.6.2/libgcc/../gcc
-I/emc/sukhav/cross/gcc-4.6.2/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o
unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c
/emc/sukhav/cross/gcc-4.6.2/libgcc/../gcc/unwind-dw2.c
/emc/sukhav/cross/gcc-4.6.2/libgcc/../gcc/unwind-dw2.c: In function
âuw_init_context_1â:
/emc/sukhav/cross/gcc-4.6.2/libgcc/../gcc/unwind-dw2.c:1461:5: warning: missing
braces around initializer [-Wmissing-braces]
/emc/sukhav/cross/gcc-4.6.2/libgcc/../gcc/unwind-dw2.c:1461:5: warning: (near
initialization for âonce_regsizes.__on_wordâ) [-Wmissing-braces]
In file included from
/emc/sukhav/cross/gcc-4.6.2/libgcc/../gcc/unwind-dw2.c:1582:0:
/emc/sukhav/cross/gcc-4.6.2/libgcc/../gcc/unwind.inc: In function
â_Unwind_ForcedUnwind_Phase2â:
/emc/sukhav/cross/gcc-4.6.2/libgcc/../gcc/unwind.inc:189:1: error:
unrecognizable insn:
(insn 34 33 35 8 (set (mem/v:DI (plus:DI (reg/f:SI 1 1)
(const_int 20 [0x14])) [0 S8 A8])
(reg:SI 2 2)) /emc/sukhav/cross/gcc-4.6.2/libgcc/../gcc/unwind.inc:163
-1
 (nil))
/emc/sukhav/cross/gcc-4.6.2/libgcc/../gcc/unwind.inc:189:1: internal compiler
error: in extract_insn, at recog.c:2109
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Preprocessed file attached.

[Bug c++/51222] New: [C++11][SFINAE] Unevaluated combined delete new expression completely broken

[daniel.kruegler at googlemail dot com]

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

 Bug #: 51222
   Summary: [C++11][SFINAE] Unevaluated combined delete new
expression completely broken
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@gcc.gnu.org


The following problem became obvious to me when I recently tried to provide a
both simpler and more general library emulation of is_constructible.

gcc 4.7 2012 (experimental) in C++11 mode rejects the following code:

//---
templateclass T
struct add_rref {
  typedef T type;
};

template
struct add_rrefvoid {
  typedef void type;
};

templateclass T
typename add_rrefT::type declval();

templateclass T, class U, class =
  decltype(::delete ::new T(declvalU()))

auto f(int) - char;

templateclass, class
auto f(...) - char()[2];

templateclass T, class =
  decltype(::delete ::new T())

auto g(int) - char;

templateclass
auto g(...) - char()[2];

struct C { };

struct A {
  virtual ~A() = 0;
};

struct D1 {
  D1() = delete;
};

struct D2 {
  ~D2() = delete;
};

static_assert(sizeof(gvoid(0)) == 2, Ouch);
static_assert(sizeof(gvoid()(0)) == 2, Ouch);
static_assert(sizeof(gvoid() const(0)) == 2, Ouch);
static_assert(sizeof(gA(0)) == 2, Ouch);
static_assert(sizeof(gD1(0)) == 2, Ouch);
static_assert(sizeof(gD2(0)) == 2, Ouch);
static_assert(sizeof(gint(0)) == 2, Ouch);
static_assert(sizeof(gint(0)) == 2, Ouch);
static_assert(sizeof(gvoid()()(0)) == 2, Ouch);
static_assert(sizeof(gvoid()()(0)) == 2, Ouch);
static_assert(sizeof(fvoid, void(0)) == 2, Ouch);
static_assert(sizeof(fvoid(), void()(0)) == 2, Ouch);
static_assert(sizeof(fvoid() const, void() const(0)) == 2, Ouch);
static_assert(sizeof(fint, void(0)) == 2, Ouch);
static_assert(sizeof(fvoid, int(0)) == 2, Ouch);
static_assert(sizeof(fC, void(0)) == 2, Ouch);
static_assert(sizeof(fC, int(0)) == 2, Ouch);
static_assert(sizeof(fint, int(0)) == 2, Ouch);
static_assert(sizeof(fint, int(0)) == 2, Ouch);
static_assert(sizeof(fvoid()(), void()()(0)) == 2, Ouch);
static_assert(sizeof(fvoid()(), void()()(0)) == 2, Ouch);
//---

All static assertions fail, but they shouldn't. This is very unfortunate,
because above test expressions are extremely useful for emulating an effective
variable definition including destruction semantics.

The test code should be accepted.

[Bug target/50970] Function pointer dereferenced twice in if statement on Arm cpu

[mikpe at it dot uu.se]

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

--- Comment #8 from Mikael Pettersson mikpe at it dot uu.se 2011-11-19 
18:31:32 UTC ---
gcc-4.3.6 also generates the double-call, but gcc-4.2.4 doesn't.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #17 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-19 
18:38:48 UTC ---
 we are talking about bit fields - i.e contiguous blocks of bits - so, if 
 memory
 serves me correctly, we are not in the realm of padding rules  (but I need to
 double-check the ABI doc).
 
 so:
 
 When BIG-Endian  !BLKMode ... you are copying the data in reverse order
 (pushing the bitfield into the least significant bits of the destination) -
 ergo the remaining fragment needs to be stored at the higher sub-address of
 the fragmented last word.
 
 When BE  BLKmode you are copying in ascending address order (i.e. aligning
 the bits to the MS) .. ergo the remaining fragment needs to be copied to the
 lower sub-address of the last fragmented word.

In any case, the new code probably needs to be coordinated with this:

  /* Here we transfer the words of the field
 in the order least significant first.
 This is because the most significant word is the one which may
 be less than full.
 However, only do that if the value is not BLKmode.  */

  unsigned int backwards = WORDS_BIG_ENDIAN  fieldmode != BLKmode;

[Bug c++/51223] New: [4.5/4.6/4.7 Regression] ICE with invalid function parameter

[reichelt at gcc dot gnu.org]

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

 Bug #: 51223
   Summary: [4.5/4.6/4.7 Regression] ICE with invalid function
parameter
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following invalid code snippet triggers an ICE since GCC 4.5.0:

==
struct A
{
  A foo(void i = 0);
};

void bar()
{
  A().foo();
}

A A::foo(void i)
{
  return A();
}
==

bug.cc:3:18: error: 'i' has incomplete type
bug.cc:3:19: error: invalid use of 'void'
bug.cc: In function 'void bar()':
bug.cc:8:11: error: call to 'A A::foo(type error)' uses the default argument
for parameter 1, which is not yet defined
bug.cc: At global scope:
bug.cc:11:15: error: 'i' has incomplete type
bug.cc:11:16: error: invalid use of 'void'
bug.cc: In function 'void bar()':
bug.cc:8:11: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in useless_type_conversion_p, at tree-ssa.c:1460
Please submit a full bug report, [etc.]

[Bug middle-end/51211] ICE: SIGSEGV in execute_tm_mark (trans-mem.c:2242) with -fgnu-tm -O -freorder-blocks -ftracer --param hot-bb-frequency-fraction=1 and __transaction_atomic

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson rth at gcc dot gnu.org 2011-11-19 
19:29:22 UTC ---
Author: rth
Date: Sat Nov 19 19:29:18 2011
New Revision: 181512

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181512
Log:
PR middle-end/51211
* tracer.c (ignore_bb_p): Don't copy GIMPLE_TRANSACTION.

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

[Bug lto/51224] New: ICE with local struct and -flto

[reichelt at gcc dot gnu.org]

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

 Bug #: 51224
   Summary: ICE with local struct and -flto
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following code snippet triggers an ICE when compiled with -flto -g since
the introduction of LTO (GCC 4.5.0):

=
void foo()
{
  struct A
  {
typedef void (*F)();
static F bar() { return 0; }
  };

  A::bar();
}
=

bug.cc:10:1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:21346
Please submit a full bug report, [etc.]

[Bug c++/51225] New: [c++0x] [4.7 Regression] ICE with invalid template parameter

[reichelt at gcc dot gnu.org]

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

 Bug #: 51225
   Summary: [c++0x] [4.7 Regression] ICE with invalid template
parameter
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following invalid code snippet triggers an ICE on trunk when compiled with
-std=c++0x:

==
templateint struct A {};

templatetypename void foo()
{
  Aint(x) a;
}
==

bug.cc: In function 'void foo()':
bug.cc:5:9: error: 'x' was not declared in this scope
bug.cc:5:11: internal compiler error: unexpected expression '(int)(expression
error)' of kind cast_expr
Please submit a full bug report, [etc.]

[Bug c++/51225] [c++0x] [4.7 Regression] ICE with invalid template parameter

[reichelt at gcc dot gnu.org]

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

Volker Reichelt reichelt at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
   Target Milestone|--- |4.7.0

[Bug c++/51226] New: [c++0x] ICE with opaque enum and invalid template

[reichelt at gcc dot gnu.org]

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

 Bug #: 51226
   Summary: [c++0x] ICE with opaque enum and invalid template
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following invalid code snippet triggers an ICE since GCC 4.6.0:

===
templateint struct A
{
  enum E : int;
};

template enum A::E : int {};
===

bug.cc:6:19: error: wrong number of template arguments (0, should be 1)
bug.cc:1:22: error: provided for 'templateint anonymous  struct A'
bug.cc:6:26: internal compiler error: in is_ancestor, at cp/name-lookup.c:2586
Please submit a full bug report, [etc.]

[Bug c++/51227] New: [c++0x] ICE with invalid parameter in lambda expression

[reichelt at gcc dot gnu.org]

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

 Bug #: 51227
   Summary: [c++0x] ICE with invalid parameter in lambda
expression
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following invalid code snippet triggers an ICE when compiled with
-std=c++0x since the introduction of lambda expressions (GCC 4.5.0):


templateint int foo()
{
  [] (void i) { return 0; } (0);
}

void bar()
{
  foo0();
}


bug.cc: In function 'int foo()':
bug.cc:3:12: error: 'i' has incomplete type
bug.cc:3:13: error: invalid use of 'void'
bug.cc: In instantiation of 'struct foo() [with int anonymous =
0]::lambda':
bug.cc:3:3:   required from 'int foo() [with int anonymous = 0]'
bug.cc:8:10:   required from here
bug.cc:3:4: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]

[Bug rtl-optimization/51187] miscompilation of genrecog.c at -O2 for --target=avr

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-19 
20:36:47 UTC ---
Author: ebotcazou
Date: Sat Nov 19 20:36:43 2011
New Revision: 181513

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181513
Log:
PR rtl-optimization/51187
* reorg.c (relax_delay_slots): Do not consider a jump useless if there
is a barrier between the jump and its target label.

Added:
trunk/gcc/testsuite/gcc.dg/delay-slot-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reorg.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/51187] miscompilation of genrecog.c at -O2 for --target=avr

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-19 
20:39:12 UTC ---
Author: ebotcazou
Date: Sat Nov 19 20:39:10 2011
New Revision: 181514

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181514
Log:
PR rtl-optimization/51187
* reorg.c (relax_delay_slots): Do not consider a jump useless if there
is a barrier between the jump and its target label.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/delay-slot-2.c
  - copied unchanged from r181513,
trunk/gcc/testsuite/gcc.dg/delay-slot-2.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/reorg.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/51187] miscompilation of genrecog.c at -O2 for --target=avr

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-19 
20:41:53 UTC ---
Author: ebotcazou
Date: Sat Nov 19 20:41:50 2011
New Revision: 181515

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181515
Log:
PR rtl-optimization/51187
* reorg.c (relax_delay_slots): Do not consider a jump useless if there
is a barrier between the jump and its target label.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/delay-slot-2.c
  - copied unchanged from r181514,
trunk/gcc/testsuite/gcc.dg/delay-slot-2.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/reorg.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/51187] miscompilation of genrecog.c at -O2 for --target=avr

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|ASSIGNED|RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-11/msg01991.htm
   ||l
 Resolution||FIXED
   Target Milestone|--- |4.5.4

--- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-19 
20:45:07 UTC ---
Thanks for reporting the problem.

[Bug c++/51228] New: [4.5/4.6/4.7 Regression] ICE with transparent union

[reichelt at gcc dot gnu.org]

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

 Bug #: 51228
   Summary: [4.5/4.6/4.7 Regression] ICE with transparent union
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


The following code snippet triggers an ICE since GCC 4.5.0:

==
typedef union {} U __attribute__((transparent_union));

void foo(U u) {}
==

bug.cc: In function 'void foo(U)':
bug.cc:3:6: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]

[Bug c++/51229] New: [C++0x] [4.7 Regression] Broken diagnostic: 'integer_cst' not supported by dump_dec

[reichelt at gcc dot gnu.org]

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

 Bug #: 51229
   Summary: [C++0x] [4.7 Regression] Broken diagnostic:
'integer_cst' not supported by dump_dec
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


Trunk produces a broken error message for the following code snippet (using
-std=c++0x):


struct A
{
  int i;
};

A a = { [0] {} };


bug.cc:6:10: error: expected identifier before numeric constant
bug.cc:6:16: error: 'A' has no non-static data member named '#'integer_cst' not
supported by dump_decl#declaration error'

[Bug c++/51229] [C++0x] [4.7 Regression] Broken diagnostic: 'integer_cst' not supported by dump_dec

[reichelt at gcc dot gnu.org]

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

Volker Reichelt reichelt at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |4.7.0

[Bug ada/50294] ICE in output_constructor_regular_field

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-19 
21:25:17 UTC ---
Created attachment 25861
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25861
Improved testcase

It should fail everywhere.

[Bug ada/50294] ICE in output_constructor_regular_field

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-19 
21:35:48 UTC ---
 Thus the question - what should stor-layout do with domain types
 that wrap the wrong way around (i.e. are of wrong type because Ada
 turns everything into sizetype instead of [s]sizetype dependent on
 the Ada type signedness)?

What do you mean by Ada turns everything into sizetype here?  AFAIK the Ada
compiler behaves like the other compilers, i.e. domain types are built with

/* Create a type of integers to be the TYPE_DOMAIN of an ARRAY_TYPE.
   MAXVAL should be the maximum value in the domain
   (one less than the length of the array).

   The maximum value that MAXVAL can have is INT_MAX for a HOST_WIDE_INT.
   We don't enforce this limit, that is up to caller (e.g. language front end).
   The limit exists because the result is a signed type and we don't handle
   sizes that use more than one HOST_WIDE_INT.  */

tree
build_index_type (tree maxval)
{
  return build_range_type (sizetype, size_zero_node, maxval);
}

so are all subtypes of sizetype (gigi has create_index_type instead because it
needs to have non-shared range types and lower bounds, but it's equivalent).

[Bug c++/51230] New: [4.7 Regression] Broken diagnostic: 'template_parm_index' not supported by dump_type

[reichelt at gcc dot gnu.org]

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

 Bug #: 51230
   Summary: [4.7 Regression] Broken diagnostic:
'template_parm_index' not supported by dump_type
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org


Trunk produces a broken error message for the following invalid code snippet:

==
templateint struct A {};

templateint N void foo(AN, AN);

void bar()
{
  foo(A0(), A1());
}
==

bug.cc: In function 'void bar()':
bug.cc:7:21: error: no matching function for call to 'foo(A0, A1)'
bug.cc:7:21: note: candidate is:
bug.cc:3:22: note: templateint N void foo(AN, AN)
bug.cc:3:22: note:   template argument deduction/substitution failed:
bug.cc:7:21: note:   deduced conflicting types for parameter
'#'template_parm_index' not supported by dump_type#type error'
('#'integer_cst' not supported by dump_type#type error' and '#'integer_cst'
not supported by dump_type#type error')

[Bug c++/51230] [4.7 Regression] Broken diagnostic: 'template_parm_index' not supported by dump_type

[reichelt at gcc dot gnu.org]

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

Volker Reichelt reichelt at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |4.7.0

[Bug c++/51231] New: g++ remove placement new with -O1

[dushistov at mail dot ru]

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

 Bug #: 51231
   Summary: g++ remove placement new with -O1
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dushis...@mail.ru


If code bellow compile with -O1 it prints '0', while with '-O0' it prints
deadbeaf.

The problem in   allocator.construct (allocator.address (at), value);
In boost_1_46_1/boost/interprocess/allocators/allocator.hpp it looks like:
void construct(const pointer ptr, const_reference v)
   {  new((void*)detail::get_pointer(ptr)) value_type(v);  }

if rewrite it for example in such way:
 void construct(const pointer ptr, const_reference v)
   {
static volatile value_type *myp;
myp = detail::get_pointer(ptr);
::new((void *)myp) value_type(v);
   }

the code print expected value: deadbeaf.

#include iostream
#include boost/interprocess/allocators/allocator.hpp
#include boost/interprocess/managed_shared_memory.hpp

namespace interp = boost::interprocess;

struct interp_memory_chunk
{
  interp::managed_shared_memory  chunk;

  interp_memory_chunk ()
  {
interp::shared_memory_object::remove (GCC_interprocess_test);
chunk = interp::managed_shared_memory (interp::create_only,
GCC_interprocess_test, 0x1);
  }

  ~interp_memory_chunk ()
  {
interp::shared_memory_object::remove (GCC_interprocess_test);
  }
};

typedef  interp::allocator int,
interp::managed_shared_memory::segment_manager  allocator_type;

inline  void
create (allocator_type allocator, allocator_type::value_type at, int value)
{
  allocator.construct (allocator.address (at), value);
}

int
main ()
{
  interp_memory_chunk  memory;
  allocator_type   allocator (memory.chunk.get_segment_manager ());
  allocator_type::pointer  data = allocator.allocate (1);

  create (allocator, *data, 0xdeadbeef);
  std::cout  std::hex  *data  \n;
}

[Bug c++/51231] g++ remove placement new with -O1

[dushistov at mail dot ru]

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

--- Comment #1 from Evgeniy Dushistov dushistov at mail dot ru 2011-11-19 
21:49:33 UTC ---
The code works as expected for 4.4.5,
and show buggy behaviour with 4.5.3 and 4.6.2.

[Bug c++/51231] g++ remove placement new with -O1

[dushistov at mail dot ru]

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

--- Comment #2 from Evgeniy Dushistov dushistov at mail dot ru 2011-11-19 
22:03:49 UTC ---
Created attachment 25862
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25862
the preprocessed test case

generate from source with command:
g++ -ggdb -c -save-temps -O1  -Wall -Wextra boost_interp_alloc.cpp,
you still need -lboost_thread to create executable.

[Bug c++/51231] g++ remove placement new with -O1

[dushistov at mail dot ru]

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

--- Comment #3 from Evgeniy Dushistov dushistov at mail dot ru 2011-11-19 
22:07:40 UTC ---
To build test case you need use command:
g++ -ggdb -O1  -Wall -Wextra boost_interp_alloc.cpp  -lboost_thread

I use boost 1.46.1.

Or you can use preprocessed attachment to look at generated assembler.
Tested on x86_64.

[Bug lto/50747] [4.7 Regression] ICE in produce_symtab, at lto-streamer-out.c:1435

[reichelt at gcc dot gnu.org]

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

Volker Reichelt reichelt at gcc dot gnu.org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu.org

--- Comment #4 from Volker Reichelt reichelt at gcc dot gnu.org 2011-11-19 
22:58:50 UTC ---
Here's a different testcase that triggers the assertion one line before when
compiled with -flto. So the proposed fix might not be sufficient.

=
void foo();

static void bar() __attribute__((weakref(foo)));

struct A
{
  A();
};

int i;

template typename T, int struct B : T {};

BA, i b;
=

bug.cc:14:10: internal compiler error: in produce_symtab, at
lto-streamer-out.c:1434
Please submit a full bug report, [etc.]

[Bug c++/51216] [4.6/4.7 Regression] ICE with statement expression

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 
2011-11-19 23:17:16 UTC ---
Author: paolo
Date: Sat Nov 19 23:17:12 2011
New Revision: 181517

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181517
Log:
/cp
2011-11-19  Paolo Carlini  paolo.carl...@oracle.com

PR c++/51216
* semantics.c (potential_constant_expression_1): Handle IF_STMT,
DO_STMT, FOR_STMT, and WHILE_STMT.

/testsuite
2011-11-19  Paolo Carlini  paolo.carl...@oracle.com

PR c++/51216
* g++.dg/cpp0x/pr51216.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr51216.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/51222] [C++11][SFINAE] Unevaluated combined delete new expression completely broken

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Blocks||51185

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-19 
23:36:59 UTC ---
Ouch, indeed. Then let's mark this as blocking the library issue (if Daniel in
the meanwhile you can figure out a workaround we can remove the blockage)

[Bug c++/51230] [4.7 Regression] Broken diagnostic: 'template_parm_index' not supported by dump_type

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-11-19
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
 Ever Confirmed|0   |1

[Bug bootstrap/51232] New: building the all-stage1 target requires several invocations to complete

[matt at use dot net]

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

 Bug #: 51232
   Summary: building the all-stage1 target requires several
invocations to complete
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


As mentioned here:
http://gcc.gnu.org/ml/gcc-help/2011-11/msg00193.html

../configure --enable-bootstrap --prefix=/home/matt --enable-clocale=gnu
--with-system-zlib --enable-shared --with-demangler-in-ld --enable-lto
--with-build-config=bootstrap-lto --with-fpmath=sse
--enable-languages=c,c++,lto

'make all-stage1' has to be run several times in order to complete. there's no
errors, it just stops. it sometimes stops in different places depending on -j.

I sometimes get weird, difficult-to-reproduce bootstrap failures with -j8, and
this may be one of the root problems.

As mentioned in the thread, the same issue happens for make
configure-stage2-gcc, which requires at least two runs. I can file that in a
separate bug, upon request.

Both Ian and I had the same issue, and while I'm unsure about his build
environment, mine is Ubuntu 11.10/amd64.

[Bug middle-end/51220] gcc/libquadmath/math/nanq.c:9:20: ICE: in int_mode_ for_mode, at stor-layout.c:424

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin danglin at gcc dot gnu.org 2011-11-20 
00:38:54 UTC ---
Created attachment 25863
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25863
Preprocessed source

[Bug middle-end/51220] gcc/libquadmath/math/nanq.c:9:20: ICE: in int_mode_ for_mode, at stor-layout.c:424

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2011-11-20 
00:36:14 UTC ---
Breakpoint 1, int_mode_for_mode (mode=VOIDmode) at
../../gcc/gcc/stor-layout.c:424
424  gcc_unreachable ();
(gdb) bt
#0  int_mode_for_mode (mode=VOIDmode) at ../../gcc/gcc/stor-layout.c:424
#1  0x01d9183c in extract_bit_field_1 (str_rtx=0x7ae252b8, bitsize=16,
bitnum=0, unsignedp=1, packedp=0 '\000', target=0x0, mode=BLKmode,
tmode=SImode, fallback_p=1 '\001') at ../../gcc/gcc/expmed.c:1304
#2  0x01d92af0 in extract_bit_field (str_rtx=0x7ae252b8, bitsize=16, bitnum=0,
unsignedp=1, packedp=0 '\000', target=0x0, mode=BLKmode, tmode=SImode) at
../../gcc/gcc/expmed.c:1688
#3  0x01d8f3dc in store_bit_field_1 (str_rtx=0x7af068e0, bitsize=48, bitnum=16,
bitregion_start=0, bitregion_end=0, fieldmode=DImode, value=0x7ae252c0,
fallback_p=1 '\001') at ../../gcc/gcc/expmed.c:568
#4  0x01d900ec in store_bit_field (str_rtx=0x7af068e0, bitsize=48, bitnum=16,
bitregion_start=0, bitregion_end=0, fieldmode=VOIDmode, value=0x7ae252c0) at
../../gcc/gcc/expmed.c:852
#5  0x00a12d28 in store_field (target=0x7af068e0, bitsize=48, bitpos=16,
bitregion_start=0, bitregion_end=0, mode=VOIDmode, exp=0x7af13c00,
type=0x7af1a3c0, alias_set=0, nontemporal=0 '\000') at
../../gcc/gcc/expr.c:6432
#6  0x00a07bc8 in expand_assignment (to=0x7af15560, from=0x7af13c00,
nontemporal=0 '\000') at ../../gcc/gcc/expr.c:4823
#7  0x01a50a04 in expand_gimple_stmt_1 (stmt=0x7af16510) at
../../gcc/gcc/cfgexpand.c:2171
#8  0x01a50f64 in expand_gimple_stmt (stmt=0x7af16510) at
../../gcc/gcc/cfgexpand.c:2268
#9  0x01a5b328 in expand_gimple_basic_block (bb=0x7aec56c0) at
../../gcc/gcc/cfgexpand.c:4015
#10 0x01a5d9b4 in gimple_expand_cfg () at ../../gcc/gcc/cfgexpand.c:4523
#11 0x010653f0 in execute_one_pass (pass=0x40014050) at
../../gcc/gcc/passes.c:2074
#12 0x010656e0 in execute_pass_list (pass=0x40014050) at
../../gcc/gcc/passes.c:2129
#13 0x02c23d78 in tree_rest_of_compilation (fndecl=0x7af0f480) at
../../gcc/gcc/tree-optimize.c:420
#14 0x0072d0a4 in cgraph_expand_function (node=0x7aed6280) at
../../gcc/gcc/cgraphunit.c:1819
#15 0x0072d358 in cgraph_expand_all_functions () at
../../gcc/gcc/cgraphunit.c:1886
#16 0x0072e448 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:2199
#17 0x0072a9cc in cgraph_finalize_compilation_unit () at
../../gcc/gcc/cgraphunit.c:1327
#18 0x000d989c in c_write_global_declarations () at
../../gcc/gcc/c-decl.c:10023
#19 0x0122d13c in compile_file () at ../../gcc/gcc/toplev.c:581
#20 0x01230950 in do_compile () at ../../gcc/gcc/toplev.c:1931
#21 0x01230c3c in toplev_main (argc=14, argv=0x7eff052c) at
../../gcc/gcc/toplev.c:2007
#22 0x003fcda4 in main (argc=14, argv=0x7eff052c) at ../../gcc/gcc/main.c:36

[Bug middle-end/51220] gcc/libquadmath/math/nanq.c:9:20: ICE: in int_mode_ for_mode, at stor-layout.c:424

[danglin at gcc dot gnu.org]

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

--- Comment #3 from John David Anglin danglin at gcc dot gnu.org 2011-11-20 
00:45:14 UTC ---
Guessing this was introduced by:

2011-11-16  Andreas Krebbel  andreas.kreb...@de.ibm.com

PR middle-end/50325
* expmed.c (store_bit_field_1): Use extract_bit_field on big
endian targets if the source cannot be exactly covered by word
mode chunks.

[Bug middle-end/51233] New: [ipa-iterations] running multiple passes of early IPA on zlib produces more optimal code

[matt at use dot net]

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

 Bug #: 51233
   Summary: [ipa-iterations] running multiple passes of early IPA
on zlib produces more optimal code
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


Using current trunk, with Maxim's eipa-iterations patch. I modified the zlib
1.2.3.4 makefile (from Ubuntu 11.10's source package) as such for building on
my Ubuntu 11.10/amd64 system:

CC=gcc
CFLAGS=--param eipa-iterations=3 -flto -Ofast
SFLAGS=$(CFLAGS) -shared -fPIC
LDFLAGS=-flto -L. libz.a

And then built and tested the resulting minigzip utility both at the
macro-level (total runtime), and the micro-level (using callgrind's cache miss
and branch misprediction benchmarks). Macro level, when run a single 50MB file
on a ramdisk in single user mode shows minor improvements that may qualify as
noise. At the micro level, callgrind shows 0.4% fewer branch mispredictions,
and a dramatic decrease in data accesses (but a slight uptick in data cache
misses).

While there are some notable code differences between 2 and 3 iterations, they
don't appear to have an effect on the performance at the macro- or micro-level.

Given the relative simplicity of the code in the library, these additional
optimizations could possibly have been gotten within a single iteration.

[Bug bootstrap/39618] trunk revision 145459 - The configure of libstdc++-v3 hangs while checking for PCH support

[kurt at intricatesoftware dot com]

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

--- Comment #2 from Kurt Miller kurt at intricatesoftware dot com 2011-11-20 
03:29:51 UTC ---
Created attachment 25864
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25864
PCH Supoort for OpenBSD

Attached is a patch against gcc-4.6.2 which uses brk/sbrk for PCH support.
Since malloc uses mmap the heap is unused and at a fixed address (so long as
PIE is not enabled on gcc). I originally wrote this in 2008 for 4.2 and has
been in use

[Bug bootstrap/39618] trunk revision 145459 - The configure of libstdc++-v3 hangs while checking for PCH support

[kurt at intricatesoftware dot com]

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

Kurt Miller kurt at intricatesoftware dot com changed:

   What|Removed |Added

 CC||kurt at intricatesoftware
   ||dot com

--- Comment #3 from Kurt Miller kurt at intricatesoftware dot com 2011-11-20 
03:31:22 UTC ---
... since then without issues.

OpenBSD uses random mmap() return addresses. malloc uses mmap and the runtime
linker randomizes shared library load addresses, thus using mmap as a fixed
address is rather difficult on OpenBSD.

[Bug c++/51234] New: ambiguity in mangling function attribute

[s__nakayama at infoseek dot jp]

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

 Bug #: 51234
   Summary: ambiguity in mangling function attribute
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s__nakay...@infoseek.jp


// test
__attribute__ ((cdecl)) int foo(int);
__attribute__ ((stdcall)) int bar(int);

template class T 
int baz(T* func)
{
  return func(1);
}

int main()
{
  baz(foo);
  baz(bar);
  return 0;
}

//result
Error: symbol `__Z3bazIFiiEEiPT_' is already defined

[Bug c++/51194] [C++0x] ICE about template aliasing

[dodji at gcc dot gnu.org]

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

--- Comment #6 from Dodji Seketeli dodji at gcc dot gnu.org 2011-11-20 
07:10:31 UTC ---
Author: dodji
Date: Sun Nov 20 07:10:24 2011
New Revision: 181523

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181523
Log:
PR c++/51194 - ICE with invalid alias template

gcc/cp/

PR c++/51194
* pt.c (lookup_template_class_1): Go out early if the type of the
template is error_mark_node.

gcc/testsuite/

PR c++/51194
* g++.dg/cpp0x/alias-decl-15.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-15.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/51194] [C++0x] ICE about template aliasing

[dodji at gcc dot gnu.org]

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

Dodji Seketeli dodji at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Dodji Seketeli dodji at gcc dot gnu.org 2011-11-20 
07:11:48 UTC ---
This should be fixed in trunk (4.7) now.

[Bug boehm-gc/43682] libgcj don't support Win x64?

[aflyhorse at foxmail dot com]

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

--- Comment #4 from Chen Chen aflyhorse at foxmail dot com 2011-11-20 
07:18:28 UTC ---
I've noticed the gc-7.2alpha6.tar.gz have released. The Boehm-GC has been a
major obscure for the gcj port of Mingew64 I think... (embarrassed)
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/