--- 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
--- 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 co
--- 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 contr
--- 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
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- 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: p
This code:
# 1 "fs.c"
# 1 ""
# 1 ""
# 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
some disasm listings to show what is going wrong..
i cant find the guilty source files:-(
000fa8b2 <___pack_d>:
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
--- 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=gcc&view=rev&rev=147469
Log:
PR target/37179
* config/i386/driver-i386.c (proce
--- 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 |Add
--- 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 int
--- 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=17856&action=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 dec
--- 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 ma
--- 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 p
--- 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: gcc.c-torture/execute/ieee/
--- 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=17857&action=view)
a test case
I've got a small test case from libiberty/concat.c.
With -O1, 4.3 compiles vconcat_length to the co
--- 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
--- 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:
W
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 libgfortra
--- 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 sur
--- 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=gcc&view=rev&rev=147477
Log:
2009-05-13 Tobias Burnus
PR fortran/34153
*
--- 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 #6 from laurent at guerby dot net 2009-05-13 15:09 ---
No objection from me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38703
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-05-13
15:16 ---
Subject: Re: Various cleanup tests fail
> 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|WAITING |NEW
Ever Confirmed|0 |1
Last reconfir
--- 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 #2 from reichelt at gcc dot gnu dot org 2009-05-13 16:07
---
Confirmed (with "-m32 -O2 -g" on x86_64-unknown-linux-gnu). Reduced testcase:
==
typedef struct A
{
int i;
struct A *p;
} A;
static int f1(A *t)
{
if (t->
--- 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 #1 from ubizjak at gmail dot com 2009-05-13 16:26 ---
It looks to me, that these test never really passed on x87. Compiling wiht
gcc-4.3, we get:
main:
leal4(%esp), %ecx
andl$-16, %esp
pushl -4(%ecx)
pushl %ebp
movl%esp
--- Comment #11 from doko at debian dot org 2009-05-13 16:28 ---
Subject: Re: [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3
not exported
bkoz at gcc dot gnu dot org schrieb:
> --- Comment #10 from bkoz at gcc dot gnu dot org 2009-05-12 23:01 ---
>
> Sorry for the delay Pa
--- 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 reconfir
--- 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-stor
# 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 libstdc
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
referen
--- 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 li
--- 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 fail
--- 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]), %[o
--- 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 issue
--- 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.
--
http://gcc.
--- 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 -
+10
--- 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 creat
--- 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
--- 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 |Adde
--- 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=gcc&view=rev&rev=147494
Log:
PR middle-end/39976
* tree-outof-ssa.c (maybe_renu
--- 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 m
--- 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
Status|REOPENE
--- 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=gcc&view=rev&rev=147498
Log:
PR middle-end/40035
* dse.c (check_mem_read_rtx): Gua
--- 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=gcc&view=rev&rev=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=17858&action=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 a
--
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 poin
--- 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=gcc&view=rev&rev=147504
Log:
2009-05-14 Manuel Lopez-Ibanez
PR cpp/36674
libcpp/
--- 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 --enable-__cxa_ate
--- 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=17859&action=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=gcc&view=rev&rev=147507
Log:
PR fortran/39865
* io.c (resolve_tag_format): CH
--- 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=17860&action=view)
A patch
A binary search on trunk shows me that the patch in r146829 and
its follow-up r146988 fix the issue.
Se
--- 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 (t
--- 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
---
1 - 100 of 127 matches
Mail list logo
