[Bug fortran/38066] bug6 ambiguous reference
--- 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 should I append this existing one? It think appending would be preferred. (By the way, if you reply to the bug email, could you delete the quoted text? The reason is that the whole text of the email is added to the bugreport - including the quotes. The quoted text makes it more difficult hard to read through the comments using the web interface; quoting a line or two is OK, if one explicitly refers to those lines in the comment.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38066
[Bug fortran/38065] private/public confusion with a contained function
--- 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 of PRIVATE type 't1'
gfortran has two bugs:
a) F1 is an internal function and thus PUBLIC/PRIVATE does not apply
b) If one makes F1 a (PUBLIC) *module* function, the program still would be a
valid Fortran 2003 program (and an invalid Fortran 95 program).
I still need to test whether the original program is fixed or not; there are
quite a lot files ...
Fix:
+++ gcc/fortran/resolve.c (Arbeitskopie)
@@ -10181,0 +10182 @@ resolve_fntype (gfc_namespace *ns)
+ && !sym->attr.contained
@@ -10186,2 +10187,3 @@ resolve_fntype (gfc_namespace *ns)
- gfc_error ("PUBLIC function '%s' at %L cannot be of PRIVATE type '%s'",
-sym->name, &sym->declared_at, sym->ts.derived->name);
+ gfc_notify_std (GFC_STD_F2003, "Fortran 2003: PUBLIC function '%s' at "
+ "%L of PRIVATE type '%s'", sym->name,
+ &sym->declared_at, sym->ts.derived->name);
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--------
CC||burnus at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
[Bug fortran/38065] private/public confusion with a contained function
--- 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 AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-11-11 13:28:28 |2008-11-11 14:35:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
[Bug fortran/38066] bug6 ambiguous reference
--- 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: * NAG f95: Error: bug6M.f90, line 17: Symbol GETNULLSET found both in module PBIT4SET and in PBIT8SET detected at [EMAIL PROTECTED] Error: bug6M.f90, line 17: Symbol GETNULLSET found both in module PBIT4SET and in PBIT8SET detected at [EMAIL PROTECTED] * g95: In file bug6M.f90:22 END MODULE Bug6 1 Error: Name 'getnullset' at (1) is an ambiguous reference to 'getnullset' from module 'pbit4set' * ifort: bug6M.f90(17): error #6405: The same named entity from different modules and/or program units cannot be referenced. [GETNULLSET] CALL GetNullSet (search_set) * openf95: openf95-486 openf95: ERROR SUB_A, File = bug6M.f90, Line = 17, Column = 12 "GETNULLSET" has been use associated from module "PBIT4SET" and at least one more module. It must not be referenced. > The NAG, Intel and g95 compilers all compile this code. Hmm, not here! You have in bug6M.f90: USE PBit4Set USE PBit8Set That makes the following two getNullSet available: pure subroutine getNullSet (ANullSet) ! In pbit4setM.f90 type (TPBit4Set), intent(out) :: ANullSet pure subroutine getNullSet (ANullSet) ! In pbit8setM.f90 type (TPBit8Set), intent(out) :: ANullSet If you now call "getNullSet" you have a problem since getNullSet exists in both PBit4Set and PBit8Set. (Note: "getNullSet" is *not* a generic interface.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38066
[Bug fortran/38065] private/public confusion with a contained function
--- 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]> PR fortran/38065 * resolve.c (resolve_fntype): Fix private derived type checking. 2008-11-12 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/38065 * gfortran.dg/private_type_11.f90: New test. * gfortran.dg/private_type_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/private_type_11.f90 trunk/gcc/testsuite/gfortran.dg/private_type_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
[Bug fortran/38065] private/public confusion with a contained function
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
[Bug fortran/38094] [4.4 regression] gfortran.dg/private_type_4.f90 -O doesn't work
--- 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]> PR fortran/38065 PR fortran/38094 * gfortran.dg/private_type_4.f90: Add -std=f95 option. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/private_type_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38094
[Bug fortran/38065] private/public confusion with a contained function
--- 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]> PR fortran/38065 PR fortran/38094 * gfortran.dg/private_type_4.f90: Add -std=f95 option. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/private_type_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38065
[Bug fortran/38094] [4.4 regression] gfortran.dg/private_type_4.f90 -O doesn't work
--- 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 |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38094
[Bug fortran/38094] [4.4 regression] gfortran.dg/private_type_4.f90 -O doesn't work
--- 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]> PR fortran/38094 * gfortran.dg/private_type_4.f90: Fix dg-error pattern. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/private_type_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38094
[Bug fortran/38094] [4.4 regression] gfortran.dg/private_type_4.f90 -O doesn't work
--- 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 > "Fortran 2003: PUBLIC variable 'f1' at (1) of PRIVATE derived type 't1'". I > think the second is due to the error being emitted twice, as noted in comment > #2. That is really the disadvantage of having two branches: In my read-only svn-tree I fixed it and regtested - the commit svn tree I had the old patch, partial patch [i.e. I did too early "(cd -; svn diff)|patch -p0"]. Today is really not my day :-( Hopefully, it is now really FIXED! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38094
[Bug fortran/38095] character ICE
--- 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 (trans-expr.c:2133)
==2910==by 0x49D13E: gfc_conv_expr_descriptor (trans-array.c:4717)
==2910==by 0x4A033B: gfc_conv_array_parameter (trans-array.c:5272)
==2910==by 0x4B1A80: gfc_conv_function_call (trans-expr.c:2680)
That line is:
switch (expr->value.function.isym->id)
{
case GFC_ISYM_LEN:
/* TODO figure out why this condition is necessary. */
if (sym->attr.function
&& arg1->ts.cl->length->expr_type != EXPR_CONSTANT
&& arg1->ts.cl->length->expr_type != EXPR_VARIABLE) // <- LINE 1916
The TODO was added by Paul in Rev. 130988. The cited bugreports were
PR 31213, PR 33888 and PR 33998.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC| |burnus at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2008-11-12 22:37:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38095
[Bug fortran/38095] character ICE
--- 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://gcc.gnu.org/ml/fortran/2007-12/msg00160.html is the mail to the patch which added the TODO line.) Using the following patch and calling xmain, the program prints "size(labels)= 1". --- trans-expr.c(Revision 141811) +++ trans-expr.c @@ -1912,8 +1912,9 @@ gfc_map_intrinsic_function (gfc_expr *ex case GFC_ISYM_LEN: /* TODO figure out why this condition is necessary. */ if (sym->attr.function - && arg1->ts.cl->length->expr_type != EXPR_CONSTANT - && arg1->ts.cl->length->expr_type != EXPR_VARIABLE) + && (arg1->ts.cl->length == NULL + || (arg1->ts.cl->length->expr_type != EXPR_CONSTANT + && arg1->ts.cl->length->expr_type != EXPR_VARIABLE))) return false; new_expr = gfc_copy_expr (arg1->ts.cl->length); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38095
[Bug fortran/38095] character ICE
--- 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 regards to gfortran 4.1, 4.2 and 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38095
[Bug libfortran/38097] I/O with blanks in exponent fails; blank="NULL", BN edit descriptor
--- 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 interpretation mode (9.4.5.4, 9.5.1.5) for the connection. The edit descriptors BN and BZ set the blank interpretation mode corresponding to the BLANK= specifier values NULL and ZERO, respectively. The blank interpretation mode controls the interpretation of nonleading blanks in numeric input fields. Such blank characters are interpreted as zeros when the blank interpretation mode has the value ZERO; they are ignored when the blank interpretation mode has the value NULL. The effect of ignoring blanks is to treat the input field as if blanks had been removed, the remaining portion of the field right justified, and the blanks replaced as leading blanks. However, a field containing only blanks has the value zero. "The blank interpretation mode affects only numeric editing (10.6.1) and generalized numeric editing (10.6.4.1) on input. It has no effect on output." "9.4.5.4 BLANK= specifier in the OPEN statement "The scalar-default-char-expr shall evaluate to NULL or ZERO. The BLANK= specifier is permitted only for a connection for formatted input/output. It specifies the current value of the blank interpretation mode (10.7.6, 9.5.1.5) for input for this connection. This mode has no effect on output. It is a changeable mode (9.4.1). If this specifier is omitted in an OPEN statement that initiates a connection, the default value is NULL." Thus it should work with default settings. Not surprisingly (as g77 works), BZ/BN are also part of Fortran 95. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-redhat-linux | GCC host triplet|x86_64-redhat-linux | GCC target triplet|x86_64-redhat-linux | Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2008-11-13 15:49:23 date|| Summary|gfortran does not allow |I/O with blanks in exponent |blanks in exponent in float |fails; blank="NULL", BN edit |(even with BN) |descriptor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38097
[Bug libfortran/37294] Namelist I/O to array character internal units
--- 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 write(line,nml=stuff) which worked before. The true solution would be to do the same as NAG f95 does (cf. comment 2), but the challenge is to do is such that there is no performance penalty for code which fits into one line / for scalars. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37294
[Bug fortran/38119] New: [4.4 Regression] character ICE in gfc_trans_create_temp_array
+++ This bug was initially created as a clone of Bug #38095 +++
In trying to reduce the ICE, Mikael Morin actually found a different ICE:
--- Bug #38095 Comment #8 From Mikael Morin 2008-11-12 22:43 ---
I tried to reduce the case.
module bar
implicit none
contains
!
elemental function trim_append(xx,yy) result(xy)
character (len=*), intent(in) :: xx,yy
character (len=len(xx) + len(yy)) :: xy
xy = xx // yy
end function trim_append
!
function same(xx) result(yy)
character (len=*), intent(in) :: xx(:)
character (len=len(xx)) :: yy(size(xx))
yy = xx
end function same
!
subroutine xmain()
character(len=2) :: c(1)
c = trim_append(["a"],same(["b"]))
end subroutine xmain
!
end module bar
pr38095.f90:5: erreur interne du compilateur: dans gfc_trans_create_temp_array,
à fortran/trans-array.c:648
Veuillez soumettre un rapport complet d'anomalies,
avec le source pré-traité si nécessaire.
Consultez <http://gcc.gnu.org/bugs.html> pour plus de détail.
I bet some of you guys recognize that old friend of ours, PR31610, whose patch
was reverted in PR37903.
Of course characters are a special (understand: not working) case. Argh!
This is probably unrelated to the original ICE though.
--
Summary: [4.4 Regression] character ICE in
gfc_trans_create_temp_array
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 dot gnu dot org
BugsThisDependsOn: 38095
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38119
[Bug fortran/38119] [4.4 Regression] character ICE in gfc_trans_create_temp_array
--- 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 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38119
[Bug fortran/38095] character ICE
--- 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 > regression with regards to gfortran 4.1, 4.2 and 4.3. I filled PR38119 for that PR. For my patch, it worked at least for the test case, since I currently cannot boot strap (PPL linking problem), I cannot regtest :-( If someone wants to take over ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38095
[Bug fortran/38122] "file already opened in another unit" error when opening /dev/null or /dev/tty twice
--- 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 that runs in an older version that doesn't run in a new > version. This problem will cause people to use the old version of the > compiler. The problem with accessing the same file with different I/O units is that it quickly leads to race conditions; for /dev/null I don't see any problem, but for a normal, seekable file like "my_data_file.dat" this is different. See also: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/bd22f289feb99d22/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38122
[Bug fortran/38135] New: FORALL gives wrong result
I expect that the following program prints:
122
212
221
1000
which works with g95 and ifort, but with gfortran one gets:
11*
7211
* 721
1000
The program is a minutely modified version of the program posted to c.l.f by
James Van Buskirk at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e7ec475ff7935804
integer, parameter :: N = 3
integer A(N,N)
A(1:N,1:N)=reshape([integer::],[N,N],reshape([1],[N+1],[2]))
write(*,'(3i5)') A
write(*,'(4i5)') reshape([1],[N+1],[0])
end
--
Summary: FORALL gives wrong result
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-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=38135
[Bug fortran/38135] FORALL gives wrong result
--- 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 changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38095] character ICE
--- 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 gfortran versions and is fixed by the patch in comment 10. The program of comment 8 and thus of PR 38119 fails only with gfortran 4.4 (= regression) and ICEs at a completely different place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38095
[Bug fortran/38137] New: MERGE: -fbounds-check runtime check for same string length
Follow up to PR 33455.
"13.7.75 MERGE (TSOURCE, FSOURCE, MASK)"
"FSOURCE shall be of the same type and type parameters as TSOURCE."
In the following program, the string length is different. If the string length
were known at compile time, an error would have been printed, but there is no
run-time check
subroutine foo(a)
implicit none
character(len=*) :: a
character(len=3) :: b
print *, merge(a,b,.true.) ! Unequal character lengths
end subroutine foo
call foo("ab")
end
--
Summary: MERGE: -fbounds-check runtime check for same string
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 at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38137
[Bug fortran/31610] ICE with transfer, merge in gfc_conv_expr_descriptor
--- 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
[Bug fortran/38138] [4.4 Regression] Revision 141890 caused gfortran.dg/proc_decl_18.f90
--- 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)
==32084==by 0x460FEA: gfc_parse_file (parse.c:3805)
==32084==by 0x49083C: gfc_be_parse_file (f95-lang.c:236)
[...]
==32084== Invalid read of size 8
==32084==at 0x4824B7: gfc_commit_symbols (symbol.c:2821)
==32084==by 0x45D94C: accept_statement (parse.c:1503)
==32084==by 0x460FEA: gfc_parse_file (parse.c:3805)
==32084==by 0x49083C: gfc_be_parse_file (f95-lang.c:236)
2815 gfc_commit_symbols (void)
2816 {
2817gfc_symbol *p, *q;
2818
2819for (p = changed_syms; p; p = q)
2820 {
2821q = p->tlink;
2822p->tlink = NULL;
2823p->mark = 0;
2824p->gfc_new = 0;
2825free_old_symbol (p);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38138
[Bug fortran/38095] character ICE
--- 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]> PR fortran/38095 * trans-expr.c (gfc_map_intrinsic_function): Fix pointer access. 2008-11-16 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/38095 * gfortran.dg/char_length_13.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_length_13.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38095
[Bug fortran/38095] character ICE
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38095
[Bug fortran/38160] New: C Binding: Kind parameter checking too strict and too late
Found in the README to http://www.lrz-muenchen.de/services/software/mathematik/gsl/fortran/ gfortran is quite picky with regards to the C binding type, i.e. it does not like use iso_c_binding complex(c_double),target :: z ! correct would be: c_double_complex however it is not failing right a way, but it is only failing when using C_LOC: type(c_ptr) :: ptr ptr = c_loc(z) Error: C kind parameter is for type REAL but symbol 'z' at (1) is of type COMPLEX ISSUES: a) The error should already printed for the declaration and not for C_LOC() (The same checking is also done for the dummy arguments of BIND(C) procedures.) b) The question is whether one needs an error or whether a warning is enough (For completeness, the author did not reply to my request to change the code of FGLS.) -- Summary: C Binding: Kind parameter checking too strict 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 gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38160
[Bug fortran/38152] ICE for procedure pointer assignment
--- 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 seems to work; one probably still needs
to take care of mangling of the name etc. Also there needs to be a check for
use-/host- association (cf. a few lines down and in gfc_finish_var_decl),
adding those flags unconditionally is surely wrong.
--- trans-decl.c(revision 141928)
+++ trans-decl.c(working copy)
@@ -1021,2 +1021,7 @@ gfc_get_symbol_decl (gfc_symbol * sym)
decl = gfc_get_extern_function_decl (sym);
+ if (sym->attr.proc_pointer)
+ {
+ TREE_PUBLIC (decl) = 1;
+ TREE_STATIC (decl) = 1;
+}
return decl;
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC| |burnus at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/38188] Inconsistent function results depending on irrelevant write statement
--- 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, which has an undefined value. minval = +INF maxval = -INF How about: minval = huge(minval) ! largest finite value maxval = -huge(minval)! smallest finite value or shorter (untested) min = minval(arr( [(1+kcycle*i, i=0,npts-1)] ) max = maxval(arr( [(1+kcycle*i, i=0,npts-1)] ) where (g)Fortran does internally what you want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38188
[Bug libfortran/25830] [libgfortran] Optionally support multi-process locking
--- 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/software/products/compilers/docs/flin/main_for/lref_for/source_files/rflioop.htm I think Fortran 2008 does not allow to such access which makes it a non-issue in terms of the standard, including for coarrays, but still this is a not so rarely requested feature. (But one has to be careful as a user otherwise the program might read/write garbage.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25830
[Bug fortran/38199] [4.4 regression] I/O performance
--- 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 optimization and has to read past all blanks). -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org Keywords||missed-optimization Priority|P3 |P4 Summary|missed optimization,|[4.4 regression] I/O |regression: I/O performance |performance http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
[Bug fortran/38205] New: Tranformational function SUM rejected in initialization expressions
The following program fails with:
Error: transformational intrinsic 'sum' at (1) is not permitted in an
initialization expression
I think it is valid Fortran 2003 per "7.1.7 Initialization expression":
"(5) A reference to a transformational standard intrinsic function other than
NULL, where each argument is an initialization expression"
Note: Fortran 95 7.1.7.1 the program is invalid (only few transformational
functions are allowed).
Found by James Van Buskirk:
http://groups.google.com/group/comp.lang.fortran/msg/2119be02dcf93517
integer, parameter :: a = sum([1,2])
print *, a
end
--
Summary: Tranformational function SUM rejected in initialization
expressions
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=38205
[Bug fortran/38184] invariant RESHAPE not expanded if SOURCE is empty
--- 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 dot org changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38184
[Bug fortran/38160] C Binding: Kind parameter checking too strict and too late
--- 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]> PR fortran/38160 * trans-types.c (gfc_validate_c_kind): Remove function. * decl.c (gfc_match_kind_spec): Add C kind parameter check. (verify_bind_c_derived_type): Remove gfc_validate_c_kind call. (verify_c_interop_param): Update call. * gfortran.h (verify_bind_c_derived_type): Update prototype. (gfc_validate_c_kind): Remove. * symbol.c (verify_bind_c_derived_type): Update verify_c_interop * call. * resolve.c (gfc_iso_c_func_interface): Ditto. 2008-11-22 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/38160 * gfortran.dg/bind_c_usage_18.f90: New test. * gfortran.dg/c_kind_tests_2.f03: Update dg-messages. * gfortran.dg/interop_params.f03: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/bind_c_usage_18.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_kind_tests_2.f03 trunk/gcc/testsuite/gfortran.dg/interop_params.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38160
[Bug fortran/38160] C Binding: Kind parameter checking too strict and too late
--- 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 Status|UNCONFIRMED |RESOLVED Keywords||rejects-valid Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38160
[Bug fortran/37779] Missing RECURSIVE not detected
--- 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 sub end subroutine test NAG f95 detects this: Error: hfjf.f90, line 7: Invalid recursive self-reference to TEST as does openf95: openf95-343 openf95: ERROR SUB, File = hfjf.f90, Line = 5, Column = 10 A RECURSIVE keyword must be declared for a subprogram so that the subprogram can be called recursively. ifort, g95 and gfortran accept this program. (Can be also moved into a different PR.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37779
[Bug fortran/37779] Missing RECURSIVE not detected
--- 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=37779
[Bug fortran/38205] Tranformational function SUM rejected in initialization expressions
--- 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
[Bug fortran/38152] ICE for procedure pointer assignment
--- 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
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- 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
[Bug fortran/38248] Fatal Error: Reading module mmm: Expected left parenthesis
--- 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's libgfortran.so, for .mod files this is not the case. (.mod files are not like *.h files compiler independent, but simply a "binary" dump of the interfaces of a single module.) I think a solution would be to create a version number for the .mod data and add a checking. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC| |burnus at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38248
[Bug fortran/38247] problem with contained subprocedure.
--- 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: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38247
[Bug fortran/38249] read(*,*) seems to have broken
--- 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 needs to be
careful: By default, every character after column 72 is ignored; I forgot how
this interplays with tabs (i.e. whether they count as 1 or as 6 spaces).
The line "read(*,*)x,y" looks harmless and of cause works here with a simple
test program; the line should work since early gfortran 4.0.0.
Can you attach a minimal program which fails? And include the exact command you
entered and the exact gfortran version ("gcc version" and the "Target:" line
shown by "gfortran -v").
Additionally, you could try a newer version, cf.
http://gcc.gnu.org/wiki/GFortranBinaries, though I would expect that this does
not help as the problem is probably elsewhere. (I'd expect that it is a bug in
your program.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38249
[Bug fortran/38252] [4.4 Regression] Empty function with CONTAINS triggers Internal Error
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Summary|Empty function with CONTAINS|[4.4 Regression] Empty |triggers Internal Error |function with CONTAINS ||triggers Internal Error Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38252
[Bug fortran/38248] Ignored temporary module files manipulation errors
--- 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]> PR fortran/38248 * module.c (gfc_dump_module): Check rename/unlink syscalls errors. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38248
[Bug fortran/38259] New: Add version number to .mod file
Currently, there are only strange parenthesis-related error messages given if an old, incompatible .mod file is used with a newer compiler, e.g. Fatal Error: Reading module mmm at line 16 column 65: Expected left parenthesis (cf. also PR 38248). The solution is to add a version number which is always bumped if a .mod related change happened, which presumably was the case for all new GCC/gfortran releases. -- Summary: Add version number to .mod file 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 gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38259
[Bug fortran/38273] New: Cray pointers: Document that
http://groups.google.com/group/comp.lang.fortran/msg/b535884fdbd62f39
Intel has: in the manual
"A pointer cannot be a function return value."
As gfortran also rejects it,
Error: CRAY POINTER attribute conflicts with FUNCTION attribute at (1)
one could also add it to the manual, or to say it in James Van Buskirk's words:
"We can see that gfortran doesn't like function results to be cray
pointers either, although I can't find this in the gfortran manual."
--
Summary: Cray pointers: Document that
Product: gcc
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
[Bug fortran/38205] Tranformational function SUM rejected in initialization expressions
--- 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 the other transformational intrinsics which are allowed in initialization expressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38205
[Bug fortran/38205] Tranformational function SUM rejected in initialization expressions
--- 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 a dim= (-> return a scalar) or if not present, it returns a expr->rank sized array. To be used with PRODUCT and SUM at least. gfc_simplify_reshape might give some idea, though that assumes that source is a rank == 1 array. (Maybe get_expr_storage_size gives also some ideas.) Currently not simplified are: - ALL/ANY/COUNT - cshift/eoshift - dot_product/matmul - (max|min)(loc|val) - note: (max|min)val is implemented for rank == 1 w/o dim - pack/unpack - spread - transpose -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38205
[Bug fortran/38285] New: Wrong I/O output: Interaction between F and P for output
Found on the J3 mailing list. gfortran is the compiler which prints "0.0"as second number (4.1 to 4.4); ifort, g95, NAG f95, openf95 and sunf95 print the 3742 twice. Van Snyder writes: The list items in subclause 10.8.5 "P editing" of 08-007r2 that begin "On output,..." are silent concerning the effect of P editing on F editing for output. The specification of the effect of P on F during output is hiding in the first list item, which begins "On input," With the little program program F_and_P print 1, 3742.0, 0.3742 1 format ( f14.0, 4pf14.0 ) end program F_and_P five of my six compilers produce a program that (correctly) prints 3742. 3742. while one (incorrectly) prints 3742. . This treatment of F and P interaction goes back to F66 (7.2.3.5.1, 7.2.3.6.2), F77 (13.5.7.1, 13.5.9.2.1), and f90/95 (10.6.5, 10.5.1.2.1). The effect of P on F output would be more clearly explained in a separate list item, say between the second and third items. I don't think it's possible to rearrange the first list item both to be correct and not to hide either the input or output effect. -- Summary: Wrong I/O output: Interaction between F and P for output Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-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=38285
[Bug fortran/38285] Wrong I/O output: Interaction between F and P for output
--- 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., "4PF14.1" gfortran and the other compilers print: "3742.0". Thus, I think the problem is the special case for abs(internal number) < 0 together with Fw.d with d == 0. >From the F2003 standard: "10.7.5 P editing" "The kP edit descriptor temporarily changes (9.4.1) the scale factor for the connection to k. The scale factor affects the editing of F, E, EN, ES, D, and G edit descriptors for numeric quantities." [...] "(1) On [...] F output editing, the scale factor effect is that the externally represented number equals the internally represented number multiplied by 10^k." -- burnus at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.3 4.2.1 4.3.2 4.4.0 Known to work||3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38285
[Bug fortran/38282] Add the remaining HPF bit intrinsics
--- 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 (I) Description. Number of one bits. Class. Elemental function. Argument. I shall be of type integer. Result Characteristics. Default integer. Result Value. The result value is equal to the number of one bits in the sequence of bits of I. The model for the interpretation of an integer value as a sequence of bits is in 13.3. 13.7.129 POPPAR (I) Description. Parity expressed as 0 or 1. Class. Elemental function. Argument. I shall be of type integer. Result Characteristics. Default integer. Result Value. POPPAR (I) has the value 1 if POPCNT (I) is odd, and 0 if POPCNT (I) is even. * * * For completeness: Fortran 2008 and also the HPF standard also list the following "Array Reduction Functions" (HPF): - IALL - Bitwise AND of all the elements of ARRAY along dimension DIM corresponding to the true elements of the mask - IANY - Bitwise OR of all the elements of ARRAY along dimension DIM corresponding to the true elements of MASK. - IPARITY - Bitwise exclusive OR of all the elements of ARRAY along dimension DIM corresponding to the true elements of MASK. - PARITY - True if and only if an odd number of values are true in MASK along dimension DIM. And Fortran 2008 also the following elemental procedures for bits: - DSHIFTL(I,J,SHIFT) - Combined left shift - DSHIFTR(I,J,SHIFT) - Combined right shift - SHIFTA - Right shift with fill. - SHIFTL - Left shift - SHIFTR - Right shift - MASKL Left justified mask - MASKR - Right justified mask - BGE - True if and only if I is bitwise greater than or equal to J - BGT - True if and only if I is bitwise greater than J. - BLE - True if and only if I is bitwise less than or equal to J - BLT - True if and only if I is bitwise less than J. - MERGE_BITS - Merge of bits under mask -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug fortran/34143] alloc_comp_constructor.f90 fails with -fdefault-integer-8
--- 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
[Bug fortran/32795] allocatable components are nullified prematurely
--- 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
[Bug fortran/38289] New: "procedure( ), pointer" rejected
Found at
http://de.wikibooks.org/wiki/Fortran:_Fortran_2003:_Zeiger
The following is rejected because of the space in "( )". With "()" it compiles:
procedure( ), pointer :: pptr => null()
1
Error: Syntax error in PROCEDURE statement at (1)
--
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
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38289
[Bug fortran/38290] New: ICE with invalid proc-pointer
Found at http://de.wikibooks.org/wiki/Fortran:_Fortran_2003:_Zeiger
The following program gives an ICE:
hjff.f90:4.34:
procedure( up ), pointer :: pptr => null()
1
Error: Interface 'up' of procedure 'pptr' at (1) must be explicit
hjff.f90:4.15:
procedure( up ), pointer :: pptr => null()
1
Error: Symbol 'up' at (1) has no IMPLICIT type
f951: internal compiler error: in resolve_specific_s0, at
fortran/resolve.c:2758
Please submit a full bug report,
program bsp
implicit none
procedure( up ), pointer :: pptr => null()
pptr => ooops
call pptr
end program bsp
--
Summary: ICE with invalid proc-pointer
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: 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=38290
[Bug fortran/38289] "procedure( ), pointer" rejected
--- 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 CC||janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38289
[Bug fortran/38291] New: Rejects I/O with POS= if FMT=*
Found at http://de.wikibooks.org/wiki/Fortran:_Fortran_2003:_Ein-_und_Ausgabe The following is valid and the error message is bogus: read( 50, *, pos = 1 ) 1 Error: FMT=* is not allowed with a REC= specifier at (1). open(50,access='stream') read( 50, *, pos = 1 ) end -- Summary: Rejects I/O with POS= if FMT=* 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 ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38291
[Bug fortran/36463] gfc_get_default_type(): Bad symbol
--- 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? I think only PR 35971, comment 0 (with modification of PR 35971 comment 2) and [essentially/exactly the same] comment 12 of this PR remain (= compiles, but ICE at run time). I don't see ad hoc whether PR 35810 is the problem; if you close this PR, can you add a note to the PR that one should re-check PR 35971, comment 0 and PR 36463, comment 12 before closing? That way we are sure that the test case does not get lost, if PR 35810 does not fix the remaining issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug fortran/37131] inline matmul for small matrix sizes
--- 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.87605572 s
> inline with sum 2.0721283 s
With -O2 I get:
matmul =10.724670 s
subroutine without explicit interface:7.7324829 s
subroutine with explicit interface:7.8684921 s
inline with sum 7.7684860 s
Only with I get with -O3 -ffast-math -march=native on AMD64 the following:
matmul =10.65 s
subroutine without explicit interface: 0.91205692 s
subroutine with explicit interface: 0.82805157 s
inline with sum 2.4521542 s
For comparison with ifort ("loop was vectorized" in lines 40, 41, 43):
matmul =2.660166 s
subroutine without explicit interface: 0.000E+00 s
subroutine with explicit interface: 0.000E+00 s
inline with sum 0.000E+00 s
and openf95 -O3:
matmul = 1.26807904 s (-O2: 28.2537651 s)
subroutine without explicit interface: 1.07606697 s (4.07225418)
subroutine with explicit interface: 1.05206609 s (4.08025742)
inline with sum 0.748046875 s (3.7522316)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC| |burnus at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131
[Bug middle-end/38336] New: fold_builtin_memory_op generates invalid GIMPLE
See http://gcc.gnu.org/ml/fortran/2008-11/msg00398.html for details.
With some gfortran allocatation patch, the middle end generates invalid GIMPLE
at any optimization level (but -O0). The difference between two
-fdump-tree-original (-O0 and with optimization) looks as follows:
ERRMSG.12 = &"Attempt to deallocate an unallocated object"[1]{lb: 1 sz:
1};
-ERRMSG.12 = stat.11 != 0 ? (void) __builtin_memcpy ((void *) &err, (void
*) ERRMSG.12, 30) : (void) 0;
+ERRMSG.12 = stat.11 != 0 ? err = *(character(kind=1)[1:30] * {ref-all})
ERRMSG.12 : (void) 0;
The invalid GIMPLE later generates an ICE of the kind:
a.f90:16: internal compiler error: verify_gimple failed
Richard wrote:
> (see builtins.c:fold_builtin_memory_op)
--
Summary: fold_builtin_memory_op generates invalid GIMPLE
Product: gcc
Version: 4.4.0
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
[Bug fortran/38291] Rejects I/O with POS= if FMT=*
--- 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='stream') is doing so. > So the read statement by itself is invalid. ??? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38291
[Bug fortran/38291] Rejects I/O with POS= if FMT=*
--- 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 catching that error either. Ah, you are also talking about the run-time check in the library and not only about the compile-time check in f951. > I will post the patch tonight. Thanks a ton! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38291
[Bug fortran/38351] poor error message
--- 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 b) openf95: openf95-380 openf95: ERROR MAIN__, File = fgjf.f90, Line = 15, Column = 4 No specific match to the defined generic operation "+" can be found. All others, including ifort and Lahey have less useful messages such as (Lahey): 2104-S: "SOURCE.F90", line 15, column 4: Combination of operand types invalid. Admittedly, the message of gfortran - while essentially the same - is less helpful has the mentioning of the TYPEs is misleading. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38351
[Bug fortran/38386] New: Update BIND(C,name= checking for Fortran 2008
At the J3 / WG5 mailing list (reply by Bill Long):
Reinhold Bader wrote:
> >
> > before taking this offline, I'd like to understand something about BIND(C)
> > which other people might know ...
> >
> > Take the following example program:
> >
> > module mod_label_interf
> > use, intrinsic :: iso_c_binding
> > implicit none
> > interface foo
> > subroutine foo_1(x, n, i) bind(c, name='Foo')
> > import :: c_float, c_int
> > real(c_float) :: x
> > integer(c_int), value :: n, i
> > end subroutine
> > subroutine foo_2(x, n, i) bind(c, name='Foo')
> > import :: c_float, c_int
> > real(c_float) :: x(*)
> > integer(c_int), value :: n, i
> > end subroutine
> > end interface
> > end module
> > program label_interf
> > use mod_label_interf
> > implicit none
> > integer(c_int) :: i
> > real(c_float) :: xx, xxx(3)
> > i = 2
> > call foo(xx, 1, i)
> > call foo(xxx, 3, i)
> > write(*, *) xx
> > write(*, *) xxx
> > end program
> >
> > together with the C implementation
> >
> > #include
> >
> > void Foo(float *x, int n, int i) {
> > int j;
> > for (j=0; j > *(x+j) = (float) (i + j) + 0.1;
> > }
> > }
> >
> > This code is accepted by various processors and executes in accordance with
> > my
> > personal expectations (for what that is worth :-)).
> > It is not accepted by NAG's compiler, and also not by IBM xlf. NAG's error
> > message is
> >
> > Error: label_interf.f90: Duplicate binding label 'Foo' for external
> > procedure FOO_2 and external procedure FOO_1
> >
This error message is consistent with the Fortran 2003 rules. An
(non-abstract) interface declares the procedure name to be external.
However, in 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
[Bug fortran/38382] Open(Unit=6 fails
--- 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 denotes the OUTPUT_UNIT. In many compilers, including gfortran, the standard output is unit 6, the standard error output is 0 (ERROR_UNIT) and the standard input unit is 5 (= INPUT_UNIT). (The constants such as OUTPUT_UNIT are defined in the intrinsic module "ISO_FORTRAN_ENV".) As a general advise, you should try not to use unit numbers smaller than 10 as some of them are likely to have a special meaning, depending on the compiler; especially the numbers 0, 5, 6 should be avoided (unless you want to redirect stdin/stderr/stdout). If a compiler prints "Hello" to the screen for the following program, it is invalid according to the Fortran 2003 standard, previous Fortran standard have not specified this. use iso_fortran_env ! Needs a (partially) Fortran 2003 supporting compiler open(unit=OUTPUT_UNIT, file="foo.txt") print *, "Hello" end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38382
[Bug fortran/38389] New: (DE)ALLOCATE compile time check for same variable
The Intel Fortran compiler has: error #8112: The same name cannot be specified more than once in a DEALLOCATE statement. [X] deallocate(x, x, errmsg=err) ^ Expected: Similar diagnostics for gfortran -- Summary: (DE)ALLOCATE compile time check for same variable 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38389
[Bug fortran/36457] preprocessing: option -idirafter undefined for fortran
--- 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/bugzilla/show_bug.cgi?id=36457
[Bug fortran/38398] New: g0.w edit descriptor: Update for F2008 Tokyo meeting changes
The current g0.w edit descriptor implementation is based on the F2008 comment resolution at J3 resolution. Afterwards there was the Tokyo WG5, which also addressed ISO member comments. Unfortunately, the g0. was changed a bit. At the WG5 meeting in Tokyo, one agreed on the following modified version, see ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1760.txt: "2.6 Generalized output editing A similar feature has been added, see 08-296r2." That is the following paper: http://www.j3-fortran.org/doc/year/08/08-296r2.txt I think the current implementation (see PR 37228) is based on http://j3-fortran.org/doc/year/08/08-251r3.txt and http://www.j3-fortran.org/doc/year/08/08-272.html "In the original J3 response, 08-251r3, G0.d, like G0, was defined in terms of the ESw.d format, meaning that even values close to zero would be shown in E format, unlike the Gw.d format (for w>0) which would choose F format for such values. N1743 suggested that G0 and G0.d behave more like Gw.d in such cases and J3 agrees." Currently, gfortran prints: 3.4500E+00 ES10.4 3.4500 F10.4 3.450 g10.4 3.4500E+00 g0.4 Note that contrary to the other edit descriptors: "that any leading or trailing blanks are removed. If I read the new proposal correctly, the out should not be: "3.450" without heading spaces. * * * Per C1007+, the e may not be specified for g0, e.g. "g0.4e4" gfortran rejects this, but with a rather strange error message: print '(g0.4e4)', 3.45 1 Error: Period required in format specifier at (1) -- Summary: g0.w edit descriptor: Update for F2008 Tokyo meeting changes 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=38398
[Bug fortran/38398] g0.w edit descriptor: Update for F2008 Tokyo meeting changes
--- 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 |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38398
[Bug fortran/38425] New: I/O: POS= compile-time diagnostics
Cf. http://gcc.gnu.org/ml/fortran/2008-12/msg00043.html !-- character(len=30) :: str open(3,access='stream') ! C919 (R913) If io-unit is not a file-unit-number, the ! io-control-spec-list shall not contain a REC= specifier ! or a POS= specifier. write(str,*, pos=4) 5 ! C927 (R913) If a POS= specifier appears, the ! io-control-spec-list shall not contain a REC= specifier. write(3,pos=5,rec=4) 5 !Fortran runtime error: REC=specifier must be positive write(3,rec=-3) 44 !Fortran runtime error: POS=specifier must be positive write(3,pos=-4) 44 end -- Summary: I/O: POS= compile-time diagnostics 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 gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38425
[Bug fortran/38290] procedure pointer assignment checking
--- 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 noticed that it has lots of problems with intrinsics (both in lvalue and rvalue)" -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|janus at gcc dot gnu dot org|burnus at gcc dot gnu dot | |org Status|REOPENED|ASSIGNED Last reconfirmed|2008-12-02 11:46:51 |2008-12-06 12:25:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290
[Bug fortran/38432] New: Add warning for endless loops
Ignoring overflows, the following program would run for ever. NAG f95 prints the Warning: DO loop has zero iteration count integer :: i do i = 1, -3, 1 end do end -- Summary: Add warning for endless loops 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 gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38432
[Bug fortran/38432] Add warning for loops which are never executed
--- 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 Summary|Add warning for endless |Add warning for loops which |loops |are never executed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38432
[Bug fortran/38439] New: I/O PD edit descriptor inconsistency
Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/2fc107eda65d9065 The following code WRITE (*,'(1PD24.15E4)') 1.0d0 end is rejected in gfortran 4.2 to 4.4 with: Error: Period required in format specifier at (1) (and ifort, NAG f95 and g95 also reject it). It is accepted with openf95, sunf95 and gfortran 4.1 [the latter with a warning matching the error message above], and it is said to be accepted with g77. The compiled programs then prints: 1.000D+ (note the "D") Using the run-time version of the format string, i.e. character(len=25) :: str str = '(1PD24.15E4)' WRITE (*,str) 1.0d0 end it works with gfortran (4.1 to 4.4) and with g95. The PD edit descriptor was always invalid according to the Fortran standard, using '(1PE24.15E4)' works with all compilers and is valid (but it prints "...E+" not "D"). The question is now whether a) One accepts it with, e.g., -std=legacy. (The error message should then point to the -std=legacy option) -- or -- b) One checks whether on can get rid of the "D" support in libgfortran to save some microseconds; libgfortran should then also print a run-time error message. -- Summary: I/O PD edit descriptor inconsistency 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=38439
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- 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) and call gfc_add_include_path() instead of add_path().
>
> Tobias, do we still need/want this?
Good question. FX and Joe don't like the idea, but Fortran files (".h"/".inc"
and ".mod" files one can find in /usr/include in some Linux distributions.
openSUSE has a .mod file and *.inc for NetCDF in /usr/include. The place for
the .mod looks wrong, but for .inc?
A semi-proper place for .mod files is:
/usr/lib64/gcc/x86_64-suse-linux/4.4/finclude/
(Semi because finclude does not distinguish between e.g. 32bit and 64bit.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/37829] ICE in resolve_symbol
--- 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't convert TYPE(_gfortran_iso_c_binding_c_funptr) to TYPE(c_funptr) > at (1) > The question is: Is it valid/Do we want to support this? I don't see why it should be invalid (though I have not spend too much time on finding a reason). It also compiles just fine with ifort and g95. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
[Bug fortran/38471] New: [4.3/4.4 Regression] ICE on pointer assignment of nested derived-type component
Reported at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/bf908dba87ce677a
Valgrind shows:
==10280== Invalid read of size 8
==10280==at 0x4B67E2: gfc_trans_pointer_assignment (trans-expr.c:4076)
==10280==by 0x4956AF: gfc_trans_code (trans.c:)
==10280==by 0x4AD5FB: gfc_generate_function_code (trans-decl.c:3887)
trans-expr.c is:
4066if (expr1->symtree->n.sym->attr.subref_array_pointer)
4067 {
4068decl = expr1->symtree->n.sym->backend_decl;
4069gfc_init_se (&rse, NULL);
4070rse.descriptor_only = 1;
4071gfc_conv_expr (&rse, expr2);
4072tmp = gfc_get_element_type (TREE_TYPE (rse.expr));
4073tmp = fold_convert (gfc_array_index_type, size_in_bytes
(tmp));
4074if (!INTEGER_CST_P (tmp))
4075 gfc_add_block_to_block (&lse.post, &rse.pre);
4076gfc_add_modify (&lse.post, GFC_DECL_SPAN(decl), tmp);
4077 }
module test
implicit none
!===
type b
integer :: j
end type b
!===
type a
type(b), dimension(4) :: i
end type a
!===
contains
!===
subroutine test_sub(sorb,ipn)
type(a), intent(in), target :: sorb
integer, dimension(:), pointer :: ipn
ipn=>sorb%i%j
end subroutine test_sub
!===
end module test
--
Summary: [4.3/4.4 Regression] ICE on pointer assignment of nested
derived-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 dot gnu dot org
OtherBugsDependingO 32834
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
[Bug fortran/38471] [4.3/4.4 Regression] ICE on pointer assignment of nested derived-type component
--- 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_specific
$15 = (struct lang_decl *) 0x0
(gdb) pt decl->decl_common.lang_specific
type = struct lang_decl {
tree saved_descriptor;
tree stringlen;
tree addr;
tree span;
} *
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
[Bug fortran/38471] [4.3/4.4 Regression] ICE with subreference pointer
--- 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 whether in gfc_check_pointer_assign the attr.subref_array_pointer is
set, but I indeed see:
(gdb) p lvalue->symtree->n.sym->attr.subref_array_pointer
$7 = 1
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||pault at gcc dot gnu dot org
Summary|[4.3/4.4 Regression] ICE on |[4.3/4.4 Regression] ICE
|pointer assignment of nested|with subreference pointer
|derived-type component |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
[Bug fortran/38471] [4.3/4.4 Regression] ICE with subreference pointer where pointer is a DUMMY argument
--- 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_symbol * sym)
[...]
if ((sym->attr.dummy && ! sym->attr.function) || (sym->attr.result && byref))
{
// We enter here as the POINTER is a DUMMY
[...]
return sym->backend_decl;
}
[...]
if (sym->attr.subref_array_pointer)
{
tree span;
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3/4.4 Regression] ICE|[4.3/4.4 Regression] ICE
|with subreference pointer |with subreference pointer
||where pointer is a DUMMY
||argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
[Bug fortran/38471] [4.3/4.4 Regression] ICE with subreference pointer assignment
--- 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 for finding the bug goes to Sudeep Punnathanam. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 Regression] ICE|[4.3/4.4 Regression] ICE |with subreference pointer |with subreference pointer |where pointer is a DUMMY|assignment |argument| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
[Bug fortran/38487] Bogus Warning: INTENT(INOUT) actual argument might interfere with actual argument
--- 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 I think the warning is OK in the sense that the pointer could point to the same memory address which could potentially make trouble, but still the warning feels too strong. However, I have not studied neither the test case not dependency.c in details. Mikael, what do you think? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||mikael at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38487
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
--- 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
[Bug fortran/38471] [4.3/4.4 Regression] ICE with subreference pointer assignment
--- 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 patch looks quite similar (identical?). The attached test case works when "type b" does not contain "character :: c" and fails if it does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
[Bug fortran/38506] New: Character storage association - actual <-> dummy argument
Cloned from PR 36771. See also
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/3d909edac01e60e2#
Since F2003 one can pass a "string" to a character(len=1),dimension(*)
dummy. The question is whether this should also work for generic
resolution or not.
The "call One('String')" (one = generic name) of the following program
is rejected by gfortran, ifort, NAG f95 and g95, stating that no
matching specific procedure could be found. On the other hand, all of
them accept "call Two" (= specific name). My question is now whether
"call One" should work as well (which would indicate a bug in all four
compilers) or not.
My gut feeling is that it is valid, but I cannot really pin point it in
the standard.*
*** Action item: If valid, gfortran should accept this.
Another question: Am I reading it correctly that if the default kind has
not the same value as "UCS4 = selected_char_kind('ISO_10646')" then a
call with an actual argument ucs4_"string" to a procedure with
array-valued ucs4-kind dummy argument is invalid Fortran 2003 and should
be rejected by the compiler with -std=f2003? This also holds for Fortran
2008 (current draft), does it?**
*** Action item: If invalid, we need to rejected (kind /= 1) character used
with storage association when -std < gnu is given. (I'm almost positive that it
is invalid.)
(One needs to be careful this also works with rank > 1.)
MODULE modtest
USE ISO_C_BINDING
INTERFACE One
MODULE PROCEDURE Two
END INTERFACE
CONTAINS
SUBROUTINE Two( chr ) bind(C)
CHARACTER(LEN=1, KIND=C_CHAR), DIMENSION(*) :: chr
END SUBROUTINE Two
END MODULE modtest
PROGRAM main
USE ISO_C_BINDING
USE modtest
CHARACTER(LEN=4, KIND=C_CHAR) :: chrScalar
chrScalar = 'Scal'
CALL One( chrScalar )
CALL Two( chrScalar )
END PROGRAM main
* Regarding the standard, I think "12.4.1.5 Sequence association" is the
most important section, but I also looked at "12.4.1.2 Actual arguments
associated with dummy data objects", "16.4.3 Storage association" and
(for c_char) "15.2 Interoperability between Fortran and C entities".
** "12.5.2.11 Sequence association" also talks about default kind and
c_char only.
--
Summary: Character storage association - actual <-> 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
[Bug fortran/36771] Non-Standard addition for C_LOC and character strings
--- 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 whether
there exists scenarios where it causes problems, but ad hoc I don't see any.
Patch:
--- resolve.c (Revision 142706)
+++ resolve.c
@@ -2165,7 +2165,7 @@ gfc_iso_c_func_interface (gfc_symbol *sy
if (args_sym->attr.dimension != 0
&& (args_sym->as && args_sym->as->rank == 0))
{
- gfc_error_now ("Allocatable variable '%s' used as a
"
+ gfc_notify_std (GFC_STD_F2003, "Allocatable variable
'%s' used as a "
"parameter to '%s' at %L must not be
"
"an array of zero size",
args_sym->name, sym->name,
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
------------------------
CC||burnus at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36771
[Bug fortran/38507] Bogus Warning: Deleted feature: GOTO jumps to END of construct
--- 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 CONTINUE statement for each DO statement." "8.1.4.2 Range of the DO construct" contains this small print (small = deprecated, might get removed in later versions): "The range of a nonblock DO construct consists of the do-body and the following DO termination. The end of such a range is not bounded by a particular statement as for the other executable constructs (e.g., END IF); nevertheless, the range satisfies the rules for blocks (8.1.1). Transfer of control into the do-body or to the DO termination from outside the range is prohibited; in particular, it is permitted to branch to a do-term-shared-stmt only from within the range of the corresponding inner-shared-do-construct." Example: do 10 i = 1, 5 do 10 ii = 1,5 goto 10 10 continue end NAG f95 prints: Obsolescent: 10 is a shared DO termination label ifort -stand f95 prints: Warning: Sharing of a DO termination statement by more than one DO statement is an obsolescent feature in Fortran 95. Use an END DO or CONTINUE statement for each DO statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38507
[Bug tree-optimization/38515] New: Disabling PPL/CLOOG with configure does not work
--disable-ppl and --without-ppl are accepted, but still ./configure searches for PPL/CLOOG, finds them and enables them. Expected: One can build 4.4 also without PPL/CLOOG even if they are installed. -- Summary: Disabling PPL/CLOOG with configure does not work Product: 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=38515
[Bug fortran/38504] double minus sign when printing integer?
--- 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 -m64 (default) I get "-", maybe it helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38504
[Bug fortran/38506] -std=f*: Reject scalar character to array dummy in several cases
--- 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.) Diagnostics: Bader writes: "For handing on c_char scalars to char * an exception was made in F2003, allowing scalars to be matched to an entity with the dimension(*) attribute; otherwise dimension(*) will match arrays only, though of arbitrary dimension." I think this is partially misleading. I think "12.4.1.5 Sequence association" is relevant and it also applies to default character. I.e. one seemingly needs to rejected this for kind=4 character strings with -std=f2003: Index: interface.c === --- interface.c (Revision 142761) +++ interface.c (Arbeitskopie) @@ -1525,6 +1525,12 @@ compare_parameter (gfc_symbol *formal, g formal->name, &actual->where); return 0; } + else if (where && formal->ts.kind != 1 + && gfc_notify_std (GFC_STD_GNU, "Extension: Non-default-kind" + "/C_CHAR scalar CHARACTER actual argument " + "with array dummy argument '%s' at %L", + formal->name, &actual->where) == FAILURE) + return 0; else if ((gfc_option.allow_std & GFC_STD_F2003) == 0) return 0; else -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords|rejects-valid | Summary|Character storage |-std=f*: Reject scalar |association - actual <->|character to array dummy in |dummy argument |several cases http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38506
[Bug fortran/36771] Non-Standard addition for C_LOC and character strings
--- 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 sunf95 - of these only "ifort" allows it (even with all checking enabled - thus presumably only by accident and not on purpose). Thus I wonder whether simply using the following "evil" workaround is better than patching the compiler: f_ptr = C_LOC(X(1:1)) That works with gfortran, ifort, g95 and NAG f95. (It fails with sunf95, whose C interoperability is a bit shaky in general.) As the string should be contiguous in memory it should be the OK. Additionally, that is also what one would do in C: char X[40]; ptr = &X; // or equivalently: ptr = &X[0]; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36771
[Bug fortran/38536] New: ICE with C_LOC in resolve.c due to not properly going through expr->ref
There are two C_LOC issues related to not going through all expr->ref. The
second one was found by Scot Breitenfeld (in PR 36771 comment 4), the first one
I found while trying to reduce it.
* * *
use iso_c_binding
character(len=2),target :: str(2)
print *, c_loc(str(1))
end
Result:
Gives no error
Expected:
Error: CHARACTER argument 'str' to 'c_loc' at (1) must have a length of 1
Using C_LOC(str) an error is printed. Seemingly, is_scalar_expr_ptr either does
not work or it is the wrong function for the check in resolve.c's
gfc_iso_c_func_interface.
* * *
The following program gives:
Internal Error at (1):
Unexpected expression reference type in gfc_iso_c_func_interface
The problem also occurs in resolve.c's gfc_iso_c_func_interface, though at a
different line.
USE ISO_C_BINDING
TYPE test
CHARACTER(LEN=2), DIMENSION(1:2) :: c
INTEGER(C_INT) :: i
END TYPE test
TYPE(test), TARGET :: chrScalar
TYPE(C_PTR) :: f_ptr
f_ptr = c_loc(chrScalar%c(1)(1:1))
end
--
Summary: ICE with C_LOC in resolve.c due to not properly going
through expr->ref
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 dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536
[Bug fortran/36771] Non-Standard addition for C_LOC and character strings
--- 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 that is what I ended up doing. > BTW, ifort 11 and pgf90 7.2-1 also allow C_LOC(X). OK. Then I close this PR as WONTFIX. > But, while using X(1:1) works fine in general, if I try to use it in a > derived type gfortan (all versions) it fails to compile with an internal > error, Filed as new PR 38536. Thanks a lot for finding and reporting this problem. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36771
[Bug fortran/31822] Missing run-time bound checks for character pointer => target
--- 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 (1) However, I start to wonder whether that is actually valid? I know that it is rejected (at compile time) by gfortran, ifort, NAG f95, g95, openf95, and sunf95. However, if I read 7.4.2 of the Fortran 2003 standard I cannot find the restriction. ifort prints: error #6795: The target must be of the same type and kind type parameters as the pointer. [PTR] And that is what I find in the standard: "C716 (R735) If data-target is not unlimited polymorphic, data-pointer-object shall be type compatible (5.1.1.2) with it, and the corresponding kind type parameters shall be equal." The type "character" is doubtlessly compatible with the type "character" and both kind type parameters are the same (namely "1" = default character). I cannot find any special case about the LENgth type parameter in that section. In Fortran 95 I also only read: "Constraint: The target shall be of the same type, kind type parameters, and rank as the pointer." I must miss something because it is extremely unlikely that all compiler get it wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31822
[Bug fortran/31822] Missing run-time bound checks for character pointer => target
--- 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 (it does not seem to be in the corrigenda). OK. Found it. I think the "Otherwise" clause of the following applies: "If data-target is a disassociated pointer, all nondeferred type parameters of the declared type of data pointer-object that correspond to nondeferred type parameters of data-target shall have the same values as the corresponding type parameters of data-target. Otherwise, all nondeferred type parameters of the declared type of data-pointer-object shall have the same values as the corresponding type parameters of data-target." Thus: One indeed needs the check mentioned in comment 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31822
[Bug fortran/38568] New: ICE with invalid bounds for I/O FMT= array
The following program is invalid, however, there should be no ICE. Warning
printed:
Warning: Upper array reference at (1) is out of bounds (9 > 1) in dimension 1
hello.f90:2: internal compiler error: Segmentation fault
valgrind:
==32039== Invalid read of size 4
==32039==at 0x49C0DD: gfc_conv_scalarized_array_ref (trans-array.c:2414)
==32039==by 0x49D9A4: gfc_conv_array_ref (trans-array.c:2462)
==32039==by 0x4B7511: gfc_conv_variable (trans-expr.c:679)
character(len=9) :: fmt(1)
fmt = '("Hello")'
WRITE(*, FMT(1:9) ) ! Invalid 1:9 is regarded as array bounds not at
substring
end
Found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/250dfb55a30226da
--
Summary: ICE with invalid bounds for I/O FMT= array
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: 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
[Bug fortran/38594] [4.4 Regression] module function name mangled improperly if contained function of same name exists
--- 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 at gcc dot gnu dot org changed: What|Removed |Added CC| |burnus at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38594
