[Bug tree-optimization/55176] New: [4.8 Regression] Out of memory during Chromium build

[markus at trippelsdorf dot de]

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



 Bug #: 55176

   Summary: [4.8 Regression] Out of memory during Chromium build

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: mar...@trippelsdorf.de





Created attachment 28595

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

testcase



If one compiles the attached testcase with "-02" or higher,

cc1plus will quickly run out of memory and eventually be killed

by the OOM killer.



 % g++ -O2 -c exit.ii

g++: internal compiler error: Killed (program cc1plus)

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

[corsepiu at gcc dot gnu.org]

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



--- Comment #3 from Ralf Corsepius  2012-11-02 
05:35:18 UTC ---

DJ, 



any chances to see your patch from comment#1 be commited?

[Bug regression/55167] [4.8 Regression]: g++.dg/other/vector-compare.C, ICE

[hp at gcc dot gnu.org]

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



Hans-Peter Nilsson  changed:



   What|Removed |Added



 Depends on||55001



--- Comment #4 from Hans-Peter Nilsson  2012-11-02 
05:34:06 UTC ---

I made this PR depend on PR55001, which has a committed patch that solves the

regression in this PR.  So, looks like a dup, for some definition thereof.

[Bug bootstrap/55175] New: i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'

[corsepiu at gcc dot gnu.org]

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



 Bug #: 55175

   Summary: i386/sfp-exceptions.c:52:7: error: impossible

constraint in 'asm'

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

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

ReportedBy: corse...@gcc.gnu.org





Created attachment 28594

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

*.i of the file raising the breakdown



Bootstrapping gcc-trunk (xgcc (GCC) 4.8.0 20120927 (experimental)) fails with

this error for --target=i386-rtems4.11:



...

/users/rtems/src/rtems.org/rtems-gcc/BUILD-i386/./gcc/xgcc

-B/users/rtems/src/rtems.org/rtems-gcc/BUILD-i386/./gcc/ -nostdinc

-B/users/rtems/src/rtems.org/rtems-gcc/BUILD-i386/i386-rtems4.11/soft-float/newlib/

-isystem

/users/rtems/src/rtems.org/rtems-gcc/BUILD-i386/i386-rtems4.11/soft-float/newlib/targ-include

-isystem /users/rtems/src/rtems.org/rtems-gcc/newlib/libc/include

-B/opt/rtems-4.11/i386-rtems4.11/bin/ -B/opt/rtems-4.11/i386-rtems4.11/lib/

-isystem /opt/rtems-4.11/i386-rtems4.11/include -isystem

/opt/rtems-4.11/i386-rtems4.11/sys-include  -msoft-float -g -O2 -Wall -O2

-I../../../../libgcc/../newlib/libc/sys/rtems/include -g -O2 -Wall -DIN_GCC

-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings

-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 

-isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector

-Dinhibit_libc  -I. -I. -I../../.././gcc -I../../../../libgcc

-I../../../../libgcc/. -I../../../../libgcc/../gcc

-I../../../../libgcc/../include  -DHAVE_CC_TLS  -o sfp-exceptions.o -MT

sfp-exceptions.o -MD -MP -MF sfp-exceptions.dep  -c

../../../../libgcc/config/i386/sfp-exceptions.c -fvisibility=hidden

-DHIDE_EXPORTS

../../../../libgcc/config/i386/sfp-exceptions.c: In function

'__sfp_handle_exceptions':

../../../../libgcc/config/i386/sfp-exceptions.c:52:7: error: impossible

constraint in 'asm'

   asm volatile ("fdiv\t{%y0, %0|%0, %y0}" : "+t" (f));

   ^

../../../../libgcc/config/i386/sfp-exceptions.c:62:7: error: impossible

constraint in 'asm'

   asm volatile ("fdivs\t%1" : "+t" (f) : "m" (g));

   ^

make: *** [sfp-exceptions.o] Error 1

[Bug tree-optimization/55162] Loop ivopts cuts off top bits of loop counter

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #2 from Andrew Pinski  2012-11-02 
04:08:25 UTC ---

>For example, passing a virtual address 0x1000 and c = 0x8000 to the

function should actually run over the address range 0x1000 .. 0x80001000,





No it runs over the address range 0x1000 .. -1 and more as 0x8000 * 4

wraps/overflows.  If x was char* then I would say there is a bug but this is

int* which has a size of 4.

[Bug fortran/55174] internal compiler error: Segmentation fault with bad array reference

[kargl at gcc dot gnu.org]

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



kargl at gcc dot gnu.org changed:



   What|Removed |Added



 CC||kargl at gcc dot gnu.org



--- Comment #1 from kargl at gcc dot gnu.org 2012-11-02 02:57:36 UTC ---

(In reply to comment #0)

> This 4-line Fortran program has an error at line 3, where array(*) is of 
> course

> not permitted as an argument of a function.

> 

> implicit none

> integer:: array(2)=(/42,666/)

> print *, size(array(*))

> end

> 

> Other compilers (g95, ifort) correctly diagnose the error but gfortran 4.8.0 

> gives an internal compiler error: Segmentation fault and asks me to tell you.

> My compile-time output follows.

> 

> cayley[~/Jfh] % /local/scratch/gf/bin/gfortran -v trybadstar.f90

> Driving: /local/scratch/gf/bin/gfortran -v trybadstar.f90 -l gfortran -l m

> -shared-libgcc

> Using built-in specs.

> COLLECT_GCC=/local/scratch/gf/bin/gfortran

> COLLECT_LTO_WRAPPER=/local/scratch/gf/libexec/gcc/i686-pc-linux-gnu/4.8.0/lto-wrapper

> Target: i686-pc-linux-gnu

> Configured with: /local/scratch/gcc-4.8-20120701/configure

> --prefix=/local/scratch/gf --enable-languages=c,fortran --disable-libada

> --with-local-prefix=/local/scratch --with-gmp=/local/scratch

> Thread model: posix

> gcc version 4.8.0 20120701 (experimental) (GCC) 



John,



It looks like it has been fixed on trunk (aka 4.8.0).

For me, gfc4x is 4.8.0 20121002.  gfortran 4.5.x 

seems to also work, so it appears that a regression

crept in in the 4.6. development.



troutmask:sgk[209] gfc4x -o z k.f90

k.f90:2.20:



print *, size(array(*))

1

Error: Expected array subscript at (1)

troutmask:sgk[210] gfc47 -o z k.f90

f951: internal compiler error: Segmentation fault: 11

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

troutmask:sgk[211] gfc46 -o z k.f90

f951: internal compiler error: Segmentation fault: 11

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

troutmask:sgk[212] gfc45 -o z k.f90

k.f90:2.20:



print *, size(array(*))

1

Error: Expected array subscript at (1)



A quick scan of gcc/fortran/ChangeLog did not reveal

an obvious candidate for the revision that fixed the

problem.  We should probably add your test to the

testsuite to make sure it does not get broken, again.

[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe

[pinskia at gcc dot gnu.org]

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



--- Comment #39 from Andrew Pinski  2012-11-02 
02:41:37 UTC ---

(In reply to comment #38)

> Ah, the #c3 fail on powerpc was due to a powerpc glibc pthread_once bug.  And

> comment #36 should have read:

> ..previous test was for *either* atomic bool or atomic int.



Looks like the MIPS glibc pthread_once has the same issue too.  I should have

read the comments fully to see that.

[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe

[amodra at gmail dot com]

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



--- Comment #38 from Alan Modra  2012-11-02 02:39:29 
UTC ---

Ah, the #c3 fail on powerpc was due to a powerpc glibc pthread_once bug.  And

comment #36 should have read:

..previous test was for *either* atomic bool or atomic int.

[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe

[pinskia at gcc dot gnu.org]

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



--- Comment #37 from Andrew Pinski  2012-11-02 
02:16:48 UTC ---

(In reply to comment #36)

> The change I mention in #c22

>  http://gcc.gnu.org/viewcvs?view=revision&revision=184110

> tests for atomic ops on all of bool, short, int and long long, where the

> previous test was for *either* atomic bool or atomic short.  My fix for 
> powerpc

> removed the long long test.  Does mips lack atomic on bool or short?



No it does not lack atomic for either book or short.  I am getting exactly the

same failure as mentioned in #c3 and not the double free though.

[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe

[amodra at gmail dot com]

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



--- Comment #36 from Alan Modra  2012-11-02 02:13:20 
UTC ---

The change I mention in #c22

 http://gcc.gnu.org/viewcvs?view=revision&revision=184110

tests for atomic ops on all of bool, short, int and long long, where the

previous test was for *either* atomic bool or atomic short.  My fix for powerpc

removed the long long test.  Does mips lack atomic on bool or short?

[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe

[pinskia at gcc dot gnu.org]

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



--- Comment #35 from Andrew Pinski  2012-11-02 
01:35:35 UTC ---

I get the same "randomish" failure on MIPS64 (the Octeon 1 with 16 cores) with

GCC 4.7.  The patch listed below will not help me at all as the code is already

using the __atomic_* functions.  Was there another change to the libstdc++ code

which fixes similar issue too?

[Bug fortran/55174] New: internal compiler error: Segmentation fault with bad array reference

[john.harper at vuw dot ac.nz]

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



 Bug #: 55174

   Summary: internal compiler error: Segmentation fault with bad

array reference

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: john.har...@vuw.ac.nz





This 4-line Fortran program has an error at line 3, where array(*) is of course

not permitted as an argument of a function.



implicit none

integer:: array(2)=(/42,666/)

print *, size(array(*))

end



Other compilers (g95, ifort) correctly diagnose the error but gfortran 4.8.0 

gives an internal compiler error: Segmentation fault and asks me to tell you.

My compile-time output follows.



cayley[~/Jfh] % /local/scratch/gf/bin/gfortran -v trybadstar.f90

Driving: /local/scratch/gf/bin/gfortran -v trybadstar.f90 -l gfortran -l m

-shared-libgcc

Using built-in specs.

COLLECT_GCC=/local/scratch/gf/bin/gfortran

COLLECT_LTO_WRAPPER=/local/scratch/gf/libexec/gcc/i686-pc-linux-gnu/4.8.0/lto-wrapper

Target: i686-pc-linux-gnu

Configured with: /local/scratch/gcc-4.8-20120701/configure

--prefix=/local/scratch/gf --enable-languages=c,fortran --disable-libada

--with-local-prefix=/local/scratch --with-gmp=/local/scratch

Thread model: posix

gcc version 4.8.0 20120701 (experimental) (GCC) 

COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro'

 /local/scratch/gf/libexec/gcc/i686-pc-linux-gnu/4.8.0/f951 trybadstar.f90

-quiet -dumpbase trybadstar.f90 -mtune=generic -march=pentiumpro -auxbase

trybadstar -version -fintrinsic-modules-path

/local/scratch/gf/lib/gcc/i686-pc-linux-gnu/4.8.0/finclude -o /tmp/cccgAIgM.s

GNU Fortran (GCC) version 4.8.0 20120701 (experimental) (i686-pc-linux-gnu)

compiled by GNU C version 4.8.0 20120701 (experimental), GMP version

5.0.5, MPFR version 3.1.0, MPC version 0.9

warning: GMP header version 5.0.5 differs from library version 5.0.3.

warning: MPFR header version 3.1.0 differs from library version 3.1.0-p3.

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

GNU Fortran (GCC) version 4.8.0 20120701 (experimental) (i686-pc-linux-gnu)

compiled by GNU C version 4.8.0 20120701 (experimental), GMP version

5.0.5, MPFR version 3.1.0, MPC version 0.9

warning: GMP header version 5.0.5 differs from library version 5.0.3.

warning: MPFR header version 3.1.0 differs from library version 3.1.0-p3.

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

f951: internal compiler error: Segmentation fault

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

cayley[~/Jfh] %

[Bug rtl-optimization/44194] struct returned by value generates useless stores

[eraman at gcc dot gnu.org]

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



--- Comment #50 from eraman at gcc dot gnu.org 2012-11-02 00:28:45 UTC ---

Author: eraman

Date: Fri Nov  2 00:28:40 2012

New Revision: 193085



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

Log:

Backport 191302 and 192651 from trunk:



2012-09-14  Eric Botcazou  



PR rtl-optimization/44194

* calls.c (expand_call): In the PARALLEL case, copy the return value

into pseudos instead of spilling it onto the stack.

* emit-rtl.c (adjust_address_1): Rename ADJUST into ADJUST_ADDRESS and

add new ADJUST_OBJECT parameter.

If ADJUST_OBJECT is set, drop the underlying object if it cannot be

proved that the adjusted memory access is still within its bounds.

(adjust_automodify_address_1): Adjust call to adjust_address_1.

(widen_memory_access): Likewise.

* expmed.c (store_bit_field_1): Call adjust_bitfield_address instead

of adjust_address.  Do not drop the underlying object of a MEM.

(store_fixed_bit_field): Likewise.

(extract_bit_field_1): Likewise.  Fix oversight in recursion.

(extract_fixed_bit_field): Likewise.

* expr.h (adjust_address_1): Adjust prototype.

(adjust_address): Adjust call to adjust_address_1.

(adjust_address_nv): Likewise.

(adjust_bitfield_address): New macro.

(adjust_bitfield_address_nv): Likewise.

* expr.c (expand_assignment): Handle a PARALLEL in more cases.

(store_expr): Likewise.

(store_field): Likewise.



* dse.c: Fix typos in the head comment.

2012-10-21  Eric Botcazou  



PR rtl-optimization/44194

* calls.c (expand_call): Allow sibling calls in the PARALLEL case.



gcc/testsuite/ChangeLog:

2012-09-14  Eric Botcazou  

* gcc.dg/pr44194-1.c: Check that there are no memory accesses left.





Modified:

branches/google/gcc-4_7/gcc/ChangeLog.google-4_7

branches/google/gcc-4_7/gcc/calls.c

branches/google/gcc-4_7/gcc/dse.c

branches/google/gcc-4_7/gcc/emit-rtl.c

branches/google/gcc-4_7/gcc/expmed.c

branches/google/gcc-4_7/gcc/expr.c

branches/google/gcc-4_7/gcc/expr.h

branches/google/gcc-4_7/gcc/testsuite/ChangeLog.google-4_7

branches/google/gcc-4_7/gcc/testsuite/gcc.dg/pr44194-1.c

[Bug middle-end/55001] Handle VEC_COND_EXPR better in tree-vect-generic.c

[glisse at gcc dot gnu.org]

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



Marc Glisse  changed:



   What|Removed |Added



Summary|Handle VEC_COND_EXPR in |Handle VEC_COND_EXPR better

   |tree-vect-generic.c |in tree-vect-generic.c



--- Comment #3 from Marc Glisse  2012-11-01 23:43:38 
UTC ---

When vcond is not handled for large vector types, the code goes straight to

scalars. It should first try small vectors, as is done for other operations.

[Bug middle-end/55001] Handle VEC_COND_EXPR in tree-vect-generic.c

[glisse at gcc dot gnu.org]

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



--- Comment #2 from Marc Glisse  2012-11-01 23:39:48 
UTC ---

Author: glisse

Date: Thu Nov  1 23:39:44 2012

New Revision: 193077



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

Log:

2012-11-01  Marc Glisse  



PR middle-end/55001



gcc/

* tree-vect-generic.c (expand_vector_condition): New function.

(expand_vector_operations_1): Call it.



testsuite/

* g++.dg/ext/vector19.C: Remove target restrictions.

* gcc.dg/fold-compare-7.c: New testcase.





Added:

trunk/gcc/testsuite/gcc.dg/fold-compare-7.c   (with props)

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/g++.dg/ext/vector19.C

trunk/gcc/tree-vect-generic.c



Propchange: trunk/gcc/testsuite/gcc.dg/fold-compare-7.c

('svn:eol-style' added)



Propchange: trunk/gcc/testsuite/gcc.dg/fold-compare-7.c

('svn:keywords' added)

[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument

[manu at gcc dot gnu.org]

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

--- Comment #20 from Manuel López-Ibáñez  2012-11-01 
23:23:41 UTC ---
(In reply to comment #19)
> Reported as bug 55173. I'm not going to claim to understand bug 43486
> sufficiently to know it is the same issue, but if you are sure, please feel
> free to close as duplicate.

Well, it is the same underlying issue. It could be worked-around case by case
by passing "some" location (like the = location) down to the warning point. But
this is likely quite a large refactoring. 

The alternative is some general infrastructure like the one proposed in:
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01222.html, which would require an
even more massive refactoring to be useful. In fact, that particular proposal
would still require to pass down an explicit location, because it does not
actually add locations to constants, but stores their location together with
the assignment expression (and the assignment expression is not passed down to
the point of warning, only the without-location constant).

[Bug middle-end/55103] [4.8 Regression] All MIPS16 attribute tests ICEs

[sje at gcc dot gnu.org]

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



Steve Ellcey  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #4 from Steve Ellcey  2012-11-01 23:17:48 
UTC ---

I have checked in a patch for this problem as an obvious fix.



http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00153.html



I forgot to put the bug number in ChangeLog, that is why bugzilla

did not get updated automatically.

[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[hjl.tools at gmail dot com]

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



--- Comment #17 from H.J. Lu  2012-11-01 23:07:06 
UTC ---

T(In reply to comment #16)

> > I think the bug is in unsigned array index computation as

> > shown in Comment 7. dyn->d_tag is signed type and Pmode

> > != ptr_mode here.

> 

> Possibly, you must be extra careful with these kinds of awkward setups.  We

> already had similar issues in the past (MEM_REF expansion on SPARC64, array

> indexes on IA-64/VMS) but the bugs were in the RTL expansion.  I'll dig.



I agree. It is a pain to work with Pmode == DImode and ptr_mode == SImode

for x32.  On the other hand, it does expose many issues in middle-end as

well as in backend.

[Bug c++/43486] Preserve variable-use locations

[paolo.carlini at oracle dot com]

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



--- Comment #7 from Paolo Carlini  2012-11-01 
23:06:54 UTC ---

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

[Bug c++/55173] GCC gives wrong location, and ignores -isystem, when warning about default arguments

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #1 from Paolo Carlini  2012-11-01 
23:06:54 UTC ---

Dup



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

[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument

[mw_triad at users dot sourceforge.net]

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



--- Comment #19 from Matthew Woehlke  
2012-11-01 23:04:42 UTC ---

Reported as bug 55173. I'm not going to claim to understand bug 43486

sufficiently to know it is the same issue, but if you are sure, please feel

free to close as duplicate.

[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #18 from Manuel López-Ibáñez  2012-11-01 
23:00:51 UTC ---
(In reply to comment #15)
> This is what I meant when I said that the issue is different, and is much more
> general than -Wzero-as-null-pointer-constant. Consider, eg, with -Woverflow:
> 
> #pragma GCC system_header
> 
> class Foo
> {
>  public:
>   Foo(signed char);
> };
> 
> class Bar
> {
>  public:
>   Bar(Foo = 1);
> };

The issue is that literals don't have locations, so input_location is used. And
input_location here is in the main file, so system_header doesn't apply. This
is why input_location must die.

Clang uses the correct location for warning, so it honors system_header
(requires -Wsystem-headers):

In file included from pr52718.c:1:
./pr52718.h:11:13: warning: implicit conversion from 'int' to 'signed char'
changes value from 1 to 16 [-Wconstant-conversion]
  Bar(Foo = 1);
^
1 warning generated.

Ultimately, GCC needs to track the locations of literals like clang does.
Everything else is a hack around the main issue. This is PR43486. There have
been some recent attempts
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01222.html, but I am afraid that
work seems stalled for lack of time/help.

[Bug c++/55173] New: GCC gives wrong location, and ignores -isystem, when warning about default arguments

[mw_triad at users dot sourceforge.net]

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



 Bug #: 55173

   Summary: GCC gives wrong location, and ignores -isystem, when

warning about default arguments

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: mw_tr...@users.sourceforge.net





This came up originally related to bug 52718, but according to Paolo there, is

not actually related at all...



Consider the following header:



#pragma GCC system_header // or include via -isystem

class Foo

{

  Foo(void* = 0);

};

class Bar

{

  Bar(Foo = 0, void* = 0)

};



The following instantiation:



Bar bar;



...trips -Wzero-as-null-pointer-constant (also, the warning is reported in the

source file, not the header).



This appears to only happen when a default parameter implicitly invokes a

constructor, where the warning occurs in the constructor invocation. IOW, this:



Bar bar(nullptr);



...does not trigger a warning, as 'Foo(nullptr)' is okay.



Besides the less-helpful-than-desired diagnostic, this behavior is unfortunate,

as it prevents promoting warnings to errors in the face of such constructs, or

else forcing programmers to avoid use of default parameters.

[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[ebotcazou at gcc dot gnu.org]

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



--- Comment #16 from Eric Botcazou  2012-11-01 
23:00:06 UTC ---

> The patch compiles testcase, but totally miscompiles glibc.



Ouch.  Then this means that the existing non-PIC code is wrong as well.



> I think the bug is in unsigned array index computation as

> shown in Comment 7. dyn->d_tag is signed type and Pmode

> != ptr_mode here.



Possibly, you must be extra careful with these kinds of awkward setups.  We

already had similar issues in the past (MEM_REF expansion on SPARC64, array

indexes on IA-64/VMS) but the bugs were in the RTL expansion.  I'll dig.

[Bug fortran/55172] New: ICE on invalid: gfc_variable_attr(): Bad array reference

[abensonca at gmail dot com]

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



 Bug #: 55172

   Summary: ICE on invalid: gfc_variable_attr(): Bad array

reference

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

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

ReportedBy: abenso...@gmail.com





The following test case produces and ICE with gfortran 4.8 (r193051):



module gn

  type :: ncb

  end type ncb

  type, public :: tn

 class(ncb), allocatable, dimension(:) :: cb

  end type tn

contains

  integer function name(self)

implicit none

class (tn), intent(in) :: self

select type (component => self%cb(i))

end select

  end function name

end module gn



$ gfortran -v

Using built-in specs.

COLLECT_GCC=gfortran

COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-

linux-gnu/4.8.0/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: ../gcc-trunk/configure --

prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --

disable-multilib --with-gmp=/home/abenson/Galacticus/Tools

Thread model: posix

gcc version 4.8.0 20121031 (experimental) (GCC) 



$ gfortran -c bug4.F90 -o bug4.o

bug4.F90:14.13:



end module gn

 1   

Internal Error at (1):

gfc_variable_attr(): Bad array reference





The code is invalid because the "name" function contains "implicit none" but 

the variable "i" used in:



select type (component => self%cb(i))



is not explicitly defined. If I remove the "implicit none" or explicitly 

define "i" the ICE goes away.





(Reported by Janus at http://gcc.gnu.org/ml/fortran/2012-11/msg5.html):

With 4.7 the ICE also occurs, but only after the correct error message:



select type (component => self%cb(i))

   1

Error: Symbol 'i' at (1) has no IMPLICIT type

[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument

[paolo.carlini at oracle dot com]

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



--- Comment #17 from Paolo Carlini  2012-11-01 
22:42:05 UTC ---

If you like, sure. I want to emphasize again that the issue really is about the

behavior of the pragma vs warnings for default arguments, *any* warning, and if

you check is *very* old. Before filing a new PR please double check that the

issue has not been discussed already and maybe resolved as wontfix for some

reason. Thanks.

[Bug rtl-optimization/54457] [x32] Fail to combine 64bit index + constant

[hjl.tools at gmail dot com]

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



--- Comment #9 from H.J. Lu  2012-11-01 22:37:20 
UTC ---

Like this:



# Return 1 if -mx32 can compile, 0 otherwise.



proc check_effective_target_maybe_x32 { } {

return [check_no_compiler_messages maybe_x32 object {

void foo (void) {}

} {-mx32}]

}

[Bug rtl-optimization/54457] [x32] Fail to combine 64bit index + constant

[hjl.tools at gmail dot com]

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



--- Comment #8 from H.J. Lu  2012-11-01 22:31:45 
UTC ---

(In reply to comment #7)

> Shouldn't the gcc.target/i386/pr54457.c testcase be...

> 

> Index: gcc/testsuite/gcc.target/i386/pr54457.c

> ===

> --- gcc/testsuite/gcc.target/i386/pr54457.c (revision 193061)

> +++ gcc/testsuite/gcc.target/i386/pr54457.c (working copy)

> @@ -1,4 +1,4 @@

> -/* { dg-do compile { target { ! { ia32 } } } } */

> +/* { dg-do compile { target { ! { ia32 || lp64 } } } } */

>  /* { dg-options "-O2 -mx32 -maddress-mode=short" } */

> 

>  extern char array[40];

> 

> On x86_64-apple-darwin12 at -m64, the gcc.target/i386/pr54457.c testcase fails

> the excessive errors test whereas the change above converts that to an

> unsupported test.



It will disable test on Linux/x86-64.  We can add

check_effective_target_maybe_x32 to check if -mx32

works before compiling with -mx32.

[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[hjl.tools at gmail dot com]

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



--- Comment #15 from H.J. Lu  2012-11-01 22:30:16 
UTC ---

All binaries die before main:



Starting program:

/export/build/gnu/glibc-x32-long/build-x86_64-linux/libio/bug-fclose1 



Program received signal SIGSEGV, Segmentation fault.

0xf7dddc8d in elf_get_dynamic_info (temp=0x0, l=0xf7ffdc18)

at get-dynamic-info.h:61

61 + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;

(gdb) disass $pc -19, +30

Dump of assembler code from 0xf7dddc7a to 0xf7dddc98:

   0xf7dddc7a :mov%r8d,%esi

   0xf7dddc7d :sub%eax,%esi

   0xf7dddc7f :cmp$0xa,%esi

   0xf7dddc82 :ja 0xf7ddd431 

   0xf7dddc88 :neg%eax

   0xf7dddc8a :lea(%rcx,%rax,4),%eax

=> 0xf7dddc8d :mov%edx,-0x4300(%rax)

   0xf7dddc93 :jmpq   0xf7ddd431 

End of assembler dump.

(gdb) p/x $rcx

$1 = 0xf7ffdc38

(gdb) p/x $rax

$2 = 0x37ffe064

(gdb) list

56  else if ((d_tag_utype) DT_VALTAGIDX (dyn->d_tag) < DT_VALNUM)

57info[DT_VALTAGIDX (dyn->d_tag) + DT_NUM + DT_THISPROCNUM

58 + DT_VERSIONTAGNUM + DT_EXTRANUM] = dyn;

59  else if ((d_tag_utype) DT_ADDRTAGIDX (dyn->d_tag) < DT_ADDRNUM)

60info[DT_ADDRTAGIDX (dyn->d_tag) + DT_NUM + DT_THISPROCNUM

61 + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;

62  ++dyn;

63}

64

65#define DL_RO_DYN_TEMP_CNT8

(gdb) p info

$3 = (Elf32_Dyn **) 0xf7ffdc38

(gdb) bt

#0  0xf7dddc8d in elf_get_dynamic_info (temp=0x0, l=0xf7ffdc18)

at get-dynamic-info.h:61

#1  dl_main (phdr=, phnum=9, user_entry=, 

auxv=) at rtld.c:1311

#2  0xf7df12c0 in _dl_sysdep_start (

start_argptr=start_argptr@entry=0xd100, dl_main=)

at ../elf/dl-sysdep.c:241

#3  0xf7ddfaa8 in _dl_start_final (arg=0xd100) at rtld.c:331

#4  _dl_start (arg=) at rtld.c:557

#5  0xf7ddc057 in _start ()

   from /export/build/gnu/glibc-x32-long/build-x86_64-linux/elf/ld.so

#6  0x0001 in ?? ()

#7  0x in ?? ()

(gdb)

[Bug target/55145] [4.8 Regression] [x32] -maddress-mode=long miscompiles glibc

[hjl.tools at gmail dot com]

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



H.J. Lu  changed:



   What|Removed |Added



 Status|WAITING |NEW



--- Comment #2 from H.J. Lu  2012-11-01 22:29:22 
UTC ---

I don't know if there are other bugs in addition to PR 55142.

I will leave it open until I can compile glibc to verify.

[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[hjl.tools at gmail dot com]

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



H.J. Lu  changed:



   What|Removed |Added



 Status|ASSIGNED|NEW

  Component|target  |middle-end



--- Comment #14 from H.J. Lu  2012-11-01 22:24:20 
UTC ---

(In reply to comment #13)

> Created attachment 28591 [details]

> Tentative fix

> 

> This generates (essentially) the same RTL as in non-PIC mode, so the generated

> code should be correct if it is correct in non-PIC mode.

> 

> Tested only in LP64 mode though.



The patch compiles testcase, but totally miscompiles glibc.

I think the bug is in unsigned array index computation as

shown in Comment 7. dyn->d_tag is signed type and Pmode

!= ptr_mode here.

[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument

[mwoehlke.floss at gmail dot com]

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



--- Comment #16 from mwoehlke.floss at gmail dot com 2012-11-01 22:03:46 UTC ---

On 2012-11-01 16:52, paolo.carlini at oracle dot com wrote:

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

> --- Comment #15 from Paolo Carlini  
> 2012-11-01 20:52:15 UTC ---

>

> This is what I meant when I said that the issue is different, and is much more

>

> general than -Wzero-as-null-pointer-constant. Consider, eg, with -Woverflow:

>

> #pragma GCC system_header

>

> class Foo

> {

>   public:

>Foo(signed char);

> };

>

> class Bar

> {

>   public:

>Bar(Foo = 1);

> };



Would you prefer I open a new bug report?

[Bug target/29963] could speed up variable access with different object layout

[amylaar at gcc dot gnu.org]

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



--- Comment #2 from Jorn Wolfgang Rennecke  
2012-11-01 21:42:12 UTC ---

(In reply to comment #1)

> I'm not sure how the proposed optimization could be done in a generic way.  It

> would not work for code (i.e. text section) that resides in read-only memory,

> such as ROM or MMU read-only pages.



In that case, you could indeed only do this optimization for constant

variables / arrays.



But it is not uncommon to load the program into RAM before executing,

e.g. because the ROM it's stored in is too slow.  In this case, placing

the program code in a writable segment is merely a matter of policy;

the user would be expected have control if this optimization is enabled,

taking into account if there are any overriding security concerns.

[Bug target/55160] [4.8 Regression] Counterproductive loop induction variable optimization

[olegendo at gcc dot gnu.org]

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



--- Comment #3 from Oleg Endo  2012-11-01 21:28:53 
UTC ---

Author: olegendo

Date: Thu Nov  1 21:28:49 2012

New Revision: 193071



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

Log:

PR target/55160

* gcc.target/sh/pr55160.c: New.





Added:

trunk/gcc/testsuite/gcc.target/sh/pr55160.c

Modified:

trunk/gcc/testsuite/ChangeLog

[Bug target/29963] could speed up variable access with different object layout

[olegendo at gcc dot gnu.org]

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



Oleg Endo  changed:



   What|Removed |Added



 CC||olegendo at gcc dot gnu.org



--- Comment #1 from Oleg Endo  2012-11-01 21:26:56 
UTC ---

I'm not sure how the proposed optimization could be done in a generic way.  It

would not work for code (i.e. text section) that resides in read-only memory,

such as ROM or MMU read-only pages.

[Bug target/54938] sh libgcc_unpack_df.o fails to build: ../../../srcw/libgcc/fp-bit.h:221:19: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:4273

[olegendo at gcc dot gnu.org]

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



--- Comment #7 from Oleg Endo  2012-11-01 21:19:53 
UTC ---

I guess this is done, isn't it Easwaran?

[Bug c++/55171] New: incorrect virtual thunk on mingw

[mitza at ociweb dot com]

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



 Bug #: 55171

   Summary: incorrect virtual thunk on mingw

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: mi...@ociweb.com





Created attachment 28593

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

test for virtual call on mingw



When a virtual call invoked on an object which uses both virtual and

non-virtual inheritance, the virtual thunk leaves the target function with an

invalid "this" pointer.



Attached test fails with output:



created Derived object at: 0x2c1a50

Derived virtual call at: 0x409800

Assertion failed!



>From gdb:

In the body of the most-derived constructor

(gdb) inf vt this

vtable for 'Derived' @ 0x4097ec (subobject @ 0x2c1a50):

[0]: 0x40188a 

[1]: 0x40190a 

[2]: 0x401932 



vtable for 'VirtBase' @ 0x409808 (subobject @ 0x2c1a58):

[0]: 0x401902 

[1]: 0x40192a 

[2]: 0x4019d1 



0x004019d1 in virtual thunk to Derived::foo() const () at gccbug.cpp:45

Dump of assembler code for function _ZTv0_n16_NK7Derived3fooEv:

=> 0x004019d1 <+0>: mov0x4(%esp),%eax

   0x004019d5 <+4>: mov(%eax),%eax

   0x004019d7 <+6>: add-0x10(%eax),%eax

   0x004019da <+9>: mov%eax,0x4(%esp)

   0x004019de <+13>:jmp0x401932 



After thunk has jumped to target function

Derived::foo (this=0x409800) at gccbug.cpp:41

41  {

(gdb) inf vt this

Cannot access memory at address 0xffec

[Bug libstdc++/55047] operator() in std::exponential_distribution may call log(0)

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #5 from Paolo Carlini  2012-11-01 
21:11:02 UTC ---

Fixed mainline and 4.7.3.

[Bug libstdc++/55047] operator() in std::exponential_distribution may call log(0)

[paolo at gcc dot gnu.org]

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



--- Comment #4 from paolo at gcc dot gnu.org  
2012-11-01 21:09:57 UTC ---

Author: paolo

Date: Thu Nov  1 21:09:51 2012

New Revision: 193070



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

Log:

2012-11-01   Haakan Younes  

 Paolo Carlini  



PR libstdc++/55047

* include/bits/random.h (exponential_distribution<>::operator):

Fix formula to std::log(result_type(1) - __aurng()).

* include/bits/random.tcc: Likewise, everywhere.



Modified:

branches/gcc-4_7-branch/libstdc++-v3/ChangeLog

branches/gcc-4_7-branch/libstdc++-v3/include/bits/random.h

branches/gcc-4_7-branch/libstdc++-v3/include/bits/random.tcc

[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument

[paolo.carlini at oracle dot com]

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



--- Comment #15 from Paolo Carlini  2012-11-01 
20:52:15 UTC ---

This is what I meant when I said that the issue is different, and is much more

general than -Wzero-as-null-pointer-constant. Consider, eg, with -Woverflow:



#pragma GCC system_header



class Foo

{

 public:

  Foo(signed char);

};



class Bar

{

 public:

  Bar(Foo = 1);

};

[Bug regression/55168] [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0

[hubicka at ucw dot cz]

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



--- Comment #2 from Jan Hubicka  2012-11-01 20:49:18 UTC 
---

This actually looks like a previously latent issue in predict.c For all but

estimate_num_iterations_int.  It uses the funny definition of number of

iterations (i.e. 0 means that loop will exit at first invocation of the exit

condition and that is what it will be predicted with when nitercst == 1.



Index: predict.c

===

--- predict.c   (revision 193062)

+++ predict.c   (working copy)

@@ -1433,8 +1437,8 @@ predict_loops (void)

 the loop, use it to predict this exit.  */

  else if (n_exits == 1)

{

- nitercst = estimated_stmt_executions_int (loop);

- if (nitercst < 0)

+ nitercst = estimated_stmt_executions_int (loop) + 1;

+ if (nitercst <= 0)

continue;

  if (nitercst > max)

nitercst = max;

Re: [Bug regression/55168] New: [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0

[Jan Hubicka]

This actually looks like a previously latent issue in predict.c For all but
estimate_num_iterations_int.  It uses the funny definition of number of
iterations (i.e. 0 means that loop will exit at first invocation of the exit
condition and that is what it will be predicted with when nitercst == 1.

Index: predict.c
===
--- predict.c   (revision 193062)
+++ predict.c   (working copy)
@@ -1433,8 +1437,8 @@ predict_loops (void)
 the loop, use it to predict this exit.  */
  else if (n_exits == 1)
{
- nitercst = estimated_stmt_executions_int (loop);
- if (nitercst < 0)
+ nitercst = estimated_stmt_executions_int (loop) + 1;
+ if (nitercst <= 0)
continue;
  if (nitercst > max)
nitercst = max;

[Bug c++/55170] incorrect mangling, should not include prefix

[rafael.espindola at gmail dot com]

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



--- Comment #1 from Rafael Avila de Espindola  2012-11-01 20:29:02 UTC ---

The relevant thread seems to be



http://sourcerytools.com/pipermail/cxx-abi-dev/2011-April/002404.html

[Bug regression/55168] [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0

[hp at gcc dot gnu.org]

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



Hans-Peter Nilsson  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #1 from Hans-Peter Nilsson  2012-11-01 
20:26:05 UTC ---

Found the patch, added co-author to CC.

[Bug c++/55170] New: incorrect mangling, should not include prefix

[rafael.espindola at gmail dot com]

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



 Bug #: 55170

   Summary: incorrect mangling, should not include prefix

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: rafael.espind...@gmail.com





Given the testcase



namespace mozilla {

  template

  struct IsConvertible {

static const bool value =true;

  };



  template

  struct EnableIf {

typedef int Type;

  };



  template 

  void Handle(S x, typename EnableIf::value>::Type dummy) {

  }



  template void

  Handle(int x, EnableIf::value>::Type dummy);

}



With current gcc trunk (193066) we get

$ gcc -fabi-version=0 -c test.cpp -w

$ nm test.o

 W

_ZN7mozilla6HandleIiEEvT_NS_8EnableIfIXsrNS_13IsConvertibleIS1_EE5valueEE4TypeE



And with clang



$ ./build/bin/clang -c test.cpp

$ nm test.o

 W

_ZN7mozilla6HandleIiEEvT_NS_8EnableIfIXsr13IsConvertibleIS1_EE5valueEE4TypeE



I initially thought the bug was in clang and reported llvm.org/pr14118, but

John McCall says that "On cxx-abi-dev, I believe we decided that

prefixes on unresolved-names should be mangled essentially as written".

[Bug regression/55167] [4.8 Regression]: g++.dg/other/vector-compare.C, ICE

[glisse at gcc dot gnu.org]

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



--- Comment #3 from Marc Glisse  2012-11-01 20:22:14 
UTC ---

(In reply to comment #2)

> It could be; that PR lacks a description of the effects, so my pre-report

> search did not find it.  (It only speaks of something missing in the code,

> could be just a missing optimization at a glance.)



Yes, sorry, "dup" probably wasn't the right term, I meant it as: "I think I

know what's going on".



Thanks again for filing the bug and CCing me.

[Bug libstdc++/55169] std::discrete_distribution::operator(generator&) makes unnecessary copy of parameter vector

[paolo.carlini at oracle dot com]

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



--- Comment #3 from Paolo Carlini  2012-11-01 
19:59:48 UTC ---

Of course, of course. But in 4_7-branch we are going to change only the three

distributions using std::vectors

[Bug middle-end/55103] [4.8 Regression] All MIPS16 attribute tests ICEs

[sje at gcc dot gnu.org]

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



Steve Ellcey  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-01

 CC||sje at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #3 from Steve Ellcey  2012-11-01 19:53:01 
UTC ---

I am seeing this failure as well when building newlib with the -mips16 option.



Here is a cut down test case (1 line) that gives me the same segfault as

Andrew is seeing.





argz_add(char **argz , long unsigned int *argz_len , const char *str)

[Bug regression/55167] [4.8 Regression]: g++.dg/other/vector-compare.C, ICE

[hp at gcc dot gnu.org]

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



--- Comment #2 from Hans-Peter Nilsson  2012-11-01 
19:52:02 UTC ---

(In reply to comment #1)

> Since the error happens in expand, I assume this is a dup of PR 55001, for

> which I posted a patch earlier today.



It could be; that PR lacks a description of the effects, so my pre-report

search did not find it.  (It only speaks of something missing in the code,

could be just a missing optimization at a glance.)



I'll leave dealing with it to you.

[Bug libstdc++/55169] std::discrete_distribution::operator(generator&) makes unnecessary copy of parameter vector

[chri.snell at gmail dot com]

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



--- Comment #2 from Chris Nell  2012-11-01 
19:48:43 UTC ---

After a bit more poking, it appears that param() returns a copy (not a const

reference) for all distributions, not just discrete_distribution.  As such, it

might we worth looking into whether other implementations of

operator(generator&) suffer from the same bug.

[Bug libstdc++/55169] std::discrete_distribution::operator(generator&) makes unnecessary copy of parameter vector

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-11-01

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

   |gnu.org |com

 Ever Confirmed|0   |1



--- Comment #1 from Paolo Carlini  2012-11-01 
19:38:51 UTC ---

Yes, seems easy to fix.

[Bug libstdc++/55169] New: std::discrete_distribution::operator(generator&) makes unnecessary copy of parameter vector

[chri.snell at gmail dot com]

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



 Bug #: 55169

   Summary: std::discrete_distribution::operator(generator&) makes

unnecessary copy of parameter vector

Classification: Unclassified

   Product: gcc

   Version: 4.7.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libstdc++

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

ReportedBy: chri.sn...@gmail.com





Created attachment 28592

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

demonstration of slow std::discrete_distribution in GCC



std::discrete_distribution::operator()(generator&) is significantly slower than

directly calling operator()(generator&, const param_type&), which it delegates

to.  This is because, on random.h:4805, this->param() returns a copy rather

than a const reference.



The attached file is a simple test demonstrating this inefficient behaviour.

[Bug regression/55168] New: [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0

[hp at gcc dot gnu.org]

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



 Bug #: 55168

   Summary: [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE,

all but -O0

Classification: Unclassified

   Product: gcc

   Version: 4.7.0

Status: UNCONFIRMED

  Keywords: ice-on-valid-code

  Severity: normal

  Priority: P3

 Component: regression

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

ReportedBy: h...@gcc.gnu.org

CC: ste...@gcc.gnu.org

  Host: x86_64-unknown-linux-gnu

Target: cris-axis-elf





This test previously passed, now it fails.

A patch in the revision range (last_known_working:first_known_failing)

193042:193049

exposed or caused this regression.  Since then it fails as follows:



Running

/tmp/hpautotest-gcc0/gcc/gcc/testsuite/gcc.c-torture/compile/compile.exp ...

FAIL: gcc.c-torture/compile/pr44119.c  -O1  (internal compiler error)

FAIL: gcc.c-torture/compile/pr44119.c  -O1  (test for excess errors)

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

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

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

compiler error)

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

excess errors)

FAIL: gcc.c-torture/compile/pr44119.c  -O3 -fomit-frame-pointer -funroll-loops 

(internal compiler error)

FAIL: gcc.c-torture/compile/pr44119.c  -O3 -fomit-frame-pointer -funroll-loops 

(test for excess errors)

FAIL: gcc.c-torture/compile/pr44119.c  -O3 -fomit-frame-pointer

-funroll-all-loops -finline-functions  (internal compiler error)

FAIL: gcc.c-torture/compile/pr44119.c  -O3 -fomit-frame-pointer

-funroll-all-loops -finline-functions  (test for excess errors)

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

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

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

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

FAIL: gcc.c-torture/compile/pr44119.c  -O2 -flto -fno-use-linker-plugin

-flto-partition=none  (internal compiler error)

FAIL: gcc.c-torture/compile/pr44119.c  -O2 -flto -fno-use-linker-plugin

-flto-partition=none  (test for excess errors)

FAIL: gcc.c-torture/compile/pr44119.c  -O2 -flto -fuse-linker-plugin

-fno-fat-lto-objects  (internal compiler error)

FAIL: gcc.c-torture/compile/pr44119.c  -O2 -flto -fuse-linker-plugin

-fno-fat-lto-objects  (test for excess errors)



The messages in gcc.log are similar:



Executing on host: /tmp/hpautotest-gcc0/cris-elf/gccobj/gcc/xgcc

-B/tmp/hpautotest-gcc0/cris-elf/gccobj/gcc/  -fno-diagnostics-show-caret   -O1 

-w -c   -isystem

/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem

/tmp/hpautotest-gcc0/gcc/newlib/libc/include  -o pr44119.o

/tmp/hpautotest-gcc0/gcc/gcc/testsuite/gcc.c-torture/compile/pr44119.c   

(timeout = 300)

/tmp/hpautotest-gcc0/gcc/gcc/testsuite/gcc.c-torture/compile/pr44119.c: In

function 'func_96':



/tmp/hpautotest-gcc0/gcc/gcc/testsuite/gcc.c-torture/compile/pr44119.c:45:1:

internal compiler error: Floating point exception



0x84ab35 crash_signal



/tmp/hpautotest-gcc0/gcc/gcc/toplev.c:333



0x7d4bbf predict_loops



/tmp/hpautotest-gcc0/gcc/gcc/predict.c:1524



0x7d67b4 tree_estimate_probability()



/tmp/hpautotest-gcc0/gcc/gcc/predict.c:2259



0x7d75d4 tree_estimate_probability_driver



/tmp/hpautotest-gcc0/gcc/gcc/predict.c:2296





Author of only suspect patch in revision range CC:ed.

[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument

[paolo.carlini at oracle dot com]

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



--- Comment #14 from Paolo Carlini  2012-11-01 
19:07:10 UTC ---

Ok, I can reproduce this. Note, I don't think it's the same issue reported here

earlier. Apparently something is going wrong with the pragma. A WA is writing:



  Bar(Foo = Foo(0));



in this case the warning is correctly suppressed. The 0 in the Foo constructor

doesn't matter, the warning is correctly suppressed and you can as well remove

it from the testcase. I'm looking into this, hopefully can be fixed without

reworking too many diagnostic things outside this specific warning proper.

[Bug regression/55167] [4.8 Regression]: g++.dg/other/vector-compare.C, ICE

[glisse at gcc dot gnu.org]

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



--- Comment #1 from Marc Glisse  2012-11-01 19:05:13 
UTC ---

Thanks.



Since the error happens in expand, I assume this is a dup of PR 55001, for

which I posted a patch earlier today. Note that AFAIK, anything that starts

failing because of this patch was silently miscompiled before.



(I am also investigating a different problem with this testcase, due to the

fact that the C front-end turns (void)(x<0) into if(x<0)(void)0 which vector x

doesn't like)

[Bug middle-end/55150] Crash in copy_rtx

[vmakarov at gcc dot gnu.org]

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



--- Comment #5 from Vladimir Makarov  2012-11-01 
19:02:48 UTC ---

Author: vmakarov

Date: Thu Nov  1 19:02:40 2012

New Revision: 193065



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

Log:

2012-11-01  Vladimir Makarov  



PR middle-end/55150

* lra-constraints.c (lra_constraints): Check only pseudos with

equivalences.  Add insns with equivalence pseudos.



2012-11-01  Vladimir Makarov  



PR middle-end/55150

* gcc.dg/pr55150.c: Rename to gcc.dg/pr55150-1.c.

* gcc.dg/pr55150-2.c: New test.







Added:

trunk/gcc/testsuite/gcc.dg/pr55150-1.c

trunk/gcc/testsuite/gcc.dg/pr55150-2.c

Removed:

trunk/gcc/testsuite/gcc.dg/pr55150.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/lra-constraints.c

trunk/gcc/testsuite/ChangeLog

[Bug regression/55167] New: [4.8 Regression]: g++.dg/other/vector-compare.C, ICE

[hp at gcc dot gnu.org]

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



 Bug #: 55167

   Summary: [4.8 Regression]: g++.dg/other/vector-compare.C, ICE

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: ice-on-valid-code

  Severity: normal

  Priority: P3

 Component: regression

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

ReportedBy: h...@gcc.gnu.org

CC: gli...@gcc.gnu.org

  Host: x86_64-unknown-linux-gnu

Target: cris-axis-elf





This test previously passed, now it fails.

A patch in the revision range (last_known_working:first_known_failing)

192985:192991

exposed or caused this regression.  Since then it fails as follows:



Running /tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/dg.exp ...

FAIL: g++.dg/other/vector-compare.C (internal compiler error)

FAIL: g++.dg/other/vector-compare.C (test for excess errors)



In g++.log:



Executing on host:

/tmp/hpautotest-gcc0/cris-elf/gccobj/gcc/testsuite/g++/../../g++

-B/tmp/hpautotest-gcc0/cris-elf/gccobj/gcc/testsuite/g++/../../

/tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/other/vector-compare.C 

-fno-diagnostics-show-caret  -nostdinc++

-I/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include/cris-elf

-I/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include

-I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/libsupc++

-I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/include/backward

-I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 

-std=gnu++11 -Wall  -S   -isystem

/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem

/tmp/hpautotest-gcc0/gcc/newlib/libc/include  -o vector-compare.s(timeout =

300)

/tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/other/vector-compare.C: In

function 'int main()':



/tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/other/vector-compare.C:30:21:

internal compiler error: Segmentation fault



0x9fc565 crash_signal



/tmp/hpautotest-gcc0/gcc/gcc/toplev.c:333



0x802f65 force_operand(rtx_def*, rtx_def*)



/tmp/hpautotest-gcc0/gcc/gcc/expr.c:6975



0x743ac0 expand_gimple_stmt_1



/tmp/hpautotest-gcc0/gcc/gcc/cfgexpand.c:2168



0x743ac0 expand_gimple_stmt



/tmp/hpautotest-gcc0/gcc/gcc/cfgexpand.c:2204



0x744b39 expand_gimple_basic_block



/tmp/hpautotest-gcc0/gcc/gcc/cfgexpand.c:3979



0x746276 gimple_expand_cfg



/tmp/hpautotest-gcc0/gcc/gcc/cfgexpand.c:4498





According to , this

also happens for i686-linux and revision r192986 is to blame.



Author of suspect patch CC:ed.

[Bug c++/55166] c++11: std::string and =std:move makes swapping

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #1 from Jonathan Wakely  2012-11-01 
18:40:49 UTC ---

The standard says that after the move t1 will be in a valid but unspecified

state.



It does not say it will be empty.



There are performance advantages to the current behaviour because if you do

this:



std::string t0{"abc"};

std::string t1{"123"};

t0 = std::move(t1);

t1 = "xyz";



there is no allocation for the last line, because it already has memory



You keep reporting invalid bugs which are actually correct C++11 behaviour.

Please find somewhere else to learn C++, such as stackoverflow.com

[Bug c++/55166] New: c++11: std::string and =std:move makes swapping

[lisp2d at lisp2d dot net]

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



 Bug #: 55166

   Summary: c++11: std::string and =std:move  makes swapping

Classification: Unclassified

   Product: gcc

   Version: 4.7.1

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: lis...@lisp2d.net





While moving std::string value to another place g++ makes something different.



std::string t0{"abc"};

std::string t1{"123"};



t0 = std::move(t1); or t0  = static_cast(t1);



is the same result as 



std::swap(t0,t1);

[Bug other/55164] [4.8 Regression] -fdump-*-all not working

[singhai at gcc dot gnu.org]

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



Sharad Singhai  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #3 from Sharad Singhai  2012-11-01 
18:05:53 UTC ---

This should be fixed now at r193064.

[Bug middle-end/54957] Two crashes introduced by rev192488

[rbmj at verizon dot net]

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



--- Comment #21 from rbmj at verizon dot net 2012-11-01 18:05:36 UTC ---

That fixes it for me :)

[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument

[mw_triad at users dot sourceforge.net]

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

--- Comment #13 from Matthew Woehlke  
2012-11-01 17:56:49 UTC ---
...and with your example I do indeed get no warning.

Simplified test case:

$ cat zero-as-pointer.h
#pragma GCC system_header

class Foo
{
public:
  Foo(void** = 0);
};

class Bar
{
public:
  Bar(Foo = 0);
};
$ cat zero-as-pointer.cpp 
#include "zero-as-pointer.h"

int main()
{
  Bar bar;
  return 0;
}
$ g++ -std=c++11 -Werror=zero-as-null-pointer-constant zero-as-pointer.cpp 
zero-as-pointer.cpp: In function ‘int main()’:
zero-as-pointer.cpp:5:7: error: zero as null pointer constant
[-Werror=zero-as-null-pointer-constant]
cc1plus: some warnings being treated as errors

Apparently it is something about the 'Foo = 0' part (replace Foo with
Qt::WindowFlags in my 'real' example).

[Bug other/55164] [4.8 Regression] -fdump-*-all not working

[singhai at gcc dot gnu.org]

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



--- Comment #2 from Sharad Singhai  2012-11-01 
17:55:46 UTC ---

Author: singhai

Date: Thu Nov  1 17:55:23 2012

New Revision: 193064



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

Log:

2012-11-01  Sharad Singhai  



PR other/55164

* dumpfile.h (struct dump_file_info): Fix order of flags.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/dumpfile.h

[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument

[mw_triad at users dot sourceforge.net]

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

--- Comment #12 from Matthew Woehlke  
2012-11-01 17:47:04 UTC ---
Requires qt-devel installed, but has the benefit of being the exact issue I'm
having in production (on the chance it's something screwy about Qt...):


$ cat zero-as-pointer.cpp 
#include 

int main()
{
  QLabel label;
  return 0;
}
$ g++ -std=c++11 -Werror=zero-as-null-pointer-constant zero-as-pointer.cpp 
zero-as-pointer.cpp: In function ‘int main()’:
zero-as-pointer.cpp:5:10: error: zero as null pointer constant
[-Werror=zero-as-null-pointer-constant]
cc1plus: some warnings being treated as errors
Exit 1
$ g++ --version
g++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

...maybe it got fixed in 4.7.3?


Note: the problem is this ctor:

explicit QLabel(QWidget *parent=0, Qt::WindowFlags f=0);

If I replace my declaration with:

QLabel label(nullptr, Qt::WindowFlags(nullptr));

...then I get no warning.

[Bug other/55164] [4.8 Regression] -fdump-*-all not working

[singhai at google dot com]

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



--- Comment #1 from singhai at google dot com 2012-11-01 16:26:21 UTC ---

Found the culprit. A flag was accidentally committed in wrong order.

The following patch fixes it. I am testing it.



Thanks,

Sharad



2012-11-01  Sharad Singhai  



PR other/55164

* dumpfile.h (struct dump_file_info): Fix order of flags.



Index: dumpfile.h

===

--- dumpfile.h (revision 193061)

+++ dumpfile.h (working copy)

@@ -113,8 +113,8 @@ struct dump_file_info

   const char *alt_filename; /* filename for the -fopt-info stream  */

   FILE *pstream;/* pass-specific dump stream  */

   FILE *alt_stream; /* -fopt-info stream */

+  int pflags;   /* dump flags */

   int optgroup_flags;   /* optgroup flags for -fopt-info */

-  int pflags;   /* dump flags */

   int alt_flags;/* flags for opt-info */

   int pstate;   /* state of pass-specific stream */

   int alt_state;/* state of the -fopt-info stream */

[Bug c++/55159] pythy constexpr auto lambda pointer has no initializer

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  
2012-11-01 15:11:51 UTC ---
(In reply to comment #2)
Hmmh, it doesn't look like that one, maybe I was wrong about an existing issue.

But it seems that gcc doesn't ignore the const (in "const T*" or "const auto*")
for functions here, which seems to be the root of the second problem (This is
*not* attempting to form a function with cv-qualifier-seq). Both

template 
T* addr(T& t) { return &t; }

bool less(int x, int y) { return x < y ? x : y; }

static auto* f = addr(less);

and

template 
T* addr(T& t) { return &t; }

bool less(int x, int y) { return x < y ? x : y; }

template
int deduce(T*) { return 0; }

int i = deduce(addr(less));

are accepted as they should.

[Bug other/55165] Build failure for x86_64-w64-mingw32

[mikpe at it dot uu.se]

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



--- Comment #1 from Mikael Pettersson  2012-11-01 
14:38:50 UTC ---

Change the first two (long) casts to (uintptr_t) and the third one to

(intptr_t).

[Bug other/55165] New: Build failure for x86_64-w64-mingw32

[vanboxem.ruben at gmail dot com]

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



 Bug #: 55165

   Summary: Build failure for x86_64-w64-mingw32

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: other

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

ReportedBy: vanboxem.ru...@gmail.com





Building GCC master on 1 November 2012 for build=x86_64-gnu-linux

host=x86_64-w64-mingw32 results in this error during the make all-target-libgcc

step:



/home/ruben/mingw-w64/src/gcc/gcc/stmt.c: In function 'void

compute_cases_per_edge(gimple)':

/home/ruben/mingw-w64/src/gcc/gcc/stmt.c:2064:54: error: cast from 'void*' to

'long int' loses precision [-fpermissive]

   case_edge->aux = (void *)((long)(case_edge->aux) + 1);

  ^

/home/ruben/mingw-w64/src/gcc/gcc/stmt.c:2064:59: warning: cast to pointer from

integer of different size [-Wint-to-pointer-cast]

   case_edge->aux = (void *)((long)(case_edge->aux) + 1);

   ^

/home/ruben/mingw-w64/src/gcc/gcc/stmt.c: In function 'void

expand_case(gimple)':

/home/ruben/mingw-w64/src/gcc/gcc/stmt.c:2179:57: error: cast from 'void*' to

'long int' loses precision [-fpermissive]

   case_edge->probability / (long)(case_edge->aux),

 ^



This is due to the fact that a pointer is not an int.

[Bug c++/55159] pythy constexpr auto lambda pointer has no initializer

[paolo.carlini at oracle dot com]

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



--- Comment #2 from Paolo Carlini  2012-11-01 
14:25:26 UTC ---

Daniel, you mean PR54111 maybe?

[Bug target/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[ebotcazou at gcc dot gnu.org]

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



--- Comment #13 from Eric Botcazou  2012-11-01 
14:20:17 UTC ---

Created attachment 28591

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

Tentative fix



This generates (essentially) the same RTL as in non-PIC mode, so the generated

code should be correct if it is correct in non-PIC mode.



Tested only in LP64 mode though.

[Bug rtl-optimization/54457] [x32] Fail to combine 64bit index + constant

[howarth at nitro dot med.uc.edu]

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



Jack Howarth  changed:



   What|Removed |Added



 CC||howarth at nitro dot

   ||med.uc.edu



--- Comment #7 from Jack Howarth  2012-11-01 
13:49:44 UTC ---

Shouldn't the gcc.target/i386/pr54457.c testcase be...



Index: gcc/testsuite/gcc.target/i386/pr54457.c

===

--- gcc/testsuite/gcc.target/i386/pr54457.c (revision 193061)

+++ gcc/testsuite/gcc.target/i386/pr54457.c (working copy)

@@ -1,4 +1,4 @@

-/* { dg-do compile { target { ! { ia32 } } } } */

+/* { dg-do compile { target { ! { ia32 || lp64 } } } } */

 /* { dg-options "-O2 -mx32 -maddress-mode=short" } */



 extern char array[40];



On x86_64-apple-darwin12 at -m64, the gcc.target/i386/pr54457.c testcase fails

the excessive errors test whereas the change above converts that to an

unsupported test.

[Bug target/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



  Component|middle-end  |target



--- Comment #12 from Eric Botcazou  2012-11-01 
12:51:26 UTC ---

Recategorizing.

[Bug tree-optimization/55104] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:269

[hubicka at gcc dot gnu.org]

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



--- Comment #5 from Jan Hubicka  2012-11-01 
12:44:22 UTC ---

Author: hubicka

Date: Thu Nov  1 12:44:13 2012

New Revision: 193062



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

Log:



PR middle-end/55104

* ipa-inline-transform.c (inline_call): Silence an sanity check until

ipa-cp issue if fixed.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/ipa-inline-transform.c

[Bug middle-end/55078] [4.8 Regression] FAIL: g++.dg/torture/pr46154.C

[hubicka at gcc dot gnu.org]

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



Jan Hubicka  changed:



   What|Removed |Added



 Blocks|55104   |



--- Comment #6 from Jan Hubicka  2012-11-01 
12:43:14 UTC ---

I silenced the ICE until the real issue is fixed.

[Bug tree-optimization/55104] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:269

[hubicka at gcc dot gnu.org]

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



Jan Hubicka  changed:



   What|Removed |Added



 Depends on||55078



--- Comment #4 from Jan Hubicka  2012-11-01 
12:40:22 UTC ---

Most probably dup of PR55078. I am going to silence the ICE until that one is

fixed, lets not forget to double check that after fixing PR55078 this testcase

gets fixed, too.

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[paolo.carlini at oracle dot com]

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



--- Comment #11 from Paolo Carlini  2012-11-01 
11:53:26 UTC ---

I see, thanks Daniel for the additional analysis. Indeed, I can confirm that

with the operator+ return type fixed, ICC doesn't throw either. Now I guess

it's my job to figure out the minimal change getting us the desired behavior...

[Bug middle-end/55150] Crash in copy_rtx

[rmansfield at qnx dot com]

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



--- Comment #4 from Ryan Mansfield  2012-11-01 
11:47:54 UTC ---

Created attachment 28590

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

second preprocessed src testcase

[Bug middle-end/55150] Crash in copy_rtx

[rmansfield at qnx dot com]

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

--- Comment #3 from Ryan Mansfield  2012-11-01 
11:46:24 UTC ---
I found similar crash that happens with the fix in comment #2 applied. i.e.
using rev193061:

$ ./xgcc -B. -m32 -Os -fpic -g ~/ice.i 
/home/ryan/ice.i: In function ‘DES_ede3_cbcm_encrypt’:
/home/ryan/ice.i:49:2: internal compiler error: Segmentation fault
  }
  ^
0x8e599f crash_signal
../../gcc/toplev.c:333
0x88ff75 copy_rtx(rtx_def*)
../../gcc/rtl.c:246
0x800458 remove_pseudos
../../gcc/lra-spills.c:435
0x8004c3 remove_pseudos
../../gcc/lra-spills.c:443
0x8004c3 remove_pseudos
../../gcc/lra-spills.c:443
0x8004c3 remove_pseudos
../../gcc/lra-spills.c:443
0x8004c3 remove_pseudos
../../gcc/lra-spills.c:443
0x8004c3 remove_pseudos
../../gcc/lra-spills.c:443
0x8004c3 remove_pseudos
../../gcc/lra-spills.c:443
0x800aa3 spill_pseudos
../../gcc/lra-spills.c:481
0x800aa3 lra_spill()
../../gcc/lra-spills.c:568
0x7ec7b4 lra(_IO_FILE*)
../../gcc/lra.c:2327
0x7b4156 do_reload
../../gcc/ira.c:4624
0x7b4156 rest_of_handle_reload
../../gcc/ira.c:4737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug other/55164] [4.8 Regression] -fdump-*-all not working

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-11-01

 CC||jakub at gcc dot gnu.org

   Target Milestone|--- |4.8.0

Summary|-fdump-*-all not working|[4.8 Regression]

   ||-fdump-*-all not working

 Ever Confirmed|0   |1

[Bug other/55164] New: -fdump-*-all not working

[mpolacek at gcc dot gnu.org]

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



 Bug #: 55164

   Summary: -fdump-*-all not working

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: other

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

ReportedBy: mpola...@gcc.gnu.org





Since r193061, the -fdump-*-all option produces no dumps, while e.g.

-fdump-tree-vrp or -fdump-rtl-expand are fine.

[Bug bootstrap/55163] New: Ongoing problem with gengtype-lex.c under CygWin with CRLF text mode line endings since 4.8

[nico at josuttis dot de]

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



 Bug #: 55163

   Summary: Ongoing problem with gengtype-lex.c under CygWin with

CRLF text mode line endings since 4.8

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

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

ReportedBy: n...@josuttis.de





For all versions of 4.8.0 I tried to compile, I run into the same problem

when building a C++ compiler in my CygWin environment.



The error is as follows:



flex  -ogengtype-lex.c ../../src/gcc/gengtype-lex.l && { \

  echo '#include "bconfig.h"' > gengtype-lex.c.tmp; \

  cat gengtype-lex.c >> gengtype-lex.c.tmp; \

  mv gengtype-lex.c.tmp gengtype-lex.c; \

}

g++ -c   -g -O2 -DIN_GCC-fno-exceptions -fno-rtti

-fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual

-Wmissing-format-attribute -fno-common -Wno-error -DHAVE_CONFIG_H

-DGENERATOR_FILE -I. -Ibuild -I../../src/gcc -I../../src/gcc/build 

-I../../src/gcc/../include   -I../../src/gcc/../libcpp/include

-I/cygdrive/p/gcc/gcc-trunk-install/build/./gmp

-I/cygdrive/p/gcc/gcc-trunk-install/src/gmp

-I/cygdrive/p/gcc/gcc-trunk-install/build/./mpfr

-I/cygdrive/p/gcc/gcc-trunk-install/src/mpfr

-I/cygdrive/p/gcc/gcc-trunk-install/src/mpc/src 

-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/bid

-I../libdecnumber -I../../src/gcc/../libbacktrace \

-o build/gengtype-lex.o gengtype-lex.c

gengtype-lex.c:332: error: expected unqualified-id before "do"

gengtype-lex.c:332: error: expected `,' or `;' before "do"

gengtype-lex.c:352: error: expected unqualified-id before "while"

gengtype-lex.c:352: error: expected `,' or `;' before "while"

gengtype-lex.c:394: error: `yy_size_t' does not name a type

gengtype-lex.c:524: error: expected unqualified-id before '?' token

...



It seems that there is a CR/LF problem because I can fix it by

running

 /usr/bin/sed -e 's/^M$//' 

on the generated gengtype-lex.c and then continue with the build.



It looks like my CygWin settings let gengtype-lex.c get created with

some CR/LF combinations, which the compiler is then not able to handle.

This is probably caused by having DOS/text default file system type:

 $ mount -m

 none /cygdrive cygdrive text,posix=0,user 0 0



However, as I might not be the only one having text mode (with CRLF generated)

as default, we should better fix this problem.



Note that with gcc 4.7.x this problem does not exist, so this problem is new

with 4.8.

[Bug c++/55159] pythy constexpr auto lambda pointer has no initializer

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2012-11-01 10:58:06 UTC ---
I really think that Pythy should fix this implementation, because it is not
supported by the C++11 standard. Any compiler accepting that is defect.
According to 9.4.2 p3:

"A static data member of literal type can be declared in the class definition
with the constexpr specifier; if so, its declaration shall specify a
brace-or-equal-initializer in which every initializer-clause that is an
assignment-expression is a constant expression."

As of 5.19 p2 the appearance of a lambda-expression prevents an expression from
satisfying the requirements of a (core) constant expression.

But changing your example to

template 
T* addr(T& t) { return &t; }

bool less(int x, int y) { return x < y ? x : y; }

const static auto* f = addr(less);

indeed points to a defect of gcc, not being able to deduce auto here. I think
this is the same bug that I can remember (but cannot find at the very moment)
which shows a similar problem during overload resolution in templates when
involving function addresses such as in

template 
T* addr(T& t) { return &t; }

bool less(int x, int y) { return x < y ? x : y; }

template
int deduce(const T*) { return 0; }

int i = deduce(addr(less));

This example should be accepted, but gcc doesn't like it saying:

"error: no matching function for call to 'deduce(bool (*)(int, int))'|
note: candidate is:|
note: template int deduce(const T*)|
note:   template argument deduction/substitution failed:|
note:   types 'const T' and 'bool(int, int)' have incompatible cv-qualifiers"

[Bug middle-end/55132] [4.8 Regression] FAIL: g++.dg/tree-ssa/pr45453.C

[hubicka at gcc dot gnu.org]

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



Jan Hubicka  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #5 from Jan Hubicka  2012-11-01 
10:55:27 UTC ---

Fixed now.

[Bug rtl-optimization/55154] [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:2702 with custom flags

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0



--- Comment #3 from Uros Bizjak  2012-11-01 10:42:33 
UTC ---

Confirmed, a regression from 4.7.

[Bug rtl-optimization/55154] [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:2702 with custom flags

[ubizjak at gmail dot com]

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



--- Comment #2 from Uros Bizjak  2012-11-01 10:40:37 
UTC ---

(In reply to comment #1)

> Started with http://gcc.gnu.org/viewcvs?view=revision&revision=192719

> The interesting thing is that this happened before, definitely in r190614,

> afterwards was fixed in some commit, and 190777 was fine.



As the test name implies, it was PR46254. The problem there was that %rbx is

declared as fixed reg for "-fpic -mcmodel=large" case. Fixed regs are

unavailable to RA, so we have to handle it in a special way.



This PR shows a deficiency in how subregs are handled in LRA. The test lives

and dies by correct subreg handling in the RA.



For reference, pre-LRA allocator resolved allocation for problematic insn with:



Reloads for insn # 10

Reload 0: reload_in (DI) = (subreg:DI (reg:TI 60 [ i.1 ]) 0)

reload_out (DI) = (reg:DI 4 si)

AREG, RELOAD_OTHER (opnum = 0)

reload_in_reg: (subreg:DI (reg:TI 60 [ i.1 ]) 0)

reload_out_reg: (subreg:DI (reg:TI 4 si [65]) 0)

reload_reg_rtx: (reg:DI 0 ax)

Reload 1: reload_in (DI) = (subreg:DI (reg:TI 60 [ i.1 ]) 8)

reload_out (DI) = (reg:DI 5 di)

DREG, RELOAD_OTHER (opnum = 1)

reload_in_reg: (subreg:DI (reg:TI 60 [ i.1 ]) 8)

reload_out_reg: (subreg:DI (reg:TI 4 si [65]) 8)

reload_reg_rtx: (reg:DI 1 dx)

Reload 2: reload_in (DI) = (subreg:DI (reg:TI 60 [ i.1 ]) 0)

reload_out (DI) = (scratch:DI)

GENERAL_REGS, RELOAD_OTHER (opnum = 5)

reload_in_reg: (subreg:DI (reg:TI 60 [ i.1 ]) 0)

reload_out_reg: (scratch:DI)

reload_reg_rtx: (reg:DI 38 r9)

Reload 3: reload_in (DI) = (subreg:DI (reg:TI 60 [ i.1 ]) 8)

CREG, RELOAD_FOR_INPUT (opnum = 6)

reload_in_reg: (subreg:DI (reg:TI 60 [ i.1 ]) 8)

reload_reg_rtx: (reg:DI 2 cx)

[Bug bootstrap/54834] bootstrap fails when building libbacktrace

[nico at josuttis dot de]

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



Nicolai Josuttis  changed:



   What|Removed |Added



 CC||nico at josuttis dot de



--- Comment #7 from Nicolai Josuttis  2012-11-01 
10:14:30 UTC ---

I got the same problem when switching from revision 1191942 (Oct 1st, 2012) to

revision 193061 (Nov 1st, 2012).

The effect was that the following files existed in the build tree:

 -rw-r--r-- 1 nico None 10659 Sep 21 10:16 gcc/include/unwind.h

 lrwxrwxrwx 1 nico None36 Oct  2 00:04 i686-pc-cygwin/libgcc/unwind.h ->

../../../src/libgcc/unwind-generic.h



After removing 

 gcc/include/unwind.h

the problem disappeared.



As you can see, my environment was:

 CygWin under Windows 7 x64

 (i686-pc-cygwin)



Config settings were:

../src/configure \

 --enable-languages=c++ \

 --disable-bootstrap \

 --prefix=/cygdrive/p/gcc/gcc$VERSION \

 --program-suffix=$VERSION \

 --with-gxx-include-dir=/cygdrive/p/gcc/gcc$VERSION-include \

 --disable-lto \

 --disable-sjlj-exceptions \

  2>&1 | tee -a ../make.log

[Bug tree-optimization/55162] Loop ivopts cuts off top bits of loop counter

[olegendo at gcc dot gnu.org]

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



--- Comment #1 from Oleg Endo  2012-11-01 10:11:46 
UTC ---

(In reply to comment #0)

> The same could be done on SH, too (comparing against the end address instead 
> of

> using a loop counter), but it would add a loop setup overhead.  In the optimal

> case the above function would result in the following SH code:

> 

> tst r5,r5

> bt/s.L6

> mov #0,r0

> .L3:

> mov.l   @r4+,r1

> dt  r5

> bf/s.L3

> add r1,r0

> .L6:

> rts

> nop

> 



... which is the case if '*x++' is used instead of 'x[i]':



int test (int* x, unsigned int c)

{

  int s = 0;

  unsigned int i;

  for (i = 0; i < c; ++i)

s += *x++;

  return s;

}

[Bug target/55145] [4.8 Regression] [x32] -maddress-mode=long miscompiles glibc

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2012-11-01

 Ever Confirmed|0   |1



--- Comment #1 from Uros Bizjak  2012-11-01 10:08:50 
UTC ---

So is this PR a manifestation of presumably wrong fix for PR 55142 or an

independent bug?

[Bug tree-optimization/55162] New: Loop ivopts cuts off top bits of loop counter

[olegendo at gcc dot gnu.org]

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



 Bug #: 55162

   Summary: Loop ivopts cuts off top bits of loop counter

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: olege...@gcc.gnu.org

Target: sh*-*-*





The following function:



int test (int* x, unsigned int c)

{

  int s = 0;

  unsigned int i;

  for (i = 0; i < c; ++i)

s += x[i];

  return s;

}



compiled for SH (-O2 -m4 -ml) results in the following code:



tst r5,r5  // c == 0 ?

bt/s.L6

mov #0,r0

shll2   r5 // c <<= 2

add #-4,r5 // c += -4

shlr2   r5 // c >>= 2 (unsigned shift)

add #1,r5  // c += 1

.L3:

mov.l   @r4+,r1

dt  r5

bf/s.L3

add r1,r0

.L6:

rts

nop



If the function above is invoked with c = 0x8000 the loop will do

0x4000 number of iterations, which looks suspicious.



For example, passing a virtual address 0x1000 and c = 0x8000 to the

function should actually run over the address range 0x1000 .. 0x80001000,

not 0x1000 .. 0x40001000.



I've also checked this on ARM.  There, the loop counter is transformed into the

end address and the loop compares the addresses instead of using a

decrement-and-test insn:

cmp r1, #0

beq .L4

mov r3, r0

add r1, r0, r1, asl #2

mov r0, #0

.L3:

ldr r2, [r3], #4

cmp r3, r1

add r0, r0, r2

bne .L3

bx  lr

.L4:

mov r0, r1

bx  lr



The same could be done on SH, too (comparing against the end address instead of

using a loop counter), but it would add a loop setup overhead.  In the optimal

case the above function would result in the following SH code:



tst r5,r5

bt/s.L6

mov #0,r0

.L3:

mov.l   @r4+,r1

dt  r5

bf/s.L3

add r1,r0

.L6:

rts

nop





This problem is present on rev 193061 as well as on the 4.7 branch.

[Bug target/55147] [4.8 Regression] x86: wrong code for 64-bit load

[ubizjak at gmail dot com]

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



--- Comment #6 from Uros Bizjak  2012-11-01 09:48:50 
UTC ---

(In reply to comment #5)

> Created attachment 28589 [details]

> gcc48-pr55147.patch

> 

> So like this?  Or do you want to merge the bswap{si,di}2 expanders using SWI48

> iterator too?  That would make i386.md tiny bit shorter, but would make

> gen_bswapdi2 longer (as the compiler can't figure out that for DImode (thus

> TARGET_64BIT) TARGET_BSWAP is always true).  Perhaps I could do

>   else if (mode == DImode || TARGET_BSWAP)

> so that at least optimized gcc builds would optimize it away.



No, your proposed patch is OK and pre-approved for mainline SVN.

[Bug target/55147] [4.8 Regression] x86: wrong code for 64-bit load

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2012-11-01 
09:44:22 UTC ---

Created attachment 28589

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

gcc48-pr55147.patch



So like this?  Or do you want to merge the bswap{si,di}2 expanders using SWI48

iterator too?  That would make i386.md tiny bit shorter, but would make

gen_bswapdi2 longer (as the compiler can't figure out that for DImode (thus

TARGET_64BIT) TARGET_BSWAP is always true).  Perhaps I could do

  else if (mode == DImode || TARGET_BSWAP)

so that at least optimized gcc builds would optimize it away.

[Bug target/55147] [4.8 Regression] x86: wrong code for 64-bit load

[ubizjak at gmail dot com]

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



Uros Bizjak  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

Summary|x86: wrong code for 64-bit  |[4.8 Regression] x86: wrong

   |load|code for 64-bit load



--- Comment #4 from Uros Bizjak  2012-11-01 09:27:21 
UTC ---

(In reply to comment #3)



> it creates the same number of insns/same quality (just slightly different RA

> decisions/scheduling) for f1-f3, but for f4 without bswapdi2 it creates

> slightly worse code (with bswapdi2 f4 needs just one call saved register,

> without it two, supposedly because both bswap insns are scheduled together.



We can live with that.



I have also checked that removing the pattern doesn't degrade TARGET_MOVBE, the

reason for their existence is PR53227.



Also, a regression from 4.7.

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[daniel.kruegler at googlemail dot com]

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

--- Comment #10 from Daniel Krügler  
2012-11-01 09:10:56 UTC ---
(In reply to comment #9)
I don't think that the standard says (or intends to say) that an implementation
has to defer all evaluations here. For example, assume you provide

polymorphic& operator+(polymorphic a, polymorphic b);

with some definition this is still UB when the expression

*(T*)0 + *(T*)0

occurs as operand of typeid (Note the arguments are by value). An
implementation is only required to detect whether an (immediate) runtime
glvalue of a polymorphic class as argument of typeid refers to an "empty
glvalue". Anything beyond that would fall under 

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232

I think.

[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88

[ebotcazou at gcc dot gnu.org]

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot

   |gnu.org |gnu.org



--- Comment #11 from Eric Botcazou  2012-11-01 
08:44:27 UTC ---

Investigating.

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[paolo.carlini at oracle dot com]

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



--- Comment #9 from Paolo Carlini  2012-11-01 
08:39:48 UTC ---

Oops, sorry about the rvalue stupid mistake, you are right. Thus I understand

that this type of wording means that assuming it's a glvalue, the null pointer

can appear anywhere, I see. Currentlg we are handling only the examples in the

note.

[Bug target/54996] gcc with --target=avr fails to build

[gjl at gcc dot gnu.org]

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



Georg-Johann Lay  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #4 from Georg-Johann Lay  2012-11-01 
08:26:21 UTC ---

Don't configure GCC in the source tree.  Read the online documentation on

configuring GCC again.  If you configured in the GCC sources, remove the

sources and retrieve them again to be sure they are not messed up by the

configure in the source tree.



You must have a working avr-binutils in the path.  Alternatively, you can build

and install avr binutils with the same --prefix before configuring avr-gcc. You

don't need to add it to the path in the latter case.



You need binutils 2.23 or higher for avr-gcc 4.7, see the GCC 4.7 release

notes.

[Bug c++/54431] [C++11] g++ crashes when compiling the following file

[markus at trippelsdorf dot de]

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



Markus Trippelsdorf  changed:



   What|Removed |Added



 CC||markus at trippelsdorf dot

   ||de



--- Comment #5 from Markus Trippelsdorf  
2012-11-01 07:46:30 UTC ---

unhandled expression in get_expr_operands():

 

unit size 

align 8 symtab 0 alias set -1 canonical type 0x5a017e0 fields

 context 

full-name "struct A"

X() X(constX&) this=(X&) n_parents=0 use_template=1

interface-unknown

pointer_to_this  chain >

readonly sizes-gimplified unsigned DI

size 

unit size 

align 64 symtab 0 alias set -1 canonical type 0x5a01a80>

readonly used unsigned nonlocal decl_7 DI file test.ii line 6 col 6 size

 unit size 

align 64 offset_align 128

offset 

constant 0>

bit offset 

constant 0> context  chain >

[Bug rtl-optimization/55161] New: internal compiler error: in schedule_reg_moves, at modulo-sched.c:731

[amylaar at gcc dot gnu.org]

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



 Bug #: 55161

   Summary: internal compiler error: in schedule_reg_moves, at

modulo-sched.c:731

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: ice-on-valid-code

  Severity: normal

  Priority: P3

 Component: rtl-optimization

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

ReportedBy: amyl...@gcc.gnu.org

CC: cr...@gcc.gnu.org, olege...@gcc.gnu.org

Target: arm-*-*





int test_04 (int* x, int c)

{

  int s = 0;

  for (int i = 0; i < c; ++i)

s += *--x;

  return s;

}



compiled with:



./cc1 -O2 t.c --std=c99 -mthumb -march=armv7 -fmodulo-sched



worked in r192505.



In r193060, we get:



t.c:7:1: internal compiler error: in schedule_reg_moves, at modulo-sched.c:731

[Bug lto/53746] [lto] segfault in std::vector::__base_ctor (with -fipa-pta)

[vincenzo.innocente at cern dot ch]

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



vincenzo Innocente  changed:



   What|Removed |Added



  Known to work||4.8.0

  Known to fail||4.7.2



--- Comment #5 from vincenzo Innocente  
2012-11-01 07:17:01 UTC ---

the problem still persist in 4.7.2

does not happen in 4.8 20121028 (experimental) [trunk revision 192889]

(too many things have changed though)

[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2

[daniel.kruegler at googlemail dot com]

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

--- Comment #8 from Daniel Krügler  
2012-11-01 07:11:56 UTC ---
(In reply to comment #7)
The error is real. The original example belongs to 5.2.8 p2:

"When typeid is applied to a **glvalue expression** whose type is a polymorphic
class type [..] "

which is the rule requiring dynamic evaluation of the expression. Your counter
example is an expression that is an rvalue expression, which belongs to p3:

"When typeid is applied to an expression other than a glvalue of a polymorphic
class type, the result refers to a std::type_info object representing the
static type of the expression. [..] The expression is an unevaluated operand
(Clause 5)."