[Bug c++/53570] New: Unused symbols are not removed for fully static targets (avr-gcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53570 Bug #: 53570 Summary: Unused symbols are not removed for fully static targets (avr-gcc) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jwa...@gmail.com Using built-in specs. COLLECT_GCC=avr-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.0/lto-wrapper Target: avr Configured with: /build/src/gcc-4.7.0/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,c++ --disable-libssp --disable-nls --target=avr --with-as=/usr/bin/avr-as --with-ld=/usr/bin/avr-ld --with-gnu-as --with-gnu-ld Thread model: single gcc version 4.7.0 (GCC) This is a problem report for how the linker is not smart enough to remove unused functions, even with -Os. This makes it very hard to create libraries of functions where only some functions may be used in any particular binary. Note: r option to ar is passed in, so the linker should have all the symbol information it needs to make the determination. See the attached test program, especially the lib.cpp file. There is nothing in the C++ standard that requires the compiler or linker to include the not_called symbol, or the some_large_function symbol, when they are not used. On a small target like the AVR, including those symbols is too wasteful. To reproduce: - untar this archive - run ./make.sh - avr-objdump --disassemble main, and find the unused symbols still included
[Bug c++/53570] Unused symbols are not removed for fully static targets (avr-gcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53570 --- Comment #1 from jwatte at gmail dot com 2012-06-04 07:08:03 UTC --- Created attachment 27551 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27551 Reproduction case (gzipped tar archive)
[Bug tree-optimization/53571] New: [4.6/4.7/4.8 regression] ICE with -O{2,3} -floop-parallelize-all in cloog_domain_stride()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53571
Bug #: 53571
Summary: [4.6/4.7/4.8 regression] ICE with -O{2,3}
-floop-parallelize-all in cloog_domain_stride()
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xarthisius...@gmail.com
Created attachment 27552
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27552
reduced testcase
0x77bcc1d5 in cloog_domain_stride () from /usr/lib64/libcloog.so.0
(gdb) bt
#0 0x77bcc1d5 in cloog_domain_stride () from /usr/lib64/libcloog.so.0
#1 0x77bc1ecf in ?? () from /usr/lib64/libcloog.so.0
#2 0x77bc171b in cloog_loop_generate () from /usr/lib64/libcloog.so.0
#3 0x77bd2f69 in cloog_program_generate () from
/usr/lib64/libcloog.so.0
#4 0x00d593ec in scop_to_clast ()
#5 0x00d5961e in gloog ()
#6 0x00d55763 in graphite_transform_loops ()
#7 0x0091a269 in graphite_transforms ()
#8 0x00759059 in execute_one_pass ()
#9 0x00759233 in execute_pass_list ()
#10 0x00759254 in execute_pass_list ()
#11 0x00759254 in execute_pass_list ()
#12 0x00759254 in execute_pass_list ()
#13 0x0088eae1 in tree_rest_of_compilation ()
#14 0x00a49d0b in cgraph_expand_function ()
#15 0x00a49eca in cgraph_expand_all_functions ()
#16 0x00a4a533 in cgraph_optimize ()
#17 0x00a48b22 in cgraph_finalize_compilation_unit ()
#18 0x0049de30 in c_write_global_declarations ()
#19 0x0083006e in compile_file ()
#20 0x00832000 in do_compile ()
#21 0x00832146 in toplev_main ()
#22 0x00521118 in main ()
Downstream bug: https://bugs.gentoo.org/show_bug.cgi?id=361953
[Bug c++/51494] Legal program rejection - capturing this when using static method inside lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51494
gcc-bugx at mailinator dot com changed:
What|Removed |Added
CC||gcc-bugx at mailinator dot
||com
--- Comment #4 from gcc-bugx at mailinator dot com 2012-06-04 08:21:54 UTC ---
Probably related error: this capture ignored on explicit instantiation.
8---
struct A
{
static void f() {}
template typename T
void foo()
{
[this] () { f(); };
}
};
template void A::fooint();
8---
Compiler version output:
$ g++ -std=c++11 -c -v y.cc
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --prefix=/home/x
Thread model: posix
gcc version 4.7.0 (GCC)
COLLECT_GCC_OPTIONS='-std=c++11' '-c' '-v' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/home/x/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/cc1plus -quiet -v
-D_GNU_SOURCE y.cc -quiet -dumpbase y.cc -mtune=generic -march=x86-64 -auxbase
y -std=c++11 -version -o /tmp/ccdFvfri.s
GNU C++ (GCC) version 4.7.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.0, GMP version 4.3.2, MPFR version
3.0.0-p8, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
/home/x/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/home/x/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0
/home/x/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/x86_64-unknown-linux-gnu
/home/x/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/backward
/home/x/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include
/usr/local/include
/home/x/include
/home/x/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include-fixed
/usr/include
End of search list.
GNU C++ (GCC) version 4.7.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.0, GMP version 4.3.2, MPFR version
3.0.0-p8, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: ...
y.cc: In instantiation of ‘A::foo() [with T = int]::lambda()’:
y.cc:8:4: required from ‘struct A::foo() [with T = int]::lambda()’
y.cc:8:3: required from ‘void A::foo() [with T = int]’
y.cc:11:27: required from here
y.cc:8:17: error: ‘this’ was not captured for this lambda function
[Bug c++/53570] Unused symbols are not removed for fully static targets (avr-gcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53570 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal
[Bug c++/53570] Unused symbols are not removed for fully static targets (avr-gcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53570 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-06-04 08:36:53 UTC --- This is expected as there is only one section in the object file. If you use -ffunction-sections -fdata-sections and link with -Wl,--gc-sections. The unused functions/data will be removed. Another way is to use the link time optimizer (-flto on both the compile command line and the link command line; note you need to have the optimization options passed to the link command line also).
[Bug middle-end/52097] ICE: in get_bit_range, at expr.c:4535 with -O -flto -fexceptions -fnon-call-exceptions --param allow-store-data-races=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52097 --- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 08:43:32 UTC --- Author: rguenth Date: Mon Jun 4 08:43:23 2012 New Revision: 188167 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188167 Log: 2012-06-04 Richard Guenther rguent...@suse.de Eric Botcazou ebotca...@adacore.com Backport from mainline 2012-04-03 Eric Botcazou ebotca...@adacore.com * expr.c (get_bit_range): Add OFFSET parameter and adjust BITPOS. Change type of BITOFFSET to signed. Make sure the lower bound of the computed range is non-negative by adjusting OFFSET and BITPOS. (expand_assignment): Adjust call to get_bit_range. 2012-03-27 Eric Botcazou ebotca...@adacore.com * expr.c (get_bit_range): Return the null range if the enclosing record is part of a larger bit field. 2012-03-20 Richard Guenther rguent...@suse.de * stor-layout.c (finish_bitfield_representative): Fallback to conservative maximum size if the padding up to the next field cannot be computed as a constant. (finish_bitfield_layout): If we cannot compute the distance between the start of the bitfield representative and the bitfield member start a new representative. * expr.c (get_bit_range): The distance between the start of the bitfield representative and the bitfield member is zero if the field offsets are not constants. 2012-03-16 Richard Guenther rguent...@suse.de * stor-layout.c (finish_bitfield_representative): Fall back to the conservative maximum size if we cannot compute the size of the tail padding. 2012-03-14 Richard Guenther rguent...@suse.de * tree.h (DECL_BIT_FIELD_REPRESENTATIVE): New define. * stor-layout.c (start_bitfield_representative): New function. (finish_bitfield_representative): Likewise. (finish_bitfield_layout): Likewise. (finish_record_layout): Call finish_bitfield_layout. * tree.c (free_lang_data_in_decl): Only free DECL_QUALIFIER for QUAL_UNION_TYPE fields. * tree-streamer-in.c (lto_input_ts_field_decl_tree_pointers): Stream DECL_BIT_FIELD_REPRESENTATIVE. * tree-streamer-out.c (write_ts_field_decl_tree_pointers): Likewise. PR middle-end/52080 PR middle-end/52097 PR middle-end/48124 * expr.c (get_bit_range): Unconditionally extract bitrange from DECL_BIT_FIELD_REPRESENTATIVE. (expand_assignment): Adjust call to get_bit_range. * gcc.dg/torture/pr48124-1.c: New testcase. * gcc.dg/torture/pr48124-2.c: Likewise. * gcc.dg/torture/pr48124-3.c: Likewise. * gcc.dg/torture/pr48124-4.c: Likewise. * gnat.dg/pack16.adb: Likewise. * gnat.dg/pack16_pkg.ads: Likewise. * gnat.dg/pack17.adb: Likewise. * gnat.dg/specs/pack7.ads: Likewise. * gnat.dg/specs/pack8.ads: Likewise. * gnat.dg/specs/pack8_pkg.ads: Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-2.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-3.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-4.c branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/pack16.adb branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/pack16_pkg.ads branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/pack17.adb branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/specs/pack7.ads branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/specs/pack8.ads branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/specs/pack8_pkg.ads Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/expr.c branches/gcc-4_7-branch/gcc/stor-layout.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-streamer-in.c branches/gcc-4_7-branch/gcc/tree-streamer-out.c branches/gcc-4_7-branch/gcc/tree.c branches/gcc-4_7-branch/gcc/tree.h
[Bug middle-end/48124] [4.5/4.6/4.7 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 --- Comment #30 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 08:43:32 UTC --- Author: rguenth Date: Mon Jun 4 08:43:23 2012 New Revision: 188167 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188167 Log: 2012-06-04 Richard Guenther rguent...@suse.de Eric Botcazou ebotca...@adacore.com Backport from mainline 2012-04-03 Eric Botcazou ebotca...@adacore.com * expr.c (get_bit_range): Add OFFSET parameter and adjust BITPOS. Change type of BITOFFSET to signed. Make sure the lower bound of the computed range is non-negative by adjusting OFFSET and BITPOS. (expand_assignment): Adjust call to get_bit_range. 2012-03-27 Eric Botcazou ebotca...@adacore.com * expr.c (get_bit_range): Return the null range if the enclosing record is part of a larger bit field. 2012-03-20 Richard Guenther rguent...@suse.de * stor-layout.c (finish_bitfield_representative): Fallback to conservative maximum size if the padding up to the next field cannot be computed as a constant. (finish_bitfield_layout): If we cannot compute the distance between the start of the bitfield representative and the bitfield member start a new representative. * expr.c (get_bit_range): The distance between the start of the bitfield representative and the bitfield member is zero if the field offsets are not constants. 2012-03-16 Richard Guenther rguent...@suse.de * stor-layout.c (finish_bitfield_representative): Fall back to the conservative maximum size if we cannot compute the size of the tail padding. 2012-03-14 Richard Guenther rguent...@suse.de * tree.h (DECL_BIT_FIELD_REPRESENTATIVE): New define. * stor-layout.c (start_bitfield_representative): New function. (finish_bitfield_representative): Likewise. (finish_bitfield_layout): Likewise. (finish_record_layout): Call finish_bitfield_layout. * tree.c (free_lang_data_in_decl): Only free DECL_QUALIFIER for QUAL_UNION_TYPE fields. * tree-streamer-in.c (lto_input_ts_field_decl_tree_pointers): Stream DECL_BIT_FIELD_REPRESENTATIVE. * tree-streamer-out.c (write_ts_field_decl_tree_pointers): Likewise. PR middle-end/52080 PR middle-end/52097 PR middle-end/48124 * expr.c (get_bit_range): Unconditionally extract bitrange from DECL_BIT_FIELD_REPRESENTATIVE. (expand_assignment): Adjust call to get_bit_range. * gcc.dg/torture/pr48124-1.c: New testcase. * gcc.dg/torture/pr48124-2.c: Likewise. * gcc.dg/torture/pr48124-3.c: Likewise. * gcc.dg/torture/pr48124-4.c: Likewise. * gnat.dg/pack16.adb: Likewise. * gnat.dg/pack16_pkg.ads: Likewise. * gnat.dg/pack17.adb: Likewise. * gnat.dg/specs/pack7.ads: Likewise. * gnat.dg/specs/pack8.ads: Likewise. * gnat.dg/specs/pack8_pkg.ads: Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-2.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-3.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-4.c branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/pack16.adb branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/pack16_pkg.ads branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/pack17.adb branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/specs/pack7.ads branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/specs/pack8.ads branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/specs/pack8_pkg.ads Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/expr.c branches/gcc-4_7-branch/gcc/stor-layout.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-streamer-in.c branches/gcc-4_7-branch/gcc/tree-streamer-out.c branches/gcc-4_7-branch/gcc/tree.c branches/gcc-4_7-branch/gcc/tree.h
[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 --- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 08:43:31 UTC --- Author: rguenth Date: Mon Jun 4 08:43:23 2012 New Revision: 188167 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188167 Log: 2012-06-04 Richard Guenther rguent...@suse.de Eric Botcazou ebotca...@adacore.com Backport from mainline 2012-04-03 Eric Botcazou ebotca...@adacore.com * expr.c (get_bit_range): Add OFFSET parameter and adjust BITPOS. Change type of BITOFFSET to signed. Make sure the lower bound of the computed range is non-negative by adjusting OFFSET and BITPOS. (expand_assignment): Adjust call to get_bit_range. 2012-03-27 Eric Botcazou ebotca...@adacore.com * expr.c (get_bit_range): Return the null range if the enclosing record is part of a larger bit field. 2012-03-20 Richard Guenther rguent...@suse.de * stor-layout.c (finish_bitfield_representative): Fallback to conservative maximum size if the padding up to the next field cannot be computed as a constant. (finish_bitfield_layout): If we cannot compute the distance between the start of the bitfield representative and the bitfield member start a new representative. * expr.c (get_bit_range): The distance between the start of the bitfield representative and the bitfield member is zero if the field offsets are not constants. 2012-03-16 Richard Guenther rguent...@suse.de * stor-layout.c (finish_bitfield_representative): Fall back to the conservative maximum size if we cannot compute the size of the tail padding. 2012-03-14 Richard Guenther rguent...@suse.de * tree.h (DECL_BIT_FIELD_REPRESENTATIVE): New define. * stor-layout.c (start_bitfield_representative): New function. (finish_bitfield_representative): Likewise. (finish_bitfield_layout): Likewise. (finish_record_layout): Call finish_bitfield_layout. * tree.c (free_lang_data_in_decl): Only free DECL_QUALIFIER for QUAL_UNION_TYPE fields. * tree-streamer-in.c (lto_input_ts_field_decl_tree_pointers): Stream DECL_BIT_FIELD_REPRESENTATIVE. * tree-streamer-out.c (write_ts_field_decl_tree_pointers): Likewise. PR middle-end/52080 PR middle-end/52097 PR middle-end/48124 * expr.c (get_bit_range): Unconditionally extract bitrange from DECL_BIT_FIELD_REPRESENTATIVE. (expand_assignment): Adjust call to get_bit_range. * gcc.dg/torture/pr48124-1.c: New testcase. * gcc.dg/torture/pr48124-2.c: Likewise. * gcc.dg/torture/pr48124-3.c: Likewise. * gcc.dg/torture/pr48124-4.c: Likewise. * gnat.dg/pack16.adb: Likewise. * gnat.dg/pack16_pkg.ads: Likewise. * gnat.dg/pack17.adb: Likewise. * gnat.dg/specs/pack7.ads: Likewise. * gnat.dg/specs/pack8.ads: Likewise. * gnat.dg/specs/pack8_pkg.ads: Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-2.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-3.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-4.c branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/pack16.adb branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/pack16_pkg.ads branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/pack17.adb branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/specs/pack7.ads branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/specs/pack8.ads branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/specs/pack8_pkg.ads Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/expr.c branches/gcc-4_7-branch/gcc/stor-layout.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-streamer-in.c branches/gcc-4_7-branch/gcc/tree-streamer-out.c branches/gcc-4_7-branch/gcc/tree.c branches/gcc-4_7-branch/gcc/tree.h
[Bug middle-end/48124] [4.5/4.6 Regression] likely wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48124 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Known to work||4.7.1 AssignedTo|rguenth at gcc dot gnu.org |unassigned at gcc dot ||gnu.org Summary|[4.5/4.6/4.7 Regression]|[4.5/4.6 Regression] likely |likely wrong code bug |wrong code bug --- Comment #30 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 08:43:32 UTC --- Author: rguenth Date: Mon Jun 4 08:43:23 2012 New Revision: 188167 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188167 Log: 2012-06-04 Richard Guenther rguent...@suse.de Eric Botcazou ebotca...@adacore.com Backport from mainline 2012-04-03 Eric Botcazou ebotca...@adacore.com * expr.c (get_bit_range): Add OFFSET parameter and adjust BITPOS. Change type of BITOFFSET to signed. Make sure the lower bound of the computed range is non-negative by adjusting OFFSET and BITPOS. (expand_assignment): Adjust call to get_bit_range. 2012-03-27 Eric Botcazou ebotca...@adacore.com * expr.c (get_bit_range): Return the null range if the enclosing record is part of a larger bit field. 2012-03-20 Richard Guenther rguent...@suse.de * stor-layout.c (finish_bitfield_representative): Fallback to conservative maximum size if the padding up to the next field cannot be computed as a constant. (finish_bitfield_layout): If we cannot compute the distance between the start of the bitfield representative and the bitfield member start a new representative. * expr.c (get_bit_range): The distance between the start of the bitfield representative and the bitfield member is zero if the field offsets are not constants. 2012-03-16 Richard Guenther rguent...@suse.de * stor-layout.c (finish_bitfield_representative): Fall back to the conservative maximum size if we cannot compute the size of the tail padding. 2012-03-14 Richard Guenther rguent...@suse.de * tree.h (DECL_BIT_FIELD_REPRESENTATIVE): New define. * stor-layout.c (start_bitfield_representative): New function. (finish_bitfield_representative): Likewise. (finish_bitfield_layout): Likewise. (finish_record_layout): Call finish_bitfield_layout. * tree.c (free_lang_data_in_decl): Only free DECL_QUALIFIER for QUAL_UNION_TYPE fields. * tree-streamer-in.c (lto_input_ts_field_decl_tree_pointers): Stream DECL_BIT_FIELD_REPRESENTATIVE. * tree-streamer-out.c (write_ts_field_decl_tree_pointers): Likewise. PR middle-end/52080 PR middle-end/52097 PR middle-end/48124 * expr.c (get_bit_range): Unconditionally extract bitrange from DECL_BIT_FIELD_REPRESENTATIVE. (expand_assignment): Adjust call to get_bit_range. * gcc.dg/torture/pr48124-1.c: New testcase. * gcc.dg/torture/pr48124-2.c: Likewise. * gcc.dg/torture/pr48124-3.c: Likewise. * gcc.dg/torture/pr48124-4.c: Likewise. * gnat.dg/pack16.adb: Likewise. * gnat.dg/pack16_pkg.ads: Likewise. * gnat.dg/pack17.adb: Likewise. * gnat.dg/specs/pack7.ads: Likewise. * gnat.dg/specs/pack8.ads: Likewise. * gnat.dg/specs/pack8_pkg.ads: Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-2.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-3.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr48124-4.c branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/pack16.adb branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/pack16_pkg.ads branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/pack17.adb branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/specs/pack7.ads branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/specs/pack8.ads branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/specs/pack8_pkg.ads Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/expr.c branches/gcc-4_7-branch/gcc/stor-layout.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-streamer-in.c branches/gcc-4_7-branch/gcc/tree-streamer-out.c branches/gcc-4_7-branch/gcc/tree.c branches/gcc-4_7-branch/gcc/tree.h --- Comment #31 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 08:44:51 UTC --- Fixed on the 4.7 branch, too. Not applicable as is to older branches.
[Bug tree-optimization/53550] [4.6/4.7/4.8 regression] ICE with -O{1,2,3} -fprefetch-loop-arrays in build2_stat, at tree.c:3803
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53550 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-04 09:23:35 UTC --- Author: jakub Date: Mon Jun 4 09:23:27 2012 New Revision: 188169 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188169 Log: PR tree-optimization/53550 * tree-ssa-loop-niter.c (number_of_iterations_cond): If type is POINTER_TYPE_P, use sizetype as step type instead of type. * gcc.dg/pr53550.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr53550.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-niter.c
[Bug tree-optimization/53550] [4.6/4.7/4.8 regression] ICE with -O{1,2,3} -fprefetch-loop-arrays in build2_stat, at tree.c:3803
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53550 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-04 09:27:04 UTC --- Author: jakub Date: Mon Jun 4 09:27:00 2012 New Revision: 188170 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188170 Log: PR tree-optimization/53550 * tree-ssa-loop-niter.c (number_of_iterations_cond): If type is POINTER_TYPE_P, use sizetype as step type instead of type. * gcc.dg/pr53550.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr53550.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-loop-niter.c
[Bug fortran/50619] Surprising interaction between -finit-real=NAN and the associate construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50619 Stephan Weller gcc.10.dimsea at spamgourmet dot org changed: What|Removed |Added CC||gcc.10.dimsea at ||spamgourmet dot org --- Comment #3 from Stephan Weller gcc.10.dimsea at spamgourmet dot org 2012-06-04 09:44:06 UTC --- I can confirm this behaviour in gcc-4.6.2, 4.7.0, and 4.8.0 (20120530) development version. Since this renders -finit-real=NAN unusable for me, I would consider this a serious bug.
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #22 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-06-04 09:48:37 UTC --- Author: gjl Date: Mon Jun 4 09:48:34 2012 New Revision: 188172 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188172 Log: PR target/46261 * config/avr/avr-stdint.h: New file. * config.gcc (avr-*-*,tm_file): Use avr/avr-stdint.h instead of newlib-stdint.h Added: trunk/gcc/config/avr/avr-stdint.h Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #23 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-06-04 09:51:05 UTC --- Author: gjl Date: Mon Jun 4 09:51:00 2012 New Revision: 188173 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188173 Log: Backport from 2012-06-04 mainline r188172 PR target/46261 * config/avr/avr-stdint.h: New file. * config.gcc (avr-*-*,tm_file): Use avr/avr-stdint.h instead of newlib-stdint.h Added: branches/gcc-4_7-branch/gcc/config/avr/avr-stdint.h Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config.gcc
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #24 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-06-04 09:53:14 UTC --- Author: gjl Date: Mon Jun 4 09:53:04 2012 New Revision: 188174 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188174 Log: Backport from 2012-06-04 mainline r188172 PR target/46261 * config/avr/avr-stdint.h: New file. * config.gcc (avr-*-*,tm_file): Use avr/avr-stdint.h instead of newlib-stdint.h Added: branches/gcc-4_6-branch/gcc/config/avr/avr-stdint.h Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config.gcc
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #25 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-06-04 09:55:44 UTC --- Author: gjl Date: Mon Jun 4 09:55:35 2012 New Revision: 188175 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188175 Log: Backport from 2012-06-04 mainline r188172 PR target/46261 * config/avr/avr-stdint.h: New file. * config.gcc (avr-*-*,tm_file): Use avr/avr-stdint.h instead of newlib-stdint.h Added: branches/gcc-4_5-branch/gcc/config/avr/avr-stdint.h Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config.gcc
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.5.4, 4.6.4, 4.7.1 Resolution||FIXED Known to fail|4.5.2, 4.6.1|4.5.3, 4.6.3, 4.7.0 --- Comment #26 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-06-04 09:59:53 UTC --- Fixed in: 4.7.1, 4.6.4, 4.5.4.
[Bug tree-optimization/53571] [4.6/4.7/4.8 regression] ICE with -O{2,3} -floop-parallelize-all in cloog_domain_stride()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53571 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-06-04 Target Milestone|--- |4.6.4 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 10:07:39 UTC --- Please specify the cloog/ppl versions you are using. What target is this on?
[Bug c++/53563] [4.5/4.6/4.7/4.8 Regression] ICE in start_decl, at cp/decl.c:4427
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53563 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.3.6 Keywords||error-recovery, ||ice-on-invalid-code Last reconfirmed||2012-06-04 Ever Confirmed|0 |1 Summary|ICE in start_decl, at |[4.5/4.6/4.7/4.8 |cp/decl.c:4427 |Regression] ICE in ||start_decl, at ||cp/decl.c:4427 Target Milestone|--- |4.5.4 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 10:10:13 UTC --- 4.7 and trunk issue an error before: t.ii: In function 'int main()': t.ii:9:20: error: using typedef-name 'svoid' after 'struct' t.ii:9:20: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'baselink' in check_elaborated_type_specifier, at cp/decl.c:11475 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. 4.3 works: t.ii: In function 'int main()': t.ii:9: error: no matching function for call to 'svoid::s()' t.ii:3: note: candidates are: svoid::s(const svoid)
[Bug tree-optimization/53571] [4.6/4.7/4.8 regression] ICE with -O{2,3} -floop-parallelize-all in cloog_domain_stride()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53571 --- Comment #2 from Kacper Kowalik xarthisius.kk at gmail dot com 2012-06-04 10:11:09 UTC --- (In reply to comment #1) Please specify the cloog/ppl versions you are using. What target is this on? dev-libs/cloog-ppl-0.15.10 dev-libs/ppl-0.11.2-r1 Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /dev/shm/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check --with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3 p1.3, pie-0.5.1' Thread model: posix gcc version 4.6.3 (Gentoo 4.6.3 p1.3, pie-0.5.1)
[Bug tree-optimization/53550] [4.6 regression] ICE with -O{1,2,3} -fprefetch-loop-arrays in build2_stat, at tree.c:3803
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53550
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.7.1, 4.8.0
Summary|[4.6/4.7/4.8 regression]|[4.6 regression] ICE with
|ICE with -O{1,2,3} |-O{1,2,3}
|-fprefetch-loop-arrays in |-fprefetch-loop-arrays in
|build2_stat, at tree.c:3803 |build2_stat, at tree.c:3803
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-04
10:17:22 UTC ---
Fixed for 4.7+ so far.
[Bug tree-optimization/52979] [4.7 Regression] likely wrong code bug w/packed bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52979 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 10:19:49 UTC --- Author: rguenth Date: Mon Jun 4 10:19:44 2012 New Revision: 188176 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188176 Log: 2012-06-04 Richard Guenther rguent...@suse.de Backport from mainline 2012-04-25 Jakub Jelinek ja...@redhat.com PR middle-end/52979 * stor-layout.c (get_best_mode): Don't return mode with bitsize larger than maxbits. Don't compute maxbits modulo align. Also check that unit bytes long store at bitpos / unit * unit doesn't affect bits beyond bitregion_end. * expmed.c (store_bit_field_1): Avoid trying insv if OP_MODE MEM would not fit into bitregion_start ... bitregion_end + 1 bit region. (store_split_bit_field): Decrease unit close to end of bitregion_end if access is restricted in order to avoid mutual recursion. * gcc.c-torture/compile/pr52979-1.c: New test. * gcc.c-torture/execute/pr52979-1.c: New test. * gcc.c-torture/execute/pr52979-2.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/compile/pr52979-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/execute/pr52979-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/execute/pr52979-2.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/expmed.c branches/gcc-4_7-branch/gcc/stor-layout.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/52979] [4.7 Regression] likely wrong code bug w/packed bitfields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52979 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.7.1 Resolution||FIXED --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 10:23:51 UTC --- Fixed.
[Bug c/52952] Wformat location info is bad (wrong column number)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #14 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-06-04 11:18:46 UTC --- (In reply to comment #13) I guess the C/C++ FEs could for non-trivial string literals put into a hash table mapping from locus_t (of ADDR_EXPR around STRING_CST) to the first cpp token for that string, then the diagnostic code could go from there. Where is the best place to store this hash table? And you say the C/C++ FEs, but it seems to me this would need to be done in libcpp, no? Trivial string literal above would be a string literal that doesn't have any prefixes (L/u/u8/U and variants with R), isn't contatenated from several parts and didn't need to be translated. So, printf (%.*d); (the common case) wouldn't have to be recorded, while printf (R(%) . R(*) d); would need that. For trivial string literals you'd just shift the locus by the offset, for non-trivial look up the tokens and process them again, looking at where the corresponding byte would appear to come from. What do you mean by process them again? Once we have a mapping of location_t to individual token, the only thing to be done is look inside the string for the relevant character, no? Well, this seems to require several big parts: First, handle locations + offsets in diagnostics. Perhaps we need new warning_at_offset(location, offset, ...) functions? Or should we encode the offset in location_t somehow? If an offset parameter is passed explicitly, the diagnostics code would require a lot of changes to pass the offset around. Not sure what is the best way to implement this and avoid massive changes. Second, building the hash table discussed above. Where should it be built? Where should it be stored? Third, location+offset to expanded_location code. This is the part that will use the above hash table and reprocess the tokens. Exactly how it will work is not entirely clear to me. Fourth, use the new infrastructure in Wformat warnings and other places that inspect strings. Perhaps the offset could also be re-used to implement ranges, but the diagnostics code would need to handle them differently when used for ranges and when used to specify a location within a string. I added Tom Tromey to the CC, perhaps he has some ideas about how to implement this.
[Bug fortran/50619] Surprising interaction between -finit-real=NAN and the associate construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50619 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-06-04 12:32:20 UTC --- (In reply to comment #3) I can confirm this behaviour in gcc-4.6.2, 4.7.0, and 4.8.0 (20120530) development version. Since this renders -finit-real=NAN unusable for me, I would consider this a serious bug. I concur that it is a bad wrong-code bug, but it only occurs with the nondefault flag -finit-real=* - and it is not a regression -, thus, I think it is bad but not serious. Unfortunately, the number of active gfortran developers is not that high, which in turn means that bugs aren't fixed and features not implemented as quickly as everyone would like. (Note: 99% of the Fortran-frontend development is done in the spare time!) Thus, if you are interested in contributing to gfortran - or if you know someone who is ... * * * Regarding this bugreport: I think the following patch should fix it. I will test it and submit it. --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -10105,3 +10105,4 @@ build_default_init_expr (gfc_symbol *sym) || sym-attr.cray_pointee - || sym-attr.cray_pointer) + || sym-attr.cray_pointer + || sym-assoc) return NULL;
[Bug lto/53572] New: Some public symbols don't get to serialized LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572 Bug #: 53572 Summary: Some public symbols don't get to serialized LTO Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: tetra2...@gmail.com Created attachment 27553 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27553 This archive includes Makefile, header and two cpps which illustrate the problem The attached small project builds successfully by default ygribov@ygribov-desktop:~/test/repro-x86$ make CC=path-to-gcc clean all rm -f prog main.o lib.a lib.o gcc -O2 -DNDEBUG -frtti -c -o main.o main.cpp gcc -O2 -DNDEBUG -frtti -c -o lib.o lib.cpp ar rcs lib.a lib.o gcc main.o -L. lib.a -o prog -lsupc++ but fails if I compile with LTO enabled: ygribov@ygribov-desktop:~/test/repro-x86/jni$ make CC=path-to-gcc LTO=-flto clean all rm -f prog main.o lib.a lib.o gcc -flto -O2 -DNDEBUG -frtti -save-temps -c -o main.o main.cpp gcc -O2 -DNDEBUG -frtti -save-temps -c -o lib.o lib.cpp ar rcs lib.a lib.o gcc -flto main.o -L. lib.a -o prog -lsupc++ `_ZTI1A' referenced in section `.rodata._ZTV1A[_ZTV1A]' of lib.a(lib.o): defined in discarded section `.text' of main.o (symbol from plugin) collect2: error: ld returned 1 exit status make: *** [prog] Error 1 _ZTI1A is a weak definition of vtable for class A which is defined both in main.cpp and in lib.cpp (because they both include common.h which defines thus class). Main.cpp is compiled with -flto and _ZTI1A then gets into main.o's LTO symtab. As main.o is the first file in the list which declares to provide definition for this weak symbol linker assumes that it should come from main.o. But for some reason the actual GIMPLE tree for _ZTI1A is not stored in main.o's LTO sections and this causes errors during linking (linker can't find symbol promised by main.o's LTO symtab). I tried to compile both with gcc 4.6 and gcc trunk and every time it failed in the same way. I have to include a tgz instead of single source file because problem manifests itself only when I link several files.
[Bug c++/53545] g++ 4.70 --std=c++11 generates no object file, issues no errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53545 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #4 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-06-04 12:41:06 UTC --- (In reply to comment #2) Looks like an infinite recursion between tsubst and tsubst_copy_and_build, does that ring a bell to someone? Could this be a similar problem as observed in bug 53498, comment 1?
[Bug lto/53572] Some public symbols don't get to serialized LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-04 CC||hjl at gcc dot gnu.org Version|unknown |4.7.1 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 12:53:16 UTC --- Confirmed. I see the resolution file 1 main.o 6 252 65004255f21c98f6 PREVAILING_DEF main 263 65004255f21c98f6 RESOLVED_EXEC _ZdlPv 270 65004255f21c98f6 RESOLVED_EXEC _Z1fv 202 65004255f21c98f6 PREVAILING_DEF _ZTI1A 225 65004255f21c98f6 PREVAILING_DEF _ZTS1A 213 65004255f21c98f6 RESOLVED_EXEC _ZTVN10__cxxabiv117__class_type_infoE But the error message `_ZTI1A' referenced in section `.rodata._ZTV1A[_ZTV1A]' of lib.a(lib.o): defined in discarded section `.gnu.linkonce.t._ZTI1A' of main.o (symbol from plugin) collect2: error: ld returned 1 exit status suggests this is a linker bug? Either LTO decides to drop _ZTI1A from main.o - which it can - then the linker needs to re-scan the archives and resolve the symbol to the archive provided one: nm lib.o t _GLOBAL__sub_I_a T _Z1fv W _ZN1AD0Ev W _ZN1AD1Ev W _ZN1AD2Ev n _ZN1AD5Ev V _ZTI1A V _ZTS1A V _ZTV1A U _ZTVN10__cxxabiv117__class_type_infoE U _ZdlPv U __cxa_atexit U __dso_handle B a Thus, can you file a binutils bug?
[Bug c++/53573] New: template type dependant name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573 Bug #: 53573 Summary: template type dependant name resolution broken Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ke...@fry-it.com
[Bug target/53461] Incorrect handling of CASE_VECTOR_PC_RELATIVE in config/m68k.md
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53461 --- Comment #1 from Andreas Schwab schwab at gcc dot gnu.org 2012-06-04 13:13:15 UTC --- Author: schwab Date: Mon Jun 4 13:13:09 2012 New Revision: 188179 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188179 Log: PR target/53461 * config/m68k/m68k.md (tablejump): Fix check for CASE_VECTOR_PC_RELATIVE. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.md
[Bug target/53461] Incorrect handling of CASE_VECTOR_PC_RELATIVE in config/m68k.md
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53461 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2012-06-04 13:14:43 UTC --- Fixed in trunk.
[Bug lto/53471] [4.7/4.8 Regression] ICE in pp_base_format, at pretty-print.c:510 (-flto -g)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53471 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 13:19:23 UTC --- Author: rguenth Date: Mon Jun 4 13:19:17 2012 New Revision: 188181 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188181 Log: 2012-06-04 Richard Guenther rguent...@suse.de PR middle-end/53471 * dwarf2out.c (dwarf2out_finish): If generating LTO do not create new assembler names. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug lto/53471] [4.7/4.8 Regression] ICE in pp_base_format, at pretty-print.c:510 (-flto -g)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53471 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 13:24:30 UTC --- Author: rguenth Date: Mon Jun 4 13:24:24 2012 New Revision: 188182 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188182 Log: 2012-06-04 Richard Guenther rguent...@suse.de PR middle-end/53471 * dwarf2out.c (dwarf2out_finish): If generating LTO do not create new assembler names. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/dwarf2out.c
[Bug lto/53471] [4.7/4.8 Regression] ICE in pp_base_format, at pretty-print.c:510 (-flto -g)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53471 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 13:24:30 UTC --- Author: rguenth Date: Mon Jun 4 13:24:24 2012 New Revision: 188182 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188182 Log: 2012-06-04 Richard Guenther rguent...@suse.de PR middle-end/53471 * dwarf2out.c (dwarf2out_finish): If generating LTO do not create new assembler names. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/dwarf2out.c --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 13:24:54 UTC --- Fixed.
[Bug lto/53471] [4.7/4.8 Regression] ICE in pp_base_format, at pretty-print.c:510 (-flto -g)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53471 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 13:24:54 UTC --- Fixed.
[Bug c++/53573] template type dependant name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
Keean Schupke ke...@fry-it.com changed:
What|Removed |Added
CC||ke...@fry-it.com
--- Comment #1 from Keean Schupke ke...@fry-it.com 2012-06-04 13:30:59 UTC ---
// test.cpp
//
// gcc-version: gcc (Gentoo 4.7.0 p1.0, pie-0.5.3) 4.7.0
// system-type: Linux Ra 3.0.29-tuxonice #4 SMP PREEMPT
//Sat May 26 10:21:39 BST 2012
//x86_64 Genuine Intel(R) CPU U7300 @ 1.30GHz GenuineIntel GNU/Linux
// compile options: g++ test.cpp
// compile output:
//test.cpp: In instantiation of ‘T f(T) [with T = int]’:
//test.cpp:27:9: required from here
//test.cpp:18:12: error: ‘g’ was not declared in this scope,
//and no declarations were found by argument-dependent lookup
//at the point of instantiation [-fpermissive]
//test.cpp:21:5: note: ‘int g(int)’ declared here, later in the
//translation unit
template typename T T f(T t) {
return g(t);
}
int g(int x) {
return x + 1;
}
main() {
int x(1);
x = f(x);
}
[Bug c++/53574] New: ICE with -fstack-usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53574 Bug #: 53574 Summary: ICE with -fstack-usage Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: ebotca...@gcc.gnu.org, ja...@gcc.gnu.org The following testcase ICEs with -std=c++11 -fstack-usage, works fine without the latter. Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The problem is when -fstack-usage uses lang_hooks.decl_printable_name (current_function_decl, 2) late, not sure if it is because free_lang_data frees something that the C++ FE needs for it and toplevel.c shouldn't be calling that langhook so late, or if it is a C++ FE bug.
[Bug c++/53573] template type dependant name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573 --- Comment #2 from Keean Schupke ke...@fry-it.com 2012-06-04 13:33:38 UTC --- The function called in the template definition is clearly dependent on the template parameter 'T' and therefore itsname should be resolved at the point of instantiation where 'g' is clearly defined and in scope (and is not local). The error message says: no declarations were found by argument-dependent lookup at the point of instantiation when 'g' should be found. See Technicalities C.13.8
[Bug c++/53574] ICE with -fstack-usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53574 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-04 13:34:26 UTC --- Created attachment 27554 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27554 rh828003.ii
[Bug fortran/53552] Add support for !GCC$ warning directive (cf. #pragma warning)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53552 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-06-04 13:38:51 UTC --- (In reply to comment #1) Wouldn't it be better to make Fortran use the common GCC diagnostics machinery? In some off-line discussion, Manuel wrote: | diagnostics-core.h implements that core | entry points. A FE needs to implement their own printf-like codes (see | tree-diagnostics.c) and pretty-printer of expressions (similar to | c-pretty-printer.c but for its own AST). Regarding the multi-location support of gfortran: | this is not implemented. But since the FEs need to handle | their own format specifiers, it is a matter of interfacing your | current implementation with the common diagnostics machinery. | you could start by simply adding an interface to the current | Fortran diagnostics machinery to access it from diagnostics.c. That | is, implement enough glue code so you can call the current Fortran | code passing through warning_at/error_at (or just re-wire gfc_warning | to pass through diagnostic_report_diagnostic). This will give you | #pragma GCC diagnostics, Werror=, and fdiagnostics-show-option almost | for free. I think as part of the implementation, one should pass to gfc_warning the flag which triggers it (or 0 for default warning), similar to warning_at; example: warning_at (loc, OPT_Wcast_qual, ... For hooking up front-end warnings, maybe java/lang.c can be of some help. Or cp/error.c (esp. cp_print_error_function and cp_printer).
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #3 from Keean Schupke ke...@fry-it.com 2012-06-04 13:44:14 UTC ---
From: Technicalities C.13.8.3:
struct X { X(int); /* ... */ };
void g(X);
templateclass T void f(T a) { g(a); }
void h()
{
extern void g(int);
f(2); // invokes f(X(2)); that is, fX(X(2))
}
Here, the point of instantiation for f is just before h()...
Note: just before h(), not just before templateclass T
[Bug fortran/53552] Add support for !GCC$ warning directive (cf. #pragma warning)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53552 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-06-04 14:03:03 UTC --- (In reply to comment #2) I think as part of the implementation, one should pass to gfc_warning the flag which triggers it (or 0 for default warning), similar to warning_at; example: warning_at (loc, OPT_Wcast_qual, ... This is a must to fix this bug and PR44054, whether you wish to use the common diagnostics code or not. For hooking up front-end warnings, maybe java/lang.c can be of some help. Or cp/error.c (esp. cp_print_error_function and cp_printer). Note that you don't actually need to implement a pretty-printer to get this bug and PR44054 fixed. The diagnostics.c code does not (if it does, it is a bug) look into the string, you only need to fake a pretty-printer well enough that calls the existing Fortran equivalent of a pretty-printer to process the string.
[Bug lto/53572] Some public symbols don't get to serialized LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2012-06-04 14:10:35 UTC --- mine.
[Bug lto/53572] Some public symbols don't get to serialized LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2012-06-04 14:19:02 UTC --- I do not have linker plugin enabled setup handy at the moment, but the following patch should fix it: Index: cgraph.h === --- cgraph.h(revision 188138) +++ cgraph.h(working copy) @@ -1126,7 +1126,8 @@ varpool_can_remove_if_no_refs (struct va if (DECL_EXTERNAL (node-symbol.decl)) return true; return (!node-symbol.force_output !node-symbol.used_from_other_partition - (DECL_COMDAT (node-symbol.decl) + ((DECL_COMDAT (node-symbol.decl) + symtab_used_from_object_file_p ((symtab_node) node)) || !node-symbol.externally_visible || DECL_HAS_VALUE_EXPR_P (node-symbol.decl))); } I am testing this patch for mainline. As discussed on IRC, this patch can have negative effect on V1 linker API setups: here all comdats appears to be externally visible and thus they will be forced to output. But perhaps it is now resonable to expect V2 linker API even for GCC 4.7 based setups for sane LTO with C++? We already mention in release notes that V1 API is bad idea... Honza
[Bug target/53575] New: --with-abi=x32 without --with-multilib-list doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53575 Bug #: 53575 Summary: --with-abi=x32 without --with-multilib-list doesn't work Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: ubiz...@gmail.com Target: x86-64-*-linux* From: http://groups.google.com/group/x32-abi/browse_thread/thread/360abfbd5e1b4f8a?hl=en --- if i configure gcc using --with-abi=mx32, but don't specify --with-multilib-list, then the config will default to --with-multilib-list=m32,m64. then trying to build gcc will fail as it will use . for its os multilib dir instead of ../libx32. if i specify --with-multilib-list=mx32, then everything works great. should the config.gcc logic for with_multilib_list==default consult the with_abi setting ? maybe something like: if test $x86_multilibs = default; then if test $with_abi != ; then x86_multilibs=$with_abi else x86_multilibs=m64,m32 fi fi --- I think --with-abi=mx32 should also add x32 run-time library, in addition to 64-bit and 32-bit ones.
[Bug lto/53572] Some public symbols don't get to serialized LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-04 14:38:06 UTC --- (In reply to comment #3) I do not have linker plugin enabled setup handy at the moment, but the following patch should fix it: Index: cgraph.h === --- cgraph.h(revision 188138) +++ cgraph.h(working copy) @@ -1126,7 +1126,8 @@ varpool_can_remove_if_no_refs (struct va if (DECL_EXTERNAL (node-symbol.decl)) return true; return (!node-symbol.force_output !node-symbol.used_from_other_partition - (DECL_COMDAT (node-symbol.decl) + ((DECL_COMDAT (node-symbol.decl) + symtab_used_from_object_file_p ((symtab_node) node)) !symtab_used_from_object_file_p I suppose. I would have expected used_from_other_partition to be true in this case. Also the 4.7 branch looks suspiciously different from this, referencing flag_toplevel_reorder ... The adjusted as above patch works on trunk though. But I really would say object files are also another partition. || !node-symbol.externally_visible || DECL_HAS_VALUE_EXPR_P (node-symbol.decl))); } I am testing this patch for mainline. As discussed on IRC, this patch can have negative effect on V1 linker API setups: here all comdats appears to be externally visible and thus they will be forced to output. If as comdat the linker should eliminate them. But perhaps it is now resonable to expect V2 linker API even for GCC 4.7 based setups for sane LTO with C++? We already mention in release notes that V1 API is bad idea... Well, sure - assuming that we have a V2 capable linker is ok I guess. In the end we should simply annotate the resolution file with the linker capability, thus extend the file-format to include a one-line header with a version. Richard. Honza
[Bug c/47530] [trans-mem] tail call optimization problem with _ITM_commitTransaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47530 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #7 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-06-04 15:21:42 UTC --- Reopened with Luke's testcase, which triggers on both 4.7 and 4.8. Luke, in the future, it would really help if you could narrow down the testcase to the smallest reproducible testcase. This helps us immensely and expedites any possible fix.
[Bug c/47530] [trans-mem] tail call optimization problem with _ITM_commitTransaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47530 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added AssignedTo|rth at gcc dot gnu.org |aldyh at gcc dot gnu.org --- Comment #8 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-06-04 15:24:38 UTC --- Created attachment 27555 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27555 reduced testcase for luke's sample
[Bug c/47530] [trans-mem] tail call optimization problem with _ITM_commitTransaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47530 --- Comment #9 from Patrick Marlier patrick.marlier at gmail dot com 2012-06-04 15:26:37 UTC --- Aldy, I have a testcase and a patch for this. I will submit it soon. Patrick
[Bug middle-end/47530] [trans-mem] tail call optimization problem with _ITM_commitTransaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47530 --- Comment #10 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-06-04 15:51:22 UTC --- Created attachment 27556 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27556 propsed patch being tested Whoops, sorry Patrick. I already have a patch I am testing :). If you already have yours tested, feel free to submit it, otherwise I'll post shortly.
[Bug middle-end/47530] [trans-mem] tail call optimization problem with _ITM_commitTransaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47530 --- Comment #11 from Patrick Marlier patrick.marlier at gmail dot com 2012-06-04 15:58:35 UTC --- Created attachment 27557 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27557 testcase (In reply to comment #10) Created attachment 27556 [details] propsed patch being tested Whoops, sorry Patrick. I already have a patch I am testing :). If you already have yours tested, feel free to submit it, otherwise I'll post shortly. Go ahead and submit (I will not able to do it before few hours). My patch was quite similar except for the testcase (using the tree dump but untested). Testcase attached if you want to include it into the testsuite.
[Bug rtl-optimization/51771] trans-mem: abnormal edges get lost or corrupted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51771 --- Comment #7 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-06-04 16:08:30 UTC --- (In reply to comment #4) Created attachment 27303 [details] RBTree microbenchmark test case I believe that I'm seeing this in the RSTM suite's RBTree microbenchmark as well. It appears to be manifesting with the same symptoms as pr47530, _ITM_commitTransaction is generated as a tail call. An abort in _ITM_commitTransaction during multithreaded execution corrupts the stack slot that is used to hold a time value. Luke, this is actually PR47530 and unrelated to this PR. I am fixing it for PR47530, and any further discussing will be in that PR.
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #4 from Keean Schupke ke...@fry-it.com 2012-06-04 16:38:21 UTC ---
From C++ Standard N3242=11-0012 14.6 Name Resolution
10. If a name does not depend on a template-parameter (as defined in 14.6.2), a
declaration (or set of declarations) for that name shall be in scope at the
point where the name appears in the template definition; the name is bound to
the declaration (or declarations) found at that point and this binding is not
affected by declarations that are visible at the point of instantiation.
[Example:
void f(char);
templateclass T void g(T t) {
f(1); // f(char)
f(T(1)); // dependent
f(t); // dependent
dd++; // not dependent
// error: declaration for dd not found
}
enum E { e };
void f(E);
double dd;
void h() {
g(e); // will cause one call of f(char) followed
// by two calls of f(E)
g(’a’); // will cause three calls of f(char)
}
— end example ]
[Bug middle-end/47530] [trans-mem] tail call optimization problem with _ITM_commitTransaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47530 --- Comment #12 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-06-04 16:51:33 UTC --- Author: aldyh Date: Mon Jun 4 16:51:24 2012 New Revision: 188190 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188190 Log: PR middle-end/47530 * trans-mem.c (expand_block_edges): Do not skip the first statement when resetting the BB. Added: trunk/gcc/testsuite/g++.dg/tm/pr47530-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/trans-mem.c
[Bug middle-end/47530] [trans-mem] tail call optimization problem with _ITM_commitTransaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47530 --- Comment #13 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-06-04 16:52:55 UTC --- Author: aldyh Date: Mon Jun 4 16:52:47 2012 New Revision: 188191 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188191 Log: PR middle-end/47530 * trans-mem.c (expand_block_edges): Do not skip the first statement when resetting the BB. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/tm/pr47530-2.C Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/trans-mem.c
[Bug middle-end/47530] [trans-mem] tail call optimization problem with _ITM_commitTransaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47530 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #14 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-06-04 16:56:21 UTC --- fixed on 4.7 and trunk. closing PR.
[Bug c++/53573] template type dependent name resolution broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53573
--- Comment #5 from Keean Schupke ke...@fry-it.com 2012-06-04 17:13:18 UTC ---
The following program will apparently compile correctly, but will silently
produce incorrect results at runtime:
#include iostream
char g(char x) {
return x - 1;
}
template typename T T f(T t) {
return g(t);
}
int g(int x) {
return x + 1;
}
main() {
int x(1);
int y(f(x));
std::cout y \n;
int z(fint(x));
std::cout z \n;
}
This should print 2 2 but prints 0 0. Interestingly it also produces
incorrect results with gcc-4.6.3 and gcc-4.5.3. However the code below (which
does not compile on gcc-4.7.0 does produce the correct results on gcc-4.6.3 and
gcc-4.5.3:
#include iostream
template typename T T f(T t) {
return g(t);
}
char g(char x) {
return x - 1;
}
int g(int x) {
return x + 1;
}
main() {
int x(1);
int y(f(x));
std::cout y \n;
int z(fint(x));
std::cout z \n;
}
So it looks like earlier versions of GCC relied on 'g' being undefined at the
point of definition to defer binding until instantiation instead of looking for
dependence on a template parameter. gcc-4.7.0 does not seem to do either.
One more example:
#include iostream
class A {};
A g(A x) {
return x;
}
template typename T T f(T t) {
return g(t);
}
int g(int x) {
return x + 1;
}
main() {
int x(1);
int y(f(x));
std::cout y \n;
int z(fint(x));
std::cout z \n;
}
generates the following compile error:
test.cpp: In function ‘T f(T) [with T = int]’:
test.cpp:35:11: instantiated from here
test.cpp:26:12: error: could not convert ‘t’ from ‘int’ to ‘A’
[Bug target/53559] ICE on altivec builtins stv[l|r]x[l]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53559 --- Comment #2 from edmarwjr at gcc dot gnu.org 2012-06-04 17:42:30 UTC --- Author: edmarwjr Date: Mon Jun 4 17:42:25 2012 New Revision: 188194 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188194 Log: 2012-06-04 Edmar Wienskoski ed...@freescale.com PR target/53559 * config/rs6000/altivec.md (altivec_stvlx): Change machine mode of operands. (altivec_stvlxl): Ditto. (altivec_stvrx): Ditto. (altivec_stvrxl): Ditto. gcc/testsuite 2012-06-04 Edmar Wienskoski ed...@freescale.com PR target/53559 * gcc.target/powerpc/cell_builtin_1.c: New test case. * gcc.target/powerpc/cell_builtin_2.c: Ditto. * gcc.target/powerpc/cell_builtin_3.c: Ditto. * gcc.target/powerpc/cell_builtin_4.c: Ditto. * gcc.target/powerpc/cell_builtin_5.c: Ditto. * gcc.target/powerpc/cell_builtin_6.c: Ditto. * gcc.target/powerpc/cell_builtin_7.c: Ditto. * gcc.target/powerpc/cell_builtin_8.c: Ditto. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-1.c branches/gcc-4_6-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-2.c branches/gcc-4_6-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-3.c branches/gcc-4_6-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-4.c branches/gcc-4_6-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-5.c branches/gcc-4_6-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-6.c branches/gcc-4_6-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-7.c branches/gcc-4_6-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-8.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/rs6000/altivec.md branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/53576] New: Very unhelpful error message: Unclassifiable statement instead of Can't convert TYPE to ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53576 Bug #: 53576 Summary: Very unhelpful error message: Unclassifiable statement instead of Can't convert TYPE to ... Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org The following program is invalid; gfortran rejects it, but with a completely unhelpful error message. The problem is that the amn(jj) should be amn%value(jj). Current error message: wfn 1 Error: Unclassifiable statement at (1) Expected error (or something similar): = amn(jj) 1 Error: Can't convert TYPE(amn_t) to COMPLEX(4) at (1) Note: gfortran prints the proper error message if the loop bound is changed from amn%nsites to, e.g., 5. (That's how I got the type-conversion error message.) program simple_wf_op_gen type :: amn_t integer :: nsites = 0 complex :: value(1) end type amn_t type(amn_t) :: amn integer :: jj complex :: wfn do jj = 1, amn%nsites wfn = amn(jj) end do end program simple_wf_op_gen
[Bug c++/53570] Unused symbols are not removed for fully static targets (avr-gcc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53570 --- Comment #3 from jwatte at gmail dot com 2012-06-04 18:07:04 UTC --- I will try -flto and report back. Thanks! Btw: I think that's expected is in the eye of the beholder. If all you've ever done is VAX/GCC-style UNIX, then it's expected. If you've worked with other toolchains, like AIX, CodeWarrior, Microsoft, etc, then you'd actually expect function-level linking by default.
[Bug target/53575] --with-abi=x32 without --with-multilib-list doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53575 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-06/msg00225.htm ||l Target Milestone|--- |4.8.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-06-04 18:10:39 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00225.html
[Bug target/53559] ICE on altivec builtins stv[l|r]x[l]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53559 --- Comment #3 from edmarwjr at gcc dot gnu.org 2012-06-04 18:15:56 UTC --- Author: edmarwjr Date: Mon Jun 4 18:15:46 2012 New Revision: 188198 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188198 Log: 2012-06-04 Edmar Wienskoski ed...@freescale.com PR target/53559 * config/rs6000/altivec.md (altivec_stvlx): Change machine mode of operands. (altivec_stvlxl): Ditto. (altivec_stvrx): Ditto. (altivec_stvrxl): Ditto. gcc/testsuite 2012-06-04 Edmar Wienskoski ed...@freescale.com PR target/53559 * gcc.target/powerpc/cell_builtin_1.c: New test case. * gcc.target/powerpc/cell_builtin_2.c: Ditto. * gcc.target/powerpc/cell_builtin_3.c: Ditto. * gcc.target/powerpc/cell_builtin_4.c: Ditto. * gcc.target/powerpc/cell_builtin_5.c: Ditto. * gcc.target/powerpc/cell_builtin_6.c: Ditto. * gcc.target/powerpc/cell_builtin_7.c: Ditto. * gcc.target/powerpc/cell_builtin_8.c: Ditto. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-2.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-3.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-4.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-5.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-6.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-7.c branches/gcc-4_7-branch/gcc/testsuite/gcc.target/powerpc/cell_builtin-8.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/rs6000/altivec.md branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/53571] [4.6/4.7/4.8 regression] ICE with -O{2,3} -floop-parallelize-all in cloog_domain_stride()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53571 --- Comment #3 from Kacper Kowalik xarthisius.kk at gmail dot com 2012-06-04 18:23:12 UTC --- Git bisect show this revision as a culprit: http://gcc.gnu.org/viewcvs?view=revisionrevision=163142
[Bug target/53559] ICE on altivec builtins stv[l|r]x[l]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53559 --- Comment #4 from edmarwjr at gcc dot gnu.org 2012-06-04 18:44:58 UTC --- Author: edmarwjr Date: Mon Jun 4 18:44:53 2012 New Revision: 188200 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188200 Log: 2012-06-04 Edmar Wienskoski ed...@freescale.com PR target/53559 * config/rs6000/altivec.md (altivec_stvlx): Change machine mode of operands. (altivec_stvlxl): Ditto. (altivec_stvrx): Ditto. (altivec_stvrxl): Ditto. gcc/testsuite 2012-06-04 Edmar Wienskoski ed...@freescale.com PR target/53559 * gcc.target/powerpc/cell_builtin_1.c: New test case. * gcc.target/powerpc/cell_builtin_2.c: Ditto. * gcc.target/powerpc/cell_builtin_3.c: Ditto. * gcc.target/powerpc/cell_builtin_4.c: Ditto. * gcc.target/powerpc/cell_builtin_5.c: Ditto. * gcc.target/powerpc/cell_builtin_6.c: Ditto. * gcc.target/powerpc/cell_builtin_7.c: Ditto. * gcc.target/powerpc/cell_builtin_8.c: Ditto. Added: trunk/gcc/testsuite/gcc.target/powerpc/cell_builtin-1.c trunk/gcc/testsuite/gcc.target/powerpc/cell_builtin-2.c trunk/gcc/testsuite/gcc.target/powerpc/cell_builtin-3.c trunk/gcc/testsuite/gcc.target/powerpc/cell_builtin-4.c trunk/gcc/testsuite/gcc.target/powerpc/cell_builtin-5.c trunk/gcc/testsuite/gcc.target/powerpc/cell_builtin-6.c trunk/gcc/testsuite/gcc.target/powerpc/cell_builtin-7.c trunk/gcc/testsuite/gcc.target/powerpc/cell_builtin-8.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/altivec.md trunk/gcc/testsuite/ChangeLog
[Bug fortran/53456] Add time support for VxWorks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53456 --- Comment #10 from Janne Blomqvist jb at gcc dot gnu.org 2012-06-04 19:13:54 UTC --- Author: jb Date: Mon Jun 4 19:13:49 2012 New Revision: 188201 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188201 Log: PR 53456 Fix typo in gf_cputime. 2012-06-04 Robert Mason r...@verizon.net Janne Blomqvist j...@gcc.gnu.org PR fortran/53456 * intrinsics/time_1.h (gf_cputime): Fix typo in clock_gettime branch. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/time_1.h
[Bug fortran/53456] Add time support for VxWorks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53456 --- Comment #11 from Janne Blomqvist jb at gcc dot gnu.org 2012-06-04 19:15:25 UTC --- Author: jb Date: Mon Jun 4 19:15:21 2012 New Revision: 188202 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188202 Log: PR 53456 Fix incorrect ChangeLog entry. Modified: trunk/libgfortran/ChangeLog
[Bug preprocessor/53463] [4.8 Regression]: system header not recognized, yielding warnings about long long preprocessor constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53463
--- Comment #6 from Dodji Seketeli dodji at gcc dot gnu.org 2012-06-04
19:20:16 UTC ---
Author: dodji
Date: Mon Jun 4 19:19:58 2012
New Revision: 188203
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188203
Log:
PR preprocessor/53463 - Fix system header detection for built-in macro tokens
The location for a built-in macro token is BUILTIN_LOCATION. When we
see that location value, we cannot know if that token was used in a
system header or not. And that can trigger some unwanted warnings on
e.g, the use of __LONG_LONG_MAX__ built-in macro in system headers
when we compile with -pedantic, like in the test case accompanying
this patch.
In that case, I think we ought to step-up to see where the built-in
macro has been expanded, until we see a location that is not for a
built-in macro. Then we can check if the resulting location is in a
system header or not.
Now that we step up to the location of first non-built-in-macro token,
it appeared that for
testsuite/c-c++-common/dfp/convert-int-saturate.c, G++ then fails to
emit the warning in:
volatile unsigned int usi;
int
main ()
{
usi = DEC32_MAX; /* { dg-warning overflow in implicit constant
conversion } */
...
}
Because DEC32_MAX is defined in the system header float.h as a
built-in macro:
#define DEC32_MAX__DEC32_MAX__
And during the parsing of the assignment expression that should have
led to the warning above, input_location is set to the location for
the DEC32_MAX, which is actually the location for the built-in
__DECL32_MAX_EXP.
A possible fix is to use the location of the = operator as the
default location for assignment expressions. This is what the patch
does.
I had to adjust a couple of tests to arrange for this.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
libcpp/
PR preprocessor/53463
* line-map.c (linemap_location_in_system_header_p): For built-in
macro tokens, check the first expansion point location for that is
not for a token coming from a built-in macro.
gcc/cp/
PR preprocessor/53463
* parser.c (cp_parser_assignment_expression): Use the location
for the LHS as the default location for the expression.
gcc/testsuite/
PR preprocessor/53463
* g++.dg/cpp/limits.C: New test.
* g++.dg/parse/error19.C: Adjust.
* g++.dg/warn/Wconversion-real-integer2.C: Likewise.
* g++.dg/warn/pr35635.C: Likewise.
* g++.old-deja/g++.pt/assign1.C: Likewise.
Added:
trunk/gcc/testsuite/g++.dg/cpp/limits.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/error19.C
trunk/gcc/testsuite/g++.dg/warn/Wconversion-real-integer2.C
trunk/gcc/testsuite/g++.dg/warn/pr35635.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/assign1.C
trunk/libcpp/ChangeLog
trunk/libcpp/line-map.c
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524 --- Comment #20 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-06-04 19:27:26 UTC --- Author: paolo Date: Mon Jun 4 19:27:12 2012 New Revision: 188204 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188204 Log: 2012-06-04 Paolo Carlini paolo.carl...@oracle.com PR c++/53524 * doc/invoke.texi (Wenum-compare): Update documentation. /cp 2012-06-04 Paolo Carlini paolo.carl...@oracle.com PR c++/53524 * call.c (build_conditional_expr_1): Use OPT_Wenum_compare to control enumeral mismatch in conditional expression too. /testsuite 2012-06-04 Paolo Carlini paolo.carl...@oracle.com PR c++/53524 * g++.dg/warn/Wenum-compare-no-2: New. Added: trunk/gcc/testsuite/g++.dg/warn/Wenum-compare-no-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug c++/51494] Legal program rejection - capturing this when using static method inside lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51494 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2012-06-04 19:35:40 UTC --- The testcases in comments 2 and 4 are PR 53137, which is fixed for 4.7.1.
[Bug lto/53572] Some public symbols don't get to serialized LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572 --- Comment #5 from Jan Hubicka hubicka at ucw dot cz 2012-06-04 19:52:51 UTC --- !node-symbol.used_from_other_partition - (DECL_COMDAT (node-symbol.decl) + ((DECL_COMDAT (node-symbol.decl) + symtab_used_from_object_file_p ((symtab_node) node)) !symtab_used_from_object_file_p Ah, yes. Sorry. I suppose. I would have expected used_from_other_partition to be true Well, used_from_other_partition reffers to IR partitions, not other uses. I would not mix them unless we need so. There are some differences - like symbols from other partitions can be local and can use custom calling conventions. Symbols used form asm can't. But perhaps it is now resonable to expect V2 linker API even for GCC 4.7 based setups for sane LTO with C++? We already mention in release notes that V1 API is bad idea... Well, sure - assuming that we have a V2 capable linker is ok I guess. In the end we should simply annotate the resolution file with the linker capability, thus extend the file-format to include a one-line header with a version. As I tried to explain on IRC, this won't help since V1/V2 API differs already on compile time when we don't have linker plugin and have no clue what version of API will be used at linktime. It is possible to teach lto-plugin to do the hack instead of doing it in lto-streamer-out.c if we really want sane support for V1 API. Concerning the problem in this PR, i guess we probably should give up handling this sanely in V1 API: we already hide COMDAT vtables and type descriptions should be harmless/dropped by the linker eventually. Honza
[Bug c++/53545] g++ 4.70 --std=c++11 generates no object file, issues no errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53545 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org 2012-06-04 19:54:05 UTC --- (In reply to comment #4) Could this be a similar problem as observed in bug 53498, comment 1? Indeed, the testcases look similar and the stack traces are both infinite recursions that ping-pong between the same 2 functions. Thanks.
[Bug preprocessor/53463] [4.8 Regression]: system header not recognized, yielding warnings about long long preprocessor constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53463 --- Comment #7 from dodji at seketeli dot org dodji at seketeli dot org 2012-06-04 19:57:31 UTC --- Hans-Peter and Greta, Could you please test trunk and, if the commit above fixes the issue for you, close the bug please? Thank you in advance.
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524 --- Comment #21 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-06-04 20:31:04 UTC --- Author: paolo Date: Mon Jun 4 20:30:59 2012 New Revision: 188207 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188207 Log: 2012-06-04 Paolo Carlini paolo.carl...@oracle.com PR c++/53524 * doc/invoke.texi (Wenum-compare): Update documentation. /cp 2012-06-04 Paolo Carlini paolo.carl...@oracle.com PR c++/53524 * call.c (build_conditional_expr_1): Use OPT_Wenum_compare to control enumeral mismatch in conditional expression too. /testsuite 2012-06-04 Paolo Carlini paolo.carl...@oracle.com PR c++/53524 * g++.dg/warn/Wenum-compare-no-2: New. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/warn/Wenum-compare-no-2.C Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/call.c branches/gcc-4_7-branch/gcc/doc/invoke.texi branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/50619] Surprising interaction between -finit-real=NAN and the associate construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50619 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-06-04 21:01:05 UTC --- Author: burnus Date: Mon Jun 4 21:01:02 2012 New Revision: 188208 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188208 Log: 2012-06-04 Tobias Burnus bur...@net-b.de PR fortran/50619 * resolve.c (build_default_init_expr): Don't initialize ASSOCIATE names. 2012-06-04 Tobias Burnus bur...@net-b.de PR fortran/50619 * gfortran.dg/init_flag_10.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/init_flag_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug c++/53577] New: segmentation fault on syntax error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53577
Bug #: 53577
Summary: segmentation fault on syntax error
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ettl.mar...@gmx.de
gcc crashes on following syntactically wrong code:
typedef union U1
{
int i;
} U2 __attribute__((transparent_union));
static
void foo2(U1) {} static foo(int) foo2(U2) {} void bar2(U1 u1,
U2 u2)
{
foo2(u1);
foo2(u2);
}
I am using gcc version:
$ gcc -v
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Ziel: x86_64-linux-gnu
Konfiguriert mit: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread-Modell: posix
gcc-Version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
If you need further information about my system configuration, please let me
know.
Best regards
Ettl Martin
[Bug c++/53577] segmentation fault on syntax error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53577 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-06-04 21:44:22 UTC --- Dup. *** This bug has been marked as a duplicate of bug 51228 ***
[Bug c++/51228] [4.5/4.6 Regression] ICE with transparent union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51228 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||ettl.martin at gmx dot de --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-06-04 21:44:22 UTC --- *** Bug 53577 has been marked as a duplicate of this bug. ***
[Bug bootstrap/53555] [4.8 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53555 --- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-06-04 23:31:57 UTC --- Author: hjl Date: Mon Jun 4 23:31:54 2012 New Revision: 188212 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188212 Log: Skip debug insns in ix86_sched_reorder PR bootstrap/53555 * config/i386/i386.c (ix86_sched_reorder) Skip debug insns. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug libstdc++/53578] New: include/ext/concurrence.h relies on ill-formed narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578 Bug #: 53578 Summary: include/ext/concurrence.h relies on ill-formed narrowing conversions Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: richard-gccbugzi...@metafoo.co.uk From around line 271 of ext/concurrence.h: // matches a gthr-win32.h recursive mutex templatetypename _Rm static typename __enable_ifsizeof(_Rm::sema), void::__type _S_destroy(_Rm* __mx) This SFINAE device doesn't work in Clang in C++11 mode, because the sizeof expression evaluates to a value greater than one, and thus the implicit conversion to bool for the first template parameter is a narrowing conversion. I assume g++ will hit this too once it adds support for the narrowing check in converted constant expressions.
[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-06-04 23:55:04 UTC --- I assume g++ will hit this too once it adds support for the narrowing check in converted constant expressions. IIRC g++ had the check for narrowing in converted constant expressions and it was removed because the standard had a defect.
[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-06-05 00:00:18 UTC --- (In reply to comment #1) I assume g++ will hit this too once it adds support for the narrowing check in converted constant expressions. IIRC g++ had the check for narrowing in converted constant expressions and it was removed because the standard had a defect. Actually I take that back. GCC already implements the error for narrowing for converted constant expressions. Also ext/concurrence.h is an extension to the C++ standard so I don't think we should worry about other compilers besides GCC here.
[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jwakely.gcc at gmail dot ||com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-06-05 00:04:59 UTC --- Let's ask Jon to have a look, I think he figured out rather recently these bits.
[Bug libstdc++/53579] New: libstdc++ configure atomicity tests use CXXFLAGS instead of CXXFLAGS_FOR_TARGET
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53579 Bug #: 53579 Summary: libstdc++ configure atomicity tests use CXXFLAGS instead of CXXFLAGS_FOR_TARGET Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org When trying to fix PR 29366 by removing config/cpu/sh/atomicity.h I've noticed that libstdc++'s configure would refuse to pick up config/cpu/generic/atomicity_builtins. On the SH target atomicity builtins have to be enabled by either -msoft-atomic or -mhard-atomic. For sh-linux -msoft-atomic is enabled by default. When building a cross toolchain (top level make) CFLAGS_FOR_TARGET / CXXFLAGS_FOR_TARGET can be used to enable the atomicity builtins. However, libstdc++ configure uses CXXFLAGS when testing for atomicity builtins availability, so it will default to using config/cpu/generic/atomicity_mutex. I'm not quite sure where the fix should go, either in the top level configure/makefile (which fails to set CXXFLAGS to CXXFLAGS_FOR_TARGET for libstdc++ configure) or libstdc++ itself, because when libstdc++ is actually compiled CXXFLAGS_FOR_TARGET is passed to xgcc as expected.
[Bug libstdc++/29366] atomics config for sh is weird
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29366 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Depends on||53579 --- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org 2012-06-05 00:19:41 UTC --- (In reply to comment #4) I've just committed the essential patch for PR 52941 which should allow us to remove config/cpu/sh/atomicity.h now. Is is enough to simply delete the whole config/cpu/sh dir, or is there more to be done? Apparently there is more to be done: PR 53579 ;)
[Bug libstdc++/53578] include/ext/concurrence.h relies on ill-formed narrowing conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53578 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-05 00:24:31 UTC --- That stuff was a hack to get it working in a hurry, ideally we want a __gthread_mutex_destroy function. Otherwise, I can fix the sfinae check to work properly. Presumably just comparing to 0 would avoid a narrowing conversion.
[Bug target/53511] SH Target: Add support for fma patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Attachment #27547|0 |1 is obsolete|| --- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org 2012-06-05 02:41:54 UTC --- Created attachment 27558 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27558 Proposed patch This patch adds the FMA patterns and aligns the SH target with the -mfused-madd / -mno-fused-madd option handling in other targets. Kaz, if you have some time and a SH64 test env at hand, could you please check the patch on SH64? I had to touch the __builtin_sh_media_FMAC_S mapping. I think it should be OK, since the number and semantics of the insn operands is the same as before.
[Bug c/53580] New: Internal Segmentation fault in nested omp parallel, omp parallel for and omp parallel for reduction Directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53580
Bug #: 53580
Summary: Internal Segmentation fault in nested omp parallel,
omp parallel for and omp parallel for reduction
Directives
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fedediaz...@gmail.com
Created attachment 27559
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27559
Attached preprocesses source that the output demands
When trying to compile nested #pragma omp parallel, #pragma omp parallel for
and #pragma omp parallel for reduction (+:variable), the compiler throws an
internal error:segmentation fault.
test code---
#include stdio.h
#include omp.h
int main(int argc, char **argv){
int x, y, variableReduction=0;
#pragma omp parallel
#pragma omp for
for(x=0; x = 10 ; x++){
#pragma omp for reduction(+: variableReduction)
for(y=0; y = 10 ; y++){
variableReduction += 0;
}
}
return variableReduction;
}---
gcc -v
Using internal specifications.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
The command line arguments and the output is:
gcc -Wall -Wextra -fopenmp test.c -o test
test.c:12:9: warning: work-sharing region may not be closely nested inside of
work-sharing, critical, ordered, master or explicit task region [enabled by
default]
test.c:12:9: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions.
Preprocessed source stored into /tmp/cck4oOHH.out file, please attach this to
your bugreport.
Somewhat similar to Bug report 35674
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35674) but different compiler
context (i think)
Hope it's clear enough, my first bug report :-)
[Bug target/53511] SH Target: Add support for fma patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511 --- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-06-05 04:47:22 UTC --- (In reply to comment #4) This patch adds the FMA patterns and aligns the SH target with the -mfused-madd / -mno-fused-madd option handling in other targets. Make -mfused-madd no-op instead to remove for the backward compatibility. Other than that, the patch looks fine to me. I had to touch the __builtin_sh_media_FMAC_S mapping. I think it should be OK, since the number and semantics of the insn operands is the same as before. It seems that __builtin_sh_media_FMAC_S is broken on trunk in the first place, though I can test it only on sh64-elf environment now. Anyway the patch should OK in this regard.
