[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #9 from scovich at gmail dot com 2009-05-13 07:55 --- RE: __builtin_expect -- Thanks! It did help quite a bit, even though the compiler was already emitting not-taken branch hints on its own. RE: Filing bugs -- I have. This RFE arose out of Bug #40078, which was triggered by attempts to work around Bug #40067. I still have some issues with overconservative use of branch delay slots and possibly loop pipelining, but haven't gotten to filing them yet. I've also filed other bugs in the past where it would have been nice to work around using inline asm but control flow was a pain. In the end, is there any particular reason *not* to make inline asm easier to use and more transparent to the compiler, given points #1 and #2? Invoking point #3, what significant uses of computed gotos exist, other than to work around switch statements that compile suboptimally? The docs don't mention any, and yet we have them instead of (or in addition to) bug reports. I'd take a stab at implementing this myself -- it's probably a one-liner -- but I've never hacked gcc before and have no clue where that one line might lurk. BTW, how does one exploit the compiler's overflow catching? I tried testing a+b a and a+b b (for unsigned ints) with no luck, and there's no __builtin test for overflow or carry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
--- Comment #6 from dannysmith at users dot sourceforge dot net 2009-05-13 08:12 --- (In reply to comment #5) Also, I don't think this is necessarily an either-or situation; we could add my patch and have the typeinfo exported from the DLL, and also add yours so that clients could link a comdat copy (which would override the import stub) until we have a better solution for importing from the DLL. Yes. I was just thinking out loud. I have no objection to your patch. Perhaps MULTIPLE_SYMBOL_SPACES should be defined in terms of an -mmultiple-symbol-spaces target option , since if we depend on auto-import than we should treat dll imports thae same as static lib imports. Also, how come emitting the typeinfo .linkonce as we currently do isn't the same as COMDAT for these purposes? I'm not sure I understand your question. In earlier versions of G++, both vtables and typeinfo were always emitted with linkonce semantics, because of the MULTIPLE_SYMBOL_SPACES define. Regards Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #10 from jakub at gcc dot gnu dot org 2009-05-13 08:19 --- Of course there is a very important reason. If you allow inline asms to change control flow, even just to labels whose address has been taken through label, you penalize a lot of code which doesn't change the control flow, as the compiler will have to assume each inline asm which could possibly get at an label address (not just directly, but through global variables, pointers etc.) can jump to it. That's an awful lot of extra flow graph edges and optimization limitations. Unless you'd invent some new syntax to say if an inline asm can change control flow and by default assume it can't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #18 from jakub at gcc dot gnu dot org 2009-05-13 08:30 --- No, .p2align is the right thing to do, given that GCC doesn't have 100% accurate information about instruction sizes (for e.g. inline asms it can't have, for stuff where branch shortening can decrease the size doesn't have it until the shortening branch phase which is too late for this machine reorg, and in other cases the lengths are just upper bounds). Say .p2align 16,,5 says insert a nop up to 5 bytes if you can reach the 16-byte boundary with it, otherwise don't insert anything. But that necessarily means that there were less than 11 bytes in the same 16 byte page and if the lower bound insn size estimation determined that in 11 bytes you can't have 3 branch changing instructions, you are fine. Breaking of fused compare and jump (32-bit code only) is unfortunate, but inserting it before the cmp would mean often unnecessarily large padding. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug fortran/39624] short-list explicit interfaces in generic interfaces if no match is found
-- fxcoudert 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-05-13 08:56:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39624
[Bug libfortran/33905] show_backtrace hangs on SIGSEGV in malloc/free
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-05-13 09:03 --- Frankly, this is a snag in a non-default debugging feature in rare conditions; that has to be a third-order enhancement request, at least! :) We cannot provide completely foolproof debugging capablities anyway: people who want to have the full power of debugging will be able to use gdb themselves. (Even with a temporary file, other things can go wrong!) I'd be in favour of closing this as WONTFIX, unless we have serious indication that this actually happens often in non mixed-language cases. Toon, what's your take? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33905
[Bug c/40128] New: [ARM] Incorrect optimized code = -O2
This code:
# 1 fs.c
# 1 built-in
# 1 command line
# 1 fs.c
int foo(unsigned int bar)
{
unsigned int mask = bar 0x8001;
if (mask 0x8000)
mask = 0x8000;
return mask;
}
produces incorrect assembly code with -Os or -O2:
.file fs.c
.text
.align 2
.global foo
.type foo, %function
foo:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cmp r0, #0
andge r0, r0, #-2147483648 == should be -2147483647
movlt r0, #-2147483648
@ lr needed for prologue
bx lr
.size foo, .-foo
.ident GCC: (GNU) 4.1.2
*** Command line: arm-v4t-linux-gnueabi -save-temps -O2 fs.c
*** Output:
Using built-in specs.
Target: arm-v4t-linux-gnueabi
Configured with:
/home/alarsen/projects/toolchain/OSELAS.Toolchain-1.1.1/build-cross/gcc-4.1.2/configure
--host=i686-host-linux-gnu --target=arm-v4t-linux-gnueabi
--prefix=/opt/OSELAS.Toolchain-1.1.1/arm-v4t-linux-gnueabi/gcc-4.1.2-glibc-2.5-kernel-2.6.18
--with-sysroot=/opt/OSELAS.Toolchain-1.1.1/arm-v4t-linux-gnueabi/gcc-4.1.2-glibc-2.5-kernel-2.6.18/sysroot-arm-v4t-linux-gnueabi
--with-arch=armv4t --with-float=soft --with-fpu=vfp --disable-nls
--disable-multilib --enable-symvers=gnu --enable-__cxa_atexit --enable-shared
--enable-threads=posix --enable-languages=c,c++ --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.1.2
/opt/OSELAS.Toolchain-1.1.1/arm-v4t-linux-gnueabi/gcc-4.1.2-glibc-2.5-kernel-2.6.18/libexec/gcc/arm-v4t-linux-gnueabi/4.1.2/cc1
-E -quiet -v fs.c -march=armv4t -mfloat-abi=soft -mfpu=vfp -O2 -fpch-preprocess
-o fs.i
ignoring nonexistent directory
/opt/OSELAS.Toolchain-1.1.1/arm-v4t-linux-gnueabi/gcc-4.1.2-glibc-2.5-kernel-2.6.18/sysroot-arm-v4t-linux-gnueabi/usr/local/include
#include ... search starts here:
#include ... search starts here:
/opt/OSELAS.Toolchain-1.1.1/arm-v4t-linux-gnueabi/gcc-4.1.2-glibc-2.5-kernel-2.6.18/lib/gcc/arm-v4t-linux-gnueabi/4.1.2/include
/opt/OSELAS.Toolchain-1.1.1/arm-v4t-linux-gnueabi/gcc-4.1.2-glibc-2.5-kernel-2.6.18/lib/gcc/arm-v4t-linux-gnueabi/4.1.2/../../../../arm-v4t-linux-gnueabi/include
/opt/OSELAS.Toolchain-1.1.1/arm-v4t-linux-gnueabi/gcc-4.1.2-glibc-2.5-kernel-2.6.18/sysroot-arm-v4t-linux-gnueabi/usr/include
End of search list.
/opt/OSELAS.Toolchain-1.1.1/arm-v4t-linux-gnueabi/gcc-4.1.2-glibc-2.5-kernel-2.6.18/libexec/gcc/arm-v4t-linux-gnueabi/4.1.2/cc1
-fpreprocessed fs.i -quiet -dumpbase fs.c -march=armv4t -mfloat-abi=soft
-mfpu=vfp -auxbase fs -O2 -version -o fs.s
GNU C version 4.1.2 (arm-v4t-linux-gnueabi)
compiled by GNU C version 4.2.4 (Ubuntu 4.2.4-1ubuntu3).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2befb21690236570f62e4f3b11d6068c
--
Summary: [ARM] Incorrect optimized code = -O2
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: al at alarsen dot net
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-v4t-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40128
[Bug c/40129] New: M16C invalid shift count used by pack_d - ashldi3
some disasm listings to show what is going wrong.. i cant find the guilty source files:-( 000fa8b2 ___pack_d: snip fadb7: 75 42 push.w:g r2//pushing 64 bit exponent [63:48] fadb9: 75 42 push.w:g r2//pushing 64 bit exponent [47:32] fadbb: 75 42 push.w:g r2//pushing 64 bit exponent [31:16] fadbd: 75 40 push.w:g r0//pushing 64 bit exponent [15:0] fadbf: 75 c2 34 00 mov.w:g #52,r2 //shift count to get exponent in [62:52] fadc3: fd 83 6f 0f jsr.a f6f83 ___ashldi3 ___ashldi3 detects that it needs to shift more then 32 bits and prepares to shift by -(32-52) = 20 bits (and after that 'shift' by 32 by moving registers around) 000f6f83 ___ashldi3: snip f7055: 73 b2 07mov.w:g 7[fb],r2 //src bit[15:0] f7058: 73 b0 05mov.w:g 5[fb],r0 //src bit[31:16] f705b: 72 b2 e2mov.b:g -30[fb],r1l //shift count (20) f705e: 72 23 mov.b:g r1l,r1h //shift count (20) f7060: eb 21 sha.l r1h,r2r0 //the shift The M16C/60, M16C/20, M16C/Tine Series Software Manual says: If src is a register and you selected (.W) or (.L) for the size specifier (.size), the number of shifts is 16 to +16. Although you can set 0, no bits are shifted and no flags are changed. If you set a value less than 16 or greater than +16, the result of shift is indeterminate. the actual result on my hardware is a shift by 4 (20 0xf). i think ___ashldi3 (and friends!) should (also) check if the shift is 16 and only do the shift % 16 with the shift instruction and do the rest of the shift by moving registers. -- Summary: M16C invalid shift count used by pack_d - ashldi3 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eightdot at hotmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: m32c-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40129
[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #11 from scovich at gmail dot com 2009-05-13 09:51 --- If you allow inline asms to change control flow, even just to labels whose address has been taken through label, you penalize a lot of code which doesn't change the control flow, as the compiler will have to assume each inline asm which could possibly get at an label address (not just directly, but through global variables, pointers etc.) can jump to it. I'm going to invoke #3 again to respond to these concerns: a. This RFE is specifically limited to local control flow only, so the compiler can safely ignore any label not in the asm's enclosing function, as well as labels whose addresses are never taken (or provably never used). Computed gotos appear to make the same assumptions, based on the docs' strong warning not allow labels to leak out of their enclosing function in any way. b. While it's always possible that an asm could jump to a value loaded from an arbitrary, dynamically-generated address, the same is true for computed gotos. Either way, compiler analysis or not, doing so would almost certainly send you to la-la land because label values aren't known until assembler time or later and have no guaranteed relationship with each other. The only way to get a valid label address is using one directly, or computing it with some sort of base+(label-base). Either way requires taking the address of the desired label at some point and tipping off the compiler. c. It's pretty easy to write functions whose computed gotos defy static analysis, but most of the time the compiler does pretty well. Well-written asm blocks should access memory via m constraints -- which the compiler can analyze -- rather than manually dereferencing a pointer passed in with an r constraint. This is especially true for asm blocks with no internal control flow, which this RFE encourages. d. If a code path is short/simple enough that incoming jumps penalize it heavily (whether from computed gotos or jumps from asm), it's probably also small enough that the compiler (or programmer, if need be) can duplicate it for the short path. A big, ugly code path probably wouldn't even notice an extra control flow arc or two. In the end, a big goal of this RFE is to allow programmers to make the compiler aware of control flow arcs they're already adding (or tempted to add) behind its back. It therefore wouldn't strike me as much of a limitation if jumps to labels not explicitly passed to the asm are unsupported and may lead to undefined behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40124
[Bug c/40128] [ARM] Incorrect optimized code = -O2
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-13 09:52 --- Can you try a newer version of the compiler ? 4.1.x is unsupported today. I can see this is fixed on trunk and 4.3 as of revisions 147467 147441. An older version of 4.4 does not show this problem. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40128
[Bug debug/40126] [4.5 Regression] -O2 -g results in: can't resolve `.LFE95' {*UND* section} - `.Ltext0' {.text section}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
Summary|[4.5 regression] -O2 -g |[4.5 Regression] -O2 -g
|results in: can't resolve |results in: can't resolve
|`.LFE95' {*UND* section} - |`.LFE95' {*UND* section} -
|`.Ltext0' {.text section} |`.Ltext0' {.text section}
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40126
[Bug inline-asm/40124] Inline asm should support limited control flow
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-05-13 09:58 --- I strongly oppose to making asm handling even more complex. -- 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=40124
[Bug target/37179] gcc emits bad opcode 'ffreep'
--- Comment #16 from uros at gcc dot gnu dot org 2009-05-13 10:06 --- Subject: Bug 37179 Author: uros Date: Wed May 13 10:05:48 2009 New Revision: 147469 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147469 Log: PR target/37179 * config/i386/driver-i386.c (processor_signatures): New enum. (SIG_GEODE): Move from vendor_signatures to processor_signatures. (host_detect_local_cpu): For SIG_AMD vendor, check for SIG_GEODE processor signature to detect geode processor. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/driver-i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37179
[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 10:08 --- I can see this with trunk at r147467 -- 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-05-13 10:08:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246
[Bug tree-optimization/39251] FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 = .* \+ -
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-13 10:10 --- Appears on trunk as of r147467. -- 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-05-13 10:10:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39251
[Bug target/37987] iwmmxt: insn does not satisfy its constraints on (int64_t)
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 10:14 --- Can you check this with a later compiler. 4.2.x is closed. Works for me with current trunk. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37987
[Bug ada/37109] can't canadian cross ada (if host=target, but host!=build)
--- Comment #2 from christian dot joensson at gmail dot com 2009-05-13 10:24 --- what is the current situation concerning gnatlib? is that passed explicitly from stage to stage? -- christian dot joensson at gmail dot com changed: What|Removed |Added CC||christian dot joensson at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37109
[Bug ada/37109] can't canadian cross ada (if host=target, but host!=build)
--- Comment #3 from christian dot joensson at gmail dot com 2009-05-13 10:25 --- sorry, I meant gnatbind instead of gnatlib... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37109
[Bug target/34341] GCC generates incorrect code on ARM in certain case, resulting in stack corruption
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-13 10:52 ---
I see a problem with your testcase here. r is assigned to h which has not been
initialized if I uncomment the line //r=h as per your comment above.
int test_func(void *p) {
dummy_func();
register int r;
register void *h;
if (p == 0) {
return 0;
}
//r = (int)h;
return r;
}
I'm not sure what the bug is here because the testcase doesn't seem reasonable.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34341
[Bug c/40128] [ARM] Incorrect optimized code = -O2
--- Comment #2 from al at alarsen dot net 2009-05-13 11:20 --- Created an attachment (id=17856) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17856action=view) preprocessed intermediate -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40128
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #19 from vvv at ru dot ru 2009-05-13 11:42 --- (In reply to comment #18) No, .p2align is the right thing to do, given that GCC doesn't have 100% accurate information about instruction sizes (for e.g. inline asms it can't have, for stuff where branch shortening can decrease the size doesn't have it until the shortening branch phase which is too late for this machine reorg, and in other cases the lengths are just upper bounds). Say .p2align 16,,5 says insert a nop up to 5 bytes if you can reach the 16-byte boundary with it, otherwise don't insert anything. But that necessarily means that there were less than 11 bytes in the same 16 byte page and if the lower bound insn size estimation determined that in 11 bytes you can't have 3 branch changing instructions, you are fine. Breaking of fused compare and jump (32-bit code only) is unfortunate, but inserting it before the cmp would mean often unnecessarily large padding. You are rigth, if padding required for every 16-byte page with 4 branches on it. But Intel writes about 16-byte chunk, not 16-byte page. Quote from Intel 64 and IA-32 Architectures Optimization Reference Manual: Assembly/Compiler Coding Rule 10. (M impact, L generality) Do not put more than four branches in a 16-byte chunk. IMHO, here chunk - memory range from x to x+10h, where x - _any_ address. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug target/37386] Interrupt service routine for arm target corrupts program counter
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 12:31 ---
This appears to be fixed with trunk as of r147467. Can you reproduce this with
4.3 or 4.4 ? If not we can close this one out.
_Z18serial_IRQ_Routinev:
@ Interrupt Service Routine.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
stmfd sp!, {r0, r1, r2, r3, r4, ip}
mov r2, #0
ldr r3, .L9
ldr r0, .L9+4
mov r1, r2
.L6:
ldr r4, [r3, #36]
ldr ip, [r3, #40]
cmp r4, ip
bne .L2
ldr ip, [r3, #32]
cmp ip, #0
beq .L1
.L2:
ldr ip, [r3, #32]
sub ip, ip, #1
str ip, [r3, #32]
ldr ip, [r3, #40]
ldr r4, [r3, #40]
add r4, r4, #1
str r4, [r3, #40]
ldr r4, [r3, #40]
ldrbip, [r3, ip]@ zero_extendqisi2
cmp r4, #32
add r2, r2, #1
streq r1, [r3, #40]
cmp r2, #16
strbip, [r0, #0]
bne .L6
.L1:
ldmfd sp!, {r0, r1, r2, r3, r4, ip}
subspc, lr, #4
.L10:
.align 2
.L9:
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37386
[Bug target/36966] arm iwmmxt builtin problem
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 12:34 --- Appears with today's trunk (r147467) with the following options. /home/ramrad01/fsfbugzilla/pr36966.c: In function 'foo': /home/ramrad01/fsfbugzilla/pr36966.c:5: internal compiler error: in arm_expand_binop_builtin, at config/arm/arm.c:16182 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- 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-05-13 12:34:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36966
[Bug target/36798] internal compiler error: in arm_expand_binop_builtin, at config/arm/arm.c:12548
--- Comment #7 from ramana at gcc dot gnu dot org 2009-05-13 12:45 --- I get an ICE with trunk as of r146467 using -flax-vector-conversions otherwise the test doesn't compile. -- 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-05-13 12:45:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36798
[Bug bootstrap/40027] [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2009-05-13 13:02 --- Subject: Re: [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld jakub at gcc dot gnu dot org writes: Look for DEEP_BRANCH_PREDICTION in config/i386/*. On i386/i486/i586 doing call 1f; 1: is just fine, but on several newer CPUs it confuses return prediction logic (more calls than rets), so when optimizing for those CPUs gcc calls a separate pad which just reads the return address from the stack and immediately returns. This pad can be shared among all functions within the same binary or shared Ok, thanks for the explanation. library. If hidden linkonce doesn't work on some Solaris version, you should just make sure USE_HIDDEN_LINKONCE is 0 for that target. Indeed: that far easier than determining which version of Sun ld has all the necessary support. Proposed patch here: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00723.html Thanks. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40027
[Bug c/37384] Assembler error message when building vlc-0.9.1
--- Comment #6 from michael dot haubenwallner at salomon dot at 2009-05-13 13:08 --- As this seems to be a bug in glibc headers: Would it be feasible to add an include-fix for this, to be able to use gcc-4.3 with older glibc? -- michael dot haubenwallner at salomon dot at changed: What|Removed |Added CC||michael dot haubenwallner at ||salomon dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37384
[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution
--- Comment #12 from hp at gcc dot gnu dot org 2009-05-13 13:09 --- The relax_delay_slots (first) call finds that there's a branch to a redundant insn that it can eliminate. It does this by redirecting the branch to a new or existing label and deleting the insn, or rather move it and make it a USE-mark at the new label. When doing this, the old USE-mark quoted above (not related to the new USE-mark by other means being before it in the execution path) is now deemed unreachable and removed by jump.c:delete_related_insns. So, it seems a solution will include propagating existing USE-marks when redirecting branch labels, perhaps in reorg_redirect_jump or update_block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-05-13 13:31 --- Instruction decoders generally operate on whole cache-lines, so 16-byte chunk very very likely refers to a cache-line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug tree-optimization/39251] FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 = .* \+ -
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-13 13:35 --- trunk or 4.4? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39251
[Bug c/40128] [ARM] Incorrect optimized code = -O2
--- Comment #3 from al at alarsen dot net 2009-05-13 13:37 --- (In reply to comment #1) Can you try a newer version of the compiler ? 4.1.x is unsupported today. I can see this is fixed on trunk and 4.3 as of revisions 147467 147441. An older version of 4.4 does not show this problem. Thanks - I can confirm that 4.2.4 does not show the problem either. -- al at alarsen dot net changed: What|Removed |Added Known to fail||4.1.2 Known to work||4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40128
[Bug fortran/39782] [4.3/4.4 Regression] IO depends on uninitialised value
--- Comment #10 from burnus at gcc dot gnu dot org 2009-05-13 13:47 ---
For 4.4 the equivalent diff should be the following (untested). I don't see ad
hoc whether the sfree can be removed as well or not.
Index: libgfortran/io/transfer.c
===
--- libgfortran/io/transfer.c (revision 147470)
+++ libgfortran/io/transfer.c (working copy)
@@ -2148,7 +2148,6 @@ data_transfer_init (st_parameter_dt *dtp
if (dtp-pos != dtp-u.p.current_unit-strm_pos)
{
fbuf_flush (dtp-u.p.current_unit, 1);
- flush (dtp-u.p.current_unit-s);
if (sseek (dtp-u.p.current_unit-s, dtp-pos - 1) == FAILURE)
{
generate_error (dtp-common, LIBERROR_OS, NULL);
@@ -2951,10 +2950,7 @@ finalize_transfer (st_parameter_dt *dtp)
if (dtp-u.p.current_unit-flags.form == FORM_UNFORMATTED
file_position (dtp-u.p.current_unit-s) = dtp-rec)
- {
- flush (dtp-u.p.current_unit-s);
- sfree (dtp-u.p.current_unit-s);
- }
+ sfree (dtp-u.p.current_unit-s);
return;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
[Bug target/40130] New: rint from gcc.c-torture/execute miscompiled with -march=i486
I see these failures when running the testsuite at -march=i486 (note: execute/ieee means that -mieee-fp is also added to the command line) FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution, -O1 FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution, -O2 FAIL: gcc.c-torture/execute/ieee/20010114-2.c execution, -Os FAIL: gcc.c-torture/execute/ieee/20030331-1.c execution, -O1 FAIL: gcc.c-torture/execute/ieee/20030331-1.c execution, -O2 FAIL: gcc.c-torture/execute/ieee/20030331-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/ieee/20030331-1.c execution, -O3 -g FAIL: gcc.c-torture/execute/ieee/20030331-1.c execution, -Os -- Summary: rint from gcc.c-torture/execute miscompiled with - march=i486 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonzini at gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40130
[Bug target/40105] SH: 4.3/4.4 compilers segfault when recompiling itself on gentoo system
--- Comment #4 from kkojima at gcc dot gnu dot org 2009-05-13 14:07 --- Created an attachment (id=17857) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17857action=view) a test case I've got a small test case from libiberty/concat.c. With -O1, 4.3 compiles vconcat_length to the codes below: ... .L5: jsr @r12! Call strlen nop add r0,r9 mov.l @r8,r4 mov r4,r2 add #4,r2 mov.l @(4,r8),r1 cmp/hs r2,r1 bt/s.L4 mov r8,r2 mov.l @(16,r8),r4 mov r13,r2 .L4: mov r4,r1 add #4,r1 mov.l r1,@r2 mov.l @r4,r4 tst r4,r4 bf/s.L5 mov r9,r4 !!! mov.l .L17,r0 jsr @r0 ! Call malloc. ... i.e. the delayed branch optimization fills a delay slot with an inappropriate instruction at the line !!!. I've confirmed that the 4.4 compiler's output is similar and the outputs for 4.2 and 4.5 look correct even with -O. I have no idea for what is going on ATM, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40105
[Bug tree-optimization/33404] Predictive commoning + ivopts possibly introducing extra sign extensions.
--- Comment #5 from ramana at gcc dot gnu dot org 2009-05-13 14:33 --- (In reply to comment #4) (In reply to comment #3) (In reply to comment #2) Also IV-opts is messing up anyways, it should have done out+1 as the base instead of out, blah. Filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36905 . Can we close this bug, then, or is there some other problem reported in this testcase? As far as I can tell, predictive commoning does not introduce any new sign extensions (it does not eliminate any, either, but that is not its job). I am closing this because the problem is not in predictive commoning which is doing the right thing and the problem is as per PR36905. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33404
[Bug target/39244] Various cleanup tests fail
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 14:39 --- I don't see these failing with trunk as of 147209 or on an arm-none-linux-gnueabi 4.4.x on the testresults mailing list. Do these still fail for your tester? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39244
[Bug c++/40131] New: [C++0x] uniform init with std::string causes internal compiler segfault
Produce this bug by the following:
std::string foo {bar};
--
Summary: [C++0x] uniform init with std::string causes internal
compiler segfault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mobileforces at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40131
[Bug c/37384] Assembler error message when building vlc-0.9.1
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-05-13 14:48 --- (In reply to comment #6) As this seems to be a bug in glibc headers: Would it be feasible to add an include-fix for this, to be able to use gcc-4.3 with older glibc? It should have already been. As libgfortran uses those headers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37384
[Bug target/38703] testsuite __gnu_mcount_nc link error when profiling on arm
--- Comment #5 from ramana at gcc dot gnu dot org 2009-05-13 14:51 --- (In reply to comment #1) That's what dg-require-profiling does. IMHO this is a deficiency in your glibc. It's very hard to distinguish between something is subtly busted and my glibc sucks, so I'm not sure fixing this is appropriate for fsf gcc. Given this bit here, can this now be closed as WONTFIX ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38703
[Bug fortran/34153] Debugging: Cannot set breakpoint in comment lines or END PROGRAM
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-13 14:53 --- Subject: Bug 34153 Author: burnus Date: Wed May 13 14:52:54 2009 New Revision: 147477 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147477 Log: 2009-05-13 Tobias Burnus bur...@net-b.de PR fortran/34153 * gfortran.h (gfc_exec_op): Add EXEC_END_PROCEDURE. * dump-parse-tree.c (show_code_node): Use EXEC_END_PROCEDURE. * trans.c (gfc_trans_code): Ditto. * resolve.c (resolve_code): Ditto. * st.c (gfc_free_statement): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/st.c trunk/gcc/fortran/trans.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34153
[Bug debug/40109] Incorrect debug info nesting for typedef statements within namespaces
--- Comment #2 from dodji at gcc dot gnu dot org 2009-05-13 14:58 --- Patch submitted for review at http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00706.html. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Summary| Incorrect debug info |Incorrect debug info nesting |nesting for typedef |for typedef statements |statements within namespaces|within namespaces http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40109
[Bug tree-optimization/39251] FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 = .* \+ -
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2009-05-13 15:20 --- Subject: Re: FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not forwprop1 = .* \+ - trunk or 4.4? I see it in trunk revision 147374. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39251
[Bug c/37384] Assembler error message when building vlc-0.9.1
--- Comment #8 from michael dot haubenwallner at salomon dot at 2009-05-13 15:21 --- (In reply to comment #7) (In reply to comment #6) Would it be feasible to add an include-fix for this It should have already been. As libgfortran uses those headers. Hmm, cannot find anything related in inclhack.def on either gcc-4_3-branch, gcc-4_4-branch or trunk. What did I miss here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37384
[Bug fortran/34153] Debugging: Cannot set breakpoint in comment lines or END PROGRAM
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-13 16:14 --- FIXED on the trunk (4.5). Thanks for the bug report! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34153
[Bug debug/40126] [4.5 Regression] -O2 -g results in: can't resolve `.LFE95' {*UND* section} - `.Ltext0' {.text section}
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-13 16:32 --- It is caused by revision 14734: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00316.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40126
[Bug target/40130] rint from gcc.c-torture/execute miscompiled with -march=i486
--- Comment #2 from ubizjak at gmail dot com 2009-05-13 16:34 --- Adding -ffloat-store also fixes these failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40130
[Bug target/35623] RTL check failure in arm_const_double_rtx
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-13 16:34 --- Can you try a later compiler ? -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35623
[Bug rtl-optimization/39836] [4.4/4.5 regression] unoptimal code generated
-- 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-05-13 16:47:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39836
[Bug target/40130] rint from gcc.c-torture/execute miscompiled with -march=i486
--- Comment #3 from joseph at codesourcery dot com 2009-05-13 16:50 --- Subject: Re: rint from gcc.c-torture/execute miscompiled with -march=i486 On Wed, 13 May 2009, ubizjak at gmail dot com wrote: Adding -ffloat-store also fixes these failures. ieee.exp already uses -ffloat-store on x86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40130
[Bug regression/40132] New: failure to assign asm constraints properly
# gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.4.0/configure --prefix=/usr/local/dist --program-prefix=dist- --without-doc --enable-bootstrap Thread model: posix gcc version 4.4.0 (GCC) I just compiled to gcc 4.4.0 (replacing my 4.2.2 version) and found that the function_graph tracer in linux broke. Investigating it further, I found that gcc did not properly assign the constraints used in arch/x86/kernel/ftrace.c (Linux 2.6.30-rc5). Maybe the constraints are not assigned properly, but it worked in all my previous versions of gcc, and I do not see anything wrong with it. Here's the code (prepare_ftrace_return): unsigned long return_hooker = (unsigned long) return_to_handler; [...] /* * Protect against fault, even if it shouldn't * happen. This tool is too much intrusive to * ignore such a protection. */ asm volatile( 1: _ASM_MOV (%[parent]), %[old]\n 2: _ASM_MOV %[return_hooker], (%[parent])\n movl $0, %[faulted]\n 3:\n .section .fixup, \ax\\n 4: movl $1, %[faulted]\n jmp 3b\n .previous\n _ASM_EXTABLE(1b, 4b) _ASM_EXTABLE(2b, 4b) : [old] =r (old), [faulted] =r (faulted) : [parent] r (parent), [return_hooker] r (return_hooker) : memory ); Here's what gcc 4.2.2 does (working): 80228893: 48 c7 c0 3d be 20 80mov$0x8020be3d,%rax 8022889a: 4c 8b 27mov(%rdi),%r12 8022889d: 48 89 07mov%rax,(%rdi) 802288a0: b8 00 00 00 00 mov$0x0,%eax 802288a5: 85 c0 test %eax,%eax The return_hooker is put into %rax, old is %r12 and all is fine. But gcc 4.4.0 decided to use %r12 for both the return_hooker and old! 80229503: 49 c7 c4 7d bf 20 80mov$0x8020bf7d,%r12 8022950a: 4c 8b 27mov(%rdi),%r12 8022950d: 4c 89 27mov%r12,(%rdi) 80229510: b8 00 00 00 00 mov$0x0,%eax 80229515: 85 c0 test %eax,%eax Thus overwriting the return_hooker variable before it is used as an input! Is there something wrong with the constraints, or is this indeed a bug in GCC? -- Summary: failure to assign asm constraints properly Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rostedt at goodmis dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40132
[Bug libstdc++/40133] New: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa}-linux
Tracking http://gcc.gnu.org/ml/gcc/2009-05/msg00035.html as a bug report.
Paolo checked in a patch in rev 147123 on the gcc-4_4-branch to do link tests
for the atomic builtins, which works ok on hppa, but fails for arm.
--
Summary: exception propagation support not enabled in libstdc++
4.4 on {armeabi,hppa}-linux
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: arm-linux-gnueabi hppa-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40133
[Bug target/40134] New: symbols not resolved when building shared libraries (link with -lgcc_s -lgcc?)
this showed up when trying to address PR40133. Enabling the exception propagation support keeps the __sync_val_compare_and_swap_4 unresolved. /usr/bin/ld: ./atomic-1.exe: hidden symbol `__sync_val_compare_and_swap_4' in /home/doko/gcc/4.4/gcc-4.4-4.4.0/build/gcc/libgcc.a(linux-atomic.o) is referenced by DSO /usr/bin/ld: final link failed: Nonrepresentable section on output Linking the shared libstdc++ with both -lgcc_s and -lgcc does fix these. There seem to be two issues: - libtool currently doesn't allow to link with -lgcc_s -lgcc (in this order). see http://gcc.gnu.org/ml/libstdc++/2009-05/msg00064.html - g++ should link be default with -lgcc_s -lgcc? this is how I understand http://gcc.gnu.org/ml/gcc/2009-05/msg00039.html -- Summary: symbols not resolved when building shared libraries (link with -lgcc_s -lgcc?) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC target triplet: arm-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40134
[Bug libstdc++/40133] exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa}-linux
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-05-13 17:07 --- the arm failure is PR40134 now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40133
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #21 from vvv at ru dot ru 2009-05-13 17:13 --- I guess! Your patch is absolutely correct for AMD AthlonTM 64 and AMD OpteronTM processors, but it is nonoptimal for Intel processors. Because: 1. AMD limitation for 16-bytes page (memory range XXX0 - XXXF), but Intel limitation for 16-bytes chunk (memory range - +10h) 2. AMD - maximum of _THREE_ near branches (CALL, JMP, conditional branches, or returns), Intel - maximum of _FOUR_ branches! Quotation from Software Optimization Guide for AMD64 Processors 6.1 Density of Branches When possible, align branches such that they do not cross a 16-byte boundary. The AMD AthlonTM 64 and AMD OpteronTM processors have the capability to cache branch-prediction history for a maximum of three near branches (CALL, JMP, conditional branches, or returns) per 16-byte fetch window. A branch instruction that crosses a 16-byte boundary is counted in the second 16-byte window. Due to architectural restrictions, a branch that is split across a 16-byte boundary cannot dispatch with any other instructions when it is predicted taken. Perform this alignment by rearranging code; it is not beneficial to align branches using padding sequences. The following branches are limited to three per 16-byte window: jcc rel8 jcc rel32 jmp rel8 jmp rel32 jmp reg jmp WORD PTR jmp DWORD PTR call rel16 call r/m16 call rel32 call r/m32 Coding more than three branches in the same 16-byte code window may lead to conflicts in the branch target buffer. To avoid conflicts in the branch target buffer, space out branches such that three or fewer exist in a given 16-byte code window. For absolute optimal performance, try to limit branches to one per 16-byte code window. Avoid code sequences like the following: ALIGN 16 label3: call label1 ; 1st branch in 16-byte code window jc label3 ; 2nd branch in 16-byte code window call label2 ; 3rd branch in 16-byte code window jnzlabel4 ; 4th branch in 16-byte code window ; Cannot be predicted. If there is a jump table that contains many frequently executed branches, pad the table entries to 8 bytes each to assure that there are never more than three branches per 16-byte block of code. Only branches that have been taken at least once are entered into the dynamic branch prediction, and therefore only those branches count toward the three-branch limit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug fortran/40039] Procedures as actual arguments: Check intent of arguments
--- Comment #3 from janus at gcc dot gnu dot org 2009-05-13 17:15 --- FAIL: gfortran.dg/interface_19.f90 -O0 (test for excess errors) FAIL: gfortran.dg/proc_ptr_result_1.f90 -O0 (test for excess errors) The last of these three test cases is probably invalid, the second failure seems to be a problem with intrinsics, and about the first one I'm not sure. For intrinsics, the intent of the arguments is currently not considered at all. We need gfc_intrinsic_arg to have an 'intent' member. The F03 standard says: The dummy arguments of the specific intrinsic procedures in 13.6 have INTENT(IN). The dummy arguments of the generic intrinsic procedures in 13.7 have INTENT(IN) if the intent is not stated explicitly. The test case proc_ptr_result_1.f90 is invalid indeed. Relevant quote from the standard: Section 5.1.2.7: INTENT (INOUT) is not equivalent to omitting the INTENT attribute. The argument corresponding to an INTENT (INOUT) dummy argument always shall be definable, while an argument corresponding to a dummy argument without an INTENT attribute need be definable only if the dummy argument is actually redefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40039
[Bug regression/40132] failure to assign asm constraints properly
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-13 17:17 --- What GCC is doing is correct according to the source you gave it. The source needs to be modified to mark old as being an early clobber. Like: asm volatile( 1: _ASM_MOV (%[parent]), %[old]\n 2: _ASM_MOV %[return_hooker], (%[parent])\n movl $0, %[faulted]\n 3:\n .section .fixup, \ax\\n 4: movl $1, %[faulted]\n jmp 3b\n .previous\n _ASM_EXTABLE(1b, 4b) _ASM_EXTABLE(2b, 4b) : [old] =r (old), [faulted] =r (faulted) : [parent] r (parent), [return_hooker] r (return_hooker) : memory ); -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40132
[Bug middle-end/40095] [4.5 Regression] Revision 147342/147343 caused extra failures
--- Comment #4 from matz at gcc dot gnu dot org 2009-05-13 17:51 --- flatten-2.c is the more important one. We leave the static function doubleindirect1 in there, which we shouldn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40095
[Bug target/40130] rint from gcc.c-torture/execute miscompiled with -march=i486
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-13 17:57 --- So -- invalid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40130
[Bug target/40130] rint from gcc.c-torture/execute miscompiled with -march=i486
--- Comment #5 from ubizjak at gmail dot com 2009-05-13 18:16 --- (In reply to comment #4) So -- invalid? There was a reason Paolo reported this problem, so let him have the last word. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40130
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #14 from matz at gcc dot gnu dot org 2009-05-13 18:16 --- http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00753.html should fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #22 from ubizjak at gmail dot com 2009-05-13 18:22 --- (In reply to comment #21) I guess! Your patch is absolutely correct for AMD AthlonTM 64 and AMD OpteronTM processors, but it is nonoptimal for Intel processors. Because: ... CCing H.J for Intel optimization issues. -- ubizjak at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-05-13 18:34 --- Note that we need something that works for the generic model as well, which in this case looks like it is the same as for AMD models. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug libstdc++/40133] exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa}-linux
--- Comment #2 from paolo dot carlini at oracle dot com 2009-05-13 18:42 --- To be clear, due to PR40134, the patch mentioned has been reverted for now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40133
[Bug libstdc++/40133] exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa}-linux
--- Comment #3 from paolo dot carlini at oracle dot com 2009-05-13 18:42 --- To be clear, due to PR40134, the patch mentioned has been reverted for now. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40133
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #24 from hjl dot tools at gmail dot com 2009-05-13 18:45 --- Using padding to avoid 4 branches in 16byte chunk may not be a good idea since it will increase code size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug target/37386] Interrupt service routine for arm target corrupts program counter
--- Comment #3 from fede dot tft at hotmail dot it 2009-05-13 18:53 --- (In reply to comment #2) This appears to be fixed with trunk as of r147467. Can you reproduce this with 4.3 or 4.4 ? If not we can close this one out. Tested with GCC 4.3.2, the bug is fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37386
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #25 from vvv at ru dot ru 2009-05-13 18:56 --- (In reply to comment #22) CCing H.J for Intel optimization issues. VVV 1. AMD limitation for 16-bytes page (memory range XXX0 - XXXF), but VVV Intel limitation for 16-bytes chunk (memory range - +10h) I have a doubt about this now. Sanks to Richard Guenther (Comment #20). So I am going to make measurements for check it for Core2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #26 from vvv at ru dot ru 2009-05-13 19:05 --- (In reply to comment #23) Note that we need something that works for the generic model as well, which in this case looks like it is the same as for AMD models. There is processor property TARGET_FOUR_JUMP_LIMIT, may be create new one - TARGET_FIVE_JUMP_LIMIT? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #27 from jakub at gcc dot gnu dot org 2009-05-13 19:08 --- If inserting the padding isn't worth it for say core2, m_CORE2 could be dropped from X86_TUNE_FOUR_JUMP_LIMIT, but certainly it would be interesting to see SPEC numbers backing that up. Similarly for AMD CPUs, and if on at least one of these it is beneficial, probably m_GENERIC should keep it, though with far improved min_insn_size so that it doesn't trigger unnecessarily so often. Vlad/Honza, could one of you SPEC test say current 4.4 with one (or both of): http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00702.html http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00703.html on top of it (no need to compare clearly unneeded paddings to no paddings, better compare only somewhat needed paddings against no paddings) compared with X86_TUNE_FOUR_JUMP_LIMIT cleared for the used CPU? -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #28 from vvv at ru dot ru 2009-05-13 19:18 --- (In reply to comment #24) Using padding to avoid 4 branches in 16byte chunk may not be a good idea since it will increase code size. It's enough only one byte NOP per 16-byte chunk for padding. But, IMHO, four branches in 16 byte chunk - is very-very infrequent. Especially for 64-bit mode. BTW, it's difficult to understand, what Intel mean ander term branch. Is it CALL, JMP, conditional branches, or returns (same as AMD), or only JMP and conditional branches. I beleave last case right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug fortran/31519] spurious ICE messages when module does not compile
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2009-05-13 19:37 --- I used to see that, but now not any more. Does someone else still see this happening? And with what testcase? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519
[Bug bootstrap/24382] ORIGINAL_LD_FOR_TARGET has bizarre value
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2009-05-13 19:48 --- As far as I know, this one has disappeared a long time ago. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24382
[Bug target/38900] ICE: unable to find a register to spill
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-05-13 20:04
---
Simpler testcase, confirmed on native i386-pc-mingw32 (trunk, SVN rev. 147441):
$ cat a.c
void __attribute__((dllimport,fastcall)) h(int);
void f()
{
h(2);
h(1);
}
$ gcc -S -O1 a.c -foptimize-sibling-calls
a.c: In function 'f':
a.c:7: error: unable to find a register to spill in class 'CREG'
a.c:7: error: this is the insn:
(call_insn/j 10 8 11 2 a.c:6 (call (mem:QI (reg/f:SI 3 bx [58]) [0 S1 A8])
(const_int 0 [0x0])) 468 {*sibcall_1} (expr_list:REG_DEAD (reg/f:SI 3
bx [58])
(expr_list:REG_DEAD (reg:SI 2 cx)
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:SI 2 cx))
(nil)))
a.c:7: internal compiler error: in spill_failure, at reload1.c:2094
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
Last reconfirmed|-00-00 00:00:00 |2009-05-13 20:04:31
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #15 from matz at gcc dot gnu dot org 2009-05-13 20:14 --- Subject: Bug 39976 Author: matz Date: Wed May 13 20:14:44 2009 New Revision: 147494 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147494 Log: PR middle-end/39976 * tree-outof-ssa.c (maybe_renumber_stmts_bb): New function. (trivially_conflicts_p): New function. (insert_backedge_copies): Use it. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-outof-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug target/34625] msgl-check.c:199: error: unrecognizable insn:
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2009-05-13 20:24 --- Fixed, at least for current trunk. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34625
[Bug middle-end/40135] New: using alias-set zero for union accesses necessary because of RTL alias oracle
The RTL alias oracle does defer to TBAA even for the case of disambiguating two accesses based on decls. This makes /* Permit type-punning when accessing a union, provided the access is directly through the union. For example, this code does not permit taking the address of a union member and then storing through it. Even the type-punning allowed here is a GCC extension, albeit a common and useful one; the C standard says that such accesses have implementation-defined behavior. */ for (u = t; TREE_CODE (u) == COMPONENT_REF || TREE_CODE (u) == ARRAY_REF; u = TREE_OPERAND (u, 0)) if (TREE_CODE (u) == COMPONENT_REF TREE_CODE (TREE_TYPE (TREE_OPERAND (u, 0))) == UNION_TYPE) return 0; in c-common.c necessary which needlessly pessimizes TBAA in the face of union accesses. -- Summary: using alias-set zero for union accesses necessary because of RTL alias oracle Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization, alias Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40135
[Bug middle-end/40135] using alias-set zero for union accesses necessary because of RTL alias oracle
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-13 20:31 --- The tree alias oracle gets this right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40135
[Bug middle-end/39986] decimal float constant is incorrect when cc1 is a 64-bit binary
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-05-13 20:46 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39986
[Bug middle-end/40035] ICE when cross-compiling with -Os
--- Comment #2 from bje at gcc dot gnu dot org 2009-05-13 20:52 --- Subject: Bug 40035 Author: bje Date: Wed May 13 20:52:00 2009 New Revision: 147498 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147498 Log: PR middle-end/40035 * dse.c (check_mem_read_rtx): Guard against width == -1. testsuite/ * gcc.c-torture/compile/pr40035.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr40035.c Modified: trunk/gcc/ChangeLog trunk/gcc/dse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40035
[Bug middle-end/40035] ICE when cross-compiling with -Os
--- Comment #3 from bje at gcc dot gnu dot org 2009-05-13 20:56 --- Fixed. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40035
[Bug middle-end/40035] ICE when cross-compiling with -Os
--- Comment #4 from bje at gcc dot gnu dot org 2009-05-13 21:42 --- Subject: Bug 40035 Author: bje Date: Wed May 13 21:42:03 2009 New Revision: 147501 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147501 Log: Backport from mainline: PR middle-end/40035 * dse.c (check_mem_read_rtx): Guard against width == -1. testsuite/ * gcc.c-torture/compile/pr40035.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40035.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/dse.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40035
[Bug target/39942] Nonoptimal code - leaveq; xchg %ax,%ax; retq
--- Comment #29 from hjl dot tools at gmail dot com 2009-05-13 21:44 --- Created an attachment (id=17858) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17858action=view) Impact of X86_TUNE_FOUR_JUMP_LIMIT on SPEC CPU 2K This is my old data of X86_TUNE_FOUR_JUMP_LIMIT on Penryn and Nehalem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39942
[Bug c++/40007] [4.5 regression] specialization causes access problem in primary template
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-13 21:53:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40007
[Bug target/34341] GCC generates incorrect code on ARM in certain case, resulting in stack corruption
--- Comment #2 from awalbran at innaworks dot com 2009-05-13 21:27 --- Yes, I agree that the testcase does not make much sense, it is just the smallest testcase that I could find which demonstrates the bug. It is fine that the return value is undefined; the problem is that the stack pointer gets corrupted, which should never happen no matter what the function happens to do. However, if I remember correctly this bug no longer occurs in a more recent version of GCC, so I guess this report is mostly just useful for regression testing now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34341
[Bug preprocessor/36674] #include location is offset by one row in errors from preprocessed files
--- Comment #2 from manu at gcc dot gnu dot org 2009-05-13 23:18 --- Subject: Bug 36674 Author: manu Date: Wed May 13 23:17:55 2009 New Revision: 147504 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147504 Log: 2009-05-14 Manuel Lopez-Ibanez m...@gcc.gnu.org PR cpp/36674 libcpp/ * directives (do_linemarker): Compensate for the increment in location that occurs when we reach the end of line. * files (_cpp_stack_include): Mention _cpp_find_file in the comment. testsuite/ * gcc.dg/cpp/pr36674.i: New. Added: trunk/gcc/testsuite/gcc.dg/cpp/pr36674.i Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/directives.c trunk/libcpp/files.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36674
[Bug preprocessor/36674] #include location is offset by one row in errors from preprocessed files
--- Comment #3 from manu at gcc dot gnu dot org 2009-05-13 23:19 --- FIXED in GCC 4.5 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36674
[Bug c/40136] New: Initializing a union whose first member is an anonymous struct
Not sure if this is a bug or a standards interpretation issue. Consider the
following union, whose first member is an anonymous struct:
union Foo {
struct { float a,b,c; };
const char* x;
};
icc (10.1) permits initialization of the first member of the union:
Foo foo = { .0f, .0f, .0f };
gcc (4.0.1) doesn't permit that, but does permit the following, which I believe
should not be accepted:
Foo foo = { foo };
--
Summary: Initializing a union whose first member is an anonymous
struct
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markleone at gmail dot com
GCC host triplet: i686-apple-darwin9-gcc-4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40136
[Bug c++/40137] New: Segmentation fault compiling simple c++ code
san ~ $ g++ -v -save-temps gcc4.4.0_segfaults.cpp Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++,fortran,objc,obj-c++ --enable-threads=posix --mandir=/usr/share/man --infodir=/usr/share/info --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic Thread model: posix gcc version 4.4.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/cc1plus -E -quiet -v -D_GNU_SOURCE gcc4.4.0_segfaults.cpp -mtune=generic -fpch-preprocess -o gcc4.4.0_segfaults.ii ignoring nonexistent directory /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0 /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/i686-pc-linux-gnu /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward /usr/local/include /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/i686-pc-linux-gnu/4.4.0/cc1plus -fpreprocessed gcc4.4.0_segfaults.ii -quiet -dumpbase gcc4.4.0_segfaults.cpp -mtune=generic -auxbase gcc4.4.0_segfaults -version -o gcc4.4.0_segfaults.s GNU C++ (GCC) version 4.4.0 (i686-pc-linux-gnu) compiled by GNU C version 4.4.0, GMP version 4.2.4, MPFR version 2.4.1. GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129315 Compiler executable checksum: 9eeca1d61ee5f7a810fd0c50c7c0ab78 gcc4.4.0_segfaults.cpp: In member function void FooT::foo() [with T = int]: gcc4.4.0_segfaults.cpp:33: instantiated from here gcc4.4.0_segfaults.cpp:26: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: Segmentation fault compiling simple c++ code Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: piccinini dot santiago at gmail dot com GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40137
[Bug target/38703] testsuite __gnu_mcount_nc link error when profiling on arm
--- Comment #7 from ramana at gcc dot gnu dot org 2009-05-13 23:56 --- Marking as WONTFIX as per comment#1 above. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38703
[Bug c++/40137] Segmentation fault compiling simple c++ code
--- Comment #1 from piccinini dot santiago at gmail dot com 2009-05-13 23:56 --- Created an attachment (id=17859) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17859action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40137
[Bug fortran/39865] ICE in gfc_conv_scalarized_array_ref
--- Comment #12 from jakub at gcc dot gnu dot org 2009-05-14 00:00 --- Subject: Bug 39865 Author: jakub Date: Thu May 14 00:00:27 2009 New Revision: 147507 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147507 Log: PR fortran/39865 * io.c (resolve_tag_format): CHARACTER array in FMT= argument isn't an extension. Reject non-CHARACTER array element of assumed shape or pointer or assumed size array. * trans-array.c (array_parameter_size): New function. (gfc_conv_array_parameter): Add size argument. Call array_parameter_size if it is non-NULL. * trans-array.h (gfc_conv_array_parameter): Adjust prototype. * trans-expr.c (gfc_conv_function_call, gfc_trans_arrayfunc_assign): Adjust callers. * trans-intrinsic.c (gfc_conv_intrinsic_loc): Likewise. * trans-io.c (gfc_convert_array_to_string): Rewritten. * gfortran.dg/pr39865.f90: New test. * gfortran.dg/hollerith.f90: Don't expect errors for CHARACTER arrays in FMT=. * gfortran.dg/hollerith_f95.f90: Likewise. * gfortran.dg/hollerith6.f90: New test. * gfortran.dg/hollerith7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/hollerith6.f90 trunk/gcc/testsuite/gfortran.dg/hollerith7.f90 trunk/gcc/testsuite/gfortran.dg/pr39865.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/hollerith.f90 trunk/gcc/testsuite/gfortran.dg/hollerith_f95.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39865
[Bug target/40105] SH: 4.3/4.4 compilers segfault when recompiling itself on gentoo system
--- Comment #5 from kkojima at gcc dot gnu dot org 2009-05-14 00:12 --- Created an attachment (id=17860) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17860action=view) A patch A binary search on trunk shows me that the patch in r146829 and its follow-up r146988 fix the issue. See http://gcc.gnu.org/ml/gcc-patches/2009-04/msg02097.html for r146829 changes. With these patches, 4.3 compiler emits bf .L5 instead of bf/s .L5 even with -O1. So it seems that this is an rtl-optimization issue which is fixed on trunk recently. I'm not sure about the backport to the release branches because that patch is originally for PR 34415 which was also a mips 4.3 regression and solved only on the trunk (4.4 at that moment). I've attached an r146829+r146988 patch tuned for gcc-4_3-branch. Could you try it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40105
[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution
--- Comment #13 from hp at gcc dot gnu dot org 2009-05-14 00:12 --- By chance I stumbled upon an old fix I did some years ago in which I changed a use of next_active_insn to next_real insn (to avoid skipping USE insns). You can see it in comments referring to a now-deleted main use (the references gone stale). This PR is just the same bug in another place! I think I'll be going for the same solution; it will reduce the number of filled delay-slots or redirected jumps and removed redundant insns, but presumably safer as it will not include moving or duplicating the USE insns. It would also be solved by a reorg rewrite, in which USE insns wouldn't be sprinkled into the insn stream, sometimes ignored, sometimes incorrectly... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
[Bug c++/40137] Segmentation fault compiling simple c++ code
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-14 00:35 --- *** This bug has been marked as a duplicate of 40013 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40137
[Bug c++/40013] [4.4/4.5 Regression] ICE when creating a local array with size from the return value of a member function of an object in a nested class in a template class
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-14 00:35 --- *** Bug 40137 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||piccinini dot santiago at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40013
[Bug c/40136] Initializing a union whose first member is an anonymous struct
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-14 00:42 ---
4.0 branch is closed. Gcc 4.1.2 gave
[...@gnu-3 tmp]$ cat u.cc
union Foo {
struct { float a,b,c; };
const char* x;
};
Foo foo = { .0f, .0f, .0f };
Foo foo1 = { foo };
[...@gnu-3 tmp]$ gcc -c u.cc
u.cc:7: error: cannot convert const char* to float in initialization
[...@gnu-3 tmp]$
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40136
[Bug c/40065] spurious format string warnings
--- Comment #4 from bje at gcc dot gnu dot org 2009-05-14 01:01 --- Andrew wrote: GCC can assume %qE means anything from just printing E in quotes Can you explain this? Is it really the case that the format specifier can have an optional argument? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40065
[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution
--- Comment #14 from hp at gcc dot gnu dot org 2009-05-14 01:18 --- Created an attachment (id=17861) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17861action=view) patch for just the bug at hand. This patch just changes the next_active_insn for the exposure in this PR. I think most uses of next_active_insn in reorg.c and resource.c should be changed to next_real_insn. Or reorg.c rewritten, at least to not use in-stream liveness markers like those USE insns. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
[Bug middle-end/39301] ICE in register_overhead, at bitmap.c:115
--- Comment #7 from bje at gcc dot gnu dot org 2009-05-14 01:31 --- The test case does not run in a GB of RAM on my x86-64 system. It sends the system deep into swap until the out-of-memory manager kicks in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39301
[Bug target/40129] M16C invalid shift count used by pack_d - ashldi3
--- Comment #1 from dj at redhat dot com 2009-05-14 02:52 --- Do you have a test case that shows an actual problem? Because the m32c port has special code that tests for shift counts outside -16..16 and pre-shifts the value to make the shift count fit (see gcc/config/m32c/m32c.c m32c_prepare_shift()). -- dj at redhat dot com changed: What|Removed |Added CC||dj at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40129
[Bug libstdc++/19495] basic_string::_M_rep() can produce an unnaturally aligned pointer to _Rep
--- Comment #26 from bje at gcc dot gnu dot org 2009-05-14 02:54 --- This test now passes on powerpc*-linux-gnu. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19495
