--- Comment #5 from Thomas dot Koenig at online dot de 2007-03-09 20:13
---
Subject: Re: [4.3/4.2 regression] Runtime error on legal code using RECL
I believe I have a fix. I am testing now. We were not initializing a few
things when we have a record length given.
Index: io
--- Comment #11 from Thomas dot Koenig at online dot de 2007-02-28 23:13
---
Subject: Re: a ** exp fails for integer exponents if exp is -huge()-1
(endless loop)
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-02-28 22:39
---
Yes declare this as undefined code
--- Comment #3 from Thomas dot Koenig at online dot de 2007-01-13 08:42
---
Subject: Re: Strange syntax error with high-value character
jvdelisle at gcc dot gnu dot org wrote:
Turns out that the character 254 which is Hex FE is also the 2's complement
representation of -2 which
--- Comment #4 from Thomas dot Koenig at online dot de 2007-01-13 11:51
---
Subject: Re: Strange syntax error with high-value character
jvdelisle at gcc dot gnu dot org wrote:
Turns out that the character 254 which is Hex FE is also the 2's complement
representation of -2 which
--- Comment #21 from Thomas dot Koenig at online dot de 2006-05-27 20:24
---
Subject: Re: [meta-bug] g77 features lacking in gfortran
sgk at troutmask dot apl dot washington dot edu wrote:
27757 does not belong in this meta-bug. It is actually
a regression with respect
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-08
07:36 ---
Subject: Re: Function entries and entries with alternate returns not
implemented
You wrote (in bugzilla):
- We tried out the designed successor and found it very immature. In fact
it is not even
dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20783
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-06
14:21 ---
This goes away when --disable-checking is specified for 4.0
and 4.1.
Closing as invalid.
--
What|Removed |Added
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-05
07:17 ---
This is fixed with
http://gcc.gnu.org/bugzilla/attachment.cgi?id=8525action=view
(an attachment to PR 20661).
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20744
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu
--
What|Removed |Added
Keywords||wrong-code
Known to fail||4.0.0 4.1.0
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-01
11:45 ---
No write or print statement is necessary:
$ cat assign.f90
program main
assign 1000 to i
1000 format (A)
end
$ gfortran assign.f90
$ gfortran -fdump-parse-tree assign.f90
In file
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-01
13:34 ---
This patch fixes the test case. It also includes my
EOR patch for advancing I/O.
This is regression-tested on mainline. I'll submit a proper
patch when I have finished regression-testing it on 4.0
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-29
15:11 ---
I'll try and have a look.
Hopefully, my copyright papers that I sent off on 2005-03-19 will
come through sometime soon, because the end-of-record patch
at http://gcc.gnu.org/ml/gcc-patches/2005-03
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20618
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-24
14:29 ---
Actually, implementing this would be a bit harder
than I thought.
It seems that the variable expression is evaluated
at runtime, so you can do things like
$ cat v-fmt2.f
program main
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http
--
What|Removed |Added
OtherBugsDependingO||19292
nThis||
Severity|normal
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-19
13:20 ---
(In reply to comment #8)
Due to general gfortran lameness only contained functions are ever inlined.
Top-level functions are never inlined.
Why?
I've worked with a Fortrtran 77 compiler (vor
operations in tailcall
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20517
--
What|Removed |Added
Keywords||missed-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20517
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-17
13:41 ---
(In reply to comment #3)
I cannot remember the rules but -0.0 * 0.0 could be -0.0 (and not 0.0),
someone needs to help me
here.
I'm trying to see what input could apply to, but I can't think of one
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-17
14:40 ---
(In reply to comment #2)
The patches suggested in comment #2 under bug 20156 fixes bugs 20156, 20125
and
20471 on the macintosh and does not seem to cause any new problems.
Can you submit
--
What|Removed |Added
BugsThisDependsOn||19106
AssignedTo|unassigned at gcc dot gnu |Thomas dot Koenig at online
|dot org
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-13
21:10 ---
I believe this is also fixed with
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00729.html
Copyright papers, where are you? :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20092
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-13
22:11 ---
Patch here:
http://gcc.gnu.org/ml/fortran/2005-03/msg00232.html
--
What|Removed |Added
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20437
dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20438
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-12
09:45 ---
(In reply to comment #4)
(In reply to comment #3)
- Why the casts to double?
Because that is required by the C standard.
Isn't that covered by the as-if rule? I'm fairly
sure the cast
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-12
22:52 ---
The 0 as data pointer is a signal to the library that it
needs to fill out the properties of the array, because
the front end can't determine it.
See
http://gcc.gnu.org/ml/fortran/2005-03/msg00199
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-12
23:13 ---
(In reply to comment #6)
Well the real reason is creal/cimag returns double and not float.
Use crealf/cimagf instead.
You're right, of course. Doing that gets me
bb 0:
foo (cr, ci);
return cr
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20432
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11
21:21 ---
My vote would go for fixing this, because of the NIST
testsuite failure.
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11
21:36 ---
(In reply to comment #1)
D.2395 * 0.0
Can trap if D.2395 is a non quiet NAN.
D.2395 gets its value from
D.2395 = SR.23 / SR.24;
two lines earlier. Is there anything that would generate
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11
21:59 ---
There are two strange things here:
- Why the + 0. ?
- Why the casts to double?
--
What|Removed |Added
Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20434
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11
22:49 ---
- Why the casts to double?
Because that is required by the C standard.
Isn't that covered by the as-if rule? I'm fairly
sure the cast to double won't change the result of
the operator
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-09
15:13 ---
$ cat eoshift.f90
print *,eoshift((/1, 3/), 3)
end
$ gfortran eoshift.f90
$ ./a.out
Segmentation fault
This fails because the loop
for (n = 0; n len; n++)
{
memcpy (dest
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-09
16:01 ---
The complaint is a segfault at runtime when
you actually want to do anything with the
string whose length depends on a missing
optional argument. This isn't too bad (the
same thing happens if you
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-09
23:33 ---
This looks very much like a front end bug. The
along parameter gets the wrong value.
Look at this:
$ cat test_spread.f90
program test_spread
implicit none
integer, parameter :: N = 1000
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08
08:20 ---
Updated patch:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00729.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20131
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08
08:21 ---
Updated patch:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00729.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19568
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08
15:35 ---
Here's a somewhat reduced testcase that fails
for me on ia64-unknown-linux-gnu:
$ cat forall_5.f90
program evil_forall
implicit none
type t
logical valid
integer :: s
integer, dimension
in gfc_conv_array_initializer
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08
20:30 ---
On i686-pc-linux-gnu, forall_5.f90 does the following:
$ gfortran forall_5.f90
$ ./a.out
Fortran runtime error: Attempt to allocate a negative amount of memory.
$ gfortran -v
Using built-in specs
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-06
23:34 ---
Updated patch:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00566.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19568
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-06
23:34 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00566.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20131
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-04
10:47 ---
This is really _very_ inefficient, by a factor of 20.
Some test numbers:
$ g77 write-record.f
$ time ./a.out
real0m1.819s
user0m1.774s
sys 0m0.044s
$ gfortran write-record.f
$ time
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-03
20:27 ---
Same thing on i686:
$ gfortran write-many.f
$ time ./a.out
real0m5.576s
user0m5.508s
sys 0m0.038s
$ g77 write-many.f
$ time ./a.out
real0m3.252s
user0m3.185s
sys 0m0.041s
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20278
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-01
15:43 ---
(In reply to comment #14)
(In reply to comment #13)
(In reply to comment #11)
I get the same as I got above with the following version on x86:
GNU C version 4.0.0 20050225 (experimental) (i686-pc
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-01
21:07 ---
Andrew,
I'm sorry if I'm not making myself clear here.
The problem that I see is that, on ia64-unknown-linux-gnu and on
i386-pc-linux-gnu, with clean trees, I see code like
L2:;
D.2390 = 0.0 / SR
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-01
21:26 ---
(In reply to comment #18)
L2:;
D.2390 = 0.0 / SR.22;
D.2392 = SR.22 + D.2390 * 0.0;
c$real = (D.2371 + D.2372 * D.2390) / D.2392;
c$imag = (D.2372 - D.2371 * D.2390) / D.2392
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-28
20:55 ---
Comment #7 shows that there is still something to be done
for (br+I*bi)/a (with real br, bi, a). This could be
simplified to br/a + I*bi/a, which isn't happening.
Thomas
--
What
--
Bug 18902 depends on bug 19953, which changed state.
Bug 19953 Summary: Special-case real + complex arithmetic operation
(-ffast-math)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
What|Old Value |New Value
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-28
20:55 ---
What I meant was comment#8 *sigh*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-27
12:52 ---
Is this really fixed?
Look at this:
$ cat c-div.c
#include math.h
#include complex.h
int main()
{
float a;
complex float b,c;
foo(a,b);
c = b/a;
return creal(c) + cimag(c) 0
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-26
20:46 ---
Patch for the first bug here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01694.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20163
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-26
20:49 ---
Here is a reduced test case for the second error:
$ cat open-after-error.f
open(10,status=foo,err=100)
call abort
100 continue
open(10,status=scratch)
end
$ cat open-after
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
12:28 ---
I'll check later wether this is fixed with the proposed fix
for PR 19568 to be found at
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02295.html
Thomas
--
What|Removed
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
21:27 ---
No, this isn't fixed with the patch I referred to earlier.
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20131
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
22:54 ---
Add fflush(stdout); at the end of cio.c, and things work
as expected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
23:09 ---
This is two bugs.
The first bug can be reduced to
$ cat open-opt.f
open(unit=10,status=scratch )
end
$ gfortran open-opt.f
$ ./a.out
At line 1 of file open-opt.f
Fortran runtime error: Bad
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
23:29 ---
This has a pretty good chance of fixing it.
Proper testing, Changelog entry, ... tomorrow.
Index: string.c
===
RCS file: /cvsroot/gcc
--
What|Removed |Added
CC||Thomas dot Koenig at online
||dot de
http://gcc.gnu.org
of pointer array segfaults at runtime
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-18
10:42 ---
I think this is identical to PR 15332.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20037
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-17
09:42 ---
(In reply to comment #7)
Using Mathematica I get for
(10^20 + 10^12 I)/(1 - 10^-8) = 10^20 + 2 * 10^12 I
so really neither of them are mathematically correct.
The test case was (10^20-10^12*I)/(1
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-17
13:52 ---
Another datapoint - the fact that slarrb has problems
has been confirmed by a Lapack developer. A new version is
slated to appear as a patch soon. Hopefully, this will reduce
the potential hang
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-16
12:41 ---
I think I have identified the problem.
The hang itself is probably caused by a Lapack bug, because slarrb is
only fed 0. and NaN as arguments.
The reason why this is so is probably due to a problem
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-16
20:51 ---
Checking this on i686-unknown-linux-gnu, I find the same
result with flag_complex_method=2 as on ia-64. I am also
seeing the same result with logarithmic scaling (using frexp and
ldexp). Maybe I'm
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-15
10:29 ---
And in fact this only can happen with -funsafe-math-optimizations (or maybe
with -fno-trapping-
math because a+0.0 can trap.
Hmm...
if b is complex and has the value (0., signalling NaN
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
--
What|Removed |Added
OtherBugsDependingO||5900
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
--
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-15
20:14 ---
This does not happen on an Athlon-xp with -march=athlon-xp
-mfmath=sse. Might be target or 64-bit specific.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-14
12:25 ---
I can confirm that this is fixed in the 20050213 snapshot.
Both the reduced C test case and the original Fortran routine
don't segfault any more. Thanks to whoever fixed this :-)
I would suggest
for
flag_complex_method=2
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC
--
What|Removed |Added
OtherBugsDependingO||18902
nThis||
Keywords|
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-14
20:06 ---
Same thing for complex division, where the performance
penalty is probably also pretty severe:
$ cat c-div.c
#include math.h
#include complex.h
int main()
{
float a;
complex float b,c
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-14
22:38 ---
For addition, this is a regression against 3.3.5:
$ cat c-add.c
#include math.h
#include complex.h
int main()
{
float a;
complex float b,c;
foo(a,b);
c = b+a;
return creal(c
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-13
17:50 ---
Looking at PR 17123 a bit more closely, I think that
this is a duplicate.
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19928
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10
08:52 ---
(In reply to comment #2)
There are a gazillion places where we just check if (optimize) without
any specific flag. It would be quite a lot of work to introduce flags for all
of them, and I'm not sure
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10
10:17 ---
It appears the problem is caused by one of the
optimization options that cannot be controlled with
flags.
One suspect is this code snippet from gcc/config/ia64.c :
static bool
ia64_rtx_costs (rtx x
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10
20:31 ---
*** This bug has been marked as a duplicate of 19848 ***
--
What|Removed |Added
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10
20:31 ---
*** Bug 19825 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
--
Bug 5900 depends on bug 19825, which changed state.
Bug 19825 Summary: -fno-loop-optimize2 does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19825
What|Old Value |New Value
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10
20:35 ---
(In reply to comment #4)
$ find . -name '*.c' | xargs grep '[(|!] *optimize[) =!|]' | wc -l
204
Any idea how I should go about further debugging PR 5900? There is a
wrong-code for ia-64
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-09
08:12 ---
gfortran -c -O1 -fno-tree-ccp -fno-tree-ch -fno-tree-copyrename -fno-tree-dce
-fno-tree-dominator-opts -fverbose-asm -fno-unswitch-loops -fno-peel-loops
-fno-unroll-loops -fno-tree-dse -fno-tree-fre
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
--
What|Removed |Added
OtherBugsDependingO||5900
nThis||
Version|unknown |4.0.0
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-09
12:43 ---
See PR 19848.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-09
21:19 ---
Same thing on i686-pc-linux-gnu with the gcc driver:
$ cat main.c
int main()
{
return 0;
}
$ gcc -S -fverbose-asm -o main-o0.s main.c
$ gcc -S -fno-cprop-registers -fno-defer-pop -fno-guess
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08
09:24 ---
On ia64-unknown-linux-gnu, -O1 produces the same result that -O3 does.
Here's a shell script that I currently use for shotgun
testing of single optimization options:
for a in \
branch-count-reg cprop
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08
15:36 ---
(In reply to comment #34)
Please, try the opposite: disable optimizations through -O1 -fno-[optnam] and
see if you find out something.
Still the same four failures with
#! /bin/sh
: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08
16:36 ---
This blocks testing of compiler options in PR 5900.
--
What|Removed |Added
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08
16:36 ---
I am not sure which of my tests of compiler options
were actually testing anything. There appears to be a bug
in passing at least one -fno - switch (see PR 19825).
Thomas
--
http://gcc.gnu.org
1 - 100 of 326 matches
Mail list logo
