[Bug ada/55088] ada tarball missing COPYING file

[pinskia at gcc dot gnu.org]

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



--- Comment #1 from Andrew Pinski  2012-10-27 
06:42:10 UTC ---

The language specific tar balls are no longer produced.  I don't know if we

should close this bug as fixed or won't fix.

[Bug debug/55094] New: [4.7/4.8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2224

[d.g.gorbachev at gmail dot com]

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



 Bug #: 55094

   Summary: [4.7/4.8 Regression] ICE in maybe_record_trace_start,

at dwarf2cfi.c:2224

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: debug

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

ReportedBy: d.g.gorbac...@gmail.com





GCC 4.8, i686-pc-linux-gnu. Also happens in 4.7 configured with checking.



Compile this with `-g -Os -fomit-frame-pointer -fno-asynchronous-unwind-tables

-mpreferred-stack-boundary=2':



== 8< ==

extern int puts(const char *s);



int main(int argc, char **argv)

{

  if (argc) {

puts(argv[0]);

__builtin_trap();

  }

  __builtin_trap();

}

== >8 ==



1.c: In function 'main':

1.c:10:1: internal compiler error: in maybe_record_trace_start, at

dwarf2cfi.c:2224

 }

 ^

0x82cf181 maybe_record_trace_start

../../gcc-4.8/gcc/dwarf2cfi.c:2224

0x82cf56b scan_trace

../../gcc-4.8/gcc/dwarf2cfi.c:2401

0x82cf9cd create_cfi_notes

../../gcc-4.8/gcc/dwarf2cfi.c:2556

0x82cfcfa execute_dwarf2_frame

../../gcc-4.8/gcc/dwarf2cfi.c:2915

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.

[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 #17 from Andrew Pinski  2012-10-27 
00:57:11 UTC ---

(In reply to comment #15)

> The text is now a bit more reddish. Fixed!



Thanks that is much better and thanks again for adding this text.

[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



--- Comment #16 from Ian Lance Taylor  2012-10-27 00:55:14 
UTC ---

Thanks!

[Bug rtl-optimization/55093] [4.8 Regression] [x32] -maddress-mode=long failed

[hjl.tools at gmail dot com]

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



--- Comment #2 from H.J. Lu  2012-10-27 00:19:22 
UTC ---

Another zero-extend bug?



Breakpoint 1, fancy_abort (

file=0x146ea68 "/export/gnu/import/git/gcc-misc/gcc/config/i386/i386.c", 

line=14088, 

function=0x14879e3 

"print_reg") at /export/gnu/import/git/gcc-misc/gcc/diagnostic.c:1143

1143  internal_error ("in %s, at %s:%d", function, trim_filename (file),

line);

(gdb) f 1

#1  0x00f4fbde in print_reg (x=0xf5131168, code=113, file=0x1a13da0)

at /export/gnu/import/git/gcc-misc/gcc/config/i386/i386.c:14083

14083  gcc_assert (x == pc_rtx

(gdb) call debug_rtx (x)

(reg:SI 16 argp)

(gdb) f 2

#2  0x00f51f64 in ix86_print_operand_address (file=0x1a13da0, addr=0xf5138bd0)

at /export/gnu/import/git/gcc-misc/gcc/config/i386/i386.c:15046

15046print_reg (base, code, file);

(gdb) call debug_rtx (addr)

(unspec:DI [

(zero_extend:DI (plus:SI (reg:SI 16 argp)

(const_int 68 [0x44])))

] UNSPEC_LEA_ADDR)

(gdb)

[Bug rtl-optimization/55093] [4.8 Regression] [x32] -maddress-mode=long failed

[hjl.tools at gmail dot com]

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



--- Comment #1 from H.J. Lu  2012-10-27 00:16:52 
UTC ---

Created attachment 28541

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

A testcase

[Bug rtl-optimization/55093] New: [4.8 Regression] [x32] -maddress-mode=long failed

[hjl.tools at gmail dot com]

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

 Bug #: 55093
   Summary: [4.8 Regression] [x32] -maddress-mode=long failed
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com, vmaka...@redhat.com


LRA caused -maddress-mode=long to fail:

[hjl@gnu-tools-1 gcc]$ ../prev-gcc/xgcc -B../prev-gcc/ -mx32 -O2 -S /tmp/x.ii
-maddress-mode=long
/tmp/x.ii: In function ‘bool set_lattice_value(tree, prop_value_t)’:
/tmp/x.ii:25385:1: internal compiler error: in print_reg, at
config/i386/i386.c:14088
 }
 ^
0xf4fbdd print_reg(rtx_def*, int, _IO_FILE*)
/export/gnu/import/git/gcc-misc/gcc/config/i386/i386.c:14083
0xf51f63 ix86_print_operand_address
/export/gnu/import/git/gcc-misc/gcc/config/i386/i386.c:15046
0x976edd output_address(rtx_def*)
/export/gnu/import/git/gcc-misc/gcc/final.c:3709
0xf503ad ix86_print_operand(_IO_FILE*, rtx_def*, int)
/export/gnu/import/git/gcc-misc/gcc/config/i386/i386.c:14317
0x976e6f output_operand(rtx_def*, int)
/export/gnu/import/git/gcc-misc/gcc/final.c:3693
0x976a02 output_asm_insn(char const*, rtx_def**)
/export/gnu/import/git/gcc-misc/gcc/final.c:3572
0x975678 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
/export/gnu/import/git/gcc-misc/gcc/final.c:2890
0x973b53 final(rtx_def*, _IO_FILE*, int)
/export/gnu/import/git/gcc-misc/gcc/final.c:1919
0x9782c7 rest_of_handle_final
/export/gnu/import/git/gcc-misc/gcc/final.c:4321
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-tools-1 gcc]$

[Bug go/55091] 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



--- Comment #1 from H.J. Lu  2012-10-27 00:01:11 
UTC ---

One can also use RUNTESTFLAGS="--target_board='unix{-mavx}'"

to test -mavx.  I am not sure if libgo supports it.

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

[paolo.carlini at oracle dot com]

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



--- Comment #8 from Paolo Carlini  2012-10-26 
23:38:33 UTC ---

I think that at some point I had the same trick in my local tree too, then I

don't remember sending it to the mailing list, not even as a RFC. I think you

should, CC Jason, and ask whether is it possible that at that point TREE_TYPE

is not set or the check would just paper over the real issue.

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

[vmakarov at redhat dot com]

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



Vladimir Makarov  changed:



   What|Removed |Added



 CC||vmakarov at redhat dot com



--- Comment #5 from Vladimir Makarov  2012-10-26 
23:06:44 UTC ---

Ok, I'll try to find a reason for this slow down.

[Bug rtl-optimization/55092] [4.8 Regression] LRA doesn't scale

[hjl.tools at gmail dot com]

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



--- Comment #5 from H.J. Lu  2012-10-26 23:03:05 
UTC ---

-fno-ira-share-spill-slots doesn't make a difference.

[Bug rtl-optimization/55092] [4.8 Regression] LRA doesn't scale

[vmakarov at redhat dot com]

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



--- Comment #4 from Vladimir Makarov  2012-10-26 
22:57:38 UTC ---

(In reply to comment #2)

>  LRA reuses stack memory much better than reload (in all modes but especially

> in -O0).  May be that is the reason of the var-tracking problem.



I forgot to say that LRA understands -fno-ira-share-spill-slots.  In this case,

 each pseudo gets own stack slot.



I thing it is worth to try it.

[Bug rtl-optimization/55092] [4.8 Regression] LRA doesn't scale

[hjl.tools at gmail dot com]

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



--- Comment #3 from H.J. Lu  2012-10-26 22:56:55 
UTC ---

The testcase is compiled with -O2, not -O0.

[Bug rtl-optimization/55092] [4.8 Regression] LRA doesn't scale

[vmakarov at redhat dot com]

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



--- Comment #2 from Vladimir Makarov  2012-10-26 
22:49:23 UTC ---

 LRA reuses stack memory much better than reload (in all modes but especially

in -O0).  May be that is the reason of the var-tracking problem.

[Bug rtl-optimization/55092] [4.8 Regression] LRA doesn't scale

[jakub at gcc dot gnu.org]

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



Jakub Jelinek  changed:



   What|Removed |Added



 CC||jakub at gcc dot gnu.org



--- Comment #1 from Jakub Jelinek  2012-10-26 
22:13:09 UTC ---

It isn't LRA that doesn't scale, it is var-tracking memory clobbering that

needs improvements, but it would be nice to analyze what are the changes that

LRA does compared to reload that make var-tracking to take that much longer and

whether the generated code is better or worse.  If it is better, this is just

PR54402 dup.

[Bug rtl-optimization/55092] New: [4.8 Regression] LRA doesn't scale

[hjl.tools at gmail dot com]

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



 Bug #: 55092

   Summary: [4.8 Regression] LRA doesn't scale

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

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

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

CC: vmaka...@redhat.com





From



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



-

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.

-



It only happens with -m32.  It takes less than 20 seconds for

-m64 and -mx32. Turn-off LRA takes only 13 seconds to finish.

[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.

[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 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 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



 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] 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 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 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 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 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 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 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 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 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 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

[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 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

[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 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] 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 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 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 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 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 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++/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 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 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 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 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 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 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

[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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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

[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 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 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 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++/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 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/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/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++/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++/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 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++/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 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++/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 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++/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 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++/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

[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++/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

[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++/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++/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++/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++/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 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 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 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

[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 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/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 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 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.