--- Comment #6 from domob at gcc dot gnu dot org 2008-10-04 10:40 ---
(In reply to comment #5)
Hmm. I see that in my previous comment #3 I said the wrong thing: the attached
sample code should be correct, once the name in the PASS argument is fixed.
The reasoning behind #3
--- Comment #1 from domob at gcc dot gnu dot org 2008-10-02 07:22 ---
(In reply to comment #0)
subroutine x_init (this, text, value)
type(x_t) :: this
character(*) :: text
integer :: value
call base_t%init (text)
! or...
call base_init (base_t, text)
I
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-30 18:49 ---
Confirmed. I'll work this out.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-25 10:28 ---
I guess this is illegal, too:
PROGRAM main
IMPLICIT NONE
CALL test (5, (/ 1, 2, 3, 4, 5, 6, 7, 8, 9 /) )
CONTAINS
SUBROUTINE test (n, arr)
IMPLICIT NONE
INTEGER :: n, arr(:)
INTEGER :: i = 5
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-24 14:39 ---
Thanks for the report Salvatore, I'll take this one on. It seems the new F2003
features are starting to getting used, from the bug-noise :D
--
domob at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-23 14:28 ---
Subject: Bug 37588
Author: domob
Date: Tue Sep 23 14:26:47 2008
New Revision: 140594
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140594
Log:
2008-09-23 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-23 14:29 ---
Fixed on trunk.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-21 10:27 ---
Hi,
thanks for having a look at the manual! This is surely greatly appreciated!
(In reply to comment #0)
General remarks
---
1. Section on distributing programs is missing:
What is needed if you
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-21 10:31 ---
Just one more comment: Thanks for the great list of typos and suggestions; if
you want and need help, I can volunteer to fix some of them if I find some time
to do so, as this should be trivially possible now
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-21 15:35 ---
Subject: Bug 35846
Author: domob
Date: Sun Sep 21 15:33:37 2008
New Revision: 140529
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140529
Log:
2008-09-21 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #7 from domob at gcc dot gnu dot org 2008-09-21 15:36 ---
Fixed on trunk.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-20 11:52 ---
After coming back to this bug, I believe the problem is that gfc_conv_expr
takes care of finding out string lengths' for things like TRIM(x) which don't
have a cl-length, but gfc_conv_expr_descriptor which is called
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-19 20:17 ---
I'll take this on as it is about GENERIC type-bound procedures.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-18 12:04 ---
Subject: Bug 37507
Author: domob
Date: Thu Sep 18 12:02:50 2008
New Revision: 140451
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140451
Log:
2008-09-18 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-18 12:06 ---
Fixed for trunk.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-17 11:57 ---
Subject: Bug 35770
Author: domob
Date: Wed Sep 17 11:56:09 2008
New Revision: 140413
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140413
Log:
2008-09-13 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-17 11:59 ---
Fixed for trunk (4.4) and 4.3.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from domob at gcc dot gnu dot org 2008-09-14 09:59 ---
Subject: Bug 36214
Author: domob
Date: Sun Sep 14 09:57:50 2008
New Revision: 140358
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140358
Log:
2008-09-11 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #10 from domob at gcc dot gnu dot org 2008-09-14 10:02 ---
Fixed for trunk (4.4) and 4.3.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-14 16:51 ---
Yes, that's probably the best to get comments/reviews for your patch; if you
think it is already mature, CC [EMAIL PROTECTED], too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35840
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-13 07:45 ---
Subject: Bug 35770
Author: domob
Date: Sat Sep 13 07:44:36 2008
New Revision: 140336
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140336
Log:
2008-09-13 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-13 09:23 ---
This shouldn't be too hard to do, I think. I'll look into this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37507
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-12 14:47 ---
Removing the
double precision :: fonc
from sub makes the program compile as expected (as I guess). I'm not sure if
that's a bug or a problem with the original code, but I could imagine that this
declaration makes
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-12 15:56 ---
(In reply to comment #3)
(In reply to comment #1)
Removing the
double precision :: fonc
from sub makes the program compile as expected (as I guess). I'm not sure
if
that's a bug or a problem
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-12 18:07 ---
I've not checked, but maybe this is related to PR 37199?
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from domob at gcc dot gnu dot org 2008-09-11 07:29 ---
Subject: Bug 36214
Author: domob
Date: Thu Sep 11 07:28:18 2008
New Revision: 140264
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140264
Log:
2008-09-11 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #8 from domob at gcc dot gnu dot org 2008-09-11 19:15 ---
Subject: Bug 37199
Author: domob
Date: Thu Sep 11 19:13:59 2008
New Revision: 140296
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140296
Log:
2008-09-08 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #9 from domob at gcc dot gnu dot org 2008-09-11 19:15 ---
Fixed on 4.3 branch.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-10 14:54 ---
I see the same problem with the program below:
implicit none
real, parameter :: r = 0.0
real(kind=8), parameter :: rd = real(b'
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-10 16:08 ---
-fdump-parse-tree gives
ASSIGN MAIN__:rd 5.31837115e-315_8
ASSIGN MAIN__:z (complex 5.3183711317956924e-315_8 0_8)
ASSIGN MAIN__:r 0
IF (/= MAIN__:z __convert_r8_c8[[((MAIN__:rd
--- Comment #7 from domob at gcc dot gnu dot org 2008-09-10 19:04 ---
The problem is that gfc_interpret_float does not set the default mpfr precision
to the value for its kind parameter but leaves the setting that is already
present. This is presumably the reason why inserting
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-09 09:26 ---
Subject: Bug 35837
Author: domob
Date: Tue Sep 9 09:25:33 2008
New Revision: 140140
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140140
Log:
2008-09-05 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-09 09:27 ---
Fixed for 4.3 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35837
--- Comment #7 from domob at gcc dot gnu dot org 2008-09-09 09:48 ---
Subject: Bug 37411
Author: domob
Date: Tue Sep 9 09:46:51 2008
New Revision: 140141
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140141
Log:
2008-09-09 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #8 from domob at gcc dot gnu dot org 2008-09-09 09:49 ---
This was indeed fixed with PR 37199, I committed the test-case as well as the
assertion mentioned. Fixed.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-09 18:09 ---
Subject: Bug 37429
Author: domob
Date: Tue Sep 9 18:08:08 2008
New Revision: 140163
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140163
Log:
2008-09-09 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-09 18:11 ---
Type-bound procedure call expressions missed a correct initialization of their
rank field, fixed.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-08 06:36 ---
IIRC, this behaviour is due to a patch I submitted some time ago. Maybe I
could change this warning into an error even for non-standard conforming mode
in case the length or a kind parameter differs. What do you
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-08 07:57 ---
Subject: Bug 37099
Author: domob
Date: Mon Sep 8 07:55:49 2008
New Revision: 140101
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140101
Log:
2008-09-04 Daniel Kraft [EMAIL PROTECTED]
* PR fortran
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-08 07:57 ---
Fixed on trunk and 4.3
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-08 08:28 ---
Dominique reported that my pending patch for PR 37199 fixes this problem, too,
and a test confirms this for me. Reading the commets, it seems quite plausible
to me that the ICE here is caused because of the missing
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-08 09:18 ---
Subject: Bug 37199
Author: domob
Date: Mon Sep 8 09:17:27 2008
New Revision: 140102
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140102
Log:
2008-09-08 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-08 13:52 ---
Subject: Bug 36167
Author: domob
Date: Mon Sep 8 13:51:26 2008
New Revision: 140107
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140107
Log:
2008-09-08 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #7 from domob at gcc dot gnu dot org 2008-09-08 13:54 ---
This was apparently really fixed by my patch for PR 37199, I committed the
test-case attached to trunk. Marking fixed.
--
domob at gcc dot gnu dot org changed:
What|Removed
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: domob at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37423
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: domob at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37425
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: domob at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37427
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37427
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: domob at gcc dot gnu
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-08 17:59 ---
Created an attachment (id=16255)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16255action=view)
ICE'ing invalid test
This is the ICE'ing test. I will investigate this bug, as it seems to be a
problem with type
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-08 18:37 ---
Reading the comments, this sounds really like the problem fixed for PR 37199
(sym-as wrongly NULL after interface-remapping). I agree that adding the
test and gcc_assert sounds like a good idea for me.
I will work
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-07 08:34 ---
(In reply to comment #1)
The problem is that for
implicit character(len=*,kind=kind('A')) (Q)
the length of the first parameter string is used everywhere. The following
fixes it, but I have no idea why
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-07 14:46 ---
parm.12.dim[0].ubound = D.1541;
parm.12.dim[0].stride = NON_LVALUE_EXPR D.1546;
parm.12.data = (void *) (*ifm.11)[0];
parm.12.offset = NON_LVALUE_EXPR D.1545;
D.1547 = MAX_EXPR (parm.12.dim[0
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-07 19:00 ---
program bounds_issue
real, pointer :: pdf0(:)
allocate(pdf0(0:282))
pdf0 = f(pdf0)
contains
function f(x)
real, intent(in) :: x(0:) ! x(1:), f(1:...) works
real :: f(0
--- Comment #7 from domob at gcc dot gnu dot org 2008-09-05 11:57 ---
Subject: Bug 36746
Author: domob
Date: Fri Sep 5 11:56:23 2008
New Revision: 140034
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140034
Log:
2008-09-05 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #8 from domob at gcc dot gnu dot org 2008-09-05 11:58 ---
Fixed on trunk.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-05 20:53 ---
Subject: Bug 35837
Author: domob
Date: Fri Sep 5 20:51:50 2008
New Revision: 140046
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140046
Log:
2008-09-05 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-05 20:55 ---
Fixed for trunk.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-04 17:14 ---
Shouldn't for this code:
IMPLICIT TYPE(t)(x)
DIMENSION x(:)
x get the implicit type on the DIMENSION statement and this be thus equivalent
to
TYPE(t) :: x
DIMENSION x(:)
(if that's a legal way to specify DIMENSION
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-04 19:17 ---
Subject: Bug 37099
Author: domob
Date: Thu Sep 4 19:16:13 2008
New Revision: 139997
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139997
Log:
2008-09-04 Daniel Kraft [EMAIL PROTECTED]
* PR fortran
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-04 20:23 ---
I'll try to find something about this in the standard. But you think DIMENSION
(and friends) is legally apply-able (applicable?) to symbols that are
declared later with their type? Hm... I hope to find out
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-03 12:27 ---
Subject: Bug 37193
Author: domob
Date: Wed Sep 3 12:25:57 2008
New Revision: 139936
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139936
Log:
2008-08-30 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-03 12:27 ---
Subject: Bug 36371
Author: domob
Date: Wed Sep 3 12:25:57 2008
New Revision: 139936
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139936
Log:
2008-08-30 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-03 12:28 ---
Fixed on 4.4 and 4.3.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-02 08:51 ---
Subject: Bug 37228
Author: domob
Date: Tue Sep 2 08:50:13 2008
New Revision: 139886
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139886
Log:
2008-09-01 Jerry DeLisle [EMAIL PROTECTED]
PR fortran
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-02 08:51 ---
Subject: Bug 37301
Author: domob
Date: Tue Sep 2 08:50:13 2008
New Revision: 139886
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139886
Log:
2008-09-01 Jerry DeLisle [EMAIL PROTECTED]
PR fortran
2003: Finish derived-type finalization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: domob at gcc dot gnu dot
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-02 17:05 ---
Created an attachment (id=16196)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16196action=view)
Proposed patch implementing the main part
This is an experimental patch that implements the logic to create code
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-02 17:08 ---
For the needed parts to actually call finalizers building upon the attached
patch from comment #1, some means for temporary-creation before trans are
needed to handle things like:
x = foo (x)
or
foo (bar ())
Some
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-01 13:44 ---
Subject: Bug 37193
Author: domob
Date: Mon Sep 1 13:43:10 2008
New Revision: 139866
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139866
Log:
2008-09-01 Daniel Kraft [EMAIL PROTECTED]
PR fortran
fully conformant
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: domob at gcc dot gnu dot org
http://gcc.gnu.org
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
org
ReportedBy: domob at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37222
--- Comment #4 from domob at gcc dot gnu dot org 2008-08-22 07:14 ---
Subject: Bug 32095
Author: domob
Date: Fri Aug 22 07:13:25 2008
New Revision: 139425
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139425
Log:
2008-08-22 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #4 from domob at gcc dot gnu dot org 2008-08-22 07:14 ---
Subject: Bug 34228
Author: domob
Date: Fri Aug 22 07:13:25 2008
New Revision: 139425
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139425
Log:
2008-08-22 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #5 from domob at gcc dot gnu dot org 2008-08-22 07:16 ---
Fixed.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from domob at gcc dot gnu dot org 2008-08-22 07:17 ---
Fixed.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #5 from domob at gcc dot gnu dot org 2008-08-22 11:40 ---
What's with this PR, do you have any decision? I'm not sure about a `fixed'
warning, as this seems to be not common with gfortran, right?
But I'd suggest maybe a -Wsurprising warning, so that at least -Wall
--- Comment #7 from domob at gcc dot gnu dot org 2008-08-22 20:37 ---
Subject: Bug 30239
Author: domob
Date: Fri Aug 22 20:36:12 2008
New Revision: 139499
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139499
Log:
2008-08-22 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #8 from domob at gcc dot gnu dot org 2008-08-22 20:38 ---
I think we can fix this now, added a -Wsurprising warning.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #1 from domob at gcc dot gnu dot org 2008-07-31 10:31 ---
So the following two lines should give this error, right:
subroutine test (a)
character(len(a)) :: a
end subroutine test
subroutine test2 (n, arr)
integer :: arr(n), n
end subroutine test2
where in test2
--- Comment #3 from domob at gcc dot gnu dot org 2008-07-31 11:54 ---
Thanks for the quick reply, Tobias. I'll try to get the used but not yet
typed part implemented to emit errors for -std != gnu.
To fix the problem in this PR, I see those possible solutions:
a) Disallow not-yet
--- Comment #6 from domob at gcc dot gnu dot org 2008-07-29 09:12 ---
Subject: Bug 36403
Author: domob
Date: Tue Jul 29 09:11:51 2008
New Revision: 138234
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138234
Log:
2008-07-29 Daniel Kraft [EMAIL PROTECTED]
PR fortran
--- Comment #7 from domob at gcc dot gnu dot org 2008-07-29 09:17 ---
Fixed.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from domob at gcc dot gnu dot org 2008-07-28 18:41 ---
Thanks for all the hints, Tobias! I've had a look through the F2003 standard
about intrinsics taking optional char arguments, and it seems as though PACK
and RESHAPE would suffer from the same problem as EOSHIFT does
201 - 300 of 320 matches
Mail list logo
