--- Comment #8 from maxposedon at gmail dot com 2009-05-14 06:51 ---
in gcc-4.4.0 release this bug wasn't fixed
--
maxposedon at gmail dot com changed:
What|Removed |Added
--- Comment #13 from jakub at gcc dot gnu dot org 2009-05-14 06:45 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from burnus at gcc dot gnu dot org 2009-05-14 06:28 ---
Patch: http://gcc.gnu.org/ml/fortran/2009-05/msg00163.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39352
--- Comment #54 from dave dot korn dot cygwin at gmail dot com 2009-05-14
06:25 ---
I've started work on the binutils support for this. Work-in-progress patch at
http://sourceware.org/ml/binutils/2009-05/msg00228.html
Once that's complete, I could deal with the GCC end too.
What shou
--- Comment #7 from bje at gcc dot gnu dot org 2009-05-14 06:18 ---
Fails with 4.5.0 20090513.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bje at gcc dot gnu dot org
|dot org
--- Comment #5 from bje at gcc dot gnu dot org 2009-05-14 06:08 ---
Can this PR be closed now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38156
--- Comment #14 from bje at gcc dot gnu dot org 2009-05-14 05:34 ---
Can this PR be closed now, Janis?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34526
--- Comment #2 from bje at gcc dot gnu dot org 2009-05-14 05:22 ---
Still present in GCC 4.5.0 20090513. Note that -O2 or above is also required
to trigger this bug -- that was not mentioned in the original report.
--
bje at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from bje at gcc dot gnu dot org 2009-05-14 05:19 ---
Still present in GCC 4.5.0 20090513.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31557
--- Comment #2 from bje at gcc dot gnu dot org 2009-05-14 05:16 ---
Still present in GCC 4.5.0 20090513.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31055
--- Comment #16 from luisgpm at linux dot vnet dot ibm dot com 2009-05-14
04:12 ---
Just for the record... The 64-bit case is fixed. There are still performance
issues in the 32-bit case.
I'll attach more information soon.
Luis
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
--- Comment #9 from bje at gcc dot gnu dot org 2009-05-14 04:03 ---
The original reporter seems to have resolved this to their satisfaction in
their CrystalSpace3d bug report. This report was due to running up against a
limitation of the -fPIC implementation.
--
bje at gcc dot gnu d
--- Comment #10 from bje at gcc dot gnu dot org 2009-05-14 03:46 ---
Still present in GCC 4.5.0 20090513.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27682
--- Comment #14 from bje at gcc dot gnu dot org 2009-05-14 03:35 ---
Confirmed with GCC 4.5.0 20090513 (experimental) [trunk revision 147498].
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619
--- Comment #9 from billingd at gcc dot gnu dot org 2009-05-14 03:24
---
Draft patch http://gcc.gnu.org/ml/libstdc++/2009-05/msg00090.html
--
billingd at gcc dot gnu dot org changed:
What|Removed |Added
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bje at gcc dot gnu dot org
|dot org
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bje at gcc dot gnu dot org
|dot org
--- Comment #5 from bje at gcc dot gnu dot org 2009-05-14 03:19 ---
Still present in GCC: (GNU) 4.5.0 20090513 (experimental) [trunk revision
147498].
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26525
--- Comment #6 from bje at gcc dot gnu dot org 2009-05-14 03:04 ---
Still present in GCC (GNU) 4.5.0 20090513 (experimental) [trunk revision
147498].
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16798
--- Comment #5 from bje at gcc dot gnu dot org 2009-05-14 03:00 ---
Still present in GCC 4.5.0 (20090513).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16456
--- 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
--- 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_pr
--- 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 #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=17861&action=view)
patch for just the bug at hand.
This patch just changes the next_active_insn for the exposure in this PR.
I think m
--- 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/bugzil
--- 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 #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 #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 #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 #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 #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 #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 #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
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
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 };
--- 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
--- 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/
--
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 #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
--- 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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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
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
# 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
--- 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
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- 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
--- 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 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 #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 #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 #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 #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 #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 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
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfir
--- 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?
--- 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 #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 #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 #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 #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
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 #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
--- 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 #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
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 #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
--- 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 #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 #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
1 - 100 of 127 matches
Mail list logo
