[Bug c++/57138] ICE in cp_parser_class_specifier with variadic templates, using declarations, save-temps and precompiled header

2013-05-02 Thread jmetcalfe at acm dot org


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



--- Comment #2 from Jacob Metcalfe  2013-05-02 
07:02:47 UTC ---

Modified the subject to reflect the stack produced by the given example. In our

larger code base the stack was somewhat different but related. I have been

unable to produce this stack in a reduced example because of the sensitivity to

removing unused lines of code:



GCC 4.8.0 stack:

core/Policy.hpp:37:59: internal compiler error: Segmentation fault

 using type = Type;

   ^

0x86943f crash_signal

../../gcc/toplev.c:332

0x508fd8 tsubst(tree_node*, tree_node*, int, tree_node*)

../../gcc/cp/pt.c:11227

0x50c992 tsubst_template_args

../../gcc/cp/pt.c:9607

0x5091b8 tsubst(tree_node*, tree_node*, int, tree_node*)

../../gcc/cp/pt.c:11465

0x50952d tsubst(tree_node*, tree_node*, int, tree_node*)

../../gcc/cp/pt.c:11107

0x50eb00 lookup_template_class_1

../../gcc/cp/pt.c:7363

0x50eb00 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,

int, int)

../../gcc/cp/pt.c:7562

0x5090af tsubst(tree_node*, tree_node*, int, tree_node*)

../../gcc/cp/pt.c:11337

0x50816e tsubst_decl

../../gcc/cp/pt.c:10625

0x509694 tsubst(tree_node*, tree_node*, int, tree_node*)

../../gcc/cp/pt.c:11081

0x50be68 instantiate_template_1

../../gcc/cp/pt.c:14719

0x50be68 instantiate_template(tree_node*, tree_node*, int)

../../gcc/cp/pt.c:14769

0x5097a7 instantiate_alias_template

../../gcc/cp/pt.c:14799

0x5097a7 tsubst(tree_node*, tree_node*, int, tree_node*)

../../gcc/cp/pt.c:11108

0x50816e tsubst_decl

../../gcc/cp/pt.c:10625

0x509694 tsubst(tree_node*, tree_node*, int, tree_node*)

../../gcc/cp/pt.c:11081

0x507f73 tsubst_decl

../../gcc/cp/pt.c:10037

0x509694 tsubst(tree_node*, tree_node*, int, tree_node*)

../../gcc/cp/pt.c:11081

0x516817 instantiate_class_template_1

../../gcc/cp/pt.c:8818

0x516817 instantiate_class_template(tree_node*)

../../gcc/cp/pt.c:9054


[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

2013-05-02 Thread rguenther at suse dot de


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



--- Comment #3 from rguenther at suse dot de  
2013-05-02 07:37:55 UTC ---

On Wed, 1 May 2013, wschmidt at gcc dot gnu.org wrote:



> 

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

> 

> Bill Schmidt  changed:

> 

>What|Removed |Added

> 

>  CC||rguenth at gcc dot gnu.org,

>||wschmidt at gcc dot gnu.org

> 

> --- Comment #2 from Bill Schmidt  2013-05-01 
> 21:58:09 UTC ---

> I've reproduced this as well.  Additionally, gcc.dg/vect/vect-96.c fails

> similarly.  Both tests began failing at r196872:

> 

> 2013-03-21  Richard Biener  

> 

> * tree-vect-data-refs.c (vect_update_interleaving_chain): Remove.

> (vect_insert_into_interleaving_chain): Likewise.

> (vect_drs_dependent_in_basic_block): Inline ...

> (vect_slp_analyze_data_ref_dependence): ... here.  New function,

> split out from ...

> (vect_analyze_data_ref_dependence): ... here.  Simplify.

> (vect_check_interleaving): Simplify.

> (vect_analyze_data_ref_dependences): Likewise.  Split out ...

> (vect_slp_analyze_data_ref_dependences): ... this new function.

> (dr_group_sort_cmp): New function.

> (vect_analyze_data_ref_accesses): Compute data-reference groups

> here instead of in vect_analyze_data_ref_dependence.  Use

> a more efficient algorithm.

> * tree-vect-slp.c (vect_slp_analyze_bb_1): Use

> vect_slp_analyze_data_ref_dependences.  Call

> vect_analyze_data_ref_accesses earlier.

> * tree-vect-loop.c (vect_analyze_loop_2): Likewise.

> * tree-vectorizer.h (vect_analyze_data_ref_dependences): Adjust.

> (vect_slp_analyze_data_ref_dependences): New prototype.

> 

> Richi, I think this commit was not intended to have any functional effect -- 
> is

> that correct?



Correct.  Dumping order is affected by the patch though, thus if

we previously disabled vectorization at some point the dumping

before that can be affected due to the re-ordering.


[Bug tree-optimization/57124] 254.gap@spec2000 got miscompare after r198413

2013-05-02 Thread rguenth at gcc dot gnu.org


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



--- Comment #3 from Richard Biener  2013-05-02 
08:01:39 UTC ---

At least the reduced testcase contains undefined signed integer overflow.

It multiplies 65531 by 65536 here:



  x3 = x2 * 65536;



it's still "miscompiled" with -fno-strict-overflow though, a QOI issue

(it works correctly with -fwrapv).  The docs trying to point out the

difference between -fno-strict-overflow and -fwrapv are especially poor

(ISTR strongly objecting the notion of -f[no-]strict-overflow ...)


[Bug middle-end/57134] [4.9 Regression] ICE with -mstrict-align and inline assembly on ppc64

2013-05-02 Thread rguenth at gcc dot gnu.org


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



Richard Biener  changed:



   What|Removed |Added



 Target||powerpc64

  Known to work||4.7.2

   Target Milestone|--- |4.9.0

Summary|ICE with -mstrict-align and |[4.9 Regression] ICE with

   |inline assembly on ppc64|-mstrict-align and inline

   ||assembly on ppc64

  Known to fail||4.9.0



--- Comment #2 from Richard Biener  2013-05-02 
08:06:45 UTC ---

Eventually somebody check 4.8.x.


[Bug c++/57140] New: Segmentation fault in backtrace_dwarf_add

2013-05-02 Thread dcb314 at hotmail dot com


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



 Bug #: 57140

   Summary: Segmentation fault in backtrace_dwarf_add

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: dcb...@hotmail.com





Created attachment 29993

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29993

gzipped C++ source code



I just tried to compile the package spectrum-1.4.8-10

on gcc-4.9 trunk dated 20130501 on an AMD x86_64 box.



The compiler said



/home/dcb/rpmbuild/BUILD/spectrum-1.4.8/src/adhoc/adhocadmin.cpp:328:38:

internal compiler error: Segmentation fault

 data.output.sort(compareSDataASC);

  ^

0xaa2adf crash_signal

../../src/trunk/gcc/toplev.c:333

0xaf3104 copy_loops

../../src/trunk/gcc/tree-inline.c:2214

0xafcd56 copy_cfg_body

../../src/trunk/gcc/tree-inline.c:2339

0xafcd56 copy_body

../../src/trunk/gcc/tree-inline.c:2519

0xb01a3b expand_call_inline

../../src/trunk/gcc/tree-inline.c:4119

0xb01a3b gimple_expand_calls_inline

../../src/trunk/gcc/tree-inline.c:4226

0xb01a3b optimize_inline_calls(tree_node*)

../../src/trunk/gcc/tree-inline.c:4380

0xefef2c inline_transform(cgraph_node*)

../../src/trunk/gcc/ipa-inline-transform.c:415

0xa0335f execute_one_ipa_transform_pass

../../src/trunk/gcc/passes.c:2175

0xa0335f execute_all_ipa_transforms()

../../src/trunk/gcc/passes.c:2215

0x7c6988 expand_function

../../src/trunk/gcc/cgraphunit.c:1633

0x7c8706 expand_all_functions

../../src/trunk/gcc/cgraphunit.c:1744

0x7c8706 compile()

../../src/trunk/gcc/cgraphunit.c:2042

0x7c8dd9 finalize_compilation_unit()

../../src/trunk/gcc/cgraphunit.c:2119

0x5eb3b0 cp_write_global_declarations()

../../src/trunk/gcc/cp/decl2.c:4330

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.



Here is a valgrind dump



==10282== Process terminating with default action of signal 11 (SIGSEGV)

==10282==  General Protection Fault

==10282==at 0xFAF570: backtrace_dwarf_add (dwarf.c:1438)

==10282==by 0xFAB767: elf_add (elf.c:757)

==10282==by 0xFABABE: backtrace_initialize (elf.c:858)

==10282==by 0xFAAB59: fileline_initialize (fileline.c:144)

==10282==by 0xFAAC61: backtrace_pcinfo (fileline.c:184)

==10282==by 0xFAA6D0: unwind (backtrace.c:83)

==10282==by 0xFDA868: _Unwind_Backtrace (unwind.inc:295)

==10282==by 0xFAA731: backtrace_full (backtrace.c:106)



Preprocessed source code attached. Flag -O3 required.


[Bug fortran/57141] New: Cannot change attributes of USE-associated intrinsic

2013-05-02 Thread roger.ferrer at bsc dot es


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



 Bug #: 57141

   Summary: Cannot change attributes of USE-associated intrinsic

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: roger.fer...@bsc.es





Hi,



gfortran-4.8 (and 4.7 as well and possibly earlier versions too) complain with

this snippet.



The error message is not emitted if the declaration of R is uncommented.



! -- test.f90

MODULE M

INTRINSIC :: NULL

!! Uncommenting the following statement

!! causes the error go away

! REAL, POINTER :: R(:) => NULL()

END MODULE M



MODULE M_INTERN

USE M

IMPLICIT NONE

REAL, POINTER :: ARR(:) => NULL()

END MODULE M_INTERN

! -- end of test.f90



$ gfortran -c test.f90

test.f90:12.37:



REAL, POINTER :: ARR(:) => NULL()

 1

Error: Cannot change attributes of USE-associated symbol null at (1)



Kind regards,


[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

2013-05-02 Thread amodra at gmail dot com


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



Alan Modra  changed:



   What|Removed |Added



 CC||amodra at gmail dot com



--- Comment #2 from Alan Modra  2013-05-02 08:18:45 
UTC ---

BTW, running gkeytool without any args shows the problem too. When libjava is

built with -g -O2, I get



Exception in thread "main" java.lang.NoClassDefFoundError:

gnu.classpath.tools.keytool.Main

   at java.lang.Class.initializeClass(natClass.cc)

Caused by: java.lang.IllegalMonitorStateException: current thread not owner

   at java.lang.Object.notifyAll(natObject.cc:1437)

   at gnu.gcj.runtime.SystemClassLoader.findClass(natSystemClassLoader.cc:29)

   at java.lang.ClassLoader.loadClass(ClassLoader.java)

   at java.lang.ClassLoader.loadClass(ClassLoader.java:387)

   at java.lang.Class.initializeClass(natClass.cc:728)



But note that natObject.cc:1437 is a lie!  The real failure occurs

natObject.cc:1431 and it looks like the two identical throws have merged. 

Putting a break on the right place, I see



(gdb) p this

$8 = (java::lang::Object * const) 0xffc6aec



(gdb) p/x addr

$9 = 0xffc6aec



Uh oh!  The address is not 8-byte aligned, so one of the flag bits appears to

be set.  This is why we appear to have locking problems.


[Bug c++/57140] [4.9 Regression] Segmentation fault in backtrace_dwarf_add

2013-05-02 Thread mpolacek at gcc dot gnu.org


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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-05-02

 CC||mpolacek at gcc dot gnu.org

  Known to work||4.8.1

Summary|Segmentation fault in   |[4.9 Regression]

   |backtrace_dwarf_add |Segmentation fault in

   ||backtrace_dwarf_add

 Ever Confirmed|0   |1

  Known to fail||4.9.0



--- Comment #1 from Marek Polacek  2013-05-02 
08:48:01 UTC ---

Confirmed.


[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

2013-05-02 Thread amodra at gmail dot com


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



--- Comment #3 from Alan Modra  2013-05-02 08:54:39 
UTC ---

In libgcj-tools.so

 20316: 00456aec   144 OBJECT  LOCAL  DEFAULT   22

_ZN3gnu9classpath5tools7keytool17Main$ShutdownHook6class$E



That's in .data, as expected.





>From the .o file (classpath/tools/.libs/libgcj_tools_la-tools.o) I see this is

laid out *not* at an 8 byte address.



26803: 000680ac   144 OBJECT  GLOBAL HIDDEN   110

_ZN3gnu9classpath5tools7keytool17Main$ShutdownHook6class$E



While the containing section is 8-byte aligned.

  [110] .data.rel.local   PROGBITS 2151b8 07358c 00  WA  0   0 

8





So a gcj bug by the look of it.


[Bug rtl-optimization/57130] [4.8/4.9 Regression] Incorrect "and --> extract" conversion in combine

2013-05-02 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |



--- Comment #3 from Jakub Jelinek  2013-05-02 
09:07:31 UTC ---

Created attachment 29994

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29994

gcc49-pr57130.patch



Untested fix, though not sure if it won't pessimize too much.  The in_code ==

COMPARE handling simply look safe to me when recursing into a SUBREG. 

Sometimes it could, e.g. for (subreg:SI (and:DI (reg:DI) (const_int

0x0800))) with in_code == COMPARE, but we'd probably have to pass the

SUBREG mode around and special case it everywhere.


[Bug c++/57140] [4.9 Regression] Segmentation fault in backtrace_dwarf_add

2013-05-02 Thread mpolacek at gcc dot gnu.org


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



Marek Polacek  changed:



   What|Removed |Added



 CC||rguenth at gcc dot gnu.org



--- Comment #2 from Marek Polacek  2013-05-02 
09:22:17 UTC ---

Seems to have started with http://gcc.gnu.org/r198333


[Bug rtl-optimization/57130] [4.8/4.9 Regression] Incorrect "and --> extract" conversion in combine

2013-05-02 Thread jakub at gcc dot gnu.org


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



--- Comment #4 from Jakub Jelinek  2013-05-02 
09:23:22 UTC ---

Created attachment 29995

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29995

simplify-truncate.patch



Another thing, it is weird we don't simplify that subreg much earlier, we know

that nonzero_bits on the inner operand has all zeros in the mode that it is

truncated to, therefore it must be zero.


[Bug middle-end/57140] [4.9 Regression] Segmentation fault in backtrace_dwarf_add

2013-05-02 Thread rguenth at gcc dot gnu.org


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



Richard Biener  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

  Component|c++ |middle-end

   Target Milestone|--- |4.9.0



--- Comment #3 from Richard Biener  2013-05-02 
09:32:21 UTC ---

I will have a look.


[Bug c++/57138] [4.8/4.9 Regression] ICE in cp_parser_class_specifier with variadic templates, using declarations, save-temps and precompiled header

2013-05-02 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-05-02

 CC||jakub at gcc dot gnu.org,

   ||jason at gcc dot gnu.org

   Target Milestone|--- |4.8.1

Summary|ICE in  |[4.8/4.9 Regression] ICE in

   |cp_parser_class_specifier   |cp_parser_class_specifier

   |with variadic templates,|with variadic templates,

   |using declarations, |using declarations,

   |save-temps and precompiled  |save-temps and precompiled

   |header  |header

 Ever Confirmed|0   |1



--- Comment #3 from Jakub Jelinek  2013-05-02 
09:55:45 UTC ---

No PCH is needed, just --enable-checking=yes compiler.

Simplified testcase for -std=c++0x:

template  class T, typename ... Y>

struct D

{

  template 

  using type = T ;

};

template 

class A {};

template 

struct B;

template 

struct B 

{

  typedef A  type;

};

template 

using C = typename B ::type;

struct E : public D  {};



The ICE started with http://gcc.gnu.org/r186434


[Bug target/56864] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0

2013-05-02 Thread sch...@linux-m68k.org


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



--- Comment #9 from Andreas Schwab  2013-05-02 10:37:53 
UTC ---

r196872 it is.


[Bug rtl-optimization/57130] [4.8/4.9 Regression] Incorrect "and --> extract" conversion in combine

2013-05-02 Thread jakub at gcc dot gnu.org


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



--- Comment #5 from Jakub Jelinek  2013-05-02 
10:49:08 UTC ---

Created attachment 29996

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29996

gcc49-pr57130.patch



Alternative to the #c3 patch, using SET instead of COMPARE only when needed for

the recursive call for SUBREG.


[Bug fortran/57141] Cannot change attributes of USE-associated intrinsic

2013-05-02 Thread dominiq at lps dot ens.fr


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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-05-02

 Ever Confirmed|0   |1



--- Comment #1 from Dominique d'Humieres  2013-05-02 
11:13:01 UTC ---

Confirmed from 4.3.1 to trunk.


[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

2013-05-02 Thread amodra at gmail dot com


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



--- Comment #4 from Alan Modra  2013-05-02 11:35:20 
UTC ---

I believe this is triggered by powerpc turning on -fsection-anchors by default,

and a section anchor bug loses the alignment.  The classes are all nicely

aligned if I compile with -fno-section-anchors


[Bug fortran/57142] New: SIZE/SHAPE overflow despite kind=8

2013-05-02 Thread burnus at gcc dot gnu.org


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



 Bug #: 57142

   Summary: SIZE/SHAPE overflow despite kind=8

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Keywords: diagnostic, wrong-code

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: bur...@gcc.gnu.org





The following program should print:

  1 k=8 / 4294967300 k=8

  1 k=8 / 2147483650 k=8



However, it prints:

  1 k=8 / 4 k=8

  1 k=8 / -2147483646 k=8



Expected:

* kind=8 is properly handled

* With kind=4, a warning/error is printed that the value exceeds huge(1_4)



NOTE: shape has the same issue; ubound/lbound are okay (in both regards). The

run-time version is fine.





!integer :: A(huge(1)+2_8), B(2,3)

integer :: A(1), B(huge(1)+3_8,2_8)

print '(4(i0,a))', size(A,kind=8),' k=', kind(size(A,kind=8)),' / ', &

   size(B,kind=8),' k=', kind(size(B,kind=8))

print '(4(i0,a))', size(A,dim=1,kind=8),' k=', kind(size(A,dim=1,kind=8)), &

  ' / ',   size(B,dim=1,kind=8),' k=', kind(size(B,dim=1,kind=8))

end


[Bug c++/57143] New: gcc failed to parse try/catch(...) when exception_ptr is involved

2013-05-02 Thread pichot.fabien at gmail dot com


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



 Bug #: 57143

   Summary: gcc failed to parse try/catch(...) when exception_ptr

is involved

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: pichot.fab...@gmail.com





Created attachment 29997

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29997

The test emphazing the bug.



Gcc fail to parse a try/catch block in a lambda expression.



It's very strange, we found a way to get around the problem by taking the

exception_ptr by reference explicitly.



Bug reproduced on three machines (uname -a):

- Linux  3.7.0-sabayon #1 SMP Wed Jan 23 20:51:11 UTC 2013 x86_64 Intel(R)

Core(TM) i5-2520M CPU @ 2.50GHz GenuineIntel GNU/Linux

- Linux  3.2.1-gentoo-r2 #5 SMP Fri Feb 24 16:43:17 CET 2012 x86_64

Intel(R) Xeon(R) CPU X3450 @ 2.67GHz GenuineIntel GNU/Linux

- Darwin  11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT

2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64



I'm compiling with:

- g++-4.7.1

- g++-4.7.2

- g++-4.8.0



with the same command line: -v -std=c++11 -save-temps -W -Wall ./try-catch.cc


[Bug c++/57143] gcc failed to parse try/catch(...) when exception_ptr is involved

2013-05-02 Thread pichot.fabien at gmail dot com


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



--- Comment #1 from Fabien Pichot  2013-05-02 
11:52:39 UTC ---

Created attachment 29998

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29998

g++-4.8.0 -v output


[Bug c++/57143] gcc failed to parse try/catch(...) when exception_ptr is involved

2013-05-02 Thread pichot.fabien at gmail dot com


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



--- Comment #2 from Fabien Pichot  2013-05-02 
11:53:39 UTC ---

Created attachment 2

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=2

preprocessed file


[Bug fortran/57142] [4.7/4.8/4.9 Regression] SIZE/SHAPE overflow despite kind=8

2013-05-02 Thread dominiq at lps dot ens.fr


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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-05-02

Summary|SIZE/SHAPE overflow despite |[4.7/4.8/4.9 Regression]

   |kind=8  |SIZE/SHAPE overflow despite

   ||kind=8

 Ever Confirmed|0   |1



--- Comment #1 from Dominique d'Humieres  2013-05-02 
11:53:45 UTC ---

When compiled with gfortran 4.5.3 or older, the output is the one you expect:



1 k=8 / 4294967300 k=8

1 k=8 / 2147483650 k=8



>From 4.6.4 to trunk the outputs is



1 k=8 / 4 k=8

1 k=8 / -2147483646 k=8


[Bug c++/57143] gcc failed to parse try/catch(...) when exception_ptr is involved

2013-05-02 Thread paolo.carlini at oracle dot com


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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #3 from Paolo Carlini  2013-05-02 
12:02:19 UTC ---

Dup. Already fixed.



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


[Bug c++/56388] [4.7/4.8/4.9 regression] catch(...) in lambda rejected

2013-05-02 Thread paolo.carlini at oracle dot com


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



Paolo Carlini  changed:



   What|Removed |Added



 CC||pichot.fabien at gmail dot

   ||com



--- Comment #4 from Paolo Carlini  2013-05-02 
12:02:19 UTC ---

*** Bug 57143 has been marked as a duplicate of this bug. ***


[Bug fortran/57142] [4.7/4.8/4.9 Regression] SIZE/SHAPE overflow despite kind=8

2013-05-02 Thread dominiq at lps dot ens.fr


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



Dominique d'Humieres  changed:



   What|Removed |Added



 CC||franke.daniel at gmail dot

   ||com, jvdelisle at gcc dot

   ||gnu.org



--- Comment #2 from Dominique d'Humieres  2013-05-02 
12:58:20 UTC ---

The change is due to revision 158253.


[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

2013-05-02 Thread amodra at gmail dot com


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



--- Comment #5 from Alan Modra  2013-05-02 14:01:59 
UTC ---

So the section anchor code places vars (and constants) in blocks according to

their alignment and sizes (varasm.c:place_block_symbol).  The calculations are

all good, offsets are properly aligned, and the overall block aligned.  The

problem is that when we come to actually output the vars, in some cases we emit

*more* data than given by the size.  That results in following vars being at a

different offset than originally calculated, and sometimes misaligned.



Here's an example of output showing the mismatch.

.type   _atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook,

@object

.size   _atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook, 24

_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook:

.long   _Utf259

.long   _Utf111

.long   _Utf110

.long   _Utf166

.long   _Utf111

.long   _Utf257

.long   0

.long   0

.long   0

Notice the actual size is 36 bytes, not the 24 give by .size.



 

unit size 

align 32 symtab 0 alias set 22 canonical type 0xfffb60f46e0 fields



pointer_to_this >

BLK

size 

unit size 

align 32 symtab 0 alias set 22 canonical type 0xfffb60f4788

domain 

SI

size 

unit size 

align 32 symtab 0 alias set -1 canonical type 0xfffb60f4248

precision 32 min  max >

pointer_to_this >

constant addressable asm_written used static ignored BLK file

/home/alan/src/gcc-virgin/libjava/classpath/tools/gnu/classpath/tools/keytool/Main.java

line 0 col 0 size  unit size 

align 32 initial 

(mem/c:BLK (symbol_ref:SI

("_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook") [flags 0x82]

) [22

_atable_syms_gnu_classpath_tools_keytool_Main$ShutdownHook+0 S24 A32]) chain

>



I'm not sure how we came to think the array had 3 elements rather than 2. 

Here's that "initial" field.



 

unit size 

align 32 symtab 0 alias set 22 canonical type 0xfffb60f46e0 fields



pointer_to_this >

BLK

size 

unit size 

align 32 symtab 0 alias set 22 canonical type 0xfffb60f4788

domain 

SI

size 

unit size 

align 32 symtab 0 alias set -1 canonical type 0xfffb60f4248

precision 32 min  max >

pointer_to_this >

constant lngt 3

val 

constant lngt 3

idx 

unsigned SI file  line 0 col 0 size  unit size 

align 32 offset_align 128

offset 

bit offset  context

 chain >

val 

readonly constant arg 0 >

idx 

unsigned SI file  line 0 col 0 size  unit size 

align 32 offset_align 128 offset  bit

offset  context  chain

>

val 

readonly constant arg 0 >

idx 

unsigned SI file  line 0 col 0 size  unit size 

align 32 offset_align 128 offset 

bit offset  context

>

val 

readonly constant arg 0 >>

val 

constant lngt 3 idx 

val 

readonly constant arg 0 > idx

 val  idx 

val 

readonly constant arg 0 >>

val 

constant lngt 3 idx 

val  idx  val  idx  val >>


[Bug middle-end/56988] ipa-cp incorrectly propagates a field of an aggregate

2013-05-02 Thread jamborm at gcc dot gnu.org


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



--- Comment #5 from Martin Jambor  2013-05-02 
14:05:35 UTC ---

Patch committed to trunk.  I will commit the 4.8 version early next week.



Author: jamborm

Date: Thu May  2 14:03:02 2013

New Revision: 198540



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

Log:

2013-05-02  Martin Jambor  



PR middle-end/56988

* ipa-prop.h (ipa_agg_replacement_value): New flag by_ref.

* ipa-cp.c (ipa_get_indirect_edge_target_1): Also check that by_ref

flags match.

(find_aggregate_values_for_callers_subset): Fill in the by_ref flag of

ipa_agg_replacement_value structures.

(known_aggs_to_agg_replacement_list): Likewise.

* ipa-prop.c (write_agg_replacement_chain): Stream by_ref flag.

(read_agg_replacement_chain): Likewise.

(ipcp_transform_function): Also check that by_ref flags match.



testsuite/

* gcc.dg/ipa/pr56988.c: New test.





Added:

trunk/gcc/testsuite/gcc.dg/ipa/pr56988.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/ipa-cp.c

trunk/gcc/ipa-prop.c

trunk/gcc/ipa-prop.h

trunk/gcc/testsuite/ChangeLog


[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

2013-05-02 Thread sch...@linux-m68k.org


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



--- Comment #6 from Andreas Schwab  2013-05-02 14:25:09 
UTC ---

There is a long standing bug with VLA types (see bug 28865) that has a similar

effect.


[Bug bootstrap/48231] bootstrapping gcc-4.6.0-RC-20110321 fails for h8300-rtems*

2013-05-02 Thread joel at gcc dot gnu.org


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



Joel Sherrill  changed:



   What|Removed |Added



 CC||joel at gcc dot gnu.org



--- Comment #4 from Joel Sherrill  2013-05-02 14:53:05 
UTC ---

Ping DJ. 



Any chance you can commit this to all impacted branches and the head.



Thanks.


[Bug c++/52892] Function pointer loses constexpr qualification

2013-05-02 Thread paolo.carlini at oracle dot com


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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2013-05-02

 Blocks||55004

 Ever Confirmed|0   |1


[Bug tree-optimization/57144] New: [4.9 regression] mpfr miscompiled after r198413

2013-05-02 Thread sch...@linux-m68k.org


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



 Bug #: 57144

   Summary: [4.9 regression] mpfr miscompiled after r198413

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Keywords: build

  Severity: normal

  Priority: P3

 Component: tree-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: sch...@linux-m68k.org

CC: l...@gcc.gnu.org

Depends on: 57124

Target: ia64-*-*





r198413 is causing miscompilation of mpfr-2.4.2 on ia64, seen by a lot of

failures in its testsuite, some are looping infinitely.  This makes it

impossible to bootstrap with an in-tree mpfr, because the fortran compiler

hangs while calling mpfr_log10 from gfc_arith_init_1.



The patch in  does

not help.


[Bug c++/57109] ice tsubst_copy, at cp/pt.c:12171

2013-05-02 Thread paolo.carlini at oracle dot com


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



Paolo Carlini  changed:



   What|Removed |Added



 Status|WAITING |UNCONFIRMED

 Ever Confirmed|1   |0


[Bug fortran/57145] New: [OOP] Faulty "Actual argument must be polymorphic" error

2013-05-02 Thread loximann at gmail dot com


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



 Bug #: 57145

   Summary: [OOP] Faulty "Actual argument must be polymorphic"

error

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: loxim...@gmail.com





The following program will not compile with the following error:



move_alloc.F90:16.20:



print*, my_func(static)

1

Error: Actual argument to 'input' at (1) must be polymorphic



However, if the declaration of type 'big' is removed altogether (comment lines

6-8), the program compiles without a problem.



##

module my_module

type :: small

real :: a

end type



type :: big

class(small), pointer :: v(:)

end type

end module



program my_program

use my_module

implicit none

type(small) :: static(1)=[small(5.5)]



print*, my_func(static)



contains

function my_func(input)

class(small) :: input(:)

real :: my_func

my_func=input(1)%a

end function

end program


[Bug tree-optimization/57144] [4.9 regression] mpfr miscompiled after r198413

2013-05-02 Thread rguenth at gcc dot gnu.org


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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.9.0


[Bug spam/57146] New: Makefile error in wiselib library

2013-05-02 Thread darshanmadival8 at gmail dot com


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



 Bug #: 57146

   Summary: Makefile error in wiselib library

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: minor

  Priority: P3

 Component: spam

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: darshanmadiv...@gmail.com





Created attachment 3

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=3

This is the patch for above error



Makefile in the folder "geniric_apps/convergecast/" uses



$(WISELIB_PATH)

$(WISELIB_GENERIC_APPS)



variable to include Makefile.local and Makefile which are in the parent dir

and whose initialization are not visible



got error which compiling for Shawn





$ make shawn

Makefile:19: /../apps/generic_apps/Makefile.local: No such file or directory

Makefile:20: /Makefile: No such file or directory

make: *** No rule to make target `/Makefile'.  Stop.

$

***


[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

2013-05-02 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #7 from Jakub Jelinek  2013-05-02 
15:17:31 UTC ---

I don't see how this would be related to PR28865, that PR is about .size

directive, if TYPE_SIZE is smaller than DECL_SIZE.  But from what Alan posted

here, that is not the case here, here TYPE_SIZE is the same as DECL_SIZE, 24

bytes both, and the problem is that the CONSTRUCTOR in DECL_INITIAL has 3

entries rather than two.  Perhaps gcj FE bug?


[Bug spam/57146] Makefile error in wiselib library

2013-05-02 Thread paolo.carlini at oracle dot com


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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Paolo Carlini  2013-05-02 
15:23:18 UTC ---

.


[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

2013-05-02 Thread wschmidt at gcc dot gnu.org


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



--- Comment #4 from Bill Schmidt  2013-05-02 
15:27:08 UTC ---

(In reply to comment #3)

> 

> Correct.  Dumping order is affected by the patch though, thus if

> we previously disabled vectorization at some point the dumping

> before that can be affected due to the re-ordering.



It appears that we are vectorizing the same loops, but we are now vectorizing

one loop differently.  In r196871, the loop is peeled for alignment.  In

r196872, the loop is versioned for alignment.  



I will attach the vectorization detail dumps for the two revisions.


[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

2013-05-02 Thread wschmidt at gcc dot gnu.org


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



--- Comment #5 from Bill Schmidt  2013-05-02 
15:29:10 UTC ---

Created attachment 30001

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30001

Vectorization details dump for r196871


[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

2013-05-02 Thread wschmidt at gcc dot gnu.org


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



--- Comment #6 from Bill Schmidt  2013-05-02 
15:29:51 UTC ---

Created attachment 30002

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30002

Vectorization details dump for r196872


[Bug tree-optimization/57027] [4.9 Regression] ICE in gimple_assign_rhs_code, at gimple.h:2022

2013-05-02 Thread danglin at gcc dot gnu.org


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



--- Comment #2 from John David Anglin  2013-05-02 
15:42:23 UTC ---

Related fails:



FAIL: gcc.c-torture/compile/991202-1.c  -O2  (internal compiler error)

FAIL: gcc.c-torture/compile/991202-1.c  -O2  (test for excess errors)

FAIL: gcc.c-torture/compile/991202-1.c  -O3 -fomit-frame-pointer  (internal

comp

iler error)

FAIL: gcc.c-torture/compile/991202-1.c  -O3 -fomit-frame-pointer  (test for

exce

ss errors)

FAIL: gcc.c-torture/compile/991202-1.c  -O3 -g  (internal compiler error)

FAIL: gcc.c-torture/compile/991202-1.c  -O3 -g  (test for excess errors)

FAIL: gcc.c-torture/compile/991202-1.c  -Os  (internal compiler error)

FAIL: gcc.c-torture/compile/991202-1.c  -Os  (test for excess errors)

FAIL: gcc.c-torture/compile/991202-1.c  -O2 -flto -flto-partition=none 

(interna

l compiler error)

FAIL: gcc.c-torture/compile/991202-1.c  -O2 -flto -flto-partition=none  (test

fo

r excess errors)

FAIL: gcc.c-torture/compile/991202-1.c  -O2 -flto  (internal compiler error)

FAIL: gcc.dg/pr41345.c (test for excess errors)

FAIL: gcc.dg/pr52132.c (internal compiler error)

FAIL: gcc.dg/pr52132.c (test for excess errors)

FAIL: gcc.dg/torture/vec-cvt-1.c  -O2  (internal compiler error)

FAIL: gcc.dg/torture/vec-cvt-1.c  -O2  (test for excess errors)

FAIL: gcc.dg/torture/vec-cvt-1.c  -O3 -fomit-frame-pointer  (internal compiler

error)

FAIL: gcc.dg/torture/vec-cvt-1.c  -O3 -fomit-frame-pointer  (test for excess

errors)

FAIL: gcc.dg/torture/vec-cvt-1.c  -O3 -fomit-frame-pointer -funroll-loops 

(internal compiler error)

FAIL: gcc.dg/torture/vec-cvt-1.c  -O3 -fomit-frame-pointer -funroll-loops 

(test for excess errors)

FAIL: gcc.dg/torture/vec-cvt-1.c  -O3 -fomit-frame-pointer -funroll-all-loops

-finline-functions  (internal compiler error)

FAIL: gcc.dg/torture/vec-cvt-1.c  -O3 -fomit-frame-pointer -funroll-all-loops

-finline-functions  (test for excess errors)

FAIL: gcc.dg/torture/vec-cvt-1.c  -O3 -g  (internal compiler error)

FAIL: gcc.dg/torture/vec-cvt-1.c  -O3 -g  (test for excess errors)

FAIL: gcc.dg/torture/vec-cvt-1.c  -Os  (internal compiler error)

FAIL: gcc.dg/torture/vec-cvt-1.c  -Os  (test for excess errors)

FAIL: gcc.dg/torture/vec-cvt-1.c  -O2 -flto -flto-partition=none  (internal

compiler error)

FAIL: gcc.dg/torture/vec-cvt-1.c  -O2 -flto -flto-partition=none  (test for

excess errors)

FAIL: gcc.dg/torture/vec-cvt-1.c  -O2 -flto  (internal compiler error)

FAIL: gcc.dg/torture/vec-cvt-1.c  -O2 -flto  (test for excess errors)



All fail with similar ICEs:



Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ 

-f

no-diagnostics-show-caret -fdiagnostics-color=never   -O2  -w -c  -o 991202-1.o

/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/991202-1.c(timeout =

3

00)

spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/

-fno-diagnostics

-show-caret -fdiagnostics-color=never -O2 -w -c -o 991202-1.o

/test/gnu/gcc/gcc/

gcc/testsuite/gcc.c-torture/compile/991202-1.c

/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/991202-1.c: In function

'k

1f':

/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/991202-1.c:6:7: internal

c

ompiler error: tree check: expected ssa_name, have real_cst in

convert_mult_to_f

ma, at tree-ssa-math-opts.c:2584


[Bug lto/57084] 483. xalancbmk run fails with -O2 -flto for i686

2013-05-02 Thread jamborm at gcc dot gnu.org


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



Martin Jambor  changed:



   What|Removed |Added



 CC||hubicka at gcc dot gnu.org



--- Comment #2 from Martin Jambor  2013-05-02 
15:46:35 UTC ---

OK, after I verified and re-verified that the call target determined

by devirtualization is actually correct, I have noticed that the call

graph of the target is an inlined node.  I'm not sure what effects

exactly that has but the following (untested) patch helps while still

performing the devirtualization (and the assembly around the calls is

slightly different).



I think that the final patch will look a bit different because a) the

new code is basically copied from ipa_make_edge_direct_to_target an

thus we'd better commonize it somehow (and I'd like to discuss with

Honza at least the name of the new function) and b) I see no reason

why the constructor-based devirtualization method in PRE cannot have

the same problem and so we'll probably want to handle it there instead

(Honza said on IRC something about a patch he already had but I am not

sure what he meant).



Another interesting point is that at least in the 64 bit non-LTO

build, these polymorphic calls are devirtualized during inlining.  I'm

going to look at why we do not do it in 32 bit LTO one (so far I do

not know which one is the problem).





Index: src/gcc/ipa-prop.c

===

--- src.orig/gcc/ipa-prop.c

+++ src/gcc/ipa-prop.c

@@ -1978,6 +1978,7 @@ ipa_analyze_node (struct cgraph_node *no

 tree

 ipa_intraprocedural_devirtualization (gimple call)

 {

+  struct cgraph_node *callee;

   tree binfo, token, fndecl;

   struct ipa_jump_func jfunc;

   tree otr = gimple_call_fn (call);

@@ -1993,6 +1994,18 @@ ipa_intraprocedural_devirtualization (gi

   token = OBJ_TYPE_REF_TOKEN (otr);

   fndecl = gimple_get_virt_method_for_binfo (tree_low_cst (token, 1),

  binfo);

+  if (!fndecl)

+return NULL_TREE;

+

+  callee = cgraph_get_node (fndecl);

+  if (!callee || callee->global.inlined_to)

+{

+  if (!canonicalize_constructor_val (fndecl, NULL)

+  || !TREE_PUBLIC (fndecl))

+return NULL_TREE;

+  cgraph_get_create_real_symbol_node (fndecl);

+}

+

   return fndecl;

 }


[Bug middle-end/57140] [4.9 Regression] Segmentation fault in backtrace_dwarf_add

2013-05-02 Thread rguenth at gcc dot gnu.org


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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #4 from Richard Biener  2013-05-02 
15:46:56 UTC ---

Author: rguenth

Date: Thu May  2 15:46:12 2013

New Revision: 198548



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

Log:

2013-05-02  Richard Biener  



PR middle-end/57140

* tree-inline.c (copy_loops): Properly handle removed loops.

(copy_cfg_body): Mark destination loops for fixup if source

loops needed fixup.



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



Added:

trunk/gcc/testsuite/g++.dg/torture/pr57140.C

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-inline.c


[Bug fortran/57145] [OOP] Faulty "Actual argument must be polymorphic" error

2013-05-02 Thread dominiq at lps dot ens.fr


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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 CC||burnus at gcc dot gnu.org

 Resolution||FIXED



--- Comment #1 from Dominique d'Humieres  2013-05-02 
15:50:18 UTC ---

This has been fixed between revisions 189610 (2012-07-18) which gives the error

and 189780 (2012-07-23). This may have been fixed by revision 189669 and/or

189678.



The test compiles with the latest 4.8.0 release, so you may consider to

upgrade.


[Bug target/56864] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0

2013-05-02 Thread wschmidt at gcc dot gnu.org


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



Bill Schmidt  changed:



   What|Removed |Added



 CC||rguenth at gcc dot gnu.org



--- Comment #10 from Bill Schmidt  2013-05-02 
15:55:07 UTC ---

Well, I still can't find the magic to reproduce this myself, but our overnight

tester shows the failure

(http://gcc.gnu.org/ml/gcc-testresults/2013-05/msg00094.html).



Richi, this is another test that started failing with the same commit as

PR56865.  In this case, it appears we are now vectorizing a loop that we

formerly expected not to.  Are you able to reproduce this?



Andreas, would you be able to provide -fdump-tree-vect-details information for

r196871 and r196872 to make it easier to debug the problem?



Thanks,

Bill


[Bug target/56864] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0

2013-05-02 Thread sch...@linux-m68k.org


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



--- Comment #11 from Andreas Schwab  2013-05-02 16:19:57 
UTC ---

Created attachment 30003

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30003

r196871 dump


[Bug tree-optimization/57027] [4.9 Regression] ICE in gimple_assign_rhs_code, at gimple.h:2022

2013-05-02 Thread amylaar at gcc dot gnu.org


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



--- Comment #3 from Jorn Wolfgang Rennecke  
2013-05-02 16:28:15 UTC ---

Created attachment 30004

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30004

tentative patch



Would that help?


[Bug tree-optimization/57144] [4.9 regression] mpfr miscompiled after r198413

2013-05-02 Thread law at redhat dot com


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



Jeffrey A. Law  changed:



   What|Removed |Added



 CC||law at redhat dot com



--- Comment #1 from Jeffrey A. Law  2013-05-02 16:28:40 
UTC ---

Thanks.   I can trigger a 2.4.2 testsuite failure on x86_64.  Investigating.


[Bug fortran/57142] [4.7/4.8/4.9 Regression] SIZE/SHAPE overflow despite kind=8

2013-05-02 Thread burnus at gcc dot gnu.org


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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org



--- Comment #3 from Tobias Burnus  2013-05-02 
16:29:59 UTC ---

Author: burnus

Date: Thu May  2 16:29:14 2013

New Revision: 198549



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

Log:

2013-05-02  Tobias Burnus  



PR fortran/57142

* simplify.c (gfc_simplify_size): Renamed from

simplify_size; fix kind=8 handling.

(gfc_simplify_size): New function.

(gfc_simplify_shape): Add range check.

* resolve.c (resolve_function): Fix handling

for ISYM_SIZE.



2013-05-02  Tobias Burnus  



PR fortran/57142

* gfortran.dg/size_kind_2.f90: New.

* gfortran.dg/size_kind_3.f90: New.





Added:

trunk/gcc/testsuite/gfortran.dg/size_kind_2.f90

trunk/gcc/testsuite/gfortran.dg/size_kind_3.f90

Modified:

trunk/gcc/fortran/ChangeLog

trunk/gcc/fortran/resolve.c

trunk/gcc/fortran/simplify.c

trunk/gcc/testsuite/ChangeLog


[Bug target/56864] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0

2013-05-02 Thread sch...@linux-m68k.org


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



--- Comment #12 from Andreas Schwab  2013-05-02 16:36:18 
UTC ---

Created attachment 30005

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30005

r196872 dump


[Bug tree-optimization/57144] [4.9 regression] mpfr miscompiled after r198413

2013-05-02 Thread law at redhat dot com


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



Jeffrey A. Law  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-05-02

 AssignedTo|unassigned at gcc dot   |law at redhat dot com

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #2 from Jeffrey A. Law  2013-05-02 17:03:03 
UTC ---

It looks like more overflow issues, though slightly different than 57124.  In

the case I looked at in the mpfr code we overflow converting a constant to the

desired type.  It's all downhill from there.


[Bug tree-optimization/57147] New: [4.9 Regression]: setjmp call and if body wrongly elided (function runs off early end)

2013-05-02 Thread roland at gnu dot org


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



 Bug #: 57147

   Summary: [4.9 Regression]: setjmp call and if body wrongly

elided (function runs off early end)

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: rol...@gnu.org

Target: arm-linux-gnueabi





Created attachment 30006

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30006

preprocessed source



This is with trunk@198549.  It's a regression from gcc-4_8-branch@198420.



Preprocessed source attached.



Configured as: --target=arm-linux-gnueabi --with-arch=armv7-a

Command line below.



This example is not expected to be usable on an arm-linux-gnueabi system,

but the problem is easily seen by examining the assembly.  In the function

TestSyscall, a good compilation calls _setjmp, returns normally on a

nonzero result, and ends in an __assert_fail call (a noreturn function, so

no epilogue/return after the call) on a zero result.  In a bad compilation,

the function just ends where the _setjmp call should be, no epilogue, no

return (so execution just runs into the following function).





gcc/cc1 -v  -fpreprocessed syscall_return_regs_test.i -quiet -dumpbase

syscall_return_regs_test.c -mtls-dialect=gnu -auxbase-strip

scons-out/nacl_irt_test-arm-glibc/obj/tests/syscall_return_regs/syscall_return_regs_test.o

-g -O2 -Wstrict-prototypes -Wall -Wundef -Wpedantic -Werror

-Wno-variadic-macros -Wno-unused-local-typedefs -std=gnu99 -version

-fomit-frame-pointer -fdiagnostics-show-option -o syscall_return_regs_test.s

GNU C (GCC) version 4.9.0 20130502 (experimental) (arm-linux-gnueabi)

compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3,

MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

ignoring nonexistent directory

"/usr/local/google/home/mcgrathr/gnu/build/inst/lib/gcc/arm-linux-gnueabi/4.9.0/include"

ignoring nonexistent directory

"/usr/local/google/home/mcgrathr/gnu/build/inst/lib/gcc/arm-linux-gnueabi/4.9.0/include-fixed"

ignoring nonexistent directory

"/usr/local/google/home/mcgrathr/gnu/build/inst/arm-linux-gnueabi/include"

#include "..." search starts here:

#include <...> search starts here:

 /usr/local/google/home/mcgrathr/gnu/build/inst/arm-linux-gnueabi/sys-include

End of search list.

GNU C (GCC) version 4.9.0 20130502 (experimental) (arm-linux-gnueabi)

compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3,

MPC version 0.9

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Compiler executable checksum: e560f858071b4c04ef52cbbad3e21d4b


[Bug tree-optimization/57147] [4.9 Regression]: setjmp call and if body wrongly elided (function runs off early end)

2013-05-02 Thread roland at gnu dot org


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



roland at gnu dot org changed:



   What|Removed |Added



 CC||rguenther at suse dot de



--- Comment #1 from roland at gnu dot org 2013-05-02 17:31:44 UTC ---

Bisected to r198096:



2013-04-19  Richard Biener  



PR tree-optimization/56982

* builtins.def (BUILT_IN_LONGJMP): longjmp is not a leaf

function.

* gimplify.c (gimplify_call_expr): Notice special calls.

(gimplify_modify_expr): Likewise.

* tree-cfg.c (make_abnormal_goto_edges): Handle setjmp-like

abnormal control flow receivers.

(call_can_make_abnormal_goto): Handle cfun->calls_setjmp

in the same way as cfun->has_nonlocal_labels.

(gimple_purge_dead_abnormal_call_edges): Likewise.

(stmt_starts_bb_p): Make setjmp-like abnormal control flow

receivers start a basic-block.



* gcc.c-torture/execute/pr56982.c: New testcase.


[Bug bootstrap/48231] bootstrapping gcc-4.6.0-RC-20110321 fails for h8300-rtems*

2013-05-02 Thread dj at redhat dot com


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



--- Comment #5 from DJ Delorie  2013-05-02 17:39:29 UTC 
---

I'm OK with it being committed, but it's not up to me, ping Jeff or Kazu.



h8 portJeff Lawl...@redhat.com

h8 portKazu Hiratak...@codesourcery.com


[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

2013-05-02 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||aph at gcc dot gnu.org,

   ||tromey at gcc dot gnu.org

   Target Milestone|--- |4.8.1



--- Comment #8 from Jakub Jelinek  2013-05-02 
18:21:24 UTC ---

So, the decl in question seems to be created by:

#0  build_decl_stat (loc=13046123, code=VAR_DECL, name=0xf42cd7d0,

type=0xf7915840) at ../../gcc/tree.c:4166

#1  0x081bbf87 in gen_indirect_dispatch_tables (type=0xf7973f60) at

../../gcc/java/class.c:472

#2  0x08207f7b in parse_class_file () at ../../gcc/java/jcf-parse.c:1566

#3  0x082091bc in parse_zip_file_entries () at ../../gcc/java/jcf-parse.c:2101



and the DECL_INITIAL for it filled by:



#0  emit_symbol_table (name=0xf42cd7a8, the_table=0xf42cf5c0,

decl_table=0xf42cd938, the_syms_decl=the_syms_decl@entry=0xf42cf61c, 

the_array_element_type=the_array_element_type@entry=0xf790e720,

element_size=element_size@entry=1) at ../../gcc/java/class.c:2965

#1  0x081c7854 in make_class_data (type=0xf7973f60) at

../../gcc/java/class.c:2066

#2  0x081d13ca in finish_class () at ../../gcc/java/class.c:2255

#3  0x082081df in parse_class_file () at ../../gcc/java/jcf-parse.c:1661

#4  0x082091bc in parse_zip_file_entries () at ../../gcc/java/jcf-parse.c:2101



One bug seems to be

one_elt_array_domain_type = build_index_type (integer_one_node);

That name seems to be inconsistent with what it does, build_index_type

(integer_one_node); returns an index type with  , i.e. two

element array.  One element array is build_index_type (integer_zero_node);.



And, either the individual decls need to be created with different types,

depending on how many elements they will have, or at least treated as C []

arrays and at least DECL_SIZE and DECL_SIZE_UNIT need to be updated when

setting DECL_INITIAL.



>From quick skimming, emit_{symbol,assertion}_table are the only callers in

gcc/java/ of build_constructor that don't bother with sizing the array type

appropriately.


[Bug bootstrap/48231] bootstrapping gcc-4.6.0-RC-20110321 fails for h8300-rtems*

2013-05-02 Thread joel at gcc dot gnu.org


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



--- Comment #6 from Joel Sherrill  2013-05-02 18:55:02 
UTC ---

>From Jeff Law:



The problem is that's not the right fix.  See this thread:



http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00707.html



Basically something needs to avoid building the C++ runtime for the 16 

bit models of the H8.  I don't think we have any configury magic for that.


[Bug c++/14283] Diagnostic for invalid template-id could be improved

2013-05-02 Thread paolo.carlini at oracle dot com


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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 CC|gcc-bugs at gcc dot gnu.org |

 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot

   |gnu.org |com



--- Comment #14 from Paolo Carlini  2013-05-02 
19:13:16 UTC ---

Implementing what Manuel suggested (but I propose to say template type, not

just template, otherwise the error message for g++.dg/template/typename11.C

doesn't seem clear enough to me)


[Bug fortran/57148] New: integer*4 fails to read largest negative number

2013-05-02 Thread jayas at hvdc dot ca


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



 Bug #: 57148

   Summary: integer*4 fails to read largest negative number

Classification: Unclassified

   Product: gcc

   Version: 4.6.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ja...@hvdc.ca





I am using MINGW32 build of GCC 4.6.2 on Windows 7 x64.



Range of integer*4 is from -2147483648 to +2147483647. If you try to assign

-2147483648 to an integer*4 variable, it gives an error saying too big for its

kind.


[Bug fortran/33285] integer too big compile error in gfortran

2013-05-02 Thread pinskia at gcc dot gnu.org


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



Andrew Pinski  changed:



   What|Removed |Added



 CC||jayas at hvdc dot ca



--- Comment #7 from Andrew Pinski  2013-05-02 
19:19:16 UTC ---

*** Bug 57148 has been marked as a duplicate of this bug. ***


[Bug fortran/57148] integer*4 fails to read largest negative number

2013-05-02 Thread pinskia at gcc dot gnu.org


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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #1 from Andrew Pinski  2013-05-02 
19:19:16 UTC ---

You are wrong in saying the range is -2147483648 to +2147483647.  In fortran

the range is symmetrical around 0.



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


[Bug rtl-optimization/57131] [4.8/4.9 Regression] Wrong register assignment?

2013-05-02 Thread jakub at gcc dot gnu.org


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



--- Comment #5 from Jakub Jelinek  2013-05-02 
19:26:38 UTC ---

Author: jakub

Date: Thu May  2 06:00:46 2013

New Revision: 198511



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

Log:

PR rtl-optimization/57131

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



Added:

trunk/gcc/testsuite/gcc.c-torture/execute/pr57131.c

Modified:

trunk/gcc/testsuite/ChangeLog



Author: jakub

Date: Thu May  2 19:25:34 2013

New Revision: 198560



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

Log:

PR rtl-optimization/57131

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



Added:

branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57131.c

Modified:

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog


[Bug target/57091] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1268 with -mcmodel=large and indirect call

2013-05-02 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 CC||jakub at gcc dot gnu.org

 Resolution||FIXED

   Target Milestone|--- |4.8.1



--- Comment #2 from Jakub Jelinek  2013-05-02 
19:28:38 UTC ---

Author: vmakarov

Date: Thu May  2 19:02:19 2013

New Revision: 198558



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

Log:

2013-05-02  Vladimir Makarov  



* lra-constraints.c (process_alt_operands): Add checking alt

number to choose the best alternative.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/lra-constraints.c



Author: vmakarov

Date: Wed May  1 18:54:17 2013

New Revision: 198503



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

Log:

2013-05-01  Vladimir Makarov  



PR target/57091

* lra-constraints.c (best_small_class_operands_num): Remove.

(process_alt_operands): Remove small_class_operands_num.  Take

small classes operands into losers and only if the operand is not

matched.  Modify debugging output.

(curr_insn_transform): Remove best_small_class_operands_num.

Print insn name.



2013-05-01  Vladimir Makarov  



PR target/57091

* gcc.target/i386/pr57091.c: New test.





Added:

trunk/gcc/testsuite/gcc.target/i386/pr57091.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/lra-constraints.c

trunk/gcc/testsuite/ChangeLog

Author: vmakarov

Date: Thu May  2 19:16:29 2013

New Revision: 198559



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

Log:

2013-05-02  Vladimir Makarov  



Backport from mainline

2013-05-02  Vladimir Makarov  



* lra-constraints.c (process_alt_operands): Add checking alt

number to choose the best alternative.



2013-05-01  Vladimir Makarov  



PR target/57091

* lra-constraints.c (best_small_class_operands_num): Remove.

(process_alt_operands): Remove small_class_operands_num.  Take

small classes operands into losers and only if the operand is not

matched.  Modify debugging output.

(curr_insn_transform): Remove best_small_class_operands_num.

Print insn name.



2013-05-02  Vladimir Makarov  



Backport from mainline

PR target/57091

* gcc.target/i386/pr57091.c: New test.





Added:

branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr57091.c

Modified:

branches/gcc-4_8-branch/gcc/ChangeLog

branches/gcc-4_8-branch/gcc/lra-constraints.c

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog


[Bug target/57097] [4.8 Regression] ICE: in find_hard_regno_for, at lra-assigns.c:561 with -O2 -fPIC -m32

2013-05-02 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #4 from Jakub Jelinek  2013-05-02 
19:29:15 UTC ---

Author: vmakarov

Date: Thu May  2 17:56:40 2013

New Revision: 198557



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

Log:

2013-05-02  Vladimir Makarov  



Backport from mainline

2013-04-29  Vladimir Makarov  



PR target/57097

* lra-constraints.c (process_alt_operands): Discourage a bit more

using memory for pseudos.  Print cost dump for alternatives.

Modify cost values for conflicts with early clobbers.

(curr_insn_transform): Spill pseudos reassigned to NO_REGS.



2013-05-02  Vladimir Makarov  



Backport from mainline

2013-04-29  Vladimir Makarov  



PR target/57097

* gcc.target/i386/pr57097.c: New test.





Added:

branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr57097.c

Modified:

branches/gcc-4_8-branch/gcc/ChangeLog

branches/gcc-4_8-branch/gcc/lra-constraints.c

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog


[Bug rtl-optimization/57046] [4.8 Regression] wrong code generated by gcc 4.8.0 on i686

2013-05-02 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #7 from Jakub Jelinek  2013-05-02 
19:29:52 UTC ---

Author: vmakarov

Date: Thu May  2 17:52:45 2013

New Revision: 198556



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

Log:

2013-05-02  Vladimir Makarov  



Backport from mainline

2013-04-24  Vladimir Makarov  



PR rtl-optimizations/57046

* lra-constraints (split_reg): Set up lra_risky_transformations_p

for multi-reg splits.



2013-05-02  Vladimir Makarov  



Backport from mainline

2013-04-24  Vladimir Makarov  



PR rtl-optimizations/57046

* gcc.target/i386/pr57046.c: New test.





Added:

branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr57046.c

Modified:

branches/gcc-4_8-branch/gcc/ChangeLog

branches/gcc-4_8-branch/gcc/lra-constraints.c

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog


[Bug target/57018] [4.8 Regression] Miscompilation of bison 2.7.1 under "-Os -fomit-frame-pointer"

2013-05-02 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #11 from Jakub Jelinek  2013-05-02 
19:30:23 UTC ---

Author: vmakarov

Date: Thu May  2 17:50:08 2013

New Revision: 198555



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

Log:

2013-05-02  Vladimir Makarov  



Backport from mainline

2013-04-22  Vladimir Makarov  



PR target/57018

* lra-eliminations.c (mark_not_eliminable): Prevent elimination of

a set sp if no stack realignment.



2013-05-02  Vladimir Makarov  



Backport from mainline

2013-04-22  Vladimir Makarov  



PR target/57018

* gcc.target/i386/pr57018.c: New test.





Added:

branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr57018.c

Modified:

branches/gcc-4_8-branch/gcc/ChangeLog

branches/gcc-4_8-branch/gcc/lra-eliminations.c

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog


[Bug rtl-optimization/56999] [4.8 Regression] LRA caused miscompilation of xulrunner

2013-05-02 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #9 from Jakub Jelinek  2013-05-02 
19:31:16 UTC ---

Author: vmakarov

Date: Thu May  2 17:46:58 2013

New Revision: 198554



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

Log:

2013-05-02  Vladimir Makarov  



Backport from mainline

2013-04-18  Vladimir Makarov  



PR rtl-optimization/56992

* lra-coalesce.c (coalescable_pseudo_p): Remove 2nd parameter and

related code.

(lra_coalesce): Remove split_origin_bitmap and related code.

* lra.c (lra): Coalesce after undoing inheritance. Recreate live

ranges if necessary.



2013-05-02  Vladimir Makarov  



Backport from mainline

2013-04-18  Jakub Jelinek  



PR rtl-optimization/56992

* g++.dg/opt/pr56999.C: New test.





Added:

branches/gcc-4_8-branch/gcc/testsuite/g++.dg/opt/pr56999.C

Modified:

branches/gcc-4_8-branch/gcc/ChangeLog

branches/gcc-4_8-branch/gcc/lra-coalesce.c

branches/gcc-4_8-branch/gcc/lra.c

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog


[Bug rtl-optimization/56847] [4.8 Regression] '-fpie' triggers - internal compiler error: in gen_add2_insn, at optabs.c:4705

2013-05-02 Thread jakub at gcc dot gnu.org


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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #11 from Jakub Jelinek  2013-05-02 
19:31:50 UTC ---

Author: vmakarov

Date: Thu May  2 17:41:53 2013

New Revision: 198553



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

Log:

2013-05-02  Vladimir Makarov  



Backport from mainline

2013-04-19  Vladimir Makarov  



PR rtl-optimization/56847

* lra-constraints.c (process_alt_operands): Discourage alternative

with non-matche doffsettable memory constraint fro memory with

known offset.



2013-05-02  Vladimir Makarov  



Backport from mainline

2013-04-19  Vladimir Makarov  



PR rtl-optimization/56847

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





Added:

branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr56847.c

Modified:

branches/gcc-4_8-branch/gcc/ChangeLog

branches/gcc-4_8-branch/gcc/lra-constraints.c

branches/gcc-4_8-branch/gcc/testsuite/ChangeLog


[Bug tree-optimization/57149] New: [4.8 Regression] wrong -Wmaybe-uninitialized warning with -Os

2013-05-02 Thread doko at gcc dot gnu.org


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



 Bug #: 57149

   Summary: [4.8 Regression] wrong -Wmaybe-uninitialized warning

with -Os

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: d...@gcc.gnu.org





Created attachment 30007

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30007

preprocessed source



seen when building a driver in an arm linux 3.4 kernel, the warning shows up

when building with -Os, but not when building with -O[g123], works with all

optimization levels in 4.7.3.



$ gcc -Wall -Wno-unused-but-set-variable -Os -marm -mapcs -mabi=aapcs-linux

-march=armv7-a -msoft-float -g -c ci13xxx_msm.i)

In file included from drivers/usb/gadget/ci13xxx_msm.c:21:0:

drivers/usb/gadget/ci13xxx_msm.c: In function 'msm_udc_irq':

drivers/usb/gadget/ci13xxx_udc.c:2544:13: warning: 'err' may be used

uninitialized in this function [-Wmaybe-uninitialized]

dbg_event(_usb_addr(mEp), "ERROR", err);

 ^

drivers/usb/gadget/ci13xxx_udc.c:2357:23: note: 'err' was declared here

   int type, num, dir; int err = -EINVAL;

   ^

$ gcc -Wall -Wno-unused-but-set-variable -Og -marm -mapcs -mabi=aapcs-linux

-march=armv7-a -msoft-float -g -c ci13xxx_msm.i

$


[Bug target/57150] New: GCC when targeting power7 spills long double using VSX instructions.

2013-05-02 Thread meissner at gcc dot gnu.org


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



 Bug #: 57150

   Summary: GCC when targeting power7 spills long double using VSX

instructions.

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: meiss...@gcc.gnu.org





Created attachment 30008

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30008

Cut down example to show the problem, using -mcpu=power7 -m64



In the glibc file e_scalbl.c, the compiler is using VSX stxvd2x and lxvd2x

instructions to spill long double, even though only 1/2 of the register is

used.  The compiler should use scalar load/store instructions.


[Bug target/57150] GCC when targeting power7 spills long double using VSX instructions.

2013-05-02 Thread meissner at gcc dot gnu.org


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



--- Comment #1 from Michael Meissner  2013-05-02 
19:37:21 UTC ---

Created attachment 30009

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30009

Assembler file


[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

2013-05-02 Thread jakub at gcc dot gnu.org


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



--- Comment #9 from Jakub Jelinek  2013-05-02 
19:37:46 UTC ---

Created attachment 30010

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30010

gcc49-pr57074.patch



Fix I've tried, but it didn't survive bootstrap, will need to debug it tomorrow

(unless somebody beats me to do that).


[Bug target/57150] GCC when targeting power7 spills long double using VSX instructions.

2013-05-02 Thread meissner at gcc dot gnu.org


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



Michael Meissner  changed:



   What|Removed |Added



 Target||powerpc64-gnu-linux

 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2013-05-02

   Host||powerp64-gnu-linux

 Ever Confirmed|0   |1

  Known to fail||4.5.0

  Build||powerpc64-gnu-linux



--- Comment #2 from Michael Meissner  2013-05-02 
19:42:51 UTC ---

This goes back to the original VSX submission for GCC 4.5.



While the code is slow, it does appear to be correct.


[Bug middle-end/57073] __builtin_powif (-1.0, k) should be optimized to "1.0 - 2.0 * (K%2)"

2013-05-02 Thread tkoenig at gcc dot gnu.org


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



Thomas Koenig  changed:



   What|Removed |Added



  Attachment #29968|0   |1

is obsolete||



--- Comment #6 from Thomas Koenig  2013-05-02 
19:56:33 UTC ---

Created attachment 30011

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30011

Patch that should work, but doesn't.



Here's the actual patch that fails, without the Fortran

front end part.


[Bug fortran/57148] integer*4 fails to read largest negative number

2013-05-02 Thread kargl at gcc dot gnu.org


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



kargl at gcc dot gnu.org changed:



   What|Removed |Added



 CC||kargl at gcc dot gnu.org



--- Comment #2 from kargl at gcc dot gnu.org 2013-05-02 20:02:58 UTC ---

(In reply to comment #1)

> You are wrong in saying the range is -2147483648 to +2147483647.  In fortran

> the range is symmetrical around 0.

> 

> *** This bug has been marked as a duplicate of bug 33285 ***



Not quite right.  The model numbers imply a symmetric range.

It is processor dependent on whether the most negative

value is -2147483648.  Without see the source, it's difficult

to say what OP hit. If her/his code is equivalent to



program foo

  integer i

  read(*,*) i

  print *, i

end program foo



update to 4.8. or trunk.  



This is trunk.

% gfc4x -o foo foo.f90

% ./foo

-2147483648 

 -2147483648



This is 4.7.something_revision.

gfc47 -o foo foo.f90

troutmask:sgk[214] ./foo

-2147483648 

At line 3 of file foo.f90 (unit = 5, file = 'stdin')

Fortran runtime error: Integer overflow while reading item 1



If OP tries a simple assignment he/she will hit an issue

with a unary minus operator.


[Bug other/57151] New: Wasted work in method verify_cgraph_node

2013-05-02 Thread pchang9 at cs dot wisc.edu


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



 Bug #: 57151

   Summary: Wasted work in method verify_cgraph_node

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: other

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: pcha...@cs.wisc.edu





Created attachment 30012

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30012

Suggested patch



The problem appears in version 4.8 and in revision 198496. I attached

a one-line patch that fixes it.



In method "verify_cgraph_node" in cgraph.c, the second loop over

"node->indirect_calls" should break immediately after "error_found" is

set to "true".  All the iterations after "error_found" is set to

"true" do not perform any useful work, at best they just set

"error_found" again to "true".



Method "ix86_legitimate_combined_insn" in i386.c has a similar loop

over "recog_data.n_alternatives", and this loop breaks immediately

after "win" is set to "true", just like in the proposed patch.  Other

methods (e.g., "tagged_types_tu_compatible_p" in c-typeck.c,

"rest_of_record_type_compilation" in utils.c, "distance_agu_use" in

i386.c) also have similar loops that break like in the proposed patch.


[Bug c++/54318] [C++11] Bogus "template instantiation depth exceeds maximum" error + segfault

2013-05-02 Thread zeratul976 at hotmail dot com


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



Nathan Ridge  changed:



   What|Removed |Added



Version|4.8.0   |4.7.3



--- Comment #1 from Nathan Ridge  2013-05-02 
20:54:17 UTC ---

This seems to be fixed in the 4.8.0 release.



Should I keep the bug open so it might be fixed in the 4.7 series?


[Bug target/57150] GCC when targeting power7 spills long double using VSX instructions.

2013-05-02 Thread meissner at gcc dot gnu.org


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



--- Comment #3 from Michael Meissner  2013-05-02 
21:03:08 UTC ---

It shows up due to -fcaller-saves, which creates a V2DF save area.


[Bug middle-end/57073] __builtin_powif (-1.0, k) should be optimized to "1.0 - 2.0 * (K%2)"

2013-05-02 Thread burnus at gcc dot gnu.org


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



--- Comment #7 from Tobias Burnus  2013-05-02 
21:08:36 UTC ---

The problem is the following in gimplify.c:



In gimplify_cond_expr, one has:



  /* If this COND_EXPR has a value, copy the values into a temporary within

 the arms.  */

  if (!VOID_TYPE_P (type))

  ...  

  /* If either an rvalue is ok or we do not require an lvalue, create the

 temporary.  But we cannot do that if the type is addressable.  */

  if (((fallback & fb_rvalue) || !(fallback & fb_lvalue))

  && !TREE_ADDRESSABLE (type))

  ...

  tmp = create_tmp_var (type, "iftmp");

  result = tmp;



This is then used in the then_ and else_ branches, e.g.



 

arg 1 

constant 1.0e+0>>



That's passed to gimplify_modify_expr, where one runs into the assert:



  if (gimplify_ctxp->into_ssa && is_gimple_reg (*to_p))

{

  /* We should have got an SSA name from the start.  */

  gcc_assert (TREE_CODE (*to_p) == SSA_NAME);

}



which fails as the TREE_CODE of "iftmp.1" is VAR_DECL.


[Bug c++/53846] [c++11] memory exhaustion on simple recursive function template that uses decltype

2013-05-02 Thread zeratul976 at hotmail dot com


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



--- Comment #3 from Nathan Ridge  2013-05-02 
21:12:27 UTC ---

This seems to be fixed in the 4.8.0 release. Close?


[Bug middle-end/57073] __builtin_powif (-1.0, k) should be optimized to "1.0 - 2.0 * (K%2)"

2013-05-02 Thread burnus at gcc dot gnu.org


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



--- Comment #8 from Tobias Burnus  2013-05-02 
22:00:53 UTC ---

For completeness, gimplify_ctxp->into_ssa is 0 for the -O0 optimization and it

gets set to 1 in gimple_regimplify_operands. Thus, it is not surprising that it

works with the -O0 example ("(-1.0)**k") but not with the -O1 example

("a=-1;a**k").



If one ignores the assert, one runs into: control flow within basic block 2.


[Bug libgcj/57074] gcc-4.8.0 libgcj regression on 32bit Power architecture

2013-05-02 Thread amodra at gmail dot com


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



Alan Modra  changed:



   What|Removed |Added



   Target Milestone|4.8.1   |---



--- Comment #10 from Alan Modra  2013-05-02 23:04:37 
UTC ---

Another fairly easy fix is to make output_object_block() emit the .align

directives instead of padding.  Yes, this covers up the real bug that Jakub has

been looking at, but it might be worth doing for robustness.


[Bug c++/57152] New: [C++11] Compiler segfault when using const in template alias

2013-05-02 Thread ali.rostai at gmail dot com


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



 Bug #: 57152

   Summary: [C++11] Compiler segfault when using const in template

alias

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ali.ros...@gmail.com





Created attachment 30013

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30013

preprocessed source



Segfaul for this program





template< typename T >

using variadic_input = const std::initializer_list;



void function( variadic_input ints )

{}



int main(){

function({1,2});

}





The problem is with const keyword in alias declaration. If you remove it, no

problem...



gcc --version

gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2



uname -a

Linux ubc 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:32:08 UTC 2012 i686 i686

i686 GNU/Linux


[Bug gcov-profile/57121] undefined reference to gcov_merge_init and gcov_merge_add

2013-05-02 Thread netravathi.muniraju at asia dot thalesgroup.com


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



--- Comment #9 from Netra  
2013-05-03 00:58:00 UTC ---

(In reply to comment #5)

> Simple work around is to use -fprofile-generate instead of -lgcov and GCC 
> knows

> what it should be linking against then.



Andrew ,



It would be great if you can provide me some more pointers as in why i am

leading to these "undefined reference" errors .



Thanks


[Bug c++/57153] New: [C++11] tries to use copy constructor for in-class initialized member in default constructor of template struct

2013-05-02 Thread f.heckenb...@fh-soft.de


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



 Bug #: 57153

   Summary: [C++11] tries to use copy constructor for in-class

initialized member in default constructor of template

struct

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: f.heckenb...@fh-soft.de





Created attachment 30014

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30014

Test case



The included test case produces the following error:



% g++-4.7 -std=c++11 test.cpp 

test.cpp: In constructor 'constexpr B<0>::B()':

test.cpp:8:8: error: use of deleted function 'A::A(const A&)'

test.cpp:4:3: error: declared here

test.cpp: In function 'int main()':

test.cpp:17:9: note: synthesized method 'constexpr B<0>::B()' first required

here 



I don't think a copy constructor of the member should be needed for the default

constructor of the containing struct.



The error disappears when I declare the latter explicitly, but not when I

declare it as "= default".



Is also disappears if struct B is not a template. I don't see why this should

make a difference.


[Bug bootstrap/57154] New: [4.9 Regression] Bootstrap broken for powerpc64-unknown-linux-gnu

2013-05-02 Thread wschmidt at gcc dot gnu.org

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

 Bug #: 57154
   Summary: [4.9 Regression] Bootstrap broken for
powerpc64-unknown-linux-gnu
Classification: Unclassified
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wschm...@gcc.gnu.org
CC: berg...@gcc.gnu.org, meiss...@gcc.gnu.org,
pthau...@gcc.gnu.org, tejohn...@gcc.gnu.org
  Host: powerpc*-*-*
Target: powerpc*-*-*
 Build: powerpc*-*-*


Bootstrap has been broken for PowerPC Linux since r198532:

2013-05-02  Teresa Johnson  

* loop-unswitch.c (unswitch_loop): Use helper routines with rounding
divides.
* cfg.c (update_bb_profile_for_threading): Ditto.
* tree-inline.c (copy_bb): Ditto.
(copy_edges_for_bb): Ditto.
(initialize_cfun): Ditto.
(copy_cfg_body): Ditto.
(expand_call_inline): Ditto.
* ipa-inline-analysis.c (estimate_edge_size_and_time): Ditto.
(estimate_node_size_and_time): Ditto.
(inline_merge_summary): Ditto.
* cgraphclones.c (cgraph_clone_edge): Ditto.
(cgraph_clone_node): Ditto.
* sched-rgn.c (compute_dom_prob_ps): Ditto.
(compute_trg_info): Ditto.

Configuration information:

  $ /home/wschmidt/gcc/gcc-mainline-base/configure --target=powerpc64-linux
--host=powerpc64-linux --build=powerpc64-linux --enable-threads=posix
--enable-shared --enable-__cxa_atexit
--enable-languages=c,c++,fortran,objc,obj-c++ --enable-secureplt
--enable-checking=yes --with-gmp=/home/wschmidt/gcc-libs/gcc-host-libs
--with-mpfr=/home/wschmidt/gcc-libs/gcc-host-libs
--with-mpc=/home/wschmidt/gcc-libs/gcc-host-libs-ppc64
--with-libelf=/home/wschmidt/gcc-libs/gcc-host-libs
--with-ppl=/home/wschmidt/gcc-libs/gcc-host-libs
--with-cloog=/home/wschmidt/gcc-libs/gcc-host-libs --with-long-double-128
--enable-decimal-float --disable-alsa
--prefix=/home/wschmidt/gcc/install/gcc-mainline-base --enable-lto
--with-plugin-ld=/home/meissner/tools-binutils/ppc64/bin/ld
--with-host-libstdcxx=-Wl,-Bstatic,-L/home/wschmidt/gcc-libs/gcc-host-libs/lib,-lstdc++,-Bdynamic,-lm

Failure details during stage2:

/home/wschmidt/gcc/gcc-mainline-base/gcc/cse.c: In function ‘void
remove_invalid_refs(unsigned int)’:
/home/wschmidt/gcc/gcc-mainline-base/gcc/cse.c:2005:1: internal compiler error:
in check_probability, at basic-block.h:941
 }
 ^
0x10a9351b check_probability
/home/wschmidt/gcc/gcc-mainline-base/gcc/basic-block.h:941
0x10a93573 combine_probabilities
/home/wschmidt/gcc/gcc-mainline-base/gcc/basic-block.h:950
0x10a9abcb compute_dom_prob_ps
/home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:1444
0x10a9b17b sched_rgn_local_init(int)
/home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:3291
0x10a9b313 schedule_region
/home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:2984
0x10a9f05f schedule_insns()
/home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:3384
0x10a9f1fb rest_of_handle_sched
/home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:3577
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [cse.o] Error 1
make[3]: *** Waiting for unfinished jobs
/home/wschmidt/gcc/gcc-mainline-base/gcc/emit-rtl.c: In function ‘rtx_def*
emit_pattern_after_setloc(rtx, rtx, int, rtx_def* (*)(rtx))’:
/home/wschmidt/gcc/gcc-mainline-base/gcc/emit-rtl.c:4542:1: internal compiler
error: in check_probability, at basic-block.h:941
 }
 ^
0x10a9351b check_probability
/home/wschmidt/gcc/gcc-mainline-base/gcc/basic-block.h:941
0x10a93573 combine_probabilities
/home/wschmidt/gcc/gcc-mainline-base/gcc/basic-block.h:950
0x10a9abcb compute_dom_prob_ps
/home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:1444
0x10a9b17b sched_rgn_local_init(int)
/home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:3291
0x10a9b313 schedule_region
/home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:2984
0x10a9f05f schedule_insns()
/home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:3384
0x10a9f1fb rest_of_handle_sched
/home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:3577
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [emit-rtl.o] Error 1

Compilation commands:

/home/wschmidt/gcc/build/gcc-mainline-base/./prev-gcc/xg++
-B/home/wschmidt/gcc/build/gcc-mainline-base/./prev-gcc/
-B/home/wschmidt/gcc/install/gcc-mainline-base/powerpc64-linux/bin/ -nostdinc++
-B/home/wschmidt/gcc/build/gcc-mainline-base/prev-powerpc64-linux/libstdc++-v3/src/.libs
-B/home/wschmidt/gcc/build/gcc-mainline-base/prev-powerpc64-li

[Bug bootstrap/57154] [4.9 Regression] Bootstrap broken for powerpc64-unknown-linux-gnu

2013-05-02 Thread tejohnson at google dot com

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

--- Comment #1 from Teresa Johnson  2013-05-03 
05:13:07 UTC ---
Investigating. I am not sure I have access to a powerpc64, but I am
trying to trigger it on x86_64.

Teresa

On Thu, May 2, 2013 at 9:16 PM, wschmidt at gcc dot gnu.org
 wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154
>
>  Bug #: 57154
>Summary: [4.9 Regression] Bootstrap broken for
> powerpc64-unknown-linux-gnu
> Classification: Unclassified
>Product: gcc
>Version: 4.9.0
> Status: UNCONFIRMED
>   Keywords: build
>   Severity: normal
>   Priority: P3
>  Component: bootstrap
> AssignedTo: unassig...@gcc.gnu.org
> ReportedBy: wschm...@gcc.gnu.org
> CC: berg...@gcc.gnu.org, meiss...@gcc.gnu.org,
> pthau...@gcc.gnu.org, tejohn...@gcc.gnu.org
>   Host: powerpc*-*-*
> Target: powerpc*-*-*
>  Build: powerpc*-*-*
>
>
> Bootstrap has been broken for PowerPC Linux since r198532:
>
> 2013-05-02  Teresa Johnson  
>
> * loop-unswitch.c (unswitch_loop): Use helper routines with rounding
> divides.
> * cfg.c (update_bb_profile_for_threading): Ditto.
> * tree-inline.c (copy_bb): Ditto.
> (copy_edges_for_bb): Ditto.
> (initialize_cfun): Ditto.
> (copy_cfg_body): Ditto.
> (expand_call_inline): Ditto.
> * ipa-inline-analysis.c (estimate_edge_size_and_time): Ditto.
> (estimate_node_size_and_time): Ditto.
> (inline_merge_summary): Ditto.
> * cgraphclones.c (cgraph_clone_edge): Ditto.
> (cgraph_clone_node): Ditto.
> * sched-rgn.c (compute_dom_prob_ps): Ditto.
> (compute_trg_info): Ditto.
>
> Configuration information:
>
>   $ /home/wschmidt/gcc/gcc-mainline-base/configure --target=powerpc64-linux
> --host=powerpc64-linux --build=powerpc64-linux --enable-threads=posix
> --enable-shared --enable-__cxa_atexit
> --enable-languages=c,c++,fortran,objc,obj-c++ --enable-secureplt
> --enable-checking=yes --with-gmp=/home/wschmidt/gcc-libs/gcc-host-libs
> --with-mpfr=/home/wschmidt/gcc-libs/gcc-host-libs
> --with-mpc=/home/wschmidt/gcc-libs/gcc-host-libs-ppc64
> --with-libelf=/home/wschmidt/gcc-libs/gcc-host-libs
> --with-ppl=/home/wschmidt/gcc-libs/gcc-host-libs
> --with-cloog=/home/wschmidt/gcc-libs/gcc-host-libs --with-long-double-128
> --enable-decimal-float --disable-alsa
> --prefix=/home/wschmidt/gcc/install/gcc-mainline-base --enable-lto
> --with-plugin-ld=/home/meissner/tools-binutils/ppc64/bin/ld
> --with-host-libstdcxx=-Wl,-Bstatic,-L/home/wschmidt/gcc-libs/gcc-host-libs/lib,-lstdc++,-Bdynamic,-lm
>
> Failure details during stage2:
>
> /home/wschmidt/gcc/gcc-mainline-base/gcc/cse.c: In function ‘void
> remove_invalid_refs(unsigned int)’:
> /home/wschmidt/gcc/gcc-mainline-base/gcc/cse.c:2005:1: internal compiler 
> error:
> in check_probability, at basic-block.h:941
>  }
>  ^
> 0x10a9351b check_probability
> /home/wschmidt/gcc/gcc-mainline-base/gcc/basic-block.h:941
> 0x10a93573 combine_probabilities
> /home/wschmidt/gcc/gcc-mainline-base/gcc/basic-block.h:950
> 0x10a9abcb compute_dom_prob_ps
> /home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:1444
> 0x10a9b17b sched_rgn_local_init(int)
> /home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:3291
> 0x10a9b313 schedule_region
> /home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:2984
> 0x10a9f05f schedule_insns()
> /home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:3384
> 0x10a9f1fb rest_of_handle_sched
> /home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:3577
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[3]: *** [cse.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> /home/wschmidt/gcc/gcc-mainline-base/gcc/emit-rtl.c: In function ‘rtx_def*
> emit_pattern_after_setloc(rtx, rtx, int, rtx_def* (*)(rtx))’:
> /home/wschmidt/gcc/gcc-mainline-base/gcc/emit-rtl.c:4542:1: internal compiler
> error: in check_probability, at basic-block.h:941
>  }
>  ^
> 0x10a9351b check_probability
> /home/wschmidt/gcc/gcc-mainline-base/gcc/basic-block.h:941
> 0x10a93573 combine_probabilities
> /home/wschmidt/gcc/gcc-mainline-base/gcc/basic-block.h:950
> 0x10a9abcb compute_dom_prob_ps
> /home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:1444
> 0x10a9b17b sched_rgn_local_init(int)
> /home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:3291
> 0x10a9b313 schedule_region
> /home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:2984
> 0x10a9f05f schedule_insns()
> /home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:3384
> 0x10a9f1fb rest_of_handle_sched
> /home/wschmidt/gcc/gcc-mainline-base/gcc/sched-rgn.c:3577
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please i