[Bug fortran/45513] New: BOZ kinds differently handled, F2008: BOZ in bit intrinsics
As reported by Fran,cois-Xavier at http://gcc.gnu.org/ml/fortran/2010-08/msg00484.html a) integer(kind=8) :: i i = 0 print *, kind(ior (i, zff1e)) print *, kind(ior (0_8, zff1e)) end gives different different results for the compile-time and run-time evaluation. b) F2008 allows BOZ in bit intrinsics, which need to be properly handled; for IOR(I,J) one has: * I or J can be BOZ or integers, but they can't both be BOZ. * Result Characteristics. Same as I if I is of type integer; otherwise, same as J. -- Summary: BOZ kinds differently handled, F2008: BOZ in bit intrinsics Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45513
[Bug bootstrap/45514] New: [4.6 Regression] Bootstrap broken on arm-linux in locate_neon_builtin_icode
At r163779 I get a slightly different error: /home/guerby/build/./prev-gcc/xgcc -B/home/guerby/build/./prev-gcc/ -B/n/57/guerby/install-trunk-163779/armv5tel-unknown-linux-gnueabi/bin/ -B/n/57/guerby/install-trunk-163779/armv5tel-unknown-linux-gnueabi/bin/ -B/n/57/guerby/install-trunk-163779/armv5tel-unknown-linux-gnueabi/lib/ -isystem /n/57/guerby/install-trunk-163779/armv5tel-unknown-linux-gnueabi/include -isystem /n/57/guerby/install-trunk-163779/armv5tel-unknown-linux-gnueabi/sys-include -c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/dpd -I../libdecnumber \ ../../trunk/gcc/config/arm/arm.c -o arm.o ../../trunk/gcc/config/arm/arm.c: In function 'locate_neon_builtin_icode': ../../trunk/gcc/config/arm/arm.c:18928:22: error: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat] ../../trunk/gcc/config/arm/arm.c:17984:20: note: 'itype' should be initialized ../../trunk/gcc/config/arm/arm.c:18928:22: error: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat] ../../trunk/gcc/config/arm/arm.c:17985:13: note: 'bits' should be initialized ../../trunk/gcc/config/arm/arm.c:18928:22: error: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat] ../../trunk/gcc/config/arm/arm.c:17986:24: note: 'codes' should be initialized ../../trunk/gcc/config/arm/arm.c:18928:22: error: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat] ../../trunk/gcc/config/arm/arm.c:17987:22: note: 'num_vars' should be initialized ../../trunk/gcc/config/arm/arm.c: In function 'arm_output_asm_insn': ../../trunk/gcc/config/arm/arm.c:22664:3: error: function might be possible candidate for 'gnu_printf' format attribute [-Werror=missing-format-attribute] cc1: all warnings being treated as errors make[3]: *** [arm.o] Error 1 make[3]: Leaving directory `/home/guerby/build/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/guerby/build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/guerby/build' make: *** [bootstrap] Error 2 History of failures is here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067 -- Summary: [4.6 Regression] Bootstrap broken on arm-linux in locate_neon_builtin_icode Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC build triplet: arm-linux-gnueabi GCC host triplet: arm-linux-gnueabi GCC target triplet: arm-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45514
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #12 from laurent at guerby dot net 2010-09-03 06:25 --- The bootstrap is still broken on arm-linux, I opened a new report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45514 And I'm closing this one. -- laurent at guerby dot net changed: What|Removed |Added CC||ramana at gcc dot gnu dot ||org Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug target/35507] [avr] 4.3.0: size of small funcion increases from 2 to 29 words
--- Comment #5 from abnikant dot singh at atmel dot com 2010-09-03 06:45 --- gcc version 4.6.0 20100903 (experimental) (GCC) [Head] produces 2 words: mult: /* prologue: function */ /* frame size = 0 */ /* stack size = 0 */ .L__stack_usage = 0 rcall __mulsi3 /* epilogue start */ ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35507
[Bug bootstrap/45514] [4.6 Regression] Bootstrap broken on arm-linux in locate_neon_builtin_icode
--- Comment #1 from ramana at gcc dot gnu dot org 2010-09-03 07:19 --- *** This bug has been marked as a duplicate of 45444 *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45514
[Bug bootstrap/45444] [4.6 regression] ARM bootstrap failure: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat]
--- Comment #6 from ramana at gcc dot gnu dot org 2010-09-03 07:19 --- *** Bug 45514 has been marked as a duplicate of this bug. *** -- ramana at gcc dot gnu dot org changed: What|Removed |Added CC||laurent at guerby dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45444
[Bug ada/45499] Ada bootstrap broken
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-03 07:30 --- I think for -D and -U at least the canonicalization should be joined instead of separate, because that's how people are used to write these options (which doesn't mean the tools the driver invokes shouldn't be changed to handle both). And for -I- similarly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45499
[Bug c++/45515] New: Unable to find base class constructor of templated base class
The following code fails to compile:
template class T
class Foo {
public:
Foo(int i, int j) {}
};
class Bar : public Fooint {
Bar() : Foo(0, 0) {}
};
This produces the following output:
foo.cc: In constructor ?Bar::Bar()?:
foo.cc:8: error: class ?Bar? does not have any field named ?Foo?
foo.cc:8: error: no matching function for call to ?Fooint::Foo()?
foo.cc:4: note: candidates are: FooT::Foo(int, int) [with T = int]
foo.cc:2: note: Fooint::Foo(const Fooint)
If I change line 8 to Bar() : Fooint(0, 0) {} it compiles fine. The
original code also compiles fine with clang and comeau. Tested with head gcc,
4.3, and 4.4.
--
Summary: Unable to find base class constructor of templated base
class
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andareed at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45515
[Bug fortran/44602] [F2008] EXIT: Jump to end of construct
--- Comment #6 from domob at gcc dot gnu dot org 2010-09-03 08:02 --- Subject: Bug 44602 Author: domob Date: Fri Sep 3 08:01:51 2010 New Revision: 163798 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163798 Log: 2010-09-03 Daniel Kraft d...@domob.eu PR fortran/44602 * gfortran.h (struct gfc_code): Renamed `whichloop' to `which_construct' as this is no longer restricted to loops. * parse.h (struct gfc_state_data): New field `construct'. * match.c (match_exit_cycle): Handle EXIT from non-loops. * parse.c (push_state): Set `construct' field. * resolve.c (resolve_select_type): Extend comment. * trans-stmt.c (gfc_trans_if): Add exit label. (gfc_trans_block_construct), (gfc_trans_select): Ditto. (gfc_trans_simple_do): Store exit/cycle labels on the gfc_code itself. (gfc_trans_do), (gfc_trans_do_while): Ditto. (gfc_trans_exit): Use new name `which_construct' instead of `whichloop'. (gfc_trans_cycle): Ditto. (gfc_trans_if_1): Use fold_build3_loc instead of fold_build3. 2010-09-03 Daniel Kraft d...@domob.eu PR fortran/44602 * gfortran.dg/exit_2.f08; Adapt error messages. * gfortran.dg/exit_3.f08: New test. * gfortran.dg/exit_4.f08: New test. * gfortran.dg/exit_5.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/exit_3.f08 trunk/gcc/testsuite/gfortran.dg/exit_4.f08 trunk/gcc/testsuite/gfortran.dg/exit_5.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/match.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/parse.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/exit_2.f08 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44602
[Bug fortran/44602] [F2008] EXIT: Jump to end of construct
--- Comment #7 from domob at gcc dot gnu dot org 2010-09-03 08:04 --- Fixed. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44602
[Bug fortran/34162] F2008: Allow internal procedures as actual argument
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-03 08:39 --- Asked at gcc-patches/fortran for suggestions how to implement this: http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00211.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34162
[Bug c++/45515] Unable to find base class constructor of templated base class
--- Comment #1 from andareed at gmail dot com 2010-09-03 08:41 --- Never mind, it compiles with head gcc. -- andareed at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45515
build gcc (c,c++,ada) for ia64-hp-hpux11.23 fails
I need an native gcc (c,c++,ada) for TARGET=ia64-hp-hpux11.23. Because to build and gcc (with ada) you already need a gcc (with ada), so I try to reach this by cross compiling from a linux platform (SLES11.1 with gcc 4.5.0). (I have already done this for hppa2.0w-hp-hpux11.11 , which works fine) When I start to build the cross compiler the bootstrap fails: (it fails in gcc-4.5.1/gcc/ada/gcc-interface/Makefile::2444:gnatlib: ../stamp-gnatlib-$(RTSDIR) ../stamp-gnatlib2-$(RTSDIR)) $ ../gcc-4.5.0/configure --prefix=/cross/ia/C1 --enable-languages=c,c++,ada --with-gnu-as --with-sysroot=/cross/iaroot --enable-threads --disable-nls --disable-shared --disable-bootstrap --target=ia64-hp-hpux11.23 ... make[3]: Entering directory `/cross/build/objgccC1/gcc/ada' rm -f rts/s-*.ali rm -f rts/s-*.o rm -f rts/a-*.ali rm -f rts/a-*.o rm -f rts/*.ali rm -f rts/*.o rm -f rts/*.a rm -f rts/*.sl touch ../stamp-gnatlib2-rts rm -f ../stamp-gnatlib-rts rm -rf rts mkdir -p rts chmod u+w rts ln -s /cross/build/gcc-4.5.0/gcc/ada/ada.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/calendar.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/directio.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/gnat.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/interfac.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/ioexcept.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/machcode.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/text_io.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/unchconv.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/unchdeal.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/sequenio.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/system.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/memtrack.adb rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/a-[a-o]*.adb rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/a-[p-z]*.adb rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/a-[a-o]*.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/a-[p-z]*.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/g-*.ad? rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/i-*.ad? rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/s-[a-o]*.adb rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/s-[p-z]*.adb rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/s-[a-o]*.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/s-[p-z]*.ads rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/adadecode.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/adadecode.h rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/adaint.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/adaint.h rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/argv.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/cio.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/cstreams.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/errno.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/exit.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/cal.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/ctrl_c.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/env.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/env.h rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/arit64.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/raise.h rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/raise.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/sysdep.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/aux-io.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/init.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/initialize.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/seh_init.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/final.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/tracebak.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/tb-alvms.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/tb-alvxw.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/tb-gcc.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/expect.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/mkdir.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/socket.c rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/gsocket.h rts ; ln -s /cross/build/gcc-4.5.0/gcc/ada/targext.c rts ; true rm -f rts/a-intnam.ads rts/s-inmaop.adb rts/s-intman.adb rts/s-osinte.adb rts/s-osinte.ads rts/s-osprim.adb rts/s-taprop.adb rts/s-taspri.ads rts/s-tpopsp.adb rts/system.ads rts/a-except.ads rts/a-except.adb rm -f rts/*-*-*.ads rts/*-*-*.adb ln -s /cross/build/gcc-4.5.0/gcc/ada/a-intnam-hpux.ads rts/a-intnam.ads; ln -s /cross/build/gcc-4.5.0/gcc/ada/s-inmaop-posix.adb rts/s-inmaop.adb; ln -s /cross/build/gcc-4.5.0/gcc/ada/s-intman-posix.adb rts/s-intman.adb; ln -s /cross/build/gcc-4.5.0/gcc/ada/s-osinte-posix.adb rts/s-osinte.adb; ln -s /cross/build/gcc-4.5.0/gcc/ada/s-osinte-hpux.ads rts/s-osinte.ads; ln -s /cross/build/gcc-4.5.0/gcc/ada/s-osprim-posix.adb rts/s-osprim.adb; ln -s /cross/build/gcc-4.5.0/gcc/ada/s-taprop-posix.adb rts/s-taprop.adb; ln -s /cross/build/gcc-4.5.0/gcc/ada/s-taspri-posix-noaltstack.ads rts/s-taspri.ads; ln -s /cross/build/gcc-4.5.0/gcc/ada/s-tpopsp-posix-foreign.adb rts/s-tpopsp.adb; ln -s /cross/build/gcc-4.5.0/gcc/ada/system-hpux-ia64.ads rts/system.ads; ln -s /cross/build/gcc-4.5.0/gcc/ada/a-except-2005.ads
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #13 from aoliva at gcc dot gnu dot org 2010-09-03 08:59 --- The different types arise when, say, we copyprop a const-unqualified variable into a MEM_REF that used to reference a const-qualified temp. The top-level const qualifications are irrelevant at that point, for we're dealing with rvalues of pointer types. I'm experimenting with simply dropping the TYPE_QUALS test from tree-pretty-print. This fixed the pt.c -fcompare-debug problem. Richard, is there any reason for top-level qualifiers to be relevant in MEM_REF operands? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #14 from rguenther at suse dot de 2010-09-03 09:06 --- Subject: Re: -fcompare-debug failure at -O3 On Fri, 3 Sep 2010, aoliva at gcc dot gnu dot org wrote: --- Comment #13 from aoliva at gcc dot gnu dot org 2010-09-03 08:59 --- The different types arise when, say, we copyprop a const-unqualified variable into a MEM_REF that used to reference a const-qualified temp. The top-level const qualifications are irrelevant at that point, for we're dealing with rvalues of pointer types. I'm experimenting with simply dropping the TYPE_QUALS test from tree-pretty-print. This fixed the pt.c -fcompare-debug problem. Richard, is there any reason for top-level qualifiers to be relevant in MEM_REF operands? Hmm, not really. But in the end at some point I want to drop the fancy printing of MEM_REFs. What you can do is instead of dump_generic_node (buffer, TREE_TYPE (TREE_OPERAND (node, 1)), spc, flags | TDF_SLIM, false); do dump_generic_node (buffer, TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (node, 1))), spc, flags | TDF_SLIM, false); as that is what matters. Or even better, see if the issue goes away when you change the gimplifier to use the main variant in the first place. That's sth I would prefer - not sure why I missed that. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug c++/45501] Compiler does not find template function if member is addressed with this
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-03 09:09 --- Ah, ok, thanks Jason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45501
[Bug tree-optimization/45085] [4.6 Regression] incorrect -Wuninitialized warning
--- Comment #8 from jakub at gcc dot gnu dot org 2010-09-03 09:10 --- Seems http://gcc.gnu.org/viewcvs?root=gccview=revrev=162842 has been committed, just Honza forgot to mention the PR in the ChangeLog, testcase and commit message. I certainly can't reproduce this bug with 20100811 gcc and later, while I can with 20100730. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45085
[Bug tree-optimization/45506] [4.6 Regression] tree_mem_ref_addr, at tree-ssa-address.c:278
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-03 09:28 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-09-02 19:49:24 |2010-09-03 09:28:41 date|| Summary|tree_mem_ref_addr, at tree- |[4.6 Regression] |ssa-address.c:278 |tree_mem_ref_addr, at tree- ||ssa-address.c:278 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45506
[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505
[Bug c/45502] Passing multi-dimensional array to function using C99 VLA function parameter format fails if function is inlined
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-03 09:39 --- I can reproduce it with the SUSE release, it seems to be one of the backported alias fixes that causes this (and it vanishes with -fno-strict-aliasing). Works for all FSF releases I tried. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45502
[Bug middle-end/45496] Static members of templates cause LTO to omit required code
--- Comment #24 from rguenth at gcc dot gnu dot org 2010-09-03 09:47 --- Fixed for 4.5.2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45496
[Bug middle-end/45496] Static members of templates cause LTO to omit required code
--- Comment #25 from rguenth at gcc dot gnu dot org 2010-09-03 09:48 --- Subject: Bug 45496 Author: rguenth Date: Fri Sep 3 09:47:09 2010 New Revision: 163801 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163801 Log: 2010-09-03 Richard Guenther rguent...@suse.de * lto-elf.c (validate_file): Always error if validation fails. 2010-09-03 Richard Guenther rguent...@suse.de PR lto/45496 Backport from mainline 2010-07-07 Jakub Jelinek ja...@redhat.com * lto-elf.c (ELFOSABI_NONE, ELFOSABI_LINUX): Define if not defined. (validate_file): Allow merging of ELFOSABI_NONE with ELFOSABI_LINUX objects. Modified: branches/gcc-4_5-branch/gcc/lto/ChangeLog branches/gcc-4_5-branch/gcc/lto/lto-elf.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45496
[Bug tree-optimization/45506] [4.6 Regression] tree_mem_ref_addr, at tree-ssa-address.c:278
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-03 09:51 --- Fixed by rev. 163802. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45506
[Bug debug/45500] ICE: in rtl_for_decl_init, at dwarf2out.c:16307 with -g -msse and using v16qi
--- Comment #3 from jakub at gcc dot gnu dot org 2010-09-03 09:54 --- Subject: Bug 45500 Author: jakub Date: Fri Sep 3 09:53:44 2010 New Revision: 163803 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163803 Log: PR debug/45500 * dwarf2out.c (rtl_for_decl_init): Give up for all generic vectors, not just generic vectors with BLKmode. * gcc.target/i386/pr45500.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr45500.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45500
[Bug c/45512] null pointer dereference in gcc
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-03 09:56 --- Can't reproduce this. Can you re-check with a more recent version? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45512
[Bug fortran/45516] New: [F08] allocatable compontents of recursive type
John Reid, The new features of Fortran 2008, chapter 5.3: A recursive type is permitted to be based on allocatable components. Here is a simple example of a type that holds a stack: type entry real :: value integer :: index type(entry), allocatable :: next end type entry [...] For this gfortran currently gives: type(entry), allocatable :: next 1 Error: Component at (1) must have the POINTER attribute -- Summary: [F08] allocatable compontents of recursive type Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org OtherBugsDependingO 39627 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45516
[Bug fortran/45516] [F08] allocatable compontents of recursive type
--- Comment #1 from janus at gcc dot gnu dot org 2010-09-03 09:59 ---
Here is a patch to accept the type declaration in comment #0:
Index: decl.c
===
--- decl.c (revision 163798)
+++ decl.c (working copy)
@@ -1494,11 +1494,11 @@ build_struct (const char *name, gfc_charlen *cl, g
gfc_component *c;
gfc_try t = SUCCESS;
- /* F03:C438/C439. If the current symbol is of the same derived type that
we're
- constructing, it must have the pointer attribute. */
+ /* F08:C440. If the current symbol is of the same derived type that we're
+ constructing, it must be POINTER or ALLOCATABLE. */
if ((current_ts.type == BT_DERIVED || current_ts.type == BT_CLASS)
current_ts.u.derived == gfc_current_block ()
- current_attr.pointer == 0)
+ !current_attr.pointer !current_attr.allocatable)
{
gfc_error (Component at %C must have the POINTER attribute);
return FAILURE;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45516
[Bug debug/45500] ICE: in rtl_for_decl_init, at dwarf2out.c:16307 with -g -msse and using v16qi
--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-03 10:15 --- Subject: Bug 45500 Author: jakub Date: Fri Sep 3 10:14:43 2010 New Revision: 163807 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163807 Log: PR debug/45500 * dwarf2out.c (rtl_for_decl_init): Give up for all generic vectors, not just generic vectors with BLKmode. * gcc.target/i386/pr45500.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr45500.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/dwarf2out.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45500
[Bug fortran/45507] [4.6 Regression] Bogus Error: Can't convert TYPE(c_ptr) to INTEGER(4)
--- Comment #4 from janus at gcc dot gnu dot org 2010-09-03 10:29 --- Mine. -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-09-02 19:45:28 |2010-09-03 10:29:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45507
[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294
--- Comment #2 from ramana at gcc dot gnu dot org 2010-09-03 10:43 --- I don't see this with an arm-linux-gnu toolchain for r163798. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511
[Bug c++/45510] Bug with anonymous unions and bit-fields
--- Comment #8 from paolo dot carlini at oracle dot com 2010-09-03 10:46 --- If you look at the actual Standard, both alignment and allocation of bit-fields are implementation defined. Thus, as far as I can see, at best we are talking about non-portable implementation defined behavior. If you want my advice, try to stay away from those tricks, with and without anonymous struct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45510
[Bug debug/45500] ICE: in rtl_for_decl_init, at dwarf2out.c:16307 with -g -msse and using v16qi
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-03 10:50 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45500
[Bug debug/45517] New: ICE in output_die
GCC 4.[1234] ICE in output_die on:
// { dg-do compile }
// { dg-options -g }
struct S
{
virtual ~S () {}
};
void
foo ()
{
struct T
{
T () {}
void bar ()
{
struct U : public S
{
T t;
U () : t () {}
};
}
} t;
}
4.5/trunk works.
--
Summary: ICE in output_die
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45517
[Bug ada/45499] Ada bootstrap broken
--- Comment #6 from joseph at codesourcery dot com 2010-09-03 11:17 --- Subject: Re: Ada bootstrap broken On Fri, 3 Sep 2010, hjl dot tools at gmail dot com wrote: (In reply to comment #3) Subject: Re: Ada bootstrap broken I don't see where a -Y option would come from or what would accept it. Y can be any letter from A to Z and a to z. See PR 45504 for an example. But the changes to canonical options (to preferentially use separate arguments) only affect options marked with both Joined and Separate in a .opt file. My understanding is that cc1_options is not used for Ada and so the only specs relevant to passing things to gnat1 are those in gcc-interface/lang-specs.h so this should only ever affect -I. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45499
[Bug tree-optimization/45427] Number of iteration analysis bogus
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-09-03 11:32 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
[Bug ada/45499] Ada bootstrap broken
--- Comment #7 from joseph at codesourcery dot com 2010-09-03 11:38 --- Subject: Re: Ada bootstrap broken On Fri, 3 Sep 2010, jakub at gcc dot gnu dot org wrote: I think for -D and -U at least the canonicalization should be joined instead of separate, because that's how people are used to write these options (which doesn't mean the tools the driver invokes shouldn't be changed to handle both). And for -I- similarly. The canonicalization is an internal convention, except where GCC is passing options directly to tools not included in GCC such as the linker. I chose separate as the preferred canonicalization on the basis of POSIX generally only having the separate forms of operands. It looks like the issue is not in fact how the driver passes -I options to gnat1 but how gnat1 internally reconstitutes an argv array from decoded options for use by the Ada parts of gnat1 that expect such an array. So I'm testing a patch local to the ada/gcc-interface code that only adjusts that reconstitution, only for -I. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45499
[Bug fortran/45516] [F08] allocatable compontents of recursive type
--- Comment #2 from burnus at gcc dot gnu dot org 2010-09-03 12:12 --- (In reply to comment #1) Here is a patch to accept the type declaration in comment #0: Well, you at least need to use gfc_notify_std(GFC_STD_F2008, ... And one should make sure that the allocation/clean up works as expected. * * * As follow up to the initial implementation, one should implement at some point the following, which does not do a deep copy but simply appends the old data. (Example from the mentioned article.) type entry real :: value integer :: index type(entry), allocatable :: next end type entry type (entry), allocatable :: top top = entry ( new_value, new_index, top ) (The last line assume reallocate on assignment; I think it already works for derived types with structure constructor; I know that it does not yet work for intrinsic types - not does it work on other assignment than structure constructors.) The classical way to append a new item is the following, which should avoid a deep copy (check!): type (entry), allocatable :: top, temp temp = entry ( new_value, new_index, temp ) call move_alloc(top,temp%next) call move_alloc(temp,top) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||domob at gcc dot gnu dot ||org, burnus at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45516
[Bug lto/44812] m32 lto produces non-relocatable subtraction expression errors
--- Comment #32 from hubicka at gcc dot gnu dot org 2010-09-03 12:26 --- Subject: Bug 44812 Author: hubicka Date: Fri Sep 3 12:26:24 2010 New Revision: 163811 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163811 Log: PR lto/44812 * lto-cgraph.c (intput_node, input_varpool_node): Set DECL_EXTERNAL on functions/variables in other partition. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-cgraph.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44812
[Bug c/45502] Passing multi-dimensional array to function using C99 VLA function parameter format fails if function is inlined
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-09-03 12:55 --- A fix will appear in the repositories beyond http://download.opensuse.org/repositories/devel:/gcc/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45502
[Bug target/45511] ICE in neon_valid_immediate, at config/arm/arm.c:8294
--- Comment #3 from rmansfield at qnx dot com 2010-09-03 13:02 --- I can still reproduce it with r163811. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511
[Bug bootstrap/45518] New: [4.6 regression] bootstrap failure on sparc64-unknown-linux-gnu
I'm seeing a bootstrap failure on the compile farm's gcc63 machine. I realize
there've been several logs submitted to gcc-testresults from Laurent's
autotesters, but those testers configured with somewhat different options than
I did. I'm configuring with:
--disable-lib{ssp,mudflap,gomp} --enable-languages=c --disable-nls
--enable-threads=posix
whereas Laurent passes --with-cpu=v8 and --disable-multilib.
Bootstrapping fails starting at r163383, Bernd's 4-insn combine change, when
configuring support libraries (libiberty, zlib, libdecnumber) for stage3. I
double-checked subsequent revisions that fix other PRs from r163383 (e.g.
r163546) and those did not help either. I tried --disable-multilib and/or
--with-cpu=niagara and that did not help.
I'm unsure of what other information to provide, but can provide more
information on request.
--
Summary: [4.6 regression] bootstrap failure on sparc64-unknown-
linux-gnu
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: froydnj at gcc dot gnu dot org
GCC build triplet: sparc64-unknown-linux-gnu
GCC host triplet: sparc64-unknown-linux-gnu
GCC target triplet: sparc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45518
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #21 from thutt at vmware dot com 2010-09-03 13:07 --- (In reply to comment #8) Is 'coverity' a compiler? I don't think so. Coverity is not a tool that generates code, but it does perform all the syntactic semantic analysis that a code-generating compiler will. Then, it goes beyond that with further static analysis. Do you have actual examples of *compilers* which, everything taken into account, decided to make sure this case is worth warning? That's the worst argument I've read in a long time. Do we need proof that another compiler does something before the gcc team will take it up now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug fortran/34162] F2008: Allow internal procedures as actual argument
--- Comment #3 from domob at gcc dot gnu dot org 2010-09-03 13:11 --- Subject: Bug 34162 Author: domob Date: Fri Sep 3 13:10:40 2010 New Revision: 163813 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163813 Log: 2010-09-03 Daniel Kraft d...@domob.eu PR fortran/34162 * resolve.c (resolve_actual_arglist): Allow internal procedure as actual argument with Fortran 2008. 2010-09-03 Daniel Kraft d...@domob.eu PR fortran/34162 * gfortran.dg/internal_dummy_1.f90: Add -std=f2003. * gfortran.dg/internal_dummy_2.f08: New test. * gfortran.dg/internal_dummy_3.f08: New test. * gfortran.dg/internal_dummy_4.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/internal_dummy_2.f08 trunk/gcc/testsuite/gfortran.dg/internal_dummy_3.f08 trunk/gcc/testsuite/gfortran.dg/internal_dummy_4.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/internal_dummy_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34162
[Bug fortran/34162] F2008: Allow internal procedures as actual argument
--- Comment #4 from domob at gcc dot gnu dot org 2010-09-03 13:11 --- Fixed. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34162
[Bug java/45504] [4.6 Regression] Failed to bootstrap
--- Comment #6 from hjl at gcc dot gnu dot org 2010-09-03 13:13 --- Subject: Bug 45504 Author: hjl Date: Fri Sep 3 13:13:10 2010 New Revision: 163814 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163814 Log: Check -D XXX=YYY. 2010-09-03 H.J. Lu hongjiu...@intel.com PR java/45504 * jvgenmain.c (main): Check -D XXX=YYY. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/jvgenmain.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45504
[Bug ada/45499] Ada bootstrap broken
--- Comment #8 from jsm28 at gcc dot gnu dot org 2010-09-03 13:18 --- Subject: Bug 45499 Author: jsm28 Date: Fri Sep 3 13:17:46 2010 New Revision: 163817 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163817 Log: PR ada/45499 * gcc-interface/misc.c (gnat_init_options): Allow options with empty canonical form. Generate a single save_argv element from -I options. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/misc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45499
[Bug bootstrap/45519] New: [4.6 regression] Failed to bootstrap
On Linux/x86, revision 163804 gave: /home/regress/tbox/svn-gcc/libgcc/../gcc/unwind-dw2-fde-glibc.c: In function '_Unwind_IteratePhdrCallback': /home/regress/tbox/svn-gcc/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: error: Invalid first operand of MEM_REF. D.10501_117 /home/regress/tbox/svn-gcc/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: note: in statement D.11538_238 = MEM[(struct Elf32_Dyn *)D.10501_117 + 8B]; /home/regress/tbox/svn-gcc/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [unwind-dw2-fde-glibc.o] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/home/regress/tbox/native/build/i686-pc-linux-gnu/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/home/regress/tbox/native/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/regress/tbox/native/build' make: *** [bootstrap] Error 2 Revision 163799 is OK. It may be caused by revision 163802: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00093.html -- Summary: [4.6 regression] Failed to bootstrap Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug ada/45499] Ada bootstrap broken
--- Comment #9 from jsm28 at gcc dot gnu dot org 2010-09-03 13:21 --- Fixed for 4.6. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.0 Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45499
[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-03 13:22 --- Can you attach preprocessed source that allows reproducing on x86_64? Thx. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-03 13:22:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug bootstrap/45518] [4.6 regression] bootstrap failure on sparc64-unknown-linux-gnu
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-03 13:27 --- How does it fail? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45518
[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-03 13:31 --- [...@gnu-1 gcc]$ ./xgcc -B./ -m32 -O2 -S /tmp/pr45519.i ../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c: In function \u2018_Unwind_IteratePhdrCallback\u2019: ../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: error: Invalid first operand of MEM_REF. D.11075_117 ../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: note: in statement D.12093_230 = MEM[(struct Elf32_Dyn *)D.11075_117 + 8B]; ../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-03 13:32 --- Created an attachment (id=21682) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21682action=view) A testcase [...@gnu-1 gcc]$ ./xgcc -B./ -m32 -O2 -S /tmp/pr45519.i ../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c: In function \u2018_Unwind_IteratePhdrCallback\u2019: ../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: error: Invalid first operand of MEM_REF. D.11075_117 ../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: note: in statement D.12093_230 = MEM[(struct Elf32_Dyn *)D.11075_117 + 8B]; ../../../src-trunk/libgcc/../gcc/unwind-dw2-fde-glibc.c:134:1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug bootstrap/45518] [4.6 regression] bootstrap failure on sparc64-unknown-linux-gnu
--- Comment #2 from froydnj at codesourcery dot com 2010-09-03 13:34
---
Subject: Re: [4.6 regression] bootstrap failure on
sparc64-unknown-linux-gnu
configure says:
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: in
home/froydnj/build-mainline/intl':
configure: error: cannot run C compiled programs.
The compiled program for:
int
main (void)
{
return 0;
}
segfaults. gdb says:
(gdb) run
Starting program: /home/froydnj/build-mainline/intl/a.out
Program received signal SIGSEGV, Segmentation fault.
0x0010059c in __do_global_ctors_aux ()
Current language: auto
The current source language is auto; currently asm.
(gdb) where
#0 0x0010059c in __do_global_ctors_aux ()
#1 0x001003b0 in _init ()
#2 0x00100518 in __libc_csu_init ()
#3 0xf80100157fd0 in __libc_start_main () from /lib64/libc.so.6
#4 0x001003f4 in _start ()
(gdb)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45518
[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-03 13:43 ---
Reduced testcase:
typedef struct { unsigned int p_vaddr; } Elf32_Phdr;
typedef struct { int d_tag; } Elf32_Dyn;
typedef unsigned _Unwind_Ptr __attribute__((__mode__(__pointer__)));
int
_Unwind_IteratePhdrCallback (const Elf32_Phdr *p_dynamic,
_Unwind_Ptr load_base)
{
Elf32_Dyn *dyn = (Elf32_Dyn *) ((p_dynamic-p_vaddr) + (load_base));
for (; dyn-d_tag != 0 ; dyn++)
if (dyn-d_tag == 3)
return 0;
return 1;
}
pr45519.3.i: In function '_Unwind_IteratePhdrCallback':
pr45519.3.i:11:1: error: Invalid first operand of MEM_REF.
D.2729_7
pr45519.3.i:11:1: note: in statement
D.2745_1 = MEM[(struct Elf32_Dyn *)D.2729_7 + 4B];
pr45519.3.i:11:1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Other reduced testcase:
typedef struct { unsigned int p_vaddr; } Elf32_Phdr;
typedef struct { int d_tag; } Elf32_Dyn;
int
_Unwind_IteratePhdrCallback (const Elf32_Phdr *p_dynamic,
unsigned int load_base)
{
Elf32_Dyn *dyn = (Elf32_Dyn *) ((p_dynamic-p_vaddr) + (load_base));
for (; dyn-d_tag != 0 ; dyn++)
if (dyn-d_tag == 3)
return 0;
return 1;
}
pr45519.3.i:4:1: internal compiler error: in build2_stat, at tree.c:3724
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug c/42884] GCC (v4.3.3) fails to detect uninitialized variable
--- Comment #22 from manu at gcc dot gnu dot org 2010-09-03 14:06 --- (In reply to comment #21) (In reply to comment #8) Is 'coverity' a compiler? I don't think so. Coverity is not a tool that generates code, but it does perform all the syntactic semantic analysis that a code-generating compiler will. Then, it goes beyond that with further static analysis. GCC is not designed to be used as a static analysis tool. This doesn't mean it wouldn't be interesting to be able to reuse GCC analysis modules for doing that. Other compilers have shown that it is possible and a desirable feature [*]. However, GCC is not designed to be reusable, there is none working on a similar thing for GCC, and no sign that any existing GCC developer will start working on it in the near future. Unless someone new starts working on this, don't expect anything similar from GCC. [*] http://clang-analyzer.llvm.org/ Do you have actual examples of *compilers* which, everything taken into account, decided to make sure this case is worth warning? That's the worst argument I've read in a long time. Do we need proof that another compiler does something before the gcc team will take it up now? There is more work to do in GCC than people willing (or being paid) to do it, so if there is some indication that some feature may be impossible or too expensive to implement, existing GCC developers will probably focus their efforts on something else more feasible. If you can show that another compiler is able to do it in an efficient way, that shows that it is feasible. As far as I know, GCC has always been a very conservative compiler in terms of features, not a source of innovation. So yes, showing a working implementation seems to be a necessary condition (but not a sufficient one). In fact, it is common practice to check what other compilers do in order to verify a bug, and it is useful information in bug reports. I am sorry for this flamewar. I hope I clarified all the issues and the wiki [**] contains a more detailed discussion about the technical issues related to uninitialized warnings in case anyone is willing to help to solve them. [**] http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42884
[Bug c/45512] null pointer dereference in gcc
--- Comment #2 from regehr at cs dot utah dot edu 2010-09-03 14:20 --- No crash from r163817, thanks! -- regehr at cs dot utah dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45512
[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-09-03 14:21 ---
Hmhm, IVOPTs expands crap into arguments.
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c (revision 163817)
+++ gcc/tree-ssa-loop-ivopts.c (working copy)
@@ -1023,6 +1023,11 @@ find_bivs (struct ivopts_data *data)
type = TREE_TYPE (PHI_RESULT (phi));
base = fold_convert (type, base);
+ STRIP_USELESS_TYPE_CONVERSION (base);
+ if (CONVERT_EXPR_P (base)
+ (POINTER_TYPE_P (TREE_TYPE (base))
+ != POINTER_TYPE_P (TREE_OPERAND (base, 0
+ continue;
if (step)
{
if (POINTER_TYPE_P (type))
fixes the testcase, I am bootstrapping and testing this on x86_64 as a
short-term fix but have to think about it some more.
Can you check if 32bit bootstrap succeeds with that?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug target/45476] libgcc should contain TCmode functions
--- Comment #9 from uros at gcc dot gnu dot org 2010-09-03 14:23 --- Subject: Bug 45476 Author: uros Date: Fri Sep 3 14:23:05 2010 New Revision: 163819 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163819 Log: libgcc/ChangeLog: PR target/45476 * Makefile.in (sifuncs, difuncs, tifuncs): Filter out LIB2FUNCS_EXCLUDE functions. gcc/ChangeLog: PR target/45476 * config/i386/t-darwin (LIB2FUNCS_EXCLUDE): New. * config/i386/darwin.h (LIBGCC2_HAS_TF_MODE, LIBGCC2_TF_CEXT, TF_SIZE): New defines. gcc/testsuite/ChangeLog: PR target/45476 * gcc.target/i386/float128-1.c: Enable for all x86 targets. * gcc.target/i386/float128-2.c: Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/darwin.h trunk/gcc/config/i386/t-darwin trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/float128-1.c trunk/gcc/testsuite/gcc.target/i386/float128-2.c trunk/libgcc/ChangeLog trunk/libgcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45476
[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-03 14:33 --- Created an attachment (id=21683) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21683action=view) alternate fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug tree-optimization/45506] [4.6 Regression] tree_mem_ref_addr, at tree-ssa-address.c:278
--- Comment #5 from hjl at gcc dot gnu dot org 2010-09-03 14:41 --- Subject: Bug 45506 Author: hjl Date: Fri Sep 3 14:40:36 2010 New Revision: 163821 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163821 Log: Add gcc.dg/pr45506.c. 2010-09-03 H.J. Lu hongjiu...@intel.com PR tree-optimization/45506 * gcc.dg/pr45506.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr45506.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45506
[Bug c++/45520] New: Regression: compiler segmentation fault on decltype from a dereferenced map iterator
The compiler says: main.cc:7:35: internal compiler error: Segmentation fault
The map must be a class member to reproduce the bug.
If the decltype is not in a lambda, but a method argument, a different message
appears:
main.cc:6:32: internal compiler error: in tree_low_cst, at tree.c:6328
This code compiled correctly with g++ 4.5.0.
File content:
#include map
struct S {
std::map void*, int Map;
void f() {
auto lambda=[](decltype(*Map.begin()) i) { };
}
};
--
Summary: Regression: compiler segmentation fault on decltype from
a dereferenced map iterator
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: qduaty at gmail dot com
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45520
[Bug middle-end/45415] [4.6 Regression] ICE in partition_view_bitmap, at tree-ssa-live.c:334
--- Comment #4 from matz at gcc dot gnu dot org 2010-09-03 14:43 --- Subject: Bug 45415 Author: matz Date: Fri Sep 3 14:42:46 2010 New Revision: 163822 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163822 Log: PR middle-end/45415 * tree-sra.c (sra_modify_assign): If we modify the statement, say so. * tree-ssa.c (verify_ssa): Check number of operands and links per statement to agree. testsuite/ PR middle-end/45415 * gcc.dg/pr45415.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr45415.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c trunk/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45415
[Bug c++/45520] [C++0x] Regression: compiler segmentation fault on decltype from a dereferenced map iterator
--- Comment #1 from paolo dot carlini at oracle dot com 2010-09-03 14:44 --- Let's ask Jason to have a look. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org Summary|Regression: compiler|[C++0x] Regression: compiler |segmentation fault on |segmentation fault on |decltype from a dereferenced|decltype from a dereferenced |map iterator|map iterator http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45520
[Bug c++/45510] Bug with anonymous unions and bit-fields
--- Comment #9 from runipg at broadcom dot com 2010-09-03 14:45 --- Subject: Re: Bug with anonymous unions and bit-fields Thank you so much. You can close this bug if you wish. -Runip On 03-Sep-2010, at 3:47 AM, paolo dot carlini at oracle dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #8 from paolo dot carlini at oracle dot com 2010-09-03 10:46 --- If you look at the actual Standard, both alignment and allocation of bit-fields are implementation defined. Thus, as far as I can see, at best we are talking about non-portable implementation defined behavior. If you want my advice, try to stay away from those tricks, with and without anonymous struct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45510 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45510
[Bug middle-end/45415] [4.6 Regression] ICE in partition_view_bitmap, at tree-ssa-live.c:334
--- Comment #5 from matz at gcc dot gnu dot org 2010-09-03 14:46 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45415
[Bug middle-end/45484] Invalid memory access in gcc.c-torture/execute/builtins/sprintf-chk.c
--- Comment #23 from jakub at gcc dot gnu dot org 2010-09-03 14:47 --- Subject: Bug 45484 Author: jakub Date: Fri Sep 3 14:46:39 2010 New Revision: 163823 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163823 Log: PR middle-end/45484 * dwarf2out.c (flush_queued_reg_saves): Rename to... (dwarf2out_flush_queued_reg_saves): ... this. No longer static. (dwarf2out_frame_debug_expr, dwarf2out_frame_debug): Adjust callers. * dwarf2out.h (dwarf2out_flush_queued_reg_saves): New prototype. * config/i386/i386.c (output_set_got): Call it. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/dwarf2out.c trunk/gcc/dwarf2out.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45484
[Bug middle-end/45484] Invalid memory access in gcc.c-torture/execute/builtins/sprintf-chk.c
--- Comment #24 from jakub at gcc dot gnu dot org 2010-09-03 14:50 --- Subject: Bug 45484 Author: jakub Date: Fri Sep 3 14:50:20 2010 New Revision: 163824 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163824 Log: PR middle-end/45484 * dwarf2out.c (flush_queued_reg_saves): Rename to... (dwarf2out_flush_queued_reg_saves): ... this. No longer static. (dwarf2out_frame_debug): Adjust callers. * dwarf2out.h (dwarf2out_flush_queued_reg_saves): New prototype. * config/i386/i386.c (output_set_got): Call it. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/i386.c branches/gcc-4_5-branch/gcc/dwarf2out.c branches/gcc-4_5-branch/gcc/dwarf2out.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45484
[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap
--- Comment #7 from hjl dot tools at gmail dot com 2010-09-03 14:52 --- (In reply to comment #6) Created an attachment (id=21683) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21683action=view) [edit] alternate fix Doesn't work on Linux/x86. I got /export/gnu/import/git/gcc/libgcc/../gcc/libgcov.c: In function \u2018__gcov_merge_single\u2019: /export/gnu/import/git/gcc/libgcc/../gcc/libgcov.c:636:1: internal compiler error: in fold_binary_loc, at fold-const.c:9411 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [_gcov_merge_single.o] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug fortran/45521] New: Fortran 2008: GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE
As the introduction of Fortran 2008 mentions: - ALLOCATABLE and POINTER attributes are used in generic resolution. - Procedureness of a dummy argument is used in generic resolution. Or as The new features of Fortran 2008 puts it: A pair of specific procedures in a generic interface are permitted to be distinguishable by virtue of a pointer argument without intent in of one corresponding to an allocatable argument of the other or a data argument of one corresponding to a procedure argument of the other. Fortran 2008's 12.4.3.4.5 Restrictions on generic declarations has Two dummy arguments are distinguishable if - one is a procedure and the other is a data object, - they are both data objects or known to be functions, and neither is TKR compatible with the other, - one has the ALLOCATABLE attribute and the other has the POINTER attribute, or - one is a function with nonzero rank and the other is not known to be a function. Interpretation request F08/0001 / 10-145 changes this (EDITS to 10-007) '[286:4] In 12.4.3.4.5p3, after the other has the POINTER attribute, Insert and not the INTENT(IN) attribute.' Cf. http://j3-fortran.org/doc/meeting/193/10-199.txt Fortran 2003 just had (16.2.3 Restrictions on generic declarations): Two dummy arguments are distinguishable if neither is a subroutine and neither is TKR compatible (5.1.1.2) with the other. -- Summary: Fortran 2008: GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 39627 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45521
[Bug libstdc++/45347] concurrence.h: In constructor '__gnu_cxx::__cond::__cond()': /home/jayk/obj/gcc451/alphaev67-dec-osf5.1/libstdc++-v3/include/ext/concurrence.h:276:29: warning: missing initialize
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-03 15:05 --- Thus, Jon, are we just missing a #pragma GCC system_header at the beginning of that file? In case, just add it and close the PR? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45347
[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap
--- Comment #8 from hjl dot tools at gmail dot com 2010-09-03 15:37 ---
(In reply to comment #5)
Hmhm, IVOPTs expands crap into arguments.
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c (revision 163817)
+++ gcc/tree-ssa-loop-ivopts.c (working copy)
@@ -1023,6 +1023,11 @@ find_bivs (struct ivopts_data *data)
type = TREE_TYPE (PHI_RESULT (phi));
base = fold_convert (type, base);
+ STRIP_USELESS_TYPE_CONVERSION (base);
+ if (CONVERT_EXPR_P (base)
+ (POINTER_TYPE_P (TREE_TYPE (base))
+ != POINTER_TYPE_P (TREE_OPERAND (base, 0
+ continue;
if (step)
{
if (POINTER_TYPE_P (type))
fixes the testcase, I am bootstrapping and testing this on x86_64 as a
short-term fix but have to think about it some more.
Can you check if 32bit bootstrap succeeds with that?
I can bootstrap C with this one on Linux/x86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug debug/41063] ICE in output_die
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-03 15:44 --- *** Bug 45517 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41063
[Bug debug/45517] ICE in output_die
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-03 15:44 --- *** This bug has been marked as a duplicate of 41063 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45517
[Bug tree-optimization/45522] New: VRP misses oppurtunity for statement folding.
Hi, compiling the attached testcase (reduced from tree.c) with -O2 leads to vrp folding: if (D.2762_2 == 6) goto bb 3; else goto bb 9; bb 3: D.2766_5 = (int) D.2762_2; D.2767_6 = tree_code_type[D.2766_5]; into D.2762_2 = type_1(D)-base.code; if (D.2762_2 == 6) goto bb 3; else goto bb 9; bb 3: D.2766_5 = 6; D.2767_6 = tree_code_type[6]; this is good transform, however tree_code_type is constant initialized array and we miss possibility to fold it into constant until expansion triggering code in expr.c I would like to retire. We can fold tree_code_type[6], so apparently just no one calls fold_gimple_stmt on it? -- Summary: VRP misses oppurtunity for statement folding. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hubicka at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45522
[Bug tree-optimization/45522] VRP misses oppurtunity for statement folding.
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-09-03 15:59 --- Created an attachment (id=21684) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21684action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45522
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #24 from ro at gcc dot gnu dot org 2010-09-03 16:03 --- Subject: Bug 42843 Author: ro Date: Fri Sep 3 16:02:37 2010 New Revision: 163833 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163833 Log: PR testsuite/42843 * Makefile.in (PLUGINCC): Define in terms of @CC@ / @CXX@ (PLUGINCFLAGS): Define in terms of @CFLAGS@ / @CXXFLAGS@ Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug fortran/45159] Unnecessary temporaries
--- Comment #21 from tkoenig at gcc dot gnu dot org 2010-09-03 16:17 --- Subject: Bug 45159 Author: tkoenig Date: Fri Sep 3 16:16:34 2010 New Revision: 163834 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163834 Log: 2010-09-03 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/45159 * dependency.c (gfc_deb_compare_expr): Compare equal for equal arglists for pure user functions, or for those intrinsic functions which are also pure. * intrinsics.c (add_conv): Mark conversion functions as pure. (add_char_conversions): Likewise. 2010-09-03 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/45159 * gfortran.dg/dependency_34.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_34.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45159
inlining bug gcc
Bug Report:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-6'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --with-tune=generic --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.4 (Debian 4.3.4-6)
IInlining bug :
The value set within one inline function is reset to another value.
The value is checked by using another inline function within the set function
iinline void setFD(int32_t fd) {
_fd = fd;
COUT_2 DescrInfo::setIntDescr IO= this FD=[ fd , _fd
]\n;
COUT_2.flush();
DescrInfo::fd();
// The value of _fd when accessed within fd() is equal to 0; it is correct
within this inline function.
}
Regards,
Pierre Innocent
babel...@yahoo.com
d...@tsert.com
[Bug tree-optimization/45522] VRP misses oppurtunity for statement folding.
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-09-03 16:33 --- OK, the problem seems to be that fold_stmt seems to make no serious attempt to fold constant references. There is some code in maybe_fold_reference that seems to partly duplicate fold_const_aggregate_ref however. What is reason for that? The following patch solves the problem, I am looking what other testcases I can find. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45522
[Bug tree-optimization/45522] VRP misses oppurtunity for statement folding.
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-09-03 16:34 --- Created an attachment (id=21685) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21685action=view) patch for better folding -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45522
[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap
--- Comment #9 from hjl dot tools at gmail dot com 2010-09-03 16:48 --- It also failed on Linux/ia64 with similar error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug c++/45523] New: Failure to bind auto variable to function template instance
The following code:
template typename T void foo();
void f() {auto g = fooint;}
fails to compile in GCC 4.5.0's C++0x mode with the following error:
foo.cpp: In function void f():
foo.cpp:2:20: error: g has incomplete type
Trying different variants of this code, it appears that GCC believes that
fooint is an ambiguous overloaded function, while there is only one matching
function.
--
Summary: Failure to bind auto variable to function template
instance
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jewillco at osl dot iu dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45523
[Bug c++/45523] Failure to bind auto variable to function template instance
--- Comment #1 from jewillco at osl dot iu dot edu 2010-09-03 17:08 --- Created an attachment (id=21686) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21686action=view) File containing test case in error report -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45523
[Bug bootstrap/45519] [4.6 regression] Failed to bootstrap
--- Comment #10 from hjl dot tools at gmail dot com 2010-09-03 17:09
---
(In reply to comment #8)
(In reply to comment #5)
Hmhm, IVOPTs expands crap into arguments.
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c (revision 163817)
+++ gcc/tree-ssa-loop-ivopts.c (working copy)
@@ -1023,6 +1023,11 @@ find_bivs (struct ivopts_data *data)
type = TREE_TYPE (PHI_RESULT (phi));
base = fold_convert (type, base);
+ STRIP_USELESS_TYPE_CONVERSION (base);
+ if (CONVERT_EXPR_P (base)
+ (POINTER_TYPE_P (TREE_TYPE (base))
+ != POINTER_TYPE_P (TREE_OPERAND (base, 0
+ continue;
if (step)
{
if (POINTER_TYPE_P (type))
fixes the testcase, I am bootstrapping and testing this on x86_64 as a
short-term fix but have to think about it some more.
Can you check if 32bit bootstrap succeeds with that?
I can bootstrap C with this one on Linux/x86.
With default languages, I got one regression:
Executing on host: /export/build/gnu/gcc-32bit/build-i686-linux/gcc/xgcc
-B/export/build/gnu/gcc-32bit/build-i686-linux/gcc/
/net/gnu-6/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr38240.c
-ansi -pedantic-errors -S -o pr38240.s(timeout = 300)
/net/gnu-6/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr38240.c:
In function 'g':^M
/net/gnu-6/export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/pr38240.c:8:21:
internal compiler error: in convert_move, at expr.c:326^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See http://gcc.gnu.org/bugs.html for instructions.^M
compiler exited with status 1
with revision 163817 plus the fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45519
[Bug c++/45523] [C++0x] Failure to bind auto variable to function template instance
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-03 17:10 --- Let's add Jason in CC about this one too. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org Summary|Failure to bind auto|[C++0x] Failure to bind auto |variable to function|variable to function |template instance |template instance http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45523
[Bug tree-optimization/45421] [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-03 17:23 --- Subject: Re: [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table I'm now running an mips-sgi-irix6.5 bootstrap with Ada included with this patch. Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45421
[Bug target/45524] New: r163815/r163816 produces new regressions on x86_64-apple-darwin10
The new commits... Author: krebbel Date: Fri Sep 3 13:14:14 2010 New Revision: 163815 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163815 Log: gcc/ 2010-09-03 Andreas Krebbel andreas.kreb...@de.ibm.com * configure.ac: Use the GCC_AC_ENABLE_DECIMAL_FLOAT macro. * Makefile.in: Add aclocal.m4 dependency to dfp.m4. * configure: Regenerate. * aclocal.m4: Regenerate. config/ 2010-09-03 Andreas Krebbel andreas.kreb...@de.ibm.com * dfp.m4: New file. libdecnumber/ 2010-09-03 Andreas Krebbel andreas.kreb...@de.ibm.com * configure.ac: Use the GCC_AC_ENABLE_DECIMAL_FLOAT macro. * Makefile.in: Add aclocal.m4 dependency to dfp.m4. * configure: Regenerate. * aclocal.m4: Regenerate. libgcc/ 2010-09-03 Andreas Krebbel andreas.kreb...@de.ibm.com * configure.ac: Use the GCC_AC_ENABLE_DECIMAL_FLOAT macro. Include dfp.m4. * configure: Regenerate. Author: krebbel Date: Fri Sep 3 13:16:24 2010 New Revision: 163816 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163816 Log: gcc/ 2010-09-03 Andreas Krebbel andreas.kreb...@de.ibm.com * configure: Regenerate. * aclocal.m4: Regenerate. libdecnumber/ 2010-09-03 Andreas Krebbel andreas.kreb...@de.ibm.com * configure: Regenerate. * aclocal.m4: Regenerate. libgcc/ 2010-09-03 Andreas Krebbel andreas.kreb...@de.ibm.com * configure: Regenerate. produce new regressions at -m32/-m64 on x86_64-apple-darwin10 of... FAIL: c-c++-common/dfp/func-vararg-mixed-2.c (test for excess errors) WARNING: c-c++-common/dfp/func-vararg-mixed-2.c compilation failed to produce executable FAIL: c-c++-common/dfp/pr36800.c (test for excess errors) WARNING: c-c++-common/dfp/pr36800.c compilation failed to produce executable FAIL: c-c++-common/dfp/pr39034.c (test for excess errors) WARNING: c-c++-common/dfp/pr39034.c compilation failed to produce executable FAIL: c-c++-common/dfp/pr39035.c (test for excess errors) WARNING: c-c++-common/dfp/pr39035.c compilation failed to produce executable FAIL: gcc.target/i386/pr32065-2.c (test for excess errors) WARNING: gcc.target/i386/pr32065-2.c compilation failed to produce executable These are of the form... Executing on host: /Users/howarth/darwin_objdir/gcc/xgcc -B/Users/howarth/darwin_objdir/gcc/ /Users/howarth/gcc/gcc/testsuite/c-c++-common/dfp/func-vararg-mixed-2.c -mpreferred-stack-boundary=2 -lm -m32 -o ./func-vararg-mixed-2.exe (timeout = 300) Undefined symbols: ___dpd_truncddsd2, referenced from: _vararg_d64 in ccSemHJT.o ___dpd_nesd2, referenced from: _main in ccSemHJT.o ___dpd_nedd2, referenced from: _main in ccSemHJT.o ___dpd_netd2, referenced from: _main in ccSemHJT.o ___dpd_extendsddd2, referenced from: _main in ccSemHJT.o ld: symbol(s) not found -- Summary: r163815/r163816 produces new regressions on x86_64- apple-darwin10 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug fortran/45525] New: gfortran.dg/dummy_procedure_1.f90 failed
On Linux/x86-64, I got
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/dummy_procedure_1.f90:39.10:^M
^M
call s1(i) ! { dg-error Expected a procedure for argument }^M
1^M
Error: Expected a procedure for argument 'f' at (1)^M
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/dummy_procedure_1.f90:43.10:^M
^M
call s1(z) ! { dg-error Expected a procedure for argument }^M
1^M
Error: Expected a procedure for argument 'f' at (1)^M
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/dummy_procedure_1.f90:44.10:^M
^M
call s2(x) ! { dg-error Invalid procedure argument }^M
1^M
Error: Invalid procedure argument at (1)^M
PASS: gfortran.dg/dummy_procedure_1.f90 -O (test for errors, line 39)
FAIL: gfortran.dg/dummy_procedure_1.f90 -O (test for errors, line 40)
--
Summary: gfortran.dg/dummy_procedure_1.f90 failed
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45525
[Bug fortran/45525] [4.6 Regression] gfortran.dg/dummy_procedure_1.f90 failed
--- Comment #1 from hjl dot tools at gmail dot com 2010-09-03 18:09 --- It failed with revision 163827 and worked with 163811. It may be caused by revision163813 : http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00104.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC|kargl at gcc dot gnu dot org|d at domob dot eu Summary|gfortran.dg/dummy_procedure_|[4.6 Regression] |1.f90 failed|gfortran.dg/dummy_procedure_ ||1.f90 failed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45525
[Bug fortran/45525] [4.6 Regression] gfortran.dg/dummy_procedure_1.f90 failed
--- Comment #2 from domob at gcc dot gnu dot org 2010-09-03 18:24 --- Created an attachment (id=21687) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21687action=view) Proposed patch Patch to fix this. I wonder why it did not show up for me before, but I'm taking this and will regtest/submit this nearly obvious patch now. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45525
[Bug middle-end/45312] [4.4 Regression] GCC 4.4.4 miscompiles the Linux kernel
--- Comment #14 from uweigand at gcc dot gnu dot org 2010-09-03 18:30 --- (In reply to comment #12) Yes, it would but I think the reload should still generate the right code in this particular order of insns. IMHO, fixing the order of insn is not the right thing to do because there might be situation of cycle (e.g. value of p600 is inherited from 2 but should be reloaded into 3 and p356 is inherited from 3 and should be reloaded into 2). The problem is definitely in reload inheritance. Reg_last_reload_reg is not invalidated by insn #1407 which is generated by another reload of insn #675. Actually, I think this really is a reload insn ordering problem. Note that reload inheritance tracking via reg_last_reload_reg works on the whole reloaded insn including all the generated reload insns as a whole. Conflicts between different reloads of the same original insn should be treated specially, taking into account reload insn ordering (this is done in free_for_value_p). In this particular case, what happens is this. After initial reload register selection, we have this set of reloads: Reload 0: reload_in (SI) = (reg/v/f:SI 132 [ kpte ]) GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0) reload_in_reg: (reg/v/f:SI 132 [ kpte ]) reload_reg_rtx: (reg:SI 5 di) Reload 1: reload_in (SI) = (reg/v/f:SI 132 [ kpte ]) DIREG, RELOAD_FOR_INPUT (opnum = 1) reload_in_reg: (reg/v/f:SI 132 [ kpte ]) reload_reg_rtx: (reg:SI 5 di) Reload 2: reload_in (SI) = (reg:SI 588 [ D.29684 ]) BREG, RELOAD_FOR_INPUT (opnum = 2) reload_in_reg: (reg:SI 588 [ D.29684 ]) reload_reg_rtx: (reg:SI 3 bx) Reload 3: reload_in (SI) = (reg:SI 356) CREG, RELOAD_FOR_INPUT (opnum = 3) reload_in_reg: (reg:SI 356) reload_reg_rtx: (reg:SI 2 cx) Reload inheritance notes that reload_in of reload 2 (reg:SI 588) is already available in CX at this point. While this cannot be used as reload register due to the BREG class, it is chosen as override input, i.e. reload_in is set to (reg:SI 2 cx) instead of of (reg:SI 588). Code near the end of choose_reload_regs then verifies whether this causes any problems due to re-use of the CX register, and comes to the (correct) decision that it does not, since it knows the reload insn for reload 3 (a RELOAD_FOR_INPUT for operand 3) which clobbers CX will certainly be generated *after* the override-input reload insn for reload 2 (a RELOAD_FOR_INPUT for operand 2). Unfortunately, some time *after* this decision has been made, the when_needed field of reload 3 is changed from RELOAD_FOR_INPUT to RELOAD_OTHER. This causes the sequence of generated reload insns to change (RELOAD_OTHER reloads are emitted before RELOAD_FOR_INPUT reloads) -- this breaks the assumptions the reload inheritance code made, and causes wrong code to be generated. Now the question is, why does this change to RELOAD_OTHER happen. This is done in merge_assigned_reloads, which is called because i386 is a target with SMALL_REGISTER_CLASSES. This routine notices that reloads 0 and 1 share a reload register DI, and decides to merge them, making reload 0 a RELOAD_OTHER reload (and cancelling reload 1). It then goes through all other reloads: /* If this is now RELOAD_OTHER, look for any reloads that load parts of this operand and set them to RELOAD_FOR_OTHER_ADDRESS if they were for inputs, RELOAD_OTHER for outputs. Note that this test is equivalent to looking for reloads for this operand number. This loop now appears to detect reload 3 as a reload that loads part of the operand 0. This happens because reg_overlap_mentioned_for_reload_p (rld[j].in, rld[i].in)) returns true since both reload-in values are stack slots, and reg_overlap_mentioned_for_reload_p conservatively assumes that all memory accesses conflict. Therefore, when_needed for reload 3 is also set to RELOAD_OTHER. This is not only unnecessary, but in turn causes the breakage. Now in this particular case, it might be possible to fix the problem by using a better detection of which additional reloads need to be modified. (The comment says, Note that this test is equivalent to looking for reloads for this operand number. -- which is not true, but could be implemented instead ...) However, the problem seems to be more fundamental. If *any* change, even necessary changes, to when_needed flags are made at this point, *any* decision on reload inheritance or input overrides that was based on reload insn ordering may now be incorrect. I guess a conservative fix could be to check whether any reload inheritance was indeed or input override was indeed performed on this insn, and if so, refuse to perform the merge ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-09-03 18:53 --- Created an attachment (id=21688) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21688action=view) gcc/config.log from x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-09-03 18:54 --- Created an attachment (id=21689) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21689action=view) gcc/autohost.h from x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
[Bug target/45524] r163815/r163816 produces new regressions on x86_64-apple-darwin10
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-09-03 18:56 --- Added gcc/config.log and gcc/autohost.h files from a build on x86_64-apple-darwin10 configured with... ../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-checking=yes --enable-languages=c --enable-lto -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
Re: [Bug c++/45523] New: Failure to bind auto variable to function template instance
I think there is a dup of this bug without auto. Not to mention it was
defect report against the standard.
On Sep 3, 2010, at 10:07 AM, jewillco at osl dot iu dot edu gcc-bugzi...@gcc.gnu.org
wrote:
The following code:
template typename T void foo();
void f() {auto g = fooint;}
fails to compile in GCC 4.5.0's C++0x mode with the following error:
foo.cpp: In function ‘void f()’:
foo.cpp:2:20: error: ‘g’ has incomplete type
Trying different variants of this code, it appears that GCC believes
that
fooint is an ambiguous overloaded function, while there is only
one matching
function.
--
Summary: Failure to bind auto variable to function template
instance
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jewillco at osl dot iu dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45523
[Bug c++/45523] [C++0x] Failure to bind auto variable to function template instance
--- Comment #3 from pinskia at gmail dot com 2010-09-03 19:02 ---
Subject: Re: New: Failure to bind auto variable to function template instance
I think there is a dup of this bug without auto. Not to mention it was
defect report against the standard.
On Sep 3, 2010, at 10:07 AM, jewillco at osl dot iu dot edu
gcc-bugzi...@gcc.gnu.org
wrote:
The following code:
template typename T void foo();
void f() {auto g = fooint;}
fails to compile in GCC 4.5.0's C++0x mode with the following error:
foo.cpp: In function âvoid f()â:
foo.cpp:2:20: error: âgâ has incomplete type
Trying different variants of this code, it appears that GCC believes
that
fooint is an ambiguous overloaded function, while there is only
one matching
function.
--
Summary: Failure to bind auto variable to function template
instance
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jewillco at osl dot iu dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45523
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45523
[Bug c++/45510] Bug with anonymous unions and bit-fields
--- Comment #10 from runipg at broadcom dot com 2010-09-03 19:19 ---
Subject: Re: Bug with anonymous unions and bit-fields
Your suggestion works:
struct bfc {
union {
struct {
unsigned int a : 1,
b : 4;
};
unsigned int data;
};
};
void
testc()
{
cout __func__ endl;
bfc bf0;
bf0.data = 0;
cout bf0.data= hex bf0.data endl;
cout bf0.a= bf0.a endl;
cout bf0.b= bf0.b endl;
bf0.a = 1;
cout bf0.data= hex bf0.data endl;
cout bf0.a= bf0.a endl;
cout bf0.b= hex bf0.b endl;
bf0.b = 1;
cout bf0.data= hex bf0.data endl;
cout bf0.a= bf0.a endl;
cout bf0.b= hex bf0.b endl;
}
Output is
testc
bf0.data=0
bf0.a=0
bf0.b=0
bf0.data=1
bf0.a=1
bf0.b=0
bf0.data=3
bf0.a=1
bf0.b=1
---
I guess the fundamental issue which confused me was:
struct bfa {
union {
unsigned int a : 1,
b : 4;
unsigned int data;
};
};
that it appeared to be a union of 2 integers (one bit-field) rather than
the implementation version where the union is of 3 integers
(two-bitfields). If the standard does not say anything specific about
it, then I guess the compiler is free to do whatever it wants.
In fact, I tried a slight variation on bfa, where I tried to force
alignment on the first integer packing.
struct bfd {
union {
unsigned int a : 1,
b : 4,
: 0; //force alignment
unsigned int data;
};
};
However this gives the same result as bfa.
So I guess semantically it is very confusing to a user. Perhaps this
part of the language should be tightened.
Thanks Paolo!
-Runip
paolo dot carlini at oracle dot com wrote:
--- Comment #8 from paolo dot carlini at oracle dot com 2010-09-03 10:46
---
If you look at the actual Standard, both alignment and allocation of
bit-fields
are implementation defined. Thus, as far as I can see, at best we are talking
about non-portable implementation defined behavior. If you want my advice, try
to stay away from those tricks, with and without anonymous struct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45510
[Bug c++/45523] [C++0x] Failure to bind auto variable to function template instance
--- Comment #4 from jewillco at osl dot iu dot edu 2010-09-03 19:29 --- One thing that I forgot to mention -- the Comeau online compiler accepts this code without any errors (just a warning about g being unused). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45523
[Bug fortran/45186] [4.6 Regression] Gfortran 4.5.0 emits wrong linenumbers
--- Comment #13 from burnus at gcc dot gnu dot org 2010-09-03 19:41 --- Subject: Bug 45186 Author: burnus Date: Fri Sep 3 19:41:11 2010 New Revision: 163838 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163838 Log: 2010-09-03 Tobias Burnus bur...@net-b.de PR fortran/45186 * trans-intrinsic.c (gfc_conv_intrinsic_sign, gfc_conv_intrinsic_leadz): Use build_call_expr_loc instead of build_call_expr. * trans-expr.c (gfc_conv_expr_present, gfc_conv_missing_dummy, gfc_conv_string_length, gfc_conv_substring, gfc_conv_component_ref, gfc_conv_unary_op, gfc_conv_powi, gfc_conv_cst_int_power, gfc_conv_string_tmp, gfc_conv_concat_op, gfc_conv_expr_op, gfc_build_compare_string, gfc_set_interface_mapping_bounds, gfc_conv_subref_array_arg, gfc_conv_derived_to_class, conv_isocbinding_procedure, gfc_conv_procedure_call, fill_with_spaces, gfc_trans_string_copy, gfc_trans_alloc_subarray_assign, gfc_trans_structure_assign, gfc_trans_pointer_assignment, gfc_trans_scalar_assign, gfc_trans_zero_assign, gfc_trans_array_copy, gfc_trans_array_constructor_copy): Change fold_build[0-9] to fold_build[0-9]_loc. * trans-io.c (set_parameter_const, set_parameter_value, set_parameter_ref, gfc_convert_array_to_string, set_string, set_internal_unit, io_result, set_error_locus, nml_get_addr_expr, build_dt): Ditto. * trans-openmp.c (gfc_omp_clause_default_ctor, gfc_omp_clause_copy_ctor, gfc_omp_clause_assign_op, gfc_trans_omp_array_reduction, gfc_trans_omp_atomic, gfc_trans_omp_do): Ditto. * trans.c (gfc_add_modify, gfc_build_addr_expr, gfc_build_array_ref, gfc_trans_runtime_error_vararg, gfc_trans_runtime_check, gfc_call_malloc, gfc_allocate_with_status, gfc_allocate_array_with_status, gfc_call_free, gfc_deallocate_with_status, gfc_call_realloc): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-io.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
