https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80666
--- Comment #8 from Jos de Kloe ---
Yes I would object to closing it.
This issue has a large impact on significant bodies of legacy code in our
institute.
I understand that you wish to enforce "standards", but removing a "Non-standard
extension"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80666
--- Comment #6 from Jos de Kloe ---
Thanks for your test results and views on this matter.
> (1) PARAMETER has a very precise definition in Fortran and AFAICT this
> definition (named constants) does not match your use in the above quotation.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80666
--- Comment #2 from Jos de Kloe ---
(In reply to Dominique d'Humieres from comment #1)
> Why do you think this a bug in gfortran?
>
> The code compiles if you remove 'implicit none'. With it you have to define
> 'keylen' before using it, as in y
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: kloedej at knmi dot nl
Target Milestone: ---
For gfortran v.6.3.1 (on Fedora 25) I noticed that this example code:
subroutine test_arg_order(key,keylen)
implicit none
character
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: kloedej at knmi dot nl
Target Milestone: ---
Created attachment 37778
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37778&action=edit
minimal examp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53685
Jos de Kloe changed:
What|Removed |Added
CC||kloedej at knmi dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594
--- Comment #4 from Jos de Kloe 2012-03-16 11:36:48
UTC ---
> I am lost.
The way around that I mentioned was for gcc 4.7+ (so I cannot test this right
away, but will upgrade as soon as it is feasible for me).
Anyway, thanks for your thoughts.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594
--- Comment #2 from Jos de Kloe 2012-03-16 08:28:11
UTC ---
Thanks for your answer.
Using stop 0 or stop 1 would indeed be a way around, but the awkward thing is
that I do have some requirements to produce different values for the exit
status for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594
Bug #: 52594
Summary: no traceback expected for explicit fortran stop
command combined with -fbacktrace
Classification: Unclassified
Product: gcc
Version: 4.6.2
Statu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52325
--- Comment #7 from Jos de Kloe 2012-03-02 13:50:59
UTC ---
Thanks for your (really) fast response and fix.
I'll keep my eye open for other details that might improve gfortran.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52325
Bug #: 52325
Summary: unclear error: Unclassifiable statement
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569
--- Comment #16 from Jos de Kloe 2011-02-14 14:12:15
UTC ---
(In reply to comment #15)
> FIXED on the 4.4 and 4.5 branches and on the 4.6 trunk.
>
> Thanks Jos and Eric for the reports!
Hi Tobias,
thanks a lot for looking into this issue and f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569
Summary: gfortran does not detect that the parameters for
passing a partial string to a subroutine are
incorrect.
Product: gcc
Version: unknown
Status: UNCONFIRMED
--- Comment #2 from kloedej at knmi dot nl 2008-12-12 14:47 ---
(In reply to comment #1)
> Sort of confirmed. You are aware that 'value-1' corresponds to
> '-HUGE(value)-1', which is out of range for integer numbers of that kind?
Thanks for your reply.
Yes I
nc.
best regards,
Jos de Kloe
--
Summary: double minus sign when printing integer?
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu d
--- Comment #3 from kloedej at knmi dot nl 2008-10-07 11:23 ---
Hi,
thanks for this discussion.
I do agree now that this code was invalid. I was thinking otherwise because no
compiletime or runtime error was issued by any of the compilers that I tried.
Checking this during compilation
ED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kloedej at knmi dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37746
--- Comment #6 from kloedej at knmi dot nl 2008-01-16 14:11 ---
Dear people,
this comment is just to let you know that the problem is also solved on my side
now. My software compiles and runs again as expected.
thanks a lot for your effort and fast response.
Jos de Kloe
--
http
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kloedej at knmi dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34672
--- Comment #5 from kloedej at knmi dot nl 2007-06-01 08:41 ---
(In reply to comment #1)
> for integer overflows, see e.g.
> https://www.cisl.ucar.edu/docs/ibm/ref/fpe.html
> For x86 (32/64) platforms, this does not seem to be directly supported by
> hardware; in this ca
Jos de Kloe
--
Summary: runtime integer overflow checking fails
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kloedej at knmi dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32153
--- Comment #8 from kloedej at knmi dot nl 2007-05-29 07:29 ---
(In reply to comment #7)
Hi,
this is just to report that my code works again as expected.
Thanks a lot for the fast fix of this bug!
Jos de Kloe
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32083
six
gcc version 4.3.0 20070525 (experimental)
best regards,
Jos de Kloe
--
Summary: bug in transfer integer->real->integer
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kloedej at knmi dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32083
--- Comment #10 from kloedej at knmi dot nl 2006-11-27 08:21 ---
thanks for your effort to fix this bug!
I can confirm todays binary version, downloaded from
"http://quatramaran.ens.fr/~coudert/gfortran/gfortran-linux.tar.gz
works fine for me.
best regards,
Jos de kloe
--
--- Comment #5 from kloedej at knmi dot nl 2006-11-24 08:12 ---
Yes, I can confirm the gfortran version used was 4.3.0.
I didn't notice the version number changed when I downoaded the latest version.
Sorry for that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29951
--- Comment #1 from kloedej at knmi dot nl 2006-11-23 09:27 ---
Hi,
a little correction on the just submitted report.
I seem to have mixed up the two cases. The string case fails so it clearly has
nothing to do with the rank of the first parameter to transfer().
Jos de Kloe
incorrect conversion from string to integer by convert()
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kloedej at knmi dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29951
--- Comment #6 from kloedej at knmi dot nl 2006-10-31 08:25 ---
A short additional remark on this item:
I just learned (thanks to Paul Poli) that the NAGware f95 compiler does behave
in the same way as gfortran, i.e. refusing to compile the constant -2147483648
in:
integer(KIND=4) :: i
--- Comment #5 from kloedej at knmi dot nl 2006-10-25 07:16 ---
Thanks for your additional explanation, and the link to the original mail in
the mailing list.
A last remark on my side is then about the actual text of this error message.
People not familiar with the choice made in the
--- Comment #2 from kloedej at knmi dot nl 2006-10-24 15:04 ---
In my simple view as a physicist the minus sign is an integral part of the
number and not an operation on it, but then I didn't have a formal computer
science education. As a gfortran programmer you have a choice h
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kloedej at knmi dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29580
--- Comment #1 from kloedej at knmi dot nl 2006-10-23 12:03 ---
Sorry, variable names should differ of course, the sample code should be:
program testhexconstant
integer, parameter :: i4_ = Selected_Int_Kind( 9)
! works fine
integer(i4_), parameter :: a = z"7F8
dot gnu dot org
ReportedBy: kloedej at knmi dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29561
--- Comment #15 from kloedej at knmi dot nl 2006-03-10 08:27 ---
(In reply to comment #14)
> All I'm saying is that in this situation there seems to be no way to jump
> to some label if something goes wrong (because there is no EOR parameter
> for WRITE).
> But I agree
;
best regards,
Jos de Kloe
--
Summary: incorrect behaviour of error-handler for internal read
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned
Summary: false warning abiout unused label
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kloedej at knmi dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26277
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kloedej at knmi dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26257
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kloedej at knmi dot nl
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23654
38 matches
Mail list logo
