--- Comment #7 from kkylheku at gmail dot com 2008-02-23 08:03 ---
Both my patches apply even if Carlos' patches are removed. The crti.o problem
remains.
What's happening is that xgcc actually searches for the crti.o module, and then
passes the full path to crti.o down to collect2 if
--- Comment #8 from kkylheku at gmail dot com 2008-02-23 08:54 ---
I ended up doing the symlink trick because quite a bit of the sysroot material
is needed to build everything, like libstdc++. It worked like a charm. And so
now I have a compiler with search paths only in its own tree.
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2008-02-23 10:44
---
(In reply to comment #11)
As a MinGW administrator, I am dismayed that you consider this
__USE_MINGW_ACCESS kludge as a solution to this bug; I would like this
particularly nasty kludge to go away, from the
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-02-23 11:07
---
(In reply to comment #0)
although it should be removed from any place.
It's not used in any other place.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #2 from nightstrike at gmail dot com 2008-02-23 11:12 ---
Here's an even better way to do it:
Index: configure.ac
===
--- configure.ac(revision 132554)
+++ configure.ac(working copy)
@@
--- Comment #2 from _deepfire at feelingofgreen dot ru 2008-02-23 11:56
---
I think this is correct CPP behavior.
it only evaluates one level of _ .
Interesting, reading the CPP manual[1] gives me an impression that there is
at least intent to support nested expansions:
You might
Also reported as http://bugs.debian.org/466613
An ICE appeared twice while trying to build webkit on s390. The first file
fails to build with -O2 but is OK with -O1, for the second file it is just the
opposite.
$ gcc -v
Using built-in specs.
Target: s390-linux-gnu
Configured with:
--- Comment #1 from joss at debian dot org 2008-02-23 12:52 ---
Created an attachment (id=15212)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15212action=view)
First test case (fails with -O2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35311
--- Comment #2 from joss at debian dot org 2008-02-23 12:52 ---
Created an attachment (id=15213)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15213action=view)
Second test case (fails with -O1)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35311
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-02-23 12:57
---
Hi,
as I added to the gcc-patches thread, I think GCC is valid to optimize stack
alignment on the reduced testcase and it is precisely what is supposed to be
done by the code Michael disabled. ABI is not strict
--- Comment #3 from joseph at codesourcery dot com 2008-02-23 13:47 ---
Subject: Re: Function macro nesting depth appears
to be uncomfortably limited.
I think GCC aims to implement the version of the rescanning rules
described in X3J11/86-196, as posted in Dave Prosser's message
The following expression violates the syntax but is not diagnosed and rejected
with -pedantic-errors, for C90 or C99:
extern int x;
#if #foo
#endif
--
Summary: Invalid syntax in PP expressions not diagnosed in strict
mode
Product: gcc
The following obeys the syntax, semantics and constraints of C99, but is
rejected with -pedantic-errors
extern int x;
#if 0 ? 2,3 : 2
#endif
--
Summary: Valid pp-expression rejected in C99 mode
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
--- Comment #4 from neil at gcc dot gnu dot org 2008-02-23 14:03 ---
To be honest this isn't even a disputed case from what I can see. I doubt you
can find a serious C implementation (i.e. tcc etc. doesn't count) that will do
what you expect.
--
neil at gcc dot gnu dot org changed:
--- Comment #3 from rwild at gcc dot gnu dot org 2008-02-23 14:04 ---
Subject: Bug 31569
Author: rwild
Date: Sat Feb 23 14:04:12 2008
New Revision: 132570
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132570
Log:
gcc/:
PR documentation/31569
* doc/install.texi2html: Use makeinfo
--- Comment #11 from matz at gcc dot gnu dot org 2008-02-23 14:08 ---
FWIW, Torbjorn: I agree with Honza that it would be very good to see the
original testcase that segfaults on darwin. The testcases here are all of
the type where it's questionable if the behaviour is really wrong.
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2008-02-23 14:28
---
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00198.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from uros at gcc dot gnu dot org 2008-02-23 15:24 ---
Subject: Bug 34256
Author: uros
Date: Sat Feb 23 15:24:02 2008
New Revision: 132572
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132572
Log:
PR target/22076
PR target/34256
*
--- Comment #9 from uros at gcc dot gnu dot org 2008-02-23 15:24 ---
Subject: Bug 22076
Author: uros
Date: Sat Feb 23 15:24:02 2008
New Revision: 132572
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132572
Log:
PR target/22076
PR target/34256
*
--- Comment #10 from ubizjak at gmail dot com 2008-02-23 15:33 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #12 from matz at gcc dot gnu dot org 2008-02-23 16:15 ---
In fact I'm now convinced of the opposite, the testcases here don't show any
problem. The non-alignment of RSP at function entry in these cases is not a
bug. See the discussions at
--- Comment #1 from s__nakayama at infoseek dot jp 2008-02-23 16:20 ---
This is a duplicate of #13399.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35275
--- Comment #5 from kcwu at csie dot org 2008-02-23 16:21 ---
this issue is resolved in gcc 4.3 20080221 snapshot.
$ time gcc43 -O3 -c f5.c -Wall
user0m0.418s
And the memory usage is less than 10 MB.
--
kcwu at csie dot org changed:
What|Removed
--- Comment #38 from jvdelisle at gcc dot gnu dot org 2008-02-23 16:40
---
Janne, do you want to bring your patch from comment #35 up to date and submit
for approval to the lists?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-02-23 16:48
---
Status: local experimental trunk
Front-end has most if not all keywords compiling.
DECIMAL= is working all the way through to runtime.
WAIT compiles and executes a stub in the runtime with a new
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 17:08 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-23 17:08 ---
Subject: Bug 35027
Author: pinskia
Date: Sat Feb 23 17:08:12 2008
New Revision: 132574
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132574
Log:
2008-02-23 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #13 from tege-gcc at swox dot com 2008-02-23 17:09 ---
Created an attachment (id=15214)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15214action=view)
This is a minimized version of the original faling code.
I understand the reasoning about local calls. The problem
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 17:16 ---
I think this is a dup of bug 22168.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35312
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pcarlini at suse dot de 2008-02-23 17:00 ---
*** This bug has been marked as a duplicate of 13399 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2008-02-23 17:00 ---
*** Bug 35275 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
The following valid testcase triggers an ICE since GCC 4.2.0 when compiled
with -fmudflap:
#includesetjmp.h
jmp_buf buf;
void foo(volatile char* p)
{
if (__builtin_setjmp(buf))
*p;
}
bug.c: In function 'foo':
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35314
--- Comment #9 from drow at gcc dot gnu dot org 2008-02-23 17:43 ---
Subject: Re: References to original ${prefix} paths in
relocated toolchain and /lib and /usr/lib search paths appear in
cross toolchain.
On Sat, Feb 23, 2008 at 08:03:34AM -, kkylheku at gmail dot
The following valid code snippet triggers an ICE on mainline:
=
typedef union { int i; } U __attribute__((transparent_union));
static void foo(U) {}
static void foo(int) {}
void bar()
{
foo(0);
}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35315
--- Comment #10 from drow at gcc dot gnu dot org 2008-02-23 17:45 ---
Subject: Re: References to original ${prefix} paths in
relocated toolchain and /lib and /usr/lib search paths appear in
cross toolchain.
On Sat, Feb 23, 2008 at 08:54:56AM -, kkylheku at gmail
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 17:59 ---
Subject: Bug 33512
Author: pinskia
Date: Sat Feb 23 17:58:48 2008
New Revision: 132575
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132575
Log:
2008-02-23 Andrew Pinski [EMAIL PROTECTED]
PR
The following valid code snippet triggers an ICE since GCC 3.1:
struct A
{
void operator delete[] (void*, ...);
};
bug.cc:2: internal compiler error: Segmentation fault
Please submit a full bug report,
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35317
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-23 18:02 ---
The RTL level has been fixed. The tree level needs fixing still but I am not
working on that.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from hubicka at gcc dot gnu dot org 2008-02-23 18:05
---
I see. It is quite pity that Darwin's dynamic linker insist on the alignment.
I guess it would be worthwhile to try to tell GCC to optimize those calls as
local: calling overhead of recursive functions is quite
The following valid code snippet triggers an ICE on mainline and 4.3 branch
when compiled with -O:
void foo()
{
double x = 4, y;
__asm__ volatile ( : =r,r (x), =r,r (y) : %0,0 (x), m,r (8));
}
bug.c: In
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35318
--- Comment #15 from hubicka at gcc dot gnu dot org 2008-02-23 18:10
---
Still, can I ask how does the PLT entry of Darwin look like? It seems a bit
weird that recursive call that should not trigger lazy binding will get into
code relying on the alignment.
Or are some kind of aliases
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 18:12 ---
this works on:
Target: i386-apple-darwin8.11.1
Configured with: /Users/apinski/src/local/gcc/configure
--prefix=/Users/apinski/local-gcc --disable-multilib
Thread model: posix
gcc version 4.4.0 20080223
The following valid code snippet triggers an ICE on mainline and 4.3 branch
when compiled with -O:
===
void foo()
{
throw 0r;
}
===
bug.cc: In function 'void foo()':
bug.cc:3: internal compiler error: in write_type, at cp/mangle.c:1695
Please submit a full bug report,
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35319
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-02-23 18:17
---
The code also ICEs without -O.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35319
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35316
The following valid code snippet triggers an ICE since GCC 4.2.0:
==
templateint struct A
{
int i : 2;
void foo()
{
typeof(i) j;
}
};
==
bug.cc: In member function 'void Aanonymous ::foo()':
bug.cc:7: internal compiler error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35320
--- Comment #16 from tege-gcc at swox dot com 2008-02-23 18:27 ---
I don't know how a PLT entry looks like. They use the object format
macho, of which I know nothing.
Note that the new testcase does not have any recursive calls.
--
The following invalid code snippet triggers an ICE since GCC 4.0.0:
=
struct A
{
A operator[] (int);
};
struct B
{
A a;
};
void foo()
{
__builtin_offsetof(B, a[0]);
}
=
bug.cc: In function 'void foo()':
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35321
--- Comment #48 from fxcoudert at gcc dot gnu dot org 2008-02-23 18:42
---
Subject: Bug 25477
Author: fxcoudert
Date: Sat Feb 23 18:42:04 2008
New Revision: 132576
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132576
Log:
PR target/25477
*
The following invalid code snippet triggers an ICE since GCC 4.2.0:
=
_Pragma(GCC dependency)
=
bug.c:1: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
A correct error message is
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35322
--- Comment #39 from jb at gcc dot gnu dot org 2008-02-23 18:46 ---
(In reply to comment #38)
Janne, do you want to bring your patch from comment #35 up to date and submit
for approval to the lists?
Sure, I hope to get it done withing a few days; assigning to myself.
--
jb at gcc
The following invalid code snippet triggers an ICE on mainline and 4.3 branch:
=
void foo(int);
void bar()
{
foo(1r);
}
=
bug.cc: In function 'void bar()':
bug.cc:5: internal compiler error: in arg_assoc_type, at
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35323
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 18:51 ---
The preprocessor is the one that is crashing and the preprocessor in the case
of the #pragma is the one that errors out.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
The following invalid code snippet triggers an ICE since GCC 3.1:
==
typedef void (func_type)();
struct A
{
friend func_type f : 2;
};
==
bug.cc:5: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
The following invalid code snippet is accepted since GCC 3.4.0:
=
templateint struct A {};
templatetypename struct B : Asizeof(0=0) {};
=
Before the code was correctly rejected, although the error message
couldn't
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35324
--- Comment #49 from fxcoudert at gcc dot gnu dot org 2008-02-23 19:00
---
To fix this completely, a little bit more work is required to check what should
be done for nanl(), which is not handled by current patch. (I don't have time
to look into it.) For more information, see
The following invalid code snippet triggers an ICE on mainline and 4.3 branch:
templateint struct A {};
templatetypename struct B : Asizeof(0=0r) {};
templatetypename struct C : Asizeof(0=0r) {};
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35325
The following invalid code snippet triggers an ICE since GCC 4.2.0:
%:%:;
bug.cc:1: error: stray '%:%:' in program
bug.cc:1: internal compiler error: vector VEC(fs_p,base) index domain
The following invalid code snippet triggers an ICE on mainline and 4.3 branch:
struct A
{
A(int)();
};
templateint void foo(bool b, A a) { b ? a : 0; }
bug.cc:3: error: 'A' declared as
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35327
The following invalid code snippet triggers an ICE since GCC 4.2.0 when
compiled with -fopenmp:
struct A
{
~A()();
};
void foo()
{
A a;
#pragma omp parallel firstprivate(a)
;
}
The following invalid code snippet triggers an ICE since GCC 4.2.0:
#pragma implementation
#pragma interface
templatevoid struct A
{
A() {}
};
bug.cc:4: error: 'void' is not a valid type
The following invalid code snippet triggers an ICE since GCC 3.1.1:
#pragma weak int = foo
built-in:0: error: weak declaration of 'int' must be public
bug.c:1: internal compiler error: in
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35326
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35330
The following invalid code snippet triggers an ICE on mainline and 4.3 branch:
templatetypename... struct A;
templatetypename...T struct AT*
{
friend void foo();
};
bug.cc:3: error:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35331
Broken diagnostics are issued for the following invalid code snippet since
GCC 3.0:
void foo(double x)
{
__builtin_isgreater(x, 0.0)();
__builtin_isless(x, 0.0)();
__builtin_isunordered(x, 0.0)();
}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35332
A broken diagnostic is issued for the following invalid code snippet since
GCC 4.0.0:
void foo(__complex__ double x)
{
__builtin_conj(x)();
}
bug.cc: In function 'void foo(double
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35333
A broken diagnostic is issued for the following invalid code snippet since
at least GCC 2.95.3:
void foo(__complex__ unsigned int i)
{
((__complex__ int)i)();
}
bug.cc: In function 'void
A broken diagnostic is issued for the following invalid code snippet since
GCC 4.0.0:
struct A {};
void foo()
{
A a;
a = ({ { 1; } });
}
bug.cc: In function 'void foo()':
bug.cc:6:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35335
A broken diagnostic is issued for the following invalid code snippet since
at least GCC 2.95.3:
struct A
{
int i : 2;
};
void foo(bool b)
{
A a;
(a.i || b)();
}
bug.cc: In function
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35329
--- Comment #1 from segher at kernel dot crashing dot org 2008-02-23 19:51
---
(In reply to comment #0)
The following rule is not handled by GCC
(a x) || (a y) === a (x | y)
Perhaps that is because those two expressions aren't equivalent?
But, confirmed, assuming you meant to
Broken diagnostics are issued for the following invalid code snippet
on mainline and 4.3 branch:
int i = 1r;
bool b = !1r;
bug.cc:1: error: cannot convert '#'fixed_point_type' not supported
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35338
--- Comment #1 from segher at kernel dot crashing dot org 2008-02-23 19:57
---
Not equivalent in the presence of overflow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35307
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 20:00 ---
(In reply to comment #1)
Not equivalent in the presence of overflow.
You mean defined overflow :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #30 from fxcoudert at gcc dot gnu dot org 2008-02-23 20:10
---
On powerpc-apple-darwin9.2, gfortran.dg/large_real_kind_form_io_2.f90 fails for
that reason:
$ cat a.f90
real(kind=16) :: a,b
character(len=180) :: tmp
b =
--- Comment #31 from fxcoudert at gcc dot gnu dot org 2008-02-23 20:11
---
Subject: Bug 24685
Author: fxcoudert
Date: Sat Feb 23 20:10:29 2008
New Revision: 132577
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132577
Log:
PR libfortran/24685
*
Hi All,
I have a very subtly problem when linking a shared object that includes the
gcc-runtime to support c++ exceptions, type info, ...
The problem is that the following crashes:
try {
throw cCoreException();
}
// catch(const
--- Comment #7 from galtgendo at o2 dot pl 2008-02-23 20:17 ---
Well, shortly after I reported this bug hardware got upgraded (it was
Christmas).
Now it's 512MB and gcc 4.2.3.
It still fails.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34572
A broken diagnostic is issued for the following invalid code snippet since
GCC 4.2.0:
struct A {};
void foo()
{
#pragma omp parallel firstprivate(A)
;
}
bug.cc: In function 'void
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-02-23 20:22 ---
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
CC|
1 - 100 of 123 matches
Mail list logo
