[Bug debug/54693] VTA guality issues with loops

[aoliva at gcc dot gnu.org]

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



Alexandre Oliva  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-10-26

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #6 from Alexandre Oliva  2012-10-26 
07:16:35 UTC ---

Patchset for trunk posted:

http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02379.html

[Bug debug/54953] [4.8 Regression] New sra-1.c FAILs on powerpc

[aoliva at gcc dot gnu.org]

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



--- Comment #2 from Alexandre Oliva  2012-10-26 
07:42:07 UTC ---

Without your poposed change, AFTER_WITH_REG is only used while adding

REG_UNUSED marks to REG defs.  That the REG def is unused means it's going to

be discarded and, when it is, either the debug temp will be reset altogether,

or we'll propagate the expression stored in the REG to uses of the REG (e.g.,

the debug use, if we omit the debug temp, or the debug temp, if we needlessly

add it), or we (should?) emit another debug temp BEFORE_WITH_VALUE and use that

instead of the REG (in the orginal debug use or in the needless debug temp). 

In any of these cases, the debug temp is useless.



All that siad, it's probably not a terribly important optimization, so if the

above wouldn't make sense in a comment before the questionable hunk, we might

as well drop it.  Adding REG_FORCE for this new use is probably fine too.

[Bug debug/54953] [4.8 Regression] New sra-1.c FAILs on powerpc

[jakub at gcc dot gnu.org]

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



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  2012-10-26 
08:28:59 UTC ---

Created attachment 28535

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

gcc48-pr54953.patch



Ok, I'll test this version then.  Feel free to clarify comments ;)

[Bug debug/54971] SRA pessimizes debug info by not creating debug stmts for fields without replacements

[jamborm at gcc dot gnu.org]

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



Martin Jambor  changed:



   What|Removed |Added



URL||http://gcc.gnu.org/ml/gcc-p

   ||atches/2012-10/msg02396.htm

   ||l



--- Comment #9 from Martin Jambor  2012-10-26 
09:32:51 UTC ---

Thanks a lot for looking into the miscompare, I simplified your fix a

little, though.  I'd prefer to have get_access_replacement small and

avoid the extra parameter, we can use the grp_to_be_debug_replaced

instead.  I also omitted the DECL_SEEN_IN_BIND_EXPR_P test because I

though it just might never be set on a newly created replacement decl.



The patch is at

http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02396.html

[Bug tree-optimization/55079] New: [4.8 regeression] false positive -Warray-bounds

[dimhen at gmail dot com]

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



 Bug #: 55079

   Summary: [4.8 regeression] false positive -Warray-bounds

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: dim...@gmail.com





$ cat tst.c

int f(unsigned len, int buflen)

{

unsigned taillen;

unsigned slen;

unsigned i;

int b[17];/* needed <= 17 to trigger Warning */

int j = 0;/* needed to trigger Warning */



b[0] = 0;

taillen= buflen & 7;/* taillen [0..7] */



if(taillen) {/* taillen [1..7] */

slen= 8 - taillen;/* slen[7..1] */

if (len

[Bug c++/55076] ice when compiling lambda function

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2012-10-26

 Ever Confirmed|0   |1



--- Comment #1 from Paolo Carlini  2012-10-26 
10:04:46 UTC ---

Please reduce the testcase to a manageable size: we have open quite a few

issues about lambdas and most likely this is a duplicate, but it's

unnecessarily hard to tell with a 600+ KB attachment.

[Bug tree-optimization/55079] [4.8 regeression] false positive -Warray-bounds

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-26

 CC||hubicka at gcc dot gnu.org

   Target Milestone|--- |4.8.0

 Ever Confirmed|0   |1



--- Comment #1 from Richard Biener  2012-10-26 
10:08:44 UTC ---

It's because of unrolling.

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

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Target Milestone|--- |4.8.0

[Bug tree-optimization/54824] [4.8 Regression] ICE in verify_loop_structure

[rguenth at gcc dot gnu.org]

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



--- Comment #10 from Richard Biener  2012-10-26 
10:12:41 UTC ---

Author: rguenth

Date: Fri Oct 26 10:12:35 2012

New Revision: 192841



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

Log:

2012-10-26  Richard Biener  



PR middle-end/54824

* tree-optimize.c (execute_fixup_cfg): Insert __builtin_unreachable

at the end of blocks with no successors.



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



Added:

trunk/gcc/testsuite/gcc.dg/torture/pr54824.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-optimize.c

[Bug tree-optimization/54824] [4.8 Regression] ICE in verify_loop_structure

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #11 from Richard Biener  2012-10-26 
10:12:58 UTC ---

Fixed.

[Bug middle-end/54385] [4.8 regression] ICE in pre_and_rev_post_order_compute, at cfganal.c:873

[mikpe at it dot uu.se]

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



Mikael Pettersson  changed:



   What|Removed |Added



 CC||mikpe at it dot uu.se



--- Comment #3 from Mikael Pettersson  2012-10-26 
10:15:26 UTC ---

I just hit this ICE trying to built trunk @ r192837 as a cross to m68k-linux

with java enabled.  Steven's patch fixed the ICE.



(The java build also needed my proposed PR49847 patch.)

[Bug tree-optimization/54570] [4.8 Regression] FAIL: gcc.dg/builtin-object-size-8.c execution test

[rguenth at gcc dot gnu.org]

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



--- Comment #9 from Richard Biener  2012-10-26 
10:32:53 UTC ---

Note that attributes on __builtin_object_size are wrong - it is marked as pure

which means that



 struct A { char a[4]; int i; } x;



 __builtin_object_size (&x, 1) == __builtin_object_size (&x.a[0], 1)



this only does not "break" as we fold the individual object size calls

to (different) constants before checking whether they are equivalent calls.

Same effect if it were const instead of pure.

[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows

[burnus at gcc dot gnu.org]

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



Tobias Burnus  changed:



   What|Removed |Added



 CC||burnus at gcc dot gnu.org,

   ||rguenther at suse dot de



--- Comment #1 from Tobias Burnus  2012-10-26 
10:36:30 UTC ---

>From PR 54281:



| With --disable-nls intl.h does

|

| #ifdef ENABLE_NLS

| #include 

| extern void gcc_init_libintl (void);

| extern size_t gcc_gettext_width (const char *);

| #else

| /* Stubs.  */

| # undef textdomain

| # define textdomain(domain) (domain)

| # undef bindtextdomain

| # define bindtextdomain(domain, directory) (domain)

| # undef gettext

| # define gettext(msgid) (msgid)

|

| which wrecks an included libintl.h:

| We end up including libintl.h through

|

| gcc/double-int.h

| #include 

|   #include   (here from GCC 4.1)

|#include 

|  #include 



Side note: On my system only GCC 4.1's c++locale.h includes libintl.h, GCC

4.3/4.4/4.5/4.6/4.7 don't.



And:

| Possibly by looking for and

| including libintl.h before re-defining those macros?  It's the toplevel

| intl.h btw.



| Another fix is to include all system headers (and thus gmp.h) from system.h

| which always comes before includes of intl.h.







The patch for PR 54281 comment 10 (Rev. 190487) changed it to:



 #if defined(HAVE_LIBINTL_H) || defined(ENABLE_NLS)

 # include 

 #endif



 #ifdef ENABLE_NLS

...

#else

 /* Stubs. */

 # undef textdomain

 # define textdomain(domain) (domain)

...







As written in comment 0, that breaks MinGW builds as libintl.h re-defined

fprint on non-POSIX-printf systems. If one now tries to undo the effect by

using:



#if defined(HAVE_LIBINTL_H) || defined(ENABLE_NLS)

#  include 

#  if !defined(ENABLE_NLS)

#undef fprintf

#undef sprintf

#undef snprintf

#undef vfprintf

#  endif

#endif





One ends up with:



libbackend.a(ipa-pure-const.o): In function `check_decl':

C:\MinGW\msys\1.0\home\brad\gfortran\ibin\gcc/../../gcc-trunk/gcc/ipa-pure-const.c:253:

undefined reference to `_libintl

_fprintf'

...

libcommon-target.a(opts.o): In function `wrap_help':

C:\MinGW\msys\1.0\home\brad\gfortran\ibin\gcc/../../gcc-trunk/gcc/opts.c:884:

undefined reference to `___printf__'







Without having tested with neither MinGW nor with GCC 4.1/Linux, I wonder

whether one could do something like:



 #if defined(HAVE_LIBINTL_H) && !defined(ENABLE_NLS)

# define _LIBINTL_H 1

#end if



#ifdef (ENABLE_NLS)

 # include 

 #endif



Or is that too evil or won't it work?

[Bug debug/54402] [4.8 Regression] var-tracking does not scale

[rsandifo at gcc dot gnu.org]

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



rsand...@gcc.gnu.org  changed:



   What|Removed |Added



 CC||rsandifo at gcc dot gnu.org



--- Comment #4 from rsandifo at gcc dot gnu.org  
2012-10-26 10:53:29 UTC ---

As Uros says in bug 54507, the reflect test from libgo is another example.

Without var tracking it takes 20s on my x86_64 box (tested with a 32-bit

compiler).  With var tracking it takes 46m 40s.

[Bug c++/55080] New: -pedantic produces error: floating-point literal cannot appear in a constant-expression

[manu at gcc dot gnu.org]

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



 Bug #: 55080

   Summary: -pedantic produces error: floating-point literal

cannot appear in a constant-expression

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: accepts-invalid

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: m...@gcc.gnu.org

CC: f...@csl.cornell.edu, m...@gcc.gnu.org, m...@suse.de,

papad...@shfj.cea.fr, rearn...@gcc.gnu.org,

rgue...@gcc.gnu.org, rnew...@compubrite.com

Depends on: 11393

 Build: any





+++ This bug was initially created as a clone of Bug #11393 +++



class B { 

 static const int c = 3.1415926;

};





-std=c++98 -pedantic gives

error: floating-point literal cannot appear in a constant-expression

  static const int c = 3.1415926;

   ^



and -std=c++98 gives nothing. Both -std=c++11 -pedantic and just -std=c++11

report nothing.



This is a bug. -pedantic should not produce errors. If this is a GNU extension

in c++98 mode, then it should produce a warning like:



warning: ISO C++98 forbids using a floating-point literal in a

constant-expression [-Wpedantic]

[Bug c++/55080] -pedantic produces error: floating-point literal cannot appear in a constant-expression

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords|accepts-invalid |diagnostic
 CC|fang at csl dot |
   |cornell.edu, matz at suse   |
   |dot de, papadopo at shfj|
   |dot cea.fr, rearnsha at gcc |
   |dot gnu.org, rguenth at gcc |
   |dot gnu.org, rnewman at |
   |compubrite dot com  |
 Depends on|11393   |

--- Comment #1 from Manuel López-Ibáñez  2012-10-26 
11:40:05 UTC ---
I shouldn't have used clone bug...

[Bug c++/11393] Initializer of static const float class member is not legal in c++98

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||MOVED



--- Comment #29 from Paolo Carlini  2012-10-26 
11:43:52 UTC ---

Ok, thanks guys. Let's close this then, the new clearer PRs clarify the valid

standing issues in this area.

[Bug c++/11393] Initializer of static const float class member is not legal in c++98

[manu at gcc dot gnu.org]

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

--- Comment #30 from Manuel López-Ibáñez  2012-10-26 
11:45:11 UTC ---
> 
> Your "c" example seems like a completely separate issue that should be a
> separate PR, I don't understand why it's being discussed here.

It is now PR55080.

About this PR, I concur now with Jonathan:

"My suggestion would be do nothing and lose the PR.  If you want a warning in
C++98 use -pedantic, which is consistent with other GNU extensions. In C++11
use constexpr."

[Bug bootstrap/55049] [4.8 Regression] bootstrap failed with --with-multilib-list=m32,m64,mx32

[hjl.tools at gmail dot com]

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



H.J. Lu  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #6 from H.J. Lu  2012-10-26 11:47:31 
UTC ---

Fixed.

[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos

[rguenth at gcc dot gnu.org]

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



Richard Biener  changed:



   What|Removed |Added



   Priority|P1  |P3



--- Comment #22 from Richard Biener  2012-10-26 
11:57:19 UTC ---

Ok, first of all we need to call fix_loop_structure from tracer.  That properly

associates blocks with loops.



The issue that remains is that disambiguate_loops_with_multiple_latches

doesn't disambiguate the loop because we keep loop->latch as non-NULL

Later local-pure-const asks for LOOPS_NORMAL and create_preheaders cannot

deal with the situation, breaking loop structure.



Thus, first of all fix_loop_structure needs to re-compute latches properly.



I have a patch.

[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows

[rguenther at suse dot de]

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



--- Comment #2 from rguenther at suse dot de  
2012-10-26 12:05:14 UTC ---

On Fri, 26 Oct 2012, burnus at gcc dot gnu.org wrote:



> 

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

> 

> Tobias Burnus  changed:

> 

>What|Removed |Added

> 

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

>||rguenther at suse dot de

> 

> --- Comment #1 from Tobias Burnus  2012-10-26 
> 10:36:30 UTC ---

> From PR 54281:

> 

> | With --disable-nls intl.h does

> |

> | #ifdef ENABLE_NLS

> | #include 

> | extern void gcc_init_libintl (void);

> | extern size_t gcc_gettext_width (const char *);

> | #else

> | /* Stubs.  */

> | # undef textdomain

> | # define textdomain(domain) (domain)

> | # undef bindtextdomain

> | # define bindtextdomain(domain, directory) (domain)

> | # undef gettext

> | # define gettext(msgid) (msgid)

> |

> | which wrecks an included libintl.h:

> | We end up including libintl.h through

> |

> | gcc/double-int.h

> | #include 

> |   #include   (here from GCC 4.1)

> |#include 

> |  #include 

> 

> Side note: On my system only GCC 4.1's c++locale.h includes libintl.h, GCC

> 4.3/4.4/4.5/4.6/4.7 don't.

> 

> And:

> | Possibly by looking for and

> | including libintl.h before re-defining those macros?  It's the toplevel

> | intl.h btw.

> 

> | Another fix is to include all system headers (and thus gmp.h) from system.h

> | which always comes before includes of intl.h.

> 

> 

> 

> The patch for PR 54281 comment 10 (Rev. 190487) changed it to:

> 

>  #if defined(HAVE_LIBINTL_H) || defined(ENABLE_NLS)

>  # include 

>  #endif

> 

>  #ifdef ENABLE_NLS

> ...

> #else

>  /* Stubs. */

>  # undef textdomain

>  # define textdomain(domain) (domain)

> ...

> 

> 

> 

> As written in comment 0, that breaks MinGW builds as libintl.h re-defined

> fprint on non-POSIX-printf systems. If one now tries to undo the effect by

> using:

> 

> #if defined(HAVE_LIBINTL_H) || defined(ENABLE_NLS)

> #  include 

> #  if !defined(ENABLE_NLS)

> #undef fprintf

> #undef sprintf

> #undef snprintf

> #undef vfprintf

> #  endif

> #endif

> 

> 

> One ends up with:

> 

> libbackend.a(ipa-pure-const.o): In function `check_decl':

> C:\MinGW\msys\1.0\home\brad\gfortran\ibin\gcc/../../gcc-trunk/gcc/ipa-pure-const.c:253:

> undefined reference to `_libintl

> _fprintf'

> ...

> libcommon-target.a(opts.o): In function `wrap_help':

> C:\MinGW\msys\1.0\home\brad\gfortran\ibin\gcc/../../gcc-trunk/gcc/opts.c:884:

> undefined reference to `___printf__'

> 

> 

> 

> Without having tested with neither MinGW nor with GCC 4.1/Linux, I wonder

> whether one could do something like:

> 

>  #if defined(HAVE_LIBINTL_H) && !defined(ENABLE_NLS)

> # define _LIBINTL_H 1

> #end if

> 

> #ifdef (ENABLE_NLS)

>  # include 

>  #endif

> 

> Or is that too evil or won't it work?



Fact is that all this stuff happens because gmp.h is not included

from system.h ...

[Bug c++/55080] -pedantic produces error: floating-point literal cannot appear in a constant-expression

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-26

 Ever Confirmed|0   |1



--- Comment #2 from Jonathan Wakely  2012-10-26 
12:10:43 UTC ---

cp_parser_primary_expression in parser.c only calls

cp_parser_non_integral_constant_expression (which prints the error) when

pedantic is false

[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows

[dnovillo at google dot com]

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



--- Comment #3 from dnovillo at google dot com  
2012-10-26 12:34:53 UTC ---

On Fri, Oct 26, 2012 at 8:05 AM, rguenther at suse dot de

 wrote:



> Fact is that all this stuff happens because gmp.h is not included

> from system.h ...



I broke Ada when I tried it.  I don't remember the details, but it

seemed tedious to fix.





Diego.

[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows

[rguenther at suse dot de]

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



--- Comment #4 from rguenther at suse dot de  
2012-10-26 12:36:30 UTC ---

On Fri, 26 Oct 2012, dnovillo at google dot com wrote:



> 

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

> 

> --- Comment #3 from dnovillo at google dot com  
> 2012-10-26 12:34:53 UTC ---

> On Fri, Oct 26, 2012 at 8:05 AM, rguenther at suse dot de

>  wrote:

> 

> > Fact is that all this stuff happens because gmp.h is not included

> > from system.h ...

> 

> I broke Ada when I tried it.  I don't remember the details, but it

> seemed tedious to fix.



I know ... but it's the only way that is designed to avoid this

kind of issues.



Richard.

[Bug c++/55081] New: [4.8 regression?] Non-optimized static array elements initialization

[zhroma at ispras dot ru]

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



 Bug #: 55081

   Summary: [4.8 regression?] Non-optimized static array elements

initialization

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

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

ReportedBy: zhr...@ispras.ru





Created attachment 28536

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

Preprocessed minimized testcase.



In some cases g++ 4.8 revision 192141 and later generate initialization block

for local static array with constant elements, while earlier g++ versions 

insert constants into assembly data section (gcc-base is rev192140, gcc-peak is

rev192141, tested on 64bit Linux):

$ cat test.cpp 

struct R {

int field;

};

long* foo() {

R r;

static long array[] = {

sizeof(char),

(reinterpret_cast(&(r.field)) -

reinterpret_cast(&r))+1,

};

return array;

}

$ gcc-base/bin/g++ -O2 test.cpp -S -o 1.s

$ gcc-peak/bin/g++ -O2 test.cpp -S -o 2.s 

$ diff -u 1.s 2.s

--- 1.s

+++ 2.s

@@ -6,8 +6,27 @@

 _Z3foov:

 .LFB0:

 .cfi_startproc

+cmpb$0, _ZGVZ3foovE5array(%rip)

+je.L11

 movl$_ZZ3foovE5array, %eax

 ret

+.p2align 4,,10

+.p2align 3

+.L11:

+subq$8, %rsp

+.cfi_def_cfa_offset 16

+movl$_ZGVZ3foovE5array, %edi

+call__cxa_guard_acquire

+testl%eax, %eax

+je.L3

+movl$_ZGVZ3foovE5array, %edi

+movq$1, _ZZ3foovE5array(%rip)

+call__cxa_guard_release

+.L3:

+movl$_ZZ3foovE5array, %eax

+addq$8, %rsp

+.cfi_def_cfa_offset 8

+ret

 .cfi_endproc

 .LFE0:

 .size_Z3foov, .-_Z3foov

@@ -16,7 +35,9 @@

 .type_ZZ3foovE5array, @object

 .size_ZZ3foovE5array, 16

 _ZZ3foovE5array:

+.zero8

 .quad1

-.quad1

+.local_ZGVZ3foovE5array

+.comm_ZGVZ3foovE5array,8,8

 .ident"GCC: (GNU) 4.8.0 20121005 (experimental)"

 .section.note.GNU-stack,"",@progbits



So, the value of array[0] (sizeof(char) equals 1) is generated on the first

function call instead of emitting it to assemlby data section directly. If I

remove second constant element



static long array[] = {

sizeof(char),

};



.. or reimplement it in the following way



static long array[] = {

sizeof(char),

__builtin_offsetof(R, field)+1,

};



the problem disappears.



As I understand, the patch rev192141 goal is new warning. Maybe it should not

affect codegen so much?



Additional information.

The problem described above lead to Webkit build failure.

There is the following step while generating assembly for Webkit JavaScriptCore

low-level interpreter: it generates dummy executable containing a function with

static array:



static const unsigned extractorTable[308992] = {

unsigned(-1639711386),

(reinterpret_cast(&(reinterpret_cast

(0x4000)-unsigned(267773781),

sizeof(ValueProfile),

// and so on...

};



And later this dummy executable file (its data section) is parsed to find all

these sizeof-and-offset values. This certainly seems strange, but when Webkit

is cross-compiled it helps to find offsets without running anything on target.

After gcc revision 192141 that executable-parsing script fails to get all

sizeof(...) values - they are zeros in gcc-generated assembly data section.

[Bug c++/55076] ice when compiling lambda function

[markus at trippelsdorf dot de]

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



Markus Trippelsdorf  changed:



   What|Removed |Added



 CC||markus at trippelsdorf dot

   ||de



--- Comment #2 from Markus Trippelsdorf  
2012-10-26 13:19:45 UTC ---

Testcase was over 7.1 Mbyte, but parallel creduce is quick.



markus@x4 tmp % cat test.ii

void src_new (int);

template < bool > struct A

{

void prepare ()

{

([=] { src_new (con); });

} 

int con;

};



markus@x4 tmp % g++ -std=c++11 -c test.ii

test.ii: In lambda function:

test.ii:6:28: internal compiler error: Segmentation fault

 ([=] { src_new (con); });

^

[Bug c++/54955] alignas example in gcc 4.8 changes.html won't compile

[dodji at gcc dot gnu.org]

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



Dodji Seketeli  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

[Bug c++/55058] [4.7/4.8 Regression] Unexpected invalid type conversion error

[sebastian.hu...@embedded-brains.de]

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



Sebastian Huber  changed:



   What|Removed |Added



  Attachment #28518|0   |1

is obsolete||

  Attachment #28527|0   |1

is obsolete||



--- Comment #5 from Sebastian Huber  
2012-10-26 13:28:08 UTC ---

Created attachment 28537

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

Test case.



Thanks for the hint to the delta tool.  This is great for automatic test case

reduction.



The test code is now:



template 

struct A { };



template 

struct B {

  B(const A T::* p);

  typedef A D;

};



template 

B::B(const D T::* p) { }



struct C {

  C() : e() {};



  const A e;

};



B g(&C::e);



The crucial thing is the "typedef A D".  It works, if we move it before the

constructor declaration "B(const A T::* p)".  Removing the constructor

definition works also.

[Bug c++/55076] ice when compiling lambda function

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|WAITING |NEW

 CC|paolo.carlini at oracle dot |

   |com |



--- Comment #3 from Paolo Carlini  2012-10-26 
13:30:35 UTC ---

Indeed. Thanks Markus! Next, whether it's actually a (more or less manifest)

dup.

[Bug c++/54955] alignas example in gcc 4.8 changes.html won't compile

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 CC|dodji at gcc dot gnu.org|



--- Comment #4 from Paolo Carlini  2012-10-26 
13:31:33 UTC ---

Thanks Dodji!

[Bug c++/55076] ice when compiling lambda function

[markus at trippelsdorf dot de]

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



--- Comment #4 from Markus Trippelsdorf  
2012-10-26 13:41:36 UTC ---

Valgrind says:



markus@x4 tmp % /var/tmp/gcc_valgrind/usr/local/bin/g++ -std=c++11 -c test.ii

==10632== Invalid read of size 2

==10632==at 0x668622: lvalue_kind(tree_node const*) (tree.c:148)

==10632==by 0x668803: lvalue_kind(tree_node const*) (tree.c:103)

==10632==by 0x6691C8: lvalue_p(tree_node const*) (tree.c:269)

==10632==by 0x4CF7EC: standard_conversion(tree_node*, tree_node*,

tree_node*, bool, int) (call.c:1104)

==10632==by 0x4D5629: implicit_conversion(tree_node*, tree_node*,

tree_node*, bool, int, int) (call.c:1696)

==10632==by 0x4D7702: add_function_candidate(z_candidate**, tree_node*,

tree_node*, tree_node*, vec_t const*, tree_node*, tree_node*,

 int, int) (call.c:1987)

==10632==by 0x4D3EEE: add_candidates(tree_node*, tree_node*,

vec_t const*, tree_node*, tree_node*, bool, tree_node*, tree_node*,

int,

 z_candidate**, int) (call.c:4954)

==10632==by 0x4DA7B0: perform_overload_resolution(tree_node*,

vec_t const*, z_candidate**, bool*, int) (call.c:3807)

==10632==by 0x4E0D5C: build_new_function_call(tree_node*,

vec_t**, bool, int) (call.c:3884)

==10632==by 0x656EEA: finish_call_expr(tree_node*, vec_t**,

bool, bool, int) (semantics.c:2190)

==10632==by 0x5CEA2E: cp_parser_postfix_expression(cp_parser*, bool, bool,

bool, cp_id_kind*) (parser.c:5814)

==10632==by 0x5D9D32: cp_parser_unary_expression(cp_parser*, bool, bool,

cp_id_kind*) (parser.c:6682)

==10632==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

==10632==

[Bug c++/54883] Name mangling of types in an unnamed namespace

[sebastian.hu...@embedded-brains.de]

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



Sebastian Huber  changed:



   What|Removed |Added



 CC||sebastian.huber@embedded-br

   ||ains.de



--- Comment #1 from Sebastian Huber  
2012-10-26 13:49:23 UTC ---

This bug is also present in x86-64 in GCC 4.6, 4.7, and 4.8.



echo "namespace { enum E { E1 }; } void f(E e) { }" | tee a.c b.c > /dev/null

g++ -c a.c -o a.o

g++ -c b.c -o b.o

objdump --syms a.o



a.o: file format elf64-x86-64



SYMBOL TABLE:

 ldf *ABS*   a.c

 ld  .text   .text

 ld  .data   .data

 ld  .bss    .bss

 ld  .comment.SUSE.OPTs 

.comment.SUSE.OPTs

 ld  .note.GNU-stack

.note.GNU-stack

 ld  .eh_frame   .eh_frame

 ld  .comment    .comment

 g F .text  0009 _Z1fN12_GLOBAL__N_11EE





objdump --syms b.o



b.o: file format elf64-x86-64



SYMBOL TABLE:

 ldf *ABS*   b.c

 ld  .text   .text

 ld  .data   .data

 ld  .bss    .bss

 ld  .comment.SUSE.OPTs 

.comment.SUSE.OPTs

 ld  .note.GNU-stack

.note.GNU-stack

 ld  .eh_frame   .eh_frame

 ld  .comment    .comment

 g F .text  0009 _Z1fN12_GLOBAL__N_11EE

[Bug c++/55076] ice when compiling lambda function

[redi at gcc dot gnu.org]

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



--- Comment #5 from Jonathan Wakely  2012-10-26 
14:00:45 UTC ---

probably bug 54403

[Bug c++/54984] [4.6/4.7/4.8 Regression] Array allocated with new in a template class is default initialised

[paolo at gcc dot gnu.org]

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



--- Comment #6 from paolo at gcc dot gnu.org  
2012-10-26 14:03:38 UTC ---

Author: paolo

Date: Fri Oct 26 14:03:32 2012

New Revision: 192846



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

Log:

/cp

2012-10-26  Paolo Carlini  



PR c++/54984

* init.c (build_new): Don't turn a null *init into a pointer to

empty vector orig_init.



/testsuite

2012-10-26  Paolo Carlini  



PR c++/54984

* g++.dg/template/new11.C: New.





Added:

trunk/gcc/testsuite/g++.dg/template/new11.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/init.c

trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/54472] ICE (spill_failure): unable to find a register to spill in class 'AREG' with -O -fschedule-insns -fselective-scheduling

[abel at gcc dot gnu.org]

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



--- Comment #7 from Andrey Belevantsev  2012-10-26 
14:04:03 UTC ---

(In reply to comment #6)

> Have you managed to check the patch?



The patch does the right thing for sets and clobbers, but the uses case should

be amended, too, judging from the sched-deps.c code.   Sorry, I was too busy to

send the patch, now, I'll try doing this on the next week.

[Bug c++/55076] ice when compiling lambda function

[markus at trippelsdorf dot de]

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



--- Comment #6 from Markus Trippelsdorf  
2012-10-26 14:07:11 UTC ---

(In reply to comment #5)

> probably bug 54403



Yes. Valgrind backtrace is the same.

[Bug c++/54984] [4.6/4.7/4.8 Regression] Array allocated with new in a template class is default initialised

[paolo at gcc dot gnu.org]

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



--- Comment #7 from paolo at gcc dot gnu.org  
2012-10-26 14:19:51 UTC ---

Author: paolo

Date: Fri Oct 26 14:19:44 2012

New Revision: 192847



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

Log:

/cp

2012-10-26  Paolo Carlini  



PR c++/54984

* init.c (build_new): Don't turn a null *init into a pointer to

empty vector orig_init.



/testsuite

2012-10-26  Paolo Carlini  



PR c++/54984

* g++.dg/template/new11.C: New.



Added:

branches/gcc-4_7-branch/gcc/testsuite/g++.dg/template/new11.C

Modified:

branches/gcc-4_7-branch/gcc/cp/ChangeLog

branches/gcc-4_7-branch/gcc/cp/init.c

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

[Bug c++/54984] [4.6 Regression] Array allocated with new in a template class is default initialised

[paolo.carlini at oracle dot com]

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



Paolo Carlini  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

  Known to work||4.7.3, 4.8.0

 Resolution||FIXED

   Target Milestone|--- |4.7.3

Summary|[4.6/4.7/4.8 Regression]|[4.6 Regression] Array

   |Array allocated with new in |allocated with new in a

   |a template class is default |template class is default

   |initialised |initialised

  Known to fail|4.8.0   |



--- Comment #8 from Paolo Carlini  2012-10-26 
14:21:15 UTC ---

Fixed mainline and 4.7.3.

[Bug libstdc++/54075] [4.7.1] unordered_map insert 3x slower than 4.6.2

[paolo.carlini at oracle dot com]

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



--- Comment #32 from Paolo Carlini  2012-10-26 
14:34:37 UTC ---

Thanks. Francois, can you please further investigate this issue? In fact, if

the slowdown goes away with a preliminary reserve, it must be possible to

handle the problem rather easily, by tweaking the grow policy or something (We

should be a bit patient and consider that vs 4.4.x the implementation is almost

completely different)

[Bug c++/55081] [4.8 regression?] Non-optimized static array elements initialization

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org,

   ||jason at gcc dot gnu.org

   Target Milestone|--- |4.8.0



--- Comment #1 from Jakub Jelinek  2012-10-26 
14:49:20 UTC ---

Works fine with -std=c++11.

In store_init we have:

  /* In C++0x constant expression is a semantic, not syntactic, property.

 In C++98, make sure that what we thought was a constant expression at

 template definition time is still constant.  */

  if ((cxx_dialect >= cxx0x

   || DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (decl))

  && (decl_maybe_constant_var_p (decl)

  || TREE_STATIC (decl)))



but here DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (decl) isn't set and

cxx_dialect < cxx0x for -std=c++98.  Not sure what we should do here, either

just call maybe_constant_value or maybe_constant_init otherwise to fold sizeof,

or, if it is really not appropriate for C++98 as an optimization,

fold_sizeof_expr_r recursively plus fold.  Jason, what do you think?

[Bug c++/55082] New: c++11: default member constructor

[lisp2d at lisp2d dot net]

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



 Bug #: 55082

   Summary: c++11: default member constructor

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





In class definition default constructor for elements works only

by using {} notation.

 Operator = is not allowed.



bug.cpp:



class A{

int a{0}; // works

int b = 0; // works

public:

explicit  A(int x):a(x),b(x){}

};



class B{

A a{0}; // works

A b = 0;  // error: trying to use operator=

public:

explicit  B(int x):a(x),b(x){}

};



int main(int,char**){

  B b(1);

  return  0;}

[Bug c/55083] New: failure while configuring libatomic is not cleaned up

[pedzsan at gmail dot com]

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



 Bug #: 55083

   Summary: failure while configuring libatomic is not cleaned up

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: pedz...@gmail.com





If something fails during the configuration phase of libatomic, a subsequent

"make" will take a different path and not complete the configure processing.



The error can be seen in the configure-target-libatomic: code of Makefile.in

(at the top directory).  Midway down, if the directory exists, exit 0 is

called.  If it does not exist, then it is created and configure for libatomic

is called.  But if configure fails, the directory is not removed.  Subsequent

"make" will assume that everything had been configured.

[Bug c/55084] New: please submit full bug report

[nikhildagade007 at gmail dot com]

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



 Bug #: 55084

   Summary: please submit full bug report

Classification: Unclassified

   Product: gcc

   Version: unknown

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c

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

ReportedBy: nikhildagade...@gmail.com





internal error:Segmentation fault

[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault

[dodji at gcc dot gnu.org]

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



Dodji Seketeli  changed:



   What|Removed |Added



 Status|NEW |ASSIGNED

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

   |gnu.org |

[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault

[dodji at seketeli dot org]

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

--- Comment #8 from dodji at seketeli dot org  
2012-10-26 15:13:10 UTC ---
"paolo.carlini at oracle dot com"  a écrit:

> Dodji, are there any chances you can look into this
> issue? The alias decls seem determinant.

Sure.  Sorry for the delay, I was buried into something else.  I am
looking into this now.

[Bug bootstrap/55083] failure while configuring libatomic is not cleaned up

[pinskia at gcc dot gnu.org]

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



Andrew Pinski  changed:



   What|Removed |Added



   Keywords||build

  Component|c   |bootstrap



--- Comment #1 from Andrew Pinski  2012-10-26 
15:14:17 UTC ---

Can you be more specific than about the failure you are seeing in configuring

for libatomic?



Also what target are you seeing an error for?

[Bug c/55084] please submit full bug report

[mpolacek at gcc dot gnu.org]

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



Marek Polacek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |WAITING

   Last reconfirmed||2012-10-26

 CC||mpolacek at gcc dot gnu.org

 Ever Confirmed|0   |1



--- Comment #1 from Marek Polacek  2012-10-26 
15:15:50 UTC ---

Please read http://gcc.gnu.org/bugs/#report.

[Bug c++/55081] [4.8 regression?] Non-optimized static array elements initialization

[amonakov at gcc dot gnu.org]

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



Alexander Monakov  changed:



   What|Removed |Added



 CC||amonakov at gcc dot gnu.org



--- Comment #2 from Alexander Monakov  2012-10-26 
15:17:20 UTC ---

Not sure if that's relevant, but the original testcase uses 0x4000 in place of

non-compile-time-constant (&r) like this:



struct R {

int field;

};

long* foo() {

static long array[] = {

sizeof(char),

  (reinterpret_cast(&(reinterpret_cast(0x4000)->field)) - 0x4000),  

};

return array;

}

[Bug web/54973] [bugzilla] make "Before reporting a bug" notice more prominent

[redi at gcc dot gnu.org]

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



--- Comment #7 from Jonathan Wakely  2012-10-26 
15:20:54 UTC ---

This is why we need it:

http://gcc.gnu.org/ml/gcc-bugs/2012-10/msg02459.html

[Bug middle-end/37448] gcc 4.3.1 cannot compile big function

[hubicka at gcc dot gnu.org]

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



--- Comment #47 from Jan Hubicka  2012-10-26 
15:22:50 UTC ---

Hmm, good timming. I just started looking into re-tunning inliner heuristics

for 4.8 so I should look again into this inline bomb... Looks like inliner did

not get faster ;)

[Bug web/54973] [bugzilla] make "Before reporting a bug" notice more prominent

[pinskia at gcc dot gnu.org]

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



--- Comment #8 from Andrew Pinski  2012-10-26 
15:25:30 UTC ---

(In reply to comment #7)

> This is why we need it:

> http://gcc.gnu.org/ml/gcc-bugs/2012-10/msg02459.html



I agree we need it but I don't think the above one is a good example as the

summary for that bug is "please submit full bug report" :).

[Bug web/54973] [bugzilla] make "Before reporting a bug" notice more prominent

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-10-26
 Ever Confirmed|0   |1

--- Comment #9 from Frédéric Buclin  2012-10-26 
15:27:59 UTC ---
(In reply to comment #8)
> I agree we need it but I don't think the above one is a good example as the
> summary for that bug is "please submit full bug report" :).

Close that bug as invalid. I personally don't hesitate to kill such bugs when
doing triage in bugzilla.mozilla.org.

[Bug bootstrap/55083] failure while configuring libatomic is not cleaned up

[pedzsan at gmail dot com]

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



--- Comment #2 from Perry Smith  2012-10-26 15:31:27 
UTC ---

To be clear, the error during configuration is not what the bug report is

about.  The discussion of the error can be seen here:

http://gcc.gnu.org/ml/gcc/2012-10/msg00380.html



cc1 is failing because LD_LIBRARY_PATH is set to the wrong value.



What this bug report is addressing is the fact that a failure does not clean

up.



The test I'm doing may be a little hard to recreate but I am doing



rm -r powerpc-ibm-aix6.1.0.0/libatomic

make configure-target-libatomic



but you will need to somehow cause your gcc/xgcc or gcc/cc1 to fail (or create

some other way to cause the configure to fail).

[Bug c++/55081] [4.8 regression?] Non-optimized static array elements initialization

[jason at gcc dot gnu.org]

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



--- Comment #3 from Jason Merrill  2012-10-26 
15:33:45 UTC ---

(In reply to comment #1)

> but here DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (decl) isn't set and

> cxx_dialect < cxx0x for -std=c++98.  Not sure what we should do here, either

> just call maybe_constant_value or maybe_constant_init otherwise to fold 
> sizeof,

> or, if it is really not appropriate for C++98 as an optimization,

> fold_sizeof_expr_r recursively plus fold.  Jason, what do you think?



I think let's just remove the cxx_dialect check here.

[Bug web/54973] [bugzilla] make "Before reporting a bug" notice more prominent

[ian at airs dot com]

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



Ian Lance Taylor  changed:



   What|Removed |Added



 CC||ian at airs dot com



--- Comment #10 from Ian Lance Taylor  2012-10-26 15:47:21 
UTC ---

I'm in favor of this change and I'll approve it but I don't know how to

actually do it.

[Bug middle-end/36041] Speed up builtin_popcountll

[gpiez at web dot de]

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



Gunther Piez  changed:



   What|Removed |Added



 CC||gpiez at web dot de



--- Comment #10 from Gunther Piez  2012-10-26 15:51:24 UTC 
---

Just noted the exceptional slowness of the provided __builtin_popcountll() even

on ARMv5.



I already used the above parallel bit count algorithm in the case that a native

bit count instruction (like the SSE popcnt or NEON vcnt) is not present, but

native 64 bit registers are available. 



But on a 32 bit architecture like ARM I figured it made sense to just use the

__builtin_popcountll() because the many 64 bit instructions in the algorithm

may be very slow without NEON or similar support on a pure 32 bit architecture.



But "optimizing" my code with some macro magic to make it use the library

popcount made the whole program 25% slower, although only a minor part of it

actually does use the popcount instruction.

[Bug tree-optimization/55085] New: [4.8 regression] false positive -Warray-bounds

[dimhen at gmail dot com]

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



 Bug #: 55085

   Summary: [4.8 regression] false positive -Warray-bounds

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: dim...@gmail.com





$ gcc -Werror -Wall -Wextra -O2 -funroll-loops -c 1.c

1.c: In function 'bar':

1.c:12:11: error: array subscript is above array bounds [-Werror=array-bounds]

  if(!a[i])

   ^

void bar(unsigned m)

{

void *a[3];



int i;

for(i=0; i<(int)m; i++)

a[i]=0; // missing warning ?



switch(m) {

case 2:

for(i=0; i<(int)m; i++)

if(!a[i])

return;

}

}

[Bug tree-optimization/55085] [4.8 regression] false positive -Warray-bounds

[dimhen at gmail dot com]

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



--- Comment #1 from Dmitry G. Dyachenko  2012-10-26 
15:56:16 UTC ---

$ gcc -v

Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: /home/dima/src/gcc-current/configure

--prefix=/usr/local/gcc_current --with-multilib-list=m64 --enable-shared

--enable-checking=release --enable-gnu-unique-object --enable-linker-build-id

--enable-languages=c,c++,lto --enable-plugin --with-tune=native

--enable-version-specific-runtime-libs

Thread model: posix

gcc version 4.8.0 20121026 (experimental) [trunk revision 192841] (GCC)

[Bug c++/55081] [4.8 regression?] Non-optimized static array elements initialization

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-10-26

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

   |gnu.org |

 Ever Confirmed|0   |1



--- Comment #4 from Jakub Jelinek  2012-10-26 
15:57:55 UTC ---

Created attachment 28538

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

gcc48-pr55081.patch



Untested fix.

[Bug web/54973] [bugzilla] make "Before reporting a bug" notice more prominent

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |LpSolit at netscape dot net
   |gnu.org |

--- Comment #11 from Frédéric Buclin  2012-10-26 
16:03:54 UTC ---
Instead of a fieldset, I simply put a solid border. Also, I didn't reuse the
comment class but hardcoded the style for this block. Are you happy with the
color, or do you want something else?

[Bug web/54973] [bugzilla] make "Before reporting a bug" notice more prominent

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/bugzilla
   ||/enter_bug.cgi?product=gcc

--- Comment #12 from Frédéric Buclin  2012-10-26 
16:06:33 UTC ---
Click the URL link above to see how it looks like. The change has already been
applied to GCC Bugzilla.

[Bug debug/54971] SRA pessimizes debug info by not creating debug stmts for fields without replacements

[jamborm at gcc dot gnu.org]

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



--- Comment #10 from Martin Jambor  2012-10-26 
16:13:08 UTC ---

Author: jamborm

Date: Fri Oct 26 16:13:00 2012

New Revision: 192848



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

Log:

2012-10-26  Martin Jambor  



PR debug/54971

* tree-sra.c (struct access): New flag grp_to_be_debug_replaced.

(dump_access): Dump the new flag.

(analyze_access_subtree): Set the new flag when appropriate.

(create_access_replacement): Handle debug replacements differently.

(generate_subtree_copies): Handle the grp_to_be_debug_replaced flag.

(init_subtree_with_zero): Likewise.

(sra_modify_expr): Likewise.

(load_assign_lhs_subreplacements): Likewise.

(sra_modify_assign): Likewise.







Modified:

trunk/gcc/ChangeLog

trunk/gcc/tree-sra.c

[Bug fortran/55086] New: ICE with FORALL in allocate_temp_for_forall_nest_1

[burnus at gcc dot gnu.org]

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



 Bug #: 55086

   Summary: ICE with FORALL in allocate_temp_for_forall_nest_1

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: ice-on-valid-code

  Severity: normal

  Priority: P3

 Component: fortran

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

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





The following program crashes in trans-stmt.c:3234's

allocate_temp_for_forall_nest_1 for:



3234  unit = fold_convert (gfc_array_index_type, TYPE_SIZE_UNIT (type));



as TYPE_SIZE_UNIT(type) == NULL.





ICEs in the such-marked line. ICEs with GCC 4.1 to 4.8.



  implicit none

  character(len=5), pointer :: a(:), b(:)

  character(len=5), pointer :: c, d

  allocate (a(2), b(2), c, d)

  a = [ "abcde", "ABCDE" ]

  call aloct_pointer_copy_4 (b, a)

  print *, b(1)

  print *, b(2)

  if (any (a /= b)) stop 'WRONG'



  call aloct_copy_4 (b, a)

  print *, b(1)

  print *, b(2)

  if (any (a /= b)) stop 'WRONG'



  d = '12345'

  c = "abcde"

  call test2 (d, c)

  print *, d

  if (d /= '1cb15') stop 'WRONG'



  call test2p (d, c)

  print *, d

  if (d /= '1cb15') stop 'WRONG'



contains

 subroutine aloct_pointer_copy_4(o, i)

  character(len=*), pointer :: o(:), i(:)

  integer :: nl1, nu1

  integer :: i1

  nl1 = lbound(i,dim=1)

  nu1 = ubound(i,dim=1)

  forall (i1 = nl1:nu1) o(i1) = i(i1)

 end subroutine aloct_pointer_copy_4

 subroutine aloct_copy_4(o, i)

  character(len=*), pointer :: o(:), i(:)

  integer :: nl1, nu1

  integer :: i1

  nl1 = lbound(i,dim=1)

  nu1 = ubound(i,dim=1)

  forall (i1 = nl1:nu1) o(i1) = i(i1)

 end subroutine aloct_copy_4

 subroutine test2(o, i)

  character(len=*) :: o, i

  integer :: nl1, nu1

  integer :: i1

  nl1 = 2

  nu1 = 4

  forall (i1 = nl1:nu1) o(i1:i1) = i(i1:i1)

  forall (i1 = nl1:nu1) o(i1:i1) = o(nu1+1-i1:nu1+1-i1)

 end subroutine test2

 subroutine test2p(o, i)

  character(len=*), pointer :: o, i

  integer :: nl1, nu1

  integer :: i1

  nl1 = 2

  nu1 = 4

  forall (i1 = nl1:nu1) o(i1:i1) = i(i1:i1)   !  ICE

  forall (i1 = nl1:nu1) o(i1:i1) = o(nu1+1-i1:nu1+1-i1)

 end subroutine test2p

end

[Bug fortran/37336] Fortran 2003: Finish derived-type finalization

[janus at gcc dot gnu.org]

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



--- Comment #13 from janus at gcc dot gnu.org 2012-10-26 16:47:08 UTC ---

Latest patch at: http://gcc.gnu.org/ml/fortran/2012-10/msg00126.html



This patch compiles the test case in comment 6 without errors, but the

finalizer is not called.



However, when changing the main program to ...



program main

  use child_module

  implicit none

  class(child),allocatable :: infant

  allocate(infant,source=new_child())

end



... the finalizer is called twice: Once at the end of the main program, and

once through the _copy procedure (which is invoked by the ALLOCATE statement),

I think. Not sure if this is the expected behavior.



If the "class(child)" here is changed to "type(child)", no finalization is done

(and in fact not even a finalization routine is generated for the type

'child').

But certainly it should, just as for the original test case in comment 6.

[Bug web/54973] [bugzilla] make "Before reporting a bug" notice more prominent

[pinskia at gcc dot gnu.org]

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



--- Comment #13 from Andrew Pinski  2012-10-26 
16:48:05 UTC ---

(In reply to comment #12)

> Click the URL link above to see how it looks like. The change has already been

> applied to GCC Bugzilla.



Is there any way to make the text red rather than yellowish?  I am having a

hard time to focus on the text.

[Bug middle-end/37448] gcc 4.3.1 cannot compile big function

[hubicka at gcc dot gnu.org]

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



--- Comment #48 from Jan Hubicka  2012-10-26 
16:48:08 UTC ---

The problem here is walking of callgraph edges to sum the code size of the

caller function in both early inliner and late inliner. I am still not very

keen on making the cost calucuations incremental, but I will see if keeping the

sum of all edges makes sense here...



Honza

[Bug c++/55076] ice when compiling lambda function

[markus at trippelsdorf dot de]

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

--- Comment #7 from Markus Trippelsdorf  
2012-10-26 16:48:46 UTC ---
What about the following naïve patch? 
At least it fixes the problem and causes no new test suite regressions.

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 8d555c2..0f1a75d 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -145,7 +145,7 @@ lvalue_kind (const_tree ref)
 case ARRAY_REF:
 case PARM_DECL:
 case RESULT_DECL:
-  if (TREE_CODE (TREE_TYPE (ref)) != METHOD_TYPE)
+  if (TREE_TYPE (ref) && TREE_CODE (TREE_TYPE (ref)) != METHOD_TYPE)
return clk_ordinary;
   break;

[Bug web/54973] [bugzilla] make "Before reporting a bug" notice more prominent

[redi at gcc dot gnu.org]

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



--- Comment #14 from Jonathan Wakely  2012-10-26 
16:52:40 UTC ---

That looks great to me (I was just being lazy reusing the existing FIELDSET

style)



Thanks for doing this!

[Bug tree-optimization/35357] Loop peeling not happening

[xinliangli at gmail dot com]

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



--- Comment #2 from davidxl  2012-10-26 16:55:48 
UTC ---

(In reply to comment #1)

> What is the expected optimization and what is its benefit?



Should be transformed into the following the simplified loop body.

void foo(int n)

{

  int i;



  if (n > 0) {

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

{

   b[i*2] = a[3*i+1];

   b[i*2] +=1; 

}

b[i*2] = a[3*i + 1];

  }

}



Icc at O2 distributes the loop body:



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

  {

   b[i*2] = a[3*i+1]; 

  }

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

  {

   b[i*2] += 1; 

  }

[Bug web/54973] [bugzilla] make "Before reporting a bug" notice more prominent

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #15 from Frédéric Buclin  2012-10-26 
16:57:59 UTC ---
The text is now a bit more reddish. Fixed!

[Bug c++/55082] c++11: default member constructor

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #1 from Daniel Krügler  
2012-10-26 17:24:35 UTC ---
This is no compiler defect: The A constructor is explicit and won't be
considered within a copy-initialization context. You need a
direct-initialization context like the one that works. This is completely
analog to a rewrite of your main code as

B b = 1; // error: conversion from 'int' to non-scalar type 'B' requested

This issue is invalid.

[Bug middle-end/37448] gcc 4.3.1 cannot compile big function

[steven at gcc dot gnu.org]

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



Steven Bosscher  changed:



   What|Removed |Added



 CC||steven at gcc dot gnu.org



--- Comment #49 from Steven Bosscher  2012-10-26 
17:28:58 UTC ---

(In reply to comment #47)

> Hmm, good timming. I just started looking into re-tunning inliner 

> heuristics for 4.8 so I should look again into this inline bomb... 

> Looks like inliner did not get faster ;)



While everything else did get faster. Much of the work from PR54146 also

helps for this PR. But the inliner heuristics are even more insane than

this test case.



What are the reasons for your aversion against incrementally updating

the inliner heuristics?

[Bug target/55061] libbacktrace build fails during bootstrap on powerpc-apple-darwin9

[ian at gcc dot gnu.org]

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



--- Comment #26 from ian at gcc dot gnu.org  2012-10-26 
17:35:04 UTC ---

Author: ian

Date: Fri Oct 26 17:34:59 2012

New Revision: 192853



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

Log:

PR target/55061

* configure.ac: Check for _Unwind_GetIPInfo function declaration.

* configure: Regenerate.



Modified:

trunk/libbacktrace/ChangeLog

trunk/libbacktrace/configure

trunk/libbacktrace/configure.ac

[Bug c++/55082] c++11: default member constructor

[redi at gcc dot gnu.org]

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



Jonathan Wakely  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||INVALID



--- Comment #2 from Jonathan Wakely  2012-10-26 
17:39:37 UTC ---

Daniel's correct, invalid

[Bug c++/54955] alignas example in gcc 4.8 changes.html won't compile

[dodji at seketeli dot org]

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



--- Comment #5 from dodji at seketeli dot org  
2012-10-26 17:42:44 UTC ---

> --- Comment #4 from Paolo Carlini  
> 2012-10-26 13:31:33 UTC ---

>

> Thanks Dodji!



You are welcome.  :)



A candidate patch was proposed at

http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02439.html

[Bug target/55061] libbacktrace build fails during bootstrap on powerpc-apple-darwin9

[ian at airs dot com]

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



Ian Lance Taylor  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #27 from Ian Lance Taylor  2012-10-26 17:52:06 
UTC ---

This time for sure.

[Bug c++/54875] Forward declare enums cannot be used as a template argument

[dodji at gcc dot gnu.org]

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



Dodji Seketeli  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2012-10-26

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

   |gnu.org |

 Ever Confirmed|0   |1

[Bug debug/54970] Missing DW_OP_GNU_implicit_pointer in debuginfo

[jakub at gcc dot gnu.org]

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



--- Comment #3 from Jakub Jelinek  2012-10-26 
19:19:30 UTC ---

Author: jakub

Date: Fri Oct 26 19:19:25 2012

New Revision: 192860



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

Log:

PR debug/54970

* cfgexpand.c (expand_debug_expr): Expand &MEM_REF[&var, n]

as DEBUG_IMPLICIT_PTR + n if &var expands to DEBUG_IMPLICIT_PTR.

* tree-sra.c (create_access_replacement): Allow also MEM_REFs

with ADDR_EXPR first operand in DECL_DEBUG_EXPR expressions.

* var-tracking.c (track_expr_p): Handle MEM_REFs in DECL_DEBUG_EXPR

expressions.

* dwarf2out.c (add_var_loc_to_decl): Likewise.



PR debug/54971

* gcc.dg/guality/pr54970.c: New test.



Added:

trunk/gcc/testsuite/gcc.dg/guality/pr54970.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/cfgexpand.c

trunk/gcc/dwarf2out.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-sra.c

trunk/gcc/var-tracking.c

[Bug debug/54971] SRA pessimizes debug info by not creating debug stmts for fields without replacements

[jakub at gcc dot gnu.org]

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



--- Comment #11 from Jakub Jelinek  2012-10-26 
19:19:30 UTC ---

Author: jakub

Date: Fri Oct 26 19:19:25 2012

New Revision: 192860



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

Log:

PR debug/54970

* cfgexpand.c (expand_debug_expr): Expand &MEM_REF[&var, n]

as DEBUG_IMPLICIT_PTR + n if &var expands to DEBUG_IMPLICIT_PTR.

* tree-sra.c (create_access_replacement): Allow also MEM_REFs

with ADDR_EXPR first operand in DECL_DEBUG_EXPR expressions.

* var-tracking.c (track_expr_p): Handle MEM_REFs in DECL_DEBUG_EXPR

expressions.

* dwarf2out.c (add_var_loc_to_decl): Likewise.



PR debug/54971

* gcc.dg/guality/pr54970.c: New test.



Added:

trunk/gcc/testsuite/gcc.dg/guality/pr54970.c

Modified:

trunk/gcc/ChangeLog

trunk/gcc/cfgexpand.c

trunk/gcc/dwarf2out.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/tree-sra.c

trunk/gcc/var-tracking.c

[Bug rtl-optimization/55010] Internal consistency failure : invalid rtl sharing found in the insn

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

   Target Milestone|--- |4.8.0



--- Comment #3 from Jakub Jelinek  2012-10-26 
19:24:29 UTC ---

Fixed.

[Bug other/55087] New: bogus "linux-vdso.so.1: No such file or directory" caused by libbacktrace

[markus at trippelsdorf dot de]

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



 Bug #: 55087

   Summary: bogus "linux-vdso.so.1: No such file or directory"

caused by libbacktrace

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: other

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

ReportedBy: mar...@trippelsdorf.de





With r192267 a superfluous "linux-vdso.so.1: No such file or directory"

error message appears whenever the compiler crashes. 



For example:

test.ii: In lambda function:

test.ii:7:28: internal compiler error: Segmentation fault

 ([=] { src_new (con); });

^

linux-vdso.so.1: No such file or directory

Please submit a full bug report,



1bfb5d87e5e2589cb18ef7f35da012b308ff78bf is the first bad commit

commit 1bfb5d87e5e2589cb18ef7f35da012b308ff78bf

Author: ian 

Date:   Tue Oct 9 18:20:45 2012 +



Add support for tracing through shared librarie

[Bug other/55087] bogus "linux-vdso.so.1: No such file or directory" caused by libbacktrace

[ian at airs dot com]

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



Ian Lance Taylor  changed:



   What|Removed |Added



 CC||ian at airs dot com



--- Comment #1 from Ian Lance Taylor  2012-10-26 19:53:13 
UTC ---

What system are you running on?



How did you build GCC?

[Bug other/55087] bogus "linux-vdso.so.1: No such file or directory" caused by libbacktrace

[markus at trippelsdorf dot de]

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



--- Comment #2 from Markus Trippelsdorf  
2012-10-26 19:55:16 UTC ---

(In reply to comment #1)

> What system are you running on?

> 

> How did you build GCC?



Linux x86_64.



~/gcc/configure --disable-werror --disable-multilib --enable-languages=c,c++

make -j4

[Bug other/55087] bogus "linux-vdso.so.1: No such file or directory" caused by libbacktrace

[ian at gcc dot gnu.org]

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



--- Comment #3 from ian at gcc dot gnu.org  2012-10-26 
20:08:34 UTC ---

Author: ian

Date: Fri Oct 26 20:08:29 2012

New Revision: 192861



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

Log:

PR other/55087

* posix.c (backtrace_open): Add does_not_exist parameter.

* elf.c (phdr_callback): Do not warn if shared library could not

be opened.

* fileline.c (fileline_initialize): Update calls to

backtrace_open.

* internal.h (backtrace_open): Update declaration.



Modified:

trunk/libbacktrace/ChangeLog

trunk/libbacktrace/elf.c

trunk/libbacktrace/fileline.c

trunk/libbacktrace/internal.h

trunk/libbacktrace/posix.c

[Bug other/55087] bogus "linux-vdso.so.1: No such file or directory" caused by libbacktrace

[ian at airs dot com]

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



Ian Lance Taylor  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #4 from Ian Lance Taylor  2012-10-26 20:09:31 
UTC ---

Probably fixed.  Please reopen if not.

[Bug target/54255] FAIL: gcc.target/i386/asm-dialect-1.c (test for excess errors) fails on x86_64/i686 darwin

[howarth at nitro dot med.uc.edu]

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



--- Comment #3 from Jack Howarth  2012-10-26 
20:18:05 UTC ---

Posted a general fix for all older assembler that lack -masm=intel support...



http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02448.html

[Bug other/55087] bogus "linux-vdso.so.1: No such file or directory" caused by libbacktrace

[markus at trippelsdorf dot de]

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



Markus Trippelsdorf  changed:



   What|Removed |Added



 Status|RESOLVED|UNCONFIRMED

 Resolution|FIXED   |



--- Comment #5 from Markus Trippelsdorf  
2012-10-26 20:25:51 UTC ---

Thanks for the quick fix, Ian. The problem has gone.



The message probably only occurs on a system with a fairly recent

version of glibc. (I'm running glibc trunk from last week)

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

[hp at gcc dot gnu.org]

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



Hans-Peter Nilsson  changed:



   What|Removed |Added



 CC||hp at gcc dot gnu.org



--- Comment #1 from Hans-Peter Nilsson  2012-10-26 
20:30:09 UTC ---

Yeah cris-elf too, range 192820:192824, likely universal except for one

platform...

[Bug c++/55081] [4.8 regression?] Non-optimized static array elements initialization

[jakub at gcc dot gnu.org]

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



--- Comment #5 from Jakub Jelinek  2012-10-26 
20:30:39 UTC ---

Author: jakub

Date: Fri Oct 26 20:30:35 2012

New Revision: 192862



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

Log:

PR c++/55081

* typeck2.c (store_init_value): Call fold_non_dependent_expr

and maybe_constant_init even for C++98.



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



Added:

trunk/gcc/testsuite/g++.dg/opt/pr55081.C

Modified:

trunk/gcc/cp/ChangeLog

trunk/gcc/cp/typeck2.c

trunk/gcc/testsuite/ChangeLog

[Bug c++/55081] [4.8 Regression] Non-optimized static array elements initialization

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED

Summary|[4.8 regression?]   |[4.8 Regression]

   |Non-optimized static array  |Non-optimized static array

   |elements initialization |elements initialization



--- Comment #6 from Jakub Jelinek  2012-10-26 
20:31:43 UTC ---

Fixed.

[Bug other/55087] bogus "linux-vdso.so.1: No such file or directory" caused by libbacktrace

[ian at airs dot com]

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



Ian Lance Taylor  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED



--- Comment #6 from Ian Lance Taylor  2012-10-26 20:34:45 
UTC ---

Marking as fixed again.

[Bug ada/55088] New: ada tarball missing COPYING file

[sudoman at ninthfloor dot org]

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



 Bug #: 55088

   Summary: ada tarball missing COPYING file

Classification: Unclassified

   Product: gcc

   Version: 4.6.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: ada

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

ReportedBy: sudo...@ninthfloor.org





the ada-specific tarball i checked is missing the COPYING file. the one i

checked is this one:



ftp://ftp.gnu.org/gnu/gcc/gcc-4.6.3/gcc-ada-4.6.3.tar.gz



i'm guessing other versions, and other subprojects may have this issue as well.

[Bug bootstrap/55089] New: ICE in varasm.c during bootstrap-lean on x86_64-pc-solaris2.10

[Tim.Mooney at ndsu dot edu]

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



 Bug #: 55089

   Summary: ICE in varasm.c during bootstrap-lean on

x86_64-pc-solaris2.10

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: blocker

  Priority: P3

 Component: bootstrap

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

ReportedBy: tim.moo...@ndsu.edu





Created attachment 28539

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

config.log from libgcc directory, where ICE occurs



I'm attempting to build gcc 4.7.2 on x86_64-sun-solaris2.10.  I'm using the

Oracle Studio 12.3 compiler suite to build the initial xgcc.  Relevant settings

are



CC="cc -m64"

CFLAGS=-m64

export CC 

CPPFLAGS="-I/local/gnu/include -I/local/include"

CFLAGS="-m64 -I/local/gnu/include -I/local/include"

LDFLAGS="-m64 -L/local/gnu/lib/64 -L/local/lib/64"

export CPPFLAGS CFLAGS LDFLAGS



BOOT_CFLAGS="-O -g"

export BOOT_CFLAGS



The build proceeds to where configure outputs



gmake[3]: Leaving directory `/local/src/RPM/BUILD/gcc-4.7.2-obj/gcc'

mkdir x86_64-pc-solaris2.10/libgcc

Checking multilib configuration for libgcc...

Configuring stage 1 in x86_64-pc-solaris2.10/libgcc

configure: creating cache ./config.cache

checking build system type... x86_64-pc-solaris2.10

checking host system type... x86_64-pc-solaris2.10

checking for --enable-version-specific-runtime-libs... no

checking for a BSD-compatible install... /local/gnu/bin/ginstall -c

checking for gawk... nawk

checking for x86_64-pc-solaris2.10-ar... ar

checking for x86_64-pc-solaris2.10-lipo... lipo

checking for x86_64-pc-solaris2.10-nm...

/local/src/RPM/BUILD/gcc-4.7.2-obj/./gc

c/nm

checking for x86_64-pc-solaris2.10-ranlib... ranlib

checking for x86_64-pc-solaris2.10-strip... strip

checking whether ln -s works... yes

checking for x86_64-pc-solaris2.10-gcc...

/local/src/RPM/BUILD/gcc-4.7.2-obj/./g

cc/xgcc -B/local/src/RPM/BUILD/gcc-4.7.2-obj/./gcc/

-B/local/gnu/x86_64-pc-solar

is2.10/bin/ -B/local/gnu/x86_64-pc-solaris2.10/lib/ -isystem

/local/gnu/x86_64-p

c-solaris2.10/include -isystem /local/gnu/x86_64-pc-solaris2.10/sys-include   

checking for suffix of object files... configure: error: in

`/local/src/RPM/BUIL

D/gcc-4.7.2-obj/x86_64-pc-solaris2.10/libgcc':

configure: error: cannot compute suffix of object files: cannot compile

See `config.log' for more details.





Examining

/local/src/RPM/BUILD/gcc-4.7.2-obj/x86_64-pc-solaris2.10/libgcc/config.log I

see



Thread model: posix

gcc version 4.7.2 (GCC)

configure:3355: $? = 0

configure:3344: /local/src/RPM/BUILD/gcc-4.7.2-obj/./gcc/xgcc

-B/local/src/RPM/BUILD/gcc-4.7.2-obj/./gcc/

-B/local/gnu/x86_64-pc-solaris2.10/bin/ -B/local/gnu/x86_64-pc-solaris2.10/lib/

-isystem /local/gnu/x86_64-pc-solaris2.10/include -isystem

/local/gnu/x86_64-pc-solaris2.10/sys-include-V >&5

xgcc: error: unrecognized command line option '-V'

xgcc: fatal error: no input files

compilation terminated.

configure:3355: $? = 1

configure:3344: /local/src/RPM/BUILD/gcc-4.7.2-obj/./gcc/xgcc

-B/local/src/RPM/BUILD/gcc-4.7.2-obj/./gcc/

-B/local/gnu/x86_64-pc-solaris2.10/bin/ -B/local/gnu/x86_64-pc-solaris2.10/lib/

-isystem /local/gnu/x86_64-pc-solaris2.10/include -isystem

/local/gnu/x86_64-pc-solaris2.10/sys-include-qversion >&5

xgcc: error: unrecognized command line option '-qversion'

xgcc: fatal error: no input files

compilation terminated.

configure:3355: $? = 1

configure:3371: /local/src/RPM/BUILD/gcc-4.7.2-obj/./gcc/xgcc

-B/local/src/RPM/BUILD/gcc-4.7.2-obj/./gcc/

-B/local/gnu/x86_64-pc-solaris2.10/bin/ -B/local/gnu/x86_64-pc-solaris2.10/lib/

-isystem /local/gnu/x86_64-pc-solaris2.10/include -isystem

/local/gnu/x86_64-pc-solaris2.10/sys-include-o conftest -g -m64

-I/local/gnu/include -I/local/include   conftest.c  >&5

conftest.c:16:1: internal compiler error: in ?, at varasm.c:2555

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

configure:3374: $? = 1

configure:3562: checking for suffix of object files

configure:3584: /local/src/RPM/BUILD/gcc-4.7.2-obj/./gcc/xgcc

-B/local/src/RPM/BUILD/gcc-4.7.2-obj/./gcc/

-B/local/gnu/x86_64-pc-solaris2.10/bin/ -B/local/gnu/x86_64-pc-solaris2.10/lib/

-isystem /local/gnu/x86_64-pc-solaris2.10/include -isystem

/local/gnu/x86_64-pc-solaris2.10/sys-include-c -g -m64 -I/local/gnu/include

-I/local/include  conftest.c >&5

conftest.c:16:1: internal compiler error: in ?, at varasm.c:2555

Please submit a full bug report,

with preprocessed source if appropriate.



I'm attaching two files; the entire log of what configure output from the

beginning, and the config.log from the libgcc directory.



Note that it's been quite a while since I last built gcc, so it's entirely

possible that something I'm doing is no longer the recommended

[Bug bootstrap/55089] ICE in varasm.c during bootstrap-lean on x86_64-pc-solaris2.10

[Tim.Mooney at ndsu dot edu]

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



--- Comment #1 from Tim Mooney  2012-10-26 21:12:20 
UTC ---

Created attachment 28540

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

output from the rpmbuild that was run to configure gcc



I use rpmbuild to package local software.  This attachment has the complete

output from running the rpmbuild command.  It's mainly useful because it shows

the important environment settings and all of the configure and compilation

output, up to the failure in libgcc.

[Bug middle-end/55090] New: [4.8 regression] ICE in inline_call, at ipa-inline-transform.c:269

[sch...@linux-m68k.org]

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



 Bug #: 55090

   Summary: [4.8 regression]  ICE in inline_call, at

ipa-inline-transform.c:269

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Keywords: ice-on-valid-code

  Severity: normal

  Priority: P3

 Component: middle-end

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

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

CC: hubi...@gcc.gnu.org

Target: m68k-*-*





$ gcc/g++ -Bgcc/ ../gcc/gcc/testsuite/g++.dg/torture/pr46154.C

-fno-diagnostics-show-caret -O2 -fipa-cp-clone -S -o pr46154.s

../gcc/gcc/testsuite/g++.dg/torture/pr46154.C:17:1: internal compiler error: in

inline_call, at ipa-inline-transform.c:269

linux-vdso.so.1: No such file or directory

0xcef787 inline_call(cgraph_edge*, bool, vec_t**, int*, bool)

../../gcc/gcc/ipa-inline-transform.c:265

0xcee28b inline_small_functions

../../gcc/gcc/ipa-inline.c:1524

0xcee28b ipa_inline

../../gcc/gcc/ipa-inline.c:1706



Introduced by r192821.

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

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 CC||sch...@linux-m68k.org



--- Comment #2 from Dominique d'Humieres  2012-10-26 
21:22:34 UTC ---

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

[Bug middle-end/55090] [4.8 regression] ICE in inline_call, at ipa-inline-transform.c:269

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #1 from Dominique d'Humieres  2012-10-26 
21:22:34 UTC ---

Dup of 55078.



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

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

[dominiq at lps dot ens.fr]

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



Dominique d'Humieres  changed:



   What|Removed |Added



 Status|UNCONFIRMED |NEW

   Last reconfirmed||2012-10-26

 Ever Confirmed|0   |1

[Bug bootstrap/55089] ICE in varasm.c during bootstrap-lean on x86_64-pc-solaris2.10

[Tim.Mooney at ndsu dot edu]

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



--- Comment #2 from Tim Mooney  2012-10-26 21:42:39 
UTC ---

I just tried the older 4.7.0 and the same error happens, though the line number

in varasm.c is slightly different:



configure:3625: checking for suffix of object files

configure:3647: /local/src/RPM/BUILD/gcc-4.7.0-obj/./gcc/xgcc

-B/local/src/RPM/BUILD/gcc-4.7.0-obj/./gcc/

-B/local/gnu/x86_64-pc-solaris2.10/bin/ -B/local/gnu/x86_64-pc-solaris2.10/lib/

-isystem /local/gnu/x86_64-pc-solaris2.10/include -isystem

/local/gnu/x86_64-pc-solaris2.10/sys-include-c -g -m64 -I/local/gnu/include

-I/local/include  conftest.c >&5

conftest.c:16:1: internal compiler error: in ?, at varasm.c:2528

[Bug go/55091] New: libgo testsuite doesn't support --target_board='unix{-mx32}'

[hjl.tools at gmail dot com]

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



 Bug #: 55091

   Summary: libgo testsuite doesn't support

--target_board='unix{-mx32}'

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: go

AssignedTo: i...@airs.com

ReportedBy: hjl.to...@gmail.com





My Linux/x86-64 GCC supports -m32, -m64 and -mx32. I am using



# make check RUNTESTFLAGS="--target_board='unix{-mx32}'"



to only run -mx32 test.  But libgo runs all 3 -m32, -m64 and -mx32

tests, instead of just -mx32.