: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
In the following example (two files) the compiler is generating a reference to
the undefined symbol __vtab_scalar_func_class_Scalar_func.3804. This is
probably meant
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
The compiler rejects the following valid code that contains no recursion.
module example
type, abstract :: foo
contains
procedure :: dot
procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94909
--- Comment #3 from Neil Carlson ---
Richard, this is just a typical declaration of an abstract type. An extension
of this type will have to define the deferred dot_ function with an interface
that happens to match the interface of dot. The dot f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87625
--- Comment #6 from Neil Carlson ---
Yes, can this please be back-ported? Still broken on at least 8.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
Some relatively recent change (since ~Sept) has broken 8.2.1 and 9.0. Code that
contained the type of allocation given in the following
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
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. I
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 array(ncell
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=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
type(pa
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 of the
: 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
: 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. PR8411
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84120
--- Comment #1 from Neil Carlson ---
This explains the problem underlying PR82205
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=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 th
: 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.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84189
Neil Carlson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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 for
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=89174
--- Comment #3 from Neil Carlson ---
r265171 is the commit that broke the 9.0 trunk; r265171 segfaults but r265170
works correctly. I haven't been able to pinpoint where this stuff was
back-ported to the 8 branch, but it definitely was. This exam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566
Neil Carlson changed:
What|Removed |Added
CC||neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
--- Comment #13 from Neil Carlson ---
I've pinpointed were the regression was introduced on the 8 branch.
r268313 segfaults, but r268311 (the preceding change to 8) works fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174
--- Comment #14 from Neil Carlson ---
The comment for r268313 calls out a change to
gfc_find_and_cut_at_last_class_ref -- same function Thomas worked on for the
fix on the trunk.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
My colleague passed this example on to me to report. This runs correctly with a
8.2.1 and 9 from Sept, but fails with the current 8 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925
--- Comment #2 from Neil Carlson ---
Right, when I said it failed on 8, I had misunderstood my colleague; he had
only tried 9.
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 0x
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 allo
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=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=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 reporte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84432
Neil Carlson changed:
What|Removed |Added
CC||neil.n.carlson at gmail dot com
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=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=49213
Neil Carlson changed:
What|Removed |Added
Version|4.7.0 |8.0.1
--- Comment #26 from Neil Carlson
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
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 tim
: 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
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 #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=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
+++ b/literal_characte
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
+++ b/overload_
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=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), deferr
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 be
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,
or
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 gfortran
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 "&BAR" (like I was expecting/hoping when I started experimenting
with the original example). 13.11.3.1 says
1 I
: 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 an
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 #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
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(:,:)
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
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 #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
: 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
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: in
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 an
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 exe
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=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
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
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 =
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 #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
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=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 ^@
: 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 na
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
e
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=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))
co
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, 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 #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 separ
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=67564
--- Comment #11 from neil.n.carlson at gmail dot com ---
Ping
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, but
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 pu
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
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. It is
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 i
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 su
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=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.
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
1 - 100 of 139 matches
Mail list logo
