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
: 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=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=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
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?
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=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 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 #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
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
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
: 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
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 ...
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=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
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
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
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
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=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=45794
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo:
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
101 - 137 of 137 matches
Mail list logo
