--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-10-09 14:24
---
(In reply to comment #3)
this has already been reported. See PR 33676.
Great! I'm glad I'm not mad and other people are seeing it as well.
Unfortunately, having a rather slow pentium4 and
incompetence
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33679
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-10-06 23:04
---
I checked and the simplification routines work correctly, which means there is
no real testsuite coverage for these functions. We should always include
testcases comparing values calculated at runtime
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-10-05 07:52
---
(In reply to comment #5)
Ah yes, this is the old moves of cost 2 don't need reloads thing.
Could you try the attached patch?
Bootstrap completed (C + Fortran) with this patch applied. Thanks.
--
fxcoudert
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-10-05 11:15
---
Confirmed. Reduced testcase:
$ cat a.f90
module test
contains
subroutine func_1(u,n)
integer :: n, u(n(1))
end subroutine
end module test
$ gfortran a.f90
f951: internal compiler error: Segmentation
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
--
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
--
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 #21 from fxcoudert at gcc dot gnu dot org 2007-10-05 17:41
---
Yet another one:
print *, transfer(achar([0]), 0_1)
end
Reducing this testcase has opened Pandora's box, I'll try to fix them one after
another.
--
fxcoudert at gcc dot gnu dot org changed
--- Comment #22 from fxcoudert at gcc dot gnu dot org 2007-10-05 21:59
---
Created an attachment (id=14307)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14307action=view)
Patch for 4 testcases of this PR
The following three cases are fixed by the patch attached (fix resolution
--- Comment #23 from fxcoudert at gcc dot gnu dot org 2007-10-05 22:02
---
(In reply to comment #22)
Created an attachment (id=14307)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14307action=view) [edit]
Patch for 4 testcases of this PR
It also fixes that one:
contains
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-10-04 13:25
---
We still have an ICE on __powitf2, at -O2 (but not -O1):
$ cat foo.i
typedef float TFtype __attribute__ ((mode (TF)));
TFtype __powitf2 (TFtype x, int m)
{
TFtype y = x;
while (m = 1)
{
x = x * x
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-10-04 15:04
---
Subject: Bug 33502
Author: fxcoudert
Date: Thu Oct 4 15:04:09 2007
New Revision: 129011
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129011
Log:
PR fortran/33502
* scanner.c
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-10-04 15:05
---
Fixed on mainline. Thanks for the bug report!
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-10-04 15:08
---
Subject: Bug 33529
Author: fxcoudert
Date: Thu Oct 4 15:08:14 2007
New Revision: 129012
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129012
Log:
PR fortran/33529
* decl.c
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-04 15:09
---
Fixed on mainline. Thanks for the bug report, and please reopen this one or
open a new one if you still experience problems.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-10-04 15:10
---
Fixed, isn't it?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-10-04 15:18
---
Subject: Bug 32021
Author: fxcoudert
Date: Thu Oct 4 15:18:48 2007
New Revision: 129014
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129014
Log:
PR libfortran/32021
* runtime/environ.c
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-04 15:19
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #20 from fxcoudert at gcc dot gnu dot org 2007-10-03 08:08
---
Further reduced testcase:
integer i(1)
print *, transfer(achar(i), x)
end
The type mismatch disappears if you change the transfer statement into
transfer([x]), x, so this is a problem in the return type
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
GCC build triplet
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-03 09:46
---
Subject: Bug 26682
Author: fxcoudert
Date: Wed Oct 3 09:46:46 2007
New Revision: 128977
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128977
Log:
PR fortran/26682
* options.c
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
OtherBugsDependingO 32834
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:26
---
(In reply to comment #1)
Created an attachment (id=14291)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14291action=view) [edit]
Putative patch
I thought about that, because it seems right
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:40
---
(In reply to comment #4)
OTOH I'm seeing a testsuite failure with derived_comp_array_ref_5.f90
for which I have no explanation at the moment, I'll have to doublecheck
if it disappears without my patch.
Hum
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-10-03 16:52
---
(In reply to comment #6)
failures of default_format_1.f90 (which I'm seeing as well)
You're seeing failures of default_format_1.f90 on i686-darwin (IIRC, that's
what you've got these days)? That's not supposed
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-10-03 17:09
---
(In reply to comment #8)
I checked all tests individually, and both the tests related to
tiny(0.0_8) fail.
That means Apple's printf() failures to read and write denormals are not
powerpc-specific. I've
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-10-03 21:27
---
Subject: Bug 26682
Author: fxcoudert
Date: Wed Oct 3 21:27:39 2007
New Revision: 128993
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128993
Log:
PR fortran/26682
* trans-decl.c
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-03 21:30
---
I've fixed 1 and 2 (and added an error message when -fwhole-program is used
with Fortran), and there is a separate PR to track 3, so I'll close this one.
--
fxcoudert at gcc dot gnu dot org changed
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-10-03 22:05
---
(In reply to comment #2)
Created an attachment (id=14292)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14292action=view) [edit]
Putative patch redux
That patch regtests fines on x86_64-linux with type
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-10-02 07:52
---
gfortran should now really work on all targets. I'm closing this one.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-10-02 11:20
---
Hi Dale,
pr32417.f90 doesn't ICE any more, closing this PR. Please reopen if you have
more information.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-10-02 11:27
---
(In reply to comment #5)
Really? From how I read the standard (F2K draft), UBOUND(ARRAY, DIM) has (in
this case) a value equal to the upper bound for subscript DIM of ARRAY. I
can't see it allowing returning
--
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
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-10-02 23:28
---
Subject: Bug 33469
Author: fxcoudert
Date: Tue Oct 2 23:27:51 2007
New Revision: 128967
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128967
Log:
PR libfortran/33469
* io/write.c
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-10-02 23:30
---
As I said, the default format is wide enough for powerpc-darwin. It's widely
possible that the new testcase gfortran.dg/default_format_2.f90 fails there,
though, due to the Apple printf() bug. Dominique, if you
--
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 fxcoudert at gcc dot gnu dot org 2007-10-01 10:58
---
There are three different issues:
1. -fwhole-program should be documented as not working for the Fortran
programs.
2. The Fortran main program (MAIN__) needs to be kept by the -fwhole-program
optimization
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-10-01 11:19
---
(In reply to comment #10)
It looks like it is now only a Macintosh PowerPC version problem. It also
works Ok on the Intel Macintosh and on the MSYS versions of gfortran.
I can confirm that bug on ppc-darwin
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-10-01 13:05
---
You might also want to build GMP and MPFR with internal checking enabled
(--enable-assert, I think). Doesn't this one appear on hpux11?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33584
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-10-01 13:13
---
Can you compile and run the following C test code? (gcc -std=c99, or the system
compiler)
#include math.h
#include stdio.h
int main (void)
{
printf (%ld %ld %ld\n, lround (nextafter(0.5,-9.0)), lround (0.5
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-01 16:39
---
(In reply to comment #2)
lround and nextafter aren't available on hpux10.
Does hpux10 have round()? And does it have ceil()? (I assume that the last
answer is yes, because it's ANSI C, but hpux could surprise
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-01 20:11
---
This is not target-specific:
$ cat u.f90
print *, real(huge(1.0_8),4)
end
$ gfortran u.f90
u.f90:1.16:
print *, real(huge(1.0_8),4)
1
Error: Arithmetic overflow converting REAL(8) to REAL
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-01 23:28
---
Hum, the real(16) case looks like loads of fun to come!
$ cat k.f90
integer, parameter :: k = 16
character(80) :: buf
real(k) :: xk, yk
xk = 1.0_k - epsilon(xk)
write (buf,'(1PG60.40)') xk
read (buf
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-10-02 00:37
---
(In reply to comment #5)
Hum, the real(16) case looks like loads of fun to come!
Part of it is simply a libc bug. There are numbers close to 1.0 and -1.0 that
the darwin libc can't output properly:
$ cat k2.c
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-30 22:28
---
The patch below should provide fallback functions (build in maintainer mode or
use autoreconf in libgfortran), does it work?
Index: intrinsics/c99_functions.c
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-10-01 00:05
---
Created an attachment (id=14276)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14276action=view)
Updated patch
The attached updated patch seems to fix the issue (and also fixes a problem in
the logic
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin8.10.0
GCC host triplet: powerpc-apple-darwin8.10.0
GCC target triplet: powerpc-apple-darwin8.10.0
http://gcc.gnu.org/bugzilla
--
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 #24 from fxcoudert at gcc dot gnu dot org 2007-09-29 23:15
---
First, I should note that this doesn't affect real kinds 4 and 8, due to
Jerry's per-kind I/O change; this bug now only shows up for real(kind=16).
Second, this is a problem with huge(0._16) not being equal
--- Comment #25 from fxcoudert at gcc dot gnu dot org 2007-09-29 23:20
---
I should have posted my reduced testcase, so that I don't lose it:
real(16) :: y
y=huge(y)
write(*,(G60.50E4)) y
write(*,(G60.50E4)) nearest(y,1.)
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-09-27 12:27
---
(In reply to comment #7)
It doesn't matter if it's bad coding (which I can agree).
AFAIK, the standard says the code is legal.
After reading the standard, I concur. I think a warning option should be added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
GCC build triplet: i386-pc-mingw32
GCC host triplet: i386-pc-mingw32
GCC target triplet
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- 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 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 #11 from fxcoudert at gcc dot gnu dot org 2007-09-26 22:27
---
Subject: Bug 30780
Author: fxcoudert
Date: Wed Sep 26 22:27:16 2007
New Revision: 128825
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128825
Log:
PR fortran/30780
* invoke.texi: Add note
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-09-26 22:28
---
Documentation added.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-24 20:24
---
Subject: Bug 33538
Author: fxcoudert
Date: Mon Sep 24 20:24:11 2007
New Revision: 128724
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128724
Log:
PR fortran/33538
* scanner.c, parse.c
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-24 20:26
---
Patch reverted, trunk should be back on track. Sorry.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-24 20:28
---
It would be nice to find a patch that doesn't break bootstrap on plenty of
platforms :)
I'll be on it when I have time, PR 33538 indicates the trouble caused by my
first patch, now reverted.
--
fxcoudert
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-23 09:08
---
$ cat u.f90
character (kind=kind(a)) :: u
end
$ gfortran u.f90
u.f90:1.27:
character (kind=kind(a)) :: u
1
Error: Kind 0 is not a CHARACTER kind at (1)
--
fxcoudert at gcc
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-09-23 09:08
---
Fixed on 4.3.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-23 09:32
---
Tobias says I'm not sure we need this, and Steve rightly points out that this
was ruled out in the past. So, closing for now. (If the need arises, we should
first discuss it on the list, IMHO.)
--
fxcoudert
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-09-23 09:35
---
PR 33140 disappeared from mainline around 2007-09-08. Dale, can you still see
the ICE you reported?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33174
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
and
included files
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-22 13:57
---
*** This bug has been marked as a duplicate of 33522 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-22 13:57
---
*** Bug 33523 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33522
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-22 14:00
---
Yup, introduced by
2007-08-26 Asher Langton [EMAIL PROTECTED]
* gfortran.dg/recursive_stack.f90: New.
* gfortran.dg/openmp_stack.f90: New.
OpenMP testcases should go into libgomp/testsuite
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-22 15:02
---
Patch below fixes it:
Index: trans-types.c
===
--- trans-types.c (revision 128661)
+++ trans-types.c (working copy)
@@ -1088,16
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-22 15:03
---
Subject: Bug 33502
Author: fxcoudert
Date: Sat Sep 22 15:03:24 2007
New Revision: 128671
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128671
Log:
PR fortran/33502
* scanner.c
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-09-22 15:04
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-09-22 16:55
---
Subject: Bug 33522
Author: fxcoudert
Date: Sat Sep 22 16:54:56 2007
New Revision: 128673
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128673
Log:
PR fortran/33522
* trans-types.c
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-09-22 16:59
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
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 #1 from fxcoudert at gcc dot gnu dot org 2007-09-22 23:35
---
Created an attachment (id=14245)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14245action=view)
First patch
First implementation. It doesn't even regtest, but I'll attach it here to avoid
loosing it. I'll
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33387
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-22 23:48
---
Subject: Bug 33528
Author: fxcoudert
Date: Sat Sep 22 23:48:02 2007
New Revision: 128676
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128676
Log:
PR fortran/33528
* scanner.c
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-22 23:48
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-22 23:54
---
*** Bug 33530 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-09-22 23:54
---
I've reported this one as PR33472, and Tai has proposed a fix already. (I
thought I had sent the report also to the mingw-w64 list, but I may have
forgotten.)
Also, I have built and published binaries for Win64
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-09-21 10:54
---
Subject: Bug 26253
Author: fxcoudert
Date: Fri Sep 21 10:54:20 2007
New Revision: 128648
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128648
Log:
PR libfortran/26253
* intrinsics
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-09-21 10:55
---
This should now be fixed. Please reopen if I fumbled in any way and the issue
is still present.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-09-21 11:59
---
(In reply to comment #9)
Maybe one should put it additionally also in the documentation of the CPU_TIME
intrinsic subroutine.
Yep, but I suspect that CPU_TIME is not the only routine library routine that
can
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-09-21 11:37
---
I'm changing this into a documentation PR, and assign it to myself. It was
decided that there really isn't a good way to provide high-quality timer
functions with precision-loss trapping. We need to document
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-09-21 19:49
---
Subject: Bug 31546
Author: fxcoudert
Date: Fri Sep 21 19:49:34 2007
New Revision: 128654
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128654
Log:
PR fortran/31546
* (configure.ac): Add
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-09-21 19:50
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status
801 - 900 of 3175 matches
Mail list logo
