--- Comment #6 from dfranke at gcc dot gnu dot org 2009-12-04 23:42 ---
(In reply to comment #5)
> So perhaps it's not gfortran's fault, but a short-coming in not totally
> up-to-date gdb's
Any news here?
--
dfranke at gcc dot gnu dot org changed:
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-05 00:31 ---
I'd vote for valid (moving the definition of the return type into the
specification part already is accepted).
F95, 5.1 Type declaration statements
"The speciļ¬cation-expr (7.1.6.2) of a char-len-p
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-06 12:18 ---
r148317 | burnus | 2009-06-09 19:21:45 +0200 (Tue, 09 Jun 2009) | 9 lines
2009-06-09 Tobias Burnus
[...]
* intrinsic.texi (ISO_FORTRAN_ENV): Document INT{8,16,32,64} and
REAL{32,64,128
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-06 12:59 ---
Subject: Bug 40904
Author: dfranke
Date: Sun Dec 6 12:59:46 2009
New Revision: 155022
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155022
Log:
2009-12-06 Daniel Franke
PR fortr
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-06 13:00 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from dfranke at gcc dot gnu dot org 2009-12-06 15:07
---
Unassigning myself.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-06 15:18 ---
Slightly reduced testcase:
module fox_m_fsys_array_str
contains
pure function str_vs(vs) result(s)
character, dimension(:), intent(in) :: vs
character(len=size(vs)) :: s
end function str_vs
pure
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-06 16:59 ---
Type parameter inquiries are also mentioned in PR29962, comment #10.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dfranke at gcc dot gnu dot org 2009-12-06 18:15 ---
Reduced testcase:
type t1
integer, allocatable :: d1(:)
end type t1
type t2
type(t1), allocatable :: d2(:)
end type t2
type(t2) :: a, b
a = new2( (/ new1((/1,1/)) /) )
b = new2( (/ a%d2 , a
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-06 18:25 ---
(In reply to comment #1)
> >gfortran: Internal error: Segmentation Fault (program f951)
>
> That normally means the version of GMP/MPFR you have installed are broken.
Any news here?
--
dfranke at
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-07 17:32 ---
Subject: Bug 41940
Author: dfranke
Date: Mon Dec 7 17:32:29 2009
New Revision: 155049
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155049
Log:
gcc/fortran:
2009-12-07 Daniel Franke
PR
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-07 18:04 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dfranke at gcc dot gnu dot org 2009-12-07 18:40 ---
With the upcoming release of 4.5, I think it would be nice to fix/improve the
translation related bugs now, i.e. this, PR38573 and PR40489.
As I have no idea how to reproduce/check/whatever this kind of PR, could
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-08 20:33 ---
(In reply to comment #0)
> ! The following is illegal!
> type (bad_t) :: bad = bad_t ( (/ 1., 3., 5., 7., 9. /) )
I don't get it. "Fortran 95/2003 explained" by Metcalf has exactly this i
--- Comment #5 from dfranke at gcc dot gnu dot org 2009-12-08 20:58 ---
*** Bug 34527 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-08 20:58 ---
Marking as dupe, discussion happened in PR37412.
*** This bug has been marked as a duplicate of 37412 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dfranke at gcc dot gnu dot org 2009-12-08 21:01 ---
(In reply to comment #4)
> 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 think?
I assume, this ha
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-08 21:04 ---
*** This bug has been marked as a duplicate of 37398 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-08 21:04 ---
*** Bug 38733 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-08 21:17 ---
All three cases are flagged by current 4.5.0 20091208.
The first one gives
$> gfortran-svn pr35918.f90
pr35918.f90:2.8:
real foo
1
Error: FUNCTION attribute conflicts with SUBROUTINE attribute in '
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22571
--- Comment #4 from dfranke at gcc dot gnu dot org 2009-12-08 21:41 ---
(In reply to comment #3)
> (In reply to comment #2)
> > I don't get it. "Fortran 95/2003 explained" by Metcalf has exactly this in
> > the
> > example (figure 12.3, p243) for a
--- Comment #6 from dfranke at gcc dot gnu dot org 2009-12-09 22:05 ---
(In reply to comment #5)
> See 7.1.7(3) in F2003 (and 7.1.12(3) in the F2008 draft.)
Walter, thanks for reference!
--
dfranke at gcc dot gnu dot org changed:
What|Remo
--- Comment #9 from dfranke at gcc dot gnu dot org 2009-12-10 19:10 ---
See also PR38839 for expanded character set.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36275
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-12-10 19:11 ---
See PR36275 for more possibilities on binding labels.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dfranke at gcc dot gnu dot org 2009-12-10 19:57 ---
Subject: Bug 34402
Author: dfranke
Date: Thu Dec 10 19:57:16 2009
New Revision: 155138
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155138
Log:
gcc/fortran/:
2009-12-10 Daniel Franke
--- Comment #8 from dfranke at gcc dot gnu dot org 2009-12-10 19:59 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-12-10 21:04 ---
Subject: Bug 41369
Author: dfranke
Date: Thu Dec 10 21:03:40 2009
New Revision: 155141
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155141
Log:
2009-12-10 Daniel Franke
PR fortr
--- Comment #4 from dfranke at gcc dot gnu dot org 2009-12-10 21:05 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-10 21:46 ---
Actually, the program
real:: x
complex :: c
c = c * x
end
is directly translated to ...
MAIN__ ()
{
complex(kind=4) c;
real(kind=4) x;
c = COMPLEX_EXPR * c;
}
... and yukka, the "opti
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-10 21:58 ---
Subject: Bug 40287
Author: dfranke
Date: Thu Dec 10 21:57:49 2009
New Revision: 155142
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155142
Log:
2009-12-10 Daniel Franke
PR fortr
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-10 21:58 ---
No more warning in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dfranke at gcc dot gnu dot org 2009-12-11 14:42 ---
Daniel, is there anything going to happen with those patches you attached? :)
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-11 18:56 ---
Using "-O3 -fno-signed-zeros" (the latter being set by -ffast-math) gets rid of
all the additional computations and results in
:
D.1504_2 = *a_1(D);
D.1514_10 = REALPART_EXPR <*b_4(D)&
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-12-11 21:08 ---
Subject: Bug 40290
Author: dfranke
Date: Fri Dec 11 21:08:39 2009
New Revision: 155179
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155179
Log:
2009-12-11 Daniel Franke
PR fortr
--- Comment #4 from dfranke at gcc dot gnu dot org 2009-12-11 21:10 ---
Fixed in trunk. Closing.
Thanks for the report!
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-12-11 21:44 ---
(In reply to comment #2)
> I wonder why this is not caught in parse.c's verify_st_order; the error
> message there is much nicer
Because it seems that verify_st_order is not called for every accepted
st
--- Comment #6 from dfranke at gcc dot gnu dot org 2009-12-11 22:20 ---
For the example in #1, the wrong name is picked up in trans-array.c
(gfc_trans_array_bound_check):
2310 if (!name && se->loop && se->loop->ss && se->loop->ss->expr
2311
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-11 22:30 ---
I think this one is actually ok. The message is emitted rank-times, once for
each non-integer rank, for each variable.
Here we get it three times:
real, parameter :: n = 2
real, dimension(n) :: x, y, z
end
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-11 22:55 ---
*** Bug 39192 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38303
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-11 22:55 ---
*** This bug has been marked as a duplicate of 38303 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-12 11:12 ---
Confirmed. Will have a quick poke at it.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-13 16:19 ---
F2008 allows C_SIZEOF in initialization expressions:
The definition for "specification inquiry" is in Fortran 2008 (7.1.11
Specification expression):
"A speci cation inquiry is a reference to
(
--- Comment #5 from dfranke at gcc dot gnu dot org 2009-12-13 16:22 ---
While looking at this one, I found two oddities:
* There are two similar special-case handlers for ISOCBINDING_NULL_[FUN]PTR,
one in trans-expr.c(gfc_conv_initializer), the other in trans-const.c
ds: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42359
d at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42360
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-14 19:11 ---
Subject: Bug 42354
Author: dfranke
Date: Mon Dec 14 19:10:56 2009
New Revision: 155234
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155234
Log:
gcc/fortran/:
2009-12-14 Daniel Franke
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-12-14 19:22 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from dfranke at gcc dot gnu dot org 2009-12-17 23:07
---
[Adding Paul as CC]
(In reply to comment #10)
> Would you be so kind as to follow this. It's been unconfirmed for 18 months.
> Is it a bug or not and will we or won't we fix it?
>
> I vo
--- Comment #13 from dfranke at gcc dot gnu dot org 2009-12-18 18:27
---
Tobias, thanks for your description. I'm still a bit hazy on the details, but I
changed my tree according to what I picked up. Question is, how do I verify
that the issue described in the initial report is
--- Comment #14 from dfranke at gcc dot gnu dot org 2009-12-19 11:38
---
(In reply to comment #7)
> Support for this type of format has now been added to xgettext. The support
> will be contained in gettext 0.18.
I got as far as recreating the .pot for testing. Tried to compi
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-20 15:07 ---
Try with a proper path, i.e. without the '~'. Replacement of special characters
or wildcards is done on the shell level, not within the application.
To place a file in the home directory of the use
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-23 13:32 ---
Dupe of PR30471?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-23 13:49 ---
Shouldn't the "openmp" keyword
(http://gcc.gnu.org/bugzilla/describekeywords.cgi) be sufficient?
--
dfranke at gcc dot gnu dot org changed:
What|Removed
character components
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
Reported
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-30 00:54 ---
Confirmed for 4.4.3 (20091229).
If sqrt2 is marked as PARAMETER, both 4.3.4 and 4.4.3 accept the code without
further problems.
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-02-04 13:03 ---
*** This bug has been marked as a duplicate of 42954 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-02-04 13:03 ---
*** Bug 36380 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-07-15 21:37
---
> > (In reply to comment #13)
> >> I'm leaving this assigned to Janus because, as OOP master, he knows best
> >> the
> >> place(s) where the change(s) have to be applied, f
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-07-15 21:39 ---
(From update of attachment 20021)
Obsolete duplicate.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
iority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44960
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-07-15 21:57 ---
Spin-off: PR44960
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43179
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-07-18 20:49 ---
Subject: Bug 34260
Author: dfranke
Date: Sun Jul 18 20:49:30 2010
New Revision: 162287
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162287
Log:
gcc/fortran/:
2010-07-18 Daniel Franke
--- Comment #12 from dfranke at gcc dot gnu dot org 2010-07-18 20:49
---
Subject: Bug 31346
Author: dfranke
Date: Sun Jul 18 20:49:30 2010
New Revision: 162287
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162287
Log:
gcc/fortran/:
2010-07-18 Daniel Franke
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-07-18 20:49 ---
Subject: Bug 30668
Author: dfranke
Date: Sun Jul 18 20:49:30 2010
New Revision: 162287
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162287
Log:
gcc/fortran/:
2010-07-18 Daniel Franke
--- Comment #58 from dfranke at gcc dot gnu dot org 2010-07-18 20:49
---
Subject: Bug 40011
Author: dfranke
Date: Sun Jul 18 20:49:30 2010
New Revision: 162287
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162287
Log:
gcc/fortran/:
2010-07-18 Daniel Franke
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-07-18 21:12 ---
Fixed in trunk and 4.5. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from dfranke at gcc dot gnu dot org 2010-07-18 21:13
---
Fixed in trunk and 4.5. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-07-18 21:15 ---
Fixed in trunk and 4.5. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-09-16 11:14 ---
They are not, as there, afaik, are no simplifiers yet.
Hence, with your patch they will be accepted, but you'd end up with wrong code
at the end, as the functions are not properly simplified and thus not con
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-09-18 15:58 ---
(In reply to comment #3)
> Am I correct to understand that the current situation (i.e. the error message)
> is a temporary fix for some missing gfc_simplify_*?
If the error message you refer to is
&
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
--- Comment #22 from dfranke at gcc dot gnu dot org 2010-04-30 21:02
---
Proposed patch:
http://gcc.gnu.org/ml/fortran/2010-04/msg00328.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-04-30 21:11 ---
Has this been WAITING for 18 months now?
Any news? :)
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-04-30 21:54 ---
See PR41359 for another use of SET_EXPR_LOCATION.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41827
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-04-30 22:13 ---
(In reply to comment #5)
> The compiler shouldn't crash anyway. But with a new version this problem
> should
> be solved too, isn't it?
It should be. 4.5.0 was released by now. Co
--- Comment #24 from dfranke at gcc dot gnu dot org 2010-05-01 10:24
---
(In reply to comment #23)
> are only detected with the -pedantic option.
Or -std=f95; data.c has:
/* Overwriting an existing initializer is non-standard but usually only
provokes a warning from ot
--- Comment #25 from dfranke at gcc dot gnu dot org 2010-05-01 10:36
---
Dominique, if you apply this hunk
Index: data.c
===
--- data.c (revision 158958)
+++ data.c (working copy)
@@ -352,8 +352,10
--- Comment #23 from dfranke at gcc dot gnu dot org 2010-05-01 11:15
---
Undoing the changes of comments #7, #12 and #16, I now (with splay-tree
constructors get):
$ time gfortran-svn -Wall pr40472.f90
real0m2.130s
user0m1.924s
sys 0m0.148s
Instead of those 11 minutes
--- Comment #25 from dfranke at gcc dot gnu dot org 2010-05-01 12:27
---
(In reply to comment #24)
> Without undoing the changes but with the patch in comment #23, the
> ICE with the test in comment #21 is gone.
The patch in #23 actually reverts the previous changes :)
If
--- Comment #28 from dfranke at gcc dot gnu dot org 2010-05-01 12:36
---
(In reply to comment #27)
> Apparently the repetition is along the last dimension:
> i(5,10) gives 10 errors/warnings and i(10,5) gives 5 ones.
Could you post the full test? I can't reproduce this?!
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-01 12:39 ---
With gcc version 4.6.0 20100501 (experimental) (GCC)
$ cat unused.c
int main() {
int i;
i = 42;
return 0;
}
$ gcc-svn -Wall unused.c
unused.c: In function 'main':
unused.c:2:7: warning: variable &
--- Comment #27 from dfranke at gcc dot gnu dot org 2010-05-01 13:08
---
(In reply to comment #26)
> Also I see a small slow down for the test in pr34554 (gfc is patched, gfcp
> not):
>
> [macbook] f90/bug% time gfc pr34554.f90
> 259.917u 0.168s 4:20.44 99.8% 0+0
--- Comment #30 from dfranke at gcc dot gnu dot org 2010-05-01 13:13
---
Created an attachment (id=20525)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20525&action=view)
updated patch
Updated patch. Fixes the multiplication of errors shown in comment #29. Not yet
re
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-01 14:24 ---
This is very close to PR30438.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33884
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-01 14:25 ---
See also PR33884.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30438
--- Comment #29 from dfranke at gcc dot gnu dot org 2010-05-01 14:52
---
(In reply to comment #28)
> Yes, please leave the limit in and allow users to change the max.
Ok. Closing this PR as very thoroughly FIXED then :)
--
dfranke at gcc dot gnu dot org changed:
W
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-01 18:30 ---
How about this?
Index: resolve.c
===
--- resolve.c (revision 158958)
+++ resolve.c (working copy)
@@ -11824,6 +11827,7 @@ traverse_data_list
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-01 20:15 ---
This was probably fixed when gamma was introduced for F2008.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from dfranke at gcc dot gnu dot org 2010-05-01 20:20
---
By now we have proper whole-file checking. Is this PR still relevant?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-01 20:34 ---
Whole-file checking does not catch this (yet). I'd think that it should be
possible to generate a warning here.
$> $ gfortran-svn -Wall -W -fwhole-file pr34260.f
pr34260.f:1.22:
SUBROUTINE
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-01 20:44 ---
(In reply to comment #2)
> I somehow missed that clause. I think one can thus close this bug.
Finally doing so. Please re-open if new information was obtained in the
meantime.
--
dfranke at gcc dot gnu dot
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-02 08:42 ---
(In reply to comment #1)
> All three cases are flagged by current 4.5.0 20091208.
> Tobias, please close if you agree.
Closing after 5 months of WAITING. Please reopen if you disagree.
--
dfranke at gcc d
--- Comment #33 from dfranke at gcc dot gnu dot org 2010-05-02 08:47
---
TODO (carried on):
- BESSEL_JN and BESSEL_YN: Transitional form is missing (c.f. PR36096,
PR36158)
- NORM2 is missing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33197
--- Comment #32 from dfranke at gcc dot gnu dot org 2010-05-02 09:23
---
(In reply to comment #31)
> FAIL: gfortran.dg/spread_size_limit.f90 -O scan-tree-dump-times original
> "_gfortran_spread" 1
> where the test should be updated/removed due to the change in si
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-02 14:00 ---
The testcase is still in its original form, the last attempt to get this
changed was never commented on:
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00118.html
Setting status to WAITING. To be closed as
--- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-02 14:03
---
Consensus seems to be: no, do not search the system include paths.
Set status to WAITING. To be closed as INVALID(?) in three months from now if
there is no further discussion.
--
dfranke at gcc dot gnu dot
--- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-02 14:31
---
Assuming PR37173 is correct, isn't this example invalid anyway (as already
noted by Tobias in #4)?
Instead, it should probably be written as:
CHARACTER (kind=4,len=*) MY_STRING4(1:3)
PARAMETER ( MY_ST
--- Comment #10 from dfranke at gcc dot gnu dot org 2010-05-02 15:09
---
Can this be closed? Is there something left to do here?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-02 15:20 ---
http://gcc.gnu.org/onlinedocs/gfortran/C_005fSIZEOF.html#C_005fSIZEOF has
Class:
Intrinsic function
Sounds strange, "inquiry" seems to be more likely (haven't checked)?!
See also: PR40568.
701 - 800 of 1161 matches
Mail list logo
