Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: w6ws at earthlink dot net
Target Milestone: ---
When an H edit descriptor is used in a format, only a warning is given when
-std=f95 (or higher) is specified. It should be an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504
Walter Spector changed:
What|Removed |Added
CC||w6ws at earthlink dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57360
--- Comment #9 from Walter Spector ---
It appears that Lfortran issues a message for this case. See:
https://github.com/j3-fortran/fortran_proposals/issues/83#issuecomment-1906266587
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57360
--- Comment #8 from Walter Spector ---
Hi,
It is a good point. The message is helpful when issued within a procedure.
At module scope, it doesn't mean much since everything at that level is SAVE
anyway. This is similar to what happens in C:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57360
--- Comment #5 from Walter Spector ---
IMHO this should be a "surprising" warning when -Wsurprising is specified.
The message should suggest adding an explicit SAVE attribute to make the code
clear.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723
--- Comment #17 from Walter Spector ---
Thank you Thomas!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85603
--- Comment #4 from Walter Spector ---
Hi Paul,
I built an updated compiler that includes your fix. The ICE is gone - thanks!
However the assignment is still not correctly compiled.
The example should be reallocating the character string
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: w6ws at earthlink dot net
Target Milestone: ---
The following test case causes an ICE. First noticed with v5.4, but also
happens with v4.8 and a 4/26/2018 snapshot of v9.0.0. Intel and NAG compile
and run this. PGI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85547
--- Comment #5 from Walter Spector ---
Turns out my third case, in comment #2, is incorrect. To correct it, line 5
should read:
path = (/ 'xyz/' /)
With this correction, my current trunk snapshot works ok. (Doesn't apply to
the first two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85547
--- Comment #2 from Walter Spector ---
Third variant. This one messes up NAG and PGI too:
wws@w6ws-4:/tmp$ cat testch3.f90
program testch
implicit none
character(:), allocatable :: path(:)
path = 'xyz/'
path = (/ character(16) :: &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85547
--- Comment #1 from Walter Spector ---
Slightly different test case - using allocatable string length instead of the
trims. However the same problems are evident:
program testch
implicit none
character(:), allocatable :: path
path =
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: w6ws at earthlink dot net
Target Milestone: ---
The following compiles with gfortran (v4.8.4, 5.4, and a snapshot of todays
9.0), but abends at run-time. Note there are actually two problems shown here:
First, the passed
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: w6ws at earthlink dot net
Target Milestone: ---
The following test case causes an ICE when the allocate statement is present.
This was first noticed with an older development snapshot. However I updated
my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83779
--- Comment #5 from Walter Spector ---
Thanks for mentioning that, Martin.
A couple of us in the project I work on were reviewing the options we specify
in our debug builds to try to smoke out problems. We already use options like
-Wall,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83779
--- Comment #2 from Walter Spector ---
Ah. Thank you.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: w6ws at earthlink dot net
Target Milestone: ---
Does -fbounds-check do anything useful with C/C++ code? The following trivial
code does not trigger any error at run time. (Note: I added the static
attribute because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82367
--- Comment #1 from Walter Spector ---
PGI and NAG both catch this error. I can try Intel if needed.
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: w6ws at earthlink dot net
Target Milestone: ---
Incorrect code caused a ICE:
wws@w6ws-4:/tmp$ cat cls.f90
module cls_allocmod
implicit none
contains
subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56471
Walter Spector changed:
What|Removed |Added
CC||w6ws at earthlink dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
--- Comment #38 from Walter Spector ---
Paul,
THANK YOU!
Assignee: unassigned at gcc dot gnu.org
Reporter: w6ws at earthlink dot net
Target Milestone: ---
The ENVIRONMENT portion of the gfortran man page states:
The gfortran compiler currently does not make use of any environment
variables to control its operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723
--- Comment #8 from Walter Spector ---
Hi Janus,
The ifort compiler has no problem with your example in Comment #5. That
example should be Standard Fortran 90.
The newer F2008 data pointer initialization stuff is largely in ยง4.5.4.6,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723
--- Comment #6 from Walter Spector ---
Hi Janus,
Your test case in Comment #5 is fine - because it is not attempting to
initialize the pointer at compile time. Initializing a pointer at compile time
is a F2008 feature. I was testing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723
--- Comment #4 from Walter Spector ---
As you are surmising, there are actually two problems in the example. First,
'data' needs the 'target' attribute in order to be pointed to. Second, 'data'
must either have the 'target' or a 'pointer'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298
--- Comment #18 from Walter Spector ---
Awesome!
I have noticed one bug so far. The compiler is missing a check to see if the
arguments in the I/O procedures have the 'optional' attribute. It is allowing
the attribute - even though it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298
Walter Spector changed:
What|Removed |Added
CC||w6ws at earthlink dot net
--- Comment
Assignee: unassigned at gcc dot gnu.org
Reporter: w6ws at earthlink dot net
Target Milestone: ---
The following test case demonstrates an ICE when compiling a program attempting
to use the F2008 pointer initialization feature. The example is not legal.
Nonetheless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #25 from Walter Spector ---
Thank you Dominique!
Walter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149
--- Comment #1 from Walter Spector ---
Typo: 5.8.4 -> 4.8.4
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: w6ws at earthlink dot net
Target Milestone: ---
The following causes an ICE on both 5.8.4 and the 20160309 6.0 trunk:
module myptr_mod
implicit none
integer, target, save :: int_data = 42
character(16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #14 from Walter Spector w6ws at earthlink dot net ---
Hi Dominique,
I am sorry I didn't see or respond to your comment from last year. Thank you
for the ping.
Yes, it would be fine with me to recategorize the error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383
Walter Spector w6ws at earthlink dot net changed:
What|Removed |Added
CC||w6ws
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #9 from Walter Spector w6ws at earthlink dot net ---
Harald and Steve: I am quite aware of the std= options, thanks.
My main point is that the default situation violates the Principle of Least
Astonishment. I don't have a problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #5 from Walter Spector w6ws at earthlink dot net ---
It seems quite trivial to fix, but does it really worth the work?
Well, we had an instance where this accidentally slipped into our code. Later
on, our nightly regression runs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #6 from Walter Spector w6ws at earthlink dot net ---
Adding that both READ and WRITE have this issue. Interestingly, the iolength
version of INQUIRE does not:
inquire (iolength=i), i
1
Error: Expected
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: w6ws at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #1 from Walter Spector w6ws at earthlink dot net ---
Simple test case:
program extracomma
implicit none
write (*,*), 1, 2, 3
end program
This compiles without error.
I notice that if I compile with -std=f95, it does diagnose
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #3 from Walter Spector w6ws at earthlink dot net ---
I didn't complain to Intel, but I can...
However the compilers that did catch it by default were NAG, lahey, and Absoft.
Walter
Assignee: unassigned at gcc dot gnu.org
Reporter: w6ws at earthlink dot net
Yes, this is probably a duplicate of the now-closed bug 44504.
The following code returns a stat of 0 from g95, PGI (v13.8), and NAG (v5.3.1).
However Intel and gfortran abend - which is not very friendly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59796
--- Comment #1 from Walter Spector w6ws at earthlink dot net ---
Forgot to mention: The test case was tested with gfortran 4.7.3 and 4.8.2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59796
--- Comment #3 from Walter Spector w6ws at earthlink dot net ---
My initial reaction is that yes, 6.7.3.3 in F08 states what you quoted. And I
agree that it is a programming error to pass a dangling pointer into
deallocate. But that does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976
Walter Spector w6ws at earthlink dot net changed:
What|Removed |Added
CC||w6ws
Assignee: unassigned at gcc dot gnu.org
Reporter: w6ws at earthlink dot net
Bug encountered with a snapshot of todays (June 17, 2013) trunk. The example
compiles ok with 'allocatable' attribute specified (and the related allocate
statement used) for variables t1 and t2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117
--- Comment #6 from Walter Spector w6ws at earthlink dot net 2013-01-04
14:33:15 UTC ---
Another manifestation of this problem is with type extension. Here is another
small example which fails. (Tested on v4.6.3 and also a 1/4/2013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117
--- Comment #8 from Walter Spector w6ws at earthlink dot net 2013-01-04
17:22:31 UTC ---
Good point. The key is:
T1E%T1_T%X= 2.,
If the full expanded version is used, in other words %T1_T is specified, the
example
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117
Walter Spector w6ws at earthlink dot net changed:
What|Removed |Added
CC||w6ws
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
--- Comment #8 from Walter Spector w6ws at earthlink dot net 2012-03-15
17:24:59 UTC ---
Should this bug report number be added to the F2003 meta bug?
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52564
Bug #: 52564
Summary: Accepts invalid: Missing I/O list after comma
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48820
--- Comment #6 from Walter Spector w6ws at earthlink dot net 2012-02-29
15:58:10 UTC ---
Tobias,
If you are interested, I tried the patch you posted on the email list to a
freshly checked out trunk. After building the compiler, I tried
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51589
--- Comment #5 from Walter Spector w6ws at earthlink dot net 2011-12-17
19:04:12 UTC ---
It seems like intent information should be available when the procedures are
USE associated, as opposed to the internal procedures. However gfortran does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51589
Bug #: 51589
Summary: Modification of loop index variable by intent(out) or
intent(inout) procedures
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51589
--- Comment #1 from Walter Spector w6ws at earthlink dot net 2011-12-16
21:32:55 UTC ---
Sorry - my description is backwards from the test case. The first is
intent(inout), and should probably give a warning. The second is intent(out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51589
--- Comment #2 from Walter Spector w6ws at earthlink dot net 2011-12-16
22:37:44 UTC ---
No error messages from Absoft (v9), g95, or PGI (v11.10). All print the
revised version of i, but only perform 10 iterations.
NAG (5.2 edit 721) considers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48820
Walter Spector w6ws at earthlink dot net changed:
What|Removed |Added
CC||w6ws
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48048
Summary: [F2003] Remove constraint on namelist group objects
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48048
--- Comment #2 from Walter Spector w6ws at earthlink dot net 2011-03-09
20:25:18 UTC ---
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-09
18:50:28 UTC ---
Report comes too late - it's fixed since 2011-01-26 :-)
Cf. PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48048
--- Comment #3 from Walter Spector w6ws at earthlink dot net 2011-03-09
23:17:20 UTC ---
I updated my copy of the trunk, and rebuilt 4.6. Non-derived type
allocatable/pointer variables seem to be ok. However allocatable/pointer
derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405
Summary: Preprocessor generated code can exceed 132 characters
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
--- Comment #15 from w6ws at earthlink dot net 2010-09-08 21:32 ---
Subject: Re: Bit intrinsics: ILEN and IBCHNG
FX wrote:
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2010-09-08 19:52
---
Possible remaining are only old extensions, not sure they're useful: ILEN
: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43832
--- Comment #1 from w6ws at earthlink dot net 2010-04-21 14:05 ---
An additional test: with just an OPEN statement with no list, gfortran issues:
In file miniopen.f90:4
open ()
1
Error: Syntax error in OPEN statement at (1)
While the message is technically correct, it would
--- Comment #3 from w6ws at earthlink dot net 2009-12-08 21:34 ---
(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 allocatable components... So, where's the
actual problem?
The example on p243
--- Comment #5 from w6ws at earthlink dot net 2009-12-09 00:27 ---
(In reply to comment #4)
... it dawns on me that the crucial point is, that variables with
initializer get the SAVE attribute which doesn't go well with the ALLOCATABLE
components. Correct?
I am not sure why they put
--- Comment #8 from w6ws at earthlink dot net 2009-05-18 15:36 ---
Subject: Re: Attributes not fully checked comparing actual
vs dummy procedure
Janus,
janus at gcc dot gnu dot org wrote:
--- Comment #7 from janus at gcc dot gnu dot org 2009-05-18 09:36 ---
The commit
components
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
http://gcc.gnu.org
a 'no arg check' directive
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
http
--- Comment #3 from w6ws at earthlink dot net 2009-03-20 02:13 ---
Subject: Re: Consider a 'no arg check' directive
Gents,
I was unaware of Bills TR proposal for a TYPE(*). This is good
news, and would totally solve the problem.
BTW, the no_arg_check directive actually works pretty
--- Comment #2 from w6ws at earthlink dot net 2008-11-27 19:32 ---
Tobias, Steven,
If you would like to usurp this request and use it to implement the complete
set
of F2008 bit intrinsics, please feel free to do so.
For completeness, one other HPF bit intrinsic is ILEN - which counts
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
http://gcc.gnu.org/bugzilla
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37712
--- Comment #3 from w6ws at earthlink dot net 2008-10-02 13:06 ---
Subject: Re: Parent component name getting confused with
structure constructor
Yes, my example is messed up. My excuse is that it was late and
I was tired. Next time I will verify against NAG first.
Please close
--- Comment #4 from w6ws at earthlink dot net 2008-10-02 17:18 ---
I am closing this report.
--
w6ws at earthlink dot net changed:
What|Removed |Added
Status
--- Comment #3 from w6ws at earthlink dot net 2008-07-27 13:52 ---
Subject: Re: Attributes not fully checked comparing actual
vs dummy procedure
burnus at gcc dot gnu dot org wrote:
If actual-argument procedure itself takes procedures as argument, one can
check
recursively, which
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
GCC build triplet: Attributes not fully checked comparing actual vs dummy
procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36947
--- Comment #1 from w6ws at earthlink dot net 2008-07-27 04:22 ---
Fixed summary and keyword fields
--
w6ws at earthlink dot net changed:
What|Removed |Added
GCC build
and/or
libmpfr are missing
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot
--- Comment #1 from w6ws at earthlink dot net 2008-07-03 17:41 ---
Add keyword.
--
w6ws at earthlink dot net changed:
What|Removed |Added
CC
--- Comment #3 from w6ws at earthlink dot net 2008-07-03 17:57 ---
Subject: Re: Compiler aborts with no message when libgmp
and/or libmpfr are missing
pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-03 17:46
--- Comment #6 from w6ws at earthlink dot net 2008-07-03 18:48 ---
Subject: Re: Compiler aborts with no message when libgmp
and/or libmpfr are missing
jvdelisle at gcc dot gnu dot org wrote:
This issue comes up on Cygwin a lot as well...
Yes - it happened to me yesterday - hence
--- Comment #8 from w6ws at earthlink dot net 2008-07-03 20:37 ---
Subject: Re: Compiler aborts with no message when libgmp
and/or libmpfr are missing
burnus at gcc dot gnu dot org wrote:
...
Is this really an issue with my (newer) 4.4 builds? (4.3 and 4.2 are still
dynamically
--- Comment #2 from w6ws at earthlink dot net 2008-04-27 13:24 ---
Subject: Re: Not allowing pointers to derived types in
COMMON
burnus at gcc dot gnu dot org wrote:
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-27 08:01
---
gfortran's rejection is in line
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36058
--- Comment #4 from w6ws at earthlink dot net 2008-03-24 17:47 ---
Subject: Re: Invalid-accepted - public entity with private
type should be diagnosed
pault at gcc dot gnu dot org wrote:
This is permitted in F2003 so you have to apply the F95 standard to extract
the
message out
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #1 from w6ws at earthlink dot net 2008-02-27 18:30 ---
Add keywords
--
w6ws at earthlink dot net changed:
What|Removed |Added
Keywords
--- Comment #7 from w6ws at earthlink dot net 2008-02-05 01:25 ---
Subject: Re: VOLATILE attribute not being honored with
common block variable
Gosh - one learns something everyday. The bit with EQUIVALENCE is an
interesting twist!
It seems that F2003 would allow maximum
variable
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
GCC build triplet: i686-pc
--- Comment #1 from w6ws at earthlink dot net 2008-01-31 03:09 ---
Adding myself to the cc list.
--
w6ws at earthlink dot net changed:
What|Removed |Added
--- Comment #2 from w6ws at earthlink dot net 2007-12-17 15:33 ---
Here is an additional variant of this bug:
program init_bug
implicit none
integer :: i
character(11), parameter :: string=hello world
! This compiles:
character, parameter :: up_string(len (string
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34402
--- Comment #1 from w6ws at earthlink dot net 2007-11-17 15:34 ---
First, the problem is described, and a full test case available, at:
http://www.ncl.ucar.edu/Download/build_from_src.shtml#CompilersNeeded
Second, I am not sure if part b (changing the name from BSS to TEXT
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33888
92 matches
Mail list logo
