http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
Summary: [OOP] gfortran rejects structure constructor
expression
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786
--- Comment #7 from neil.n.carlson at gmail dot com 2011-05-28 18:14:04 UTC ---
So what is the status of this defect? It would appear to be will not fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #3 from neil.n.carlson at gmail dot com 2011-06-16 20:35:48 UTC ---
(In reply to comment #1)
Note: Intrinsic assignments to polymorphic variables are forbidden [...]
This was really about the structure constructor; the assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #4 from neil.n.carlson at gmail dot com 2011-06-16 20:49:32 UTC ---
An intuitive way of viewing (and maybe even implementing I guess) the process
triggered by a structure constructor is as a sequence of assignment statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #6 from neil.n.carlson at gmail dot com 2011-06-16 22:12:17 UTC ---
(In reply to comment #5)
(In reply to comment #4)
An intuitive way of viewing (and maybe even implementing I guess) the
process
triggered by a structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #7 from neil.n.carlson at gmail dot com 2011-06-16 22:18:14 UTC ---
I want to emphasize again that the error I wanted to report was that gfortran
is rejecting valid structure constructor expressions (see comment 3). It looks
from you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786
Summary: Relational operators .eq. and == are not recognized as
equivalent
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786
--- Comment #2 from neil.n.carlson at gmail dot com 2010-09-25 00:27:24 UTC ---
Note also that the problem isn't restricted to .eq./== ; it appears to occur
with all the other pairs of equivalent operators: .ne./!=, .lt./, etc. At
least
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45794
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66577
--- Comment #5 from neil.n.carlson at gmail dot com ---
> Error: Function result 'intsuccess' at (1) cannot have an initializer
> I don't understand.
C506 -- the type specification for a function result cannot have an
initialization.
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
The following example is rejected by 6.0.0 20151025, but is accepted by 6.0.0
20150906 and 5.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070
neil.n.carlson at gmail dot com changed:
What|Removed |Added
CC||neil.n.carlson at gmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070
--- Comment #23 from neil.n.carlson at gmail dot com ---
Here's an even simpler example with the deferred length character array as a
local variable -- not a function result or dummy argument. Sure seems as
though the allocate statement itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66577
neil.n.carlson at gmail dot com changed:
What|Removed |Added
CC||neil.n.carlson at gmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68216
--- Comment #5 from neil.n.carlson at gmail dot com ---
Paul, I'm delighted than someone is finally working on this long-standing
problem. I hope you're also taking a look at all the other related PRs that
Dominique pointed out; I suspect
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
The following example produces a runtime recursion error during finalization
with -fcheck=recursion. There is indeed recursion, but the final subroutine is
declared recursive
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
The following example produces incorrect results from the sourced allocation
involving class(*) arrays. Perhaps the same as 64692
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67562
--- Comment #2 from neil.n.carlson at gmail dot com ---
Please pardon my ignorance (I rarely use gfortran), but is there a 6.0 source
distribution somewhere? The latest I can find is 5.2. Are you talking about
the current trunk? I'm puzzled
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
The following example segfaults on the allocate statement.
Using the trunk version of 20150906.
program main
type :: any_vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070
--- Comment #30 from neil.n.carlson at gmail dot com ---
Paul, you've done a lot of great work here (a huge thanks!) and I can confirm
that many of my deferred-length character issues seem to be resolved now with
the trunk (r232457, 1/15/2016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070
--- Comment #31 from neil.n.carlson at gmail dot com ---
Sorry, ignore the example of comment 30. I had already reported this in PR
67564 (not a duplicate of this one). I'm getting old ...
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
In the following example program the call to X%SUB should resolve to SUB_ARRAY,
but instead the compiler tries to resolve it to the elemental SUB_ELEM, but
then emits
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
-Wsurprising issues spurious warnings about final procedures.
module foo_type
type foo
contains
final :: foo_delete
end type
contains
subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70312
neil.n.carlson at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175
neil.n.carlson at gmail dot com changed:
What|Removed |Added
CC||neil.n.carlson at gmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67564
--- Comment #10 from neil.n.carlson at gmail dot com ---
Here's another example, but in this case the bad, source-allocated class(*)
variable is just a local variable. It is rank-2 however.
character(:), allocatable :: array(:,:)
array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67564
--- Comment #9 from neil.n.carlson at gmail dot com ---
I confirm that my original example now runs without error with the current
6-branch. However this variation, where the allocated unlimited polymorphic
variable is passed back as a return
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
The following example triggers an ICE with gfortran 6.1.0:
subroutine ice_example
type :: inner
integer :: n
end type
type :: outer
type(inner), allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67564
--- Comment #11 from neil.n.carlson at gmail dot com ---
Ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072
--- Comment #3 from neil.n.carlson at gmail dot com ---
Why is this tagged with 'ice-on-invalid-code'? What is invalid about the code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072
--- Comment #5 from neil.n.carlson at gmail dot com ---
Here's a more complete example that avoids the ICE.
It gives correct results with 6.3:
5 fubar
5 fubar
But incorrect results with 7.0:
5 fubar
0
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
This example gives an ICE with the current 7.0 trunk and all 6.x releases:
function foo()
class(*), pointer :: foo
character(3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072
--- Comment #8 from neil.n.carlson at gmail dot com ---
Ping. Is there any interest in fixing this regression?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072
neil.n.carlson at gmail dot com changed:
What|Removed |Added
Known to fail||7.1.0
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996
--- Comment #5 from neil.n.carlson at gmail dot com ---
I've built the svn trunk and tested the examples with it. The ICEs with the
comment 2 and 3 examples are gone, as Dominique found. The comment 1 example
continues to segfault when executed
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
I'm going to give 3 examples. The first gives a spurious run time segfault. The
others are attempts to work around the problem, but give an internal compiler
error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996
--- Comment #2 from neil.n.carlson at gmail dot com ---
In the final example I drop the elemental attribute from the FOO final
procedure and modify the BAR final procedure to loop over the elements of its B
array component. This too yields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996
--- Comment #1 from neil.n.carlson at gmail dot com ---
In the second example, I add a final procedure for BAR (not necessary) and
explicitly call the FOO final procedure on its B component. This gives an ICE
f951: internal compiler error
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
The following example gives an ICE with the current 8.0 trunk, but not with
7.2.1 or 6.4.1.
module fhypre
use iso_c_binding, only: c_ptr, c_null_ptr
use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
Neil Carlson changed:
What|Removed |Added
CC||neil.n.carlson at gmail dot com
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
The current 8.0 trunk gives an ICE on the following example. 6.4.1 also gives
an ICE.
type foo
integer n
end type
type bar
type(foo) array(2)
end type
type(bar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146
--- Comment #1 from Neil Carlson ---
I thought that assigning the select case expression to a temporary integer and
using that variable in the select case statement would be a workaround, but no.
You can put anything unrelated to the associate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
--- Comment #2 from Neil Carlson ---
Here's another example. The ICE is coming at the same place, toplev.c:325, so
I think it may be the same underlying problem. Like the original example, the
ICE occurs only when the main program is in a
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
The current 8.0 trunk gives an ICE on the following example, but only when then
the program units are in two separate files. Works fine with 7.2.1 and 6.4.1.
module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
--- Comment #3 from Neil Carlson ---
Unlike comment 0 code, comment 2 code also gives an ICE with 7.2.1 and 6.4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
--- Comment #1 from Neil Carlson ---
Note that the incorrect string "b" is not actually 1 character long, but 3
characters: a "b" followed by 2 non-printing characters. Vim shows them as ^@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146
--- Comment #2 from Neil Carlson ---
Turns out you don't need anything at all in the associate block to get an ICE:
type foo
integer n
end type
type bar
type(foo) array(2)
end type
type(bar) b
associate (n_array => b%array%n)
end associate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #25 from Neil Carlson ---
Here's another example similar to those above but even simpler IMHO and
involving a CLASS(*) pointer component
type box
class(*), pointer :: uptr => null()
end type
integer, target :: n
call sub(box(n))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #24 from Neil Carlson ---
Ping. This bug has been around for over 6 years now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072
--- Comment #19 from Neil Carlson ---
This fixes the code of comment 12 for me. All the other test cases continue to
work as expected. This can be closed as "fixed" as far as I'm concerned.
Thanks Paul!
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
Intrinsic assignment of a derived type with allocatable CLASS(*) array
component is not being done correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072
--- Comment #16 from neil.n.carlson at gmail dot com ---
I've confirmed Dominique's findings: Code in comments 0, 5, 11 are working now
with Paul's commit (Thanks!), but comment 12 code still gives an ICE.
Should I create a new PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072
--- Comment #12 from neil.n.carlson at gmail dot com ---
The second adds a select case and print to get at the result value before its
handed back. This produces an ICE with 6.4.1, 7.2.1, and 8.0.0 (20171028)
character(3), target :: a = 'foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072
--- Comment #13 from neil.n.carlson at gmail dot com ---
Correction to Comment 11. That example gives the *correct* result on 6.4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072
--- Comment #11 from neil.n.carlson at gmail dot com ---
Paul, I'm organizing all my bug report examples, and ran across these two test
cases from September that I can't find I ever reported. They are VERY similar
to the original example I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996
--- Comment #8 from neil.n.carlson at gmail dot com ---
> If I remove 'elemental' for 'subroutine foo_destroy', the segfault is gone.
In that case the final procedure doesn't match the array component and wouldn't
be called. I susp
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
In the following example the pointer assignment "p => x%dataptr()" is rejected
because the compiler does not recognize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
Neil Carlson changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
Neil Carlson changed:
What|Removed |Added
Version|8.0.1 |8.1.1
--- Comment #27 from Neil Carlson
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
When compiled with -fcheck=bounds, the following example gives a spurious
runtime bound mismatch error on the 'b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
--- Comment #5 from Neil Carlson ---
I disagree (in part) with comment 4. Ncells is a valid specification statement
(see 7.1.11, par 2 (4), Fortran 2008). Its value need not be known at compile
time; only when the get() function is executed.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
In the continuing theme of the PDT implementation incorrectly regarding type
parameters as components (see PR84119, PR84120, PR84122
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84120
--- Comment #1 from Neil Carlson ---
This explains the problem underlying PR82205
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
C465 (F08) prohibits an internal procedure from being a type bound procedure,
but gfortran mistakenly allows it when the TPB has the NOPASS attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84189
Neil Carlson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
Gfortran allows invalid nested derived type constructors. Consider this
example:
type parent
integer :: a, b
end type
type, extends(parent) :: child
real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143
--- Comment #2 from Neil Carlson ---
(In reply to Dominique d'Humieres from comment #1)
>
> gives 0. Should not it be 3?
Yeah. I noticed the same thing myself. It is 3 if the type parameters are
removed. I was intending to report it, but I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84093
--- Comment #2 from Neil Carlson ---
The forced cascade of keyword use is rather annoying, so perhaps someone was
thinking the current gfortran behavior is a useful extension, and it almost is.
But consider this example:
type :: parent
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
Here's yet another case of where the PDT implementation has not correctly
distinguished derived type parameters from the components of the type.
(c.f. PR84119
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
There seems to be a misconception in the implementation of PDT that the type
parameters are (in part) just regular components
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
Consider the PDT
type foo(dim)
integer,len :: dim
integer :: array(dim)
end type
While investigating how other compilers do on the gfortran testsuite programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84218
Neil Carlson changed:
What|Removed |Added
CC||neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84122
--- Comment #3 from Neil Carlson ---
Here's a related invalid example that gfortran accepts:
module mod
type foo(dim)
integer,len,public :: dim
integer :: array(dim)
end type
end module
PUBLIC/PRIVATE attributes are not valid attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381
Neil Carlson changed:
What|Removed |Added
CC||neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996
--- Comment #9 from Neil Carlson ---
With today's version (r257782) I'm still seeing the same thing Dominique
reported in comment 7, except that there is no longer any abort -- the programs
terminate successfully (0 exit code) despite the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84432
Neil Carlson changed:
What|Removed |Added
CC||neil.n.carlson at gmail dot com
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
I stumbled across this problem while reducing an actual error to a minimal test
case (PR84539). I wasn't going to bother reporting it (it seems a bit too
silly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84432
--- Comment #5 from Neil Carlson ---
No, both of those are valid. The constraint is on component initialization, and
type parameters are *not* components. So something like this would be invalid
by F08:C458
type t(a)
integer, len :: a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84432
--- Comment #6 from Neil Carlson ---
... and this would also be invalid
type t(a)
integer, len :: a = 3
character(len=a) :: c = 'foo'
end type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
Neil Carlson changed:
What|Removed |Added
Version|4.7.0 |8.0.1
--- Comment #26 from Neil Carlson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69563
Neil Carlson changed:
What|Removed |Added
Version|6.0 |8.0.1
--- Comment #2 from Neil Carlson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84539
--- Comment #1 from Neil Carlson ---
And same example but using character data. This compiles but gives a segfault
when run at the assignment statement.
class(*), allocatable :: x(:)
x = ['foo','bar']
select type (x)
type is (character(*))
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
--- Comment #4 from Neil Carlson ---
Note that if the sourced allocation in the comment 0 test case
allocate(x%v,source=['foo','bar'])
is replaced by the equivalent (I think) assignment
x%v = ['foo','bar']
Then the code produces a run
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
Here are some issues with array assignment to an allocatable CLASS(*) array
using the current 8.0 trunk.
class(*), allocatable :: x(:)
x = [4,2]
select type (x
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
The following example produces the expected result with 6.4.1, but not with the
latest 7 and 8 trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381
--- Comment #5 from Neil Carlson ---
Thomas, I saw you generated a patch with "stop n". I'd love to see how you did
it -- the regexp and counting magic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072
--- Comment #22 from Neil Carlson ---
I just verified with 8.0 trunk (r257868) that all three of my examples continue
to work as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
--- Comment #7 from Neil Carlson ---
Perhaps this modification of comment 2 code is clearer.
Put this in one file:
module mod1
integer :: ncells
end module
module mod2
contains
function get() result(array)
use mod1
real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84539
--- Comment #4 from Neil Carlson ---
Update with 8.2.0
The ICE is gone, but a run time segfault remains:
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x7f82986c06df in ???
#1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84546
--- Comment #6 from Neil Carlson ---
Thank you, thank you Paul!
This also fixes my test case for PR83118 which I think must have been due to
the same underlying problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381
--- Comment #12 from Neil Carlson ---
Argh... here's the *correct* patch
diff --git a/literal_character_constant_1.inc
b/literal_character_constant_1.inc
index ba24966..40375cd 100644
--- a/literal_character_constant_1.inc
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381
--- Comment #13 from Neil Carlson ---
And one more missed file due to a line split between the "call" and "abort".
Here's the patch:
diff --git a/overload_1.f90 b/overload_1.f90
index afd4f81..66fbea4 100644
--- a/overload_1.f90
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381
--- Comment #11 from Neil Carlson ---
One more missed file, an include file included by
literal_character_constant_1_x.F. Here's the patch:
diff --git a/literal_character_constant_1.inc
b/literal_character_constant_1.inc
index ba24966..8beea79
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88043
--- Comment #1 from Neil Carlson ---
I've been poking at Zach's example and trimmed it down a bit:
In one file:
module typeA
implicit none
private
type, abstract, public :: A
contains
procedure :: call_sub
procedure(z),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996
--- Comment #10 from Neil Carlson ---
A reader on c.l.f suggested this workaround for the bug. I'm sharing it here
because I think it may help to isolate where the problem is. The suggestion
was to make the B array component allocatable and
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
The current 8.2.1 compiler rejects this example,
module foo_nml
real :: x
namelist /foo/ x
end module
program main
use foo_nml, only: bar => foo
x =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169
--- Comment #4 from Neil Carlson ---
I think the intent of
C8102 (R868) The namelist-group-name shall not be a name accessed by use
association.
is to say you can't define a namelist with a name accessed by use association.
That seems to fit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169
--- Comment #5 from Neil Carlson ---
Stated a bit more clearly, the question is, whether in
The namelist-group-name shall not be a name accessed by use association.
the name (in the scope of the declaration) is accessed by use association,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169
--- Comment #9 from Neil Carlson ---
Actually I think the usage in comment 8 is an intentional extension. There is a
test in the dg test suite that does exactly this if I remember correctly. The
test was namelist_use.f90. I was told that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169
--- Comment #10 from Neil Carlson ---
Also a remark about the output of comment 7 just in case someone is thinking it
ought to say "" (like I was expecting/hoping when I started experimenting
with the original example). 13.11.3.1 says
1
1 - 100 of 135 matches
Mail list logo
