[Bug fortran/49213] New: [OOP] gfortran rejects structure constructor expression

2011-05-28 Thread neil.n.carlson at gmail dot com
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:

[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent

2011-05-28 Thread neil.n.carlson at gmail dot com
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.

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

2011-06-16 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

2011-06-16 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

2011-06-16 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

2011-06-16 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/45786] New: Relational operators .eq. and == are not recognized as equivalent

2010-09-24 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/45786] Relational operators .eq. and == are not recognized as equivalent

2010-09-24 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/45794] New: internal compiler error: Segmentation fault

2010-09-25 Thread neil.n.carlson at gmail dot com
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:

[Bug fortran/66577] ICE in generate_finalization_wrapper, at fortran/class.c:1567

2015-11-08 Thread neil.n.carlson at gmail dot com
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.

[Bug fortran/68174] New: Length parameter in character allocation not recognized as a scalar (regression from 5.2)

2015-11-01 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

2015-11-01 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/54070] [4.9/5/6 Regression] Wrong code with allocatable deferred-length (array) function results

2015-11-01 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/66577] ICE in generate_finalization_wrapper, at fortran/class.c:1567

2015-11-07 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/68216] [F2003] IO problem with allocatable, deferred character length arrays

2015-11-06 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/67560] New: False positive with -fcheck=recursion

2015-09-12 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/67562] New: Bad result from sourced allocation with class(*) arrays

2015-09-12 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/67562] Bad result from sourced allocation with class(*) arrays

2015-09-12 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/67564] New: Segfault on sourced allocattion statement with class(*) arrays

2015-09-13 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/54070] [4.9/5 Regression] Wrong code with allocatable deferred-length (array) function results

2016-01-18 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/54070] [4.9/5 Regression] Wrong code with allocatable deferred-length (array) function results

2016-01-18 Thread neil.n.carlson at gmail dot com
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 ...

[Bug fortran/69563] New: Generic TBP incorrectly resolves to elemental

2016-01-29 Thread 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: --- 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

[Bug fortran/70312] New: Spurious -Wsurprising warnings for final subroutines

2016-03-19 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/70312] Spurious -Wsurprising warnings for final subroutines

2016-03-19 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70312 neil.n.carlson at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug fortran/58175] [OOP] Incorrect warning message on scalar finalizer

2016-03-19 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/67564] Segfault on sourced allocattion statement with class(*) arrays

2016-03-21 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/67564] Segfault on sourced allocattion statement with class(*) arrays

2016-03-20 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/77310] New: ICE on SELECT CASE with associate name

2016-08-21 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/67564] Segfault on sourced allocattion statement with class(*) arrays

2016-09-06 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67564 --- Comment #11 from neil.n.carlson at gmail dot com --- Ping

[Bug fortran/79072] [5/6/7 Regression] ICE with class(*) pointer function result and character value

2017-01-13 Thread neil.n.carlson at gmail dot com
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?

[Bug fortran/79072] ICE with class(*) pointer function result and character value

2017-01-13 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/79072] New: ICE with class(*) pointer function result and character value

2017-01-12 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/79072] ICE with class(*) pointer function result and character value

2017-08-12 Thread neil.n.carlson at gmail dot com
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?

[Bug fortran/79072] ICE with class(*) pointer function result and character value

2017-05-07 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/82996] ICE and segfault with derived type finalization

2017-11-15 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/82996] New: ICE and segfault with derived type finalization

2017-11-14 Thread 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'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

[Bug fortran/82996] ICE and segfault with derived type finalization

2017-11-14 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/82996] ICE and segfault with derived type finalization

2017-11-14 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/83148] New: [7.2 regression] ICE: crash_signal from toplev.c:325

2017-11-24 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/79929] [7/8 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

2017-11-24 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929 Neil Carlson changed: What|Removed |Added CC||neil.n.carlson at gmail dot com

[Bug fortran/83146] New: ICE on SELECT CASE statement with associate name

2017-11-24 Thread 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

[Bug fortran/83146] ICE on SELECT CASE statement with associate name

2017-11-24 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

2017-11-24 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/83149] New: ICE on SELECT CASE: crash_signal in toplev.c:325

2017-11-24 Thread 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

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

2017-11-24 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/83118] Bad intrinsic assignment of class(*) array component of derived type (8.0 regression)

2017-11-22 Thread neil.n.carlson at gmail dot com
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 ^@

[Bug fortran/83146] ICE on SELECT CASE statement with associate name

2017-11-24 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

2017-11-24 Thread neil.n.carlson at gmail dot com
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))

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

2017-11-24 Thread neil.n.carlson at gmail dot com
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.

[Bug fortran/79072] ICE with class(*) pointer function result and character value

2017-11-22 Thread neil.n.carlson at gmail dot com
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!

[Bug fortran/83118] New: Bad intrinsic assignment of class(*) array component of derived type (8.0 regression)

2017-11-22 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/79072] ICE with class(*) pointer function result and character value

2017-11-20 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/79072] ICE with class(*) pointer function result and character value

2017-11-18 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/79072] ICE with class(*) pointer function result and character value

2017-11-18 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/79072] ICE with class(*) pointer function result and character value

2017-11-18 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/82996] ICE and segfault with derived type finalization

2017-11-16 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/83012] New: Simply contiguous pointer function not recognized as contiguous

2017-11-15 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type

2018-05-22 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 Neil Carlson changed: What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

2018-05-22 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/86100] New: Spurious error with -fcheck=bounds and allocatable class(*) array components

2018-06-10 Thread neil.n.carlson at gmail dot com
: 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

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

2017-12-26 Thread neil.n.carlson at gmail dot com
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.

[Bug fortran/84143] New: Intrinsic output of PDT incorrectly includes type parameters

2018-01-30 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/84120] Syntax for used for PDT constructors is incorrect

2018-01-30 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84120 --- Comment #1 from Neil Carlson --- This explains the problem underlying PR82205

[Bug fortran/84189] New: Internal procedure allowed as type bound procedure

2018-02-02 Thread 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: --- C465 (F08) prohibits an internal procedure from being a type bound procedure, but gfortran mistakenly allows it when the TPB has the NOPASS attribute

[Bug fortran/84189] Internal procedure allowed as type bound procedure

2018-02-02 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84189 Neil Carlson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug fortran/84093] New: Invalid nested derived type constructor not rejected

2018-01-28 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

2018-01-31 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/84093] Invalid nested derived type constructor not rejected

2018-01-29 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/84122] New: Incorrect statement sequence in PDT definition

2018-01-30 Thread 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: --- 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

[Bug fortran/84119] New: Type parameter inquiry for PDT returns array instead of scalar

2018-01-29 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/84120] New: Syntax for used for PDT constructors is incorrect

2018-01-29 Thread 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: --- 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

[Bug fortran/84218] ICE in free_expr0, at fortran/expr.c:451

2018-02-07 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84218 Neil Carlson changed: What|Removed |Added CC||neil.n.carlson at gmail dot com

[Bug fortran/84122] Incorrect statement sequence in PDT definition

2018-02-03 Thread 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

[Bug testsuite/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

2018-02-14 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381 Neil Carlson changed: What|Removed |Added CC||neil.n.carlson at gmail dot com

[Bug fortran/82996] ICE and segfault with derived type finalization

2018-02-17 Thread 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

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

2018-02-18 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84432 Neil Carlson changed: What|Removed |Added CC||neil.n.carlson at gmail dot com

[Bug fortran/84543] New: undefined reference to __copy_INTEGER_4_.3788

2018-02-24 Thread 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

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

2018-02-24 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

2018-02-24 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

2018-02-23 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/69563] Generic TBP incorrectly resolves to elemental

2018-02-23 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/84539] ICE and segfault with assignment to CLASS(*) array

2018-02-23 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/83118] [7/8 Regression] Bad intrinsic assignment of class(*) array component of derived type

2018-02-23 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/84539] New: ICE and segfault with assignment to CLASS(*) array

2018-02-23 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/84546] New: [7/8 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component

2018-02-24 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

2018-02-16 Thread 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.

[Bug fortran/79072] ICE with class(*) pointer function result and character value

2018-02-21 Thread 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.

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

2017-12-26 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/84546] [7/8 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component

2018-03-11 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

2018-03-02 Thread neil.n.carlson at gmail dot com
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 +++

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

2018-03-02 Thread neil.n.carlson at gmail dot com
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 +++

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

2018-03-02 Thread neil.n.carlson at gmail dot com
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

[Bug fortran/84539] ICE and segfault with assignment to CLASS(*) array

2018-08-16 Thread neil.n.carlson at gmail dot com
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