--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-06 12:11 ---
DATA LARGE(1), LARGE(2) / Z'', Z'7FEF' /
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1)
The error message is correct: You cannot fit the nu
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-06 12:49 ---
Using
REAL RMACH(5)
DATA RMACH(1) / Z'0080' /
is invalid Fortran 77/90/95/2003 as Fortran only allows:
"If a data-stmt-constant is a boz-literal-constant, the corresponding variable
s
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-06 13:06 ---
> The numbers are 32-bit, so why an overflow?
huge(0): 2147483647 ! biggest (positive) number fitting into integer(4)
Z'': 4294967295
I would argue that 4294967295 is bigger than 21474
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-06 19:23 ---
Patch for the first part. Missing: Check for default initializer.
Index: resolve.c
===
--- resolve.c (revision 127246)
+++ resolve.c (working copy
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-06 20:18 ---
Besides default initializers (TODO), I also forgot about the following, to be
added after the if clause of previous patch:
else if (csym->ts.type == BT_DERIVED
&& csym-
y: 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=33015
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-07 20:13 ---
Just for completeness: This is a regression with regards to g77.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
ssigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 32630
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33020
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-08 14:23 ---
Some further testing shows:
NAG f95 always wants to have a default kind for SHAPE in c_f_pointer
though the standard allows all kinds.
If I change integer(fgsl_size_t) (fgsl_size_t = c_site_t = 8) into integer(4
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-08 19:01 ---
I still would like to have somewhere a reference to "c_size_t" of the
"iso_c_binding" module as this helps the user to actually code it. It is in any
case more portable than hard coding some value
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-09 15:50 ---
Could you please tell us your gfortran version? ("gfortran -v", the gcc-version
line is of most interest.)
Not that TRANSFER is free of bugs, but it produces here 4.3.0 20070808
(x86_64-unknown-linux-gnu
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-09 18:39 ---
I think this is a duplicate of PR 33019.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33039
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-09 18:54 ---
> This is undefined code, when I rewrote most of the transfer code for scalars,
> I
> had asked what happens when the sizes did not match and everyone I asked said
> it was undefined behavior.
Well,
igned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33040
--- Comment #8 from burnus at gcc dot gnu dot org 2007-08-09 21:28 ---
Subject: Bug 33001
Author: burnus
Date: Thu Aug 9 21:27:52 2007
New Revision: 127321
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127321
Log:
2007-08-09 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #8 from burnus at gcc dot gnu dot org 2007-08-09 22:03 ---
Subject: Bug 32987
Author: burnus
Date: Thu Aug 9 22:02:32 2007
New Revision: 127324
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127324
Log:
2007-08-09 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #9 from burnus at gcc dot gnu dot org 2007-08-09 22:08 ---
FIXED for gfortran 4.3.0; gfortran now accepts the tab; it checks also at
compile time for the tab character and gives either a warning (-std=gnu/legacy)
or an error (-std=f95/f2003) if a tab has been found
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-09 22:23 ---
Some more debugging - I modified gfc_trans_structure_assign to:
--
cm = expr->ts.derived->components; i = 1;
for (c = expr->value.constructor; c; c = c->next, c
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-10 09:43 ---
Newly created test case. Expected:
* Extend (size) should be printed for "a = f()", as NAG f95 does
(I'm not sure that "different shape" is correct for the current a=b message;
addition
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-13 21:08 ---
Mark really as fixed.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
d(C) t": Diagnose missing "::"
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
R
--- Comment #7 from burnus at gcc dot gnu dot org 2007-08-14 15:48 ---
Note: Instead of having the SEQUENCE property, the BIND(C) attribute ("type,
bind(c) :: t") suffices as well.
"Two data entities have the same type if they are declared with reference to
the sa
3
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=33072
--- Comment #9 from burnus at gcc dot gnu dot org 2007-08-14 21:16 ---
(From update of attachment 13369)
> strcpy (new->local_name, name);
This does not make much sense for INTERFACE_INTRINSIC_OP.
The problem with being able to import an operator only once is related to PR
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-14 21:24 ---
Extended example (rejects-valid + accepts-invalid):
(Overlaps partially with PR31298)
module a
implicit none
interface operator(.op.)
module procedure sub
end interface
contains
function sub(i)
integer
rtran
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=33077
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-16 15:19 ---
> Well, the gfortran doc says "Shall be of type INTEGER(4), N >= 0". This is in
> contradiction with the g77 doc, which says: "Pos: INTEGER not wider than the
> default kind; scalar; IN
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-16 18:17 ---
Subject: Bug 33072
Author: burnus
Date: Thu Aug 16 18:17:46 2007
New Revision: 127564
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127564
Log:
2007-08-16 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-16 18:20 ---
FIXED - but only the initially reported bug. The other I push back to PR31298.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
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=33095
--- Comment #10 from burnus at gcc dot gnu dot org 2007-08-17 08:14 ---
Rejecting "operator(.procedure.)" has been fixed by PR33072.
Accepting multiple renames/imports of an operator ("operator(.op.),
operator(.myop.)=>operator(.op.)") is fixed by the submitted p
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-17 13:21 ---
> Oh, sh**, I didn't think about simplification.
> Well, I don't see an easy way to
> have error messages at runtime, so we should simply skip those.
Good idea. As long as the compiler does the
Product: gcc
Version: 4.3.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
OtherBugsDependingO 20585
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=33106
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-18 12:56 ---
Created an attachment (id=14072)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14072&action=view)
Diff for invoke.text (only)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33105
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-19 17:50 ---
> does any other standard but F95 allow the usage of private derived type
> outside their defining module? I'd think that an error is called for,
> regardless of the version of the standard?!
Bel
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-19 18:54 ---
Fortran 2003:
---
4.5.1.1 Accessibility
Types that are defined in a module or accessible in that module by use
association have either the PUBLIC or PRIVATE attribute. Types for which an
access-spec is
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: accepts-invalid
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
rtedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33117
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-20 06:02 ---
Hmm. I wonder why it did not work - probably I mixed it up with
PROCEDURE(REAL).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-20 06:21 ---
Richard Maine claims that also
print *, code_gree
is valid. Thus there needs to be only a Fortran 95 check in module.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/6f683312292e2865/
Note
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-21 15:46 ---
> I wasn't even aware of their existence!
Me neither. I found it in the NAG f95 release notes.
> I'll do it (unless you want to?), thanks for the doc patch.
Go ahead.
--
http://gcc.
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-21 17:06 ---
Created an attachment (id=14090)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14090&action=view)
invoke.texi patch
Note: I did not mention "Fortran 2008" and I also did not include "LOG
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-21 17:08 ---
Created an attachment (id=14091)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14091&action=view)
invoke.texi patch
Note: I did not mention "Fortran 2008" and I also did not include "LOG
--- Comment #7 from burnus at gcc dot gnu dot org 2007-08-21 19:04 ---
> * Will we want a -std=f2008 separate from f2003, or do we consider f2003 an
> alias for f2008 (F2008 being, after all, a minor improvement to F2003)?
Who said that it will be a minor change compared to F
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=33141
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-22 06:36 ---
Minimal example:
implicit none
real, TARGET :: a(0:100)
real, pointer :: p(:)
p => a
print *, lbound(a), ubound(a)
print *, lbound(p), ubound(p)
end
Prints:
0 100
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-22 14:41 ---
Note: for a(:) and thus also for "p=>a(:)" the lbound starts at 1 (this is
somewhere hidden in "6.2.2.3 Array sections") - this part works.
Partial patch. Note: This patch is incomplete as on
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-22 17:35 ---
I think the problem has been fixed meanwhile; I can reproduce it with 4.1.3
20070521 and 4.2.1 20070705, but not with 4.3.0 20070822.
Using gfortran 4.3 gives the following error message:
integer :: i,j,k,ndim
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-22 17:46 ---
> The error is caused by this line of subroutine get_cand:
> integer :: i,j,k,ndim=size(cl)
> if it is replaced by
> integer :: i,j,k,ndim
> ndim=size(cl)
> then the error doesn't
--- Comment #18 from burnus at gcc dot gnu dot org 2007-08-22 18:07 ---
> so I am tempted to close this as fixed.
At least PR 27289 and PR 29479 (marked as duplicate of this PR) seem still to
show the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-22 21:28 ---
Subject: Bug 33020
Author: burnus
Date: Wed Aug 22 21:28:08 2007
New Revision: 127719
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127719
Log:
2007-08-22 Christopher D. Rickett <[EMAI
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-22 21:29 ---
FIXED on the trunk.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
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=33162
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-24 15:03 ---
FIXED for gfortran 4.3.0.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from burnus at gcc dot gnu dot org 2007-08-24 15:04 ---
I said: FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-24 15:05 ---
*** This bug has been marked as a duplicate of 33174 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-24 15:05 ---
*** Bug 33175 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33174
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-24 15:01 ---
Subject: Bug 33139
Author: burnus
Date: Fri Aug 24 15:00:59 2007
New Revision: 127770
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127770
Log:
2007-08-24 Tobias Burnus <[EMAIL PROTECTED]&g
atus: 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=33178
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-24 19:26 ---
Subject: Bug 33178
Author: burnus
Date: Fri Aug 24 19:26:42 2007
New Revision: 127786
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127786
Log:
2007-08-24 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-24 19:28 ---
Fixed. Was a regression and kind of a typo.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Version: 4.3.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=33180
Version: 4.3.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=33188
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-25 20:27 ---
READ(a, '*') i
I think you mix this up with * (not '*') which is no character expression but
simply a single asterisk.
R914 format is default-char-expr
or label
or
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-26 09:31 ---
INVALID. I missed the "prior" in:
"The IMPORT statement specifies that the named entities from the host scoping
unit are accessible in the interface body by host association. An entity that
is i
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-26 17:59 ---
Subject: Bug 33188
Author: burnus
Date: Sun Aug 26 17:59:34 2007
New Revision: 127808
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127808
Log:
2007-08-26 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-26 18:00 ---
FIXED in 4.3.x/trunk.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
gcc
Version: 4.3.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=33196
--- Comment #9 from burnus at gcc dot gnu dot org 2007-08-26 18:11 ---
Subject: Bug 32980
Author: burnus
Date: Sun Aug 26 18:11:42 2007
New Revision: 127809
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127809
Log:
2007-08-26 Tobias Burnus <[EMAIL PROTECTED]&g
8: gamma() and other small changes
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc do
--- Comment #10 from burnus at gcc dot gnu dot org 2007-08-26 18:25 ---
FIXED for the trunk/GCC 4.3.0.
The Fortran 2008 bits are tracked in PR 33197.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-26 18:29 ---
Subject: Bug 32985
Author: burnus
Date: Sun Aug 26 18:29:45 2007
New Revision: 127811
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127811
Log:
2007-08-26 Tobias Burnus <[EMAIL PROTECTED]&g
Status: UNCONFIRMED
Keywords: accepts-invalid
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=33198
--- Comment #7 from burnus at gcc dot gnu dot org 2007-08-26 18:34 ---
Partially fixed. The remaining bits (default initializer) are tracked in
PR33198.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32985
--- Comment #12 from burnus at gcc dot gnu dot org 2007-08-26 18:37 ---
Subject: Bug 31298
Author: burnus
Date: Sun Aug 26 18:37:23 2007
New Revision: 127812
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127812
Log:
2007-08-26 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #8 from burnus at gcc dot gnu dot org 2007-08-26 18:39 ---
Mark as fixed.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #13 from burnus at gcc dot gnu dot org 2007-08-26 18:43 ---
REMAINING: operator(generic opterator) => operator(user operator)
e.g. operator(+) => operator(.myplus.)
For obvious reasons the reversed is not allowed (MR&C claims that also the
former is invalid, b
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-27 13:44 ---
Segmentation fault means: The program accessed memory it was not supposed to
access. There is no error if it accesses memory which is garbage but it may
access. Seemingly the first it happening with g95 and ifort and
Status: UNCONFIRMED
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=33204
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-27 13:53 ---
See also:
- Run-time checking, PR33204
- Whole-file checking: PR26227
- Generating .mod files for procedures which are not contained in modules or
the PROGRAM: PR30658
--
http://gcc.gnu.org/bugzilla
t: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 32630
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33215
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-28 10:04 ---
The bug is actually worse as valid Fortran 2003 programs are rejected.
The following program should print "5 -5". The two static global variables are
not the same as their binding name is not "a"
igned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33221
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-29 13:36 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-29 13:09 ---
Subject: Bug 33215
Author: burnus
Date: Wed Aug 29 13:08:55 2007
New Revision: 127898
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127898
Log:
2007-08-29 Christopher D. Rickett <[EMAI
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=33228
routine as
function
Product: gcc
Version: 4.3.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 g
g
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33230
: UNCONFIRMED
Keywords: accepts-invalid
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=33231
"read()," and "write(),"
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
Reported
ned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33233
: gcc
Version: 4.3.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=33234
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-29 18:15 ---
At least for it currently crashes already for the following reduced example;
the problem seems to be the default initializer. (Another hint that this is
indeed the problem: After commenting out the "if (f->
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-30 08:41 ---
Please attach such long examples the next time. This makes the bug report
easier to read and saves one from removing all the line breaks that get added.
I tried your example with NAG f95 and it reports:
Error: line
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-30 09:04 ---
Forgot to mention that gfortran gives the same error as NAG f95 but only when
using -std=f95 or f2003:
Error: The CHARACTER elements of the array constructor at (1) must have the
same length (24/32)
Work around
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-30 09:07 ---
Created an attachment (id=14138)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14138&action=view)
Testcase of comment 0 as file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33241
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-30 11:44 ---
I have a patch -> accept.
The standard says:
"C1208 (R1206) If MODULE appears in a procedure-stmt, each procedure-name in
that statement shall be accessible in the current scope as a module procedure.&
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-30 13:45 ---
Subject: Bug 33228
Author: burnus
Date: Thu Aug 30 13:44:47 2007
New Revision: 127925
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127925
Log:
2007-08-30 Tobias Burnus <[EMAIL PROTECTED]&g
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-30 13:47 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
901 - 1000 of 4285 matches
Mail list logo
