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
--- 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
--- 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
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=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
mmon block
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 triple
--- 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 #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
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 #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
ses, the current status quo.)
--
Summary: Consider a 'no arg check' directive
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassi
--- 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 wo
re constructors,
and allocatable components
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
Repo
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976
Walter Spector changed:
What|Removed |Added
CC||w6ws at earthlink dot net
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48820
--- Comment #6 from Walter Spector 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 the following
small test case:
mo
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
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
--- Comment #8 from Walter Spector 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=48820
Walter Spector changed:
What|Removed |Added
CC||w6ws at earthlink dot net
--- Comment
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 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)
and should give an error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51589
--- Comment #2 from Walter Spector 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 the intent(out) to be an e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51589
--- Comment #5 from Walter Spector 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
not diagnose that case eithe
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
: 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 in
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 = 'xyz
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 #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 ex
: 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
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=83779
--- Comment #2 from Walter Spector ---
Ah. Thank you.
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, -Wextr
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 leng
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117
Walter Spector changed:
What|Removed |Added
CC||w6ws at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117
--- Comment #6 from Walter Spector 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 snapshot of
the 4.8 trunk.):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117
--- Comment #8 from Walter Spector 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 works. (On Intel too.)
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=70149
--- Comment #1 from Walter Spector ---
Typo: 5.8.4 -> 4.8.4
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=34640
--- Comment #38 from Walter Spector ---
Paul,
THANK YOU!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56471
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 ENVIRONMENT portion of the gfortran man page states:
The gfortran compiler currently does not make use of any environment
variables to control its operation
: 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=82367
--- Comment #1 from Walter Spector ---
PGI and NAG both catch this error. I can try Intel if needed.
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' attri
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 F2008
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,
paragraph
: 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 ---
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 this as a GNU
Extension. My
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #3 from Walter Spector ---
I didn't complain to Intel, but I can...
However the compilers that did catch it by default were NAG, lahey, and Absoft.
Walter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #5 from Walter Spector ---
> 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 crashed with several non-gfo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #6 from Walter Spector ---
Adding that both READ and WRITE have this issue. Interestingly, the iolength
version of INQUIRE does not:
inquire (iolength=i), i
1
Error: Expected expression in INQUIRE statement at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #9 from Walter Spector ---
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 with gfortran offering such a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383
Walter Spector changed:
What|Removed |Added
CC||w6ws at earthlink dot net
--- Comment
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=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
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 ---
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 ---
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 not preclude gfortran from return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #14 from Walter Spector ---
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 as GFC_STD_LEGACY.
Walter
--- 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
> ac
--- 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
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
Ass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48048
--- Comment #2 from Walter Spector 2011-03-09
20:25:18 UTC ---
>--- Comment #1 from Tobias Burnus 2011-03-09
>18:50:28 UTC ---
>Report comes too late - it's fixed since 2011-01-26 :-)
>
>Cf. PR 47339 and PR 43062.
>
>I case something is not wor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48048
--- Comment #3 from Walter Spector 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 components are not supported.
--- 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'r
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
Assi
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-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33888
--- 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) is
: 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 #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(l
COMMON
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36058
--- 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 reject
/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 - he
--- 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
> dy
Severity: normal
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
--- 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
--- 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
> re
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, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298
Walter Spector changed:
What|Removed |Added
CC||w6ws at earthlink dot net
--- Comment
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 illeg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504
Walter Spector changed:
What|Removed |Added
CC||w6ws at earthlink dot net
--- Comment
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=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=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 #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
92 matches
Mail list logo
