--- Comment #28 from toon at moene dot indiv dot nluug dot nl 2008-10-22
08:28 ---
Jerry, do you think your patch can be applied and this bug closed ?
As I wrote, it fixed the original problem from which I constructed the two test
cases.
--
http://gcc.gnu.org/bugzilla
--- Comment #26 from toon at moene dot indiv dot nluug dot nl 2008-10-19
16:11 ---
The patch works for my case,
Please be careful with the namelist_18,f90 test case - I can't off-hand say
whether it's right or (an extension).
Cheers,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #13 from toon at moene dot indiv dot nluug dot nl 2008-10-18
08:43 ---
Unfortunately, while the original test case has been solved, the original
problem that led me to file this bug report hasn't been ...
Here's a failing example closer to the original source:
TYPE
--- Comment #14 from toon at moene dot indiv dot nluug dot nl 2008-10-18
08:46 ---
Created an attachment (id=16514)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16514action=view)
New Failing Example.
This a more complicated example that still fails after Jerry's fix
--- Comment #15 from toon at moene dot indiv dot nluug dot nl 2008-10-18
08:47 ---
Sorry, source code of new example got mangled; I created an attachment
(nl4.f90)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
--- Comment #19 from toon at moene dot indiv dot nluug dot nl 2008-10-18
15:33 ---
character*200 :: l = NAMINTERP atmkey%ppp = 076,058,062,079, atmkey%nnn = 0
1
Warning: CHARACTER expression at (1) is being truncated (222/200)
Tobias, you are right - the string
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
--- Comment #8 from toon at moene dot indiv dot nluug dot nl 2008-09-10
18:18 ---
Indeed, can be closed - thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34567
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36316
--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2008-05-23
20:07 ---
Ugh, sorry, I see I included the wrong source.
Here's the correct one:
MODULE YOMCAIN
IMPLICIT NONE
SAVE
TYPE distributed_vector
REAL, pointer :: local(:)
INTEGER :: global_length,local_start
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2008-03-19
08:37 ---
I'm hit by this, too - don't know when it started (it's in a namelist I've been
using for years).
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2008-03-17
16:00 ---
*** Bug 35613 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35612
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2008-03-17
16:00 ---
*** This bug has been marked as a duplicate of 35612 ***
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--- Comment #9 from toon at moene dot indiv dot nluug dot nl 2008-02-18
08:32 ---
What will happen now? Will anyone send an interpretation request, which will
bring it up on the table again?
No, as it isn't *impossible* to implement it (with a hidden argument), an
interp won't stand
--- Comment #7 from toon at moene dot indiv dot nluug dot nl 2008-02-15
18:15 ---
As written, I checked all my compilers and all get a wrong result
- gfortran, g95, NAG f95: NOT PRESENT
- ifort: PRESENT, WITH VALUE: 0 (even if not present)
(ifort 10 and ifort 10.1 print
: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2008-02-15
01:04 ---
At the moment I do not see how one could implement this if WG5 insists that
this is valid - except of passing a hidden argument.
As I am at a WG5 just right now, I decided to ask. Allowing OPTIONAL
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
-
array.c:147
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
http
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2008-01-16
21:47 ---
Created an attachment (id=14952)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14952action=view)
Tar file with sources to evoke problem
The test case.
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2008-01-16
21:49 ---
Does fail on x86-64-unknown-gnu-linux and OSX ppc (probably not relevant).
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2008-01-16
22:19 ---
Also wrong with Debian's 4.2.3 prerelease.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34820
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34567
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2007-12-23
13:21 ---
Created an attachment (id=14809)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14809action=view)
The Test Case
This is the directory with makefile to show the bug.
If you have a gfortran
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2007-12-23
13:49 ---
Gfortran 4.2.2 gets this right (at least when using Debian/testing's default
gfortran):
[EMAIL PROTECTED]:~/pr34567$ gfortran -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
http
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33906
: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33421
: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33422
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2007-09-13
18:43 ---
G, bugzilla
*** This bug has been marked as a duplicate of 33421 ***
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2007-09-13
18:43 ---
*** Bug 33422 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33421
--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2007-09-13
18:44 ---
Two witnesses should be enough ...
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--- Comment #8 from toon at moene dot indiv dot nluug dot nl 2007-09-06
08:56 ---
Wouldn't it be an option to simply bail out early (i.e., after the error
checks) in case of size == 0 ?
E.g., like this:
62
63 rrank = srank + 1;
64 if (rrank GFC_MAX_DIMENSIONS
at moene dot indiv dot nluug dot nl
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2007-09-04
08:11 ---
Yeah, I have to come up with a better example. In the original code that I
reduced, the interface came from a module file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33298
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2007-09-04
10:15 ---
Second try, now with interface and using zero sized arrays:
$ cat spread.f
INTERFACE SUB
SUBROUTINE SUB(P,Q)
REAL, INTENT(OUT) :: P(:,:)
REAL, INTENT(IN) :: Q(:)
END
--- Comment #6 from toon at moene dot indiv dot nluug dot nl 2007-09-04
13:04 ---
Quoting spread_generic.c:
145 for (n = 0; n ncopies; n++)
146{
147 memcpy (dest, sptr, size);
148 dest += rdelta;
149}
The C 99 Standard has the following to say
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33189
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2007-08-25
16:52 ---
Ah, but then the question becomes:
Why is this not valid ?
CHARACTER*10 a
a = '15'
READ(a, '(*)') i
PRINT*,i
END
33189.f:3.72:
READ(a, '(*)') i
--- Comment #5 from toon at moene dot indiv dot nluug dot nl 2007-05-30
01:18 ---
Subject: Re: Module with equivalence draws unsatisfied
reference
pault at gcc dot gnu dot org wrote:
--- Comment #4 from pault at gcc dot gnu dot org 2007-05-29 10:39 ---
The patch below
: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2007-05-27
17:23 ---
Subject: Re: Module with equivalence draws unsatisfied
reference
Thanks for taking this up.
This bug prevents much of Europe to compile the weather code of the
European Centre.
Kind regards
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
GCC build triplet: idem
GCC host triplet: x64_86-unknown-gnu-linux
GCC target triplet: idem
http://gcc.gnu.org
--- Comment #5 from toon at moene dot indiv dot nluug dot nl 2007-02-04
13:17 ---
It's not completely fixed yet, though.
The following:
MODULE types_m
TYPE coord_t
INTEGER ncord
REAL,ALLOCATABLE,DIMENSION(:) :: x, y
END TYPE
TYPE grib_t
INTEGER ksec0(2), ksec1(64
: toon at moene dot indiv dot nluug dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30660
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2007-01-31
21:37 ---
I can't attach the source file, so I reproduce it here:
MODULE types_m
INTEGER,PRIVATE,PARAMETER :: MXLEN = 2024, MXKEYS = 50, MXGRIBFLDS = 1000,
MXFIN = 2
TYPE coord_t
INTEGER ncord
REAL
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2006-12-29
09:03 ---
*** This bug has been marked as a duplicate of 30321 ***
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2006-12-29
09:03 ---
*** Bug 30320 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30321
at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2006-05-26
13:02 ---
Created an attachment (id=11516)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11516action=view)
Source file showing the wrong behaviour
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27773
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2006-05-26
13:06 ---
Changed summary to indicate this bug is a 4.2 regression.
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27698
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2006-03-31
11:24 ---
Could you retry this with gfortran 4.1 (now that it is out) ?
Thanks.
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2006-03-28
08:15 ---
logical, optional, intent(in) :: back
myscan = scan (str, substr, back)
I thought passing non-present optional arguments down to routines as an
optional argument is within the confines
--- Comment #7 from toon at moene dot indiv dot nluug dot nl 2006-03-11
12:09 ---
Bug fix now also committed to the 4.1 branch, so will be fixed as of 4.1.1.
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2006-02-11
13:27 ---
Subject: Re: Gratuitous warning about Fortran 2003 features w/o -std=...
We don't warn for other Fortran 2003 features we support without a -std=f95,
so
I'll look into it and fix it.
Well, that's
--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2006-02-10
08:42 ---
We don't warn for other Fortran 2003 features we support without a -std=f95, so
I'll look into it and fix it.
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed
--- Comment #3 from toon at moene dot indiv dot nluug dot nl 2006-01-10
13:04 ---
Also, very telling, it fails for s390x-ibm-linux-gnu (64 bits) and *not* for
s390-ibm-linux-gnu (32 bits).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25716
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2005-12-27
12:11 ---
Fixed in 3.4.6.
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--- Comment #5 from toon at moene dot indiv dot nluug dot nl 2005-12-27
12:24 ---
This is not a g77 error. The following C routine's compilation
fails in the same way - deep down in the middle world:
main()
{
__complex c[1] = { 0.0 };
}
--
toon at moene dot indiv dot nluug
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |toon at moene dot indiv dot
|dot org
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2005-12-15
08:29 ---
*** This bug has been marked as a duplicate of 18913 ***
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--- Comment #4 from toon at moene dot indiv dot nluug dot nl 2005-12-15
08:29 ---
*** Bug 25424 has been marked as a duplicate of this bug. ***
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--- Comment #9 from toon at moene dot indiv dot nluug dot nl 2005-11-29
19:20 ---
FX,
Your patch solved the problem for me.
AFAICS, this patch is indeed the correct fix for this problem.
Please apply it to (at least) 4.1 and trunk.
It might be appropriate for the 4.0 branch, too
--- Comment #6 from toon at moene dot indiv dot nluug dot nl 2005-11-28
15:36 ---
I think you are right. I have been putting in debug statements all over and
find that we are asking the wrong length of reads, 8 characters, instead of 1
in the failing case. I will get back
ReportedBy: toon at moene dot indiv dot nluug dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25116
--- Comment #7 from toon at moene dot indiv dot nluug dot nl 2005-11-05
11:51 ---
I got some preliminary results from debugging.
By -fdump-parse-tree, YLOCAL does have the correct (implicitly
determined) type of CHARACTER*8 at statement YLOCAL='A'.
However, by the time we reach
--- Comment #6 from toon at moene dot indiv dot nluug dot nl 2005-11-03
19:34 ---
Mine ! All Mine !
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2005-11-02
20:36 ---
Created an attachment (id=10114)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10114action=view)
Test case for this bug
Test case added.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2005-05-15 11:32 ---
Subject: Re: COMPLEX function returns incompatible with
g77
tobi at gcc dot gnu dot org wrote:
--- Additional Comments From tobi at gcc dot gnu dot org 2005-05-10
22:23 ---
Fixed
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2005-05-15 18:49 ---
Subject: Re: Segfault while compiling
libgfortran/intrinsics/selected_int_kind.f90
corsepiu at gcc dot gnu dot org wrote:
Joel, do you recall the target in RTEMS which has 4-byte floats only
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2005-04-23 10:58 ---
(In reply to comment #10)
Kazu, I just tried the patch, pr21030-vrp-ice.patch.
It seems to fix the problems with gfortran and -O2.
Kazu, could you propose your patch on gcc-patches or ping
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2005-03-12 12:57 ---
Sorry, should have looked at old bugs first ...
*** This bug has been marked as a duplicate of 19926 ***
--
What|Removed |Added
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2005-03-12 12:57 ---
*** Bug 20334 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: toon at moene dot indiv dot nluug dot nl
CC: gcc-bugs at gcc dot
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2005-01-21 20:23 ---
Subject: Re: Naive (default) complex division algorithm
pcarlini at suse dot de wrote:
--- Additional Comments From pcarlini at suse dot de 2005-01-20 12:10
---
A first
--
Bug 19292 depends on bug 19280, which changed state.
Bug 19280 Summary: Inconsistent licensing of libgfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19280
What|Old Value |New Value
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2005-01-12 22:16 ---
Weapons of Mass Relicensing ...
--
What|Removed |Added
Status
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2005-01-07 21:58 ---
This really, really is a driver issue.
AFAICS, we stick to the correct definitions ...
--
What|Removed |Added
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2005-01-05 22:18 ---
This, indeed, is a real problem.
--
What|Removed |Added
Status
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2005-01-05 22:19 ---
I'll work on this (hopefully this weekend 8/9th of January '05)
--
What|Removed |Added
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2004-11-28 12:42 ---
Subject: Re: New: can't find a register in class `GENERAL_REGS'
when trying to make Firefox 1.0
Dirk dot Schwartzkopff at gmx dot de wrote:
It is impossible to compile Firefox on IBM zSeries
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2004-11-24 00:26 ---
Subject: Re: gfortran: CONJG: false error message about
standard violation
sgk at troutmask dot apl dot washington dot edu wrote:
--- Additional Comments From sgk at troutmask dot apl dot
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2004-11-24 00:33 ---
Subject: Re: gfortran: CONJG: false error message about
standard violation
sgk at troutmask dot apl dot washington dot edu wrote:
--- Additional Comments From sgk at troutmask dot apl dot
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2004-11-20 12:03 ---
(In reply to comment #0)
z2 = conjg (z1)
1
Error: Type of argument 'z' in call to 'conjg' at (1) should be COMPLEX(4),
not
COMPLEX(8)
Yep, I think this in intrinsic.c
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2004-11-20 12:10 ---
Hmmm, I do not get this on my powerpc-unknown-linux-gnu:
[EMAIL PROTECTED]:~/g95-bugs$ /usr/snp/bin/gfortran -O2 18518.f90
[EMAIL PROTECTED]:~/g95-bugs$ (LD_LIBRARY_PATH=/usr/snp/lib export
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2004-11-20 12:16 ---
I agree too, that's why I changed the status of this bug report to NEW, i.e.,
confirmed :-)
Toon.
--
What|Removed |Added
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2004-09-23
20:21 ---
Also crashes on powerpc-unknown-linux-gnu (testing Debian up to date to
Saterday 9:00 UTC).
--
What|Removed |Added
--- Additional Comments From toon at moene dot indiv dot nluug dot nl 2003-12-23
23:48 ---
I believe this is what we want. -d8 shouldn't be Joined though.
Well, yes, obviously - unfortunately, it *is*:
a prefix [for -dletters]
and therefore eaten (while it shouldn't, because '8
90 matches
Mail list logo
