gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)
I noticed the following code
=== version 1:
templatetypename a_t, typename b_t
inline a_t append (a_t a, b_t const b) {
a.insert (a.end(), b.begin(), b.end());
return a;
}
=== version 2:
templatetypename a_t, typename b_t
inline void append (a_t
In version 1, the return type is a_t, so a class construction is
required there (the caller will then destruct the returned object).
Construction and destruction can have side effects, so the compiler
would not drop them. For the following code,
templatetypename a_t, typename b_t
inline a_t
2007/9/26, Jim Wilson [EMAIL PROTECTED]:
On Tue, 2007-09-25 at 15:13 +0800, 吴曦 wrote:
propagate_one_insn), I don't understand why GCC fails the computation
of liveness if there is no optimization flag :-(.
There is probably something else happening with -O that is recomputing
some liveness
Hello,
maybe this is the better list to post the problem (see below).
Regards
Ralf
On Wednesday, 26. September 2007 18:23:34 Ralf Lübben wrote:
Ok,
the problems seems to be the pow() function. If I use instead the function
gsl_pow_int(double x, int n) from the gsl library the performance on
Richard Guenther wrote:
On 9/26/07, Ralf Lübben [EMAIL PROTECTED] wrote:
Hello,
maybe this is the better list to post the problem (see below).
This is off-topic here, gcc-help would be a more appropriate list.
True, but it appears to be a glibc problem, rather than one which can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I require help with some work i've been doing lately on gcc (4.2.1
tree). I have managed to put some code in.
Now, for function compilation, i require to invoke the i386 (as of
now) backend multiple times and with different switches; one time
On Wed, 2007-09-26 at 23:35 +0800, 吴曦 wrote:
Thanks, it's the problem of pass_stack_adjustments.
pass_stack_adjustments isn't in gcc-4.2.x; it is only on mainline. But
the flow stuff you are using isn't on mainline anymore since the
dataflow merge. Maybe you are using a month or two old
V. Karthik Kumar [EMAIL PROTECTED] writes:
I require help with some work i've been doing lately on gcc (4.2.1
tree). I have managed to put some code in.
Now, for function compilation, i require to invoke the i386 (as of
now) backend multiple times and with different switches; one time with
Hello,
The getter/setter for version in Object.M gets/takes an int, and they
eventually get/set the version field in struct objc_class. This
field is declared as a long in objc/objc.h.
I'm asking because I think this was causing a crash in GNUMail on 64-bit
systems. More detail:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thank you for a quick reply! :)
I was to do dynamic cpu dispatching code (which could also benefit
autovectorization). I'm checking out the trunk now.
I've already implemented an userland library to do cpu detection, and
the initialization hook goes
On 9/26/07, Jose Quinteiro [EMAIL PROTECTED] wrote:
Hello,
The getter/setter for version in Object.M gets/takes an int, and they
eventually get/set the version field in struct objc_class. This
field is declared as a long in objc/objc.h.
Why? Any change here will change the ABI so it
On Sep 11, 2007, Mark Mitchell [EMAIL PROTECTED] wrote:
That's a possibility, but I don't want to commit at this point. We can
have a look at it when you submit it and decide. However, in general,
introducing churn for the sake of a feature that will be off by default
isn't something that I
Please forgive me if I'm being dense, I'm very new to Objective-C.
The problem was that a class in GNUMail (PGPController) implemented a
method thusly:
- (NSString *) version
{
return @v0.9.1;
}
That method is declared in the GNUMailBundle protocol. GNUMail would
segfault when the
I wrote a simple test program that works just fine on my 64 bit system.
The problem must lie somewhere in the GNUStep libraries. Sorry about
the waste of bandwidth.
Thanks,
Jose.
Jose Quinteiro wrote:
Please forgive me if I'm being dense, I'm very new to Objective-C.
The problem was that a
Right, page 211 of the C++ standard (2003) explains when copy-ctor and
dtor are allowed to be optimized away. But the two circumstances are
both like this:
A is constructed; A is copy-constructed to B; A is destructed
Here A is a temporary object in some sense, and the standard allows
for directly
--- Comment #5 from anlauf at gmx dot de 2007-09-26 07:10 ---
(In reply to comment #4)
I found backups of other gfortran versions:
Working:
GNU Fortran (GCC) 4.3.0 20070420 (experimental)
Failing:
GNU Fortran (GCC) 4.3.0 20070805 (experimental)
So it's a regression.
--
anlauf at
--- Comment #6 from dominiq at lps dot ens dot fr 2007-09-26 07:45 ---
Failing:
GNU Fortran (GCC) 4.3.0 20070805 (experimental)
Did you try a more recent version? I don't see the problem with
Target: powerpc-apple-darwin8
gcc version 4.3.0 20070925 (experimental) (GCC) - revision
--- Comment #7 from burnus at gcc dot gnu dot org 2007-09-26 07:53 ---
I found backups of other gfortran versions:
More tests:
Works: 2007-07-23-r126835
Fails: 2007-07-25-r126902
This probably caused by:
http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00745.html
r126885 | pault | 2007-07-24
--- Comment #8 from dominiq at lps dot ens dot fr 2007-09-26 08:10 ---
Now I get a bus error, but I have to use:
gfc -m64 -g pr33554.f90 -O0
with
gfc -m64 -g pr33554.f90 -fbounds-check -O0
the bus error disappear.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33554
--- Comment #2 from ubizjak at gmail dot com 2007-09-26 08:53 ---
The testcase from comment #1 is fixed:
test_c:
subl$16, %esp
movl24(%esp), %eax
mull20(%esp)
movl%eax, 8(%esp)
movl%edx, 12(%esp)
addl$16, %esp
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-26 08:59 ---
They are included as far as I can tell:
@item -fstack-protector
Emit extra code to check for buffer overflows, such as stack smashing
attacks. This is done by adding a guard variable to functions with
vulnerable
--- Comment #29 from belyshev at depni dot sinp dot msu dot ru 2007-09-26
09:31 ---
Another testcase:
/* { dg-do run } */
/* { dg-options -O1 --param max-aliased-vops=0 } */
struct T
{
int a, b;
} t;
__attribute__((noinline)) struct T *f (struct T *p)
{
struct T *q =
Reduced from 197.parser which failed with -O1:
/* { dg-do run } */
/* { dg-options -O1 --param max-aliased-vops=0 } */
struct T
{
int a, b;
} t;
__attribute__((noinline)) struct T *f (struct T *p)
{
struct T *q = __builtin_malloc (sizeof (struct T));
*q = *p;
return q;
}
int main
--- Comment #30 from belyshev at depni dot sinp dot msu dot ru 2007-09-26
09:46 ---
(In reply to comment #29)
Another testcase:
Ignore this one, I filed it as a separate report, see bug 33560
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-26 09:57 ---
Confirmed. I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-26 09:58 ---
get_use_of_stmt_lhs happily skips over calls.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
I have had a bug report from people who tested my gfortran binaries for
mingw-w64 that the float variants of math functions aren't working properly.
The proper report that was sent to me has this example:
C:\gfortran\test\single_bugtype table.f90
program table
real x
integer i
write(*,*) '
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #31 from rguenth at gcc dot gnu dot org 2007-09-26 11:55
---
Subject: Bug 30375
Author: rguenth
Date: Wed Sep 26 11:55:17 2007
New Revision: 128810
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128810
Log:
2007-09-26 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-26 11:55 ---
Subject: Bug 33560
Author: rguenth
Date: Wed Sep 26 11:55:17 2007
New Revision: 128810
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128810
Log:
2007-09-26 Richard Guenther [EMAIL PROTECTED]
PR
Author: rguenth
Date: Wed Sep 26 11:55:17 2007
New Revision: 128810
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128810
Log:
2007-09-26 Richard Guenther [EMAIL PROTECTED]
PR tree-optimization/30375
PR tree-optimization/33560
...
* gcc.dg/tree-ssa/complex-4.c:
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-26 11:56 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #32 from rguenth at gcc dot gnu dot org 2007-09-26 11:56
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-09-26 11:57 ---
This should now be fixed. Waiting for next results from the spec-tester to
verify.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33383
--- Comment #5 from jozef dot behran at krs dot sk 2007-09-26 11:58 ---
Section 5.6.2.1, paragraph 2 says E1[E2] is equivalent to *((E1)+(E2)). This
means if we have typedef int THostAddr[8] then the declaration THostAddr
*Host declares Host to be a pointer to 8-item arrays of integers,
--- Comment #1 from ubizjak at gmail dot com 2007-09-26 12:00 ---
(In reply to comment #0)
(Notice the extra lines between the call to _sinf and the leave.)
-O2 will remove these lines (as well as the lines above _sinf):
BTW: Could you check if _sinf returns values in %xmm0 reg?
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-26 12:03 ---
There is nothing wrong with the extra asm instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33561
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
CC||belyshev at depni dot sinp
|
--- Comment #6 from jozef dot behran at krs dot sk 2007-09-26 12:06 ---
Neither C nor C++ have qualified array types, only arrays of qualified
element types, but C++ has different rules from C regarding conversions
involving qualifiers, which allow some conversions (involving
--- Comment #6 from jsm28 at gcc dot gnu dot org 2007-09-26 12:09 ---
When you apply const to array of int, the resulting type is array of const
int not const array of int; that's how type qualifiers and arrays interact
in C, there is no such thing as a qualified array type. array of
--- Comment #7 from jozef dot behran at krs dot sk 2007-09-26 12:18 ---
Neither C nor C++ have qualified array types, only arrays of qualified
element types, but C++ has different rules from C regarding conversions
involving qualifiers, which allow some conversions (involving
--- Comment #15 from jsm28 at gcc dot gnu dot org 2007-09-26 12:32 ---
Subject: Bug 25309
Author: jsm28
Date: Wed Sep 26 12:32:27 2007
New Revision: 128811
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128811
Log:
PR c/25309
* c-common.c (complete_array_type):
--- Comment #7 from jozef dot behran at krs dot sk 2007-09-26 12:33 ---
Hm, I must apologize for argumenting about wrong point of this issue. Now I can
see why other sometimes say think before you type :)
The problem here is not whether applying const to array of int makes const
array
--- Comment #8 from joseph at codesourcery dot com 2007-09-26 12:38 ---
Subject: Re: Warning when passing a pointer to a const array
to a function that expects a pointer to a non-cast one
On Wed, 26 Sep 2007, jozef dot behran at krs dot sk wrote:
Could you give me reference in the
For gcc.dg/torture
/* { dg-do run } */
/* { dg-options --param max-aliased-vops=0 } */
struct T
{
int a, b;
} t, q;
int main (void)
{
struct T *p;
t.a = 1;
t.b = 2;
q = t;
t.a = 3;
if (q.a != 1)
__builtin_abort ();
return 0;
}
the logic behind
--- Comment #9 from joseph at codesourcery dot com 2007-09-26 12:42 ---
Subject: Re: Warning when passing a pointer to a const array
to a function that expects a pointer to a non-cast one
On Wed, 26 Sep 2007, jozef dot behran at krs dot sk wrote:
And another point: Whether C/C++
--- Comment #3 from ktietz at gcc dot gnu dot org 2007-09-26 12:52 ---
This doesn't seems to be an error in gcc. The w64 crt currently does not
implement some math functions proper. May somebody can assist to port the
assemble coded function for this target.
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-26 13:26 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
This is a duplicate of bug 1601, which I can't reopen.
This bug is still present on 4.1.2-13 (RedHat, 20070626) and 3.4.6-3 (RedHat
20060404). Looking at the produced assembly, f2 and fun are both produced; the
assembly should only produce fun and inline both f1 and f2. I havn't tested it
on
--- Comment #11 from amodra at bigpond dot net dot au 2007-09-26 14:27
---
We first choose a section here, when decl readonly_flag is false:
#0 get_section (name=0x4cca824 .data._ZSt15system_category, flags=512,
decl=0x4e44000) at /src/gcc-current/gcc/varasm.c:527
#1
--- Comment #1 from manu at gcc dot gnu dot org 2007-09-26 14:30 ---
This is a known problem. There is a patch here:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01735.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-26 14:47
---
Sorry for the wrong report, and thanks.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-26 14:49 ---
Fixed in 4.3.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-26 15:32 ---
Subject: Bug 33563
Author: rguenth
Date: Wed Sep 26 15:31:50 2007
New Revision: 128815
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128815
Log:
2007-09-26 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-26 15:32 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from michael dot a dot richmond at nasa dot gov 2007-09-26
15:36 ---
An analogous message appears when I compile the program listed below with the
flag -fdefault-real-8:
qq.f90:3.15:
rft = TRANSFER('abcd', 0.0)
1
Warning: Intrinsic TRANSFER at (1) has
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-09-26 16:40 ---
Again this is invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
with -O2 -Wall:
void f (int m, int n)
{
int j;
for (j = m; j m + 10 j n; j ++)
do_something (j);
}
t.c:2: warning: assuming signed overflow does not occur when assuming that (X +
c) = X is always true
(also note useless line number)
--
Summary: [4.3 regression]
--- Comment #5 from daney at gcc dot gnu dot org 2007-09-26 16:45 ---
Subject: Bug 33479
Author: daney
Date: Wed Sep 26 16:45:39 2007
New Revision: 128821
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128821
Log:
2007-09-26 David Daney [EMAIL PROTECTED]
PR
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-26 17:17
---
(In reply to comment #0)
The only problem is that this patch rejects (with -std=gnu/legacy) a
user-implemented .XOR., which is valid Fortran 90/95/2003.
I suggest we make it conditional on a -fxor-operator,
--- Comment #3 from bkoz at gcc dot gnu dot org 2007-09-26 17:27 ---
OK. Now there are tests for all of algorithms for defaultconstructable. As per
20.1, this is not required for template arguments unless the standard
explicitly notes it.
--- Comment #8 from hjl at lucon dot org 2007-09-26 17:39 ---
Revision 128810:
http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00806.html
doesn't fix 400.perlbench on Linux/x86-64. I am testing revision 128815:
http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00812.html
--
--- Comment #1 from ian at airs dot com 2007-09-26 17:54 ---
Created an attachment (id=14253)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14253action=view)
Patch
I'm testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33565
version 4.3.0 20070926 (experimental) (GCC)
--
Summary: fortran : wrong rank of derived type parameters array
components
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #5 from pcarlini at suse dot de 2007-09-26 18:24 ---
Seems due to a trivial thinko in the changes for 27668, 27962, etc..
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from aldot at gcc dot gnu dot org 2007-09-26 18:43 ---
For the fortran frontend, It seems that i have this patch (must be relatively
old; undetermined status, ATM).
Index: gcc/fortran/Make-lang.in
===
---
--- Comment #5 from aldot at gcc dot gnu dot org 2007-09-26 18:53 ---
(In reply to comment #4)
For the fortran frontend, It seems that i have this patch (must be relatively
old; undetermined status, ATM).
Scratch that. Testing a working version that i will attach when it passes the
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-26 19:04 ---
* gcc.dg/tree-ssa/complex-4.c: XFAIL.
is a regression then because the testcase was added back in 2006-02-18 (by me).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-26 19:04 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-09-26 19:06 ---
Hmm, __extension__ is lost with templates, see PR 21385.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33500
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33501
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33506
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33545
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.0/4.1/4.2/4.3 Regression]|[4.1/4.2/4.3 Regression]
|Rejects typedef
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.0/4.1/4.2/4.3 regression]|[4.1/4.2/4.3 regression] C++
|C++ arguments passed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33554
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30919
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25672
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.3 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-09-26 19:11 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30663
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32139
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.0/4.1 Regression]|[4.2 Regression] Incorrect
|Incorrect type
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32891
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31174
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone|---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33131
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.1 regression] bitfield |[4.1/4.2/4.3 regression]
|constants with multiple
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33391
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.2 regression]|[4.2/4.3 regression]
|fvisibility=hidden without
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33434
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33421
--- Comment #4 from bangerth at dealii dot org 2007-09-26 19:41 ---
(In reply to comment #3)
OK. Now there are tests for all of algorithms for defaultconstructable. As per
20.1, this is not required for template arguments unless the standard
explicitly notes it.
Yay, thanks for
--- Comment #9 from hjl at lucon dot org 2007-09-26 19:57 ---
(In reply to comment #8)
Revision 128810:
http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00806.html
doesn't fix 400.perlbench on Linux/x86-64. I am testing revision 128815:
--- Comment #6 from bkoz at gcc dot gnu dot org 2007-09-26 20:43 ---
the real question for me is why #pragma GCC system header doesn't work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33485
1 - 100 of 112 matches
Mail list logo
