--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-25 19:49 ---
Has anyone any objection if I change the purpose of this PR to:
-
gfortran should detect that the local variable ncoset is never allocated -
as NAG f95 does:
Error: foo.f90, line 45: ALLOCATABLE array NCOSET
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-25 19:54 ---
What is your gfortran version (gfortran -v)?
I cannot repoduce it with neither -static nor without using
gfortran 4.1.3 20070413 (prerelease)
and 4.3.0 20070425 (experimental)
under x86_64-unknown-linux-gnu
--- Comment #4 from burnus at gcc dot gnu dot org 2007-04-25 19:58 ---
>From the man page:
"-malign-double
-mno-align-double
Control whether GCC aligns "double", "long double", and "long long" variables
on a two word boundary or a one word bound
--- Comment #4 from burnus at gcc dot gnu dot org 2007-04-26 14:53 ---
> FYI, I am unable to confirm this on i686-pc-linux-gnu.
> aermod seems to work no matter what switches I throw at the compiler.
--
> > Might be related to the similar PR 31699.
> No, because PR 31699
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-26 16:04 ---
This is with which version of gfortran (use gfortran -v)?
Which options are you using?
I get here (x86-64 Linux) the same result with gfortran 4.3, 4.1.2, g95, ifort,
NAG f95:
$ gfortran -O3 -ftree-vectorize -march
--- Comment #5 from burnus at gcc dot gnu dot org 2007-04-26 20:50 ---
> This can be seen in the file (result.dat) generated by the program.
I missed that part. Reduced test:
program laplsolv
IMPLICIT NONE
integer, parameter :: n=10
double precision,dimensio
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-27 06:58 ---
Fails with the newest 4.2.0, works with current 4.3.0
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-27 09:49 ---
> No, because PR 31699 is triggered by -ftree-vectorize.
Well, at least with today's GCC plus the patch in PR 31699, it does not crash
anymore. I will do some more checks to make sure I don't m
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-27 10:16 ---
Comment by Richard Guenther in the same thread:
-
I think that even with -ffast-math 12 bits accuracy is not ok. There is
the possibility of doing another newton iteration step to improve
accuracy
--- Comment #7 from burnus at gcc dot gnu dot org 2007-04-27 12:41 ---
> (float) time for 1.0 / sqrt = 5.96 sec (res = 2.845058125000e+05)
> (float) time for rsqrt = 2.49 sec (res = 2.23602250e+05)
> (double) time for 1.0 / sqrt = 7.35 sec (res = 5.99262343
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-27 13:16 ---
The problem is:
if(0) { /* find index */
else
{
pos.1 = 0;
}
D.1356 = (int4) (() pos.1 + 1);
As C and the internal tree have array indexes starting at one, the final index
has to
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-16 09:58 ---
Work around: Remove "public :: print".
I wonder what is that specific about PRINT. It works with WRITE, OPEN, ABS, ...
but it does not work with PRINT ?!?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32760
--- Comment #7 from burnus at gcc dot gnu dot org 2007-07-16 12:57 ---
For the fix for this PR and for PR32665, see:
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01417.html
--
http
ode
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=32779
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-16 15:56 ---
Mark as duplicate. At least ac does works after reverting the patch.
*** This bug has been marked as a duplicate of 32773 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from burnus at gcc dot gnu dot org 2007-07-16 15:56 ---
*** Bug 32779 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-17 15:25 ---
> Also
> http://www.lrz-muenchen.de/services/software/mathematik/gsl/fortran/index.html
> fails with the same error.
> (One needs to change "g95)" into "g95|gfortran)" in configure.)
ents
Product: gcc
Version: 4.3.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
--- Comment #10 from burnus at gcc dot gnu dot org 2007-07-17 17:58 ---
> Does the patch fix this, please?
Yes, otherwise I would have blamed you in the patch review ;-)
> The testcase that you sent me breaks gfortran
> in other places and probably should have a PR all of its
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=32797
rejects-valid
Severity: normal
Priority: P3
Component: 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=32800
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-17 21:33 ---
Subject: Bug 32535
Author: burnus
Date: Tue Jul 17 21:33:34 2007
New Revision: 126706
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126706
Log:
2007-07-17 Janus Weil <[EMAIL PROTECTED]&g
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-17 21:34 ---
FIXED in the trunk; no regression => no backporting.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Ad
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||32630
nThis
Component: 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=32804
--- Comment #4 from burnus at gcc dot gnu dot org 2007-07-18 22:02 ---
Subject: Bug 32801
Author: burnus
Date: Wed Jul 18 22:02:21 2007
New Revision: 126732
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126732
Log:
2007-07-18 Christopher D. Rickett <[EMAI
--- Comment #5 from burnus at gcc dot gnu dot org 2007-07-18 22:06 ---
> - In the original programs (from which this example is extracted, the
>declaration of C_PTR prior to C_LOC causes the compiler to erroneously
>diagnose various other constructs
The reported pr
--- Comment #5 from burnus at gcc dot gnu dot org 2007-07-19 06:14 ---
Subject: Bug 32600
Author: burnus
Date: Thu Jul 19 06:14:19 2007
New Revision: 126744
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126744
Log:
2007-07-19 Christopher D. Rickett <[EMAI
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-19 06:35 ---
This regression is caused by
r126647 | fxcoudert | 2007-07-15 01:59:00 +0200 (So, 15 Jul 2007) | 7 lines
PR 32036
* trans-array.c (gfc_conv_array_ref): Only evaluate index once.
Without bounds check
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-19 08:30 ---
For the accept-invalid part (c_loc of an assumed-shape array). The standard
says:
"X shall either
(1) have interoperable type and type parameters and be
(a) a variable that has the TARGET attribute a
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=32816
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-19 16:30 ---
In gfc_match_allocate
m = gfc_match_variable (&tail->expr, 0);
matches successfully, but it fails at:
if (gfc_match (" )%t") != MATCH_YES)
goto syntax;
As "i" is scalar, it doe
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
ng_string
--
Summary: Useroperator
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #8 from burnus at gcc dot gnu dot org 2007-07-21 20:17 ---
Besides c_funloc (patch submitted) and c_f_pointer (scalar case, i.e. no SHAPE)
also c_associated (c_associated_1/c_associated_2) can be moved into trans*.c
The code for c_associated is essentially the same as for
--- Comment #10 from burnus at gcc dot gnu dot org 2007-07-23 06:03 ---
Subject: Bug 32600
Author: burnus
Date: Mon Jul 23 06:03:33 2007
New Revision: 126835
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126835
Log:
2007-07-23 Christopher D. Rickett <[EMAI
MED
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=32860
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Keywords|diagnostic |
http
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-23 09:03 ---
Subject: Bug 32732
Author: burnus
Date: Mon Jul 23 09:03:30 2007
New Revision: 126836
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126836
Log:
2007-07-23 Christopher D. Rickett <[EMAI
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-23 09:08 ---
FIXED. Steve, please check under IA64 HP-UX whether it works now.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-23 09:32 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01543.html
Cf. also PR 32797.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32800
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-23 09:32 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01543.html
Cf. also PR 32800.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32797
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-23 17:47 ---
Subject: Bug 32797
Author: burnus
Date: Mon Jul 23 17:47:16 2007
New Revision: 126856
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126856
Log:
2007-07-23 Christopher D. Rickett <[EMAI
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-23 17:47 ---
Subject: Bug 32800
Author: burnus
Date: Mon Jul 23 17:47:16 2007
New Revision: 126856
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126856
Log:
2007-07-23 Christopher D. Rickett <[EMAI
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-23 17:51 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-23 17:52 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #6 from burnus at gcc dot gnu dot org 2007-07-24 09:42 ---
I believe this is fixed by PR30940.
The first example gives:
Warnung: Actual argument contains too few elements for dummy argument 'i' (4/6)
at (1)
The second example:
Warnung: Character length of actua
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-24 10:09 ---
Error message:
fatal error: gfc_todo: Not Implemented: complex character array constructors
compilation terminated.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-24 11:20 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01709.html
See also PR 31205.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32842
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-24 13:28 ---
The following patch works for the original example; it also works in principle
for the additional example, but there the error message is printed three times.
Index: gcc/fortran/expr.c
--- Comment #9 from burnus at gcc dot gnu dot org 2007-07-24 13:31 ---
Daniel, could you update the bug status; e.g. mark it as fixed or write what
still needs to be done.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
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=32876
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-24 13:49 ---
Index: resolve.c
===
--- resolve.c (revision 126873)
+++ resolve.c (working copy)
@@ -7040,6 +7044,13 @@ resolve_fl_namelist (gfc_symbol *sym
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=32879
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=32880
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-24 16:20 ---
Created an attachment (id=13961)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13961&action=view)
Reduced test case
Reduced test case which does not depend anymore on external files.
Coredumps with g
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-24 16:44 ---
> Confirmed, thought the documentation for RANDOM_NUMBER already mentions that
> it
> uses KISS, so this applies only to the legacy intrinsics.
Is KISS clear enough? If yes then it indeed only applie
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=32884
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-24 17:22 ---
Confirmed.
The problem is that gfc_pure(NULL) is called and thus
sym = gfc_current_ns->proc_name;
is used as procedure symbol, which is "bar" and not "foo".
The following patch fix
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-24 17:33 ---
Seemingly the error is detected and only on writing the error the segmentation
fault occurs:
==494== Invalid read of size 8
==494==at 0x41D398: show_locus (error.c:171)
==494==by 0x41D29D: error_print
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-24 18:28 ---
Others cannot reproduce it (on i686 & x86_64), but here I can with gfortran-4.1
& 4.2 of SUSE, with the vanilla 4.2 and with 4.3.
The problem is for whatever reason the "&code->expr->where
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-24 18:53 ---
This is a translation bug:
msgid "Cannot assign to variable '%s' in PURE procedure at %L"
msgstr "In PURE-Prozedur bei %L kann nicht an Variable »%s« zugewiesen werden"
As %L / %s
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-24 20:53 ---
Of cause it did not regtest :-(
(fails for impure_assignment_2.f90, l.58, were "B" is a host-associated
variable; thus gfc_pure(NULL) seems to be ok.)
The problem is actually that gfc_check_pointer_assign
normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 27766
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32890
--- Comment #4 from burnus at gcc dot gnu dot org 2007-07-25 11:39 ---
Reminder: If implemented, change the PACK library function to print out the
size of LHS/RHS array (cf. PR 30814 & PR 32890).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
--- Comment #5 from burnus at gcc dot gnu dot org 2007-07-25 17:15 ---
> This fixes the PR but is not regtested:
Patch looks OK and regtests on x86-64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31211
--- Comment #7 from burnus at gcc dot gnu dot org 2007-07-26 09:49 ---
> > Patch looks OK and regtests on x86-64.
> That's strange - for me, it breaks ret_pointer_2.f90, at the statement print
> *,
> x(3) because the elements in the data transfer are incorrectly
4.3.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=32903
us: UNCONFIRMED
Keywords: documentation
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=32902
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-25 18:09 ---
> I think that, by extension, components with private components must be illegal
> too.
Which means checking over several levels. For the following program, g95 gives
an error. (NAG f95, ifort don't.)
&g
--- Comment #5 from burnus at gcc dot gnu dot org 2007-07-27 09:50 ---
Subject: Bug 32903
Author: burnus
Date: Fri Jul 27 09:49:55 2007
New Revision: 126975
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126975
Log:
2007-07-27 Tobias Burnus <[EMAIL PROTECTED]&g
us: UNCONFIRMED
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=32913
iority: 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=32924
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=32925
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-28 11:57 ---
Possibly a duplicate of PR 31213.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid, 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.or
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-28 13:29 ---
The problem seems to be that in decl.c the var_element() function assumes that
it only has to match a variable and not also, e.g., an array element.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32928
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-28 14:00 ---
R532 data-stmt-constant is scalar-constant
or scalar-constant-subobject
or signed-int-literal-constant
or signed-real-literal-constant
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-30 12:41 ---
Works with 2007-02-02-r121508 (on x86-64-linux)
Fails with 2007-02-02-r121519 (on x86-64-linux)
Ignoring Java and testsuite changes one finds the following changelog:
gcc/ChangeLog:
+2007-02-02 Ian Lance Taylor
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-30 15:45 ---
The problem is that "all_res" is not only the name of a (result) variable but
also of the function itself.
The following - not regtested - should work (also if one uses ENTRY rather than
FUNCTION).
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-31 15:10 ---
I can this reproduce on x86-64-linux (20070731, rev127091), however, only with
the option "-m32"; using "-m64" I don't get a crash and valgrind shows no
problems.
For "-m32 -O1 -fpredic
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-01 17:55 ---
Subject: Bug 32936
Author: burnus
Date: Wed Aug 1 17:55:24 2007
New Revision: 127135
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127135
Log:
2007-08-01 Tobias Burnus <[EMAIL PROTECTED]&
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-01 18:00 ---
FIXED in GCC 4.3; as it is not regression [and no wrong-code bug either] I will
not backport it to 4.2.x or 4.1.x -> mark as fixed.
Note: GCC gfortran 4.3.0 nightly builds are e.g. available at
http://gcc.gnu.
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-01 18:39 ---
> Could somebody test the patch below, please?
Build (/= bootstrapped) and check-gfortran'ed (-m64) on x86-64-Linux.
I get an ICE (segmentation fault) for gfortran.dg/derived_comp_array_ref_1.f90:
==26501==
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-02 07:56 ---
The essential point is that "b" is allocatable; "a" can be a parameter or a
simple dimension(2,2) array. The kind does also not matter. If one uses only
conjg or only transpose there is no error.
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-02 16:32 ---
For my testcase (with parameter) I find the following in the original dump:
(*D.1371)[(S.4 + D.1380) * D.1384 + D.1387] = CONJ_EXPR <(*(complex4[0:] *)
parm.1.data)[S.4 * D.1383 + D.1386]>;
Rewritten t
--- Comment #7 from burnus at gcc dot gnu dot org 2007-08-02 20:56 ---
CONJ_EXPR< a.data[0*1+(-2)]>
The offset = -2 is generated in gfc_conv_expr_descriptor:
offset = gfc_index_zero_node;
for (n = 0; n < ndim; n++) // ndim = 2
start = info-&
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=32979
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32980
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-03 20:25 ---
> If we're going to implement isnan, then we should implement all of the
> FP classification functions (isfinite, isinf, isnan, isnormal, and maybe
> fpclassify).
I'm not sure if this is needed.
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-03 20:45 ---
> I then believe that we do not need isnan. A person can use
> either IEEE_* when it becomes available or bind(c). I don't
> see why isnan is special in comparison to isinf.
I don't see i
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-04 11:57 ---
Created an attachment (id=14020)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14020&action=view)
Patch for invoke.texi
> I'd go for implementing isnan as an extension, and only isnan. (unt
nassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32985
Product: gcc
Version: 4.3.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://
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-04 13:17 ---
Interestingly, the following gives an error:
type a
integer :: i
end type a
type(a) :: t
common /c/ t
end
Related, the following is accepted but invalid (for different reasons):
"C588 (R558) A c
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-04 13:18 ---
And the following valid program is rejected:
use iso_c_binding
implicit none
type, bind(C):: a
integer(c_int) :: i
end type a
type(a) :: t
common /c/ t
end
--
http://gcc.gnu.org/bugzilla
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-04 13:36 ---
"C588 (R558) A common-block-object shall not be a dummy argument, an
allocatable variable, a derived-type object with an ultimate component that is
allocatable, an automatic object, a function name, an entry na
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-04 16:53 ---
I just checked: ifort, sunf95, openf95, g95 and even the picky NAG f95 accept
it. None of the compilers gives a warning except of "ifort" when passing the
option "-stand 95":
fortcom: Warnin
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-04 17:37 ---
> > - Silently accept the tab in libgfortran
> I disagree on this point.
Discussion -> [EMAIL PROTECTED] list; starts here:
http://gcc.gnu.org/ml/fortran/2007-08/msg00097.html
> > - Give a warnin
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-04 19:32 ---
> Aren't they included in the current F2008, by any chance?
Yes and no. The Fortran 2008 draft has the following functions, but they are
not necessarily called the same as the typical vendor extensions.
h
801 - 900 of 4285 matches
Mail list logo
