--- 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
--- 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
--- 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
--- 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
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- 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:
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
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
--- 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
--- 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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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,
--- 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
--- 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
--- 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:
--- 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
--- 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
--- 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
--- 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
--- 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
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:
--- 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
--- 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
--- 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:
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- 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
# 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
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
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
--- 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
--- 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
--- 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
--- 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]),
--- 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
--- 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
--- 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
--- 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
--- 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.
--- 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
--- 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
--- 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
--- 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
--- 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.
--
--- 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)
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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):
--- 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
--- 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
--- 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
--
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
--- 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
--- 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
--- 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
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
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
--- 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
--- 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
--- 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):
--- 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
--- 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
--- 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
--- 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
--- 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:
--- 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?
--
--- 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
--- 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
--- 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
--- 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
1 - 100 of 108 matches
Mail list logo
