2009/12/6 Frédéric L. W. Meunier fred...@gmail.com:
Will there be a 4.3.5 release ?
Looking at http://gcc.gnu.org/ml/gcc/2009-08/msg00066.html , yes, but 4.4.2
was released almost two months ago.
I expect so.
Richard.
Well I have good news to report.
I applied most of your recommended changes, but it still crashed,
still at the same spot:
built-in:0: internal compiler error: Segmentation fault
However, I managed to track it down to some floating point stuff
in the i370 code, and got rid of that, and now I
Jeff Law wrote:
I had an epiphany this morning and came up with an idea to achieve
the
lookahead I thought I needed, thereby making the costs created by '?'
a
lot more concrete and reliable.
Firstly, I have altered the alt_cost adjustment (for '?') in ira-
costs.c,
so that it only
Hi,
x86-64 psABI says _Bool has 1 byte and aligned at 1 byte. It also says:
---
When a value of type _Bool is passed in a register or on the stack,
the upper 63 bits of the eightbyte shall be zero.
---
However, gcc treats _Bool as char:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324
Given
On 12/07/2009 10:33 AM, H.J. Lu wrote:
Hi,
x86-64 psABI says _Bool has 1 byte and aligned at 1 byte. It also says:
---
When a value of type _Bool is passed in a register or on the stack,
the upper 63 bits of the eightbyte shall be zero.
---
However, gcc treats _Bool as char:
On 12/07/2009 10:33 AM, H.J. Lu wrote:
Hi,
x86-64 psABI says _Bool has 1 byte and aligned at 1 byte. It also says:
---
When a value of type _Bool is passed in a register or on the stack,
the upper 63 bits of the eightbyte shall be zero.
---
However, gcc treats _Bool as char:
Hi -
Please be aware of an impending temporary outage machines hosting
gcc.gnu.org, sourceware.org, sources.redhat.com, cygwin.com, and a few
other sites. All email, web, ftp, cvs, git, etc. services will be off
line while the machines are being moved between two colocation
facilities this
Note that the m32c port uses PSImode, so it may offer some suggestions
as example code.
Hi,
It seems that many current uses of listT::merge( ) fail to compile
with -std=c++0x, but I don't see a bug in bugzilla for this. Itseems to
result from:
list_Tp, _Alloc::
#ifdef __GXX_EXPERIMENTAL_CXX0X__
merge(list __x)
#else
merge(list __x)
#endif
For c++0x, don't we need BOTH
On 12/06/09 20:10, daniel tian wrote:
You might start by monitoring emit_reload_insns's behavior when it handles
your insn.
I just debug the source code with your advice. Check the function
emit_reload_insns.
That insn was deleted before entering funcion emit_reload_insns. It
was deleted
Note that the m32c port uses PSImode, so it may offer some suggestions
as example code.
Yes, that's right, but the m32c port uses it as a mode for pointers,
while I'm trying to do it with scalars.
Anyway, thank you very much.
Hi Jeff:
I have already fixed the bug. this occurs due to register
allocation failed in function global_alloc. After calling the
find_reg(), the reg_renumber still keep the value -1 in it. So the
reload() in reload1.c delete the insns.
I didn't set any call saved registers which means
--- Comment #1 from christian dot bruel at st dot com 2009-12-07 08:13
---
I'm wondering if this is not an application of the name hiding rule described
in the IEC 14882:1998 (3.3.7) that says here that the class name T::X is hidden
by the object static int T::X i, so T::X y refers to
--- Comment #4 from carrot at google dot com 2009-12-07 08:58 ---
Created an attachment (id=19247)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19247action=view)
patch
The attached patch can fix this bug. But due to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258, it can't
--- Comment #1 from christian dot bruel at st dot com 2009-12-07 09:08
---
A reduced case. Still doesn't compile on 4.5
struct T
{
int i;
T(int _i) ;
};
void foo()
{
volatile T t1 = 1;
}
--
christian dot bruel at st dot com changed:
What|Removed
cat T.C \EOF
// { dg-do link }
// { dg-options -O0 }
// { dg-additional-sources T-aux.cc }
#include T.h
D::D (int x) : C (x) {}
int
main ()
{
}
EOF
cat T.h \EOF
struct A
{
A ();
~A ();
};
struct B
{
A b;
virtual void mb ();
B (int);
virtual ~B ();
};
struct C : public B
{
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.5.0
--- Comment #18 from burnus at gcc dot gnu dot org 2009-12-07 09:23 ---
(In reply to comment #16)
I disagree with your conclusion that this is invalid. :-)
10.6.1 explicitly says that the BOZ descriptors may be used
for real and complex.
(In reply to comment #17)
Richard Maine
--- Comment #19 from burnus at gcc dot gnu dot org 2009-12-07 09:33 ---
(In reply to comment #18)
(In reply to comment #16)
I disagree with your conclusion that this is invalid. :-)
10.6.1 explicitly says that the BOZ descriptors may be used
for real and complex.
(In reply to
--- Comment #1 from redi at gcc dot gnu dot org 2009-12-07 11:02 ---
GCC 4.4.2 rejects this
tt.cc: In function 'int main(int, char**)':
tt.cc:3: error: 'A::A()' is private
tt.cc:7: error: within this context
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42302
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42315
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-07 11:08 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-07 11:08 ---
You should (also) report this to boehm-gc upstream. Note that patches to
gcc should be sent to gcc-patc...@gcc.gnu.org.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-07 11:10 ---
Fixed then.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-07 11:11 ---
If 4.4.1 works then this is P1.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42299
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-07 11:14 ---
Huh? Does plain -O2 work? Do I understand correctly that -O2 -fno-loop-block
-fno-loop-strip-mine miscompiles?
Sebastian, how can disabling graphite options but not enabling graphite
miscompile anything?? P1,
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-07 11:17 ---
-fschedule-insns is quite tricky for x86 targets, if it doesn't work do not use
it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||zaks at il dot ibm dot com,
|
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-07 11:20 ---
Please post patches to gcc to gcc-patc...@gcc.gnu.org and also report this
to libffi upstream.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42289
Hello,
in my build system I want to have the glibc in a different path, and I pass
-B/myglibcpath/lib in CFLAGS_FOR_TARGET and LDFLAGS_FOR_TARGET in the make
process.
This flag was respected in the target libmudflap linking step of gcc 4.3.4, and
therefore the usual crti.o and other startfiles
Compiling the following one-liner
#include bits/char_traits.h
(one can use #include ios instead to avoid including from bits/)
with
g++-trunk -std=c++0x -D_GLIBCXX_PARALLEL
produces several errors.
This was broken somewhere between
gcc version 4.5.0 20091117 (experimental) (GCC)
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
(This is not the same issue as 37352.)
cat Base.hh
struct Base1 {
virtual ~Base1() {}
};
struct Base2 {
virtual void f() = 0;
};
struct Base : Base1, Base2 {
virtual void f();
};
cat Base.cc
#include Base.hh
void Base::f() {}
cat Foo.cc
#include Base.hh
struct Foo
--- Comment #1 from jakub at gcc dot gnu dot org 2009-12-07 12:55 ---
Created an attachment (id=19248)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19248action=view)
gcc45-pr42317.patch
Untested patch to implement the (admittedly ugly) cgraph changes to force
D0 to be output
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.5.0
--- Comment #3 from nemokingdom at gmail dot com 2009-12-07 13:01 ---
Subject: Re: [4.5 Regression] GCC fails validity in
mdbx in polyhedral benchmark.
Hi Rguenth,
On Mon, Dec 7, 2009 at 7:14 PM, rguenth at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
---
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-12-07 14:00
---
I agree with everyone. ;) Let's not split hairs. Dominique's idea is good.
Let's go to that (comment #14) for now and leave the rest as enhancement. This
would be a great project for a new volunteer. Anyone
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-07
14:03 ---
(In reply to comment #2)
Huh? Does plain -O2 work? Do I understand correctly that -O2 -fno-loop-block
-fno-loop-strip-mine miscompiles?
Sebastian, how can disabling graphite options but not enabling
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-12-07 14:15 ---
(In reply to comment #6)
The problem is that the comparison of types is not anti-symmetrical:
Looking at the code, I see that we don't stabilize the sort for
integers. Can you please try the following (and
--- Comment #1 from paolo at gcc dot gnu dot org 2009-12-07 14:28 ---
Subject: Bug 42319
Author: paolo
Date: Mon Dec 7 14:27:59 2009
New Revision: 155036
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155036
Log:
2009-12-07 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-07 14:30
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Test program:
//
void f()
{
asm volatile(veor d8, d8, d8 : : :d8,d9,d10,d11,d14,d15);
}
//
$ gcc -c -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O2 test.c
$ objdump -d test.o
f:
0: ed2d8b08vpush {d8-d11}
4:
--- Comment #1 from siarhei dot siamashka at gmail dot com 2009-12-07
14:42 ---
Modifying the program to list q-registers in the clobber list provides even
more interesting results:
//
void f()
{
asm volatile(veor d8, d8, d8 : : :q4,q5,q7);
}
--- Comment #21 from burnus at gcc dot gnu dot org 2009-12-07 14:43 ---
(In reply to comment #20)
Dominique's idea is good. Let's go to that (comment #14) for now and leave
the rest as enhancement. This would be a great project for a new volunteer.
Anyone interested. I am willing
--- Comment #2 from burnus at gcc dot gnu dot org 2009-12-07 14:44 ---
*PING* Are you still working on this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41507
--- Comment #22 from dominiq at lps dot ens dot fr 2009-12-07 14:55 ---
(In reply to comment #21)
...
real(10) :: r10
...
This does work on platforms that do not support real(10), but have real(16).
Something such as:
integer,parameter :: k8 = selected_real_kind (precision
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-07 15:11 ---
(In reply to comment #1)
I'm wondering if this is not an application of the name hiding rule described
in the IEC 14882:1998 (3.3.7) that says here that the class name T::X is
hidden
by the object static int T::X
--- Comment #9 from ghazi at gcc dot gnu dot org 2009-12-07 15:33 ---
Subject: Bug 40302
Author: ghazi
Date: Mon Dec 7 15:32:43 2009
New Revision: 155043
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155043
Log:
PR other/40302
* arith.c: Remove HAVE_mpc* checks
--- Comment #3 from zsojka at seznam dot cz 2009-12-07 15:33 ---
This testcase (the call to f() isn't needed in this case) crashes with 4.4 with
these flags as well:
-O3 -fselective-scheduling2 -fsel-sched-pipelining
-fsel-sched-pipelining-outer-loops
(-O2 is enough for trunk)
The
--- Comment #3 from burnus at gcc dot gnu dot org 2009-12-07 15:35 ---
(In reply to comment #1)
As this is my texi cleanup bug: Dump the following in order to not forget it.
Seemingly, I applied it at some point. Thus, only comment 0 remains.
--
--- Comment #10 from ghazi at gcc dot gnu dot org 2009-12-07 15:37 ---
Subject: Bug 40302
Author: ghazi
Date: Mon Dec 7 15:36:46 2009
New Revision: 155045
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155045
Log:
PR other/40302
* gcc.dg/torture/builtin-math-6.c:
--- Comment #11 from ghazi at gcc dot gnu dot org 2009-12-07 15:43 ---
Subject: Bug 40302
Author: ghazi
Date: Mon Dec 7 15:42:55 2009
New Revision: 155046
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155046
Log:
PR other/40302
* builtins.c: Remove HAVE_mpc*
--- Comment #12 from ghazi at gcc dot gnu dot org 2009-12-07 15:45 ---
Subject: Bug 40302
Author: ghazi
Date: Mon Dec 7 15:45:01 2009
New Revision: 155047
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155047
Log:
PR other/40302
* configure.ac (HAVE_mpc): Don't
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-07 15:47 ---
The ICE got fixed by PR27425 fix on the trunk, though that only talks about
error cases where those should appear, on this testcase no errors are reported.
--
jakub at gcc dot gnu dot org changed:
What
--- Comment #2 from ramana at gcc dot gnu dot org 2009-12-07 15:52 ---
Also appears with trunk as of today.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Currently, when you get the error 'foo is not a template function' (if for
example, you try to write a template specialization of a function foo when foo
is not actually templated) you have no way of determining what definition of
foo the compiler might have found without pouring through your
--- Comment #13 from ghazi at gcc dot gnu dot org 2009-12-07 15:55 ---
Done.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #23 from burnus at gcc dot gnu dot org 2009-12-07 15:56 ---
Dominique, does the following program work on a real(16) system such as Darwin?
! { dg-do run }
! { dg-require-effective-target fortran_large_real }
! { dg-require-effective-target fortran_large_int }
!
! PR
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-12-07 15:55
---
I can confirm both of these issues.
in asm statements GCC currently just treats 'q4' and 'd8' as aliases for s16
(which of course is just a 32-bit register); there's currently no way of
expressing that a larger
--- Comment #3 from tromey at gcc dot gnu dot org 2009-12-07 15:57 ---
Yes, that's exactly what I would like. Thanks.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from domob at gcc dot gnu dot org 2009-12-07 15:58 ---
Thanks for reminding me, Tobias! Actually, yes, I still plan to fix this. I
probably don't have time and motivation right now to work on a general plan
to improve documentation issues like that, but at least on the
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2009-12-07
16:01 ---
Subject: Re: [4.5 Regression] Internal error compiling fortran/intrinsic.c
Will check 4.4 with checking enabled.
4.4.3 builds with checking enabled:
--- Comment #4 from rth at gcc dot gnu dot org 2009-12-07 16:12 ---
Not working on it any longer.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rth at gcc dot gnu dot org 2009-12-07 16:19 ---
Created an attachment (id=19249)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19249action=view)
Proposed patch
For the record, this is all that's needed for the above output.
I see quite a few gdb regressions vs
--- Comment #3 from christian dot bruel at st dot com 2009-12-07 16:41
---
The test can be reduced to this, which should not compile:
struct A {
struct X { };
int X;
};
templateclass T void f(T t) {
typename T::X x;
}
void foo() {
A a;
f(a); // error: T::X refers
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-07 16:41
---
In any case, please provide a small self-contained snippet demonstrating the
issue. Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
a 20091204 build on powerpc-linux-gnu with --enable-libstdcxx-debug and
--enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 fails to
build the 64bit libstdc++ debug lib. all other three libstdc++ variants seem to
build. Using the bfd or gold linker from the binutils 2.20 branch
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-12-07
16:54 ---
Oddly these errors don't show up on x86_64-apple-darwin9 built with mpc 0.8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42074
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2009-11-17 00:19:52 |2009-12-07
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-07 17:09 ---
Distilled testcase (-g -O2):
extern int bar (void);
static int
foo (int x, int y)
{
if (y)
goto lab;
if (x)
y = 0;
if (y)
goto lab;
y = 0;
lab:
return y;
}
void
baz (int x, int y)
{
y = foo
--- Comment #6 from jakub at gcc dot gnu dot org 2009-12-07 17:14 ---
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00992.html
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01218.html
needs review...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41679
--- Comment #92 from jakub at gcc dot gnu dot org 2009-12-07 17:15 ---
The patches weren't reviewed/approved.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-07 17:16 ---
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00222.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42244
--- Comment #1 from jakub at gcc dot gnu dot org 2009-12-07 17:23 ---
Can't reproduce. Please provide preprocessed source.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from daney at gcc dot gnu dot org 2009-12-07 17:27 ---
It is failing because the redundant stack pointer adjustments are not being
removed.
This test is passing for me on i686-pc-linux-gnu at r154987, so I think it
must be darwin specific.
If for some reason darwin
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-07 17:32 ---
Subject: Bug 41940
Author: dfranke
Date: Mon Dec 7 17:32:29 2009
New Revision: 155049
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155049
Log:
gcc/fortran:
2009-12-07 Daniel Franke
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #1 from jakub at gcc dot gnu dot org 2009-12-07 17:48 ---
Likely dup of PR42317.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42323
--- Comment #4 from zsojka at seznam dot cz 2009-12-07 18:02 ---
Created an attachment (id=19250)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19250action=view)
different testcase, this one is using doubles
tested r155020, crashes with:
-O1 -funsafe-math-optimizations
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-07 18:04 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
x86-64 psABI says:
---
When a value of type _Bool is passed in a register or on the stack,
the upper 63 bits of the eightbyte shall be zero.
---
However, gcc generates:
[...@gnu-6 tmp]$ cat b.c
_Bool myfunction(char val)
{
return val;
}
[...@gnu-6 tmp]$ gcc -O2 -S b.c
[...@gnu-6 tmp]$ cat b.s
--- Comment #3 from amonakov at gcc dot gnu dot org 2009-12-07 18:23
---
Also not reproducible on x86_64-ppc64 cross.
While codegen differences on ppc/ppc64/x86_64 cross are certainly surprising,
in the end this testcase most likely indicates a bug in sel-sched.
--
amonakov at gcc
--- Comment #93 from howarth at nitro dot med dot uc dot edu 2009-12-07
18:25 ---
(In reply to comment #92)
The patches weren't reviewed/approved.
Jakub,
Could you review and approve the patches then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
--- Comment #94 from jakub at gcc dot gnu dot org 2009-12-07 18:30 ---
No, a quick look into MAINTAINERS could tell you that as this has nothing to do
with OpenMP, isn't a gimplifier patch nor has anything to do with SPARC, I
can't approve it.
--
--- Comment #1 from hpa at zytor dot com 2009-12-07 18:32 ---
For what it's worth, gcc 3.4.6 generates a clear on the output register, and
therefore complies with the written ABI.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324
--- Comment #4 from meissner at linux dot vnet dot ibm dot com 2009-12-07
18:37 ---
Subject: Re: October 23rd change to tree-ssa-pre.c breaks calculix on powerpc
with -ffast-math
On Sun, Dec 06, 2009 at 01:25:15PM -, irar at il dot ibm dot com wrote:
--- Comment #3 from
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-07 18:39 ---
(In reply to comment #1)
For what it's worth, gcc 3.4.6 generates a clear on the output register, and
therefore complies with the written ABI.
That is true. However, gcc 3.4.6 does:
[...@gnu-26 pr42324]$ cat
--- Comment #9 from dfranke at gcc dot gnu dot org 2009-12-07 18:40 ---
With the upcoming release of 4.5, I think it would be nice to fix/improve the
translation related bugs now, i.e. this, PR38573 and PR40489.
As I have no idea how to reproduce/check/whatever this kind of PR, could
--- Comment #95 from howarth at nitro dot med dot uc dot edu 2009-12-07
18:40 ---
(In reply to comment #94)
No, a quick look into MAINTAINERS could tell you that as this has nothing to
do
with OpenMP, isn't a gimplifier patch nor has anything to do with SPARC, I
can't approve it.
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-07 18:58 ---
Gcc 4.1/4.2 generate:
xorl%eax, %eax
testb %dil, %dil
setne %al
ret
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from viriketo at gmail dot com 2009-12-07 19:07 ---
I add that this happens also in native builds (host=build=target).
gcc 4.3.4's libtool did not trim -Bxxx out of the libmudflap linking command
(maybe because of a quite old libtool).
I wonder if the libstdc++ style of
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #4 from hjl dot tools at gmail dot com 2009-12-07 19:41 ---
We have 3 options:
1. Keep the psABI ASIS and fix gcc. But zero out upper 32bits of 64bits for
_Bool on stack doesn't make any sense.
2. Remove that paragraph in the psABI and keep gcc ASIS. It will make _Bool
Attached broken code causes gcc to crash after giving diagnostics.
Command line:
g++ testcase.ii (no switch is needed)
Tested versions:
trunk r155020 - crash
trunk r153685 - crash
4.4 r154975 - crash (with enabled checking)
trunk r154886 - OK (disabled checking)
4.4 r154724 - OK (disabled
--- Comment #1 from zsojka at seznam dot cz 2009-12-07 20:07 ---
Created an attachment (id=19251)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19251action=view)
reduced testcase
I came to this problem while reducing for different error - I can supply less
reduced testcase if
--- Comment #5 from rth at gcc dot gnu dot org 2009-12-07 20:31 ---
There appears to be a phase ordering problem.
We duplicate a block in create_block_for_threading, which leaves users
of various SSA names dangling waiting on a subsequent update_ssa.
Before we get to that update_ssa
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-07 20:36 ---
Probably a short testcase for the 450.soplex link failure.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from matt at use dot net 2009-12-07 20:40 ---
Pre-processed output attached. I'm having some trouble getting it to crash
consistently, but here is the valgrind output that might indicate the problem:
==26996== Conditional jump or move depends on uninitialised value(s)
1 - 100 of 139 matches
Mail list logo
