[Bug c/49620] piece of code from modification to dvblast but cant get it to compile and run correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49620 julian gardner changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID
[Bug bootstrap/49667] New: Duplicate -L's with configure --with-gmp-lib on Solaris 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49667 Summary: Duplicate -L's with configure --with-gmp-lib on Solaris 10 Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: greg.robin...@dsto.defence.gov.au Hi, I'm running Solaris 10 sparc. If I configure gcc as this (from config.log): $ ../configure --with-gmp-lib=-L/usr/local/lib -R/usr/local/lib (using ../configire --with-gmp-lib="-L/usr/local/lib -R/usr/local/lib" (as I don't run a global LD_LIBRARY_PATH) It produces double -L entries as such (from config.log): configure:5514: checking for the correct version of the gmp/mpfr/mpc libraries configure:5545: gcc -o conftest -g -O2conftest.c -L-L/usr/local/lib -R/usr/local/lib -lmpc -lmpfr -lgmp >&5 configure:5545: $? = 0 configure:5546: result: yes and: gmpinc='' gmplibs='-L-L/usr/local/lib -R/usr/local/lib -lmpc -lmpfr -lgmp' host='sparc-sun-solaris2.10' As you can see, the test compile works. However, when compiling the compiler, it fails to link with mpc, mpfr and gmp libraries, and says that they dont exist. I can't show you the error, as it's gone from my scroll back and I've fixed the offending Makefiles, so my compiling is continuing without error. The offending Makefiles where I found the -L-L/usr/local/lib are: objdir/Makefile objdir/gcc/Makefile objdir/prev-gcc/Makefile After I corrected these, the compile continues.
[Bug bootstrap/49667] Duplicate -L's with configure --with-gmp-lib on Solaris 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49667 --- Comment #1 from Greg Robinson 2011-07-07 07:33:07 UTC --- Ok, I think I might know whats going on. I believe, I am assuming, that, say, an LDFLAGS option, where you specify -L and -R is the same format as --with-gmp-lib. In other words, --with-gmp-lib takes a directory as the option, and LDFLAGS has the -L and -R options and the directory? Right? should have check configure before posting... sorry 'bout that. It's been a long time...
[Bug bootstrap/49667] Duplicate -L's with configure --with-gmp-lib on Solaris 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49667 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely 2011-07-07 08:06:56 UTC --- yes, as documented at http://gcc.gnu.org/install/configure.html
[Bug libstdc++/49668] New: [C++0x] std::thread does not forward its args as rvalues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49668
Summary: [C++0x] std::thread does not forward its args as
rvalues
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: r...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
Created attachment 24702
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24702
do not use std::bind to implement std::thread
#include
struct moveable
{
moveable() = default;
moveable(moveable&&) = default;
};
void f(moveable) { }
int main()
{
std::thread t(f, moveable());
t.join();
}
The problem is that std::thread uses std::bind internally and the call wrapper
returned by std::bind forwards the bound args as lvalues (this is necessary
because the call wrapper could be invoked multiple times, so the arguments
cannot be moved from)
std::thread doesn't need most of the functionality of std::bind anyway, and
using it actually makes this ill-formed because std::bind tries to act on the
placeholder:
void f(decltype(std::placeholders::_1));
std::thread(t, std::placeholders::_1);
[Bug libstdc++/49668] [C++0x] std::thread does not forward its args as rvalues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49668
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.07.07 08:33:23
Ever Confirmed|0 |1
--- Comment #1 from Jonathan Wakely 2011-07-07
08:33:23 UTC ---
The same problem exists for std::packaged_task and std::async
include
struct moveable
{
moveable() = default;
moveable(moveable&&) = default;
};
void f(moveable) { }
int main()
{
std::packaged_task p(f);
p(moveable());
}
[Bug fortran/49648] ICE(segfault) with MATMUL and function-result actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49648 --- Comment #11 from Dominique d'Humieres 2011-07-07 08:53:24 UTC --- The patch in comment #8 fixes the ICEs for the test cases without disturbing my pet bugs and without regression.
[Bug middle-end/49640] Internal compiler in C99 code (using variable-length arrays) and OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49640 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.07.07 09:11:25 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek 2011-07-07 09:11:25 UTC --- Created attachment 24703 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24703 gcc47-pr49640.patch Untested fix.
[Bug tree-optimization/49666] passing nested function to inline function causes a trampoline call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49666 Richard Guenther changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.07 09:22:08 Component|other |tree-optimization Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-07-07 09:22:08 UTC --- We don't know how to "devirtualize" trampolines. In fact trampoline setup isn't very SSA analyzer friendly (look at the hoops IPA points-to analysis jumps through). We end up with : __builtin_init_trampoline (&FRAME.0.g, g, &FRAME.0); FRAME.0.m = 0; D.3251_20 = n; printf (&"%d\n"[0], D.3251_20); D.3230_3 = __builtin_adjust_trampoline (&FRAME.0.g); D.3231_4 = (int (*) (void)) D.3230_3; D.3245_18 = D.3231_4 (); printf (&"%d\n"[0], D.3245_18); Now we could "devirtualize" the above based on the fact the trampoline doesn't escape.
[Bug lto/49664] liblto_plugin.so exports too many symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49664 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.07 09:23:07 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-07-07 09:23:07 UTC --- Confirmed.
[Bug c++/49663] [4.7 Regression] [C++0x] ICE in lookup_base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49663 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/46727] [4.4 Regression] ICE with -O3 and -ffast-math (in get_callee_fndecl, at tree.c:6857)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46727
--- Comment #3 from Mikael Pettersson 2011-07-07
09:25:18 UTC ---
This was fixed for 4.5 by Matz' r152236 ("Disentangle builtin folding from
expanding").
[Bug middle-end/49662] [4.7 Regression] FAIL: gcc.dg/graphite/interchange-XX.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49662 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.07 09:25:21 CC||spop at gcc dot gnu.org Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-07-07 09:25:21 UTC --- PRE now confuses graphite. No idea why and no chance I'll dive into graphite to figure it out. Maybe Sebastian can have a look, otherwise I'll XFAIL the tests after a while (or add -fno-tree-pre to them). My testing machine had too old ppl so I missed the fails.
[Bug other/49661] et-forest.h uses extern "C"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49661 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.07 09:25:50 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-07-07 09:25:50 UTC --- Confirmed.
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150 --- Comment #22 from Rainer Orth 2011-07-07 09:24:19 UTC --- Author: ro Date: Thu Jul 7 09:24:16 2011 New Revision: 175958 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175958 Log: gcc: PR target/39150 * configure.ac (gcc_cv_as_hidden): Also accept x86_64-*-solaris2.1[0-9]*. (gcc_cv_as_cfi_directive): Likewise. (gcc_cv_as_comdat_group_group): Likewise. (set_have_as_tls): Likewise. * configure: Regenerate. * config.gcc (i[34567]86-*-solaris2*): Also handle x86_64-*-solaris2.1[0-9]*. * config.host (i[34567]86-*-solaris2*): Likewise. * config/sparc/sol2.h (ASM_CPU_DEFAULT_SPEC): Remove. * config/sol2-bi.h (ASM_CPU_DEFAULT_SPEC): Redefine. [USE_GLD] (ARCH_DEFAULT_EMULATION): Define. (TARGET_LD_EMULATION): Use it. * config/i386/sol2.h (ASM_CPU_DEFAULT_SPEC): Define. (SUBTARGET_CPU_EXTRA_SPECS): Add asm_cpu_default. * config/i386/sol2-bi.h (ASM_CPU32_DEFAULT_SPEC): Define. (ASM_CPU64_DEFAULT_SPEC): Define. (ASM_CPU_SPEC): Use %(asm_cpu_default). (ASM_SPEC): Redefine. (DEFAULT_ARCH32_P): Define using TARGET_64BIT_DEFAULT. * config/host-solaris.c [__x86_64__] (TRY_EMPTY_VM_SPACE): Reduce. * doc/install.texi (Specific, amd64-*-solaris2.1[0-9]*): Document. (Specific, i?86-*-solaris2.10): Mention x86_64-*-solaris2.1[0-9]* configuration. (Specific, x86_64-*-solaris2.1[0-9]*): Document. gcc/ada: PR target/39150 * gcc-interface/Makefile.in: Handle x86_64-solaris2. libgcc: PR target/39150 * config.host (*-*-solaris2*): Handle x86_64-*-solaris2.1[0-9]* like i?86-*-solaris2.1[0-9]*. (i[34567]86-*-solaris2*): Also handle x86_64-*-solaris2.1[0-9]*. * configure.ac (i?86-*-solaris2*): Likewise. * configure: Regenerate. gcc/testsuite: PR target/39150 * gcc.misc-tests/linkage.exp: Handle x86_64-*-solaris2.1[0-9]*. toplevel: PR target/39150 * configure.ac (i[3456789]86-*-solaris2*): Also accept x86_64-*-solaris2.1[0-9]*. * configure: Regenerate. boehm-gc: PR target/39150 * configure.ac (i?86-*-solaris2.[89]): Also accept x86_64-*-solaris2.1?. * configure: Regenerate. gnattools: PR target/39150 * configure.ac (*86-*-solaris2*): Also accept x86_64-*-solaris2.1[0-9]*. * configure: Regenerate. libcpp: PR target/39150 * configure.ac (host_wide_int): Handle x86_64-*-solaris2.1[0-9] like i[34567]86-*-solaris2.1[0-9]*. * configure: Regenerate. libgo: PR target/39150 * config/libtool.m4: Handle x86_64-*-solaris2.1[0-9]* like i?86-*-solaris*. * configure: Regenerate. libjava: PR target/39150 * configure.host (x86_64-*): Add -Usun to libgcj_flags. (x86_64-*-solaris2.1[0-9]*): New case. (i?86-*-solaris2*): Also accept x86_64-*-solaris2.1[0-9]*. Modified: trunk/ChangeLog trunk/boehm-gc/ChangeLog trunk/boehm-gc/configure trunk/boehm-gc/configure.ac trunk/configure trunk/configure.ac trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in trunk/gcc/config.gcc trunk/gcc/config.host trunk/gcc/config/host-solaris.c trunk/gcc/config/i386/sol2-bi.h trunk/gcc/config/i386/sol2.h trunk/gcc/config/sol2-bi.h trunk/gcc/config/sparc/sol2.h trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/doc/install.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.misc-tests/linkage.exp trunk/gnattools/ChangeLog trunk/gnattools/configure trunk/gnattools/configure.ac trunk/libcpp/ChangeLog trunk/libcpp/configure trunk/libcpp/configure.ac trunk/libgcc/ChangeLog trunk/libgcc/config.host trunk/libgcc/configure trunk/libgcc/configure.ac trunk/libgo/config/libtool.m4 trunk/libgo/configure trunk/libjava/ChangeLog trunk/libjava/configure.host
[Bug libstdc++/48882] [C++0x] ?: ternary operator fails in certain contexts - compile error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48882 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|?: ternary operator fails |[C++0x] ?: ternary operator |in certain contexts - |fails in certain contexts - |compile error |compile error --- Comment #3 from Paolo Carlini 2011-07-07 09:34:55 UTC --- I think we can close this.
[Bug other/49665] 'defined in discarded section' link failures on cpu2006 benchmarks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49665 Alan Modra changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|amodra at gmail dot com |unassigned at gcc dot ||gnu.org --- Comment #2 from Alan Modra 2011-07-07 09:50:54 UTC --- So, looks like a gcc bug after all. There are four files with a certain group example.s:.section .text._ZN6soplex8SPxBasisD2Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat example.s:.section .text._ZN6soplex8SPxBasisD0Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat soplex.s:.section .text._ZN6soplex8SPxBasisD2Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat soplex.s:.section .text._ZN6soplex8SPxBasisD0Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat spxbasis.s:.section .text._ZN6soplex8SPxBasisD2Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat spxbasis.s:.section .text._ZN6soplex8SPxBasisD0Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat spxsolver.s:.section .text._ZN6soplex8SPxBasisD2Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat spxsolver.s:.section .text._ZN6soplex8SPxBasisD0Ev,"axG",@progbits,_ZN6soplex8SPxBasisD5Ev,comdat In each of these files this group contains two sections, with the code for _ZN6soplex8SPxBasisD0Ev and _ZN6soplex8SPxBasisD2Ev in them. In just one file, spsbasis.o, there is an alias for _ZN6soplex8SPxBasisD2Ev. .weak_ZN6soplex8SPxBasisD1Ev .set_ZN6soplex8SPxBasisD1Ev,_ZN6soplex8SPxBasisD2Ev When the group in spsbasis.o is dropped, _ZN6soplex8SPxBasisD1Ev has no proper definition.
[Bug target/49607] [4.7 Regression] FAIL: 22_locale/time_get/get_weekday/wchar_t/wrapped_locale.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49607 Paolo Carlini changed: What|Removed |Added Component|libstdc++ |target --- Comment #2 from Paolo Carlini 2011-07-07 09:52:10 UTC --- Today (175958) I can't reproduce this on x86_64-linux -m32. Does it happen only on ia32? I'm pretty sure isn't a library issue...
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 --- Comment #15 from Paolo Carlini 2011-07-07 09:53:23 UTC --- Chris, shall we attack this issue? Thanks.
[Bug c/49644] [4.5/4.6/4.7 Regression] post-increment of promoted operand is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49644 --- Comment #6 from Orion Poplawski 2011-07-07 09:54:59 UTC --- I am on vacation and will be out of the office until Thursay, July 21st. Your message has been saved and I will respond if needed when I return. If this is an urgent CoRA computing issue, please send email to coracompu...@cora.nwra.com. Cheers, Orion -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
[Bug c/49644] [4.5/4.6/4.7 Regression] post-increment of promoted operand is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49644 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #5 from Jakub Jelinek 2011-07-07 09:54:13 UTC --- Created attachment 24704 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24704 gcc47-pr49644.patch Untested fix.
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #23 from Rainer Orth 2011-07-07 10:02:23 UTC --- Fixed for 4.7.0.
[Bug libmudflap/49550] Many libmudflap tests fail on Solaris 11/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49550 --- Comment #2 from Rainer Orth 2011-07-07 10:14:05 UTC --- Author: ro Date: Thu Jul 7 10:14:02 2011 New Revision: 175961 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175961 Log: gcc: PR libmudflap/49550 * gcc.c (MFWRAP_SPEC): Also wrap mmap64. libmudflap: PR libmudflap/49550 * mf-runtime.c (__wrap_main) [__sun__ && __svr4__]: Don't register stdin, stdout, stderr. Register __ctype, __ctype_mask. * configure.ac: Check for mmap64. Check for rawmemchr, stpcpy, mempcpy. * configure: Regenerate. * config.h.in: Regenerate. * mf-hooks1.c [HAVE_MMAP64] (__mf_0fn_mmap64): New function. (mmap64): New wrapper function. * mf-impl.h (__mf_dynamic_index) [HAVE_MMAP64]: Add dyn_mmap64. * mf-runtime.c (__mf_dynamic) [HAVE_MMAP64]: Handle mmap64. * mf-hooks2.c [HAVE_GETMNTENT && HAVE_SYS_MNTTAB_H]: Implement getmntent wrapper. * mf-hooks3.c (_REENTRANT): Define. * testsuite/libmudflap.c/heap-scalestress.c (SCALE): Reduce to 1. * testsuite/libmudflap.c/pass-stratcliff.c: Include ../config.h. (MIN): Define. Use HAVE_RAWMEMCHR, HAVE_STPCPY, HAVE_MEMPCPY as guards. * testsuite/libmudflap.c/pass47-frag.c: Expect __ctype warning on *-*-solaris2.*. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c trunk/libmudflap/ChangeLog trunk/libmudflap/config.h.in trunk/libmudflap/configure trunk/libmudflap/configure.ac trunk/libmudflap/mf-hooks1.c trunk/libmudflap/mf-hooks2.c trunk/libmudflap/mf-hooks3.c trunk/libmudflap/mf-impl.h trunk/libmudflap/mf-runtime.c trunk/libmudflap/testsuite/libmudflap.c/heap-scalestress.c trunk/libmudflap/testsuite/libmudflap.c/pass-stratcliff.c trunk/libmudflap/testsuite/libmudflap.c/pass47-frag.c
[Bug target/48108] lto should be containerized in a single mach-o section on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48108 Iain Sandoe changed: What|Removed |Added Attachment #24397|0 |1 is obsolete|| --- Comment #13 from Iain Sandoe 2011-07-07 10:23:06 UTC --- Created attachment 24705 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24705 updated Work In Progress - ppc asm fix NOTE: this is still very much a "work in progress" and is neither complete, nor really ready for extensive testing... ... However, this minor mod fixes the issue noted with powerpc (comment introducers at the end of asm statements). Patch against trunk - but should be similar for 4.6.x.
[Bug libstdc++/49668] [C++0x] std::thread does not forward its args as rvalues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49668 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #2 from Jonathan Wakely 2011-07-07 11:02:01 UTC --- Same problem for call_once too, basically everywhere that uses INVOKE( DECAY_COPY ( std::forward(func)), DECAY_COPY (std::forward(args))...) I'm going to split out the tuple::type, decay::type...> from thread::_Impl so it can be reused in and , as a really simple one-time use version of _Bind_result that doesn't support is_placeholder or is_bind_expression and forwards everything as rvalues, implementing the INVOKE expression above
[Bug c++/49669] New: Compiler crashes with "internal compiler error: in perform_member_init, at cp/init.c:530"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49669
Summary: Compiler crashes with "internal compiler error: in
perform_member_init, at cp/init.c:530"
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: z...@sogetthis.com
Host: x86
Target: x86
Build: x86
Compile this with "g++ -c x.cpp -std=c++0x":
--- BEGIN FILE x.cpp ---
struct Foo { explicit Foo(int) { } };
struct Goo { Goo() : x(Foo(4), Foo(5)) { } Foo x[2]; };
--- END FILE ---
The compiler (GCC 4.6.0) crashes with this message:
x.cpp: In constructor ‘Goo::Goo()’:
x.cpp:2:38: internal compiler error: in perform_member_init, at cp/init.c:530
[Bug c++/49669] [4.6/4.7 Regression] [C++0x] Compiler crashes with "internal compiler error: in perform_member_init, at cp/init.c:530"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49669
Jonathan Wakely changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.07.07 11:27:31
Known to work||4.5.2
Summary|Compiler crashes with |[4.6/4.7 Regression]
|"internal compiler error: |[C++0x] Compiler crashes
|in perform_member_init, at |with "internal compiler
|cp/init.c:530" |error: in
||perform_member_init, at
||cp/init.c:530"
Ever Confirmed|0 |1
Known to fail||4.6.1, 4.7.0
--- Comment #1 from Jonathan Wakely 2011-07-07
11:27:31 UTC ---
The code is invalid, to initialize the array you need:
x{Foo(4), Foo(5)}
4.5 correctly rejects it:
b.cc: In constructor 'Goo::Goo()':
b.cc:2:38: error: bad array initializer
[Bug c++/49669] [4.6/4.7 Regression] [C++0x] Compiler crashes with "internal compiler error: in perform_member_init, at cp/init.c:530"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49669
--- Comment #2 from Kerrek SB 2011-07-07 11:49:46
UTC ---
Yes, I know that the code is invalid, but that shouldn't make the compiler
crash, should it?
For that matter, your proposed correct syntax is also rejected by 4.6.0:
Goo::Goo() : x{Foo(4), Foo(5)} { }
"error: invalid initializer for array member ‘Foo Goo::x [2]"
[Bug target/49621] [4.5/4.6/4.7 regression] ICE in trunc_int_for_mode, at explow.c:57
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49621 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.07 12:03:50 CC||dje at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||meissner at gcc dot gnu.org Ever Confirmed|0 |1
[Bug target/49621] [4.5/4.6/4.7 regression] ICE in trunc_int_for_mode, at explow.c:57
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49621 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #1 from Jakub Jelinek 2011-07-07 12:07:10 UTC --- Created attachment 24706 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24706 gcc47-pr49621.patch I believe the bug is in the ppc vector select patterns, comparing a vector mode reg with const0_rtx in a NE is bound to confuse the middle-end. Both operands of a comparison should always have either the same mode, or one should be VOIDmode and the other should have integer or CC mode. The following patch fixes this, completely untested so far.
[Bug c++/49669] [4.6/4.7 Regression] [C++0x] Compiler crashes with "internal compiler error: in perform_member_init, at cp/init.c:530"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49669
--- Comment #3 from Jonathan Wakely 2011-07-07
12:12:26 UTC ---
(In reply to comment #2)
> Yes, I know that the code is invalid, but that shouldn't make the compiler
> crash, should it?
No, that's why I confirmed the bug and marked it as a regression.
> For that matter, your proposed correct syntax is also rejected by 4.6.0:
>
> Goo::Goo() : x{Foo(4), Foo(5)} { }
>
> "error: invalid initializer for array member ‘Foo Goo::x [2]"
Yes, but it works with 4.6.1
[Bug target/46278] avr-gcc 4.5.1 doing suboptimal reloads using X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46278 Georg-Johann Lay changed: What|Removed |Added Last reconfirmed||2011-07-07 CC|avr at gjlay dot de |gjl at gcc dot gnu.org Known to work||3.4.6 Target Milestone|--- |4.7.0 Known to fail||4.6.1, 4.7.0 --- Comment #4 from Georg-Johann Lay 2011-07-07 12:19:13 UTC --- For the Created attachment 22240 "vektor-zeichen-i.c" http://gcc.gnu.org/bugzilla/attachment.cgi?id=22240 I get the following sizes (-Os -mmcu=atmega128): avr-gcc-4.6.1: textdata bss dec hex filename 1076 0 1901266 4f2 vektor-zeichen-i.o avr-gcc-4.7.0: textdata bss dec hex filename 1088 0 1901278 4fe vektor-zeichen-i.o avr-gcc-4.7.0 with patch: textdata bss dec hex filename 728 0 190 918 396 vektor-zeichen-i.o For the Created attachment 24582 "snake.c" http://gcc.gnu.org/bugzilla/attachment.cgi?id=24582 I get the following sizes (-Os -mmcu=atmega168 -std=gnu99): avr-gcc-4.6.1: textdata bss dec hex filename 1549 0 01549 60d snake-i.o avr-gcc-4.7.0 textdata bss dec hex filename 1625 0 01625 659 snake-i.o avr-gcc-4.7.0 with patch: textdata bss dec hex filename 1507 0 01507 5e3 snake-i.o the "with patch" version patches by the tentative patch attached in http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00437.html This shows that the fake X addresses increase the code size and that avoiding fake X addresses as proposed by the patch are pointing into the right direction. BTW: With avr-gcc-3.4.6 I get a codesize of ~1400 bytes for the "snake.c" testcase which is because the old compiler is smarter with register allocation and no function needs a frame whereas 4.7 needs frame for some functions. But that's a different story.
[Bug middle-end/49640] Internal compiler in C99 code (using variable-length arrays) and OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49640 --- Comment #3 from Jakub Jelinek 2011-07-07 12:49:21 UTC --- Author: jakub Date: Thu Jul 7 12:49:17 2011 New Revision: 175967 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175967 Log: PR middle-end/49640 * gimplify.c (gimplify_compound_lval): For last 2 ARRAY_*REF operands and last COMPONENT_REF operand call gimplify_expr on it if non-NULL. * gcc.dg/gomp/pr49640.c: New test. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr49640.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/49640] Internal compiler in C99 code (using variable-length arrays) and OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49640 --- Comment #4 from Jakub Jelinek 2011-07-07 12:50:08 UTC --- Author: jakub Date: Thu Jul 7 12:50:03 2011 New Revision: 175968 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175968 Log: PR middle-end/49640 * gimplify.c (gimplify_compound_lval): For last 2 ARRAY_*REF operands and last COMPONENT_REF operand call gimplify_expr on it if non-NULL. * gcc.dg/gomp/pr49640.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/gomp/pr49640.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/gimplify.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/49538] [4.7 regression] Revision 175341 causes segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49538 --- Comment #4 from Markus Trippelsdorf 2011-07-07 12:49:55 UTC --- No, c70f46b057cd12973 is fine. I've tested tested: git reset --hard c70f46b057cd12973d33c01c8fa0da5c14ba3944 and then applied Jason's patch on top of this and everything is fine.
[Bug target/49607] [4.7 Regression] FAIL: 22_locale/time_get/get_weekday/wchar_t/wrapped_locale.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49607 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #3 from H.J. Lu 2011-07-07 12:55:11 UTC --- I can't reproduce it now.
[Bug middle-end/49640] Internal compiler in C99 code (using variable-length arrays) and OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49640 --- Comment #5 from Jakub Jelinek 2011-07-07 12:58:22 UTC --- Fixed for 4.6/4.7+ so far.
[Bug testsuite/48727] FAIL: g++.dg/opt/devirt2.C scan-assembler-times xyzzy 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48727 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-07-07 13:04:18 UTC --- > --- Comment #4 from Eric Botcazou 2011-07-06 > 19:15:49 UTC --- >> This also fails on 32-bit Solaris/SPARC with Sun as, which has: >> >> sethi %hi(_ZN1S5xyzzyEv), %g1 >> jmp %g1 + %lo(_ZN1S5xyzzyEv) >> sethi %hi(_ZN1S5xyzzyEv), %g1 >> jmp %g1 + %lo(_ZN1S5xyzzyEv) >> >> On the other hand, both 64-bit with Sun as and 32-bit with gas have >> >> call_ZN1S5xyzzyEv, 0 >> call_ZN1S5xyzzyEv, 0 > > This is OK, these are the 2 forms of a direct tail call on the SPARC: > sethi/jmp > or call, depending on the capability of the assembler (HAVE_AS_RELAX_OPTION). Then it's probably best to only look for (jmp|call)[^\n]*xyzzy on SPARC, and ignore the sethi, so the count still matches? Or, perhaps safer: (sethi[^\n]*xyzzy[^\n]*\n)?[^\n]*(jmp|call)[^\n]*xyzzy Rainer
[Bug c++/49669] [4.6/4.7 Regression] [C++0x] Compiler crashes with "internal compiler error: in perform_member_init, at cp/init.c:530"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49669 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.2
[Bug tree-optimization/49622] [4.4 Regression] Compiler segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49622 --- Comment #5 from Mikael Pettersson 2011-07-07 13:22:27 UTC --- This was fixed for 4.5 by r145494, Richard's merge from the alias-improvements branch.
[Bug testsuite/48727] FAIL: g++.dg/opt/devirt2.C scan-assembler-times xyzzy 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48727 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.07 13:32:09 Ever Confirmed|0 |1 --- Comment #6 from Eric Botcazou 2011-07-07 13:32:09 UTC --- > Then it's probably best to only look for > > (jmp|call)[^\n]*xyzzy > > on SPARC, and ignore the sethi, so the count still matches? That seems sufficient, IIUC the point is to have a symbol in the jmp/call. As I usually don't test with Sun as, please go ahead with whatever works for you.
[Bug fortran/49475] [OOP][debugging] Add DWARF info for Fortran's OOP features (extension, member functions)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49475 --- Comment #1 from Tobias Burnus 2011-07-07 13:33:18 UTC --- See thread starting at http://gcc.gnu.org/ml/gcc/2011-06/threads.html#00342
[Bug c++/49538] [4.7 regression] Revision 175341 causes segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49538 --- Comment #5 from Markus Trippelsdorf 2011-07-07 14:08:08 UTC --- OK I've finally found the commit in question: % git bisect start $ git bisect bad % git bisect good c70f46b057cd12973d33c01c8fa0da5c14ba3944 ... (test and repeat always with Jason's patch applied on top) ... % git bisect bad f30e87e922bda64571abe28fca8edab3bdc42918 is the first bad commit commit f30e87e922bda64571abe28fca8edab3bdc42918 Author: hubicka Date: Mon Jun 13 15:34:59 2011 + * ipa-inline.c (reset_edge_caches): Walk aliases. (update_caller_keys): Do not test inlinability of aliases. * ipa-inline-analysis.c (do_estimate_edge_time): Look through alias. (do_estimate_growth): Fix typo. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@174992 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c++/49538] [4.7 regression] Revision 175341 causes segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49538 --- Comment #6 from Markus Trippelsdorf 2011-07-07 14:43:49 UTC --- It's the first hunk that causes the problem: diff --git a/gcc/ipa-inline-analysis.c b/gcc/ipa-inline-analysis.c index 43e0f81..b008f05 100644 --- a/gcc/ipa-inline-analysis.c +++ b/gcc/ipa-inline-analysis.c @@ -2079,7 +2079,7 @@ do_estimate_edge_time (struct cgraph_edge *edge) struct inline_edge_summary *es = inline_edge_summary (edge); gcc_checking_assert (edge->inline_failed); - estimate_node_size_and_time (edge->callee, + estimate_node_size_and_time (cgraph_function_or_thunk_node (edge->callee, NULL), evaluate_conditions_for_edge (edge, true), &size, &time);
[Bug rtl-optimization/49646] gcc.dg/pr44194-1.c FAILs on Solaris/SPARC, Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49646 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||DUPLICATE --- Comment #2 from Eric Botcazou 2011-07-07 14:56:49 UTC --- PR rtl-opt/44194 is still WIP, let's avoid duplicating things. *** This bug has been marked as a duplicate of bug 44194 ***
[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 Eric Botcazou changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #37 from Eric Botcazou 2011-07-07 14:56:49 UTC --- *** Bug 49646 has been marked as a duplicate of this bug. ***
[Bug debug/49522] Divide by zero in validate_subreg in emit-rtl.c:695
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49522 --- Comment #3 from Jakub Jelinek 2011-07-07 16:06:01 UTC --- Author: jakub Date: Thu Jul 7 16:05:55 2011 New Revision: 175987 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175987 Log: PR debug/49522 * df-problems.c (dead_debug_reset): Remove dead_debug_uses referencing debug insns that have been reset. (dead_debug_insert_before): Don't assert reg is non-NULL, instead return immediately if it is NULL. * gcc.dg/debug/pr49522.c: New test. Mgcc/ChangeLog Agcc/testsuite/gcc.dg/debug/pr49522.c Mgcc/testsuite/ChangeLog Mgcc/df-problems.c Added: trunk/gcc/testsuite/gcc.dg/debug/pr49522.c Modified: trunk/gcc/ChangeLog trunk/gcc/df-problems.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49669] [4.6/4.7 Regression] [C++0x] Compiler crashes with "internal compiler error: in perform_member_init, at cp/init.c:530"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49669
--- Comment #4 from Kerrek SB 2011-07-07 16:09:55
UTC ---
You're right, it works in 4.6.1 - thanks! (Just updated.)
Say, since you're here, if I change the definition of x from "Foo[2]" to
"std::array", should I be allowed to initialize it with
Goo::Goo() : x{{Foo(4), Foo(5)}} { }
At the moment, _only_ the following seems to work:
Goo::Goo() : x({{Foo(4), Foo(5)}}) { }
In particular, initialization of "Foo[2]" and "std::array" is anything
but "uniform" :-)
[Bug other/49533] [4.7 regression] Firefox profiled build issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533 --- Comment #5 from Markus Trippelsdorf 2011-07-07 16:20:44 UTC --- This is caused by: 7791b0eb56c3c324004e6fffe2d5f21241c038f7 is the first bad commit commit 7791b0eb56c3c324004e6fffe2d5f21241c038f7 Author: hubicka Date: Mon Jun 13 13:12:23 2011 + * ipa-inline-transform.c (+can_remove_node_now_p_1): Break out from... (can_remove_node_now_p): ... here; handle same comdat groups. (clone_inlined_nodes): Update use of can_remove_node_now_p add TODO. (inline_call): Update use of can_remove_node_now_p. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@174989 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug regression/49498] [4.7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 --- Comment #8 from Jeffrey A. Law 2011-07-07 16:22:48 UTC --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/05/11 16:52, xinliangli at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 > > --- Comment #7 from davidxl 2011-07-05 22:51:49 > UTC --- > (In reply to comment #6) >> Created attachment 24693 [details] >> k.c.127t.uninit > > > 1) is the complicated control flow generated by if-merging + jump-threading? I think jump-threading is the primarly culprit. At one time I tried to track how things changed through the passes, but ultimately decided the end result either had to be analyzable or not by the uninit code. > 2) On the targets that have the problem, is branch cost considered cheap? No idea. I didn't bother to look at why cris-elf triggers the problem, but x86 doesn't. Presumably it's a branch-cost or similar issue. > 3) Looks like there are more jump-threading opportunities that can clean up > the > control flow, namely, Yes. Jump threading is inherently an iterative process. It was decided some time ago to remove the iterative step as it doesn't buy a whole lot in terms of code quality and it's a fairly significant compile-time cost. During my investigations noticed the same thing and manually reran DOM from within GDB and verified it further simplified the CFG, but rerunning DOM isn't really going to be an option. > > With the complicated control flow, the uninit analysis is definitely confused > -- requires powerful symbolic evaluation to simplify the predicates: the > predicates guarding the use in BLOCK 6: > > (n<=9 AND m==0) OR (n <= 9 AND m != 0 AND (n <=9 OR m > 100)) OR (n > 9 AND m >> 100) OR (n > 9 AND m <= 100 AND (n<=9 OR m > 100)) > > of course there might be other bugs in the analysis that prevent the above > from > formulated, but nonetheless, it is unlikely to be handled). OK. That's kindof what I needed to know -- we're unlikely to handle this particular case. > > Solution > 1) fix the test case by disabling jumpthreading and if-merging Or xfailing it for the affected targets. > 2) or maybe move the uninit analysis earlier in the pipeline. As you know, that runs the risk of introducing other false positives. I can live with #1 or the target-specific xfailing approach. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOFd1BAAoJEBRtltQi2kC7wpsIAJ1FStgYozE/6o8o5mZrj+5V hWP7WmspSVFQMLTGDZw7hNeCEnE2rIl/8Tmin6/GDWM50oNGati2HqTRqTSZwU0y YvMY8NlH1/YY4hJ94YPEpNrALAIwD8w3qdhiPVlS7eTWgOl8iTmXLJmJqk6OnT+Z BeYPxpYDkQgYvicyjT4VVcWpwcmCbE/D9bKTNt68ABAH8RTmkba/VaK1wtGpt3qt hy0qXCi59OUPh7TbcKvgrDLL3GDmy68C9afHUiEKyfDu3JxV9awl4y4Bfr1lOURF bvTOuhKQo0MOlbtgJo24nGYK2TU/1Nv1DkcdhgvsCCBciO8LPoocnSZ176ohE5E= =/ti9 -END PGP SIGNATURE-
[Bug c/49653] Undefined reference to inlined function with -O0,-std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49653
--- Comment #7 from Gary Funck 2011-07-07 16:38:33
UTC ---
(In reply to comment #6)
> why not just add this to make the code valid by emitting an extern definition?
>
> extern long trouble(long, long);
If you're suggesting that the front-end would do this automatically when
compiling -O0 -std={gnu}99, I'd agree that this would be a good way to handle
this use case.
[Bug c++/49669] [4.6/4.7 Regression] [C++0x] Compiler crashes with "internal compiler error: in perform_member_init, at cp/init.c:530"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49669
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #5 from Jonathan Wakely 2011-07-07
16:39:56 UTC ---
(In reply to comment #4)
> Say, since you're here, if I change the definition of x from "Foo[2]" to
> "std::array", should I be allowed to initialize it with
>
>Goo::Goo() : x{{Foo(4), Foo(5)}} { }
I think that should be valid
> At the moment, _only_ the following seems to work:
>
>Goo::Goo() : x({{Foo(4), Foo(5)}}) { }
Hmm, that creates a temporary array and uses that to initialize x, I
don't think that should be necessary.
> In particular, initialization of "Foo[2]" and "std::array" is anything
> but "uniform" :-)
It will never be completely uniform, because one is an array and one is an
aggregate containing an array, but I think any of these should be valid:
struct Foo { explicit Foo(int) { } };
struct TwoFoo { Foo elems[2]; };
TwoFoo x{ Foo(1), Foo(1) };
TwoFoo y{ { Foo(1), Foo(1) } };
TwoFoo z( { Foo(1), Foo(1) } );// ?
struct Goo
{
Foo a[2];
TwoFoo x, y, z;
Goo()
: a{ Foo(1), Foo(2) }
, x{ Foo(1), Foo(2) }
, y{ { Foo(1), Foo(2) } }
, z( { Foo(1), Foo(2) } ) // ?
{ }
};
Jason, when you get around to looking at this ICE, could you comment on the
initialization question above? Thanks!
[Bug c/49653] Undefined reference to inlined function with -O0,-std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49653
--- Comment #8 from Jonathan Wakely 2011-07-07
16:49:18 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > why not just add this to make the code valid by emitting an extern
> > definition?
> >
> > extern long trouble(long, long);
>
> If you're suggesting that the front-end would do this automatically when
> compiling -O0 -std={gnu}99, I'd agree that this would be a good way to handle
> this use case.
No, I was suggesting you add it, not the compiler.
[Bug c/49653] Undefined reference to inlined function with -O0,-std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49653
--- Comment #9 from Gary Funck 2011-07-07 16:55:38
UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> GF: If you're suggesting that the front-end would do this automatically when
> GF: compiling -O0 -std={gnu}99, I'd agree that this would be a good way to
> handle
> GF: this use case.
>
> No, I was suggesting you add it, not the compiler.
OK. That would be a different use case.
[Bug c/49653] Undefined reference to inlined function with -O0,-std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49653 --- Comment #10 from Jonathan Wakely 2011-07-07 17:08:54 UTC --- The point is your code is invalid and the compiler's behaviour at -O0 is correct. C99 6.9 "If an identifier declared with external linkage is used in an expression (other than as part of the operand of a sizeof operator whose result is an integer constant), somewhere in the entire program there shall be exactly one external definition for the identifier; otherwise, there shall be no more than one." You get away with the invalid program with optimisation but that doesn't make it correct. If the compiler decided not to inline the function because of its size or the amount of inlining it had already done, or a user compiled the code with -fno-inline-functions -O3, then the code would fail to link again. The solution is not to modify the compiler, but to fix the code. Either make the function static (so no external definition is needed) or ensure an external definition is present in some translation unit (or as a GNU extension mark it "always_inline" so you get away without referencing the external definition.)
[Bug c++/49665] 'defined in discarded section' link failures on cpu2006 benchmarks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49665 Andrew Pinski changed: What|Removed |Added Component|other |c++ --- Comment #3 from Andrew Pinski 2011-07-07 17:41:24 UTC --- > In each of these files this group contains two sections, with the code for > _ZN6soplex8SPxBasisD0Ev and _ZN6soplex8SPxBasisD2Ev in them. In just one > file, > spsbasis.o, there is an alias for _ZN6soplex8SPxBasisD2Ev. Hmm, if there is an set in one of the files but not the others, then there is something wrong in general. Is the code violating ODR?
[Bug middle-end/49495] -O3 causes error message "edge points to wrong declaration:"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49495 --- Comment #5 from Martin Jambor 2011-07-07 18:08:04 UTC --- Author: jamborm Date: Thu Jul 7 18:08:00 2011 New Revision: 175998 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175998 Log: 2011-07-07 Martin Jambor PR middle-end/49495 * cgraphunit.c (verify_edge_corresponds_to_fndecl): New function. (verify_cgraph_node): Some functinality moved to verify_edge_corresponds_to_fndecl, call it. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c
[Bug middle-end/49495] -O3 causes error message "edge points to wrong declaration:"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49495 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Martin Jambor 2011-07-07 18:22:49 UTC --- Fixed.
[Bug c++/49670] New: internal compiler error: in extract_insn, at recog.c:2104
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670 Summary: internal compiler error: in extract_insn, at recog.c:2104 Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: noloa...@gmail.com Sorry if this was previously reported. Searching returned an error stating I used an invalid file extension. I was attempting to compile the latest Crypto++ (svn checkout https://cryptopp.svn.sourceforge.net/svnroot/cryptopp/trunk/c5 cryptopp) on a Dell GX280 (32 bit Pentium 4). Here's the internal compiler error: $ export PREFIX=/usr/local; make g++ -DNDEBUG -g -O2 -m32 -mtune=pentium4 -march=native -pipe -c 3way.cpp g++ -DNDEBUG -g -O2 -m32 -mtune=pentium4 -march=native -pipe -c adler32.cpp g++ -DNDEBUG -g -O2 -m32 -mtune=pentium4 -march=native -pipe -c algebra.cpp g++ -DNDEBUG -g -O2 -m32 -mtune=pentium4 -march=native -pipe -c algparam.cpp g++ -DNDEBUG -g -O2 -m32 -mtune=pentium4 -march=native -pipe -c arc4.cpp g++ -DNDEBUG -g -O2 -m32 -mtune=pentium4 -march=native -pipe -c asn.cpp asn.cpp: In member function ‘void CryptoPP::OID::DEREncode(CryptoPP::BufferedTransformation&) const’: asn.cpp:254:1: error: unrecognizable insn: (insn 194 178 195 2 asn.cpp:248 (set (reg:SI 2 cx) (mem:QI (plus:SI (reg/f:SI 1 dx [orig:61 D.44160 ] [61]) (const_int 4 [0x4])) [16 S1 A32])) -1 (nil)) asn.cpp:254:1: internal compiler error: in extract_insn, at recog.c:2104 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make: *** [asn.o] Error 1 === Additional information I modified Crypto++'s GNUMakefile a bit: OLD: CXXFLAGS = -DNDEBUG -g O2 MOD: CXXFLAGS = -DNDEBUG -g -O2 -m32 -mtune=pentium4 When I invoked `make` I used the following: $ export PREFIX=/usr/local; make $ g++ --version g++ (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ uname -a Linux bruno 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux jeffrey@bruno:~/Desktop/order-status$
[Bug c/49653] Undefined reference to inlined function with -O0,-std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49653 --- Comment #11 from Gary Funck 2011-07-07 19:01:19 UTC --- Thanks for the additional info. I agree that it would be incorrect for the compiler to default to "extern" if it chooses not to inline the function (I hadn't thought that suggestion through.) My reason for filing this bug report was to point out that the program compilation behaves differently with and without optimization enabled. As a general rule, I think it is better that GCC's behavior does not change between varying levels of optimization. For example, let's say that when GCC chooses to inline this C99 defined "inline" function, that it also emits an external reference to the named routine. Then at link time, if no external definition is found, the link would fail, in a manner similar to the way that it does at -O0. IMO, that would be a better situation than now, because the tool chain's behavior is consistent across optimization levels. Of course, in both cases, it would be better if a more helpful error message is supplied. Based on the discussion of the C99 definition of "inline", cited by Johannes Schaub, the compiler is free to choose whether to use the inline definition or to generate an external reference. Thus, if we focus only on the translation unit, it seems that GCC could choose to compile the "inline" function as if it had been declared "static" when compiling in C99 mode with inlining disabled. This is no worse, it would seem, than inlining the function at higher levels of optimization, and not checking that an external definition for the function is defined somewhere in the linked program.
[Bug debug/49522] Divide by zero in validate_subreg in emit-rtl.c:695
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49522 --- Comment #4 from Jakub Jelinek 2011-07-07 19:10:05 UTC --- Author: jakub Date: Thu Jul 7 19:10:01 2011 New Revision: 176003 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176003 Log: PR debug/49522 * df-problems.c (dead_debug_reset): Remove dead_debug_uses referencing debug insns that have been reset. (dead_debug_insert_before): Don't assert reg is non-NULL, instead return immediately if it is NULL. * gcc.dg/debug/pr49522.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/debug/pr49522.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/df-problems.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c/49644] [4.5/4.6/4.7 Regression] post-increment of promoted operand is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49644 --- Comment #7 from Jakub Jelinek 2011-07-07 19:11:29 UTC --- Author: jakub Date: Thu Jul 7 19:11:27 2011 New Revision: 176004 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176004 Log: PR c/49644 * c-typeck.c (build_binary_op): For MULT_EXPR and TRUNC_DIV_EXPR with one non-complex and one complex argument, call c_save_expr on both operands. * gcc.c-torture/execute/pr49644.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr49644.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/49644] [4.5/4.6/4.7 Regression] post-increment of promoted operand is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49644 --- Comment #8 from Jakub Jelinek 2011-07-07 19:14:41 UTC --- Author: jakub Date: Thu Jul 7 19:14:38 2011 New Revision: 176005 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176005 Log: PR c/49644 * c-typeck.c (build_binary_op): For MULT_EXPR and TRUNC_DIV_EXPR with one non-complex and one complex argument, call c_save_expr on both operands. * gcc.c-torture/execute/pr49644.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/execute/pr49644.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/c-typeck.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug debug/49522] Divide by zero in validate_subreg in emit-rtl.c:695
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49522 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek 2011-07-07 19:18:22 UTC --- Should be fixed now.
[Bug c/49644] [4.5/4.6/4.7 Regression] post-increment of promoted operand is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49644 --- Comment #9 from Jakub Jelinek 2011-07-07 19:19:52 UTC --- Fixed for C in 4.6+ so far, C++ patch is waiting for review.
[Bug regression/49498] [4.7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 --- Comment #9 from davidxl 2011-07-07 19:31:53 UTC --- On Thu, Jul 7, 2011 at 9:23 AM, law at redhat dot com < gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 > > --- Comment #8 from Jeffrey A. Law 2011-07-07 > 16:22:48 UTC --- > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/05/11 16:52, xinliangli at gmail dot com wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 > > > > --- Comment #7 from davidxl 2011-07-05 > 22:51:49 UTC --- > > (In reply to comment #6) > >> Created attachment 24693 [details] > >> k.c.127t.uninit > > > > > > 1) is the complicated control flow generated by if-merging + > jump-threading? > I think jump-threading is the primarly culprit. At one time I tried to > track how things changed through the passes, but ultimately decided the > end result either had to be analyzable or not by the uninit code. > > > 2) On the targets that have the problem, is branch cost considered cheap? > No idea. I didn't bother to look at why cris-elf triggers the problem, > but x86 doesn't. Presumably it's a branch-cost or similar issue. > > > 3) Looks like there are more jump-threading opportunities that can clean > up the > > control flow, namely, > Yes. Jump threading is inherently an iterative process. It was decided > some time ago to remove the iterative step as it doesn't buy a whole lot > in terms of code quality and it's a fairly significant compile-time cost. > Does it need to be iterative? Any simple example to show dependency of jump-threading analysis on actual transformation of some other jump-threading instance (e.g, opportunity only gets exposed after transformation)? > > During my investigations noticed the same thing and manually reran DOM > from within GDB and verified it further simplified the CFG, but > rerunning DOM isn't really going to be an option. > Is incremental DOM update a choice? David > > > > > > With the complicated control flow, the uninit analysis is definitely > confused > > -- requires powerful symbolic evaluation to simplify the predicates: the > > predicates guarding the use in BLOCK 6: > > > > (n<=9 AND m==0) OR (n <= 9 AND m != 0 AND (n <=9 OR m > 100)) OR (n > 9 > AND m > >> 100) OR (n > 9 AND m <= 100 AND (n<=9 OR m > 100)) > > > > of course there might be other bugs in the analysis that prevent the > above from > > formulated, but nonetheless, it is unlikely to be handled). > OK. That's kindof what I needed to know -- we're unlikely to handle > this particular case. > > > > > Solution > > 1) fix the test case by disabling jumpthreading and if-merging > Or xfailing it for the affected targets. > > > 2) or maybe move the uninit analysis earlier in the pipeline. > As you know, that runs the risk of introducing other false positives. > > I can live with #1 or the target-specific xfailing approach. > > jeff > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJOFd1BAAoJEBRtltQi2kC7wpsIAJ1FStgYozE/6o8o5mZrj+5V > hWP7WmspSVFQMLTGDZw7hNeCEnE2rIl/8Tmin6/GDWM50oNGati2HqTRqTSZwU0y > YvMY8NlH1/YY4hJ94YPEpNrALAIwD8w3qdhiPVlS7eTWgOl8iTmXLJmJqk6OnT+Z > BeYPxpYDkQgYvicyjT4VVcWpwcmCbE/D9bKTNt68ABAH8RTmkba/VaK1wtGpt3qt > hy0qXCi59OUPh7TbcKvgrDLL3GDmy68C9afHUiEKyfDu3JxV9awl4y4Bfr1lOURF > bvTOuhKQo0MOlbtgJo24nGYK2TU/1Nv1DkcdhgvsCCBciO8LPoocnSZ176ohE5E= > =/ti9 > -END PGP SIGNATURE- > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug. >
[Bug c/49644] [4.5/4.6/4.7 Regression] post-increment of promoted operand is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49644 --- Comment #10 from Jakub Jelinek 2011-07-07 19:41:57 UTC --- Author: jakub Date: Thu Jul 7 19:41:55 2011 New Revision: 176006 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176006 Log: PR c/49644 * typeck.c (cp_build_binary_op): For MULT_EXPR and TRUNC_DIV_EXPR with one non-complex and one complex argument, call save_expr on both operands. * g++.dg/torture/pr49644.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr49644.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/49644] [4.5/4.6/4.7 Regression] post-increment of promoted operand is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49644 --- Comment #11 from Jakub Jelinek 2011-07-07 19:43:03 UTC --- Author: jakub Date: Thu Jul 7 19:42:58 2011 New Revision: 176007 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176007 Log: PR c/49644 * typeck.c (cp_build_binary_op): For MULT_EXPR and TRUNC_DIV_EXPR with one non-complex and one complex argument, call save_expr on both operands. * g++.dg/torture/pr49644.C: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/torture/pr49644.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/typeck.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug other/49533] [4.7 regression] Firefox profiled build issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533 --- Comment #6 from Markus Trippelsdorf 2011-07-07 20:29:44 UTC --- With 7791b0eb56c3c324004e6fffe2d5f21241c038f7 reverted and after reverting the following hunk: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49538#c6 , Firefox builds and runs fine again.
[Bug target/49660] 64-bit gcc doesn't enable -mv8plus with -m32 on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49660 --- Comment #7 from Eric Botcazou 2011-07-07 20:41:12 UTC --- Author: ebotcazou Date: Thu Jul 7 20:41:10 2011 New Revision: 176009 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176009 Log: PR target/49660 * config/sparc/sol2.h [TARGET_64BIT_DEFAULT] (TARGET_DEFAULT): Add MASK_V8PLUS, remove commented out flag and reorder. Backport from mainline 2011-06-28 Rainer Orth * config/sparc/sol2-64.h (TARGET_DEFAULT): Remove. (TARGET_64BIT_DEFAULT): Define. * config.gcc (sparc*-*-solaris2*): Move sparc/sol2-64.h to front of tm_file. * config/sparc/sol2.h [TARGET_64BIT_DEFAULT] (TARGET_DEFAULT): Define. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.target/sparc/cas64.c - copied unchanged from r176008, trunk/gcc/testsuite/gcc.target/sparc/cas64.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config.gcc branches/gcc-4_6-branch/gcc/config/sparc/sol2-64.h branches/gcc-4_6-branch/gcc/config/sparc/sol2.h branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/49660] 64-bit gcc doesn't enable -mv8plus with -m32 on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49660 --- Comment #6 from Eric Botcazou 2011-07-07 20:37:02 UTC --- Author: ebotcazou Date: Thu Jul 7 20:36:59 2011 New Revision: 176008 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176008 Log: PR target/49660 * config/sparc/sol2.h [TARGET_64BIT_DEFAULT] (TARGET_DEFAULT): Add MASK_V8PLUS, remove commented out flag and reorder. Added: trunk/gcc/testsuite/gcc.target/sparc/cas64.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sol2.h trunk/gcc/testsuite/ChangeLog
[Bug target/49660] 64-bit gcc doesn't enable -mv8plus with -m32 on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49660 --- Comment #8 from Eric Botcazou 2011-07-07 20:43:45 UTC --- Author: ebotcazou Date: Thu Jul 7 20:43:43 2011 New Revision: 176010 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176010 Log: PR target/49660 * config/sparc/sol2.h [TARGET_64BIT_DEFAULT] (TARGET_DEFAULT): Add MASK_V8PLUS, remove commented out flag and reorder. Backport from mainline 2011-06-28 Rainer Orth * config/sparc/sol2-64.h (TARGET_DEFAULT): Remove. (TARGET_64BIT_DEFAULT): Define. * config.gcc (sparc*-*-solaris2*): Move sparc/sol2-64.h to front of tm_file. * config/sparc/sol2.h [TARGET_64BIT_DEFAULT] (TARGET_DEFAULT): Define. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.target/sparc/cas64.c - copied unchanged from r176009, trunk/gcc/testsuite/gcc.target/sparc/cas64.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config.gcc branches/gcc-4_5-branch/gcc/config/sparc/sol2-64.h branches/gcc-4_5-branch/gcc/config/sparc/sol2.h branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug target/49660] 64-bit gcc doesn't enable -mv8plus with -m32 on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49660 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|4.7.0 |4.5.4 Resolution||FIXED --- Comment #9 from Eric Botcazou 2011-07-07 20:46:36 UTC --- Fixed in 4.5.x and above.
[Bug fortran/49648] ICE(segfault) with MATMUL and function-result actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49648 --- Comment #12 from Mikael Morin 2011-07-07 20:58:19 UTC --- Author: mikael Date: Thu Jul 7 20:58:16 2011 New Revision: 176011 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176011 Log: 2011-07-07 Mikael Morin PR fortran/49648 * resolve.c (resolve_symbol): Force resolution of function result's array specification. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c
[Bug fortran/49648] ICE(segfault) with MATMUL and function-result actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49648 --- Comment #13 from Mikael Morin 2011-07-07 21:03:27 UTC --- Author: mikael Date: Thu Jul 7 21:03:25 2011 New Revision: 176012 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176012 Log: 2011-07-07 Mikael Morin PR fortran/49648 * gfortran.dg/result_in_spec_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/result_in_spec_4.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/49648] ICE(segfault) with MATMUL and function-result actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49648 Mikael Morin changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.07.07 21:12:19 AssignedTo|unassigned at gcc dot |mikael at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/49353] C++ frontend should not declare function EXTERN when it forces them to stay
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49353 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 --- Comment #3 from Jason Merrill 2011-07-07 21:19:47 UTC --- Fixed for 4.7.0. I tried changing the code in cgraphunit.c to abort if it would change the result, but bootstrap failed building libjava, so I guess the Java front end has related issues as well.
[Bug c++/49353] C++ frontend should not declare function EXTERN when it forces them to stay
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49353 --- Comment #4 from Jason Merrill 2011-07-07 21:20:44 UTC --- Created attachment 24707 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24707 cgraph abort patch In case anyone is interested.
[Bug regression/49498] [4.7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 --- Comment #10 from Jeffrey A. Law 2011-07-07 21:26:57 UTC --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/11 13:32, xinliangli at gmail dot com wrote: > Yes. Jump threading is inherently an iterative process. It was decided > some time ago to remove the iterative step as it doesn't buy a whole lot > in terms of code quality and it's a fairly significant compile-time cost. > > >> Does it need to be iterative? Any simple example to show dependency of >> jump-threading analysis on actual transformation of some other >> jump-threading instance (e.g, opportunity only gets exposed after >> transformation)? > > > > During my investigations noticed the same thing and manually reran DOM > from within GDB and verified it further simplified the CFG, but > rerunning DOM isn't really going to be an option. > > >> Is incremental DOM update a choice? I looked at it a few years ago. I never came up with anything even remotely close to working, even at a conceptual level. While the PHI nodes represent places where interesting things happen, I wasn't able to make any leap that would allow me to use some kind of worklist algorithm to pick up the secondary optimization opportunities. During the course of those investigations I came across Bodik's work, and only recently did the light come on with how Bodik's work might translate well into how we handle jump threading. I've been drawn off that work temporarily, but expect to return to it shortly. Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOFiSHAAoJEBRtltQi2kC7PhQH/A7NwXEghs+FUlszsb7rnB9p lZkz1hrMSaVTPgMS2ewOwp6nedpK3pshOFVJHFcLxw1SjOjNePVYccH9XRXSwqSL wiuiLYTv+SfObC7icvTkQuJ0N8eJ6apxo5hBvb3d599DifwAaZHaq/3RoUslcH2O sNSfoQbJGiDSfw3HxAK36IgxRvx3Khe/1GoEMV1W40kiD9tB6wgH5YyAq1Iq6ZHR Ckgqjy/fR8IZtTruSNNCA76erYXOSUc2etQoassYLGvvwsG/htqA1c3D86TQFIfP 0K55jDWMpdOmuxEp0JrUEE0g6jVuOXHY2DPIWAt/YDY2YJwTflYSEjd8wYYqYPM= =/taX -END PGP SIGNATURE-
[Bug c++/47752] Non-dependent name is found in dependent base class although it should be rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47752 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||DUPLICATE Target Milestone|--- |4.7.0 --- Comment #3 from Jason Merrill 2011-07-07 21:29:33 UTC --- Fixed for 4.7. *** This bug has been marked as a duplicate of bug 24163 ***
[Bug c++/24163] dependent Base class scope examined during unqualified name lookup in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24163 Jason Merrill changed: What|Removed |Added CC||volker.simonis at gmail dot ||com --- Comment #9 from Jason Merrill 2011-07-07 21:29:33 UTC --- *** Bug 47752 has been marked as a duplicate of this bug. ***
[Bug c++/47356] Internal error when assigning with incomplete uniform initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47356 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #2 from Jason Merrill 2011-07-07 21:34:44 UTC --- Yes, omitted initializers imply value-initialization of those elements. Fixed in 4.6.0.
[Bug middle-end/49671] New: volatile goes missing after inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49671
Summary: volatile goes missing after inlining
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org
Take:
volatile int t;
static inline int cvmx_atomic_get32(volatile int *ptr)
{
return *ptr;
}
void f(void)
{
while (!cvmx_atomic_get32(&t))
;
}
Nothing fancy but after inlining, we have:
D.2699_5 = t;
Which is wrong as t is volatile
[Bug middle-end/49671] [4.6/4.7 Regression] volatile goes missing after inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49671 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Known to work||4.5.1 Target Milestone|--- |4.6.2 Summary|volatile goes missing after |[4.6/4.7 Regression] |inlining|volatile goes missing after ||inlining Known to fail||4.6.1, 4.7.0 --- Comment #1 from Andrew Pinski 2011-07-07 21:41:35 UTC --- It was broken since at least "GCC: (GNU) 4.6.0 20110210 (experimental) [trunk revision 170025]"
[Bug regression/49498] [4.7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 --- Comment #11 from Hans-Peter Nilsson 2011-07-07 21:51:54 UTC --- (In reply to comment #8) > > 2) On the targets that have the problem, is branch cost considered cheap? > No idea. I didn't bother to look at why cris-elf triggers the problem, > but x86 doesn't. Presumably it's a branch-cost or similar issue. I forgot so I had to look myself... At one time the default cost was measured as the best and that stuck; grep and behold the comment. So, "only" ports using the default are affected. > > Solution > > 1) fix the test case by disabling jumpthreading and if-merging > Or xfailing it for the affected targets. FWIW, I don't mind. Whatever solution you feel proud of. ;)
[Bug c++/49663] [4.7 Regression] [C++0x] ICE in lookup_base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49663 --- Comment #3 from Jason Merrill 2011-07-07 21:54:01 UTC --- Author: jason Date: Thu Jul 7 21:53:58 2011 New Revision: 176013 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176013 Log: PR c++/49663 * pt.c (push_deduction_access_scope): Preserve processing_template_decl across push_to_top_level. And revert: * class.c (pushclass): Accept NULL argument. (popclass): Deal with popping null class. * pt.c (push_access_scope, pop_access_scope): Use them rather than push_to_top_level/pop_from_top_level. * name-lookup.c (lookup_name_real_1): Check current_class_type. Added: trunk/gcc/testsuite/g++.dg/cpp0x/regress/regress4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/48157] Unable to match function call to member function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48157 --- Comment #3 from Jason Merrill 2011-07-07 21:55:11 UTC --- Author: jason Date: Thu Jul 7 21:55:09 2011 New Revision: 176014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176014 Log: PR c++/48157 * pt.c (tsubst_qualified_id): Preserve TEMPLATE_ID_EXPR in partial instantiation. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/template/template-id-4.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/pt.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/49538] [4.7 regression] Revision 175341 causes segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49538 --- Comment #7 from Jarryd Beck 2011-07-07 21:55:06 UTC --- I just wanted to comment here that I have also found this problem. I bisected it to the same revision using my own project. I reported it as bug [[49587]].
[Bug c++/48157] Unable to match function call to member function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48157 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.2 --- Comment #4 from Jason Merrill 2011-07-07 21:55:44 UTC --- Fixed for 4.6.2.
[Bug c++/49663] [4.7 Regression] [C++0x] ICE in lookup_base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49663 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jason Merrill 2011-07-07 21:56:12 UTC --- Fixed.
[Bug c++/49538] [4.7 regression] Revision 175341 causes segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49538 --- Comment #8 from Jarryd Beck 2011-07-07 21:58:45 UTC --- Sorry I linked that wrongly, it's bug 49587.
[Bug c++/49353] C++ frontend should not declare function EXTERN when it forces them to stay
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49353 --- Comment #5 from Jan Hubicka 2011-07-07 22:01:07 UTC --- Thanks for working on this! I guess we could also get rid of the rest of visibility fixup code? (i.e. copying COMDAT_GROUP into thunks&same body aliases and adding them into the cgraph comdat group lists from ipa.c instead of from frontend alone) Thanks a lot, I will look into Java. Honza
[Bug c++/46043] attribute to mark virtual methods that can't be further overriden so they can be devirtualized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46043 Jason Merrill changed: What|Removed |Added Status|NEW |WAITING CC||jason at gcc dot gnu.org --- Comment #6 from Jason Merrill 2011-07-07 22:01:14 UTC --- The final keyword is now supported in C++0x mode. Does that resolve this issue?
[Bug middle-end/49662] [4.7 Regression] FAIL: gcc.dg/graphite/interchange-XX.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49662 --- Comment #2 from Sebastian Pop 2011-07-07 22:40:34 UTC --- The loop nest is not perfect, in interchange-15.c: for (i = 0; i < N; i++) for (j = 0; j < N; j++) x[i] += a[j][i]; used to be perfect nest, now we have x[i] read and written in the outer loop, enough to confuse loop interchange. Please XFail the testcases, or change them to only have a scalar reduction: for (i = 0; i < N; i++) for (j = 0; j < N; j++) x += a[j][i];
[Bug middle-end/49671] [4.6/4.7 Regression] volatile goes missing after inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49671
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.07.07 22:48:48
AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #2 from Andrew Pinski 2011-07-07
22:48:48 UTC ---
Note the following is also broken:
int t;
static inline int cvmx_atomic_get32(int *ptr)
{
return *(volatile int*)ptr;
}
void f(void)
{
while (!cvmx_atomic_get32(&t))
;
}
--- CUT
But that is caused by IPA-SRA.
I have a fix for both issues.
[Bug target/49202] MMIX: Wrong debugging information generated (UNKNOWN: length 2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49202 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson 2011-07-07 23:00:06 UTC --- I hope to check this some time in the next four weeks... At a glance, it might be a binutils issue, with the relocs message.
[Bug middle-end/49671] [4.6/4.7 Regression] volatile goes missing after inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49671 --- Comment #3 from Andrew Pinski 2011-07-07 23:07:02 UTC --- Created attachment 24708 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24708 Fix which I am going to test
[Bug target/49202] MMIX: Wrong debugging information generated (UNKNOWN: length 2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49202 --- Comment #2 from Nils Asmussen 2011-07-07 23:10:32 UTC --- (In reply to comment #1) > I hope to check this some time in the next four weeks... > At a glance, it might be a binutils issue, with the relocs message. Thanks. I don't know if it helps, but a workaround is to remove the lines 22031,22032 of gcc/dwarf2out.c: if (SUPPORTS_DISCRIMINATOR && discriminator != 0) fprintf (asm_out_file, " discriminator %d", discriminator); This way, the unknown debugging information is gone and debugging using gdb works.
[Bug target/49670] internal compiler error: in extract_insn, at recog.c:2104
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670 --- Comment #1 from Jeffrey Walton 2011-07-08 00:45:17 UTC --- Using the stock Crypto++ makefile did not help: g++ -DNDEBUG -g -O2 -mtune=native -pipe -c 3way.cpp g++ -DNDEBUG -g -O2 -mtune=native -pipe -c adler32.cpp g++ -DNDEBUG -g -O2 -mtune=native -pipe -c algebra.cpp g++ -DNDEBUG -g -O2 -mtune=native -pipe -c algparam.cpp g++ -DNDEBUG -g -O2 -mtune=native -pipe -c arc4.cpp g++ -DNDEBUG -g -O2 -mtune=native -pipe -c asn.cpp asn.cpp: In member function ‘void CryptoPP::OID::DEREncode(CryptoPP::BufferedTransformation&) const’: asn.cpp:254:1: error: unrecognizable insn: (insn 194 178 195 2 asn.cpp:248 (set (reg:SI 2 cx) (mem:QI (plus:SI (reg/f:SI 1 dx [orig:61 D.44160 ] [61]) (const_int 4 [0x4])) [16 S1 A32])) -1 (nil)) asn.cpp:254:1: internal compiler error: in extract_insn, at recog.c:2104 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make: *** [asn.o] Error 1
[Bug target/49670] internal compiler error: in extract_insn, at recog.c:2104
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670
--- Comment #2 from Jeffrey Walton 2011-07-08
00:47:53 UTC ---
For completeness, here's the function
(http://www.cryptopp.com/docs/ref/asn_8cpp_source.html):
00244 void OID::DEREncode(BufferedTransformation &bt) const
00245 {
00246 assert(m_values.size() >= 2);
00247 ByteQueue temp;
00248 temp.Put(byte(m_values[0] * 40 + m_values[1]));
00249 for (size_t i=2; i
