[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  2012-01-27 
08:52:28 UTC ---
Created attachment 26476
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26476
pointer_map patch

local_specializations isn't GTY(()) marked at all and inserts GC TREE_LIST
nodes
into the hash table that aren't reachable otherwise.

The obvious fix I've tried first:
--- pt.c 2012-01-27 09:28:26.887327122 +0100
+++ pt.c 2012-01-27 09:45:01.787479945 +0100
@@ -79,7 +79,7 @@ static tree cur_stmt_expr;
 /* A map from local variable declarations in the body of the template
presently being instantiated to the corresponding instantiated
local variables.  */
-static htab_t local_specializations;
+static GTY ((param_is (union tree_node))) htab_t local_specializations;

 typedef struct GTY(()) spec_entry
 {

for some reason crashed elsewhere.  There is additionally the saving of the
local_specializations pointer, creating a new hash table and destroying +
restoring the pointer afterwards in two places.  Can we ggc_collect () only
when
there is at most one local_specializations array around (i.e. when
saved_local_specializations in whomever created the hash table is NULL)?

And the second question is, are the local specialization trees also reachable
from some other GC root except for local_specializations htab?  If they are
reachable from elsewhere, it would seem to me it would be much cheaper to use a
pointer_map as done in this patch (the testcase works then).

[Bug boehm-gc/48299] [4.7 Regression] FAIL: boehm-gc.c/thread_leak_test.c

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu.org

--- Comment #14 from Andreas Krebbel  2012-01-27 
08:58:33 UTC ---
Fails on s390x as well.

[Bug testsuite/52011] FAIL: gcc.dg/lto/trans-mem-* c_lto_trans-mem-*.o assemble, -flto -fgnu-tm in 32 bit mode

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-27
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-01-27 
09:00:01 UTC ---
Confirmed.

[Bug fortran/52012] [4.6/4.7 Regression] Wrong-code with realloc on assignment

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|4.7.0   |4.6.3

[Bug libstdc++/52015] New: std::to_string does not work under MinGW

[zeratul976 at hotmail dot com]

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

 Bug #: 52015
   Summary: std::to_string does not work under MinGW
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com


The std::to_string functions are guarded by
!defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF). MinGW defines this symbol as 1 in its
os_defines.h, with a comment pointing to:

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

That bug was marked as "resolved" over three years ago, but the fix was just to
add this guard, not to actually get the functions to work.

Can this be fixed so that the to_string functions work on MinGW?

[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #19 from Jakub Jelinek  2012-01-27 
09:15:13 UTC ---
Actually, on a closer look, I'd say local_specializations probably should be
just local and therefore not GCed and the bug is elsewhere:

--- gcc/cp/pt.c.jj 2012-01-26 09:22:19.0 +0100
+++ gcc/cp/pt.c 2012-01-27 10:10:38.566458106 +0100
@@ -9582,7 +9582,7 @@ tsubst_pack_expansion (tree t, tree args
 }
 }

-  if (saved_local_specializations)
+  if (need_local_specializations)
 {
   htab_delete (local_specializations);
   local_specializations = saved_local_specializations;

With this it passes two.  Of course this can be also combined with the
pointer_map conversion patch if desired (or that part can be queued for 4.8).

[Bug fortran/52012] [4.6/4.7 Regression] Wrong-code with realloc on assignment and RESHAPE w/ ORDER=

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

Summary|[4.6/4.7 Regression]|[4.6/4.7 Regression]
   |Wrong-code with realloc on  |Wrong-code with realloc on
   |assignment  |assignment and RESHAPE w/
   ||ORDER=

--- Comment #4 from Tobias Burnus  2012-01-27 
09:18:10 UTC ---
Up and including the RESHAPE call, everything looks fine. However, one then
updates the bounds as follows, which seems to fail.

If one does not use RESHAPE with the ORDER= argument, it works that the
"shape(a)" is used as argument to RESHAPE does not play a role.

  a.offset = 1;
  a.dim[0].lbound = 1;
  a.dim[0].ubound = a.dim[0].ubound + 1;
  a.offset = (a.dim[0].ubound - a.dim[0].lbound) + 1;
  a.dim[1].lbound = 1;
  a.dim[1].ubound = a.dim[1].ubound + 1;
  a.offset = (a.dim[1].ubound - a.dim[1].lbound) + 1;
  a.dim[2].lbound = 1;
  a.dim[2].ubound = a.dim[2].ubound + 1;
  a.offset = ~((a.dim[0].ubound - a.dim[0].lbound) + 1)
   + ~(a.dim[1].ubound - a.dim[1].lbound);

 * * *

Additionally, the realloc on assignment may sets the wrong bounds if no
(re)allocation is needed. From trans-expr.c's fcncall_realloc_result:

  /* Now reset the bounds from zero based to unity based.  */

That's wrong. The lower bounds are remain the same, unless the RHS has a
different shape. Then, the LHS is reallocated with a lower bound of
lbound(RHS).

Thus, one expects "7 9 / 1 3" for the program below, but gfortran has "1 3  / 
1 3". Using for the RHS external functions, other expressions and variables
correctly keep the bounds, if no realloc happens.


integer, allocatable :: a(:), b(:)
allocate(b(3))
b = [1,2,3]

allocate (a(7:9))
a = reshape( b, shape=[size(b)])
print *, lbound(a), ubound(a) ! Expected: 7 9

deallocate (a)
a = reshape( b, shape=[size(b)])
print *, lbound(a), ubound(a) ! Expected: 1 3
end

[Bug debug/52001] [4.7 Regression] Huge compile-time regression with var-tracking

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-01-27 
09:26:53 UTC ---
Author: jakub
Date: Fri Jan 27 09:26:48 2012
New Revision: 183608

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183608
Log:
PR debug/52001
* var-tracking.c (reverse_op): Don't add any reverse operation
if V already has any constant locations.

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

[Bug debug/52001] [4.7 Regression] Huge compile-time regression with var-tracking

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2012-01-27 
09:29:12 UTC ---
Fixed.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  2012-01-27 
09:33:11 UTC ---
(In reply to comment #13)
> Any code that explicitly calls __sync_* in
> libstdc++-v3 has introduced a performance regression.

But if it happens in code that is executed only rarely (e.g. the EH code will
be dominated by time spent in the unwinder, not any barriers), then it might
not be even measurable.  So I think we should first change atomicity.h and only
if you can come up with a testcase which shows a significant regression for the
libsupc++ or parallel bits, we should change those too at this point.  We are
in stage4.

[Bug fortran/51946] file compiles properly on IBM xlf compiler and Cray compiler

[pault at gcc dot gnu.org]

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

--- Comment #11 from Paul Thomas  2012-01-27 10:06:05 
UTC ---
Author: pault
Date: Fri Jan 27 10:05:56 2012
New Revision: 183613

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183613
Log:
2012-01-27  Paul Thomas  
Tobias Burnus 

PR fortran/48705
PR fortran/51870
PR fortran/51943
PR fortran/51946
* trans-array.c (gfc_array_init_size): Add two extra arguments
to convey the dynamic element size of a calls object and to
return the number of elements that have been allocated.
(gfc_array_allocate): Add the same arguments and use them to
call gfc_array_init_size.  Before the allocation dereference
the data pointer, if necessary. Set the allocated array to zero
if the class element size or expr3 are non-null.
* trans-expr.c (gfc_conv_class_to_class): Give this function
global scope.
(get_class_array_ref): New function.
(gfc_copy_class_to_class): New function.
* trans-array.h : Update prototype for gfc_array_allocate.
* trans-stmt.c (gfc_trans_allocate): For non-variable class
STATUS expressions extract the class object and the dynamic
element size. Use the latter to call gfc_array_allocate and
the former for setting the vptr and, via
gfc_copy_class_to_clasfc_cs, to copy to the allocated data.
* trans.h : Prototypes for gfc_get_class_array_ref,
gfc_copy_class_to_class and gfc_conv_class_to_class.


2012-01-27  Paul Thomas  
Tobias Burnus 

PR fortran/48705
* gfortran.dg/class_allocate_11.f03: New.

PR fortran/51870
PR fortran/51943
PR fortran/51946
* gfortran.dg/class_allocate_7.f03: New.
* gfortran.dg/class_allocate_8.f03: New.
* gfortran.dg/class_allocate_9.f03: New.
* gfortran.dg/class_allocate_10.f03: New.


Added:
trunk/gcc/testsuite/gfortran.dg/class_allocate_10.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_11.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_7.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_8.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_9.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-array.h
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog

[Bug fortran/51870] [OOP] ICE with ALLOCATE and SOURCE-expr function returning BT_CLASS

[pault at gcc dot gnu.org]

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

--- Comment #1 from Paul Thomas  2012-01-27 10:06:04 
UTC ---
Author: pault
Date: Fri Jan 27 10:05:56 2012
New Revision: 183613

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183613
Log:
2012-01-27  Paul Thomas  
Tobias Burnus 

PR fortran/48705
PR fortran/51870
PR fortran/51943
PR fortran/51946
* trans-array.c (gfc_array_init_size): Add two extra arguments
to convey the dynamic element size of a calls object and to
return the number of elements that have been allocated.
(gfc_array_allocate): Add the same arguments and use them to
call gfc_array_init_size.  Before the allocation dereference
the data pointer, if necessary. Set the allocated array to zero
if the class element size or expr3 are non-null.
* trans-expr.c (gfc_conv_class_to_class): Give this function
global scope.
(get_class_array_ref): New function.
(gfc_copy_class_to_class): New function.
* trans-array.h : Update prototype for gfc_array_allocate.
* trans-stmt.c (gfc_trans_allocate): For non-variable class
STATUS expressions extract the class object and the dynamic
element size. Use the latter to call gfc_array_allocate and
the former for setting the vptr and, via
gfc_copy_class_to_clasfc_cs, to copy to the allocated data.
* trans.h : Prototypes for gfc_get_class_array_ref,
gfc_copy_class_to_class and gfc_conv_class_to_class.


2012-01-27  Paul Thomas  
Tobias Burnus 

PR fortran/48705
* gfortran.dg/class_allocate_11.f03: New.

PR fortran/51870
PR fortran/51943
PR fortran/51946
* gfortran.dg/class_allocate_7.f03: New.
* gfortran.dg/class_allocate_8.f03: New.
* gfortran.dg/class_allocate_9.f03: New.
* gfortran.dg/class_allocate_10.f03: New.


Added:
trunk/gcc/testsuite/gfortran.dg/class_allocate_10.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_11.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_7.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_8.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_9.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-array.h
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog

[Bug fortran/51943] [OOP] ICE in conv_function_val

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  2012-01-27 10:06:05 
UTC ---
Author: pault
Date: Fri Jan 27 10:05:56 2012
New Revision: 183613

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183613
Log:
2012-01-27  Paul Thomas  
Tobias Burnus 

PR fortran/48705
PR fortran/51870
PR fortran/51943
PR fortran/51946
* trans-array.c (gfc_array_init_size): Add two extra arguments
to convey the dynamic element size of a calls object and to
return the number of elements that have been allocated.
(gfc_array_allocate): Add the same arguments and use them to
call gfc_array_init_size.  Before the allocation dereference
the data pointer, if necessary. Set the allocated array to zero
if the class element size or expr3 are non-null.
* trans-expr.c (gfc_conv_class_to_class): Give this function
global scope.
(get_class_array_ref): New function.
(gfc_copy_class_to_class): New function.
* trans-array.h : Update prototype for gfc_array_allocate.
* trans-stmt.c (gfc_trans_allocate): For non-variable class
STATUS expressions extract the class object and the dynamic
element size. Use the latter to call gfc_array_allocate and
the former for setting the vptr and, via
gfc_copy_class_to_clasfc_cs, to copy to the allocated data.
* trans.h : Prototypes for gfc_get_class_array_ref,
gfc_copy_class_to_class and gfc_conv_class_to_class.


2012-01-27  Paul Thomas  
Tobias Burnus 

PR fortran/48705
* gfortran.dg/class_allocate_11.f03: New.

PR fortran/51870
PR fortran/51943
PR fortran/51946
* gfortran.dg/class_allocate_7.f03: New.
* gfortran.dg/class_allocate_8.f03: New.
* gfortran.dg/class_allocate_9.f03: New.
* gfortran.dg/class_allocate_10.f03: New.


Added:
trunk/gcc/testsuite/gfortran.dg/class_allocate_10.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_11.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_7.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_8.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_9.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-array.h
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog

[Bug fortran/48705] [OOP] ALLOCATE with non-trivial SOURCE

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  2012-01-27 10:06:03 
UTC ---
Author: pault
Date: Fri Jan 27 10:05:56 2012
New Revision: 183613

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183613
Log:
2012-01-27  Paul Thomas  
Tobias Burnus 

PR fortran/48705
PR fortran/51870
PR fortran/51943
PR fortran/51946
* trans-array.c (gfc_array_init_size): Add two extra arguments
to convey the dynamic element size of a calls object and to
return the number of elements that have been allocated.
(gfc_array_allocate): Add the same arguments and use them to
call gfc_array_init_size.  Before the allocation dereference
the data pointer, if necessary. Set the allocated array to zero
if the class element size or expr3 are non-null.
* trans-expr.c (gfc_conv_class_to_class): Give this function
global scope.
(get_class_array_ref): New function.
(gfc_copy_class_to_class): New function.
* trans-array.h : Update prototype for gfc_array_allocate.
* trans-stmt.c (gfc_trans_allocate): For non-variable class
STATUS expressions extract the class object and the dynamic
element size. Use the latter to call gfc_array_allocate and
the former for setting the vptr and, via
gfc_copy_class_to_clasfc_cs, to copy to the allocated data.
* trans.h : Prototypes for gfc_get_class_array_ref,
gfc_copy_class_to_class and gfc_conv_class_to_class.


2012-01-27  Paul Thomas  
Tobias Burnus 

PR fortran/48705
* gfortran.dg/class_allocate_11.f03: New.

PR fortran/51870
PR fortran/51943
PR fortran/51946
* gfortran.dg/class_allocate_7.f03: New.
* gfortran.dg/class_allocate_8.f03: New.
* gfortran.dg/class_allocate_9.f03: New.
* gfortran.dg/class_allocate_10.f03: New.


Added:
trunk/gcc/testsuite/gfortran.dg/class_allocate_10.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_11.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_7.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_8.f03
trunk/gcc/testsuite/gfortran.dg/class_allocate_9.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-array.h
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog

[Bug c++/51910] [4.7 Regression] -frepo linking failure

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2012-01-27 
10:10:08 UTC ---
Created attachment 26477
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26477
gcc47-pr51910.patch

Untested fix.

[Bug fortran/48705] [OOP] ALLOCATE with non-trivial SOURCE

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #4 from Paul Thomas  2012-01-27 10:10:29 
UTC ---
Fixed on trunk

Thanks for the report

Paul

[Bug fortran/52016] New: [OOP] Polymorphism and elemental: missing diagnostic

[dominiq at lps dot ens.fr]

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

 Bug #: 52016
   Summary: [OOP] Polymorphism and elemental: missing diagnostic
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr


This PR is probably a duplicate of pr52013 with a fix before submission (see
http://gcc.gnu.org/ml/fortran/2012-01/msg00224.html ;-).

While investigating why the test in pr50981 comment #23 was yielding an ICE
even with the patch from http://gcc.gnu.org/ml/fortran/2012-01/msg00223.html ,
I reduced the origin of the ICE to the following test

type t
  integer :: a
end type t
  type(t), allocatable :: var1, var2(:)
  allocate(var1, var2(2))
  call sub_ctae(var2)
 if (any (var2%a /= 9)) call abort()

contains
  elemental subroutine sub_ctae(y)
class(t), intent(inout), optional :: y(:) ! <-- invalid and gives an ICE
!class(t), intent(inout), optional :: y ! <-- valid and works
if (present(y)) y%a = 9
if (present(y)) i = 7
  end subroutine sub_ctae
end

which gives

pr50981_4_red.f90: In function 'sub_ctae':
pr50981_4_red.f90:13:0: internal compiler error: in
gfc_conv_descriptor_data_get, at fortran/trans-array.c:147

for an unpatched r183306 and

pr50981_4_red.f90: In function 'MAIN__':
pr50981_4_red.f90:6:0: internal compiler error: in fold_convert_loc, at
fold-const.c:2016

for my patched tree.

[Bug fortran/51943] [OOP] ICE in conv_function_val

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||pault at gcc dot gnu.org
 Resolution||FIXED

--- Comment #5 from Paul Thomas  2012-01-27 10:11:42 
UTC ---
Fixed on trunk

Thanks for the report

Paul

[Bug fortran/51946] file compiles properly on IBM xlf compiler and Cray compiler

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||pault at gcc dot gnu.org
 Resolution||FIXED

--- Comment #12 from Paul Thomas  2012-01-27 10:13:27 
UTC ---
Fixed on trunk

Thanks for the report

Paul

[Bug fortran/51870] [OOP] ICE with ALLOCATE and SOURCE-expr function returning BT_CLASS

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||pault at gcc dot gnu.org
 Resolution||FIXED

--- Comment #2 from Paul Thomas  2012-01-27 10:15:08 
UTC ---
Fixed on trunk

Thanks for the report

Paul

[Bug c++/51910] [4.7 Regression] -frepo linking failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  2012-01-27 
10:17:25 UTC ---
Alternatively, we could temporarily (for the duration of do_tlink) #ifdef
HAVE_LD_DEMANGLE conditionally add putenv ("COLLECT_NO_DEMANGLE=1"); if getenv
("COLLECT_NO_DEMANGLE") is NULL and at the end of function remove it from the
environment again.

[Bug c/52017] New: internal compiler error: Segmentation fault in compiling Perl Tk on Cygwin

[marc.girod at gmail dot com]

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

 Bug #: 52017
   Summary: internal compiler error: Segmentation fault in
compiling Perl Tk on Cygwin
Classification: Unclassified
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gi...@gmail.com


Created attachment 26478
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26478
pre-processed file the compilation of which produces the error

Compiling Perl Tk-804.030 (from CPAN)

pTk> uname -srvp
CYGWIN_NT-6.0 1.7.9(0.237/5/3) 2011-03-29 10:10 unknown
pTk> gcc-4 --version
gcc-4 (GCC) 4.5.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
pTk> cygcheck -c gcc4-core
Cygwin Package Information
Package  VersionStatus
gcc4-core4.5.3-3OK


pTk> gcc-4 -c -save-temps  -I..  -I. -Ibitmaps   -DPERL_USE_SAFE_PUTENV
-U__STRICT_ANSI__ -g3 -fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include -DUSEIMPORTLIB -O3-DVERSION=\"804.03\" 
-DXS_VERSION=\"804.03\"  "-I/usr/lib/perl5/5.10/i686-cygwin/CORE"  -U_WIN32
-DWINARCH_X -Wall -Wno-implicit-int -Wno-comment -Wno-unused
-D__USE_FIXED_PROTOTYPES__ imgBMP.c
gcc-4: warning: -pipe ignored because -save-temps specified
imgBMP.c: In function ‘CommonReadBMP’:
imgBMP.c:242:2: warning: pointer targets in passing argument 2 of ‘ImgRead’
differ in signedness
imgInt.h:53:12: note: expected ‘char *’ but argument is of type ‘unsigned char
*’
imgBMP.c:256:3: warning: pointer targets in passing argument 2 of ‘ImgRead’
differ in signedness
imgInt.h:53:12: note: expected ‘char *’ but argument is of type ‘unsigned char
*’
imgBMP.c:264:3: warning: pointer targets in passing argument 2 of ‘ImgRead’
differ in signedness
imgInt.h:53:12: note: expected ‘char *’ but argument is of type ‘unsigned char
*’
imgBMP.c:278:3: warning: pointer targets in passing argument 2 of ‘ImgRead’
differ in signedness
imgInt.h:53:12: note: expected ‘char *’ but argument is of type ‘unsigned char
*’
imgBMP.c:297:3: warning: pointer targets in passing argument 2 of ‘ImgRead’
differ in signedness
imgInt.h:53:12: note: expected ‘char *’ but argument is of type ‘unsigned char
*’
imgBMP.c: In function ‘CommonWriteBMP’:
imgBMP.c:503:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/51990] ICE in copy_reference_ops_from_ref

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org 2012-01-27 10:38:32 UTC ---
Author: vries
Date: Fri Jan 27 10:38:27 2012
New Revision: 183614

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183614
Log:
2012-01-27  Tom de Vries  

PR tree-optimization/51990
* tree-ssa-sccvn.c (copy_reference_ops_from_ref): Handle WITH_SIZE_EXPR.
* tree-ssa-pre.c (create_component_ref_by_pieces_1): Same.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-pre.c
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/51990] ICE in copy_reference_ops_from_ref

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org 2012-01-27 10:38:38 UTC ---
Author: vries
Date: Fri Jan 27 10:38:34 2012
New Revision: 183615

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183615
Log:
2012-01-27  Tom de Vries  

PR tree-optimization/51990
* gcc.dg/pr51990.c: New test.
* gcc.dg/pr51990-2.c: Same.

Added:
trunk/gcc/testsuite/gcc.dg/pr51990-2.c
trunk/gcc/testsuite/gcc.dg/pr51990.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/52012] [4.6/4.7 Regression] Wrong-code with realloc on assignment and RESHAPE w/ ORDER=

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug libstdc++/52015] std::to_string does not work under MinGW

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #1 from Paolo Carlini  2012-01-27 
10:47:04 UTC ---
Kai, is this fixed for 4.7.0?

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  2012-01-27 
10:48:34 UTC ---
Thus Ed, is the fix already obvious to you? Or should I look into this? Thanks.

[Bug fortran/52016] [OOP] Polymorphism and elemental: missing diagnostic

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2012-01-27 
10:51:18 UTC ---
(In reply to comment #0)
> This PR is probably a duplicate of pr52013

No, that's a separate issue: That test case will also fail when this PR is
fixed. (Currently, it fails because of this PR *and* due to another reason.)


> with a fix before submission
>  http://gcc.gnu.org/ml/fortran/2012-01/msg00224.html

Indeed, that's the patch for this issue.

[Bug testsuite/52011] [4.7 Regression] FAIL: gcc.dg/lto/trans-mem-* c_lto_trans-mem-*.o assemble, -flto -fgnu-tm in 32 bit mode

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|FAIL:   |[4.7 Regression] FAIL:
   |gcc.dg/lto/trans-mem-*  |gcc.dg/lto/trans-mem-*
   |c_lto_trans-mem-*.o |c_lto_trans-mem-*.o
   |assemble, -flto -fgnu-tm in |assemble, -flto -fgnu-tm in
   |32 bit mode |32 bit mode

--- Comment #2 from Dominique d'Humieres  2012-01-27 
10:53:38 UTC ---
While gcc.dg/lto/trans-mem-4 is new in revision 183537, the other tests have
only been modified, then I think this pr is a regression.

[Bug middle-end/51959] [4.7 Regression] ICE in set_mem_alias_set, at emit-rtl.c:1884

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2012-01-27 
10:54:55 UTC ---
Author: rguenth
Date: Fri Jan 27 10:54:51 2012
New Revision: 183616

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183616
Log:
2012-01-27  Richard Guenther  

PR middle-end/51959
* expr.c (store_field): Use the alias-set of the scratch memory
for storing to it.

* g++.dg/torture/pr51959.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr51959.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/51959] [4.7 Regression] ICE in set_mem_alias_set, at emit-rtl.c:1884

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Richard Guenther  2012-01-27 
10:58:51 UTC ---
Fixed.

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-01-27
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
 Ever Confirmed|0   |1

--- Comment #3 from Paolo Carlini  2012-01-27 
11:02:46 UTC ---
Thus looks like we have a very very long standing bug in the implementation of
Schrage's algorithm, which nobody noticed so far. Let's fix it.

[Bug c++/51910] [4.7 Regression] -frepo linking failure

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  2012-01-27 
11:05:04 UTC ---
Created attachment 26479
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26479
gcc47-pr51910.patch

The alternative patch.  I like the first patch more, because it will work even
with -Wl,--demangle.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  2012-01-27 
11:17:35 UTC ---
Created attachment 26480
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26480
gcc47-pr51798.patch

This is one of the few remaining P1s, so in order to speed this up, is this
patch what we are considering now?  If yes, I'll go ahead and test it on
i?86/x86_64/ppc/ppc64/s390/s390x.

[Bug testsuite/52011] [4.7 Regression] FAIL: gcc.dg/lto/trans-mem-* c_lto_trans-mem-*.o assemble, -flto -fgnu-tm in 32 bit mode

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug target/52017] internal compiler error: Segmentation fault in compiling Perl Tk on Cygwin

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target||cygwin
  Component|c   |target

--- Comment #1 from Richard Guenther  2012-01-27 
11:23:27 UTC ---
Works on x86_64-linux.

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2012-01-27 
11:32:10 UTC ---
The problem is that isn't true that __r < __q, thus one of the preconditions
for the algorithm (as explained in eg, Numerical Recipes) is violated.

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|i386-pc-solaris2.1[01], |i386-pc-solaris2.1[01],
   |mips-sgi-irix6.5|mips-sgi-irix6.5,
   ||sparc-sun-solaris2*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-27
   Host|i386-pc-solaris2.1[01], |i386-pc-solaris2.1[01],
   |mips-sgi-irix6.5|mips-sgi-irix6.5,
   ||sparc-sun-solaris2*
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1
  Build|i386-pc-solaris2.1[01], |i386-pc-solaris2.1[01],
   |mips-sgi-irix6.5|mips-sgi-irix6.5,
   ||sparc-sun-solaris2*

--- Comment #1 from Rainer Orth  2012-01-27 11:37:09 UTC 
---
Ian has now provided a detailed investigation of the problem:

  http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00918.html

For the 64-bit Solaris/x86 case, Solaris engineering has identified and fixed
the bug:

7133114 fsbase (%fs:0) is not set properly after makecontext()/setcontext()

The fix will be in Solaris 11 Update 1, and I've requested a Solaris 10
Update 10 backport, which will be delivered as a patch on top of patch
144501-19.

  Rainer

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2012-01-27 
11:41:28 UTC ---
Roughly, we have to fix either __calc or the generator itself to work fine also
when isn't true that __a << __m (which is the "normal" situation)

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-01-27 11:45:17 UTC ---
I've also had a look at the Solaris/SPARC failures, which are unrelated
to the 64-bit Solaris/x86 problem previously identified.  I could trace
it to the most trivial testcase with channels:

package main

func send(ch chan<- int) {
ch <- 1
}

func main() {
ch := make(chan int)
go send(ch)
recv := <-ch
if recv != 1 {
panic (recv)
}
print(recv, "\n")
}

On Solaris/SPARC (both 32 and 64-bit), this fails with

panic: 0

I've still to closer investigate why this happens.  I suspect that this
is also the cause of the IRIX failures (a libgo build is currently
running).  Maybe this is just and endianess problem: it's interesting
that 32-bit Solaris/x86 works (little-endian), while 32-bit
Solaris/SPARC and IRIX (both big-endian) don't.

Rainer

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|paolo.carlini at oracle dot |marc.glisse at normalesup
   |com |dot org

--- Comment #6 from Paolo Carlini  2012-01-27 
11:45:29 UTC ---
Marc, can you see a "quick and dirty" (ie, suited for 4.7 too) way to fix this?

[Bug bootstrap/52007] configure: error: installation or configuration problem: C compiler cannot create executables

[chilakaravikumar at yahoo dot co.in]

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

--- Comment #8 from chilaka  2012-01-27 
12:17:44 UTC ---

I managed to generate a Makefile in objdir then issued a make command from that
directory. After a 10 minute compilation it ended with the below error.

checking for suffix of object files... configure: error: cannot compute suffix
of object files: cannot compile

Note: I don't have any IA64 files/binaries on my host machine where this cross
compilation is going, so I have not setup where to look for target files. Is
this is the reason for this failure. 

[root@localhost objdir]# uname -a
Linux localhost.localdomain 2.6.25-14.fc9.i686 #1 SMP Thu May 1 06:28:41 EDT
2008 i686 i686 i386 GNU/Linux
[root@localhost objdir]# pwd
/opt/objdir
[root@localhost objdir]# ../gcc-4.3.0/configure --prefix=/opt/ia64gcc  
--target=ia64-redhat-linux  
[root@localhost objdir]# make 
:
make[2]: Leaving directory `/opt/objdir/gcc'
Checking multilib configuration for libgcc...
mkdir -p -- ia64-redhat-linux/libgcc
Configuring in ia64-redhat-linux/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking build system type... i686-pc-linux-gnu
checking host system type... ia64-redhat-linux-gnu
checking for ia64-redhat-linux-ar... ia64-redhat-linux-ar
checking for ia64-redhat-linux-lipo... ia64-redhat-linux-lipo
checking for ia64-redhat-linux-nm... /opt/objdir/./gcc/nm
checking for ia64-redhat-linux-ranlib... ia64-redhat-linux-ranlib
checking for ia64-redhat-linux-strip... ia64-redhat-linux-strip
checking whether ln -s works... yes
checking for ia64-redhat-linux-gcc... /opt/objdir/./gcc/xgcc
-B/opt/objdir/./gcc/ -B/opt/ia64gcc/ia64-redhat-linux/bin/
-B/opt/ia64gcc/ia64-redhat-linux/lib/ -isystem
/opt/ia64gcc/ia64-redhat-linux/include -isystem
/opt/ia64gcc/ia64-redhat-linux/sys-include
checking for suffix of object files... configure: error: cannot compute suffix
of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory `/opt/objdir'
make: *** [all] Error 2

[root@localhost objdir]# tail -40  config.log
sharedstatedir='${prefix}/com'
stage1_cflags='-g -fkeep-inline-functions'
stage1_checking='--enable-checking=yes,types'
stage1_languages='c'
stage2_werror_flag=''
sysconfdir='${prefix}/etc'
target='ia64-redhat-linux-gnu'
target_alias='ia64-redhat-linux'
target_configargs='--cache-file=./config.cache --enable-multilib
--with-cross-host=i686-pc-linux-gnu '--prefix=/opt/ia64gcc'
'--enable-languages=c,c++,fortran,java,objc'
--program-transform-name='s,^,ia64-redhat-linux-,''
target_cpu='ia64'
target_noncanonical='ia64-redhat-linux'
target_os='linux-gnu'
target_subdir='ia64-redhat-linux'
target_vendor='redhat'
tooldir='${exec_prefix}/ia64-redhat-linux'

## - ##
## Output files. ##
## - ##

alphaieee_frag='/dev/null'
host_makefile_frag='../gcc-4.3.0/config/mh-x86omitfp'
ospace_frag='/dev/null'
serialization_dependencies='serdep.tmp'
target_makefile_frag='../gcc-4.3.0/config/mt-gnu'

## --- ##
## confdefs.h. ##
## --- ##

#define PACKAGE_BUGREPORT ""
#define PACKAGE_NAME ""
#define PACKAGE_STRING ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#endif
#ifdef __cplusplus
extern "C" void exit (int) throw ();

configure: exit 0

[Bug c++/52018] New: GCC refuses to accept a disambiguation statement

[piotr.wyderski at gmail dot com]

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

 Bug #: 52018
   Summary: GCC refuses to accept a disambiguation statement
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: piotr.wyder...@gmail.com


The following code:

class string {};

struct test {

enum {

   string
};

void g(class string&& s) const {}

template  void mth(TA&&... args) const {

g(class string{std::forward(args)...});
}
};

compiled using GCC 4.6.1 and 4.6.2 fails:

$ g++ -std=gnu++0x -c test/test.cpp
test/test.cpp: In member function ‘void test::mth(TA&& ...) const’:
test/test.cpp:15:11: error: expected primary-expression before ‘class’

The Holy Book says:

3.4.4: "An elaborated-type-specifier (7.1.6.3) may be used to refer to a
previously declared class-name or enum-name
even though the name has been hidden by a non-type declaration (3.3.10)."

and the problematic statement:

g(class string{std::forward(args)...});

looks like a reference.

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  2012-01-27 
12:35:28 UTC ---
As a matter of fact, I don't see why here (and elsewhere, eg generate) we have
to use the Schrage trick to avoid integer overflow: we know that the integers
are unsigned and I don't see anything about that in the Standard.

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  2012-01-27 
12:47:10 UTC ---
Eg:

Index: random.h
===
--- random.h(revision 183615)
+++ random.h(working copy)
@@ -263,7 +263,7 @@
   result_type
   operator()()
   {
-_M_x = __detail::__mod<_UIntType, __m, __a, __c>(_M_x);
+_M_x = (__a * _M_x + __c) % __m;
 return _M_x;
   }

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[amacleod at redhat dot com]

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

--- Comment #19 from Andrew Macleod  2012-01-27 
12:49:27 UTC ---
(In reply to comment #17)
> (In reply to comment #13)
> > Any code that explicitly calls __sync_* in
> > libstdc++-v3 has introduced a performance regression.
> 
> But if it happens in code that is executed only rarely (e.g. the EH code will
> be dominated by time spent in the unwinder, not any barriers), then it might
> not be even measurable.  So I think we should first change atomicity.h and 
> only
> if you can come up with a testcase which shows a significant regression for 
> the
> libsupc++ or parallel bits, we should change those too at this point.  We are
> in stage4.

Precisely my thoughts... Its not a regression if it isn't measurable, and we
want to change as little as we possibly can at this stage.  The patch is what I
was thinking.  

I presume it generates the same code power use to get?

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  2012-01-27 12:52:29 UTC ---
The chan.go testcase also fails on 32-bit IRIX, but in a different way:

> ./chan.x
panic: runtime error: invalid memory address or nil pointer dereference

Running it under gdb, I find:

Program received signal SIGSEGV, Segmentation fault.
runtime_mcall (pfn=0x823198 )
at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:283
283 if (g == nil || !g->fromgogo) {
(gdb) where
#0  runtime_mcall (pfn=0x823198 )
at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:283
#1  0x0081b9e0 in runtime_chanrecv (t=, c=0x2030b000, 
ep=0x20102f60 "", selected=0x0, received=0x0)
at /vol/gcc/src/hg/trunk/local/libgo/runtime/chan.c:333
#2  0x0081bae0 in __go_receive_small (t=, c=)
at /vol/gcc/src/hg/trunk/local/libgo/runtime/chan.c:432
#3  0x10002418 in main.main () at /vol/gcc/src/doc/bugs/chan.go:10
#4  0x00822994 in runtime_main ()
at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:371
#5  0x00823960 in kickoff ()
at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:237
#6  0x0faee6d0 in _sethostname () from /usr/lib32/libc.so.1
#7  0x008225f4 in runtime_mcall (pfn=0x823198 )
at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:281
#8  0x in ?? ()

It may be an issue that IRIX is an emutls target.

On 64-bit IRIX, I get

> ./chan.x64
panic: 0

as on Solaris/SPARC.

Rainer

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[marc.glisse at normalesup dot org]

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

--- Comment #9 from Marc Glisse  2012-01-27 
12:53:38 UTC ---
(In reply to comment #6)
> Marc, can you see a "quick and dirty" (ie, suited for 4.7 too) way to fix 
> this?

Note that I am not a specialist.
1) add an assertion "not implemented yet, try a smaller constant"
2) if you know how to multiply by small a, you can decompose large a into
a1*a2+a3 and perform the operations separately (variants might make sense,
including using powers of 2 and also splitting x)
3) do the double precision operation. longlong.h contains generic code for that
(but beware UDIV_NEEDS_NORMALIZATION).

About comment #7, if that's how you interpret it, it may be worth opening a DR.
I believe the formula has to be interpreted with mathematical, arbitrary size
integers (although of course you can optimize when m*m fits in _Tp).

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini  2012-01-27 
13:01:23 UTC ---
Really, I don't think the intent here is involving arbitrary size integers.
This stuff must be quick, and all the integers are unsigned. I don't think we
have here something like the templates in time, really.

[Bug fortran/52016] [OOP] Polymorphism and elemental: missing diagnostic

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2012-01-27 
13:03:05 UTC ---
Author: burnus
Date: Fri Jan 27 13:02:54 2012
New Revision: 183620

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183620
Log:
2012-01-27  Tobias Burnus  

PR fortran/52016
* resolve.c (resolve_formal_arglist): Fix elemental
constraint checks for polymorphic dummies.

2012-01-27  Tobias Burnus  

PR fortran/52016
* gfortran.dg/elemental_args_check_5.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/elemental_args_check_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/52016] [OOP] Polymorphism and elemental: missing diagnostic

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Tobias Burnus  2012-01-27 
13:03:44 UTC ---
FIXED on the trunk (4.7).

Thanks for the bug report!

[Bug tree-optimization/51528] [4.6/4.7 Regression] SRA should not create BOOLEAN_TYPE replacements

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 AssignedTo|jamborm at gcc dot gnu.org  |rguenth at gcc dot gnu.org

--- Comment #3 from Richard Guenther  2012-01-27 
13:05:40 UTC ---
SRA creates, for

struct S { int i; int j; };

struct S bar (struct S);

struct S foo1 (int i)
{
  struct S x;
  x.i = i;
  x = bar (x);
  /* LHS disqualified, RHS partially scalarized.  */
  return x;
}

for the aggregate copy to the return slot

  x$i_8 = x.i;
  D.1720 = x;
  D.1720.i = x$i_8;

but that's needlessly complicated as it should just have created

  x.i = x$i_8;
  D.1720 = x;

or for the similar case

struct S g;
struct S foo3 (int i)
{
  struct S x;
  /* RHS disqualified, LHS partially scalarized.  */
  x = g;
  x.i = i;
  x = bar (x);
  return x;
}

it creates

  x = g;
  x$i_4 = g.i;
  x$i_8 = i_1(D);
  x.i = x$i_8;

which is just a complicated from of

  x = g;
  x$i_4 = x.i;

a sub-case which it handles fine when handling calls!

  x = bar (x);
  x$i_10 = x.i;


That copy-in-out game to the unscalarized parts causes this regression.

[Bug fortran/51953] [F2008] Allow multiple allocate-objects in ALLOCATE with SOURCE=

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2012-01-27 
13:06:19 UTC ---
Author: burnus
Date: Fri Jan 27 13:06:13 2012
New Revision: 183621

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183621
Log:
2012-01-27  Tobias Burnus  

PR fortran/51953
* match.c (gfc_match_allocate): Allow more than allocate
object with SOURCE=.

2012-01-27  Tobias Burnus  

PR fortran/51953
* gfortran.dg/allocate_alloc_opt_13.f90: New.
* gfortran.dg/allocate_alloc_opt_4.f90: Add -std=f2003
and change dg-error string.


Added:
trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_13.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/allocate_alloc_opt_4.f90

[Bug fortran/51953] [F2008] Allow multiple allocate-objects in ALLOCATE with SOURCE=

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||burnus at gcc dot gnu.org
 Resolution||FIXED

--- Comment #2 from Tobias Burnus  2012-01-27 
13:06:58 UTC ---
FIXED on the trunk (4.7).

[Bug fortran/51970] [OOP] gimplification failed for polymorphic MOVE_ALLOC

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2012-01-27 
13:08:58 UTC ---
Author: burnus
Date: Fri Jan 27 13:08:52 2012
New Revision: 183622

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183622
Log:
2012-01-27  Tobias Burnus  

PR fortran/51970
PR fortran/51977
* primary.c (gfc_match_varspec. gfc_match_rvalue): Set
handle array spec for BT_CLASS.
* expr.c (gfc_get_variable_expr, gfc_lval_expr_from_sym)
* frontend-passes.c (create_var): Ditto.
* resolve.c (resolve_actual_arglist, resolve_assoc_var): Ditto.
* trans-decl.c (gfc_trans_deferred_vars): Use class_pointer
instead of attr.pointer.
(gfc_generate_function_code): Use CLASS_DATA (sym) for BT_CLASS.
* trans-intrinsic.c (conv_intrinsic_move_alloc): Move assert.
* trans-stmt.c (trans_associate_var): Ask for the descriptor.

2012-01-27  Tobias Burnus  

PR fortran/51970
PR fortran/51977
* gfortran.dg/move_alloc_13.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/move_alloc_13.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/51970] [OOP] gimplification failed for polymorphic MOVE_ALLOC

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Tobias Burnus  2012-01-27 
13:09:26 UTC ---
FIXED on the trunk (4.7).

[Bug fortran/51977] [OOP] MOVE_ALLOC: Bogus "must have the same rank 0/1" for same-rank arrays

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2012-01-27 
13:08:58 UTC ---
Author: burnus
Date: Fri Jan 27 13:08:52 2012
New Revision: 183622

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183622
Log:
2012-01-27  Tobias Burnus  

PR fortran/51970
PR fortran/51977
* primary.c (gfc_match_varspec. gfc_match_rvalue): Set
handle array spec for BT_CLASS.
* expr.c (gfc_get_variable_expr, gfc_lval_expr_from_sym)
* frontend-passes.c (create_var): Ditto.
* resolve.c (resolve_actual_arglist, resolve_assoc_var): Ditto.
* trans-decl.c (gfc_trans_deferred_vars): Use class_pointer
instead of attr.pointer.
(gfc_generate_function_code): Use CLASS_DATA (sym) for BT_CLASS.
* trans-intrinsic.c (conv_intrinsic_move_alloc): Move assert.
* trans-stmt.c (trans_associate_var): Ask for the descriptor.

2012-01-27  Tobias Burnus  

PR fortran/51970
PR fortran/51977
* gfortran.dg/move_alloc_13.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/move_alloc_13.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/51977] [OOP] MOVE_ALLOC: Bogus "must have the same rank 0/1" for same-rank arrays

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Tobias Burnus  2012-01-27 
13:10:00 UTC ---
FIXED on the trunk (4.7).

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[marc.glisse at normalesup dot org]

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

--- Comment #11 from Marc Glisse  2012-01-27 
13:12:05 UTC ---
(In reply to comment #10)
> Really, I don't think the intent here is involving arbitrary size integers.
> This stuff must be quick, and all the integers are unsigned. I don't think we
> have here something like the templates in time, really.

But if we round first modulo 2^64 then modulo m, it isn't the linear
congruential algorithm it is supposed to be. I think I'd prefer for the
compiler to reject the code when used with values that would make the generator
too slow.

Let me ask on the reflector, to be sure.

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini  2012-01-27 
13:17:22 UTC ---
I see. Before asking: 26.5/4 says that "all descriptions of calculations in
this subclause use mathematical real numbers". Thus should we use floats?!?

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[paolo.carlini at oracle dot com]

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

--- Comment #13 from Paolo Carlini  2012-01-27 
13:23:01 UTC ---
Note that besides the case of the linear_congruential (where we could
definitely static_assert, I don't consider such uses really important in
practice, given also that generators much better from the statistical point of
view are highly recommended (for example the last Numeric Recipes recommends
avoiding linear congruential and doesn't provide anymore code for it), we have
also to resolve the problem with the implementation of generate, where an
algorithm is described in detail involving multiplications and currently we
also use __mod for unsafe arguments.

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[marc.glisse at normalesup dot org]

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

--- Comment #14 from Marc Glisse  2012-01-27 
13:35:29 UTC ---
(In reply to comment #12)
> I see. Before asking: 26.5/4 says that "all descriptions of calculations in
> this subclause use mathematical real numbers".

Ok, no need to ask then.

> Thus should we use floats?!?

Actually, using double is a common trick (that wouldn't be sufficient here):
compute (double)a*(double)x/(double)m and round it to an integer q; then you
can compute a*x-m*q modulo 2^64.

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[paolo.carlini at oracle dot com]

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

--- Comment #15 from Paolo Carlini  2012-01-27 
13:42:27 UTC ---
I'm not sure to understand: is using floating point quantities the way to go or
not? I'm particularly worried by generate, as I said, much more than linear
congruential. Note we can also use long double.

[Bug middle-end/51389] GCC uses up to 75GB of virtual memory

[abel at gcc dot gnu.org]

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

--- Comment #4 from Andrey Belevantsev  2012-01-27 
13:47:45 UTC ---
Author: abel
Date: Fri Jan 27 13:47:41 2012
New Revision: 183624

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183624
Log:
PR middle-end/51389
* Makefile.in (tree-data-ref.o): Depend on $(PARAMS_H).
* tree-data-ref.h (find_data_references_in_loop): Remove declaration.
* tree-data-ref.c (find_data_references_in_loop): Make static.
(compute_all_dependences): Change return type to bool.  Bail out
for too many datarefs in a loop.  Move the hunk resetting the data
dependences vector from ...
(compute_data_dependences_for_loop): ... here.  Account for
compute_all_dependences returning false.
(compute_data_dependences_for_bb): Likewise.
* params.def (PARAM_LOOP_MAX_DATAREFS_FOR_DATADEPS): New param.
* doc/invoke.texi (loop-max-datarefs-for-datadeps): Document it.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/doc/invoke.texi
trunk/gcc/params.def
trunk/gcc/tree-data-ref.c
trunk/gcc/tree-data-ref.h

[Bug middle-end/51389] GCC uses up to 75GB of virtual memory

[abel at gcc dot gnu.org]

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

Andrey Belevantsev  changed:

   What|Removed |Added

  Known to work||4.7.0

--- Comment #5 from Andrey Belevantsev  2012-01-27 
13:49:21 UTC ---
Fixed for 4.7.0.

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[paolo.carlini at oracle dot com]

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

--- Comment #16 from Paolo Carlini  2012-01-27 
13:54:44 UTC ---
Uhm, in the case of generate, however, "each operation is to be carried out
modulo 2^32", thus I guess it's safe to not use __mod at all for the
multiplication.

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[marc.glisse at normalesup dot org]

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

--- Comment #17 from Marc Glisse  2012-01-27 
13:57:43 UTC ---
(In reply to comment #15)
> I'm not sure to understand: is using floating point quantities the way to go 
> or
> not?
> Note we can also use long double.

I don't think there is any guarantee that long double has enough precision.

> I'm particularly worried by generate, as I said, much more than linear
> congruential.

Then it may be safer to implement a slow but exact fallback implementation of
_Mod.

Sorry, I can't look at it in more details right now...

[Bug fortran/52016] [OOP] Polymorphism and elemental: missing diagnostic

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2012-01-27 
13:59:10 UTC ---
Author: burnus
Date: Fri Jan 27 13:59:04 2012
New Revision: 183625

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183625
Log:
2012-01-27  Tobias Burnus  

PR fortran/52016
* resolve.c (resolve_formal_arglist): Fix elemental
constraint checks for polymorphic dummies also for
pointers.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c

[Bug libstdc++/51795] linear_congruential_engine doesn't work correctly

[paolo.carlini at oracle dot com]

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

--- Comment #18 from Paolo Carlini  2012-01-27 
14:04:28 UTC ---
Okay, thanks, but for generate we are 'lucky'. Thus, for 4.7 I'm going to add
the static_assert in linear_congruential and tweak generate to not use __mod at
all. Then we'll see.

[Bug rtl-optimization/48133] [4.5/4.6/4.7 Regression] ICE: in get_loop_body, at cfgloop.c:831 with -O -funroll-loops -fthread-jumps -fno-tree-ch

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2012-01-27 
14:07:35 UTC ---
Honza, ping?

[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.

[eric.batut at allegorithmic dot com]

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

Eric Batut  changed:

   What|Removed |Added

 CC||eric.batut at allegorithmic
   ||dot com, Greta.Yorsh at arm
   ||dot com

--- Comment #8 from Eric Batut  2012-01-27 
14:11:34 UTC ---
Any chance of seeing the work on this restart ?

I found this bug while looking for something that would help (I raised bug
51980 for the same kind of issue, still seen on trunk), but the patch attached
to this bug does not solve the issue for code that is rich with zip/uzp/trn
intrinsics.

This is a major limitation of arm-gcc with respect to performance-critical Neon
code in my opinion.

[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq

[eric.batut at allegorithmic dot com]

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

Eric Batut  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #2 from Eric Batut  2012-01-27 
14:13:08 UTC ---
Adding the usual suspects for ARM-related bugs.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

--- Comment #20 from David Edelsohn  2012-01-27 
14:27:25 UTC ---
Jonathan,

Your explanation in comment #16 does not fully explain the design of
libstdc++-v3.  If the __sync_* intrinsics provide the complete abstraction for
CAS, what is the purpose of the custom implementations of atomicity.h in
libstdc++-v3/config/{cpu,os}/* ?  One should not need those overrides if
__sync_* provides sufficient abstraction.

Jakub,

The patch is incomplete because it should update
src/libstdc++-v3/config/cpu/generic/atomicity_builtins/atomicity.h as well.

[Bug tree-optimization/52019] New: [4.7 Regression] tree-ssa/ipa-split-5.c fails with -fno-tree-sra because of CLOBBERS

[rguenth at gcc dot gnu.org]

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

 Bug #: 52019
   Summary: [4.7 Regression] tree-ssa/ipa-split-5.c fails with
-fno-tree-sra because of CLOBBERS
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org


IPA split is confused by the stale clobber in BB 5:

:
  D.1717_2 = a_1(D) != 0;
  D.1718_3 = (long int) D.1717_2;
  D.1719_4 = __builtin_expect (D.1718_3, 1);
  if (D.1719_4 != 0)
goto ;
  else
goto ;

:
  D.1722.a = 0;
  D.1722.b = 0;
  goto ;

:
  retval = make_me_big (a_1(D));
  retval = make_me_big (a_1(D));
  retval = make_me_big (a_1(D));
  retval = make_me_big (a_1(D));
  retval = make_me_big (a_1(D));
  retval = make_me_big (a_1(D));
  D.1722 = retval;
  retval ={v} {CLOBBER};

:
  retval ={v} {CLOBBER};
  return D.1722;


As you can see 'retval' is completely unused on the path to BB5.  We
should arrange for them to be removed in such cases, maybe by DCE.

This blocks SRA from not "scalarizing" clobbers, which it does like:

:
  retval$a_21 = 0;
  retval$b_22 = 0;
  return D.1722;

which is sort-of bogus anyway.

I'll fixup SRA, but for SRA to do this trick there needs to be stmts
that touch retval in any meaningful way, so a clobber that is stale
before SRA will stay so.

[Bug regression/52020] New: ICE in immed_double_const, at emit-rtl.c:544

[Greta.Yorsh at arm dot com]

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

 Bug #: 52020
   Summary: ICE in immed_double_const, at emit-rtl.c:544
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: greta.yo...@arm.com
CC: m...@suse.de, ram...@gcc.gnu.org
Target: arm-none-eabi


Regression PASS->FAIL: gcc.target/arm/pr48183.c (internal compiler error) on
arm-none-eabi. 

Revision that introduced the problem: r183566, patch described here:
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01387.html

./cc1 -quiet
/work/local-checkouts/main/gcc-fsf/gcc/testsuite/gcc.target/arm/pr48183.c -O 
-o /work/tmp/pr48183.s -mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=neon -iprefix
/work/builds/a15-jan/install/lib/gcc/arm-none-eabi/4.7.0/ -g

/work/local-checkouts/main/gcc-fsf/gcc/testsuite/gcc.target/arm/pr48183.c: In
function 'move_16bit_to_32bit':
/work/local-checkouts/main/gcc-fsf/gcc/testsuite/gcc.target/arm/pr48183.c:10:6:
internal compiler error: in immed_double_const, at emit-rtl.c:544

(gdb) info stack
#0  fancy_abort (file=0xe15150
"/work/local-checkouts/main/gcc-fsf/gcc/emit-rtl.c", line=544,
function=0xe15ff0 "immed_double_const") at
/work/local-checkouts/main/gcc-fsf/gcc/diagnostic.c:898
#1  0x00648f5c in immed_double_const (i0=0, i1=,
mode=OImode) at /work/local-checkouts/main/gcc-fsf/gcc/emit-rtl.c:544
#2  0x0066d8cb in expand_expr_real_1 (exp=0x770d8fa0, target=0x0,
tmode=, modifier=, alt_rtl=0x0) at
/work/local-checkouts/main/gcc-fsf/gcc/expr.c:9118
#3  0x005aa46d in expand_expr (exp=0x770d8fa0) at
/work/local-checkouts/main/gcc-fsf/gcc/expr.h:442
#4  expand_debug_expr (exp=0x770d8fa0) at
/work/local-checkouts/main/gcc-fsf/gcc/cfgexpand.c:2699
#5  0x005b13ca in expand_debug_locations () at
/work/local-checkouts/main/gcc-fsf/gcc/cfgexpand.c:3668
#6  gimple_expand_cfg () at
/work/local-checkouts/main/gcc-fsf/gcc/cfgexpand.c:4528
#7  0x007f0d29 in execute_one_pass (pass=0x130aa80) at
/work/local-checkouts/main/gcc-fsf/gcc/passes.c:2081
#8  0x007f1095 in execute_pass_list (pass=0x130aa80) at
/work/local-checkouts/main/gcc-fsf/gcc/passes.c:2136
#9  0x00907238 in tree_rest_of_compilation (fndecl=0x76c59100) at
/work/local-checkouts/main/gcc-fsf/gcc/tree-optimize.c:420
#10 0x005cec5a in cgraph_expand_function (node=0x76c565a0) at
/work/local-checkouts/main/gcc-fsf/gcc/cgraphunit.c:1819
#11 0x005d249a in cgraph_expand_all_functions () at
/work/local-checkouts/main/gcc-fsf/gcc/cgraphunit.c:1886
#12 cgraph_optimize () at
/work/local-checkouts/main/gcc-fsf/gcc/cgraphunit.c:2200
#13 0x005d29f5 in cgraph_finalize_compilation_unit () at
/work/local-checkouts/main/gcc-fsf/gcc/cgraphunit.c:1328
#14 0x004aca88 in c_write_global_declarations () at
/work/local-checkouts/main/gcc-fsf/gcc/c-decl.c:10030
#15 0x00896f87 in compile_file () at
/work/local-checkouts/main/gcc-fsf/gcc/toplev.c:573
#16 do_compile () at /work/local-checkouts/main/gcc-fsf/gcc/toplev.c:1938
#17 0x00897664 in toplev_main (argc=16, argv=0x7fffe348) at
/work/local-checkouts/main/gcc-fsf/gcc/toplev.c:2014
#18 0x77874c4d in __libc_start_main () from /lib/libc.so.6
#19 0x0049a7a9 in _start ()

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  2012-01-27 
14:49:12 UTC ---
(In reply to comment #20)
> The patch is incomplete because it should update
> src/libstdc++-v3/config/cpu/generic/atomicity_builtins/atomicity.h as well.

It does update even that file.
The patch attached here doesn't work though, but with
sed -i -e s/__atomic_fetch_and_add/__atomic_fetch_add/g gcc47-pr51798.patch
it does, so far bootstrap/regression tested on x86_64-linux, i686-linux and
bootstrap tested on {powerpc{,64},s390{,x}}-linux, regression testing on those
4 ongoing.

[Bug tree-optimization/50444] [4.6/4.7 Regression] -ftree-sra ignores alignment

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Guenther  2012-01-27 
14:54:44 UTC ---
Author: rguenth
Date: Fri Jan 27 14:54:37 2012
New Revision: 183629

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183629
Log:
2012-01-27  Richard Guenther  

PR tree-optimization/50444
* expr.c (mem_ref_refers_to_non_mem_p): New function.
(expand_assignment): Use it.  Properly handle misaligned
bases when expanding stores to component references.
(expand_expr_real_1): Use mem_ref_refers_to_non_mem_p and
refactor that case.

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

[Bug tree-optimization/50444] [4.6/4.7 Regression] -ftree-sra ignores alignment

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Guenther  2012-01-27 
14:57:04 UTC ---
Author: rguenth
Date: Fri Jan 27 14:56:54 2012
New Revision: 183630

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183630
Log:
2012-01-27  Richard Guenther  

PR tree-optimization/50444
* tree-sra.c (build_ref_for_offset): Properly adjust the
MEM_REF type for unaligned accesses.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr50444.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

--- Comment #22 from David Edelsohn  2012-01-27 
14:57:42 UTC ---
You're right, the patch does modify both files.  sorry.

[Bug tree-optimization/50444] [4.6 Regression] -ftree-sra ignores alignment

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to work||4.7.0
Summary|[4.6/4.7 Regression]|[4.6 Regression] -ftree-sra
   |-ftree-sra ignores  |ignores alignment
   |alignment   |

--- Comment #19 from Richard Guenther  2012-01-27 
15:00:49 UTC ---
Fixed on trunk.

[Bug middle-end/16458] PowerPC - redundant compare

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #6 from Peter Bergner  2012-01-27 
15:12:15 UTC ---
Created attachment 26481
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26481
Updated patch to eliminate redudant compares

Here's a slightly updated patch that allows the compares to be cse'd, but also
doesn't disable the generation of record form instructions (ie, instructions
that also set cr0 implicitly).

I was mistaken in my Comment #5 above.  We can sometime handle:

  if (*a == *b)
...
  else if (*a > *b)
...

and:

  switch (*index)
  ...

depending on whether expand creates the type expression via REG_EXPR or not. 
In some cases it does and in others it doesn't.  That's not a limitation in
this patch, but in expand.  That can can be handled in separate patch.

[Bug tree-optimization/52019] [4.7 Regression] tree-ssa/ipa-split-5.c fails with -fno-tree-sra because of CLOBBERS

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org
   Target Milestone|--- |4.7.0

[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target|arm-linux-androideabi   |arm-linux-androideabi,
   ||arm*-*-*eabi

--- Comment #3 from Ramana Radhakrishnan  2012-01-27 
15:25:29 UTC ---
(In reply to comment #1)
> It looks like the neon builtins are not properly marked as pure/const, that
> certainly is a road-block for optimizations.  



> The heavy use of UNSPECs is
> another.

yes, one other problem is that a lot of the neon intrinsics don't expand into
an equivalent RTL - you still need the unspecs for the polynomial types but in
general a large number of the intrinsics that are in the form of unspecs could
use the underlying vec_ expanders that are also present. 




> 
> Confirmed.

[Bug regression/52020] ICE in immed_double_const, at emit-rtl.c:544

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-27
 CC||matz at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Michael Matz  2012-01-27 15:28:18 
UTC ---
Will be fixed when Richi commits his patch from
  http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01465.html

The problem is, that SRA transforms the "bu = CLOBBER" into bu.__o=0,
where the zero is of an OImode type.  This later is transformed into
a debug instruction (still using that large-type zero), and that zero can't
be transformed into RTL because OImode constants are too large to be held in
2*HOST_WIDE_INT .

SRA should not invent new constants that weren't there before.  It could
just as well generate new clobber statements (SSA names in LHS are allowed
there), if it really must scalarize the clobber statements.

[Bug c++/51910] [4.7 Regression] -frepo linking failure

[sandra at codesourcery dot com]

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

--- Comment #11 from Sandra Loosemore  
2012-01-27 15:31:14 UTC ---
I like the first patch too.  Since -frepo seems to depend on telling the linker
not to demangle, better to just say so.

I'm not familiar with the overall code flow here.  Does -frepo end up doing the
final link with the demangling setting requested by the user, or does this
change mean it always implies --no-demangle?  E.g., if I specify both -frepo
and -Wl,-Map expecting to get a demangled map file, will I get one?

[Bug regression/52020] ICE in immed_double_const, at emit-rtl.c:544

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Guenther  2012-01-27 
15:50:57 UTC ---
Fixed.

[Bug regression/52020] ICE in immed_double_const, at emit-rtl.c:544

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-01-27 
15:50:41 UTC ---
Author: rguenth
Date: Fri Jan 27 15:50:32 2012
New Revision: 183633

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183633
Log:
2012-01-27  Richard Guenther  

PR tree-optimization/52020
* tree-sra.c (sra_modify_assign): Do not transform clobbers.

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

[Bug c++/51910] [4.7 Regression] -frepo linking failure

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  2012-01-27 
15:50:54 UTC ---
Unfortunately the patch doesn't work, I thought that there are separate ld
invocations for rpo stuff only and then a final one without, but that is not
the case.  So, I'm withdrawing both patches.  Either the changes will need to
be backed out and always force demangling to be done in collect2 as opposed to
ld,
or something else.

[Bug fortran/52021] New: FAIL: gfortran.dg/typebound_proc_25.f90 -O (internal compiler error)

[danglin at gcc dot gnu.org]

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

 Bug #: 52021
   Summary: FAIL: gfortran.dg/typebound_proc_25.f90  -O  (internal
compiler error)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
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


Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa2.
0w-hp-hpux11.11/./libgfortran/
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/typeb
ound_proc_25.f90-O   -pedantic-errors -S  -o typebound_proc_25.s   
(timeout
 = 300)
spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc
/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.
11/./libgfortran/
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/typebound_proc_25.
f90 -O -pedantic-errors -S -o typebound_proc_25.s
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/typebound_proc_25.f90:88:0:
internal
 compiler error: in gfc_release_symbol, at fortran/symbol.c:2531
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1
output is:
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/typebound_proc_25.f90:88:0:
internal
 compiler error: in gfc_release_symbol, at fortran/symbol.c:2531
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

FAIL: gfortran.dg/typebound_proc_25.f90  -O  (internal compiler error)
FAIL: gfortran.dg/typebound_proc_25.f90  -O  (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/typebound_proc_25.f90:88:0:0:
internal compiler error: in gfc_release_symbol, at fortran/symbol.c:2531

[Bug fortran/52010] [OOP] Intrinsic assignment of a CLASS to a TYPE

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2012-01-27 
16:06:51 UTC ---
The following handles the checking part. However, one also needs to handle the
access internally (in trans-expr.c). Namely:
  type_var = class_var
  type_var = class_function ()
and both for "scalar = scalar", "array = scalar" and "array = array". Note that
the class_function can also be an intrinsic function such as RESHAPE. (Cf.
PR47505.)

--- expr.c  (revision 183625)
+++ expr.c  (working copy)
@@ -3256,3 +3256,8 @@ gfc_check_assign (gfc_expr *lvalue, gfc_

-  if (gfc_compare_types (&lvalue->ts, &rvalue->ts))
+  if (lvalue->ts.type == BT_DERIVED && rvalue->ts.type == BT_CLASS)
+{
+  if (gfc_compare_types (&lvalue->ts, &CLASS_DATA (rvalue)->ts))
+   return SUCCESS;
+}
+  else if (gfc_compare_types (&lvalue->ts, &rvalue->ts))
 return SUCCESS;

[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.

[ramana at gcc dot gnu.org]

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

--- Comment #9 from Ramana Radhakrishnan  2012-01-27 
16:20:07 UTC ---
(In reply to comment #8)
> Any chance of seeing the work on this restart ?
> 
> I found this bug while looking for something that would help (I raised bug
> 51980 for the same kind of issue, still seen on trunk), but the patch attached
> to this bug does not solve the issue for code that is rich with zip/uzp/trn
> intrinsics.

I took a look at this for sometime when I was reviewing the patch submitted on
trunk. The problem in this case appears to go away with -fno-split-wide-types
but that in general is not a good idea. IIRC when RichardS and I talked about
it we did talk about maybe getting lower-subreg to pay some attention to it. 

Neon intrinsics have been improving ( I'd like to think) over time but they are
still not perfect unfortunately. I don't have time to look at this in the near
term myself. 

> 
> This is a major limitation of arm-gcc with respect to performance-critical 
> Neon
> code in my opinion.

As they say, patches are welcome :) 

Ramana

[Bug fortran/52021] FAIL: gfortran.dg/typebound_proc_25.f90 -O (internal compiler error)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2012-01-27 16:37:19 UTC ---
Please update your sources.  This should have been fixed by

r183541 | burnus | 2012-01-25 14:21:14 -0800 (Wed, 25 Jan 2012) | 7 lines

2012-01-25  Tobias Burnus  

PR fortran/51995
* class.c (gfc_build_class_symbol): Fix invalid freeing
issue with fclass->f2k_derived.

[Bug target/51687] gcc is killed when compiling med-3.0.4

[thierry at FreeBSD dot org]

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

Thierry Thomas  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #3 from Thierry Thomas  2012-01-27 
16:53:54 UTC ---
Please close this report: it was local to my machine (I cannot explain it, but
I cannot reproduce it either).

[Bug fortran/52022] New: [4.5/4.6/4.7 Regression] Wrong-code with procedures passed as actual argument

[burnus at gcc dot gnu.org]

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

 Bug #: 52022
   Summary: [4.5/4.6/4.7 Regression] Wrong-code with procedures
passed as actual argument
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Reported by patnel97269 at http://gcc.gnu.org/ml/fortran/2012-01/msg00232.html

The following program - a stripped-down version of the original version -
compiles and successfully runs with GCC 4.3 and 4.4. It prints:
   2.4.

Using GCC 4.5, 4.6 and 4.7, one gets instead a SEGFAULT.

In 4.4, the passed argument is:
sol (cost1);
while 4.5/4.6/4.7 pass the argument:
  sol (&cost1);
which does not make much sense.

There might be internally some confusion between procedures dummies (pass
address of procedure to be called) and procedures pointers (pass address of the
callee such that it can be assigned to).


module m
contains
  function cost1(x) result(y)
double precision,dimension(:) :: x
double precision,dimension(:),allocatable :: y
allocate(y(2))
y=2d0*x
  end function cost1
end module m
program test
   use m
   implicit none
   call sol(cost1)
contains
  subroutine  sol(cost3)
interface
function cost3(p) result(y)
double precision,dimension(:) :: p
double precision,dimension(:),allocatable :: y
end function cost3
end interface

print *,cost3([1d0,2d0])
  end subroutine
end program test

[Bug c++/27775] incorrect "ambiguous" error message with multiple inheritance and nested class.

[rnewman at compubrite dot com]

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

Rich Newman  changed:

   What|Removed |Added

Version|4.0.0   |4.5.1
  Known to fail||4.3.0, 4.3.4, 4.4.4, 4.5.1

--- Comment #3 from Rich Newman  2012-01-27 
17:12:13 UTC ---
Bug still in version 4.3.4:

$ g++ -c bug27775.cc
bug27775.cc:11: error: reference to 'B' is ambiguous
bug27775.cc:5: error: candidates are: struct A::B
bug27775.cc:5: error: struct A::B
bug27775.cc:11: error: reference to 'B' is ambiguous
bug27775.cc:5: error: candidates are: struct A::B
bug27775.cc:5: error: struct A::B
bug27775.cc:11: error: 'B' has not been declared
bug27775.cc:12: error: reference to 'B' is ambiguous
bug27775.cc:5: error: candidates are: struct A::B
bug27775.cc:5: error: struct A::B
bug27775.cc:12: error: reference to 'B' is ambiguous
bug27775.cc:5: error: candidates are: struct A::B
bug27775.cc:5: error: struct A::B
bug27775.cc:12: error: 'B' has not been declared
$ g++ -dumpversion
4.3.4

Also in version 4.4.4:
$ g++ -c bug27775.cc
bug27775.cc:11: error: reference to 'B' is ambiguous
bug27775.cc:5: error: candidates are: struct A::B
bug27775.cc:5: error: struct A::B
bug27775.cc:11: error: reference to 'B' is ambiguous
bug27775.cc:5: error: candidates are: struct A::B
bug27775.cc:5: error: struct A::B
bug27775.cc:11: error: 'B' has not been declared
bug27775.cc:12: error: reference to 'B' is ambiguous
bug27775.cc:5: error: candidates are: struct A::B
bug27775.cc:5: error: struct A::B
bug27775.cc:12: error: reference to 'B' is ambiguous
bug27775.cc:5: error: candidates are: struct A::B
bug27775.cc:5: error: struct A::B
bug27775.cc:12: error: 'B' has not been declared
$ g++ -dumpversion
4.4.4
$

Also in 4.5.1:

$ g++ -c bug27775.cc
bug27775.cc:11:14: error: reference to 'B' is ambiguous
bug27775.cc:5:5: error: candidates are: struct A::B A::B::B
bug27775.cc:5:5: error: struct A::B
bug27775.cc:11:14: error: 'B' has not been declared
bug27775.cc:12:14: error: reference to 'B' is ambiguous
bug27775.cc:5:5: error: candidates are: struct A::B A::B::B
bug27775.cc:5:5: error: struct A::B
bug27775.cc:12:14: error: 'B' has not been declared
$ g++ -dumpversion
4.5.1

[Bug fortran/52022] [4.5/4.6/4.7 Regression] Wrong-code with procedures passed as actual argument

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org
   Target Milestone|--- |4.5.4

--- Comment #1 from Tobias Burnus  2012-01-27 
17:24:42 UTC ---
The issue is seemingly a side effect of supporting proc-pointer returning
functions (a GCC 4.5 features).

This does not interact well with passing nonprocedure-pointer functions, that
return allocatables, as can be seen from the following chunk in trans-expr.c's
gfc_conv_procedure_call:

  if (fsym && e->expr_type != EXPR_NULL
  && ((fsym->attr.pointer
   && fsym->attr.flavor != FL_PROCEDURE)
  || (fsym->attr.proc_pointer
  && !(e->expr_type == EXPR_VARIABLE
   && e->symtree->n.sym->attr.dummy))
  || (fsym->attr.proc_pointer
  && e->expr_type == EXPR_VARIABLE
  && gfc_is_proc_ptr_comp (e, NULL))
  || fsym->attr.allocatable))

Untested patch: Do the same as we already do for pointers.

--- trans-expr.c(revision 183625)
+++ trans-expr.c(working copy)
@@ -3664,3 +3664,4 @@ gfc_conv_procedure_call (gfc_se * se, gf
  && gfc_is_proc_ptr_comp (e, NULL))
- || fsym->attr.allocatable))
+ || (fsym->attr.allocatable
+ && fsym->attr.flavor != FL_PROCEDURE)))
{

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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

--- Comment #8 from Jack Howarth  2012-01-27 
17:36:08 UTC ---
Opened as radr://10765474, "darwin11 linker bug exposed by new libstdc++ thread
tests" although it appears to be more complex than a simple linker bug as...

1) 30_threads/recursive_mutex/try_lock/1.cc compiled under darwin10 runs fine
under darwin11. Also, the darwin10 generated 1.s can be reassembled and
relinked under darwin11 and the resulting 1.exe runs fine.
2) 30_threads/recursive_mutex/try_lock/1.cc compiled under darwin11 using
-mmacosx-version-min=10.6 fails when run under either darwin11 or darwin10.
Using the 1.s generated above to reassemble and relink under darwin10 still
shows the execution failure.

[Bug other/51937] [meta-bug] GCC 4.8 pending patches

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2012-01-27 
17:54:18 UTC ---
Consider converting local_specializations in cp/pt.c to pointer_map:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852#c18

[Bug c++/51852] [regression] [c++11] tree check: expected tree_list, have HßèMÕþÿøtxøtsø

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  2012-01-27 
17:56:01 UTC ---
Author: jakub
Date: Fri Jan 27 17:55:55 2012
New Revision: 183637

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183637
Log:
PR c++/51852
* pt.c (tsubst_pack_expansion): Delete and restore
local_specialization whenever need_local_specialization, not just
when saved_local_specializations is non-NULL.

* g++.dg/other/gc5.C: New test.

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

[Bug c/52023] New: _Alignof (double) yields wrong value on x86

[eggert at gnu dot org]

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

 Bug #: 52023
   Summary: _Alignof (double) yields wrong value on x86
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: egg...@gnu.org
  Host: x86-64
Target: x86
 Build: x86-64


Created attachment 26482
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26482
gcc -v output

On x86, alignof (double) should be 4, since that's the alignment
requirement used for 'double' when laying out structures.  But with
GCC alignof incorrectly returns 8.  This causes some gnulib tests to fail
and (more importantly) it may cause problems with programs such as
conservative garbage collectors that use alignof to determine which
addresses might be of valid objects.

The problem also occurs with other fundamental types, such as 'long long'.

Here's a simple test case:

  #include 
  #include 
  int a = alignof (double);
  int b = offsetof (struct { char c; double d; }, d);
  int main (void) { return a == b; }

Here's the preprocessed output:

  int a = _Alignof (double);
  int b = __builtin_offsetof (struct { char c; double d; }, d);
  int main (void) { return a == b; }

'main' should return 1, but it returns 0 due to the bug, which causes
'a' to be 8 instead of 4 as it should be.

I'm using GCC on the trunk (r183603), built on Fedora 16 x86-64 with
no special flags, and I'm compiling with 'gcc -v -m32 test.c' and
running with './a.out'.  I'm attaching the output of 'gcc -v'.