[Bug libitm/52042] libitm.c/clone-1.c (all darwin) and libitm.c/stackundo.c (darwin 11) execution tests fail with -fpie

[patrick.marlier at gmail dot com]

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

--- Comment #6 from Patrick Marlier  
2012-02-07 04:02:08 UTC ---
Created attachment 26595
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26595
patch that seems to work for clone-1.c

Hi guys,

In fact, the problem is that getsectdata doesn't take into account the PIE. We
can use _dyld_get_image_vmaddr_slide(0) but it should not be correct in case of
many dynamic libraries I guess. What do you think? Should I propose this patch?

Patrick Marlier.

[Bug bootstrap/49469] GCC fails to bootstrap when building with embedded zlib on Mac OS X 10.6.7

[manphiz at gmail dot com]

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

--- Comment #6 from Xiyue Deng  2012-02-07 03:57:49 
UTC ---
(In reply to comment #5)
> /Users/dxy/VCS/GIT/gcc/zlib/configure: line 3225:
> /tmp/gcc-build/i386/./prev-gcc/xgcc: No such file or directory
> 
> >--enable-multilib \
> 
> Don't use that option, zlib is not very friendly to it.  And the rest of the
> build machinary knows if multilib is enabled or now.

Ah I see. Fortunately one can use --with-system-zlib as workaround.

[Bug bootstrap/49469] GCC fails to bootstrap when building with embedded zlib on Mac OS X 10.6.7

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  2012-02-07 
03:35:22 UTC ---
/Users/dxy/VCS/GIT/gcc/zlib/configure: line 3225:
/tmp/gcc-build/i386/./prev-gcc/xgcc: No such file or directory

>--enable-multilib \

Don't use that option, zlib is not very friendly to it.  And the rest of the
build machinary knows if multilib is enabled or now.

[Bug bootstrap/49469] GCC fails to bootstrap when building with embedded zlib on Mac OS X 10.6.7

[manphiz at gmail dot com]

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

--- Comment #4 from Xiyue Deng  2012-02-07 03:28:06 
UTC ---
Created attachment 26594
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26594
config.log

This is /tmp/gcc-build/i386/zlib/config when build with trunk revision 183937.
The configure options are:

${SOURCE_PATH}/configure \
--prefix=${PREFIX} \
--with-gmp=${PREFIX} \
--with-mpfr=${PREFIX} \
--with-mpc=${PREFIX} \
--with-ppl=${PREFIX} \
--with-cloog=${PREFIX} \
--enable-cloog-backend=isl \
--program-suffix=-${VERSION} \
--enable-languages=c,c++,objc,obj-c++,fortran \
--disable-nls \
--disable-werror \
--enable-__cxa_init \
--enable-concept-checks \
--enable-decimal-float \
--enable-full-dynamic-string \
--enable-libstdcxx-time \
--enable-multilib \
--enable-plugin \
--enable-static \
--enable-shared \
--enable-threads \
--enable-version-specific-runtime-libs

HTH.

[Bug plugins/44056] plugin compile error: rtl.def uses "const" keyword because of "CONST" defined to "const" in include/ansidecl.h

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Andrew Pinski  2012-02-07 
02:47:15 UTC ---
You need to define IN_GCC to stop ansidecl.h from defining CONST.

[Bug pch/45979] precompiled headers breakage on 2.6.36-rc Linux/ARM kernels

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #11 from Andrew Pinski  2012-02-07 
02:38:12 UTC ---
Fixed.

[Bug middle-end/49435] get_z.c:46: MPFR assertion failed: exp < 0 || exp <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||i686-pc-linux-gnu
  Component|pch |middle-end

--- Comment #10 from Andrew Pinski  2012-02-07 
02:36:57 UTC ---
>GMP version 5.0.2, MPFR version 3.0.1

Did you build gmp/mpfr your self?  If so did you run make check to make sure
they are working correctly?

[Bug c++/51675] [C++11][4.7 Regression] Cannot create constexpr unions

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|FIXED   |

[Bug c++/52145] New: [C++11] zero-valued integer constant expression should prefer conversion to pointer

[zeratul976 at hotmail dot com]

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

 Bug #: 52145
   Summary: [C++11] zero-valued integer constant expression should
prefer conversion to pointer
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com


In the following example:

#include 
using std::cerr;

struct S { int n; };
struct X { X(int) {} };
void f(void*)
{
cerr << "Pointer!\n";
}
void f(X)
{
cerr << "X!\n";
}
int main()
{
f(S().n);
}

With GCC 4.7.0-20120128 with the --std=c++11 flag, the output is "X!". The
correct output would be "Pointer!".

The reason is that S's implicit default constructor is constexpr, so it
value-initializes n. Therefore S().n is a zero-valued integer constant
expression, whose conversion to a pointer is preferred over the user-defined
conversion to X.

(This example was taken from Chandler Carruth's talk at the GoingNative 2012
conference.)

[Bug target/33190] tm.texi describes some non-existing hooks

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-06
 Ever Confirmed|0   |1

--- Comment #3 from Andrew Pinski  2012-02-06 
23:57:39 UTC ---
Confirmed, I just ran into LOGICAL_OP_NON_SHORT_CIRCUIT today.

[Bug target/52107] IBM 128bit long double constant loaded inefficiently

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

   Target Milestone|4.8.0   |4.7.0

[Bug c++/52035] [4.7 regression] internal compiler error: tree code ‘template_type_parm’ is not supported in LTO streams

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/52107] IBM 128bit long double constant loaded inefficiently

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #6 from Alan Modra  2012-02-06 23:43:15 
UTC ---
Fixed mainline and 4.6

[Bug target/52107] IBM 128bit long double constant loaded inefficiently

[amodra at gcc dot gnu.org]

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

--- Comment #5 from Alan Modra  2012-02-06 23:41:49 
UTC ---
Author: amodra
Date: Mon Feb  6 23:41:45 2012
New Revision: 183947

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183947
Log:
PR target/52107
* config/rs6000/rs6000.c (rs6000_emit_move): Don't create DImode
subregs of TFmode.


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

[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||arm*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-06
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2012-02-06 
23:03:04 UTC ---
Confirmed.

[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor

[p.finizio at gmail dot com]

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

--- Comment #4 from Piero Finizio  2012-02-06 
23:01:56 UTC ---
(In reply to comment #2)
> Created attachment 26581 [details]
> gcc47-pr52132.patch
> 
> Untested fix.  What get_true_reg does might be reasonable for code where we
> have quite strict requirements on what SUBREG can be applied or not, but it is
> definitely wrong for arbitrary SUBREGs in DEBUG_INSNs.  In fact, I don't see
> what get_true_reg would buy us, we get at the real REG in for_each_rtx anyway
> and can keep the SUBREGs, FLOAT_EXTEND etc. in the DEBUG_INSN.

Fix tested with gcc-4.7.0-20120126 sources, this last extracted from
gcc-4.7.0-0.10.fc17.src.rpm.
Now gmake works with mesa from git repository.

[Bug target/52144] New: ARM should support arm/thumb function attribute to permit different instruction sets in the same source

[rafael.carre at gmail dot com]

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

 Bug #: 52144
   Summary: ARM should support arm/thumb function attribute to
permit different instruction sets in the same source
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rafael.ca...@gmail.com


Reference: First message of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40419

Mixing thumb and ARM in the same source is currently not possible.

That would permit LTO to work when mixing those and close
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45729

[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor

[p.finizio at gmail dot com]

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

Piero Finizio  changed:

   What|Removed |Added

 CC||p.finizio at gmail dot com

--- Comment #3 from Piero Finizio  2012-02-06 
22:59:25 UTC ---
(In reply to comment #2)
> Created attachment 26581 [details]
> gcc47-pr52132.patch
> 
> Untested fix.  What get_true_reg does might be reasonable for code where we
> have quite strict requirements on what SUBREG can be applied or not, but it is
> definitely wrong for arbitrary SUBREGs in DEBUG_INSNs.  In fact, I don't see
> what get_true_reg would buy us, we get at the real REG in for_each_rtx anyway
> and can keep the SUBREGs, FLOAT_EXTEND etc. in the DEBUG_INSN.

Fix tested with gcc-4.7.0-20120126 sources, this last extracted from
gcc-4.7.0-0.10.fc17.src.rpm.
Now gmake works with mesa from git repository.

[Bug libfortran/49791] [4.4/4.5/4.6/4.7 Regression] Formatted namelist reads fails with: Cannot match namelist object

[burnus at gcc dot gnu.org]

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

--- Comment #20 from Tobias Burnus  2012-02-06 
22:18:39 UTC ---
(In reply to comment #19)
> --- ../../libgfortran/io/list_read.c(Revision 183913)
> @@ -2206,3 +2211,4 @@ nml_parse_qualifier (st_parameter_dt *dt
> @@ -2517,2 +2518,19 @@ nml_read_obj (st_parameter_dt *dtp, name

Using the two patches, the related PR 51825 is not fixed - and one additionally
gets the following failures:
 gfortran.dg/namelist_17.f90
 gfortran.dg/namelist_23.f90
 gfortran.dg/namelist_42.f90
 gfortran.dg/namelist_43.f90
 gfortran.dg/namelist_44.f90
 gfortran.dg/pr19657.f

[Bug target/52107] IBM 128bit long double constant loaded inefficiently

[amodra at gcc dot gnu.org]

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

--- Comment #4 from Alan Modra  2012-02-06 22:09:17 
UTC ---
Author: amodra
Date: Mon Feb  6 22:09:13 2012
New Revision: 183945

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183945
Log:
PR target/52107
* config/rs6000/rs6000.c (rs6000_emit_move): Don't create DImode
subregs of TFmode.


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

[Bug fortran/51825] Fortran runtime error: Cannot match namelist object name

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2012-02-06 
21:55:33 UTC ---
Seems to be related to PR 49791, though the patch in PR 49791 comment 19 does
not help.

[Bug tree-optimization/50969] 17% degradation in 168.wupwise for interleave via permutation

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from William J. Schmidt  2012-02-06 
21:41:47 UTC ---
Fixed with simple permute cost change for now.  A better analysis of permutes
will be considered in 4.8.

[Bug middle-end/30442] Expanded array initialization can use memset builtin function

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

   Last reconfirmed|2007-01-14 05:01:04 |2012-02-06

--- Comment #6 from Uros Bizjak  2012-02-06 21:40:50 
UTC ---
Reconfirmed with 4.7.

[Bug tree-optimization/50969] 17% degradation in 168.wupwise for interleave via permutation

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from William J. Schmidt  2012-02-06 
21:39:38 UTC ---
Author: wschmidt
Date: Mon Feb  6 21:39:34 2012
New Revision: 183944

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183944
Log:
2012-02-06  Bill Schmidt  

PR tree-optimization/50969
* tree-vect-stmts.c (vect_model_store_cost): Correct statement cost to
use vec_perm rather than vector_stmt.
(vect_model_load_cost): Likewise.
* config/i386/i386.c (ix86_builtin_vectorization_cost): Change cost of
vec_perm to be the same as other vector statements.
* config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost): Revise
cost of vec_perm for TARGET_VSX.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/tree-vect-stmts.c

[Bug libstdc++/52104] go1 fails to link on Solaris 8/9 x86 with native TLS

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  2012-02-06 
21:37:09 UTC ---
please let me know what issues remain on Solaris after r183920

[Bug middle-end/28685] Multiple comparisons are not simplified

[ubizjak at gmail dot com]

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

--- Comment #19 from Uros Bizjak  2012-02-06 21:36:01 
UTC ---
(In reply to comment #4)
> Another similar, but yet different case:

Yet another similar test:

int test (int a, int b)
{
  int lt = a + b < 0;
  int eq = a + b == 0;
  if (lt)
return 1;
  return eq;
}

combine pass creates:

(set (reg:CCZ 17 flags)
(compare:CCZ (plus:SI (reg/v:SI 63 [ a ])
(reg/v:SI 64 [ b ]))
(const_int 0 [0])))
(set (reg:SI 60 [ D.1710 ])
(plus:SI (reg/v:SI 63 [ a ])
(reg/v:SI 64 [ b ])))

we have a discrepancy here, since compare elimination pass expects RTX in the
form of:

 [(operate)
  (set-cc)]

[Bug middle-end/52142] [trans-mem] inlined transaction_pure functions are instrumented

[patrick.marlier at gmail dot com]

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

--- Comment #1 from Patrick Marlier  
2012-02-06 21:35:09 UTC ---
Created attachment 26593
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26593
another testcase but with an asm statement

the asm statement is in a transaction_pure function but diagnose a asm
statement into an atomic transaction.

$ ../gcc/xgcc -B/../gcc/ asm-2.c -fgnu-tm -O0 -S -o asm-2.s
$ ../gcc/xgcc -B/../gcc/ asm-2.c -fgnu-tm -O1 -S -o asm-2.s
asm-2.c:7:3: error: asm not allowed in atomic transaction

[Bug fortran/52143] New: [OOP] ICE with polymorphic function result in gfc_class_vptr_get

[burnus at gcc dot gnu.org]

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

 Bug #: 52143
   Summary: [OOP] ICE with polymorphic function result in
gfc_class_vptr_get
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: pa...@gcc.gnu.org


Found when creating a test case for PR 51514.

The following code causes an

test.f90:8:0: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have function_type in gfc_class_vptr_get, at
fortran/trans-expr.c:78

which is at

  vptr = gfc_advance_chain (TYPE_FIELDS (TREE_TYPE (decl)),
CLASS_VPTR_FIELD);

Backtrace:

#0  gfc_class_vptr_get (decl=0x2cce2600)
at trans-expr.c:78
#1  0x005d3f0d in gfc_vtable_field_get (decl=, field=1)
at trans-expr.c:91
#2  0x005b1fa5 in build_class_array_ref (index=0x2cbc3c90,
  base=0x2cced2a8, se=)
at trans-array.c:2984
#3  gfc_conv_scalarized_array_ref (se=0x7fffce20, ar=)
at trans-array.c:3037
#4  0x005b2852 in gfc_conv_array_ref (se=0x7fffce20, ar=0x174a888,
  sym=, where=)
at trans-array.c:3112
#5  0x005db098 in gfc_conv_variable (se=0x7fffce20, expr=0x174a620)
at trans-expr.c:1333
#6  0x005da874 in gfc_conv_expr_reference (se=0x7fffce20,
   expr=)
at trans-expr.c:5610
#7  0x005de0b0 in gfc_conv_procedure_call (se=0x7fffcff0,
  sym=0x173e1f0, args=0x1746b50, expr=0x174aa10, append_args=0x0)
at trans-expr.c:3540
#8  0x006020c5 in gfc_trans_call (code=0x174af90,
 dependency_check=, mask=0x0, count1=0x0, invert=false)
at trans-stmt.c:468



module mod_subpr
  type :: foo
integer :: i = 2
  end type
contains
  function g ()
class(foo), allocatable :: g(:)
allocate (g(3)) 
  end function g
end module

[Bug c++/52126] [4.7 Regression] compilation error

[fabien at gcc dot gnu.org]

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

--- Comment #3 from fabien at gcc dot gnu.org 2012-02-06 21:31:30 UTC ---
I'll be assigning myself to this bug when I come back from vacation next
monday.

[Bug c++/52035] [4.7 regression] internal compiler error: tree code ‘template_type_parm’ is not supported in LTO streams

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Jason Merrill  2012-02-06 
21:28:32 UTC ---
The problem here is that when we go to instantiate QVector, we step
through the members in order.  When we instantiate the declaration of insert,
we're using the declaration from the out-of-class definition, which uses the
size_type typedef.  But we haven't instantiated size_type yet, so tsubst thinks
that we're instantiating it now, and we end up just returning the version from
the template.

[Bug libstdc++/52128] [4.7 regression] r183788 caused massive libstdc++ testsuite regression on i686-linux

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Jonathan Wakely  2012-02-06 
21:24:21 UTC ---
fixed

[Bug fortran/32373] not vectorized: can't determine dependence (equivalence)

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  2012-02-06 
21:25:00 UTC ---
Author: tkoenig
Date: Mon Feb  6 21:24:54 2012
New Revision: 183943

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183943
Log:
2012-02-06  Thomas König  

PR fortran/32373
* gfortran.dg/vect/vect-8.f90:  Use vect_double effective target.
Remove module.



Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/vect/vect-8.f90

[Bug fortran/52044] [OOP] Invalid memory access with ALLOCATE, default initializer and polymorphic array components

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #2 from Paul Thomas  2012-02-06 21:24:12 
UTC ---
This is now fixed, since __builtin_memset (two.a._data.data, 0, 96); appears
after allocation.

Thanks for this and all the other extracts from Damian and co.'s book!

Cheers

Paul

[Bug middle-end/52142] New: [trans-mem] inlined transaction_pure functions are instrumented

[patrick.marlier at gmail dot com]

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

 Bug #: 52142
   Summary: [trans-mem] inlined transaction_pure functions are
instrumented
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: patrick.marl...@gmail.com
CC: al...@gcc.gnu.org, r...@gcc.gnu.org


Created attachment 26592
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26592
testcase with -fgnu-tm -O1

In this testcase, the function 'purefunc' has inline and transaction_pure
attribute. In the optimized mode (-O), the function becomes inlined but also
instrumented whereas it was annotated transaction_pure.

[Bug libstdc++/52128] [4.7 regression] r183788 caused massive libstdc++ testsuite regression on i686-linux

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  2012-02-06 
20:51:57 UTC ---
Author: redi
Date: Mon Feb  6 20:51:52 2012
New Revision: 183942

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183942
Log:
PR libstdc++/52128
* src/c++11/future.cc: Add explicit instantiation.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/future.cc

[Bug middle-end/52140] Libdfp testcase encounters ICE when compiled with soft-dfp (no -mcpu).

[rsa at us dot ibm.com]

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

--- Comment #4 from Ryan S. Arnold  2012-02-06 20:51:01 
UTC ---
(In reply to comment #3)
> Have you tried an FSF released 4.6.2?

This also fails in the same way with:

gcc version 4.6.3 20111209 (Advance-Toolchain-5.0-2) [ibm/gcc-4_6-branch
revision 182176] (GCC)

Bergner said that he'd take a look.

[Bug middle-end/52141] New: [trans-mem] ICE due to asm statement in trans-mem.c:expand_block_tm

[patrick.marlier at gmail dot com]

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

 Bug #: 52141
   Summary: [trans-mem] ICE due to asm statement in
trans-mem.c:expand_block_tm
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: patrick.marl...@gmail.com
CC: al...@gcc.gnu.org, r...@gcc.gnu.org


Created attachment 26591
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26591
testcase ICE with -fgnu-tm -O1

In the continuation of PRs: 46269, 47606, 51443.

../../trunk-debug/gcc/xgcc -B ../../trunk-debug/gcc -fgnu-tm -O1 -S -o
ICE-inline.s ICE-inline2.c
ICE-inline2.c:2:13: warning: always_inline function might not be inlinable
[-Wattributes]
ICE-inline2.c:13:5: internal compiler error: in expand_block_tm, at
trans-mem.c:2366

(gdb) bt
...
#5  0x00b1714f in expand_block_tm (region=0x1b99160, bb=0x769aa208)
at ../../trunk/gcc/trans-mem.c:2366
#6  0x00b17455 in execute_tm_mark () at
../../trunk/gcc/trans-mem.c:2467
#7  0x00a1672f in execute_one_pass (pass=0x196c0a0) at
../../trunk/gcc/passes.c:2081
...

[Bug c/52140] ICE in Libdfp testcase when compiled with soft-dfp (no -mcpu).

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|major   |normal

--- Comment #3 from Andrew Pinski  2012-02-06 
20:47:54 UTC ---
Have you tried an FSF released 4.6.2?

[Bug c/52140] ICE in Libdfp testcase when compiled with soft-dfp (no -mcpu).

[rsa at us dot ibm.com]

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

--- Comment #2 from Ryan S. Arnold  2012-02-06 20:46:34 
UTC ---
Created attachment 26590
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26590
Preprocessed .s file

[Bug c/52140] ICE in Libdfp testcase when compiled with soft-dfp (no -mcpu).

[rsa at us dot ibm.com]

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

--- Comment #1 from Ryan S. Arnold  2012-02-06 20:46:00 
UTC ---
Created attachment 26589
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26589
preprocessed .i file

[Bug c/52140] New: ICE in Libdfp testcase when compiled with soft-dfp (no -mcpu).

[rsa at us dot ibm.com]

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

 Bug #: 52140
   Summary: ICE in Libdfp testcase when compiled with soft-dfp (no
-mcpu).
Classification: Unclassified
   Product: gcc
   Version: 4.5.4
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@us.ibm.com


The following Libdfp test-case produces an ICE on PowerPC when compiled w/o
-mcpu (implies soft-dfp) and -O1 or greater optimization:

#ifndef __STDC_WANT_DEC_FP__
#define __STDC_WANT_DEC_FP__
#endif

int
foo (_Decimal64 x, _Decimal64 y)
{
  /* This is known to cause a GCC ICE when libdfp is compiled w/o -mcpu and -O1
 optimization level or greater.  */
  return (x < y) || (x > y);
}

int main(void)
{
  int ret = -1;
  _Decimal64 a = 12.45DD;
  _Decimal64 b = 12.43DD;
  ret = foo (a,b);
  return 0;
}

/opt/at4.0/bin/gcc -v:
Using built-in specs.
COLLECT_GCC=/opt/at4.0/bin/gcc
COLLECT_LTO_WRAPPER=/opt/at4.0/libexec/gcc/powerpc64-linux/4.5.4/lto-wrapper
Target: powerpc64-linux
Configured with: /home/cseo/at4.0/at4.0-5/src/gcc/configure
--build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux
--with-cpu=default64 --prefix=/opt/at4.0 --with-long-double-128
--enable-decimal-float --enable-secureplt --enable-threads=posix
--enable-languages=c,c++,fortran --enable-__cxa_atexit --enable-shared
--enable-checking --enable-lto --enable-gnu-indirect-function
--with-gmp-include=/opt/at4.0/include --with-gmp-lib=/opt/at4.0/lib64
--with-mpfr-include=/opt/at4.0/include --with-mpfr-lib=/opt/at4.0/lib64
--with-mpc-include=/opt/at4.0/include --with-mpc-lib=/opt/at4.0/lib64
--with-ppl-include=/opt/at4.0/include --with-ppl-lib=/opt/at4.0/lib64
--with-cloog-include=/opt/at4.0/include --with-cloog-lib=/opt/at4.0/lib64
--with-libelf-include=/opt/at4.0/include --with-libelf-lib=/opt/at4.0/lib64
--with-host-libstdcxx='-L/opt/at4.0/lib64 -lstdc++ -lsupc++ -lppl -lppl_c -lpwl
-lgmp -lgmpxx' --with-cpu=power4 --with-tune=power6
Thread model: posix
gcc version 4.5.4 20110524 (Advance-Toolchain-4.0-5) [ibm/gcc-4_5-branch
revision 179810] (GCC)


/opt/at4.0/bin/gcc  -DSHARED -O2 -fpic -g -m32   -c ../tests/test-GCC-PR.c
-D__STDC_DEC_FP__=200704L -D__STDC_WANT_DEC_FP__=1
-DOPTION_EGLIBC_LOCALE_CODE=1 -D_POSIX_C_SOURCE=200809L -std=gnu99
-D_SVID_SOURCE -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-Wno-long-long -include ../include/libdfp-symbols.h -include ./config.h 
-I../include  -I../dfp  -I../dfp/decimal  -I../libdecnumber/dpd 
-I../libdecnumber  -I../sysdeps/powerpc/powerpc32 
-I../sysdeps/powerpc/fpu/bits  -I../sysdeps/powerpc/fpu  -I../sysdeps/powerpc 
-I../sysdeps/soft-dfp/dpd  -I../sysdeps/soft-dfp  -I../sysdeps/dpd 
-I../decNumberMath/  -I../ieee754/  -I../base-math/  -I..  -I.  -o
test-GCC-PR.os
../tests/test-GCC-PR.c:30:1: warning: no previous prototype for 'foo'
../tests/test-GCC-PR.c: In function 'foo':
../tests/test-GCC-PR.c:34:3: internal compiler error: in prepare_float_lib_cmp,
at optabs.c:4414

I've attached the test-GCC-PR.i and test-GCC-PR.s files generated with
--save-temps.

[Bug c++/48491] ICE in "delete" with template convertion operator

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #2 from Jason Merrill  2012-02-06 
20:03:11 UTC ---
Fixed by patch for PR52088.

[Bug rtl-optimization/52139] [4.5/4.6/4.7 Regression] ICE: in remove_insn, at emit-rtl.c:3960 with -O -fPIC -fno-tree-dominator-opts -fno-tree-fre

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-02-06
 CC||jakub at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #2 from Jakub Jelinek  2012-02-06 
20:02:29 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145494
Will have a look.

[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2012-02-06 
20:01:15 UTC ---
(In reply to comment #4)
> Thanks. I tried the -std=f95 flag and it gave the same (wrong) answer as
> without it, in the test code I sent you. What is not Fortran95 compatible with
> the code snippet I sent you?

I works for me both with GCC 4.6 and GCC 4.7 both with the current version but
also with a version which still had bug 52012.

Can you please answer the following question? You only kind of answered the
third question, namely that you used the original program (of comment 0).
Additional, could you provide more information about the version you used
("gfortran -v"), of interest are the complete of "Target" and of "gcc version".


(In reply to comment #3)
> Can you provides more details?
> 
> In particular:
> - How does it fail? At compile time? At run time? With which error?
> - Which version/platform of the compiler are you using?
> - Is that with the code of comment 0 with only "B = RESHAPE..." changed to
> "B(:) = RESHAPE..." or is it for some other code?


Example on my system for a 4.6 version which has still the bug:

$ gfortran-4.6 -v |& grep -E 'gcc version|Target'
Target: x86_64-suse-linux
gcc version 4.6.2 20111212 [gcc-4_6-branch revision 18] (SUSE Linux) 

$ gfortran-4.6 -std=f95 test.f90 
test.f90:37.11:
  PAUSE
   1
Error: Deleted feature: PAUSE statement at (1)

And after commenting that line:

$ gfortran-4.6 -std=f95 test.f90
 A(   1 ,   1 ) =1.  B =1.
 A(   2 ,   1 ) =2.  B =2.
 A(   1 ,   2 ) =3.  B =3.
 A(   2 ,   2 ) =4.  B =4.
 A(   1 ,   3 ) =5.  B =5.
 A(   2 ,   3 ) =6.  B =6.
 A(   1 ,   4 ) =7.  B =7.
 A(   2 ,   4 ) =8.  B =8.

The output looks correct and is the same as with other compilers. However, if I
use the buggy version of the compiler without -std=f95, I get:

$ gfortran-4.6 hj4.f90  && ./a.out 
 A(   1 ,   1 ) =1.  B =3.
 A(   2 ,   1 ) =2.  B =4.
 A(   1 ,   2 ) =3.  B =5.
 A(   2 ,   2 ) =4.  B =6.
 A(   1 ,   3 ) =5.  B =7.
 A(   2 ,   3 ) =6.  B =8.
 A(   1 ,   4 ) =7.  B =3.36311631E-44
 A(   2 ,   4 ) =8.  B =9.62964972E-35


As written, using "(:)" - or to be more precise (it's a rank-3 array) -
"B(:,:,:) = ", -fno-realloc-lhs, or a newer version of the compiler solves the
problem as well.

[Bug c++/48490] "delete" with template convertion operator does overload resolution for class operands, but shouldn't.

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #1 from Jason Merrill  2012-02-06 
20:01:04 UTC ---
Fixed by patch for PR52088.

[Bug rtl-optimization/52139] ICE: in remove_insn, at emit-rtl.c:3960 with -O -fPIC -fno-tree-dominator-opts -fno-tree-fre --param case-values-threshold=1

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

  Attachment #26587|0   |1
is obsolete||

--- Comment #1 from Zdenek Sojka  2012-02-06 19:55:30 
UTC ---
Created attachment 26588
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26588
testcase failing in 4.5, 4.6 and 4.7

$ gcc -O -fPIC -fno-tree-dominator-opts -fno-tree-fre testcase2.c
testcase2.c: In function 'foo':
testcase2.c:44:1: internal compiler error: in remove_insn, at emit-rtl.c:3960
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/52088] [4.7 Regression] ICE in "delete" with template convertion operator

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jason Merrill  2012-02-06 
19:54:04 UTC ---
Fixed.

[Bug c++/52088] [4.7 Regression] ICE in "delete" with template convertion operator

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2012-02-06 
19:52:47 UTC ---
Author: jason
Date: Mon Feb  6 19:52:43 2012
New Revision: 183940

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183940
Log:
PR c++/52088
* cvt.c (build_expr_type_conversion): Check for template conversion.

Added:
trunk/gcc/testsuite/g++.dg/template/conv13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/52139] New: ICE: in remove_insn, at emit-rtl.c:3960 with -O -fPIC -fno-tree-dominator-opts -fno-tree-fre --param case-values-threshold=1

[zsojka at seznam dot cz]

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

 Bug #: 52139
   Summary: ICE: in remove_insn, at emit-rtl.c:3960 with -O -fPIC
-fno-tree-dominator-opts -fno-tree-fre --param
case-values-threshold=1
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O -fPIC -fno-tree-dominator-opts -fno-tree-fre --param
case-values-threshold=1 testcase.c 
testcase.c: In function 'foo':
testcase.c:17:1: internal compiler error: in remove_insn, at emit-rtl.c:3960
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  fancy_abort (file=0x1264468 "/mnt/svn/gcc-trunk/gcc/emit-rtl.c", line=3960,
function=0x1265661 "remove_insn")
at /mnt/svn/gcc-trunk/gcc/diagnostic.c:898
#1  0x0073f55c in remove_insn (insn=0x75bc6580) at
/mnt/svn/gcc-trunk/gcc/emit-rtl.c:3960
#2  0x0069c541 in delete_insn (insn=0x75bc6580) at
/mnt/svn/gcc-trunk/gcc/cfgrtl.c:145
#3  0x0069fb8a in cfg_layout_merge_blocks (a=0x75ba5410,
b=0x75ba5340) at /mnt/svn/gcc-trunk/gcc/cfgrtl.c:2896
#4  0x0068c5f6 in merge_blocks (a=0x75ba5410, b=0x75ba5340) at
/mnt/svn/gcc-trunk/gcc/cfghooks.c:683
#5  0x010810b7 in try_optimize_cfg (mode=) at
/mnt/svn/gcc-trunk/gcc/cfgcleanup.c:2696
#6  cleanup_cfg (mode=) at
/mnt/svn/gcc-trunk/gcc/cfgcleanup.c:2940
#7  0x010d6cc6 in rest_of_handle_cse () at
/mnt/svn/gcc-trunk/gcc/cse.c:7327
#8  rest_of_handle_cse () at /mnt/svn/gcc-trunk/gcc/cse.c:7310
#9  0x008fbba5 in execute_one_pass (pass=0x17ced80) at
/mnt/svn/gcc-trunk/gcc/passes.c:2081
#10 0x008fbf65 in execute_pass_list (pass=0x17ced80) at
/mnt/svn/gcc-trunk/gcc/passes.c:2136
#11 0x008fbf77 in execute_pass_list (pass=0x17c9f40) at
/mnt/svn/gcc-trunk/gcc/passes.c:2137
#12 0x00a5e24e in tree_rest_of_compilation (fndecl=0x75ba6e00) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:422
#13 0x006affca in cgraph_expand_function (node=0x75a976c0) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1829
#14 0x006b1ebc in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1896
#15 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2210
#16 0x006b250a in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1338
#17 0x0058ec70 in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:10030
#18 0x009f0a2c in compile_file () at
/mnt/svn/gcc-trunk/gcc/toplev.c:573
#19 do_compile () at /mnt/svn/gcc-trunk/gcc/toplev.c:1938
#20 toplev_main (argc=18, argv=0x7fffd7f8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:2014
#21 0x761cc09d in __libc_start_main () from /lib64/libc.so.6
#22 0x00572371 in _start ()

Tested revisions:
r183913 - crash

[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2

[sphirshman at yahoo dot com]

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

--- Comment #4 from steven hirshman  2012-02-06 
19:45:53 UTC ---
Thanks. I tried the -std=f95 flag and it gave the same (wrong) answer as
without it, in the test code I sent you. What is not Fortran95 compatible with
the code snippet I sent you?





From: burnus at gcc dot gnu.org 
To: sphirsh...@yahoo.com 
Sent: Monday, February 6, 2012 12:45 PM
Subject: [Bug fortran/52117] allocated arrays give incorrect results when used
with RESHAPE in gcc v4.6.2

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

--- Comment #3 from Tobias Burnus  2012-02-06
17:45:36 UTC ---
(In reply to comment #2)
> Thank you for the information. THe work-around works with the newer (4.6.2)
> compiler, but is unrecognized by older versions of gcc that are in use on
> - for example - NERSC computers.

Well, the bug is related to (re)allocation on assignment (a Fortran 2003
features), which is new in GCC 4.6. Thus, both the flag -f(no-)realloc-lhs but
also the bug is only in GCC 4.6 (and 4.7).

You could also use "-std=f95", which implies -fno-realloc-lhs with GCC 4.6/4.7
but is also supported in older gfortrans; however, you need to have a code
which follows Fortran 95 close enough to be compilable with that flag.


> Is there a FIX other than the workaround planned, that will be backwards
> compatible with older compilers?

The actual bug has been fixed on both the GCC 4.6 branch (on 2012-02-03) and on
the GCC 4.7 trunk (on 2012-02-02). Thus, if you have a newer version of GCC
4.6/4.7, you are also not affected. (Cf. the nightly build from
http://gcc.gnu.org/wiki/GFortranBinaries )

See bug 52012 for details.


> Also, the B(:) fails on some platforms, I'm told by some of my co-workers.

Can you provides more details? Using "B(:) =" prevents the (re)allocation of
the left-hand side and thus it should also prevent the bug.

In particular:
- How does it fail? At compile time? At run time? With which error?
- Which version/platform of the compiler are you using?
- Is that with the code of comment 0 with only "B = RESHAPE..." changed to
"B(:) = RESHAPE..." or is it for some other code?

[Bug middle-end/52134] Does not fold (x * 4) & -4

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||TREE

--- Comment #2 from Andrew Pinski  2012-02-06 
19:45:41 UTC ---
Short testcase:
unsigned f(unsigned t)
{
  return (t*4)&-4;
}
int f1(int t)
{
  return (t*4)&-4;
}

Both should be optimized to just t*4.  In fact we do it on the RTL level.
*4 is changed to <

[Bug c/52138] Operations on complex values are not inlined, even with -O3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #5 from Andrew Pinski  2012-02-06 
19:28:41 UTC ---
This is invalid as mentioned above.

[Bug c/52138] Operations on complex values are not inlined, even with -O3

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  2012-02-06 
18:58:00 UTC ---
>From the manual:

-fcx-limited-range
When enabled, this option states that a range reduction step is not needed when
performing complex division. Also, there is no checking whether the result of a
complex multiplication or division is NaN + I*NaN, with an attempt to rescue
the situation in that case. The default is -fno-cx-limited-range, but is
enabled by -ffast-math.
This option controls the default setting of the ISO C99 CX_LIMITED_RANGE
pragma. Nevertheless, the option applies to all languages. 

-fcx-fortran-rules
Complex multiplication and division follow Fortran rules. Range reduction is
done as part of complex division, but there is no checking whether the result
of a complex multiplication or division is NaN + I*NaN, with an attempt to
rescue the situation in that case.
The default is -fno-cx-fortran-rules.

[Bug c/52138] Operations on complex values are not inlined, even with -O3

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org 2012-02-06 18:50:41 UTC ---
(In reply to comment #2)
> I'm a bit confused... In the gfortran output the multiplication only about 40
> bytes. Does that mean that gfortran is using a reduced range by default?

>From gcc/toplev.c

  /* With -fcx-limited-range, we do cheap and quick complex arithmetic.  */
  if (flag_cx_limited_range)
flag_complex_method = 0;

  /* With -fcx-fortran-rules, we do something in-between cheap and C99.  */
  if (flag_cx_fortran_rules)
flag_complex_method = 1;

So, yes, gfortran does something different than gcc.

[Bug c/52138] Operations on complex values are not inlined, even with -O3

[gonnet at maths dot ox.ac.uk]

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

--- Comment #2 from Pedro  2012-02-06 18:33:11 
UTC ---
I'm a bit confused... In the gfortran output the multiplication only about 40
bytes. Does that mean that gfortran is using a reduced range by default?

[Bug c/52138] Operations on complex values are not inlined, even with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2012-02-06 
18:25:47 UTC ---
Why do you think inlining a ~ 750B long routine would be beneficial?  Note that
if one of the operands has 0 either the imaginary or real part, gcc will inline
it.

[Bug c/52138] New: Operations on complex values are not inlined, even with -O3

[gonnet at maths dot ox.ac.uk]

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

 Bug #: 52138
   Summary: Operations on complex values are not inlined, even
with -O3
Classification: Unclassified
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gon...@maths.ox.ac.uk


Irrespective of the optimization level selected, multiplying or dividing two
complex doubles generates a call to __muldc3 or __divdc3 respectively.

Using the "-fcx-limited-range" flag inlines the operations, but then the range
may be limited.

Strangely enough, in the gfortran frontend, complex arithmetic is inlined even
with no optimization (-O0).

[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2012-02-06 
17:45:36 UTC ---
(In reply to comment #2)
> Thank you for the information. THe work-around works with the newer (4.6.2)
> compiler, but is unrecognized by older versions of gcc that are in use on
> - for example - NERSC computers.

Well, the bug is related to (re)allocation on assignment (a Fortran 2003
features), which is new in GCC 4.6. Thus, both the flag -f(no-)realloc-lhs but
also the bug is only in GCC 4.6 (and 4.7).

You could also use "-std=f95", which implies -fno-realloc-lhs with GCC 4.6/4.7
but is also supported in older gfortrans; however, you need to have a code
which follows Fortran 95 close enough to be compilable with that flag.


> Is there a FIX other than the workaround planned, that will be backwards
> compatible with older compilers?

The actual bug has been fixed on both the GCC 4.6 branch (on 2012-02-03) and on
the GCC 4.7 trunk (on 2012-02-02). Thus, if you have a newer version of GCC
4.6/4.7, you are also not affected. (Cf. the nightly build from
http://gcc.gnu.org/wiki/GFortranBinaries )

See bug 52012 for details.


> Also, the B(:) fails on some platforms, I'm told by some of my co-workers.

Can you provides more details? Using "B(:) =" prevents the (re)allocation of
the left-hand side and thus it should also prevent the bug.

In particular:
- How does it fail? At compile time? At run time? With which error?
- Which version/platform of the compiler are you using?
- Is that with the code of comment 0 with only "B = RESHAPE..." changed to
"B(:) = RESHAPE..." or is it for some other code?

[Bug rtl-optimization/52060] [4.7 regression] Invalid constant simplification in combine with parallel result

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2012-02-06 
17:44:36 UTC ---
Created attachment 26586
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26586
gcc47-pr52060.patch

I think the important question is if it is ok that combine_simplify_rtx may
modify the given rtl in place, as opposed to keeping it unmodified and just
allocating new rtx and returning it.  A brief look at combine.c suggests that
SUBST () is used in so many places that it is meant to be ok to modify it in
place.

Then we for added_sets_{1,2} should just make copies of i1src resp. i0src
upfront, which means perhaps slightly bigger amount of GC, but at least it
won't miscompile things.

If the modification in place is undesirable, then e.g. force_to_mode is
something that modifies rtx in place very deep into it.

This untested fix cures the testcase on a cross to arm.

[Bug target/52137] bdver2 scheduler needs to be added to bdver1 insn reservations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|blocker |normal

[Bug target/52137] New: bdver2 scheduler needs to be added to bdver1 insn reservations

[qneill at gcc dot gnu.org]

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

 Bug #: 52137
   Summary: bdver2 scheduler needs to be added to bdver1 insn
reservations
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: qne...@gcc.gnu.org


Created attachment 26585
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26585
Add bdver2 to list of cpu attributes for bdver1.md insn reservations

The bdver2 scheduler lacks insn reservation conditions for cpu attributes in
the bdver1.md model.  The resulting generated code regresses on bdver2 hardware
for SPEC and polyhedron.

The attached patch recovers most of this performance regression.

[Bug bootstrap/7125] libz is built even if configured with --with-system-zlib

[richard.purdie at linuxfoundation dot org]

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

--- Comment #11 from Richard Purdie  
2012-02-06 16:23:16 UTC ---
Sorry, my previous report should be disregarded as it was user error. The
option does appear to work for me, removing the zlib compile where it was
previously present.

[Bug libgcj/51500] [4.7 regression] 106 unexpected libjava testsuite failures with mingw32

[jojelino at gmail dot com]

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

gee  changed:

   What|Removed |Added

  Attachment #26574|0   |1
is obsolete||

--- Comment #24 from gee  2012-02-06 16:18:44 UTC ---
Created attachment 26584
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26584
proposed patch for workaround TestEarlyGC failure

fixed wrong assumption to the code. but got following in ExtraClassLoader test
Starting program: /tmp/gcc/i686-pc-mingw32/libjava/.libs/gij -cp
D:\\cygwin\\tmp\\gcc\\libjava\\testsuite\\libjava.lang\\ExtraClassLoader.jar
ExtraClassLoader
[New Thread 5268.0x140c]
[New Thread 5268.0xd84]
Exception in thread "main" java.lang.SecurityException: attempt to use
uninitialized class loader
   at
java.lang.Throwable.(/tmp/gcc/libjava/classpath/java/lang/Throwable.java:161)
   at
java.lang.ClassLoader.checkInitialized(/tmp/gcc/libjava/classpath/java/lang/Exception.java:78)
   at
java.lang.ClassLoader.findLoadedClass(/tmp/gcc/libjava/java/lang/ClassLoader.java:694)
   at
java.lang.Class.forName(/tmp/gcc/i686-pc-mingw32/libjava/../.././libjava/java/lang/natClass.cc:105)
   at ExtraClassLoader.main(ExtraClassLoader.java:8)
[Inferior 1 (process 5268) exited with code 01]
(gdb)

[Bug libstdc++/52128] [4.7 regression] r183788 caused massive libstdc++ testsuite regression on i686-linux

[mikpe at it dot uu.se]

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

--- Comment #6 from Mikael Pettersson  2012-02-06 
16:03:09 UTC ---
(In reply to comment #3)
> Created attachment 26579 [details]
> does this patch fix it?

It does, thanks.

> What configure command are you running?

/tmp/gcc-4.7-20120204/configure --prefix=/tmp/install47
--with-gmp=/home/mikpe/pkgs/linux-x86/gmp-5.0.2
--with-mpfr=/home/mikpe/pkgs/linux-x86/mpfr-3.1.0
--with-mpc=/home/mikpe/pkgs/linux-x86/mpc-0.9
--disable-build-poststage1-with-cxx --disable-libquadmath --disable-plugin
--disable-lto --disable-nls --disable-shared --disable-libmudflap
--disable-libgomp --enable-threads=posix --enable-checking=release
--enable-languages=c,c++

> Have you tried a clean build in an empty objdir?

I always build gcc in an empty objdir.

> what version of binutils are you using?

binutils-2.20.51.0.7-8.fc14.i686

Fedora 14 user-space, but with a gcc-4.5.3 host compiler and a linux-3.2
kernel.

[Bug fortran/52117] allocated arrays give incorrect results when used with RESHAPE in gcc v4.6.2

[sphirshman at yahoo dot com]

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

--- Comment #2 from steven hirshman  2012-02-06 
15:37:35 UTC ---
Thank you for the information. THe work-around works with the newer (4.6.2)
compiler, but is unrecognized by older versions of gcc that are in use on - for
example - NERSC computers.

Is there a FIX other than the workaround planned, that will be backwards
compatible with older compilers?

Also, the B(:) fails on some platforms, I'm told by some of my co-workers.



From: burnus at gcc dot gnu.org 
To: sphirsh...@yahoo.com 
Sent: Friday, February 3, 2012 3:41 PM
Subject: [Bug fortran/52117] allocated arrays give incorrect results when used
with RESHAPE in gcc v4.6.2

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

Tobias Burnus  changed:

          What    |Removed                    |Added

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

--- Comment #1 from Tobias Burnus  2012-02-03
20:41:32 UTC ---
Work around: -fno-realloc-lhs

Or add "(:)"
  B(:) = RESHAPE(A, SHAPE(B))

Solution: Update - it has just been fixed in the last days.

Thanks for the report!

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

[Bug tree-optimization/52115] [4.7 Regression] ICE: verify_ssa failed (missing definition for SSA_NAME)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Richard Guenther  2012-02-06 
15:14:46 UTC ---
Fixed.

[Bug bootstrap/7125] libz is built even if configured with --with-system-zlib

[richard.purdie at linuxfoundation dot org]

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

Richard Purdie  changed:

   What|Removed |Added

 CC||richard.purdie at
   ||linuxfoundation dot org

--- Comment #10 from Richard Purdie  
2012-02-06 15:09:38 UTC ---
This bug is still present in gcc 4.6 as I've configured with --with-system-zlib
yet it still builds zlib for the host.

[Bug tree-optimization/52115] [4.7 Regression] ICE: verify_ssa failed (missing definition for SSA_NAME)

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-02-06 
14:54:54 UTC ---
Author: rguenth
Date: Mon Feb  6 14:54:47 2012
New Revision: 183937

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183937
Log:
2012-02-06  Richard Guenther  

PR tree-optimization/52115
* tree-sra.c (access_has_replacements_p): New function.
(sra_modify_assign): Use it to decide whether a use is uninitialized.

* gcc.c-torture/compile/pr52115.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr52115.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug middle-end/52047] [trans-mem] ICE: SIGSEGV in execute_tm_mark (trans-mem.c:2270) with -O -fgnu-tm -fprefetch-loop-arrays

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #4 from Aldy Hernandez  2012-02-06 
14:44:31 UTC ---
fixed on trunk

[Bug middle-end/52047] [trans-mem] ICE: SIGSEGV in execute_tm_mark (trans-mem.c:2270) with -O -fgnu-tm -fprefetch-loop-arrays

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez  2012-02-06 
14:42:11 UTC ---
Author: aldyh
Date: Mon Feb  6 14:42:07 2012
New Revision: 183936

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183936
Log:
PR middle-end/52047
* trans-mem.c (expand_call_tm): Add an assertion.
* calls.c (flags_from_decl_or_type): Add ECF_TM_PURE to 'no vops'
functions.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/trans-mem.c

[Bug middle-end/52047] [trans-mem] ICE: SIGSEGV in execute_tm_mark (trans-mem.c:2270) with -O -fgnu-tm -fprefetch-loop-arrays

[patrick.marlier at gmail dot com]

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

Patrick Marlier  changed:

   What|Removed |Added

 CC||patrick.marlier at gmail
   ||dot com

--- Comment #2 from Patrick Marlier  
2012-02-06 14:34:24 UTC ---
Proposed fix here:
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00096.html

Waiting Rth approval and Aldy's kindness for commit.
--
Patrick Marlier.

[Bug rtl-optimization/52060] Incorrect mask/and (ARM "bic") instruction generated for shifted expression parameter, triggered by -O2 -finline-functions

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Last reconfirmed|2012-02-03 00:00:00 |2012-02-06 0:00
  Component|target  |rtl-optimization

--- Comment #5 from Richard Earnshaw  2012-02-06 
14:28:20 UTC ---
Looks like a combine bug to me.  We have the following three insns passed to
combine:

i3 = (insn 49 48 50 5 (set (reg:SI 192)
(lshiftrt:SI (reg/v:SI 155 [ linear ])
(const_int 13 [0xd]))) bug.c:47 125 {*arm_shiftsi3}
 (nil))

i2 = (insn 46 72 48 5 (set (reg/v:SI 155 [ linear ])
(and:SI (reg:SI 154 [ iftmp.1 ])
(reg:SI 176 [ prephitmp.29 ]))) bug.c:24 75 {*arm_andsi3_insn}
 (expr_list:REG_DEAD (reg:SI 176 [ prephitmp.29 ])
(expr_list:REG_DEAD (reg:SI 154 [ iftmp.1 ])
(nil

i1 = (insn 72 41 46 5 (set (reg:SI 154 [ iftmp.1 ])
(if_then_else:SI (eq (reg:CC_NOOV 24 cc)
(const_int 0 [0]))
(const_int -2 [0xfffe])
(const_int -1 [0x]))) bug.c:23 234 {*movsicc_insn}
 (expr_list:REG_DEAD (reg:CC 24 cc)
(nil)))

Note that the result of i2 does not die in i3.  Nevertheless, we simplify this
expression to the form

(parallel [
(set (reg:SI 192)
(lshiftrt:SI (and:SI (if_then_else:SI (eq (reg:CC_NOOV 24 cc)
(const_int 0 [0]))
(const_int -8192 [0xe000])
(const_int -8192 [0xe000]))
(reg:SI 176 [ prephitmp.29 ]))
(const_int 13 [0xd])))
(set (reg/v:SI 155 [ linear ])
(and:SI (if_then_else:SI (eq (reg:CC_NOOV 24 cc)
(const_int 0 [0]))
(const_int -8192 [0xe000])
(const_int -8192 [0xe000]))
(reg:SI 176 [ prephitmp.29 ])))
])

The choice of -8192 for the constant in the if-then-else expressions seems to
come from the fact that i3 will shift the result right by 13 (ie 0x1fff) and
that therefore we can exclude those bits from the and operation (which will
ultimately collapse the if-then-else into a single constant).  However, that is
only true in the first of the two operations in the parallel above.  It's not
true for the second operation.

Over to the combine experts.

[Bug c++/52136] g++ is wrongly propagating "friend class" to the parent class

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-02-06 
14:24:39 UTC ---
(In reply to comment #4)
> I am not really sure to understand why friend class should impact his parent
> but if g++ respects the standard, why not...

It doesn't "impact his parent"

Read comment 2 again.  To access a protected non-static member you must do so
though an object expression of the derived type, because in the expression
'p->address::m' you only know if 'm' is a member of a 'mailbox' object when 'p'
has type 'mailbox*'

But for a static member that is irrelevant, the static member just exists
independently of any 'mailbox' or 'address' instance, so if mailboxField can
access members of 'mailbox' then it can access the static member, and it
doesn't matter if you refer to it as 'mailbox::parseNext' or
'address::parseNext' because both refer to the exact same entity.

[Bug fortran/41587] [OOP] ICE with ALLOCATABLE CLASS components

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #7 from Paul Thomas  2012-02-06 14:20:22 
UTC ---
As of yesterday, the testcase in comment #1 compiles and runs successfully.  We
now just need the error message for the original problem.

Cheers

Paul

[Bug tree-optimization/51528] [4.6 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

 Depends on||52115

--- Comment #8 from Richard Guenther  2012-02-06 
14:13:48 UTC ---
On ppc the main SRA pass does nothing to foo () because of differences in
how the return value is returned.  Still the IL at expansion time looks
great:

foo ()
{
:
  .b = 1;
  use_bool ();
  .i = 65534;
  return ;

}

compared to x86_64 where we have the uglier

foo ()
{
  union U u;
  union U D.1733;

:
  u.b = 1;
  use_bool (u);
  u = VIEW_CONVERT_EXPR(65534);
  D.1733 = u;
  u ={v} {CLOBBER};
  return D.1733;

Compared to -fno-tree-sra on PPC we have

foo ()
{
  union U u;

:
  .b = 1;
  use_bool ();
  u.i = 65534;
   = u;
  u ={v} {CLOBBER};
  return ;

so SRA managed to remove the aggregate temporary and its copy.

So, I don't see what's wrong on PPC (with SRA, that is).  This must be
a target bug if at all (note I'm only inspecting dumps and did not
reproduce the execute fail).

[Bug c++/52136] g++ is wrongly propagating "friend class" to the parent class

[sylvestre at debian dot org]

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

--- Comment #4 from Sylvestre Ledru  2012-02-06 
14:08:21 UTC ---
I found this bug (or behavior) while playing with clang. 

I am not really sure to understand why friend class should impact his parent
but if g++ respects the standard, why not...

[Bug middle-end/52134] Does not fold (x * 4) & -4

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-06
 Ever Confirmed|0   |1

--- Comment #1 from Eric Botcazou  2012-02-06 
14:08:13 UTC ---
> The above expression computes non-constant
> 
> ((ssizetype) (((sizetype) MAX_EXPR  + 2) * 4) & -4) - (ssizetype)
> ((sizetype) MAX_EXPR  * 4)
> 
> Not sure if such an expression cannot be reliably required to be constant
> in ada though.

Reassociation/simplification of size expressions can generally be done at will.

> Certainly this looks like a missed folding (not sure how often this
> odd BIT_AND_EXPR for sizes happen in Ada).

Quite a lot, but it's created by the folder itself (round_up).

[Bug fortran/51514] [OOP] Wrong code when passing a scalar CLASS to a TYPE

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2012-02-06 
14:04:29 UTC ---
Created attachment 26583
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26583
Completely untested/not compiled draft patch

The attached patch is completely untested. It additionally contains some - also
untested - fixes for polymophic coarrays.

Variant:

  subroutine subpr2(x)
type(foo) :: x
print *,x%i
if (x%i /= 55) call abort ()
  end subroutine
  function f()
class(foo), allocatable :: f
allocate (f)
f%i = 55
  end function f
with
  call subpr(f())

[Bug c++/52136] g++ is wrongly propagating "friend class" to the parent class

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Jonathan Wakely  2012-02-06 
13:56:58 UTC ---
Clang gets this wrong on purpose: http://llvm.org/bugs/show_bug.cgi?id=6840

But G++ implements what the standard says, so INVALID

[Bug target/38342] [4.4/4.5/4.6/4.7 Regression] __attribute__((__progmem__)) not propagated from typedef to data

[gjl at gcc dot gnu.org]

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

--- Comment #13 from Georg-Johann Lay  2012-02-06 
13:55:09 UTC ---
For avr-libc users, please f'up to
http://savannah.nongnu.org/bugs/?33716

[Bug c++/52136] g++ is wrongly propagating "friend class" to the parent class

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-02-06 
13:50:40 UTC ---
I think G++ is correct here.

[class.protected]p1
An additional access check beyond those described earlier in Clause 11 is
applied when a non-static data member or non-static member function is a
protected member of its naming class (11.2)*

* This additional check does not apply to other members, e.g., static data
members or enumerator member constants.


address::parseNext refers to the same entity as mailbox::parseNext and access
to static members does not involve an object expression, so there is no need
for that access to be done through an object expression of the derived type.

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #13 from Richard Guenther  2012-02-06 
13:43:23 UTC ---
Fixed.

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther  2012-02-06 
13:43:06 UTC ---
Author: rguenth
Date: Mon Feb  6 13:43:03 2012
New Revision: 183934

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183934
Log:
2012-02-06  Richard Guenther  

PR tree-optimization/50955
* tree-ssa-loop-ivopts.c (get_computation_cost_at): Artificially
raise cost of expressions that replace an address with an
expression based on a different pointer.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-loop-ivopts.c

[Bug c++/52136] g++ is wrongly propagating "friend class" to the parent class

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-02-06 
13:40:08 UTC ---
EDG and Solaris CC also accept it, clang doesn't

The code looks similar to this example from [class.protected] in the standard:

class B {
protected:
int i;
static int j;
};
class D1 : public B {
};
class D2 : public B {
friend void fr(B*,D1*,D2*);
};
void fr(B* pb, D1* p1, D2* p2) {
// ...
p2->i = 3;// OK (access through a D2)
p2->B::i = 4; // OK (access through a D2, even though
  // naming class is B)
// ...
B::j = 5; // OK (because refers to static member)
D2::j = 6;// OK (because refers to static member)
}

Note that the friend of D2 can access non-static members of B through D2* and
can access static members of B directly.

[Bug target/52129] wrong code to pass parameters to tail call function

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-02-06 
13:35:18 UTC ---
Fixed on the trunk so far.

[Bug target/52129] wrong code to pass parameters to tail call function

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-02-06 
13:33:09 UTC ---
Author: jakub
Date: Mon Feb  6 13:33:05 2012
New Revision: 183933

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183933
Log:
PR target/52129
* calls.c (mem_overlaps_already_clobbered_arg_p): If val is
CONST_INT_P, subtract resp. add crtl->args.pretend_args_size to it.

* gcc.c-torture/execute/pr52129.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr52129.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/52136] New: g++ is wrongly propagating "friend class" to the parent class

[sylvestre at debian dot org]

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

 Bug #: 52136
   Summary: g++ is wrongly propagating "friend class" to the
parent class
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sylves...@debian.org


---
class address 
{
protected:
static int parseNext(int a);
};


class mailbox : public address
{
friend class mailboxField;
};

class mailboxField
{
void parse(int a)
{
address::parseNext(a);
// will work with:
// mailbox::parseNext(a);
}
};
---

It should trigger:
address.cpp: In member function ‘void mailboxField::parse(int)’:
address.cpp:4:16: error: ‘static int address::parseNext(int)’ is protected
address.cpp:17:33: error: within this context

Tested with g++ 4.6.2

[Bug tree-optimization/52115] [4.7 Regression] ICE: verify_ssa failed (missing definition for SSA_NAME)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target|avr |
  Component|other   |tree-optimization
  Known to work||4.6.2
   Target Milestone|--- |4.7.0
Summary|ICE: verify_ssa failed  |[4.7 Regression] ICE:
   |(missing definition for |verify_ssa failed (missing
   |SSA_NAME)   |definition for SSA_NAME)

--- Comment #3 from Richard Guenther  2012-02-06 
13:08:27 UTC ---
Testcase that fails on x86_64:

struct S
{
  float f;
  long l;
};

extern int gi;
extern float gf;

long foo (long p)
{
  struct S s;
  float *pf;

  s.l = p;

  pf = &s.f;

  pf++;
  pf--;

  gf = *pf + 3.3;
  gi = *((short *)pf) + 2;

  return s.l + 6;
}

I have a patch.

[Bug other/52115] ICE: verify_ssa failed (missing definition for SSA_NAME)

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Guenther  2012-02-06 
12:59:23 UTC ---
Mine.

[Bug libstdc++/52128] [4.7 regression] r183788 caused massive libstdc++ testsuite regression on i686-linux

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-02-06 
12:46:27 UTC ---
Great, thanks for testing it, I'll check it in this evening.

[Bug libstdc++/52128] [4.7 regression] r183788 caused massive libstdc++ testsuite regression on i686-linux

[mario-baumann at web dot de]

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

--- Comment #4 from Mario Baumann  2012-02-06 
12:41:11 UTC ---
Hi Jonathan,

the attached fix works for bug 52133. Thanks!

Mario.

[Bug middle-end/51929] [4.7 Regression] ICE: verify_cgraph_node failed with -O2 -fno-guess-branch-probability -fipa-cp-clone

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

[Bug middle-end/51994] [4.6/4.7 Regression] git-1.7.8.3 miscompiled due to negative bitpos from get_inner_reference

[ebotcazou at gcc dot gnu.org]

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

--- Comment #35 from Eric Botcazou  2012-02-06 
12:29:06 UTC ---
> So your patch is probably ok (can you try verifying we don't get
> (too much) codegen differences on a bootstrap?)

There are no differences for a compiler build on Alpha and i586 (4.6 branch).

[Bug target/51106] [4.5/4.6 Regression] ICE in move_insn, at haifa-sched.c:2314

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2012-02-06 
12:26:48 UTC ---
Yes, it is ok for the affected branches if bootstrap/regtest passes.

[Bug target/51106] [4.5/4.6 Regression] ICE in move_insn, at haifa-sched.c:2314

[abel at gcc dot gnu.org]

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

--- Comment #7 from Andrey Belevantsev  2012-02-06 
12:10:17 UTC ---
(In reply to comment #6)
> Can this be applied to 4.5/4.6 please?

Well, the patch was approved for trunk only, but it is committed for two weeks
now and looks safe -- Jakub?

[Bug fortran/51514] [OOP] Wrong code when passing a scalar CLASS to a TYPE

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

Summary|[OOP] Wrong code when   |[OOP] Wrong code when
   |passing a CLASS to a TYPE   |passing a scalar CLASS to a
   ||TYPE

--- Comment #4 from Tobias Burnus  2012-02-06 
11:04:25 UTC ---
Actually, the issue seems to only affect scalar polymorphic variables.

If the actual argument is a polymorphic array, it works. Both as argument to an
elemental function and to an array dummy argument.

[Bug middle-end/52134] New: Does not fold (x * 4) & -4

[rguenth at gcc dot gnu.org]

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

 Bug #: 52134
   Summary: Does not fold (x * 4) & -4
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: ebotca...@gcc.gnu.org


We appearantly do not fold

((sizetype) MAX_EXPR  + 2) * 4

BIT_AND_EXPR

-4

as it happens for TYPE_SIZE_UNIT of a struct for gnat.dg/opt9.adb.

This causes an issue with trying to compute the extent/padding of
a trailing bitfield in such a struct when you do

size_diffop (TYPE_SIZE_UNIT (DECL_CONTEXT (field)),
 DECL_FIELD_OFFSET (repr));

where repr is the first field of a bitfield group and field is the last
field of a bitfield group.

The above expression computes non-constant

((ssizetype) (((sizetype) MAX_EXPR  + 2) * 4) & -4) - (ssizetype)
((sizetype) MAX_EXPR  * 4)

Not sure if such an expression cannot be reliably required to be constant
in ada though.

Certainly this looks like a missed folding (not sure how often this
odd BIT_AND_EXPR for sizes happen in Ada).

[Bug c/52118] The explanation of Wunused-local-typedefs is truncated

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Paolo Carlini  2012-02-06 
10:34:51 UTC ---
Fixed.

[Bug c/52118] The explanation of Wunused-local-typedefs is truncated

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  
2012-02-06 10:31:23 UTC ---
Author: paolo
Date: Mon Feb  6 10:31:18 2012
New Revision: 183932

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183932
Log:
2012-02-06  Paolo Carlini  

PR c/52118
* c.opt ([Wunused-local-typedefs]): Fix description.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt

[Bug debug/52132] [4.7 Regression] ICE in loc_descriptor

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2012-02-06 
10:23:31 UTC ---
Created attachment 26581
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26581
gcc47-pr52132.patch

Untested fix.  What get_true_reg does might be reasonable for code where we
have quite strict requirements on what SUBREG can be applied or not, but it is
definitely wrong for arbitrary SUBREGs in DEBUG_INSNs.  In fact, I don't see
what get_true_reg would buy us, we get at the real REG in for_each_rtx anyway
and can keep the SUBREGs, FLOAT_EXTEND etc. in the DEBUG_INSN.