--- Comment #4 from burnus at gcc dot gnu dot org 2008-11-11 19:33 ---
(In reply to comment #3)
> I will go back to my lens design program. I will recreate the bug I am
> seeing
> and proceed from there. Once I do, should I submit a new bug report, if
> necessary, or sho
--- Comment #9 from burnus at gcc dot gnu dot org 2008-11-11 14:28 ---
(In reply to comment #6)
> reduced:
>
> SUBROUTINE S1
> CONTAINS
>TYPE(T1) FUNCTION F1()
>END FUNCTION F1
> END SUBROUTINE S1
Error: PUBLIC function 'f1' at (1) cannot be
--- Comment #10 from burnus at gcc dot gnu dot org 2008-11-11 14:35 ---
bug5a.tgz compiled successfully with the patch in comment 9.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-11 15:25 ---
> Error: Name 'getnullset' at (1) is an ambiguous reference to
> 'getnullset' from module 'pbit4set'
I have not yet checked the source, but other compilers give similar errors:
--- Comment #12 from burnus at gcc dot gnu dot org 2008-11-12 07:00 ---
Subject: Bug 38065
Author: burnus
Date: Wed Nov 12 06:59:33 2008
New Revision: 141780
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141780
Log:
2008-11-12 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #13 from burnus at gcc dot gnu dot org 2008-11-12 07:02 ---
FIXED on the trunk (4.4.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2008-11-12 18:39 ---
Subject: Bug 38094
Author: burnus
Date: Wed Nov 12 18:38:08 2008
New Revision: 141798
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141798
Log:
2008-11-12 Tobias Burnus <[EMAIL PROTECTED]&
--- Comment #14 from burnus at gcc dot gnu dot org 2008-11-12 18:39 ---
Subject: Bug 38065
Author: burnus
Date: Wed Nov 12 18:38:08 2008
New Revision: 141798
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141798
Log:
2008-11-12 Tobias Burnus <[EMAIL PROTECTED]&
--- Comment #4 from burnus at gcc dot gnu dot org 2008-11-12 18:46 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #10 from burnus at gcc dot gnu dot org 2008-11-12 22:28 ---
Subject: Bug 38094
Author: burnus
Date: Wed Nov 12 22:27:10 2008
New Revision: 141811
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141811
Log:
2008-11-12 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #11 from burnus at gcc dot gnu dot org 2008-11-12 22:29 ---
(In reply to comment #5)
> The test is still failing, now with two failures. One is due to the mismatch
> between the expected error: "cannot be of PRIVATE type" and the actual one
> "Fortr
--- Comment #7 from burnus at gcc dot gnu dot org 2008-11-12 22:37 ---
Looks as if the code is valid. Valgrind shows:
==2910== Invalid read of size 4
==2910==at 0x4B1005: gfc_apply_interface_mapping_to_expr
(trans-expr.c:1916)
==2910==by 0x4B6FBE: gfc_apply_interface_mapping
--- Comment #10 from burnus at gcc dot gnu dot org 2008-11-12 23:42 ---
Some debugging shows that sym->name is "same" and sym->attr.function == 1.
Furthermore is arg1->expr_type == EXPR_FUNCTION and arg1->ts.cl->length ==
NULL.
(For cross referencing: http://gc
--- Comment #11 from burnus at gcc dot gnu dot org 2008-11-12 23:45 ---
(In reply to comment #8)
> I tried to reduce the case.
> This is probably unrelated to the original ICE though.
Looks unrelated, but still should be fixed; I think ICE from comment 8 is a
regression with r
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-13 15:49 ---
Jerry, can you have a look? Using ifort it prints: 2003.000
and it seems to be valid Fortran 95/2003.
"10.7.6 BN and BZ editing"
"The BN and BZ edit descriptors temporarily change (9.4.1) the blank
--- Comment #4 from burnus at gcc dot gnu dot org 2008-11-13 15:55 ---
Patch was: http://gcc.gnu.org/ml/fortran/2008-11/msg00080.html
I'm not completely satisfied with the patch it will break code such as:
character(50) :: line(2)
namelist /stuff/ n, m
n = 123
m = 456
: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
BugsThisDependsOn: 38095
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38119
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-14 15:55 ---
Works in 4.3.2, 4.2.1 and 4.1.3. Fails with 4.4.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from burnus at gcc dot gnu dot org 2008-11-15 10:33 ---
(In reply to comment #11)
> > I tried to reduce the case.
> > This is probably unrelated to the original ICE though.
> Looks unrelated, but still should be fixed; I think ICE from comment 8 is a
&g
--- Comment #4 from burnus at gcc dot gnu dot org 2008-11-15 10:42 ---
> It's not a bug in my program. It's a bug in NONMEM VI. That is, assuming that
> /dev/tty and /dev/null are files, which they're not. They're devices.
> Regardless, it's code
gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-15 16:10 ---
Using
A(1:N,1:N)=reshape(A(1:0,1),(/N,N/),reshape((/1/),(/N+1/),(/2/)))
the program is a Fortran 95 program, which also works with NAG f95 and openf95.
-> Blocking 32834
--
burnus at gcc dot gnu dot org chan
--- Comment #14 from burnus at gcc dot gnu dot org 2008-11-15 18:06 ---
(In reply to comment #13)
> > I filled PR38119 for that PR.
> This is probably stupid but what is the difference between the two PRs?
The program of comment 0 of this PR (PR 38095) gives an ICE with all
ing
length
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus
--- Comment #28 from burnus at gcc dot gnu dot org 2008-11-15 18:41 ---
I think this PR can be closed - the ICEs are gone, the TODO item is gone and
the missing warnings are tracked in PR 33037.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-15 20:56 ---
No crash or similar on my x86-64-linux, but valgrind shows:
==32084== Invalid read of size 1
==32084==at 0x4824B0: gfc_commit_symbols (symbol.c:2824)
==32084==by 0x45D94C: accept_statement (parse.c:1503
--- Comment #16 from burnus at gcc dot gnu dot org 2008-11-16 14:21 ---
Subject: Bug 38095
Author: burnus
Date: Sun Nov 16 14:19:38 2008
New Revision: 141917
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141917
Log:
2008-11-16 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #17 from burnus at gcc dot gnu dot org 2008-11-16 14:21 ---
FIXED on the trunk (4.4.0). Thanks for the report!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
ct and too
late
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at g
--- Comment #3 from burnus at gcc dot gnu dot org 2008-11-17 00:01 ---
(In reply to comment #2)
> > By the way, the following also fails:
> The error is fixed by the following trivial patch:
Janus, do you plan to submit it?
* * *
Regarding the ICE, the following patch seem
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-20 07:20 ---
> I don't think INF is the same as infinity. It is most like implict
> declared variable with an undefined value.
Exactly. With IMPLICIT NONE one sees that INF is an (implicitly typed) integer
variable
--- Comment #3 from burnus at gcc dot gnu dot org 2008-11-20 15:52 ---
Other compilers have the SHARE= specifier for OPEN and INQUIRE, e.g. Intel or
HP. I'm not sure it is needed, but one could consider supporting it as well
when implementing this option.
http://www.intel.com/sof
--- Comment #3 from burnus at gcc dot gnu dot org 2008-11-20 15:56 ---
Jerry, regarding the suggestion in comment 2: Do you see that we can do there
some optimization, esp. when reading a number or with "*" a string (for '(a)'
one presumably cannot do any optimiza
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38205
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-20 23:00 ---
Another test case is the following program (fixed by your patch):
http://groups.google.com/group/comp.lang.fortran/msg/2119be02dcf93517
How about packaging your patch and submitting it?
--
burnus at gcc dot gnu
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-22 18:19 ---
Subject: Bug 38160
Author: burnus
Date: Sat Nov 22 18:18:05 2008
New Revision: 142124
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142124
Log:
2008-11-22 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #3 from burnus at gcc dot gnu dot org 2008-11-22 18:28 ---
FIXED on the trunk (4.4.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-22 19:03 ---
Another code which is not rejected. If the parent procedure is called by a
contained procedure there must be a recursion:
subroutine test()
call sub()
contains
subroutine sub()
call test()
end subroutine
--- Comment #3 from burnus at gcc dot gnu dot org 2008-11-22 21:40 ---
Before closing, one should check whether a recursive-related bug remains for
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e0d04d755453a2a5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-22 21:41 ---
See also James' new c.l.f post:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e0d04d755453a2a5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38205
--- Comment #6 from burnus at gcc dot gnu dot org 2008-11-22 21:42 ---
See also test cases at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e0d04d755453a2a5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
--- Comment #20 from burnus at gcc dot gnu dot org 2008-11-23 19:07 ---
Mikael, Daniel: Have I missed something or is everything in this PR fixed in
4.4 ("trunk") and only some 4.3 back porting is needed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-24 16:20 ---
The error message looks as if you are mixing a gfortran 4.3 compiled .mod file
with a gfortran 4.4 compiler (or vice versa). While the gfortran 4.3 compiled
*.o/*.so/*.a files are supposed to be compatible with 4.4&#
--- Comment #5 from burnus at gcc dot gnu dot org 2008-11-24 16:22 ---
To add: There is currently a build problem for the linux 32bit version of the
gfortran nightlies; thus there has been no newer build since about one month.
--
burnus at gcc dot gnu dot org changed
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-24 17:07 ---
Regarding : Standard Fortran does not allow tabs, as extension gfortran
does. Thus you do not need to change the code (though it does not harm to be
standard compliant - that is what the warning tells you). But one
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Summary|Empty function with CONTAINS|[4.4 Regression
--- Comment #4 from burnus at gcc dot gnu dot org 2008-11-25 12:53 ---
Subject: Bug 38248
Author: burnus
Date: Tue Nov 25 12:51:44 2008
New Revision: 142190
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142190
Log:
2008-11-25 Jan Kratochvil <[EMAIL PROTECTED]&g
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38259
Version: 4.4.0
Status: UNCONFIRMED
Keywords: documentation
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38273
--- Comment #4 from burnus at gcc dot gnu dot org 2008-11-26 13:50 ---
I think that patch is not enough (though useful!). I think one needs to add a
gfc_simplify_sum to simplify.c and replace then the NULL by the function name
in intrinsic.c for "sum". Possibly as well for
--- Comment #5 from burnus at gcc dot gnu dot org 2008-11-26 16:52 ---
> I think that patch is not enough (though useful!). I think one needs to add a
> gfc_simplify_sum to simplify.c
One probably needs an auxiliary function which iterates through an array either
along
: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38285
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-27 09:37 ---
This is a regression with regards to g77.
The email itself (for completeness):
http://j3-fortran.org/pipermail/j3/2008-November/002084.html
The problem only occurs for a d (Fw.d) of "0", for, e.g.
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-27 11:14 ---
(In reply to comment #0)
> POPCNT and POPPAR are present in many other compilers
And (even) more interestingly they are part of the Fortran 2008 Candidate
Release (as you also mentioned):
13.7.128 POPCNT
--- Comment #15 from burnus at gcc dot gnu dot org 2008-11-27 13:21 ---
I think PR is fixed on the trunk (4.4) [-> back porting?], except of the issue
of comment 13 (-> different PR?).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34143
--- Comment #16 from burnus at gcc dot gnu dot org 2008-11-27 13:24 ---
(Most problems have been fixed, except of the one in comment 0.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32795
Summary: "procedure( ), pointer" rejected
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-27 13:44 ---
Something for you?
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
nu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38291
--- Comment #20 from burnus at gcc dot gnu dot org 2008-11-28 12:52 ---
(In reply to comment #19)
> Since comment #13 is fixed, this should not be labeled a regression any more I
> guess. Are there still problems with comment #12 (apart from PR35810), or can
> we close this PR?
--- Comment #5 from burnus at gcc dot gnu dot org 2008-11-29 16:18 ---
(In reply to comment #4)
> Timings on x86_64-unknown-linux-gnu:
> matmul =12.840802 s
> subroutine without explicit interface: 0.88805580 s
> subroutine with explicit interface: 0.876
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38336
--- Comment #3 from burnus at gcc dot gnu dot org 2008-12-01 06:44 ---
> read( 50, *, pos = 1 )
> is valid only if the unit has been connected for STREAM access.
Well, (a) I don't see how this can be tested at compile time and (b) I thought
that
open(50,access='stre
--- Comment #5 from burnus at gcc dot gnu dot org 2008-12-01 16:40 ---
(In reply to comment #4)
> > > So the read statement by itself is invalid.
> > ???
>
> I was testing with and without the open statement in the test case and saw
> that we were not catchin
--- Comment #1 from burnus at gcc dot gnu dot org 2008-12-01 16:48 ---
The best message other compilers had are:
a) NAG f95:
Error: fgjf.f90, line 15: No specific match for reference to operator +
Error: fgjf.f90, line 15: Incompatible data types for the + operator
n the case of a separate binding label, that rule is being
changed in Fortran 2008 to be the way you want it. If there is a
separate binding label then the procedure's name becomes a local name,
not external.
--
Summary: Update BIND(C,name= checking for Fortran 2008
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38386
--- Comment #1 from burnus at gcc dot gnu dot org 2008-12-03 16:49 ---
If you write:
OPEN(UNIT=OUTPUT_UNIT, FILE="foo.dat")
then you want that all output to the OUTPUT_UNIT is written to the file
"foo.dat". And a asterix UNIT=* in a PRINT or WRITE statement den
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
--- Comment #3 from burnus at gcc dot gnu dot org 2008-12-04 07:07 ---
> I can kill this warning if I invoke gfortran with -nostdinc.
But won't that break programs which use e.g. include "netcdf.inc" which is in
/usr/include/netcdf.inc ?
--
http://gcc.gnu.org/bug
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38398
--- Comment #1 from burnus at gcc dot gnu dot org 2008-12-04 12:32 ---
Jerry, I've created this PR to make sure it won't get forgotten.
--
burnus at gcc dot gnu dot org changed:
What|Removed
ned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38425
--- Comment #7 from burnus at gcc dot gnu dot org 2008-12-06 12:25 ---
Check backed out in PR 38415, cf.
http://gcc.gnu.org/ml/fortran/2008-12/msg00089.html
"I'm afraid I'll have to remove the gfc_compare_interfaces check in
gfc_check_pointer_assign again, since I just
: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38432
--- Comment #1 from burnus at gcc dot gnu dot org 2008-12-06 22:18 ---
I wanted to write: That loop will never be run, sorry for the miswording.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
mponent: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38439
--- Comment #7 from burnus at gcc dot gnu dot org 2008-12-08 11:33 ---
(In reply to comment #6)
> To add the default paths defined in gcc/cppdefault.c (cpp_include_defaults) to
> the module/INCLUDE search path, one could clone gcc/incpath.c
> (add_standard_paths)
--- Comment #5 from burnus at gcc dot gnu dot org 2008-12-09 17:28 ---
(In reply to comment #4)
> For example, I tried to adapt the testcase in PR 33295 to the c_funloc case.
> The resulting program is rejected with the following error:
> Error: Can'
ed-type component
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc
--- Comment #1 from burnus at gcc dot gnu dot org 2008-12-10 15:35 ---
More information. The problem is:
GFC_DECL_SPAN(decl)
which accesses
DECL_LANG_SPECIFIC(node)->span
however, DECL_LANG_SPECIFIC(node) == NULL as can be seen below.
(gdb) p decl->decl_common.lang_specif
--- Comment #2 from burnus at gcc dot gnu dot org 2008-12-10 18:08 ---
Paul, do you have an idea?
span is set in trans-decl.c's gfc_get_symbol_decl:
if (sym->attr.subref_array_pointer)
{
[...]
GFC_DECL_SPAN (decl) = span;
I wondered wh
--- Comment #3 from burnus at gcc dot gnu dot org 2008-12-10 18:25 ---
OK. I found it, though I'm not sure yet how to solve it best (maybe something
else needs to be moved up as well?) - and I won't have time to work on this the
next day(s?).
gfc_get_symbol_decl (gfc_sy
--- Comment #4 from burnus at gcc dot gnu dot org 2008-12-11 10:12 ---
integer, dimension(:), pointer :: ipn
ipn=>sorb%i%j
I tried it with ipn being no dummy argument and it crashes as well.
And I forgot to write the name of the initial reporter in comment 0. The credit
--- Comment #1 from burnus at gcc dot gnu dot org 2008-12-11 16:07 ---
Mikael added this as part of PR 35681 with check in
http://gcc.gnu.org/viewcvs?view=rev&revision=141931
See:
http://gcc.gnu.org/viewcvs/trunk/gcc/fortran/dependency.c?r1=141931&r2=141930&pathrev=141931
--- Comment #10 from burnus at gcc dot gnu dot org 2008-12-11 16:13 ---
As fj pointed out: PR 38471 might be a duplicate of this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
--- Comment #7 from burnus at gcc dot gnu dot org 2008-12-11 16:18 ---
Created an attachment (id=16885)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16885&action=view)
pointer_assign_7.f90 - a test cae
As fj pointed out: This PR might be a duplicate of PR 34640. The patc
al <-> dummy
argument
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid, diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38506
--- Comment #2 from burnus at gcc dot gnu dot org 2008-12-12 16:19 ---
I have the gut feeling that the program in comment 1 is valid, even though
gfortran, g95, ifort and NAG f95 reject it. See PR 38506.
Regarding the c_loc: I think that should be possible; I'm not 100% sure wh
--- Comment #3 from burnus at gcc dot gnu dot org 2008-12-12 22:28 ---
What is about the obsolescent DO related part? Do we need to do something there
(from F95, B.2):
"Shared DO termination and termination on a statement other than END DO or
CONTINUE use an END DO or a CON
: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #6 from burnus at gcc dot gnu dot org 2008-12-13 11:19 ---
For completeness, on my x86-64-linux system I get with 4.4.0, 4.3.0 and with
openSUSE binaries (4.1, 4.2, 4.3, 4.4) always a single "-".
Hmm, OK found something: With -m32 I get "--" but with
--- Comment #1 from burnus at gcc dot gnu dot org 2008-12-15 09:44 ---
Answer by Bader:
"For generics, the "R" part of the TKR rule applies, which prohibits *both*
above cases."
=> gfortran does it right. (I'm not fully convinced, but I buy this.)
Diag
--- Comment #3 from burnus at gcc dot gnu dot org 2008-12-15 10:48 ---
I think the patch in comment 2 is about the wrong gfc_error.
Additionally, the generic resolution seems to be correct in gfortran (-> PR
38506).
* * *
In any case: I tried ifort, g95, NAG f95, gfortran, and sun
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
--- Comment #5 from burnus at gcc dot gnu dot org 2008-12-15 20:35 ---
(In reply to comment #4)
> > In any case: I tried ifort, g95, NAG f95, gfortran, and sunf95
> > - of these only "ifort" allows it
>
> as you said using C_LOC(X(1:1)) works fine and t
--- Comment #1 from burnus at gcc dot gnu dot org 2008-12-17 09:46 ---
For completeness: The compile-time check works in gfortran
character(len=10), target :: str
character(len=5), pointer :: ptr
ptr => str
end
Error: Different character lengths in pointer assignment at
--- Comment #2 from burnus at gcc dot gnu dot org 2008-12-17 09:56 ---
For Fortran 97 I found it; it is in the first sentence after the "Contrain:"s
"The target shall have the same type parameters as the pointer-object"
For Fortran 2003 I'm still searching (
ds: ice-on-invalid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38568
--- Comment #3 from burnus at gcc dot gnu dot org 2008-12-25 18:07 ---
> Works with 4.3:
Well, not really. gfortran 4.1/4.2/4.3 only call the module procedure, but for
"call f()" the contained procedure should be called, which does not work with
4.[1-3].
--
burnus a
1 - 100 of 4285 matches
Mail list logo
