[Bug middle-end/40611] GCC error: in dwarf2out_begin_epilogue, at dwarf2out.c:2773
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-07-02 06:08 --- *** This bug has been marked as a duplicate of 40347 *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40611
[Bug bootstrap/40347] [4.5 Regression] i386-darwin ICEs while building libgcc during stage2
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2009-07-02 06:08 --- *** Bug 40611 has been marked as a duplicate of this bug. *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40347
[Bug libstdc++/40606] Inside new_handler throw; operator may cause abort
--- Comment #7 from tsyvarev at ispras dot ru 2009-07-02 06:16 --- gcc --version gets: gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291] Yes, problem very probably target dependent - as I said, test suite was executed on many other machines, including IA64 arhictecures with other OSes(even SLES10) and SLES11 on other architectures(even on x86_64). But problem have arisen only on SLES11[IA64]. -- tsyvarev at ispras dot ru changed: What|Removed |Added GCC target triplet||ia64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606
[Bug target/40615] New: unnecessary CSE
Compile the attached source code with options -march=armv5te -mthumb -Os
-fno-exceptions, gcc generates:
push{r4, lr}
sub sp, sp, #8
add r4, sp, #4// redundant
mov r0, r4// add r0, sp, 4
bl _ZN1XC1Ev
mov r0, r4// add r0, sp, 4
bl _Z3barP1X
mov r0, r4// add r0, sp, 4
bl _ZN1XD1Ev
add sp, sp, #8
@ sp needed for prologue
pop {r4, pc}
As mentioned in the comments, the cse is redundant. We can recompute the value
of (sp + 4) each time we want it. With this method we can save one instruction.
--
Summary: unnecessary CSE
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
[Bug target/40615] unnecessary CSE
--- Comment #1 from carrot at google dot com 2009-07-02 07:39 --- Created an attachment (id=18120) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18120action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
[Bug target/40615] unnecessary CSE
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-02 08:53 --- This looks like one of those rematerialization problems albeit with the stack pointer this time. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-02 08:53:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
[Bug target/40615] unnecessary CSE
--- Comment #3 from steven at gcc dot gnu dot org 2009-07-02 09:15 --- Is there a C test case? Can you add objdump of the gcc-generated asm and the fixed asm to show the impact on code size? (/me is surprised that 3*add r0,sp,4 is smaller than 1**add r0,sp,4+3*mov r0,r4... Thumb is amazing :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
[Bug target/40606] Inside new_handler throw; operator may cause abort
--- Comment #8 from paolo dot carlini at oracle dot com 2009-07-02 09:29 --- Richard, can you please have a quick look? I don't have any ia64 machine available and the problem can't reproduce for me on x86_64 with 4_3/4_4/4_5 -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Component|libstdc++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606
[Bug target/40615] unnecessary CSE
--- Comment #4 from ramana at gcc dot gnu dot org 2009-07-02 09:39 ---
(In reply to comment #3)
Is there a C test case? Can you add objdump of the gcc-generated asm and the
fixed asm to show the impact on code size? (/me is surprised that 3*add
r0,sp,4 is smaller than 1**add r0,sp,4+3*mov r0,r4... Thumb is amazing
:-)
The length of add r0,sp,4 and mov r0,r4 is the same for Thumb1 (16 bits).
I suppose the ideal code generated would be something like this modulo errors
with stack alignments in the prologue and the epilogue.
We also don't need r4 in that case :) . So we can save a load, a store as well
as 1 instruction over all. Smaller and faster by 1 instruction and reduced
register usage.
push{lr}
sub sp, sp, #12 (8 byte stack alignment )
add r0, sp, 4// add r0, sp, 4
bl _ZN1XC1Ev
add r0, sp, #4// add r0, sp, 4
bl _Z3barP1X
add r0, sp, #4 // add r0, sp, 4
bl _ZN1XD1Ev
add sp, sp, #12(8 byte stack alignment )
@ sp needed for prologue
pop {pc}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
[Bug middle-end/39886] [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274
--- Comment #4 from hubicka at ucw dot cz 2009-07-02 10:05 --- Subject: Re: [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274 Would you mind seeing if your patch was the same? I wanted to prevent the (set pc pc) trick, but this seems like easier fix for the problem :) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39886
[Bug libstdc++/40613] [4.5 regression] 23_containers/multiset/invalidation/1.cc
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-02 10:07 --- Today, with 149169, I can't reproduce this problem. By the way, I suspect an ICE or something similar was happening, definitely wrong categorization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40613
[Bug target/40606] Inside new_handler throw; operator may cause abort
--- Comment #10 from paolo dot carlini at oracle dot com 2009-07-02 10:08 --- Thanks Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #13 from hubicka at ucw dot cz 2009-07-02 10:10 --- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852 OK, on i386 it has some effect according to our nightly tester it is 3524421-3510754. The size used to be as low as 3431090 so it is just small improvement. I guess I will commit the patch anyway as it is quite obvious fix. The other problem might be the likely_eliminated_by_inlining_p predicate that is very optimisitic. This predicate makes inliner to believe that all indirect reads and writes to/from pointers passed to function or function parameters will be optimized out. This is important to allow inlining of methods and SRAing out objects in C++ and devirtualizing calls, but for C code it is bit too optimistic. Partly this can be cured by IPA-SRA and Martin has WIP patch for clonning that contains more fine grained analysis of function body size specialized for given parameters. I however doubt they will catch all the cases we need for C++. Perhaps simply disabling the predicate for -Os or making it just weak hint (removing some percentage of estimated cost) is best way to go, I am just re-testing it on vangelis with size estimates ignoring it. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug target/40606] Inside new_handler throw; operator may cause abort
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-02 10:05 ---
I can reproduce it, the abort is from the system libunwind:
(gdb) run
Starting program: /tmp/a.out
Executing test_4_10()
#0 0xa0010721 in __kernel_syscall_via_break ()
#1 0x20422940 in *__GI_raise (sig=value optimized out)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
#2 0x20425210 in *__GI_abort () at abort.c:88
#3 0x20383a40 in _UIia64__sos_alloc (size=736) at mi/mempool.c:61
#4 0x20383c30 in expand (pool=0x203ab990) at mi/mempool.c:137
#5 0x20383e00 in _UIia64__mempool_alloc (pool=0x203ab990)
at mi/mempool.c:180
#6 0x2038a680 in desc_prologue (body=0, rlen=9, mask=12 '\f',
grsave=44 ',', sr=0x6007b218) at ia64/Gparser.c:52
#7 0x2038ce40 in create_state_record_for (c=0x6007baf0,
sr=0x6007b218, ip=value optimized out)
at ia64/unwind_decoder.h:204
#8 0x20394ed0 in uncached_find_save_locs (c=0x6007baf0)
at ia64/Gscript.c:458
#9 0x20396420 in _ULia64_find_save_locs (c=0x6007baf0)
at ia64/Gscript.c:662
#10 0x20397710 in _ULia64_step (cursor=0x6007baf0)
at ia64/Gstep.c:338
#11 0x20385ce0 in _Unwind_RaiseException (
exception_object=0x20251860) at unwind/unwind-internal.h:78
#12 0x20386400 in _Unwind_Resume_or_Rethrow (
exception_object=0x20251860) at unwind/Resume_or_Rethrow.c:43
#13 0x201fd510 in __cxa_rethrow () from /usr/lib/libstdc++.so.6
#14 0x40001b50 in NewHandlerBox::new_handler_box () at test.cpp:188
#15 0x201fe2e0 in operator new(unsigned long) ()
from /usr/lib/libstdc++.so.6
#16 0x40001530 in test_4_10 () at test.cpp:257
#17 0x40001900 in main (argc=4145104, argv=0xc48c)
at test.cpp:431
which means libunwind cannot allocate memory.
(gdb) p *pool
$2 = {lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0,
__kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},
__size = '\0' repeats 39 times, __align = 0}, obj_size = 736,
chunk_size = 65536, reserve = 44, num_free = 16,
free_list = 0x203afcc0}
the pool seems to have plenty of space, no idea why it is expanded...
if (pool-num_free = pool-reserve)
expand (pool);
assert (pool-num_free 0);
obviously expand here doesn't need to fatally fail here ...
OTOH alloc_memory
static void *
alloc_memory (size_t size)
{
/* Hopefully, mmap() goes straight through to a system call stub... */
void *mem = mmap (0, size, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (mem == MAP_FAILED)
return NULL;
fails with a size of 65536.
This is a libunwind bug on one hand (the unnecessary fatal fail) and an
invalid testcase because you make libunwind fail by setrlimit.
Thus, invalid - not a GCC bug. You might want to file the libunwind bug
where that is appropriate (http://savannah.nongnu.org/projects/libunwind/).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606
[Bug libgcj/40616] New: libgcj version of java.io.PrintStream missing constructors
There are some new 1.5 PrintStream constructors that are in GNU Classpath but not in the local gcj version of the same file. This causes the OpenJDK7 b62 build to fail: /mnt/builder/icedtea/bootstrap/jdk1.6.0/bin/javac -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -encoding ascii -XDignore.symbol.file=true -d /mnt/builder/icedtea/openjdk-ecj/build/linux-amd64/btclasses \ -sourcepath ../../tools/src -classpath /mnt/builder/icedtea/bootstrap/jdk1.7.0/jre/lib/rt-closed.jar \ ../../tools/src/build/tools/charsetmapping/Main.java -- 1. ERROR in /mnt/builder/icedtea/openjdk-ecj/jdk/make/tools/CharsetMapping/../../tools/src/build/tools/charsetmapping/GenerateEUC_TW.java (at line 40) new PrintStream(new File(args[1], EUC_TWMapping.java), ISO-8859-1), ^^ The constructor PrintStream(File, String) is undefined http://builder.classpath.org/japi/classpath-libgcj.html#err_missing_java_io -- Summary: libgcj version of java.io.PrintStream missing constructors Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu_andrew at member dot fsf dot org OtherBugsDependingO 39410 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40616
[Bug target/40606] Inside new_handler throw; operator may cause abort
--- Comment #11 from tsyvarev at ispras dot ru 2009-07-02 11:26 --- Ok, sorry for noise. I'll try with libunwind. Only thing - what does it mean invalid testcase because you make libunwind fail by setrlimit. Does it mean that setrlimit shouldn't be used with new operator? or with exception unwind mechanism? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40606
[Bug debug/40596] [4.5 regression] Bad debug info for local variables on i386.
--- Comment #5 from jakub at gcc dot gnu dot org 2009-07-02 11:30 --- Fix posted: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00091.html -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||07/msg00091.html Status|NEW |ASSIGNED Last reconfirmed|2009-06-29 21:51:45 |2009-07-02 11:30:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40596
[Bug libstdc++/40613] [4.5 regression] 23_containers/multiset/invalidation/1.cc
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40613
[Bug c++/40614] no -Werror= for attribute warn_unused_result
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-02 11:33 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2009-07-02 11:33:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40614
[Bug debug/40599] [4.5 regression] GCC error in pre_and_rev_post_order_compute, at cfganal.c:1045
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-02 11:37 --- Jakub should maybe know more ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40599
[Bug target/22073] --with-cpu=default32 for x86_64
--- Comment #7 from marek dot rouchal at infineon dot com 2009-07-02 11:46 --- (In reply to comment #5) What you want is --with-cpu=default32 for x86_64 which does not exist yet. It does for powerpc64 though. I'd like to ping this request once again - it seems that there was no progress on this. The requirement actually is as follows: When building gcc on x86_64 (amd64), currently the resulting gcc (and g++, gfortran etc.) binaries are 64bit. This is unlike Solaris, where the binaries are 32bit. On both platforms, gcc is able to produce 32bit and 64bit binaries (thanks to the multilib support). For a network installation of gcc, with 32bit (i686) and 64bit (x86_64) Linux hosts it would be preferable, if the gcc binaries were 32bit - then gcc would run on both CPU types; and on the x86_64 systems, it would be able to build 64bit binaries with -m64. So far I have not found a way to pass -m32 selectively through the gcc bootstrap process such that the gcc (g++, gfortran, ...) binaries would be 32bit, while the multilib support would remain as is. Any hints are appreciated. Many thanks, Marek -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22073
[Bug libstdc++/40613] [4.5 regression] 23_containers/multiset/invalidation/1.cc
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-02 11:40 --- Apparently, HJ can't reproduce it either: http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00122.html -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40613
[Bug target/22073] --with-cpu=default32 for x86_64
--- Comment #8 from jsm28 at gcc dot gnu dot org 2009-07-02 11:57 --- For a 32-bit-default compiler that can also build 64-bit code, configure for i686-pc-linux-gnu with --enable-targets=all. (Set CC=gcc -m32 and CC_FOR_BUILD=gcc -m32 in your environment and configure --enable-targets=all --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu.) This is implemented in 4.3 and later. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22073
[Bug tree-optimization/40585] [4.3/4.4/4.5 Regression] tracer duplicates blocks w/o adjusting EH tree
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-02 12:16 --- Subject: Bug 40585 Author: rguenth Date: Thu Jul 2 12:15:27 2009 New Revision: 149172 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149172 Log: 2009-07-02 Richard Guenther rguent...@suse.de PR middle-end/40585 * tree-cfg.c (tree_can_duplicate_bb_p): Disallow duplicating basic blocks with RESX_EXPR. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40585
[Bug tree-optimization/40585] [4.3/4.4/4.5 Regression] tracer duplicates blocks w/o adjusting EH tree
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-07-02 12:16 --- Subject: Bug 40585 Author: rguenth Date: Thu Jul 2 12:16:39 2009 New Revision: 149173 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149173 Log: 2009-07-02 Richard Guenther rguent...@suse.de PR middle-end/40585 * tree-cfg.c (gimple_can_duplicate_bb_p): Disallow duplicating basic blocks with GIMPLE_RESX. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40585
[Bug tree-optimization/40585] [4.5 Regression] tracer duplicates blocks w/o adjusting EH tree
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-02 12:17 --- Fixed on the branches. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.3 4.4.0 4.5.0 Known to work||4.3.4 4.4.1 Summary|[4.3/4.4/4.5 Regression]|[4.5 Regression] tracer |tracer duplicates blocks w/o|duplicates blocks w/o |adjusting EH tree |adjusting EH tree Target Milestone|4.3.4 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40585
[Bug tree-optimization/40585] [4.5 Regression] tracer duplicates blocks w/o adjusting EH tree
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40585
[Bug fortran/31593] Invariant DO loop variables and subroutines
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-02 12:36 --- call output (p1, p2, p3, p4) That still clobbers p1, p2, p3, and p4 as they are passed by reference so is it really undefined code if output changes the values for the do loop? Yes. Conformance can now be tested at runtime via -fcheck=do. If one wants to change the loop variable, one should use i=0; do; i = i + 1; if(i = 10) exit; end do instead. From the F2003 standard, which also applies to loops of the form (2*i, i=1,N) 8.1.6.4.2 The execution cycle: Except for the incrementation of the DO variable that occurs in step (3), the DO variable shall neither be redefined nor become undefined while the DO construct is active. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593
[Bug bootstrap/40617] New: [4.5 Regression] Revision 149170 breaks bootstrap
Revision 149170: http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00046.html breaks bootstrap on Linux/ia32: /export/gnu/import/svn/gcc-test/bld/./prev-gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/./prev-gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include-c -g -O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../src-trunk/gcc -I../../src-trunk/gcc/build -I../../src-trunk/gcc/../include -I../../src-trunk/gcc/../libcpp/include -I../../src-trunk/gcc/../libdecnumber -I../../src-trunk/gcc/../libdecnumber/bid -I../libdecnumber\ -o build/gencheck.o ../../src-trunk/gcc/gencheck.c build/genmodes tmp-modes.c /bin/sh: line 1: 23689 Segmentation fault build/genmodes tmp-modes.c make[6]: *** [s-modes] Error 139 make[6]: *** Waiting for unfinished jobs rm gcj-dbtool.pod fsf-funding.pod jcf-dump.pod jv-convert.pod grmic.pod gcov.pod gcj.pod gc-analyze.pod gfdl.pod cpp.pod gij.pod gcc.pod gfortran.pod make[6]: Leaving directory `/export/gnu/import/svn/gcc-test/bld/gcc' make[5]: *** [all-stage2-gcc] Error 2 make[5]: Leaving directory `/export/gnu/import/svn/gcc-test/bld' make[4]: *** [stage2-bubble] Error 2 -- Summary: [4.5 Regression] Revision 149170 breaks bootstrap Product: gcc Version: 4.4.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=40617
[Bug other/40618] New: when flex is not installed, gcc build stop because of a non existent file
when flex is not installed, configure detects that flex is not installed but doesn't emit an error. Flex is required to build gcc-4.5 (to produce gengtype-lex.c). So, if no flex, no gcc :-) YC -- Summary: when flex is not installed, gcc build stop because of a non existent file Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ycollet at freesurf dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40618
[Bug bootstrap/40617] [4.5 Regression] Revision 149170 breaks bootstrap
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-02 13:46 --- For 4.5 you mean? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Version|4.4.0 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
[Bug bootstrap/40617] [4.5 Regression] Revision 149170 breaks bootstrap
--- Comment #2 from hjl dot tools at gmail dot com 2009-07-02 13:51 --- (In reply to comment #1) For 4.5 you mean? Yes. Only on Linux/ia32. Linux/x86-64 passed that failure point. -- hjl dot tools at gmail dot com changed: What|Removed |Added Version|4.5.0 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
[Bug target/22073] --with-cpu=default32 for x86_64
--- Comment #9 from marek dot rouchal at infineon dot com 2009-07-02 13:52 --- (In reply to comment #8) For a 32-bit-default compiler that can also build 64-bit code, configure for i686-pc-linux-gnu with --enable-targets=all. (Set CC=gcc -m32 and CC_FOR_BUILD=gcc -m32 in your environment and configure --enable-targets=all --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu.) This is implemented in 4.3 and later. I tried this - and it does not work here. I even added STAGE1_CFLAGS=-m32 -g as suggested in an earlier comment. The build of gcc-4.3.2 bails out at this point: gmake[7]: Leaving directory `/var/vob/relman/admin/vob/devenv/Gcc/linux40_64/gcc-4.3.2/gcc' mkdir -p -- i686-pc-linux-gnu/libgcc Checking multilib configuration for libgcc... Configuring stage 1 in i686-pc-linux-gnu/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... gawk checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for i686-pc-linux-gnu-ar... ar checking for i686-pc-linux-gnu-lipo... lipo checking for i686-pc-linux-gnu-nm... /var/vob/relman/admin/vob/devenv/Gcc/linux40_64/gcc-4.3.2/./gcc/nm checking for i686-pc-linux-gnu-ranlib... ranlib checking for i686-pc-linux-gnu-strip... strip checking whether ln -s works... yes checking for i686-pc-linux-gnu-gcc... /var/vob/relman/admin/vob/devenv/Gcc/linux40_64/gcc-4.3.2/./gcc/xgcc -B/var/vob/relman/admin/vob/devenv/Gcc/linux40_64/gcc-4.3.2/./gcc/ -B/opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/bin/ -B/opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/lib/ -isystem /opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/include -isystem /opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/sys-include checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. The relevant portion of the gcc-4.3.2/i686-pc-linux-gnu/libgcc/config.log is: configure:2398: /var/vob/relman/admin/vob/devenv/Gcc/linux40_64/gcc-4.3.2/./gcc/xgcc -B/var/vob/relman/admin/vob/devenv/Gcc/linux40_64/gcc-4.3.2/./gcc/ -B/opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/bin/ -B/opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/lib/ -isystem /opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/include -isystem /opt/gcc_4.3.2/linux40_64/i686-pc-linux-gnu/sys-include -o conftest -g -fkeep-inline-functions -Wl,-rpath,/opt/gcc_4.3.2/linux40_64/ext/lib conftest.c 5 /tmp/ccIIK43d.s: Assembler messages: /tmp/ccIIK43d.s:19: Error: suffix or operands invalid for `push' /tmp/ccIIK43d.s:21: Error: suffix or operands invalid for `push' /tmp/ccIIK43d.s:25: Error: suffix or operands invalid for `push' /tmp/ccIIK43d.s:30: Error: suffix or operands invalid for `pop' /tmp/ccIIK43d.s:31: Error: suffix or operands invalid for `pop' I assume that the -m32 option is not passed through correctly. I think that in gcc-4.3.2/Makefile the HOST_EXPORTS macro does not contain the appropriate CFLAGS. Or is this perhaps fixed in gcc-4.3.3? -- marek dot rouchal at infineon dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Known to fail||4.3.2 Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22073
[Bug bootstrap/40617] [4.5 Regression] Revision 149170 breaks bootstrap
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-02 14:24 --- Thus, please somebody attach genmodes.i that is miscompiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
[Bug bootstrap/40617] [4.5 Regression] Revision 149170 breaks bootstrap
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-07-02 14:31 --- Ok, I see it with stage3 only :( build/genmodes tmp-modes.c /bin/sh: line 1: 16996 Segmentation fault build/genmodes tmp-modes.c make[3]: *** [s-modes] Error 139 make[3]: *** Waiting for unfinished jobs rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gcc.pod make[3]: Leaving directory `/abuild/rguenther/obj-32/gcc' make[2]: *** [all-stage3-gcc] Error 2 make[2]: Leaving directory `/abuild/rguenther/obj-32' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/abuild/rguenther/obj-32' make: *** [all] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
[Bug bootstrap/40617] [4.5 Regression] Revision 149170 breaks bootstrap
--- Comment #7 from hjl dot tools at gmail dot com 2009-07-02 14:36 --- (In reply to comment #6) Ok, I see it with stage3 only :( build/genmodes tmp-modes.c /bin/sh: line 1: 16996 Segmentation fault build/genmodes tmp-modes.c make[3]: *** [s-modes] Error 139 make[3]: *** Waiting for unfinished jobs rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gcc.pod make[3]: Leaving directory `/abuild/rguenther/obj-32/gcc' make[2]: *** [all-stage3-gcc] Error 2 make[2]: Leaving directory `/abuild/rguenther/obj-32' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/abuild/rguenther/obj-32' make: *** [all] Error 2 Configuring gcc with ../src-trunk/configure --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld may see it in stage2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
[Bug c++/40619] New: [c++0x] ICE on repeated decltype expression in auto functions
templatetypename U struct X {};
templatetypename T auto f(T t) - Xdecltype(t+1) {}
templatetypename T auto g(T t) - Xdecltype(t+1) {}
Compiling with -std=c++0x gives
decltype_ice.cc:4:52: internal compiler error: Segmentation fault: 11
--
Summary: [c++0x] ICE on repeated decltype expression in auto
functions
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aaz at althenia dot net
GCC build triplet: x86_64-portbld-freebsd7.2
GCC host triplet: x86_64-portbld-freebsd7.2
GCC target triplet: x86_64-portbld-freebsd7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40619
[Bug bootstrap/40617] [4.5 Regression] Revision 149170 breaks bootstrap
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-02 14:16 --- Hm, I'm into stage2 and genmodes was already built and executed fine - so, I don't seem to be able to reproduce it right now. How did you configure? I did /space/rguenther/tramp3d/trunk/configure --enable-languages=c --disable-nls --with-build-time-tools=/abuild/rguenther/tools32/usr/bin which configures for i686-pc-linux-gnu for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
[Bug bootstrap/40617] [4.5 Regression] Revision 149170 breaks bootstrap
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 Version|4.4.0 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
[Bug bootstrap/40617] [4.5 Regression] Revision 149170 breaks bootstrap
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-02 13:56 --- Ok, I'm trying to reproduce and get genmodes.i. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
--- Comment #7 from heydowns at borg dot com 2009-07-02 14:46 --- Created an attachment (id=18121) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18121action=view) Proposed fix: Changes linking on solaris based on std=X and implements escapes in braced specs Attaching a fix that works here for Solaris 10 and I think would work for other Solaris versions. It changes the spec to account for the other options mentioned in comment 3, to handle the main issue of the bug (link values-xpg6.o in c99 mode), and also adds linking of values-xpg4.o as the Solaris manual suggests should be done. I wasn't sure exactly how to handle the various -std=gnu* modes, so I left those as they were. To enable matching on ':' in std=iso9899:, I had to augment the spec language, as suggested in comment 6. I realize you might want to treat this as a separate issue -- I can open a separate issue for this if you want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411
[Bug bootstrap/40617] [4.5 Regression] Revision 149170 breaks bootstrap
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-07-02 14:55 --- Hmm, building genmodes.o with -save-temps makes the segfault go away... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
[Bug c++/40619] [c++0x] ICE on repeated decltype expression in auto functions
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-02 14:59 --- Jason, can you have a look to this one? Thanks in advance! -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-02 14:59:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40619
[Bug bootstrap/40617] [4.5 Regression] Revision 149170 breaks bootstrap
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-02 15:01 --- Ok, i have an idea. -- 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 |2009-07-02 15:01:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
[Bug rtl-optimization/11832] Optimization of common code in switch statements
--- Comment #8 from aldot at gcc dot gnu dot org 2009-07-02 15:05 --- Important reminder from steven from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33828#c13 stevenb GCC should not hoist up further than up to the first common dominator. i.e. ..can be Hoisted to B from #3 and _not_ to the def_stmt (iff the def_stmt is not in B of course, if it is then it's obviously the correct spot to hoist to). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11832
[Bug fortran/30733] VOLATILE: Missed optimization - attribute not restricted to scope
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-02 15:07 --- Restricting can be done via casting to volatile - then it is only *(volatile int *)i That needs then to be applies in all expressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30733
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #10 from burnus at gcc dot gnu dot org 2009-07-02 14:44 --- Michael Matz fixed that for allocatable arrays, but the patch needs to be extended to nonallocatable arrays, cf. http://gcc.gnu.org/ml/fortran/2009-07/msg4.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug rtl-optimization/11832] Optimization of common code in switch statements
--- Comment #9 from steven at gcc dot gnu dot org 2009-07-02 15:12 --- Note I have various working patches for GVN-based hoisting. All of them are actually too aggressive, causing failures in the vectorizer test cases (unrecognizable data dependency patterns). But I still intend to post one of the versions for inclusion in GCC 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11832
[Bug target/22073] --with-cpu=default32 for x86_64
--- Comment #10 from jsm28 at gcc dot gnu dot org 2009-07-02 15:17 --- If you are building an i686-pc-linux-gnu compiler you should start by building i686-pc-linux-gnu binutils (configured --enable-64-bit-bfd) and installing them in the same prefix in which you are going to install GCC (making sure to put the bin/ directory of that prefix on your PATH). -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22073
[Bug other/40618] when flex is not installed, gcc build stop because of a non existent file
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-02 15:29 --- flex is only required to build svn checkouts or snapshots. Release tarballs contain the generated files. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40618
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #11 from matz at gcc dot gnu dot org 2009-07-02 15:31 --- Subject: Bug 32131 Author: matz Date: Thu Jul 2 15:31:28 2009 New Revision: 149178 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149178 Log: fortran/ PR fortran/32131 * trans-array.c (gfc_conv_descriptor_stride_get): Return constant one for strides in the first dimension of ALLOCATABLE arrays. testsuite/ PR fortran/32131 * gfortran.dg/pr32921.f: Adjust. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr32921.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug tree-optimization/20165] Pointer does not really escape with write
--- Comment #6 from steven at gcc dot gnu dot org 2009-07-02 15:40 --- Dan, you mentioned a pointer_no_escape attribute. What was that about? I've never seen that mentioned before (or a patch to implement it). Sounds like a cool attribute to have (and not just for Fortran, too). -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, rguenth at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20165
[Bug tree-optimization/20165] Pointer does not really escape with write
--- Comment #7 from rguenther at suse dot de 2009-07-02 15:46 --- Subject: Re: Pointer does not really escape with write On Thu, 2 Jul 2009, steven at gcc dot gnu dot org wrote: --- Comment #6 from steven at gcc dot gnu dot org 2009-07-02 15:40 --- Dan, you mentioned a pointer_no_escape attribute. What was that about? I've never seen that mentioned before (or a patch to implement it). Sounds like a cool attribute to have (and not just for Fortran, too). There are several useful things to specify per pointer argument: 1) whether it escapes 2) whether pointed-to memory is read 3) whether pointed-to memory is written to 4) whether memory reachable from it is read 5) whether memory reachable form it is written to 6) whether addresses to pointed-to memory may be returned 7) whether addresses to reachable memory may be returned in addition to, of course, if the function reads from / writes to global memory. Zdenek hat a patch with some fancy attribute at some point, and implementation-wise I'd like to have something that shares representation with IPA-PTA results. We do have tasks to do both IPA-PTA and the above attribute btw. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20165
[Bug bootstrap/40617] [4.5 Regression] Revision 149170 breaks bootstrap
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-07-02 15:50 --- Subject: Bug 40617 Author: rguenth Date: Thu Jul 2 15:50:26 2009 New Revision: 149179 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149179 Log: 2009-07-02 Richard Guenther rguent...@suse.de PR bootstrap/40617 * tree-ssa-structalias.c (new_var_info): Initialize is_restrict_var. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40617
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc gcc-4.2.x
--- Comment #15 from jan at codejunky dot org 2009-07-02 16:26 --- Same problem here on powerpc-32: powerpc-unknown-linux-gnu-gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o rs6000-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpfr -lgmp /usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/../../../crt1.o: In function `_start': (.text+0x20): relocation truncated to fit: R_PPC_REL24 against symbol `__libc_start_main@@GLIBC_2.0' defined in .plt section in /usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/../../../crt1.o /usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/../../../crti.o: In function `_init': initfini.c:(.init+0x10): relocation truncated to fit: R_PPC_LOCAL24PC against symbol `_GLOBAL_OFFSET_TABLE_' defined in .got section in /usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/../../..make[3]: Leaving directory `/var/tmp/paludis/build/sys-devel-gcc-4.4.0-r1/work/gcc_build/gcc' make[2]: Leaving directory `/var/tmp/paludis/build/sys-devel-gcc-4.4.0-r1/work/gcc_build' make[1]: Leaving directory `/var/tmp/paludis/build/sys-devel-gcc-4.4.0-r1/work/gcc_build' /crt1.o+fffc c-lang.o: In function `VEC_tree_base_quick_insert': /var/tmp/paludis/build/sys-devel-gcc-4.4.0-r1/work/gcc-4.4.0/gcc/tree.h:190: relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .plt section in /usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/../../../crt1.o c-lang.o: In function `VEC_tree_base_ordered_remove': /var/tmp/paludis/build/sys-devel-gcc-4.4.0-r1/work/gcc-4.4.0/gcc/tree.h:190: relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .plt section in /usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/../../../crt1.o c-lang.o: In function `VEC_tree_base_block_remove': /var/tmp/paludis/build/sys-devel-gcc-4.4.0-r1/work/gcc-4.4.0/gcc/tree.h:190: relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .plt section in /usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/../../../crt1.o c-lang.o: In function `VEC_tree_gc_copy': /var/tmp/paludis/build/sys-devel-gcc-4.4.0-r1/work/gcc-4.4.0/gcc/tree.h:191: relocation truncated to fit: R_PPC_REL24 against symbol `memcpy@@GLIBC_2.0' defined in .plt section in /usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/../../../crt1.o c-lang.o: In function `VEC_tree_gc_safe_grow_cleared': /var/tmp/paludis/build/sys-devel-gcc-4.4.0-r1/work/gcc-4.4.0/gcc/tree.h:191: relocation truncated to fit: R_PPC_REL24 against symbol `memset@@GLIBC_2.0' defined in .plt section in /usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/../../../crt1.o c-lang.o: In function `VEC_tree_heap_free': /var/tmp/paludis/build/sys-devel-gcc-4.4.0-r1/work/gcc-4.4.0/gcc/tree.h:192: relocation truncated to fit: R_PPC_REL24 against symbol `free@@GLIBC_2.0' defined in .plt section in /usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/../../../crt1.o c-lang.o: In function `VEC_tree_heap_copy': /var/tmp/paludis/build/sys-devel-gcc-4.4.0-r1/work/gcc-4.4.0/gcc/tree.h:192: relocation truncated to fit: R_PPC_REL24 against symbol `memcpy@@GLIBC_2.0' defined in .plt section in /usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/../../../crt1.o c-lang.o: In function `VEC_tree_heap_safe_grow_cleared': /var/tmp/paludis/build/sys-devel-gcc-4.4.0-r1/work/gcc-4.4.0/gcc/tree.h:192: relocation truncated to fit: R_PPC_REL24 against symbol `memset@@GLIBC_2.0' defined in .plt section in /usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.0/../../../crt1.o c-lang.o: In function `VEC_constructor_elt_base_quick_insert': /var/tmp/paludis/build/sys-devel-gcc-4.4.0-r1/work/gcc-4.4.0/gcc/tree.h:1532: additional relocation overflows omitted from the output collect2: ld returned 1 exit status make[3]: *** [cc1-dummy] Error 1 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [bootstrap] Error 2 gcc-4.4.0 binutils-2.19.1 -- jan at codejunky dot org changed: What|Removed |Added CC||jan at codejunky dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug c/40620] New: ICE in dwarf2out_begin_epilogue, at dwarf2out.c:2773 [regression]
/home/joel/test-gcc/b-gcc1-sparc/./gcc/xgcc -B/home/joel/test-gcc/b-gcc1-sparc/./gcc/ -nostdinc -B/home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/ -isystem /home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/targ-include -isystem /home/joel/test-gcc/gcc-svn/newlib/libc/include -B/home/joel/test-gcc/install/sparc-rtems4.10/bin/ -B/home/joel/test-gcc/install/sparc-rtems4.10/lib/ -isystem /home/joel/test-gcc/install/sparc-rtems4.10/include -isystem /home/joel/test-gcc/install/sparc-rtems4.10/sys-include-g -O2 -msoft-float -O2 -I/home/joel/test-gcc/gcc-svn/gcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/home/joel/test-gcc/gcc-svn/libgcc -I/home/joel/test-gcc/gcc-svn/libgcc/. -I/home/joel/test-gcc/gcc-svn/libgcc/../gcc -I/home/joel/test-gcc/gcc-svn/libgcc/../include -DHAVE_CC_TLS -o _gcov_average_profiler.o -MT _gcov_average_profiler.o -MD -MP -MF _gcov_average_profiler.dep -DL_gcov_average_profiler -c /home/joel/test-gcc/gcc-svn/libgcc/../gcc/libgcov.c /home/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind-dw2-fde.c: In function '__register_frame_info_table_bases': /home/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind-dw2-fde.c:141:1: internal compiler error: in dwarf2out_begin_epilogue, at dwarf2out.c:2773 -- Summary: ICE in dwarf2out_begin_epilogue, at dwarf2out.c:2773 [regression] Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC target triplet: sparc-rtems4.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40620
[Bug inline-asm/40621] New: GCC doesn't take into account ECX being modified inside inline assembler
GCC doesn't produce the correct assembler code when I use optimizations.
[code]
#include stdio.h
#define mulscale(a,d,c) \
({ int __a=(a), __d=(d), __c=(c); \
__asm__ __volatile__ (imull %%edx; shrdl %%cl, %%edx, %%eax \
: =a (__a), =d (__d) \
: a (__a), d (__d), c (__c) : cc); \
__a; })
#define divscale(a,b,c) \
({ int __a=(a), __b=(b), __c=(c); \
__asm__ __volatile__ (movl %%eax, %%edx; shll %%cl, %%eax; negb %%cl;
sarl %%cl, %%edx; idivl %%ebx \
: =a (__a) : a (__a), c (__c), b (__b) : edx, cc); \
__a; })
void badcode(int scale,int i,int vx,int vy,int vz)
{
int x1,y1;
i = divscale(i,vz,scale);
printf( );
x1 = mulscale(vx,i,scale);
y1 = mulscale(vy,i,scale);
printf(%d %d\n,x1,y1);
}
int main()
{
badcode(29,1856,-2048,-59,768);
return 0;
}
[/code]
Scenario 1:
Compile options -O0
Program output -4950 -143
CORRECT
Scenario 2:
Compile options -O1
Uncomment the printf( )
Program output -4950 -143
CORRECT but it's an ugly workaround
Scenario 3:
Compile options -O1
Comment out the printf( )
Program output -1431655680 -978670931
INCORRECT
The
screenshot(http://www.mediafire.com/?sharekey=bf284efa985bb0620dec85adfe0a530ae04e75f6e8ebb871)
shows comparison between Scenario 2 and Scenario 3.
As you can see, GCC stores the scale variable in ECX which is modified later
and GCC fails to restore it.
In the meantime I fixed my code by saving ECX in the stack.
I understand it might be difficult to detect all the cases when registers are
modified(especially when it happens implicitly) but
if GCC actually tries to do so and fails, this ticket can be considered as a
bugreport rather a feature request.
By the way, I'm quite impressed that GCC is smart enough to replace printf( )
with putch(' ').
--
Summary: GCC doesn't take into account ECX being modified inside
inline assembler
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hunterggl at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40621
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc gcc-4.2.x
--- Comment #16 from lucier at math dot purdue dot edu 2009-07-02 16:35 --- OK, so we've had several reliable reports that this bug still exists, but I'm not high enough in the GCC bugzilla hierarchy to reopen this bug (I just tried), perhaps Andreas or Jakub would like to do so. (Jakub, I've added your e-mail as a CC to this bug, sorry if that isn't appropriate. -- lucier at math dot purdue dot edu changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug c/40620] ICE in dwarf2out_begin_epilogue, at dwarf2out.c:2773 [regression]
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-02 16:37 --- debug/40462? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40620
[Bug inline-asm/40621] GCC doesn't take into account ECX being modified inside inline assembler
--- Comment #1 from hunterggl at gmail dot com 2009-07-02 16:38 --- Created an attachment (id=18122) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18122action=view) Test file This a small fragment of code that causes problems -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40621
[Bug inline-asm/40621] GCC doesn't take into account ECX being modified inside inline assembler
--- Comment #2 from hunterggl at gmail dot com 2009-07-02 16:39 --- Created an attachment (id=18123) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18123action=view) Comparison of asm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40621
[Bug debug/40462] [4.5 Regression] ICE in dwarf2out_begin_epilogue, at dwarf2out.c:2773 while compiling mlib-tgt.adb
--- Comment #5 from joel at gcc dot gnu dot org 2009-07-02 16:44 --- /home/joel/test-gcc/b-gcc1-sparc/./gcc/xgcc -B/home/joel/test-gcc/b-gcc1-sparc/./gcc/ -nostdinc -B/home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/ -isystem /home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/targ-include -isystem /home/joel/test-gcc/gcc-svn/newlib/libc/include -B/home/joel/test-gcc/install/sparc-rtems4.10/bin/ -B/home/joel/test-gcc/install/sparc-rtems4.10/lib/ -isystem /home/joel/test-gcc/install/sparc-rtems4.10/include -isystem /home/joel/test-gcc/install/sparc-rtems4.10/sys-include-g -O2 -msoft-float -O2 -I/home/joel/test-gcc/gcc-svn/gcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/home/joel/test-gcc/gcc-svn/libgcc -I/home/joel/test-gcc/gcc-svn/libgcc/. -I/home/joel/test-gcc/gcc-svn/libgcc/../gcc -I/home/joel/test-gcc/gcc-svn/libgcc/../include -DHAVE_CC_TLS -o _gcov_average_profiler.o -MT _gcov_average_profiler.o -MD -MP -MF _gcov_average_profiler.dep -DL_gcov_average_profiler -c /home/joel/test-gcc/gcc-svn/libgcc/../gcc/libgcov.c /home/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind-dw2-fde.c: In function '__register_frame_info_table_bases': /home/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind-dw2-fde.c:141:1: internal compiler error: in dwarf2out_begin_epilogue, at dwarf2out.c:2773 -- joel at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|mips-sgi-irix6.5|mips-sgi-irix6.5 sparc- ||rtems4.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40462
[Bug c/40622] New: ICE in dwarf2out_begin_epilogue, at dwarf2out.c:2773 [regression]
/home/joel/test-gcc/b-gcc1-sparc/./gcc/xgcc -B/home/joel/test-gcc/b-gcc1-sparc/./gcc/ -nostdinc -B/home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/ -isystem /home/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/targ-include -isystem /home/joel/test-gcc/gcc-svn/newlib/libc/include -B/home/joel/test-gcc/install/sparc-rtems4.10/bin/ -B/home/joel/test-gcc/install/sparc-rtems4.10/lib/ -isystem /home/joel/test-gcc/install/sparc-rtems4.10/include -isystem /home/joel/test-gcc/install/sparc-rtems4.10/sys-include-g -O2 -msoft-float -O2 -I/home/joel/test-gcc/gcc-svn/gcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/home/joel/test-gcc/gcc-svn/libgcc -I/home/joel/test-gcc/gcc-svn/libgcc/. -I/home/joel/test-gcc/gcc-svn/libgcc/../gcc -I/home/joel/test-gcc/gcc-svn/libgcc/../include -DHAVE_CC_TLS -o _gcov_average_profiler.o -MT _gcov_average_profiler.o -MD -MP -MF _gcov_average_profiler.dep -DL_gcov_average_profiler -c /home/joel/test-gcc/gcc-svn/libgcc/../gcc/libgcov.c /home/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind-dw2-fde.c: In function '__register_frame_info_table_bases': /home/joel/test-gcc/gcc-svn/libgcc/../gcc/unwind-dw2-fde.c:141:1: internal compiler error: in dwarf2out_begin_epilogue, at dwarf2out.c:2773 -- Summary: ICE in dwarf2out_begin_epilogue, at dwarf2out.c:2773 [regression] Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC target triplet: sparc-rtems4.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40622
[Bug c/40622] ICE in dwarf2out_begin_epilogue, at dwarf2out.c:2773 [regression]
--- Comment #1 from joel at gcc dot gnu dot org 2009-07-02 16:44 --- *** This bug has been marked as a duplicate of 40462 *** -- joel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40622
[Bug debug/40462] [4.5 Regression] ICE in dwarf2out_begin_epilogue, at dwarf2out.c:2773 while compiling mlib-tgt.adb
--- Comment #6 from joel at gcc dot gnu dot org 2009-07-02 16:44 --- *** Bug 40622 has been marked as a duplicate of this bug. *** -- joel at gcc dot gnu dot org changed: What|Removed |Added CC||joel at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40462
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc gcc-4.2.x
--- Comment #17 from bergner at gcc dot gnu dot org 2009-07-02 16:48 --- Alan, do you have any ideas? -- bergner at gcc dot gnu dot org changed: What|Removed |Added CC||amodra at bigpond dot net ||dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug inline-asm/40621] GCC doesn't take into account ECX being modified inside inline assembler
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-02 16:51 --- For both mulscale and divscale you have ecx as an input register but nothing marks it as being modified so GCC does not know that. It does not read the template string to figure out what you had meant to say. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40621
[Bug other/40618] when flex is not installed, gcc build stop because of a non existent file
--- Comment #2 from ycollet at freesurf dot fr 2009-07-02 17:39 --- It should be relatively easy to make configure emit an error when it can't find flex. I have lost a couple of hours before figuring out that flex was missing. YC -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40618
[Bug inline-asm/40621] GCC doesn't take into account ECX being modified inside inline assembler
--- Comment #4 from hunterggl at gmail dot com 2009-07-02 17:46 --- (In reply to comment #3) For both mulscale and divscale you have ecx as an input register but nothing marks it as being modified so GCC does not know that. It does not read the template string to figure out what you had meant to say. I see. Anyway, how do I let GCC know about it? What's the best solution? Saving ECX isn't a very good solution because it isn't always necessary. And what about other registers(EAX,EDX)? Do I have to save them too? There are many such assembler definitions so I'd like to make code behavior predictable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40621
[Bug other/40623] New: variable seems to be optimised out incorrectly
I'm in doubt about exact compiler info, cause I want to report a bug from Gentoo bugzilla, where reporter was using 4.3.2, but I could reproduce it with 4.4.0. We're both on x86. It's http://bugs.gentoo.org/show_bug.cgi?id=276146. A rather simple code fragment gets miscompiled, but after making a few changes, that arithmetically are no-ops, it can be compiled correctly. -- Summary: variable seems to be optimised out incorrectly Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: galtgendo at o2 dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
[Bug other/40623] variable seems to be optimised out incorrectly
--- Comment #1 from galtgendo at o2 dot pl 2009-07-02 18:02 --- Created an attachment (id=18124) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18124action=view) a testcase for the bug As I said in the Gentoo bug, one version of the 'area' line produces correct result, other does not and while that 'printf' should arithmetically be a no-op, it's required for correct compilation. I forgot to add that at least -O is required to trigger the bug, with -O0, both versions work fine, even without 'printf'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
[Bug other/40623] variable seems to be optimised out incorrectly
--- Comment #2 from galtgendo at o2 dot pl 2009-07-02 18:05 --- Due to that 'printf' thing, it seems vaguely similar to bug 39333, however here neither of the switches mentioned there has an effect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
[Bug c/40620] ICE in dwarf2out_begin_epilogue, at dwarf2out.c:2773 [regression]
--- Comment #2 from rth at gcc dot gnu dot org 2009-07-02 18:05 --- *** This bug has been marked as a duplicate of 40462 *** -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40620
[Bug debug/40462] [4.5 Regression] ICE in dwarf2out_begin_epilogue, at dwarf2out.c:2773 while compiling mlib-tgt.adb
--- Comment #7 from rth at gcc dot gnu dot org 2009-07-02 18:05 --- *** Bug 40620 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40462
[Bug other/40623] variable seems to be optimised out incorrectly
--- Comment #3 from galtgendo at o2 dot pl 2009-07-02 18:08 --- Created an attachment (id=18125) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18125action=view) data for the test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
[Bug c/40624] New: gcc -v does not give useful --prefix on w32
This is for gcc on w32 (windows). I have downloaded the MinGW installer and installed gcc from that. When doing gcc -v the resulting prefix for me is On w32 this should include the drive letter otherwise it is totally useless. So it should be --prefix=c:/mingw I also wonder if this is the way to get the include libraries path or if there is a better way. Is another way to get it planned? The background to this bug report can be found here: http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00033.html -- Summary: gcc -v does not give useful --prefix on w32 Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lennart dot borgman at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40624
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #5 from ghazi at gcc dot gnu dot org 2009-07-02 18:14 --- Make sure to re-enable the commented out tests in gfortran.dg/integer_exponentiation_4.f90. See: http://gcc.gnu.org/ml/fortran/2009-06/msg00288.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug fortran/40008] F2008: Add NEWUNIT= for OPEN statement
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-07-02 18:15 --- Complete. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40008
[Bug c/40624] gcc -v does not give useful --prefix on w32
--- Comment #1 from lennart dot borgman at gmail dot com 2009-07-02 18:16 --- Hm, something went wrong when sending the bug report. It should have said When doing gcc -v the resulting prefix for me is --prefix=/mingw On w32 ... (the rest is correct) -- lennart dot borgman at gmail dot com changed: What|Removed |Added CC||lennart dot borgman at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40624
[Bug other/40623] variable seems to be optimised out incorrectly
--- Comment #4 from paolo dot carlini at oracle dot com 2009-07-02 18:26 --- Can't reproduce in any active branch, thus already fixed for 4.5.0, 4.4.1, 4.3.4 (maybe 4.3.3 too). -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.3.2 4.4.0 Known to work||4.3.4 4.4.1 4.5.0 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
[Bug driver/40624] gcc -v does not give useful --prefix on w32
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-02 18:27 --- Since the output of gcc -v depends on how GCC was configured, this is not a bug with GCC and really a bug with the way mingw's gcc was configured. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |driver Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40624
[Bug driver/40624] gcc -v does not give useful --prefix on w32
--- Comment #3 from lennart dot borgman at gmail dot com 2009-07-02 18:29 --- pinskia, please explain why you marked this bug as invalid! -- lennart dot borgman at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40624
[Bug driver/40624] gcc -v does not give useful --prefix on w32
--- Comment #4 from lennart dot borgman at gmail dot com 2009-07-02 18:31 --- Ah, sorry, I did not see your comment. Could you advice how the MinGW team should configure the compilation? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40624
[Bug driver/40624] gcc -v does not give useful --prefix on w32
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-07-02 18:32 --- Because the FSF does not supply the binaries you are using so it is not a bug with GCC rather than the way it was configured. when configuring with --prefix=/mingw, it have to mean C:/mingw. Also GCC binaries are relocatable so the whole idea of using it to figure out the include directory is wrong. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40624
[Bug driver/40624] gcc -v does not give useful --prefix on w32
--- Comment #6 from lennart dot borgman at gmail dot com 2009-07-02 18:34 --- Thanks, I see. How can one then figure out the include path that a user has? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40624
[Bug testsuite/40625] New: [4.5 Regression] Errors in make -k check-gcc RUNTESTFLAGS=plugin.exp
On x86_64-unknown-linux-gnu, revision 149190:
make -k check-gcc RUNTESTFLAGS=plugin.exp results in
Running gcc-4.4.0/src/gcc/testsuite/gcc.dg/plugin/plugin.exp ...
ERROR: tcl error sourcing gcc-4.4.0/src/gcc/testsuite/gcc.dg/plugin/plugin.exp.
ERROR: can't read ld_library_path: no such variable
while executing
set value $ld_library_path
(procedure set_ld_library_path_env_vars line 47)
invoked from within
set_ld_library_path_env_vars
(procedure plugin-test-execute line 32)
invoked from within
plugin-test-execute $plugin_src $plugin_input_tests
(foreach body line 13)
invoked from within
foreach plugin_test $plugin_test_list {
# Replace each source file with its full-path name
for {set i 0} {$i [llength $plugin_test]} {incr i...
(file
/usr/local/google/diagnostic_plugin_gcc-4.4.0/src/gcc/testsuite/gcc.dg/plugin/plugin.exp
line 56)
invoked from within
source
/usr/local/google/diagnostic_plugin_gcc-4.4.0/src/gcc/testsuite/gcc.dg/plugin/plugin.exp
(uplevel body line 1)
invoked from within
uplevel #0 source
/usr/local/google/diagnostic_plugin_gcc-4.4.0/src/gcc/testsuite/gcc.dg/plugin/plugin.exp
invoked from within
catch uplevel #0 source $test_file_name
Similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40601,
http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg01099.html may be the cause.
--
Summary: [4.5 Regression] Errors in make -k check-gcc
RUNTESTFLAGS=plugin.exp
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tjruwase at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40625
[Bug testsuite/40625] [4.5 Regression] Errors in make -k check-gcc RUNTESTFLAGS=plugin.exp
--- Comment #1 from tjruwase at google dot com 2009-07-02 18:48 --- Created an attachment (id=18126) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18126action=view) Proposed Patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40625
[Bug other/40623] variable seems to be optimised out incorrectly
--- Comment #5 from galtgendo at o2 dot pl 2009-07-02 20:33 --- It definitely doesn't work in 4.3.3. I'll attach generated assembly. -- galtgendo at o2 dot pl changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
[Bug other/40623] variable seems to be optimised out incorrectly
--- Comment #6 from galtgendo at o2 dot pl 2009-07-02 20:35 --- Created an attachment (id=18127) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18127action=view) this is correct assembly ...when 'printf' and '(x0*(y0+dy) - (x0+dx)*y0)' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
[Bug other/40623] variable seems to be optimised out incorrectly
--- Comment #7 from galtgendo at o2 dot pl 2009-07-02 20:37 --- Created an attachment (id=18128) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18128action=view) this is the incorrect one ...with 'printf' and 'x0*y1-x1*y0' Both with '-O2' (though -0 is enough). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
[Bug other/40623] variable seems to be optimised out incorrectly
--- Comment #8 from galtgendo at o2 dot pl 2009-07-02 20:42 --- Though perhaps I didn't need to reopen. Just making sure: could you reproduce it with one of the mentioned versions ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
[Bug other/40623] variable seems to be optimised out incorrectly
--- Comment #9 from paolo dot carlini at oracle dot com 2009-07-02 20:47 --- Yes, is not fixed in 4.3.3. Is already fixed for 4.3.4, etc. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40623
[Bug rtl-optimization/40626] New: -frename-registers causes register corruption
When compiled with -frename-registers, the TBA test case produces invalid code. Specifically, the cpadd4.h opcode clobbers $c1 but the cpsub2.h assumes it still has the value a in it. Compiling with -fno-rename-registers results in valid code. -- Summary: -frename-registers causes register corruption Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dj at redhat dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: mep-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
[Bug rtl-optimization/40626] -frename-registers causes register corruption
--- Comment #1 from dj at redhat dot com 2009-07-02 21:41 --- Created an attachment (id=18129) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18129action=view) test case for the above Compile with: ./cc1 -quiet -mivc2 dj.c -O2 -o dj.s -frename-registers -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
[Bug rtl-optimization/40626] -frename-registers causes register corruption
--- Comment #2 from dj at redhat dot com 2009-07-02 21:42 --- Created an attachment (id=18130) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18130action=view) resulting .s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
[Bug rtl-optimization/40626] -frename-registers causes register corruption
--- Comment #3 from dj at redhat dot com 2009-07-02 21:42 --- Created an attachment (id=18131) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18131action=view) dump just before rnreg -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
[Bug rtl-optimization/40626] -frename-registers causes register corruption
--- Comment #4 from dj at redhat dot com 2009-07-02 21:43 --- Created an attachment (id=18132) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18132action=view) dump just after rnreg -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
[Bug fortran/40612] internal compiler error: in gfc_add_modify, at fortran/trans.c
--- Comment #7 from rogermc at iinet dot net dot au 2009-07-02 22:58 --- Although this program compiled OK under g77 it failed under gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40612
[Bug fortran/40612] internal compiler error: in gfc_add_modify, at fortran/trans.c
--- Comment #8 from kargl at gcc dot gnu dot org 2009-07-02 23:17 --- (In reply to comment #7) Although this program compiled OK under g77 it failed under gfortran. Please attach a tarball with all the files need to reproduce the failure, or us to a URL where we can get the original code. Please try with a newer version of gfortran. Literally, hundreds of bugs and changes have occurred since version 4.3.0 was released. I believe this bug is a duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34026 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40612
[Bug c++/40614] no -Werror= for attribute warn_unused_result
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-02 23:41 --- We can add an option Wunused-result that controls the warnings. Wno-unused-result and -Werror=unused-result will then work as expected. Index: gcc/c-common.c === --- gcc/c-common.c (revision 149197) +++ gcc/c-common.c (working copy) @@ -8258,13 +8258,14 @@ c_warn_unused_result (gimple_seq seq) location_t loc = gimple_location (g); if (fdecl) - warning (0, %Hignoring return value of %qD, -declared with attribute warn_unused_result, -loc, fdecl); +warning_at (loc, OPT_Wunused_result, +ignoring return value of %qD, +declared with attribute warn_unused_result, +fdecl); else - warning (0, %Hignoring return value of function -declared with attribute warn_unused_result, -loc); + warning_at (loc, OPT_Wunused_result, +ignoring return value of function +declared with attribute warn_unused_result); } break; -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40614
