[Bug c++/52529] Compiler rejects template code inconsistently

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-03-08 
08:25:48 UTC ---
A().foo(x);
Should be:
A().template foo(x);

[Bug middle-end/52097] ICE: in get_bit_range, at expr.c:4535 with -O -flto -fexceptions -fnon-call-exceptions --param allow-store-data-races=0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Andrew Pinski  2012-03-08 
08:24:56 UTC ---
(In reply to comment #10)
> (In reply to comment #8)
> > Author: rguenth
> > Date: Tue Mar  6 09:54:06 2012
> > New Revision: 184981
> 
> This patch seems to have introduced the following testsuite fails on s390x:

The PR for that testcase was reopened.

[Bug c++/52529] Compiler rejects template code inconsistently

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Andrew Pinski  2012-03-08 
08:31:16 UTC ---
All error messages seems correct to me.
template  long foo(typename T::X *x);

1/3) A().foo(x);
Where x is of some type.  T cannot be deduced from T::X where T::X would be
some type.

2) I already explained in comment #1.  You are missing a template keyword.

>all four variants compile under 4.5.3. 

Yes and it looks like GCC is actually better at rejecting invalid code.

[Bug c++/52529] Compiler rejects template code inconsistently

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  
2012-03-08 08:50:59 UTC ---
The compiler is correct to reject your example FIRST, SECOND, and THIRD.

In FIRST and THIRD you are effectively asking to deduce T from

template  long foo(typename T::X *x);

which is not possible in the general case, we have a so-called non-deduced
context here.

In SECOND you fixed the problem of FIRST correctly, but now you have the
problem that A is a dependent context. This means, that the compiler has to
guess on the meaning of "().template foo(x);

Thus, this issue should be declared as invalid.

[Bug c++/52529] Compiler rejects template code inconsistently

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-03-08 
09:28:13 UTC ---
(In reply to comment #1)
> A().foo(x);
> Should be:
> A().template foo(x);

This is a FAQ

http://womble.decadent.org.uk/c++/template-faq.html#disambiguation

[Bug target/51244] SH Target: Inefficient conditional branch

[kkojima at gcc dot gnu.org]

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

--- Comment #24 from Kazumoto Kojima  2012-03-08 
11:11:32 UTC ---
(In reply to comment #23)
> Kaz, if you have some time, could you try it out in your setup, too please?

On trunk revision 185088, for sh4-unknown-linux-gnu, the result of
compare_tests is:

New tests that FAIL:

gfortran.dg/associated_4.f90  -O1  execution test
gfortran.dg/forall_4.f90  -O3 -fomit-frame-pointer  execution test
gfortran.dg/forall_4.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
gfortran.dg/forall_4.f90  -O3 -fomit-frame-pointer -funroll-loops  execution
test
gfortran.dg/forall_4.f90  -O3 -g  execution test

Old tests that failed, that have disappeared: (Eeek!)

22_locale/ctype/is/char/3.cc execution test
27_io/basic_filebuf/underflow/wchar_t/9178.cc execution test
gfortran.dg/widechar_intrinsics_6.f90  -Os  execution test

[Bug target/51244] SH Target: Inefficient conditional branch

[kkojima at gcc dot gnu.org]

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

--- Comment #25 from Kazumoto Kojima  2012-03-08 
11:13:39 UTC ---
Created attachment 26854
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26854
worked .s file associated_4_good.s

[Bug target/52496] avr-specific built-ins missing memory barrier

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  2012-03-08 
11:14:11 UTC ---
Author: gjl
Date: Thu Mar  8 11:14:05 2012
New Revision: 185100

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185100
Log:
PR target/52496
* config/avr/avr.c (avr_mem_clobber): New static function.
(avr_expand_delay_cycles): Add memory clobber operand to
delay_cycles_1, delay_cycles_2, delay_cycles_3, delay_cycles_4.
* config/avr/avr.md (unspec): Add UNSPEC_MEMORY_BARRIER.
(enable_interrupt, disable_interrupt): New expander.
(nopv, sleep, wdr): New expanders.
(delay_cycles_1): Add memory clobber.
(delay_cycles_2): Add memory clobber.
(delay_cycles_3): Add memory clobber.
(delay_cycles_4): Add memory clobber.
(cli_sei): New insn from former "enable_interrupt",
"disable_interrupt" with memory clobber.
(*wdt): New insn from former "wdt" with memory clobber.
(*nopv): Similar, but for "nopv".
(*sleep): Similar, but for "sleep".


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.md

[Bug target/51244] SH Target: Inefficient conditional branch

[kkojima at gcc dot gnu.org]

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

--- Comment #26 from Kazumoto Kojima  2012-03-08 
11:16:39 UTC ---
Created attachment 26855
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26855
unworked .s file associated_4_bad.s

I've attached .s files against gfortran.dg/associated_4.f90 -O1 with
patched/unpatched compilers.

[Bug fortran/52469] [4.6/4.7/4.8 Regression] -fwhole-file bug: Wrong backend_decl for result of PPC function

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords|rejects-valid, wrong-code   |ice-on-valid-code
 Status|NEW |ASSIGNED

--- Comment #5 from Tobias Burnus  2012-03-08 
11:32:50 UTC ---
The problem already occurs for gfc_get_derived_type's call to gfc_get_ppc_type,
which calls in turn gfc_get_function_type.

For -fno-whole-file), gfc_get_function_type returns the function decl, for
-fwhole-file it returns a pointer to the function decl.

The reason is that for -fwhole-file, "sym" (sym->name == "func") already has a
backend_decl - one which has a pointer.

 * * *

Actually, the example source code is rather tricky:

  pointer :: func
  interface
 function func (z)
real :: func
real, intent (in) :: z
 end function func
  end interface

This declares a procedure pointer "func", i.e. it's the same as:

  abstract interface
 function template (z)
real :: template
real, intent (in) :: z
 end function template
  end interface
  procedure(template), pointer :: func


But at the same time, the original "func" is used as:

  type Contains_f_ptr
 procedure (func), pointer, nopass :: my_f_ptr
  end type Contains_f_ptr

Where "func" denotes the interface to which the procedure pointer points to
(i.e. "template" in the modified exampled). In trans-type.c, the proc pointer
is completely unexpected and thus it fails.

It should be possible to modify the example such that it also fails with
-fno-whole-file.


Draft patch:

--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2680,3 +2694,7 @@ gfc_get_function_type (gfc_symbol * sym)
   if (sym->backend_decl)
-return TREE_TYPE (sym->backend_decl);
+{
+  if (sym->attr.proc_pointer)
+   return TREE_TYPE (TREE_TYPE (sym->backend_decl));
+  return TREE_TYPE (sym->backend_decl);
+}

[Bug libitm/52526] libitm: stuck in futex_wait

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug target/52530] New: [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as

[ro at gcc dot gnu.org]

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

 Bug #: 52530
   Summary: [4.8 regression] Many 64-bit execution failures on
Solaris 10/11 with Sun as
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: h...@gcc.gnu.org, ubiz...@gmail.com
  Host: i386-pc-solaris2.1[01]
Target: i386-pc-solaris2.1[01]
 Build: i386-pc-solaris2.1[01]


Between 20120302 and 20120307, many 64-bit execution tests all over the
testsuite
started to fail on Solaris 10 and 11/x86 when using Sun as.  With gas, all is
fine.

E.g.

FAIL: gcc.c-torture/execute/20021120-1.c execution,  -O3 -fomit-frame-pointer
-funroll-loops

The test aborts, and can be reproduced with -m64 -O1 -funroll-loops.  If I add
printf's to investigate the failure (gdb cannot print optimized-out values
here),
the failure vanishes.

Between .s files for as and gas, there are no codegen differences when using
-fno-dwarf2-cfi-asm.

When I compare the 4.7 and mainline .s files with as, I find lots of changes
like

--- 20021120-1.s2012-03-08 13:00:25.054484596 +0100
+++ /var/gcc/regression/trunk/10-gcc/build/gcc/testsuite/gcc/20021120-1.s
2012-03-08 12:48:21.890112842 +0100
@@ -534,37 +534,37 @@
movsd   %xmm2, gd(,%rcx,8)
cvtsi2ss%eax, %xmm3
movss   %xmm3, gf(,%rcx,4)
-   leal1(%rax), %edi
+   leal1(%eax), %edi
cvtsi2sd%edi, %xmm4
movslq  %edi, %r8
movsd   %xmm4, gd(,%r8,8)

A reghunt revealed that this was caused by this patch:

2012-03-04  H.J. Lu  

   * config/i386/i386.c (ix86_print_operand_address): Only handle
   zero-extended DImode addresses.

I'm now trying another bootstrap with this change reverted to see if this fixes
all the failures.

  Rainer

[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as

[ubizjak at gmail dot com]

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

--- Comment #1 from Uros Bizjak  2012-03-08 13:49:52 
UTC ---
Ouch.

Before the change, we always used "q" modifier for addresses, only in two
special cases we emitted "l". This "q" modifier forced DImode address even for
SImode operands, avoiding addr32 prefixes.

The change - while correct - cancelled this optimization.

So, please revert this patch ASAP.

Also, Sun is buggy in the way addr32 prefix is handled.

[Bug fortran/52531] New: Compilation fails with polymorphic dummy argument and OpenMP

[kaladhorn at me dot com]

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

 Bug #: 52531
   Summary: Compilation fails with polymorphic dummy argument and
OpenMP
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kaladh...@me.com


The following code does not compile:

--
module test_mod
  type, public :: test_type
  end type
contains
  subroutine foo(bar)
type(test_type) :: bar
!$omp parallel default(none) shared(bar) ! Compiles if one removes
default(none)
call question(bar)
!$omp end parallel
  end subroutine
  subroutine question(var)
class(test_type), intent(in) :: var ! Compiles if one replaces class by
type
  end subroutine
end module
--

The error message is:
‘__vtab_test_mod_Test_type’ not specified in enclosing parallel

This was reproduced with gfortran 4.6 (gcc version 4.6.3 (GCC) ) and 4.7 (gcc
version 4.7.0 20120121 (experimental) (GCC) ) on x86_64-unknown-linux-gnu .

[Bug c++/40056] implicit instantiation of function templates fails with -O2, works with -O and -g...

[bircoph at gmail dot com]

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

Andrew Savchenko  changed:

   What|Removed |Added

 CC||bircoph at gmail dot com

--- Comment #5 from Andrew Savchenko  2012-03-08 
14:28:48 UTC ---
The problem is still here with gcc-4.5.3 if compiled with -O3:

x86_64-pc-linux-gnu-gcc -O -march=core2 -m64 -c TStreamerInfoReadBuffer.cxx -o
TStreamerInfoReadBuffer-1.o
x86_64-pc-linux-gnu-gcc -O2 -march=core2 -m64 -c TStreamerInfoReadBuffer.cxx -o
TStreamerInfoReadBuffer-2.o
x86_64-pc-linux-gnu-gcc -O3 -march=core2 -m64 -c TStreamerInfoReadBuffer.cxx -o
TStreamerInfoReadBuffer-1.o

nm TStreamerInfoReadBuffer-1.o | grep
_ZN13TStreamerInfo10ReadBufferIPPcEEiR7TBufferRKT_
 W _ZN13TStreamerInfo10ReadBufferIPPcEEiR7TBufferRKT_
nm TStreamerInfoReadBuffer-2.o | grep
_ZN13TStreamerInfo10ReadBufferIPPcEEiR7TBufferRKT_
 W _ZN13TStreamerInfo10ReadBufferIPPcEEiR7TBufferRKT_
nm TStreamerInfoReadBuffer-3.o | grep
_ZN13TStreamerInfo10ReadBufferIPPcEEiR7TBufferRKT_
7b10 t
_ZN13TStreamerInfo10ReadBufferIPPcEEiR7TBufferRKT_.clone.26

The guilty is -fipa-cp-clone option. Without it symbol is defined well:
x86_64-pc-linux-gnu-gcc -O3 -fno-ipa-cp-clone -march=core2 -m64 -c
TStreamerInfoReadBuffer.cxx -o TStreamerInfoReadBuffer-3-fipa-cp-clone.o
nm TStreamerInfoReadBuffer-3-fipa-cp-clone.o | grep
_ZN13TStreamerInfo10ReadBufferIPPcEEiR7TBufferRKT_
 W _ZN13TStreamerInfo10ReadBufferIPPcEEiR7TBufferRKT_

[Bug c++/40056] implicit instantiation of function templates fails with -O2, works with -O and -g...

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2012-03-08 
14:42:58 UTC ---
It's not a bug though, since you're expecting behaviour which is not guaranteed
and never has been guaranteed.

Why does it matter?  If you have another file where you suppress implicit
instantiation (either by 'extern template' or -fno-implicit-templates) then you
are required to provide an explicit instantiation somewhere in the program.
Assuming an implicit instantiation will happen is an incorrect.

[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2012-03-08 15:06:32 
UTC ---
(In reply to comment #1)
> Ouch.
> 
> Before the change, we always used "q" modifier for addresses, only in two
> special cases we emitted "l". This "q" modifier forced DImode address even for
> SImode operands, avoiding addr32 prefixes.
> 
> The change - while correct - cancelled this optimization.
> 
> So, please revert this patch ASAP.
> 

Uros, can you revert it for me? Thanks.

[Bug fortran/52531] [OOP] Compilation fails with polymorphic dummy argument and OpenMP

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2012-03-08 
15:11:03 UTC ---
OpenMP 3.1 or earlier releases don't cover Fortran 2003 nor 2008, so what you
are trying to compile is not valid.

[Bug c++/40056] implicit instantiation of function templates fails with -O2, works with -O and -g...

[bircoph at gmail dot com]

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

--- Comment #7 from Andrew Savchenko  2012-03-08 
15:11:04 UTC ---
Ok, thanks for clarification. The problem is that I'm not a developer of this
program, I just maintain its package for Gentoo. To make things worse I can't
reproduce the build failure myself on any of my hosts. But users continue to
complain one after another, so this issue needs to be cleared out.

However, I can tell that -fno-implicit-templates was never used during
compilation and I can't find any extern template declarations in that code;
though code is rather sophisticated, I may missed something tricky.

[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org 2012-03-08 15:19:36 UTC ---
Author: uros
Date: Thu Mar  8 15:19:32 2012
New Revision: 185103

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185103
Log:
PR target/52530
Revert:
2012-03-04  H.J. Lu  

* config/i386/i386.c (ix86_print_operand_address): Only handle
zero-extended DImode addresses.


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

[Bug c++/40056] implicit instantiation of function templates fails with -O2, works with -O and -g...

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2012-03-08 
15:48:34 UTC ---
(In reply to comment #6)
> Assuming an implicit instantiation will happen is an incorrect.

... is an incorrect /assumption/  :)

(In reply to comment #7)
> Ok, thanks for clarification. The problem is that I'm not a developer of this
> program, I just maintain its package for Gentoo. To make things worse I can't
> reproduce the build failure myself on any of my hosts. But users continue to
> complain one after another, so this issue needs to be cleared out.

Looking at the preprocessed source I see that the member function template
TStreamerInfo::ReadBuffer is declared in TStreamerInfo.h but only defined in
the .cxx file.  If that function (which is public) is called from a different
.cxx file then it will be implicitly instantiated, which isn't possible if the
definition isn't visible.  The member function template definition should be
moved to the header or there should be an explicit instantiation declaration
(i.e. 'extern template' declaration) in the header and an explicit
instantiation definition in the .cxx file.

[Bug libitm/52482] libitm INVALID MNEMONIC in .S (powerpc asm)

[fang at csl dot cornell.edu]

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

--- Comment #3 from David Fang  2012-03-08 
16:03:46 UTC ---
This build finished, using odcctools' as, but there are some test failures with
libitm.

http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg00893.html

How can I get the failure details for libitm tests from the build dir?

[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

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

--- Comment #4 from Uros Bizjak  2012-03-08 18:16:21 
UTC ---
Fixed by revert.

[Bug c++/52522] Overloaded functions called with initializer lists considered ambiguous

[daniel.kruegler at googlemail dot com]

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

--- Comment #5 from Daniel Krügler  
2012-03-08 18:34:36 UTC ---
(In reply to comment #2)
> but I need to investigate whether this is a language or compiler problem.

It is a language problem. My initial thought that it could be a compiler
problem, is invalid (my thanks to Jason for his help here). The following is
going on here:

The relevant constructors are:

a) template vector(InputIter, InputIter);

and simplified (i.e. ignoring default arguments):

b) vector(initializer_list);

When considering vector, (b) is the clear winner, but when considering
vector (b) would not be viable for {a,b}, so the constructor template
(a) is tried in the second phase and matches as well. There is no ordering
between those two cases, therefore the final ambiguity.

[Bug go/52532] New: Many libgo tests fail with various linker errors

[ubizjak at gmail dot com]

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

 Bug #: 52532
   Summary: Many libgo tests fail with various linker errors
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
AssignedTo: i...@airs.com
ReportedBy: ubiz...@gmail.com
Target: x86_64-pc-linux-gnu


Created attachment 26856
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26856
testsuite log file

Many libgo tests fail on x86_64 Fedora16 with:

/usr/bin/ld: dynamic variable `libgo_encoding.binary.BigEndian' is zero size
/usr/bin/ld: _gotest_.o(.text+0x7c5): unresolvable R_386_32 relocation against
symbol `libgo_encoding.binary.BigEndian'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
FAIL: hash/fnv

There are also following messages in testsuite log:

/usr/bin/ld: dynamic variable `libgo_database_sql.driver.Bool' is zero size
/usr/bin/ld: dynamic variable
`libgo_database_sql.driver.DefaultParameterConverter' is zero size
/usr/bin/ld: _gotest_.o(.text+0xd54e): unresolvable R_X86_64_32 relocation
against symbol `libgo_database_sql.driver.Bool'
/usr/bin/ld: _gotest_.o(.text+0x11239): unresolvable R_X86_64_32 relocation
against symbol `libgo_database_sql.driver.DefaultParameterConverter'
/usr/bin/ld: _gotest_.o(.text+0x15933): unresolvable R_X86_64_32 relocation
against symbol `libgo_database_sql.driver.DefaultParameterConverter'
PASS
PASS: database/sql

[Bug fortran/52531] [OOP] Compilation fails with polymorphic dummy argument and OpenMP

[kaladhorn at me dot com]

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

--- Comment #2 from kaladhorn at me dot com 2012-03-08 19:33:24 UTC ---
(In reply to comment #1)
> OpenMP 3.1 or earlier releases don't cover Fortran 2003 nor 2008, so what you
> are trying to compile is not valid.

hmm that's true, I did not think of it that way. My apologies, then.
However, I think a proper error message would be nice.

Out of curiosity, would there be a technical issue in this case?
It sure seemed natural to me.

Thanks!

[Bug fortran/52469] [4.6/4.7/4.8 Regression] -fwhole-file bug: Wrong backend_decl for result of PPC function

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  2012-03-08 
19:36:53 UTC ---
Author: burnus
Date: Thu Mar  8 19:36:43 2012
New Revision: 185109

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

PR fortran/52469
* trans-types.c (gfc_get_function_type): Handle backend_decl
of a procedure pointer.

2012-03-08  Tobias Burnus  

PR fortran/52469
* gfortran.dg/proc_ptr_34.f90


Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_34.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog

[Bug c/52533] New: ice in remove_range_assertions

[dcb314 at hotmail dot com]

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

 Bug #: 52533
   Summary: ice in remove_range_assertions
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


Created attachment 26857
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26857
C source code

I just tried to compile the package iris-1.0.0
on gcc-4.8 trunk dated 20120307 on an AMD x86_64 box.

The compiler said

jdns.c: In function '_make_printable.part.1':
jdns.c:65:23: internal compiler error: in remove_range_assertions, at
tree-vrp.c:5623
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flag -O2 required.

[Bug c++/52465] [4.7 regression] g++ rejects valid code with in-class using declaration

[fabien at gcc dot gnu.org]

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

fabien at gcc dot gnu.org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot   |fabien at gcc dot gnu.org
   |gnu.org |

--- Comment #5 from fabien at gcc dot gnu.org 2012-03-08 20:41:06 UTC ---
(In reply to comment #4)
> This is because some USING_DECLs are stored in IDENTIDIER_BINDINGs. Jason, do
> you agree that cxx_binding->value and cxx_binding->type should not be
> USING_DECLs ?

Nonsense, it cannot works. I am testing a patch...

[Bug c++/40056] implicit instantiation of function templates fails with -O2, works with -O and -g...

[bircoph at gmail dot com]

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

--- Comment #9 from Andrew Savchenko  2012-03-08 
20:44:24 UTC ---
(In reply to comment #8)
> Looking at the preprocessed source I see that the member function template
> TStreamerInfo::ReadBuffer is declared in TStreamerInfo.h but only defined in
> the .cxx file.  If that function (which is public) is called from a different
> .cxx file then it will be implicitly instantiated, which isn't possible if the
> definition isn't visible.  The member function template definition should be
> moved to the header or there should be an explicit instantiation declaration
> (i.e. 'extern template' declaration) in the header and an explicit
> instantiation definition in the .cxx file.

Hmm, I can't understand this (though I don't know all the details of the C++
standard). If I'm writing class MyClass with public method Read, this is
absolutely normal to declare Read function in the class declaration in the
MyClass.h header and define it in the MyClass.cpp. Templates are supposed to
work just as a normal functions, with the difference that code is written once,
instead of writing a bunch of overloaded functions.

If all templates must be defined in the single header, this would make an
thousands lines of code header file. And explicit template will require
compile-tyme type specification, which is impossible due to RTTI being used.

[Bug c++/40056] implicit instantiation of function templates fails with -O2, works with -O and -g...

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2012-03-08 
21:05:02 UTC ---
(In reply to comment #9)
> Hmm, I can't understand this (though I don't know all the details of the C++
> standard). If I'm writing class MyClass with public method Read, this is
> absolutely normal to declare Read function in the class declaration in the
> MyClass.h header and define it in the MyClass.cpp. Templates are supposed to
> work just as a normal functions, with the difference that code is written 
> once,
> instead of writing a bunch of overloaded functions.

No, they aren't just like normal functions.

Maybe you should read
http://www.parashift.com/c++-faq-lite/templates.html#faq-35.12

> If all templates must be defined in the single header, this would make an
> thousands lines of code header file.

Who said they have to be in a /single/ header?

Have you ever looked at the implementation of e.g.  or ?
They're entirely defined in headers.  There's a reason for that.

> And explicit template will require
> compile-tyme type specification, which is impossible due to RTTI being used.

I don't know what RTTI has to do with anything and don't know what you mean.

The explicit instantiation you need is the one that you get a linker error for
i.e.
extern template
  int TStreamerInfo::ReadBuffer(TBuffer&, char** const&, int, int, int, int);

[Bug tree-optimization/52533] [4.8 Regression] ice in remove_range_assertions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-03-08
  Component|c   |tree-optimization
 CC||jakub at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1
Summary|ice in  |[4.8 Regression] ice in
   |remove_range_assertions |remove_range_assertions
   Target Milestone|--- |4.8.0

--- Comment #1 from Jakub Jelinek  2012-03-08 
21:07:01 UTC ---
Most likely my recent tree-vrp.c patch, will have a look.

[Bug c/52534] New: gcc doesn't detect incorrect expression in call to va_start

[mib.bugzilla at gmail dot com]

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

 Bug #: 52534
   Summary: gcc doesn't detect incorrect expression in call to
va_start
Classification: Unclassified
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mib.bugzi...@gmail.com


The C standard is very clear that the second argument to va_start is a
parameter identifier, not an expression. 

For example,

int maxof(int, ...) ;
void f(void);

int maxof(int n_args, ...){
register int i;
int max, a;
va_list ap;
va_start(ap, (unsigned int)n_args);
max = va_arg(ap, int);
for(i = 2; i <= n_args; i++) {
   if((a = va_arg(ap, int)) > max) max = a;
}
va_end(ap);
return max;
}

Intel compiler finds the bug:
vaarg.c(12): error: incorrect use of va_start
  va_start(ap, (unsigned int)n_args);
  ^

[Bug c++/40056] implicit instantiation of function templates fails with -O2, works with -O and -g...

[Fons.Rademakers at cern dot ch]

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

--- Comment #11 from Fons Rademakers  
2012-03-08 21:16:57 UTC ---
Hi Andrew,

  the source code now (r43307) uses explicit instantiation and should work on
Gentoo with all compiler versions and optimization levels.

If you want older versions to work remove the conditionals at the bottom of
io/io/Module.mk.

Issue can be closed.


Cheers, Fons.

[Bug c++/52527] When using '-g', get an ICE: seg fault in add_name_attribute (called by modified_type_die)

[geir at cray dot com]

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

Geir Johansen  changed:

   What|Removed |Added

  Known to work||4.5.3
  Known to fail||4.6.0, 4.6.1, 4.6.2, 4.6.3

--- Comment #1 from Geir Johansen  2012-03-08 21:19:42 
UTC ---
Fails with GCC 4.6.0, 4.6.1, 4.6.2, 4.6.3

Works with GCC 4.5.3

[Bug libfortran/52535] New: SH Target: libfortran won't build for sub-targets where DFmode is set to SFmode?

[olegendo at gcc dot gnu.org]

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

 Bug #: 52535
   Summary: SH Target: libfortran won't build for sub-targets
where DFmode is set to SFmode?
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*


It seems that for SH sub-targets where DFmode is set to be the same as SFmode
(everything ??-single-only, m2e ..) libfortran multilibs fail to build with the
following error:

gcc-trunk-build-sh-elf/./gcc/xgcc
-B/home/yam/code/gcc/gcc-trunk-build-sh-elf/./gcc/ -B/usr/local/sh-elf/bin/
-B/usr/local/sh-elf/lib/ -isystem /usr/local/sh-elf/include -isystem
/usr/local/sh-elf/sys-include -DHAVE_CONFIG_H -I.
-I../../../../gcc-trunk/libgfortran -iquote../../../../gcc-trunk/libgfortran/io
-I../../../../gcc-trunk/libgfortran/../gcc
-I../../../../gcc-trunk/libgfortran/../gcc/config -I../../.././gcc
-I../../../../gcc-trunk/libgfortran/../libgcc -I../../libgcc -std=gnu99 -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra
-Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -mieee
-g -O2 -m2e -MT cshift0.lo -MD -MP -MF .deps/cshift0.Tpo -c
../../../../gcc-trunk/libgfortran/intrinsics/cshift0.c -o cshift0.o
../../../../gcc-trunk/libgfortran/intrinsics/cshift0.c: In function 'cshift0':
../../../../gcc-trunk/libgfortran/intrinsics/cshift0.c:131:5: error: duplicate
case value
../../../../gcc-trunk/libgfortran/intrinsics/cshift0.c:127:5: error: previously
used here
../../../../gcc-trunk/libgfortran/intrinsics/cshift0.c:161:5: error: duplicate
case value
../../../../gcc-trunk/libgfortran/intrinsics/cshift0.c:157:5: error: previously
used here
../../../../gcc-trunk/libgfortran/intrinsics/cshift0.c:268:5: error: duplicate
case value
../../../../gcc-trunk/libgfortran/intrinsics/cshift0.c:221:5: error: previously
used here
make[6]: *** [cshift0.lo] Error 1
make[6]: Leaving directory
`/home/yam/code/gcc/gcc-trunk-build-sh-elf/sh-elf/m2e/libgfortran'

Looking at the generated (?) libgfortran/kinds.h file in the sub-target's build
dir the problem seems to be a bit worse:

typedef float GFC_REAL_4;
typedef complex float GFC_COMPLEX_4;
#define HAVE_GFC_REAL_4
#define HAVE_GFC_COMPLEX_4
#define GFC_REAL_4_HUGE 3.40282347e38f
#define GFC_REAL_4_LITERAL_SUFFIX f
#define GFC_REAL_4_LITERAL(X) (X ## f)
#define GFC_REAL_4_DIGITS 24
#define GFC_REAL_4_RADIX 2

typedef double GFC_REAL_8;
typedef complex double GFC_COMPLEX_8;
#define HAVE_GFC_REAL_8
#define HAVE_GFC_COMPLEX_8
#define GFC_REAL_8_HUGE 1.7976931348623157e308
#define GFC_REAL_8_LITERAL_SUFFIX 
#define GFC_REAL_8_LITERAL(X) (X)
#define GFC_REAL_8_DIGITS 53
#define GFC_REAL_8_RADIX 2

Both GFC_REAL_8 and GFC_REAL_4 are actually of type float.  In this case all
the other GFC_REAL_8 definitions are wrong.

[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #12 from Kazumoto Kojima  2012-03-08 
22:15:33 UTC ---
*** Bug 52535 has been marked as a duplicate of this bug. ***

[Bug libfortran/52535] SH Target: libfortran won't build for sub-targets where DFmode is set to SFmode?

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Kazumoto Kojima  2012-03-08 
22:15:32 UTC ---
This is a known issue as PR34040.

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

[Bug libstdc++/52433] [C++11] debug mode iterators need to move

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  2012-03-08 
22:31:24 UTC ---
Author: redi
Date: Thu Mar  8 22:31:19 2012
New Revision: 185114

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185114
Log:
PR libstdc++/52433
* include/debug/safe_iterator.h (_Safe_iterator): Add move
constructor and move assignment operator.
* testsuite/23_containers/vector/debug/52433.cc: New.

Added:
   
branches/gcc-4_6-branch/libstdc++-v3/testsuite/23_containers/vector/debug/52433.cc
Modified:
branches/gcc-4_6-branch/libstdc++-v3/ChangeLog
branches/gcc-4_6-branch/libstdc++-v3/include/debug/safe_iterator.h

[Bug libffi/52497] libffi doesn't build on powerpc64-linux after latest upstream merge

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

URL||http://sourceware.org/ml/li
   ||bffi-discuss/2012/msg00099.
   ||html

--- Comment #2 from Peter Bergner  2012-03-08 
23:16:37 UTC ---
I submitted a patch to upstream libffi to fix the breakage.

[Bug c++/40056] implicit instantiation of function templates fails with -O2, works with -O and -g...

[bircoph at gmail dot com]

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

--- Comment #12 from Andrew Savchenko  2012-03-08 
23:27:15 UTC ---
Hello,

(In reply to comment #10)
> No, they aren't just like normal functions.
> 
> Maybe you should read
> http://www.parashift.com/c++-faq-lite/templates.html#faq-35.12

Thank you again, I misunderstood concept behind template implementation.

(In reply to comment #11)
>   the source code now (r43307) uses explicit instantiation and should work on
> Gentoo with all compiler versions and optimization levels.
> 
> If you want older versions to work remove the conditionals at the bottom of
> io/io/Module.mk.

Thanks for fixing this problem. I'll apply the solution to our packages soon.

[Bug target/51244] SH Target: Inefficient conditional branch

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

  Attachment #26853|0   |1
is obsolete||

--- Comment #27 from Oleg Endo  2012-03-09 
00:26:39 UTC ---
Created attachment 26858
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26858
Patch for the patch


> Old tests that failed, that have disappeared: (Eeek!)
>
> 22_locale/ctype/is/char/3.cc execution test
> 27_io/basic_filebuf/underflow/wchar_t/9178.cc execution test
> gfortran.dg/widechar_intrinsics_6.f90  -Os  execution test

That was a feature ;)

> I've attached .s files against gfortran.dg/associated_4.f90 -O1 with
> patched/unpatched compilers.

I'm sorry, I got the definition of the negc opcode wrong in the movrt_negc
pattern.  negc leaves the T bit always at '1' in this particular case, instead
of inverting the T bit.  It is funny that in C/C++ code it was never actually
trying to re-use the T bit after the negc, but in Fortran it did.  And that's
what went wrong.

I'm now testing the attached patch for C/C++ ...

[Bug go/52532] Many libgo tests fail with various linker errors

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Ian Lance Taylor  2012-03-09 00:44:15 
UTC ---
This is an annoying error message from some versions of GNU ld.  Go does permit
zero-sized variables, so there is nothing wrong with having them.  I think the
linker should be checking for STT_NOTYPE instead.  Anyhow, earlier today I
committed a patch to mainline which I think should fix it.

[Bug target/51244] SH Target: Inefficient conditional branch

[kkojima at gcc dot gnu.org]

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

--- Comment #28 from Kazumoto Kojima  2012-03-09 
01:44:52 UTC ---
(In reply to comment #27)
> Created attachment 26858 [details]
> Patch for the patch

Looks all fortran regressions gone away.  I'll run full tests
on sh4-unknown-lunix-gnu.

[Bug c++/52536] New: internal compiler error: Illegal instruction

[olinchy1983 at gmail dot com]

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

 Bug #: 52536
   Summary: internal compiler error: Illegal instruction
Classification: Unclassified
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olinchy1...@gmail.com


g++ -o dombindings.o -c   -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM
-DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET
-DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES  -DSTATIC_EXPORTABLE_JS_API
-DOSTYPE=\"AIX6.1\" -DOSARCH=AIX -DJSFILE -DJS_THREADSAFE -DEXPORT_XPC_API 
-D_IMPL_NS_LAYOUT
-I/export/home/softs/xulrunner_source/js/xpconnect/src/../wrappers
-I/export/home/softs/xulrunner_source/js/xpconnect/src/../loader
-I/export/home/softs/xulrunner_source/js/src
-I/export/home/softs/xulrunner_source/js/src/nanojit
-I/export/home/softs/xulrunner_source/caps/include
-I/export/home/softs/xulrunner_source/content/base/src
-I/export/home/softs/xulrunner_source/content/html/content/src
-I/export/home/softs/xulrunner_source/content/html/document/src
-I/export/home/softs/xulrunner_source/content/svg/content/src
-I/export/home/softs/xulrunner_source/layout/style
-I/export/home/softs/xulrunner_source/layout/base
-I/export/home/softs/xulrunner_source/dom/base
-I/export/home/softs/xulrunner_source/xpcom/ds 
-I/export/home/softs/xulrunner_source/js/xpconnect/src -I.
-I../../../dist/include -I../../../dist/include/nsprpub 
-I/export/home/softs/xulrunner_source/xulrunner-build/dist/include/nspr
-I/export/home/softs/xulrunner_source/xulrunner-build/dist/include/nss 
-fPIC  -fno-rtti -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof
-Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long
-fno-exceptions -fno-strict-aliasing -pthread  -DNDEBUG -DTRIMMED -g -O
-fomit-frame-pointer   -DMOZILLA_CLIENT -include ../../../mozilla-config.h -MD
-MF .deps/dombindings.pp
/export/home/softs/xulrunner_source/js/xpconnect/src/dombindings.cpp
In file included from
/export/home/softs/xulrunner_source/js/xpconnect/src/dombindings.cpp:1203:
./dombindings_gen.cpp:554: internal compiler error: Illegal instruction
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
gmake[6]: *** [dombindings.o] Error 1
gmake[6]: Leaving directory
`/export/home/softs/xulrunner_source/xulrunner-build/js/xpconnect/src'
gmake[5]: *** [libs] Error 2
gmake[5]: Leaving directory
`/export/home/softs/xulrunner_source/xulrunner-build/js/xpconnect'
gmake[4]: *** [libs_tier_platform] Error 2
gmake[4]: Leaving directory
`/export/home/softs/xulrunner_source/xulrunner-build'
gmake[3]: *** [tier_platform] Error 2
gmake[3]: Leaving directory
`/export/home/softs/xulrunner_source/xulrunner-build'
gmake[2]: *** [default] Error 2
gmake[2]: Leaving directory
`/export/home/softs/xulrunner_source/xulrunner-build'
gmake[1]: *** [realbuild] Error 2
gmake[1]: Leaving directory `/export/home/softs/xulrunner_source'

[Bug c++/52536] internal compiler error: Illegal instruction

[olinchy1983 at gmail dot com]

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

olinchy  changed:

   What|Removed |Added

 CC||olinchy1983 at gmail dot
   ||com

--- Comment #1 from olinchy  2012-03-09 02:20:29 
UTC ---
code:
dombindings.cpp

line 1203: #include "dombindings_gen.cpp"

dombindings_gen.cpp
553 lines in total

[Bug tree-optimization/52267] a&~N where N has all the bits set up till a specific point can be folded to ((unsigned)a) < N

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #2 from Andrew Pinski  2012-03-09 
04:14:59 UTC ---
I hear Jakub has a patch for VRP to do ranges for (a&N)==/!=0 case.

[Bug target/49862] bfin.c warnings

[jiez at gcc dot gnu.org]

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

--- Comment #2 from Jie Zhang  2012-03-09 05:54:30 UTC 
---
Author: jiez
Date: Fri Mar  9 05:54:25 2012
New Revision: 185125

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185125
Log:
PR target/49862
* config/bfin/bfin.c (hwloop_optimize): Fix unused variable
warnings.
(hwloop_pattern_reg): Fix set but not used warning.
(bfin_reorg_loops): Remove unused parameter.
(bfin_reorg): Update use of bfin_reorg_loops.

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

[Bug target/49862] bfin.c warnings

[jiez at gcc dot gnu.org]

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

Jie Zhang  changed:

   What|Removed |Added

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

--- Comment #3 from Jie Zhang  2012-03-09 05:56:57 UTC 
---
Mine.

[Bug tree-optimization/15241] [tree-ssa] Convert a <= 7 && b <= 7 into (a | b) <= 7.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  2012-03-09 
06:08:56 UTC ---
I am going to implement this in my tree combiner branch.  It should not be
hard.  Then what could be done is combineif could use the combiner to see if
things reduce and use that result.