[Bug rtl-optimization/91656] [10 Regression] wrong code with -fgcse-after-reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91656 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #9 from janus at gcc dot gnu.org --- *** Bug 91671 has been marked as a duplicate of this bug. ***
[Bug fortran/91671] [10 Regression] gfortran.dg/direct_io_10.f fails at runtime with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91671 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from janus at gcc dot gnu.org --- (In reply to kargl from comment #2) > Should be fixed by r275406. Confirmed. Closing. *** This bug has been marked as a duplicate of bug 91656 ***
[Bug fortran/91671] [10 Regression] gfortran.dg/direct_io_10.f fails at runtime with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91671 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |10.0 --- Comment #1 from janus at gcc dot gnu.org --- (In reply to janus from comment #0) > This is on Ubuntu 19.04 (x86_64) and my configure line includes > "--with-arch=haswell". However, the problem does not seem to be Haswell-specific, i.e. it does not go away when removing the flag --with-arch=haswell.
[Bug fortran/91671] New: [10 Regression] gfortran.dg/direct_io_10.f fails at runtime with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91671 Bug ID: 91671 Summary: [10 Regression] gfortran.dg/direct_io_10.f fails at runtime with -O3 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: --- Running the gfortran testsuite on today's trunk I see: FAIL: gfortran.dg/direct_io_10.f -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/direct_io_10.f -O3 -g execution test In particular the test case seems to fail with -O3, but not with -O2: $ gfortran-10 -O3 direct_io_10.f $ ./a.out STOP 3 $ gfortran-10 -O2 direct_io_10.f $ ./a.out $ This is on Ubuntu 19.04 (x86_64) and my configure line includes "--with-arch=haswell".
[Bug fortran/90786] [7/8/9/10 Regression] ICE on procedure pointer assignment to function with class pointer result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||janus at gcc dot gnu.org Summary|ICE on procedure pointer|[7/8/9/10 Regression] ICE |assignment to function with |on procedure pointer |class pointer result|assignment to function with ||class pointer result --- Comment #2 from janus at gcc dot gnu.org --- Compiles here with version 5.5 and 6.5, but ICEs with 7.4, 8.3 and 9.1. Regression!
[Bug fortran/90430] [9 Regression] internal procedure target rejected in initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90430 janus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) > As in Fortran 2008, internal and dummy procedures are allowed only in > procedure pointer assignments, but not in proc-ptr initialization. The following valid program works around this restriction in the Fortran standard: implicit none interface function f() result(i) integer i end function end interface procedure(f), pointer :: g g=>h contains function h() result(j) integer j j=1 end function end I'll close this PR as invalid, if you don't mind ...
[Bug fortran/90430] [9 Regression] internal procedure target rejected in initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90430 --- Comment #3 from janus at gcc dot gnu.org --- Also I have just looked into the Fortran 2018 standard, and I don't think the situation has changed there: R1518 initial-proc-target is procedure-name C1519 (R1518) The procedure-name shall be the name of a nonelemental external or module procedure, or a specific intrinsic function listed in Table 16.2. As in Fortran 2008, internal and dummy procedures are allowed only in procedure pointer assignments, but not in proc-ptr initialization.
[Bug fortran/90430] [9 Regression] internal procedure target rejected in initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90430 --- Comment #2 from janus at gcc dot gnu.org --- I think the test case is actually invalid (at least wrt Fortran 2008), see PR 85537 comment 18 (and 20).
[Bug fortran/51961] [OOP] ALLOCATE with MOLD= rejects if source-expr has a different rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51961 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > What is allocate supposed to do if the array and the mold are not > conformable? AFAICS the mold expr is normally only used for the type, provided the shape of the allocate-object is specified explicitly, as in Tobias' example: allocate (a(2), mold=b) ! Valid - but not accepted I tend to agree that this might be valid. Then 'a' should be allocated with two elements and using the type from 'b'. However, if the shape is not specified explicitly, then it can be taken from the source-expr (therefore the rank needs to agree) as in this example: allocate (a, mold=b) ! correctly rejected? From F08 section 9.7.1.2: When an ALLOCATE statement is executed for an array with no allocate-shape-spec-list, the bounds of source-expr determine the bounds of the array. Subsequent changes to the bounds of source-expr do not affect the array bounds. I would conclude that this second case is invalid, however this is not reflected in C638, which might possibly be an oversight in Fortran 2008. AFAICS Fortran 2018 changes nothing in this regard.
[Bug fortran/84382] add command-line options -std=gnu2003 and -std=gnu2008 for gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84382 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to kargl from comment #3) > How do you propose to enforce a certain standard and allow > GNU extensions? For example, -std=gnu2003 would enforce > Fortran 2003, but allow GNU extensions. The problem is that > gfortran allows several extensions that violate the > standard. The idea is that -std=gnu2003 would allow 2003 features plus GNU extensions, but reject any 2008 and 2018 features (like submodules and coarrays). > gfortran even allows extensions that aren't caught by the -std > options and are not document! That's a separate issue and discussion, not related to this PR. Ideally all extensions should be caught and documented, of course. > I think it will becomes a endless discussion on what should > and should not be covered under -std=gnu2003. I don't see that. We already have a more-or-less complete classification of what is a 2003 or 2008 feature and what is a non-std extension. My proposal would simply introduce new options corresponding to different combinations of feature classes. > What we have > now seems to be the most reasonable approach (with the > available man power to address problem). Either a user > wants GNU Fortran (ie., -std=gnu, the default behavior) or > a user wants a stricter adherence to a particular standard. I have not really thought about how to implement this PR. I assumed it would be easy to modify/extend gfc_notify_std & friends to accomomdate some new feature levels. At some point I just had the idea for this PR and I wanted to write it down for the future to think about and evaluate the idea. I haven't started an implementation because it's not high priority for me. If it's simply not needed or there is consensus that it's not worth the effort, then I'm willing to discuss and possibly close this PR, but certainly not due to someone yelling WTF. Also I don't see what's wrong about letting it hang in bugzilla until it becomes a priority/necessity for someone.
[Bug fortran/84382] add command-line options -std=gnu2003 and -std=gnu2008 for gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84382 janus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > Fortran is not C! True. Fortran is not C is not C++. The main difference wrt this PR is possibly that the latter two have a large enough user base, so that a significant amount of people actually use the options mentioned above. > WTF? Giving that questions back to you, Dominique: WTF? Which problem do you think you solve by closing PRs that have not been fixed?
[Bug fortran/41650] [Cleanup] Use gfc_expr_attr in resolve_allocate_expr/resolve_deallocate_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41650 janus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |--- --- Comment #4 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #3) > > Is this still valid? Definitely still valid. Apart from a pure cleanup, there might even be cases where 'is_abstract' is not set correctly (should be checked!). > No answer, closing as INVALID. Please leave bugs alone that you don't understand. Reopening ...
[Bug fortran/82971] ICE in gfc_find_derived_vtab, at fortran/class.c:2214 ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82971 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|NEW |RESOLVED CC||janus at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from janus at gcc dot gnu.org --- I can confirm the ICE up to version 8.2, but with current trunk I see: 5 |class(t), target :: z |1 Error: CLASS variable ‘z’ at (1) must be dummy, allocatable or pointer
[Bug fortran/71796] Link error referencing compiler generated symbol __vtab_xxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71796 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||link-failure Status|NEW |RESOLVED CC||janus at gcc dot gnu.org Known to work||7.3.0 Resolution|--- |FIXED Known to fail||6.5.0 --- Comment #6 from janus at gcc dot gnu.org --- The problem is fixed since gfortran version 7. Closing.
[Bug fortran/65359] [OOP] undefined output with array and inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65359 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|NEW |RESOLVED CC||janus at gcc dot gnu.org Known to work||8.2.0 Resolution|--- |FIXED Known to fail||7.3.0 --- Comment #2 from janus at gcc dot gnu.org --- With 8.2.0 and trunk I get the correct output 1st: -100-100-200-200 2nd: -100-100-200-200 3rd: 91 92 93 94 4th: 91 92 93 94 without any valgrind errors. Apparently this has been fixed.
[Bug fortran/29670] [meta-bug] fortran interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29670 Bug 29670 depends on bug 62176, which changed state. Bug 62176 Summary: [OOP] Inconsistent resolution of GENERIC interface https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62176 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID
[Bug fortran/62176] [OOP] Inconsistent resolution of GENERIC interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62176 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||janus at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > Reduced test > [...] > > The code compiles if the lines > > generic :: lle => string_less_equal_char, & > char_less_equal_string > > are commented. I cannot see how 'string_less_equal_char' and > 'char_less_equal_string' are ambiguous for 'lle', but not for operator '<='. Well, that's simply due to the different invocation syntax for both cases. 1) For the type-bound generic 'lle', the call looks like this: str%lle(ch) This matches both specific TBPs (which only differ in the position of the PASS argument), therefore they are ambiguous in this context. 2) The operator '<=' is invoked by one of the two forms: str <= ch ch <= str Here both specifics can be distinguished, so they are not ambiguous. In summary, gfortran's behavior is perfectly fine. This is a non-bug.
[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid --- Comment #14 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #13) > > FYI : On my environment it's not possible to produce an ICE with gcc-9 > > and several tested combinations of options / all tested configurations. Confirmed, the ICE is gone since gfortran 6. > > $ gfortran-9-20181021 -c pr52994.f90 > > pr52994.f90:43:29: > > > >43 | a%left_halo(psi%arr) = -666 > > | 1 > > Error: Different types in pointer assignment at (1); attempted assignment > > of REAL(4) to INTEGER(4) > > Note that I am surprised by the order of REAL(4) and INTEGER(4): AFAICT > a%left_halo(psi%arr) is real and -666 an integer, isn't it? The bigger problem is that the mentioned statement is not actually a pointer assignment. left_halo returns a pointer, but the assignment concerns the target of that pointer, not the pointer itself. When changing to a real value, I get: 32 | a%left_halo(arr) = -666. | 1 Error: Different ranks in pointer assignment at (1) Also this error is bogus. The assignment is valid AFAICS.
[Bug fortran/89866] [8 Regression] [F08] wrong-code problem with POINTER, INTENT(IN) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89866 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-28 CC||janus at gcc dot gnu.org Known to work||5.5.0, 6.5.0, 7.3.0, 9.0 Blocks||39627 Summary|POINTER |[8 Regression] [F08] ||wrong-code problem with ||POINTER, INTENT(IN) ||argument Ever confirmed|0 |1 Known to fail||8.2.0 --- Comment #2 from janus at gcc dot gnu.org --- I can confirm this problem. Reduced test case: PROGRAM testfortran2 IMPLICIT NONE INTEGER, DIMENSION(10), TARGET :: i4array i4array = (/ 1,2,3,4,5,6,7,8,9,10 /) call InRef(i4array) CONTAINS subroutine InRef(v) INTEGER, DIMENSION(:), POINTER, INTENT(in) :: v INTEGER :: i DO i=1, SIZE(v,1) WRITE(*,*) v(i) END DO END subroutine END This gives the correct output with all gfortran versions I tried (including trunk and 7.3), except 8.2, which prints: 1 1 1 1 1 1 1 1 1 1 Note that the test case is invalid in Fortran 2003: 8 | call InRef(i4array) | 1 Error: Fortran 2008: Non-pointer actual argument at (1) to pointer dummy ‘v’ Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39627 [Bug 39627] [meta-bug] Fortran 2008 support
[Bug fortran/85537] [F08] Invalid memory reference at runtime when calling subroutine through procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #23 from janus at gcc dot gnu.org --- Fixed on trunk with r269980. Closing. Thanks for the report!
[Bug fortran/39627] [meta-bug] Fortran 2008 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39627 Bug 39627 depends on bug 85537, which changed state. Bug 85537 Summary: [F08] Invalid memory reference at runtime when calling subroutine through procedure pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/85537] [F08] Invalid memory reference at runtime when calling subroutine through procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537 --- Comment #22 from janus at gcc dot gnu.org --- Author: janus Date: Wed Mar 27 22:40:22 2019 New Revision: 269980 URL: https://gcc.gnu.org/viewcvs?rev=269980=gcc=rev Log: fix PR 85537 2019-03-27 Janus Weil PR fortran/85537 * expr.c (gfc_check_assign_symbol): Reject internal and dummy procedures in procedure pointer initialization. 2019-03-27 Janus Weil PR fortran/85537 * gfortran.dg/dummy_procedure_11.f90: Fix test case. * gfortran.dg/pointer_init_11.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/pointer_init_11.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dummy_procedure_11.f90
[Bug fortran/78377] [cleanup] gfc_get_tbp_symtree vs. gfc_get_sym_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78377 --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > This kind of PRs is a nightmare when sorting the bug list. What do you mean by "this kind of PR"? And what is your problem with it? Do you have a better idea on how to track such issues?
[Bug fortran/85537] [F08] Invalid memory reference at runtime when calling subroutine through procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #21 from janus at gcc dot gnu.org --- Another related test case with a dummy procedure in a proc-ptr init, which currently ICEs, but should be rejected: module m implicit none contains subroutine foo(dbar) interface subroutine dbar() end subroutine end interface procedure(dbar), pointer :: bar_ptr => dbar call bar_ptr() end subroutine end module program main use m implicit none call foo(bar_impl) contains subroutine bar_impl() integer :: a = 0 write (*,*) "foo" a = a + 1 end subroutine end program
[Bug fortran/85537] [F08] Invalid memory reference at runtime when calling subroutine through procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537 --- Comment #20 from janus at gcc dot gnu.org --- (In reply to janus from comment #18) > C1220(R1217) The procedure-name shall be the name of a nonelemental external > or module procedure, or a specific intrinsic function listed in 13.6 and not > marked with a bullet (•). > > Note that this does not list internal procedures. In contrast to the corresponding restriction for procedure pointer assignments: C729 (R740) A procedure-name shall be the name of an internal, module, or dummy procedure, a procedure pointer, an external procedure that is accessed by use or host association and is referenced in the scoping unit as a procedure or that has the EXTERNAL attribute, or a specific intrinsic function listed in 13.6 and not marked with a bullet (•).
[Bug fortran/85537] [F08] Invalid memory reference at runtime when calling subroutine through procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537 janus at gcc dot gnu.org changed: What|Removed |Added Keywords|wrong-code |accepts-invalid Status|NEW |ASSIGNED Known to work|6.4.0 | Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org Target Milestone|7.5 |9.0 Known to fail||5.5.0, 6.5.0 --- Comment #19 from janus at gcc dot gnu.org --- I'll take care of fixing this.
[Bug fortran/85537] [F08] Invalid memory reference at runtime when calling subroutine through procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537 --- Comment #18 from janus at gcc dot gnu.org --- (In reply to Richard Biener from comment #13) > As said, the testcase is invalid if it needs SAVE since that prolongs > lifetime of the static chain over the duration of the contained function. I agree. Looking into Fortran 2008, one finds: R1217 initial-proc-target is procedure-name and C1220(R1217) The procedure-name shall be the name of a nonelemental external or module procedure, or a specific intrinsic function listed in 13.6 and not marked with a bullet (•). Note that this does not list internal procedures.
[Bug fortran/85537] [F08] Invalid memory reference at runtime when calling subroutine through procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537 --- Comment #17 from janus at gcc dot gnu.org --- (In reply to Tiziano Müller from comment #16) > can confirm, changing the reproducer to > > procedure(ibar), pointer :: bar_ptr => null() > bar_ptr => bar_impl > > makes it generate valid code Also this is only allowed since Fortran 2008: bar_ptr => bar_impl 1 Error: Fortran 2008: Internal procedure ‘bar_impl’ is invalid in procedure pointer assignment at (1)
[Bug fortran/85537] Invalid memory reference at runtime when calling subroutine through procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537 --- Comment #15 from janus at gcc dot gnu.org --- (In reply to Richard Biener from comment #13) > And the FE indeed accepts > > procedure(ibar), pointer, save :: bar_ptr => bar_impl > > but it should probably reject that. Indeed this is only valid since Fortran 2008: $ gfortran c0.f90 -std=f2003 c0.f90:12:53: 12 | procedure(ibar), pointer :: bar_ptr => bar_impl | 1 Error: Fortran 2008: non-NULL pointer initialization at (1)
[Bug fortran/71861] [7/8/9 Regression] [F03] ICE in write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from janus at gcc dot gnu.org --- Fixed on trunk and the 7 and 8 branches. Closing.
[Bug fortran/71861] [7/8/9 Regression] [F03] ICE in write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861 --- Comment #12 from janus at gcc dot gnu.org --- Author: janus Date: Mon Mar 25 19:58:04 2019 New Revision: 269922 URL: https://gcc.gnu.org/viewcvs?rev=269922=gcc=rev Log: fix PR 71861 2019-03-25 Janus Weil PR fortran/71861 * symbol.c (check_conflict): ABSTRACT attribute conflicts with INTRINSIC attribute. 2019-03-25 Janus Weil PR fortran/71861 * gfortran.dg/interface_abstract_5.f90: New test case. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/interface_abstract_5.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/symbol.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/71861] [7/8/9 Regression] [F03] ICE in write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861 --- Comment #11 from janus at gcc dot gnu.org --- Author: janus Date: Sun Mar 24 18:08:10 2019 New Revision: 269898 URL: https://gcc.gnu.org/viewcvs?rev=269898=gcc=rev Log: fix PR 71861 2019-03-24 Janus Weil PR fortran/71861 * symbol.c (check_conflict): ABSTRACT attribute conflicts with INTRINSIC attribute. 2019-03-24 Janus Weil PR fortran/71861 * gfortran.dg/interface_abstract_5.f90: New test case. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/interface_abstract_5.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/symbol.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/71861] [7/8/9 Regression] [F03] ICE in write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861 --- Comment #10 from janus at gcc dot gnu.org --- Author: janus Date: Wed Mar 20 21:32:23 2019 New Revision: 269827 URL: https://gcc.gnu.org/viewcvs?rev=269827=gcc=rev Log: fix PR 71861 2019-03-20 Janus Weil PR fortran/71861 * symbol.c (check_conflict): ABSTRACT attribute conflicts with INTRINSIC attribute. 2019-03-20 Janus Weil PR fortran/71861 * gfortran.dg/interface_abstract_5.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/interface_abstract_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/89601] [8 Regression] [PDT] ICE: Segmentation fault (in resolve_component)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89601 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #6) > Is this fixed or is there any plan to back port r269658? Fixed on trunk only up to now. I don't think it's worth backporting. Closing this PR as fixed.
[Bug fortran/82173] [meta-bug] Parameterized derived type errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 Bug 82173 depends on bug 89601, which changed state. Bug 89601 Summary: [8 Regression] [PDT] ICE: Segmentation fault (in resolve_component) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89601 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/71861] [7/8/9 Regression] [F03] ICE in write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861 janus at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #9 from janus at gcc dot gnu.org --- (In reply to janus from comment #8) > I'm about to regtest this ... No failures observed.
[Bug fortran/71861] [7/8/9 Regression] [F03] ICE in write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #8 from janus at gcc dot gnu.org --- (In reply to kargl from comment #7) > Does Note 15.2 in F2018 apply? > >An interface body cannot be used to describe the interface of an >internal procedure, a module procedure that is not a separate module >procedure, or an intrinsic procedure because the interfaces of such >procedures are already explicit. However, the name of a procedure >can appear in a PROCEDURE statement in an interface block (15.4.3.2). Probably yes. In any case, the test cases are rejected with an INTERFACE that is not ABSTRACT: Error: EXTERNAL attribute conflicts with INTRINSIC attribute at (1) With an ABSTRACT INTERFACE, they can be rejected via: diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c index c342d62ead1..ec753229a98 100644 --- a/gcc/fortran/symbol.c +++ b/gcc/fortran/symbol.c @@ -557,6 +557,7 @@ check_conflict (symbol_attribute *attr, const char *name, locus *where) conf (external, intrinsic); conf (entry, intrinsic); + conf (abstract, intrinsic); if ((attr->if_source == IFSRC_DECL && !attr->procedure) || attr->contained) conf (external, subroutine); I'm about to regtest this ...
[Bug fortran/89751] [PDT] ICE: Segmentation fault (in resolve_component)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89751
janus at gcc dot gnu.org changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=89707
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> The test compiles with the following patch
>
> --- ../_clean/gcc/fortran/resolve.c 2019-03-18 09:41:55.0 +0100
> +++ gcc/fortran/resolve.c 2019-03-18 11:37:56.0 +0100
> @@ -13973,7 +13976,7 @@ resolve_component (gfc_component *c, gfc
> }
>
>/* Procedure pointer components: Check PASS arg. */
> - if (c->attr.proc_pointer && !c->tb->nopass && c->tb->pass_arg_num == 0
> + if (c->attr.proc_pointer && c->tb && !c->tb->nopass &&
> c->tb->pass_arg_num == 0
>&& !sym->attr.vtype)
> {
>gfc_symbol* me_arg;
I don't think this is a particularly good idea. One should rather make sure
that the tb component is present, e.g. via:
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 749faf9fabe..86beb2c6f2f 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -3737,6 +3737,7 @@ gfc_get_pdt_instance (gfc_actual_arglist *param_list,
gfc_symbol **sym,
c2->ts = c1->ts;
c2->attr = c1->attr;
+ c2->tb = c1->tb;
/* The order of declaration of the type_specs might not be the
same as that of the components. */
However this runs into a different ICE :(
> However I have no idea if the test is valid or not.
I would say it is valid (at least I don't see why it wouldn't be).
This is very much related to PR 89707, almost a duplicate.
[Bug fortran/89707] New: [F03] PDT with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89707 Bug ID: 89707 Summary: [F03] PDT with procedure pointer component Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: --- Follow-up to PR 89601 (essentially the same ICE, but this time on valid code): program pdt_with_ppc type :: q (k) integer, kind :: k = 4 procedure (real(kind=k)), pointer, nopass :: p end type type (q) :: x end Current trunk ICEs like this: f951: internal compiler error: Segmentation fault 0xc9c0af crash_signal /home/janus/github/gcc/trunk/gcc/toplev.c:326 0x6994f3 resolve_component /home/janus/github/gcc/trunk/gcc/fortran/resolve.c:13965 0x699e8a resolve_fl_derived0 /home/janus/github/gcc/trunk/gcc/fortran/resolve.c:14315 0x69a4f7 resolve_fl_derived0 /home/janus/github/gcc/trunk/gcc/fortran/resolve.c:14402 0x69a4f7 resolve_fl_derived /home/janus/github/gcc/trunk/gcc/fortran/resolve.c:1 0x6968ef resolve_symbol /home/janus/github/gcc/trunk/gcc/fortran/resolve.c:14818 0x6b9822 do_traverse_symtree /home/janus/github/gcc/trunk/gcc/fortran/symbol.c:4157 0x690d54 resolve_types /home/janus/github/gcc/trunk/gcc/fortran/resolve.c:16730 0x695ddc gfc_resolve(gfc_namespace*) /home/janus/github/gcc/trunk/gcc/fortran/resolve.c:16844 0x683347 resolve_all_program_units /home/janus/github/gcc/trunk/gcc/fortran/parse.c:6073 0x683347 gfc_parse_file() /home/janus/github/gcc/trunk/gcc/fortran/parse.c:6323 0x6cf1ff gfc_be_parse_file /home/janus/github/gcc/trunk/gcc/fortran/f95-lang.c:204 Apparently c->tb is NULL.
[Bug fortran/89601] [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89601 --- Comment #5 from janus at gcc dot gnu.org --- Author: janus Date: Wed Mar 13 19:52:23 2019 New Revision: 269658 URL: https://gcc.gnu.org/viewcvs?rev=269658=gcc=rev Log: fix PR 89601 2019-03-13 Janus Weil PR fortran/89601 * decl.c (gfc_match_formal_arglist): Reject empty type parameter lists. (gfc_match_derived_decl): Mark as PDT only if type parameter list was matched successfully. 2019-03-13 Janus Weil PR fortran/89601 * gfortran.dg/pdt_16.f03: Modified to avoid follow-up errors. * gfortran.dg/pdt_30.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/pdt_30.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pdt_16.f03
[Bug fortran/89601] [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89601 --- Comment #4 from janus at gcc dot gnu.org --- On second thought, the test case is probably invalid. Fortran 2018 has: R727 derived-type-stmt is TYPE [ [ , type-attr-spec-list ] :: ] type-name [ ( type-param-name-list ) ] Note that once the parentheses after the type name appear, the type-param-name-list is non-optional (and cannot be empty, I guess). This is in contrast to e.g. a SUBROUTINE declaration, where the dummy-arg-list inside the paranthesis is optional: R1535 subroutine-stmt is [ prefix ] SUBROUTINE subroutine-name [ ( [ dummy-arg-list ] ) [ proc-language-binding-spec ] ]
[Bug fortran/89601] [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89601
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #3 from janus at gcc dot gnu.org ---
Draft patch to get rid of the ICE:
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 31c7fb6325c..ce9c1e1b090 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -10223,7 +10223,8 @@ gfc_match_derived_decl (void)
gfc_error_recovery ();
gfc_error_now ("Garbage after PARAMETERIZED TYPE declaration at %C");
}
- sym->attr.pdt_template = 1;
+ if (sym->formal)
+sym->attr.pdt_template = 1;
}
if (extended && !sym->components)
With this patch one gets a (correct) error on the test case:
$ gfortran-9 c0.f90
c0.f90:8:34:
8 | procedure (ul), pointer :: pj
| 1
Error: Argument ‘ki’ of ‘pj’ with PASS(ki) at (1) must be of the derived type
‘q8’
The test case can be cured by adding NOPASS to the PPC declaration.
[Bug fortran/89601] [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89601 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Summary|[8/9 Regression] ICE: |[8/9 Regression] [PDT] ICE: |Segmentation fault (in |Segmentation fault (in |resolve_component) |resolve_component) --- Comment #2 from janus at gcc dot gnu.org --- This is kind of a corner case: A PDT without parameters. Thus it should be treated just like an ordinary derived type.
[Bug fortran/87734] [7/8/9 Regression] ICE in is_illegal_recursion check for character len= parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87734 janus at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #12 from janus at gcc dot gnu.org --- It seems that not only the ICE, but also the "already declared as EXTERNAL-PROC" errors are caused by r258347 (which has been backported to the 6 and 7 branches, unfortunately): 2018-03-07 Steven G. Kargl PR fortran/64124 PR fortran/70409 * decl.c (gfc_match_char_spec): Try to reduce a charlen to a constant.
[Bug fortran/84504] [F08] procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from janus at gcc dot gnu.org --- Fixed on 9-trunk with r269529. Closing.
[Bug fortran/84504] [F08] procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504 --- Comment #9 from janus at gcc dot gnu.org --- Author: janus Date: Sat Mar 9 18:25:39 2019 New Revision: 269529 URL: https://gcc.gnu.org/viewcvs?rev=269529=gcc=rev Log: fix PR 84504 2019-03-09 Janus Weil PR fortran/84504 * expr.c (gfc_check_assign_symbol): Deal with procedure pointers to pointer-valued functions. 2019-03-09 Janus Weil PR fortran/84504 * gfortran.dg/pointer_init_10.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/pointer_init_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/70739] VALUE attribute interpretation in a non-interoperable procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70739 janus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||janus at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from janus at gcc dot gnu.org --- (In reply to zmi from comment #0) > I see difference between ifort and gfortran interpretation of a > non-interoperable procedure (without BIND(C)) with VALUE attribute in dummy > argument. IMHO using a non-interoperable procedure to interface with C code is basically a user error. You can do it, but the result will be highly compiler-dependent (as you saw). If you want mixed C/Fortran code to be compiler-independent, just use BIND(C)! I'll close this PR as invalid.
[Bug fortran/87838] Segmentation fault with function pointer to contained function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87838 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org --- (In reply to menospaamthereaper from comment #2) > Thank you Dominique for testing this on a Mac. So perhaps the problem is > specific to Linux. I just compiled the test case on Ubuntu 18.04 with gfortran versions 5, 6, 7, 8 and trunk. I don't see a segfault with any of these. Also gdb and valgrind don't show any kind of problem. > Additional information that might help with debugging the segmentation fault: > > 1) Compiling this code with > > gfortran -ffree-form -std=f2003 test.f > > gives the error > > test.f:12:13: > > f_ptr => f1 > 1 > Error: Fortran 2008: Internal procedure ‘f1’ is invalid in procedure pointer > assignment at (1) This error is correct. That's just not allowed in Fortran 2003. All fine. > 2) However, > > gfortran -ffree-form -std=f2008 test.f > > compiles successfully but gives a segmentation fault. > > ./a.out > > Program received signal SIGSEGV: Segmentation fault - invalid memory > reference. > > Backtrace for this error: > #0 0x7fe7aae3b31a > #1 0x7fe7aae3a503 > #2 0x7fe7aaa5ef1f > #3 0x7fffed8fe6c0 > Segmentation fault (core dumped) Could you please compile with the -g flag, in order to get a more meaningful backtrace? Alternatively try running the executable via gdb or valgrind for further debugging.
[Bug fortran/84504] [F08] procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504
--- Comment #7 from janus at gcc dot gnu.org ---
The following patch fixes the problem and shows no regressions on
x86_64-linux-gnu:
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 51552a79cde..4e95f243661 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4321,7 +4321,7 @@ gfc_check_assign_symbol (gfc_symbol *sym, gfc_component
*comp, gfc_expr *rvalue)
if (!r)
return r;
- if (pointer && rvalue->expr_type != EXPR_NULL)
+ if (pointer && rvalue->expr_type != EXPR_NULL && !proc_pointer)
{
/* F08:C461. Additional checks for pointer initialization. */
symbol_attribute attr;
[Bug fortran/84504] [F08] procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[F03] procedure pointer |[F08] procedure pointer |variables cannot be |variables cannot be |initialized with functions |initialized with functions |returning pointers |returning pointers --- Comment #6 from janus at gcc dot gnu.org --- Note that non-NULL pointer initialization is a Fortran 2008 feature (not permitted in the 2003 standard).
[Bug fortran/84504] [F03] procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|WAITING |ASSIGNED CC||janus at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org Summary|procedure pointer variables |[F03] procedure pointer |cannot be initialized with |variables cannot be |functions returning |initialized with functions |pointers|returning pointers --- Comment #5 from janus at gcc dot gnu.org --- (In reply to Sriram Swaminarayan from comment #4) > This compile error has to do with not being able to deal with a specific > return type for a function (i.e. those functions that return pointers). The > return type of a function should have no bearing on whether or not the > initialization should succeed. I agree here and I think your code is valid.
[Bug fortran/89621] [7/8/9 Regression] ICE with allocatable character and openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89621 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-09 CC||janus at gcc dot gnu.org Summary|Internal Compiler Error |[7/8/9 Regression] ICE with |with allocatable character |allocatable character and |and openmp |openmp Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- I can confirm the ICE with versions 6.5.0, 7.3.0, 8.2.0 and trunk. However, I don't see an ICE with 5.5.0, which makes this a regression.
[Bug fortran/87734] [7/8/9 Regression] ICE in is_illegal_recursion check for character len= parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87734 --- Comment #11 from janus at gcc dot gnu.org --- (In reply to janus from comment #10) > You mean r267793. Yes, that's certainly what fixed the ICE. Since it fixes a regression (ICE-on-invalid in PR 88376, ICE-on-valid here), it should ideally be backported to the 7 and 8 branches ...
[Bug fortran/87734] [7/8/9 Regression] ICE in is_illegal_recursion check for character len= parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87734 --- Comment #10 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #9) > > Would be useful to find out which commit triggered this change ... > > Revision r267783 (pr88376) seems to be a good suspect. You mean r267793. Yes, that's certainly what fixed the ICE.
[Bug fortran/87734] [7/8/9 Regression] ICE in is_illegal_recursion check for character len= parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87734 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #5) > The test case is now rejected with trunk, looks like a recent 9 regression: > > ig25@linux-p51k:/tmp> gfortran m_vstring.f90 > m_vstring.f90:24:30: > >24 | pure function vstring_length ( this ) result ( length ) > | 1 > Error: MODULE-PROC procedure at (1) is already declared as EXTERNAL-PROC > procedure In light of comment #7, I rather suspect that the ICE has been fixed on trunk, which leaves us with a (previously hidden) rejects-valid problem (6/7/8/9 regression?). Would be useful to find out which commit triggered this change ...
[Bug fortran/87734] [7/8/9 Regression] ICE in is_illegal_recursion check for character len= parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87734 --- Comment #7 from janus at gcc dot gnu.org --- Here is another variant, possibly illegal: module m_vstring implicit none public :: vstring_length character ( len = vstring_length() ) :: char_string contains pure integer function vstring_length () end function end module This is rejected by 5.5.0 via: character ( len = vstring_length() ) :: char_string ^ Error: size of variable ‘char_string’ is too large While it is rejected by 6, 7, 8 and trunk with the bogus error message: 10 | pure integer function vstring_length () | 1 Error: MODULE-PROC procedure at (1) is already declared as EXTERNAL-PROC procedure The latter error message is certainly bogus because nothing is declared as EXTERNAL at all.
[Bug fortran/87734] [7/8/9 Regression] ICE in is_illegal_recursion check for character len= parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87734 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #6 from janus at gcc dot gnu.org --- Here is a reduced variant of comment #0: module m_vstring implicit none public :: vstring_length contains subroutine vstring_cast() character ( len = vstring_length() ) :: char_string end subroutine pure integer function vstring_length () end function end module It compiles with 5.5.0, ICEs in is_illegal_recursion with 6.5.0, 7.3.0, 8.2.0 and is rejected with trunk (as mentioned in comment #5): 12 | pure integer function vstring_length () | 1 Error: MODULE-PROC procedure at (1) is already declared as EXTERNAL-PROC procedure
[Bug target/89451] [9 Regression] FAIL: gfortran.dg/pr79315.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89451 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from janus at gcc dot gnu.org --- In fact it looks like the problem is gone at r269173 (probably fixed by r269127).
[Bug target/89451] [9 Regression] FAIL: gfortran.dg/pr79315.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89451 janus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #11 from janus at gcc dot gnu.org --- (In reply to H.J. Lu from comment #10) > Does it fail without --with-arch=haswell if you add -march=haswell by hand? Yes, it does. Further investigation seems to indicate that the problem is related to AVX: Compiling the test case results in an ICE when adding -mavx or -march=sandybridge, but not with -msse4.2 or -march=westmere.
[Bug fortran/89451] [9 Regression] FAIL: gfortran.dg/pr79315.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89451 janus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #8 from janus at gcc dot gnu.org --- In fact I only see the problem when configuring with --with-arch=haswell. It goes away if I remove that flag.
[Bug fortran/89451] [9 Regression] FAIL: gfortran.dg/pr79315.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89451 --- Comment #5 from janus at gcc dot gnu.org --- Ah, yes, the ICE was obviously introduced with r269098.
[Bug fortran/89451] [9 Regression] FAIL: gfortran.dg/pr79315.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89451 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to janus from comment #1) > In any case, the ICE does not occur with gfortran 8.2.0, and I'm pretty sure > it was not present on trunk in December. More specifically, I think it must have appeared after 2019-01-08.
[Bug fortran/89451] [9 Regression] FAIL: gfortran.dg/pr79315.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89451 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||rguenther at suse dot de Known to work||8.2.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=79315 Known to fail||9.0 --- Comment #1 from janus at gcc dot gnu.org --- The test case itself is more than two years old (r245089). I haven't checked when it started failing. In any case, the ICE does not occur with gfortran 8.2.0, and I'm pretty sure it was not present on trunk in December.
[Bug fortran/89451] New: [9 Regression] FAIL: gfortran.dg/pr79315.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89451 Bug ID: 89451 Summary: [9 Regression] FAIL: gfortran.dg/pr79315.f90 -O (internal compiler error) Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: --- Building today's trunk on x86_64-linux-gnu (Ubuntu 18.10), I see the following failure in the gfortran testsuite: FAIL: gfortran.dg/pr79315.f90 -O (internal compiler error) FAIL: gfortran.dg/pr79315.f90 -O (test for excess errors) The backtrace for the ICE looks like this: $ gfortran-9 pr79315.f90 -Ofast -ftree-parallelize-loops=4 during GIMPLE pass: ifcvt pr79315.f90:37:0: 37 | do i = its, ite | internal compiler error: in gimple_duplicate_bb, at tree-cfg.c:6255 0x5b4a92 gimple_duplicate_bb /home/janus/github/gcc/trunk/gcc/tree-cfg.c:6255 0x7845f2 duplicate_block(basic_block_def*, edge_def*, basic_block_def*, copy_bb_data*) /home/janus/github/gcc/trunk/gcc/cfghooks.c:1085 0x785774 copy_bbs(basic_block_def**, unsigned int, basic_block_def**, edge_def**, unsigned int, edge_def**, loop*, basic_block_def*, bool) /home/janus/github/gcc/trunk/gcc/cfghooks.c:1353 0x790d6f duplicate_loop_to_header_edge(loop*, edge_def*, unsigned int, simple_bitmap_def*, edge_def*, vec*, int) /home/janus/github/gcc/trunk/gcc/cfgloopmanip.c:1296 0xc54768 gimple_duplicate_loop_to_header_edge(loop*, edge_def*, unsigned int, simple_bitmap_def*, edge_def*, vec*, int) /home/janus/github/gcc/trunk/gcc/tree-ssa-loop-manip.c:921 0x793e1c loop_version(loop*, void*, basic_block_def**, profile_probability, profile_probability, profile_probability, profile_probability, bool) /home/janus/github/gcc/trunk/gcc/cfgloopmanip.c:1696 0xb90eb9 version_loop_for_if_conversion /home/janus/github/gcc/trunk/gcc/tree-if-conv.c:2746 0xb978a7 tree_if_conversion(loop*, vec*) /home/janus/github/gcc/trunk/gcc/tree-if-conv.c:3033 0xb98929 execute /home/janus/github/gcc/trunk/gcc/tree-if-conv.c:3150
[Bug fortran/37222] [OOP] Checks when overriding type-bound procedures are incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37222 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from janus at gcc dot gnu.org --- (In reply to Jürgen Reuter from comment #4) > As Janus commented there is just one left-over (already fixed in the past > six years?). So what is really left to do here? I don't think the left-over is actually fixed (at least the FIXME notes are still present in interface.c). In any case, further improvement in this area is rather hard and yields only little gain, so I think it's reasonable to close this ten-year-old PR that presents no concrete test case (after all, the FIXMEs are still there for future reference).
[Bug fortran/84245] [7/8/9 Regression] ICE in delete_root, at fortran/bbt.c:150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84245 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org --- (In reply to G. Steinmetz from comment #0) > Changed between 20161023 and 20161030 : I see two possible candidates (guessing for the second): * r241450 * r241630
[Bug fortran/88376] [7/8/9 Regression] ICE in is_illegal_recursion, at fortran/resolve.c:1689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88376 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org, ||kargl at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > The change of behavior occurred between revision r258235 (2018-03-04, error) > and r258362 (2018-03-08, ICE) and has been back ported to GCC6 and 7. Based on this information, I'd guess that r258347 is the culprit: 2018-03-07 Steven G. Kargl PR fortran/64124 PR fortran/70409 * decl.c (gfc_match_char_spec): Try to reduce a charlen to a constant.
[Bug fortran/86322] [9 Regression] ICE in reference_record with data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86322 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org --- I have not verified, but I'm pretty sure the regression is due to r260808: 2018-05-27 Steven G. Kargl * decl.c (match_data_constant): Fortran 2018 allows pointer initialization in a data statement.
[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from janus at gcc dot gnu.org --- Fixed with r267735. Closing.
[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047 --- Comment #8 from janus at gcc dot gnu.org --- Author: janus Date: Tue Jan 8 19:29:01 2019 New Revision: 267735 URL: https://gcc.gnu.org/viewcvs?rev=267735=gcc=rev Log: 2019-01-08 Janus Weil PR fortran/88047 * class.c (gfc_find_vtab): For polymorphic typespecs, the components of the class container may not be available (in case of invalid code). 2019-01-08 Janus Weil PR fortran/88047 * gfortran.dg/class_69.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/class_69.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #7 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #6) > Janus, could please you figure out why class_array_3.f03 is failing with > your patch? I think the problem is that for class arrays the proper array refs are only established at resolution stage, so that gfc_expr_attr does not yet work at parsing stage, leading to the ICE shown in comment #4. I see no simple way to change that. In consequence, I propose the following patch: @@ -2846,7 +2846,10 @@ gfc_find_vtab (gfc_typespec *ts) case BT_DERIVED: return gfc_find_derived_vtab (ts->u.derived); case BT_CLASS: - return gfc_find_derived_vtab (ts->u.derived->components->ts.u.derived); + if (ts->u.derived->components && ts->u.derived->components->ts.u.derived) + return gfc_find_derived_vtab (ts->u.derived->components->ts.u.derived); + else + return NULL; default: return find_intrinsic_vtab (ts); } It fixes the ICEs on comment #0 and comment #5 and regtests cleanly.
[Bug fortran/88009] [9 Regression] ICE in find_intrinsic_vtab, at fortran/class.c:2761
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88009 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from janus at gcc dot gnu.org --- Fixed with r267598. Closing.
[Bug fortran/88009] [9 Regression] ICE in find_intrinsic_vtab, at fortran/class.c:2761
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88009 --- Comment #4 from janus at gcc dot gnu.org --- Author: janus Date: Sat Jan 5 14:32:12 2019 New Revision: 267598 URL: https://gcc.gnu.org/viewcvs?rev=267598=gcc=rev Log: 2019-01-05 Janus Weil PR fortran/88009 * class.c (gfc_find_derived_vtab): Mark the _final component as artificial. (find_intrinsic_vtab): Ditto. Also add an extra check to avoid dereferencing a null pointer and adjust indentation. * resolve.c (resolve_fl_variable): Add extra check to avoid dereferencing a null pointer. Move variable declarations to local scope. (resolve_fl_procedure): Add extra check to avoid dereferencing a null pointer. * symbol.c (check_conflict): Suppress errors for artificial symbols. 2019-01-05 Janus Weil PR fortran/88009 * gfortran.dg/blockdata_10.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/blockdata_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88009] [9 Regression] ICE in find_intrinsic_vtab, at fortran/class.c:2761
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88009 --- Comment #3 from janus at gcc dot gnu.org --- In fact, after getting rid of a few ICEs, the test case also shows a new (bogus) error with trunk: Error: PRIVATE attribute not allowed in BLOCK DATA program unit at (1) This is certainly bogus, because the code contains no PRIVATE attribute at all. The error seems to concern the _final procedures, which are part of the generated vtable. Will try to get rid of this as well.
[Bug fortran/88009] [9 Regression] ICE in find_intrinsic_vtab, at fortran/class.c:2761
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88009 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > Probably r264350 (pr88009). Right, I'm to blame here. But: I have a patch :)
[Bug fortran/88393] [7/8/9 Regression] [OOP] Segfault with type-bound assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88393
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||vehre at gcc dot gnu.org
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> Looking at this range of commits, I suspect that r241885 is the culprit.
Using -fdump-tree-original to compare the dumps of versions 6 and 7 shows that
the assignment subroutine itself is identical in both, but the dump from v7
contains additional code after the call to 'ass' that is not present in v6.
With v6, the call is translated as follows:
{
struct __class_m_T_t class.7;
struct __class_m_T_t class.8;
class.7._vptr = (struct __vtype_m_T * {ref-all}) &__vtab_m_T;
class.7._data = [1].c;
class.8._vptr = (struct __vtype_m_T * {ref-all}) &__vtab_m_T;
class.8._data = [0].c;
ass (, );
}
With v7, it looks much bulkier:
{
struct __class_m_T_t class.7;
struct __class_m_T_t class.8;
struct t D.3602;
struct __class_m_T_t * D.3603;
struct __class_m_T_t D.3604;
void * restrict D.3605;
class.7._vptr = (struct __vtype_m_T * {ref-all}) &__vtab_m_T;
class.7._data = [1].c;
class.8._vptr = (struct __vtype_m_T * {ref-all}) &__vtab_m_T;
D.3602 = arr[0].c;
class.8._data =
D.3603 =
D.3604 = *D.3603;
ass (, D.3603);
D.3603->_cs_length = D.3604._cs_length;
if ((void *) D.3604.cs != 0B)
{
D.3605 = (void * restrict) __builtin_malloc (MAX_EXPR <(unsigned long)
D.3603->_cs_length, 1>);
D.3603->cs = (character(kind=1)[1:0] *) D.3605;
__builtin_memcpy (D.3603->cs, D.3604.cs, (unsigned long)
D.3603->_cs_length);
}
else
{
D.3603->cs = 0B;
}
if (D.3603->_data->cs != 0B)
{
__builtin_free ((void *) D.3603->_data->cs);
D.3603->_data->cs = 0B;
}
}
Looks like there is some copying and deallocation of the allocatable components
here. Not sure why that would be necessary ...?!?
[Bug fortran/88393] [7/8/9 Regression] [OOP] Segfault with type-bound assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88393 --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > The test compiled with r241883 + patches (2016-11-06) gives the expected > result, compiled with r241924 + patches (2016-11-07) gives a segfault at run > time. Thanks for the information. Looking at this range of commits, I suspect that r241885 is the culprit.
[Bug sanitizer/88404] ICE (tree check) with -fsanitize=thread on Fortran2003 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88404 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|[9 Regression] ICE (tree|ICE (tree check) with |check) with |-fsanitize=thread on |-fsanitize=thread on|Fortran2003 code |Fortran2003 code| --- Comment #1 from janus at gcc dot gnu.org --- Actually I think this is not a real regression. The reason why I saw it with trunk but not with any released version is merely that it disappears when using --enable-checking=release.
[Bug sanitizer/88404] New: [9 Regression] ICE (tree check) with -fsanitize=thread on Fortran2003 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88404 Bug ID: 88404 Summary: [9 Regression] ICE (tree check) with -fsanitize=thread on Fortran2003 code Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Simple test case (valid Fortran2003 code with unlimited polymorphism): program t type :: tString character(len=:), allocatable :: cs end type call test(getstr()) contains subroutine test(val) class(*), intent(in) :: val end subroutine function getstr() result(str) type(tString) :: str end function end gfortran versions 5 to 8 handle this well with -fsanitize=thread, but recent 9-trunk ICEs: during GIMPLE pass: tsan0 tsan_ice.f90:1:0: 1 | program t | internal compiler error: tree check: expected record_type or union_type or qual_union_type or array_type, have void_type in may_be_nonaddressable_p, at tree-ssa-loop-ivopts.c:2265 0x5c17c3 tree_check_failed(tree_node const*, char const*, int, char const*, ...) /home/janus/github/gcc/trunk/gcc/tree.c:9757 0xdfc6d6 tree_check4(tree_node*, char const*, int, char const*, tree_code, tree_code, tree_code, tree_code) /home/janus/github/gcc/trunk/gcc/tree.h:3218 0xdfc6d6 may_be_nonaddressable_p(tree_node*) /home/janus/github/gcc/trunk/gcc/tree-ssa-loop-ivopts.c:2265 0xcb14ea instrument_expr /home/janus/github/gcc/trunk/gcc/tsan.c:190 0xcb23dd instrument_gimple /home/janus/github/gcc/trunk/gcc/tsan.c:729 0xcb23dd instrument_memory_accesses /home/janus/github/gcc/trunk/gcc/tsan.c:802 0xcb23dd tsan_pass /home/janus/github/gcc/trunk/gcc/tsan.c:854 0xcb23dd execute /home/janus/github/gcc/trunk/gcc/tsan.c:905
[Bug fortran/88393] New: [7/8/9 Regression] [OOP] Segfault with type-bound assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88393 Bug ID: 88393 Summary: [7/8/9 Regression] [OOP] Segfault with type-bound assignment Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: --- Simple test case: module m implicit none type :: t character(len=:), allocatable :: cs contains procedure :: ass generic :: assignment(=) => ass end type contains subroutine ass(a, b) class(t), intent(inout) :: a class(t), intent(in):: b print *, "ass" end subroutine end module program p use m implicit none type :: t2 type(t) :: c end type type(t2), dimension(1:2) :: arr arr(2)%c = arr(1)%c print *, "done" end While this runs flawlessly with gfortran 6.4.0, it segfaults at runtime with 7.3.0 and above.
[Bug testsuite/88265] [9 Regression] gfortran.dg/simd-builtins-1.f90 fails when using --with-arch=...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88265 --- Comment #6 from janus at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #5) > Instead of adding -march= please add instead say -mavx2 -mno-avx512f or > whatever ISA set you want to pick, and probably also > -mprefer-vector-width=256 or what you want. I guess it might be a good idea to have different variants of the test case that check the correct vector widths for AVX, AVX2, AVX512, etc. Of course one would need to make sure that e.g. the AVX512 variant is only executed on AVX512 hardware (e.g. skylake CPU).
[Bug fortran/88265] [9 Regression] gfortran.dg/simd-builtins-1.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88265 --- Comment #2 from janus at gcc dot gnu.org --- (In reply to janus from comment #0) > Both test cases expect the assembly to contain a call to "_ZGVbN4v_sinf", > but what I see on my system is a call to "_ZGVdN8v_sinf". That was on a haswell machine. On a skylake CPU I even see: call_ZGVeN16v_sinf So apparently I get broader vector calls than expected. Note that this seems to happen only when configuring with --with-arch=... (e.g. haswell or skylake-avx512 ).
[Bug fortran/88265] [9 Regression] gfortran.dg/simd-builtins-1.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88265 janus at gcc dot gnu.org changed: What|Removed |Added CC||mliska at suse dot cz Target Milestone|--- |9.0 --- Comment #1 from janus at gcc dot gnu.org --- The test case was added in (In reply to janus from comment #0) > Both test cases expect the assembly to contain a call to "_ZGVbN4v_sinf", > but what I see on my system is a call to "_ZGVdN8v_sinf". Those tests were added in r266509. Martin, do you understand how this comes about?
[Bug fortran/88265] New: [9 Regression] gfortran.dg/simd-builtins-1.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88265 Bug ID: 88265 Summary: [9 Regression] gfortran.dg/simd-builtins-1.f90 fails Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: --- When regtesting the current trunk on x86_64-linux-gnu, I see the following failures: FAIL: gfortran.dg/simd-builtins-1.f90 -O scan-assembler call.*_ZGVbN4v_sinf FAIL: gfortran.dg/simd-builtins-6.f90 -O scan-assembler call.*_ZGVbN4v_sinf Both test cases expect the assembly to contain a call to "_ZGVbN4v_sinf", but what I see on my system is a call to "_ZGVdN8v_sinf".
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #33 from janus at gcc dot gnu.org --- (In reply to janus from comment #30) > I have verified that the problem goes away when using the following as > version: > GNU assembler (GNU Binutils) 2.31.51.20181124 Same ǵoes for the 2.30 branch as of today. (I hope there will be a 2.30.1 release in the near future.) According to comment 22, binutils 2.29 also seems to work well.
[Bug target/86831] three failures in gfortran.fortran-torture with "-Ofast -march=native" on skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86831 --- Comment #10 from janus at gcc dot gnu.org --- (In reply to janus from comment #5) > However, in-pack.f90 is the only one that is made to fail by the combination > of -Ofast and -march=skylake-avx512. I think it's the same problem as PR > 86735 (at least it behaves in the same way). Indeed that problem goes away when gfortran is configured to use GNU assembler (GNU Binutils) 2.31.51.20181124 (as opposed to 2.30, with which it fails). That means it's indeed a duplicate of PR 86735 (and caused by a binutils bug). > Here is a reduction that shows the failure: Maybe it makes sense to add this (or the test case from PR 86735) to the testsuite? Although it is not caused by a bug in gcc itself, it would still be useful to detect if gcc is configured to use a problematic binutils version, I guess. (Note that only the skylake-avx512 architecture is affected.)
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #30 from janus at gcc dot gnu.org --- I have verified that the problem goes away when using the following as version: GNU assembler (GNU Binutils) 2.31.51.20181124
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #27 from janus at gcc dot gnu.org --- Created attachment 45086 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45086=edit object file
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #26 from janus at gcc dot gnu.org --- (In reply to janus from comment #25) > Created attachment 45085 [details] > assembler output In fact this seems to be identical to Jakub's assembly (except for filenames and versions strings), but while it works for him, it fails for me.
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #25 from janus at gcc dot gnu.org --- Created attachment 45085 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45085=edit assembler output assembler output obtained from comment 0 via "gfortran-9 c0.f90 -march=skylake-avx512 -Ofast -S", exhibiting wrong results
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #21 from janus at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #20) > Tried again, this time on real hw (i9-7960X) and still can't reproduce, Thanks for the data point, Jakub. Could you please share your kernel and glibc version? H.J.'s comment 15 sounds like the kernel version might make a difference. (Unfortunately I am stuck with kernel 4.15 right now and cannot verify this.) In any case, I still see the problem with current trunk and this config: * Ubuntu 18.04, kernel 4.15.0 * Intel(R) Core(TM) i9-7980XE CPU * glibc 2.27, binutils 2.30 My trunk build has been configured with: configure --program-suffix=-9 --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-arch=skylake-avx512 --prefix=/ --enable-languages=c,c++,fortran --disable-multilib
[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828 --- Comment #15 from janus at gcc dot gnu.org --- (In reply to H.J. Lu from comment #14) > Please try kernel 4.17.xx or above. Unfortunately I can not easily test a newer kernel on that hardware right now :(
[Bug fortran/88047] [9 Regression] ICE in gfc_find_vtab, at fortran/class.c:2843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88047 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) > The following patch restores the errors It doesn't seem to cause any regressions in the testsuite either. Feel free to commit this fix, Dominique. Side note: In principle I would have preferred something like this: diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c index f22241da60b..e40c23f2a5d 100644 --- a/gcc/fortran/match.c +++ b/gcc/fortran/match.c @@ -1374,7 +1374,8 @@ gfc_match_assignment (void) gfc_check_do_variable (lvalue->symtree); - if (lvalue->ts.type == BT_CLASS) + if (lvalue->ts.type == BT_CLASS && (rvalue->ts.type != BT_CLASS + || gfc_expr_attr (rvalue).class_ok)) gfc_find_vtab (>ts); return MATCH_YES; But that ICEs on class_array_3.f03.
[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828 --- Comment #13 from janus at gcc dot gnu.org --- (In reply to H.J. Lu from comment #12) > Which glibc are you using? Same as reported in PR86735: * Ubuntu 18.04, kernel 4.15.0 * Intel(R) Core(TM) i9-7980XE CPU * glibc 2.27, binutils 2.30
[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828 --- Comment #11 from janus at gcc dot gnu.org --- (In reply to Uroš Bizjak from comment #10) > (In reply to janus from comment #9) > > (In reply to Richard Biener from comment #8) > > > More details are needed here. > > > > What exactly do you need? > > Can you try with valgrind? I'm afraid that valgrind still does not support knl and skylake instructions, at least the latest release 3.14 does not seem to do it: $ valgrind ./a.out ==5650== Memcheck, a memory error detector ==5650== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==5650== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==5650== Command: ./a.out ==5650== vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0x5 0x3E 0x6 0x0 0x0 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==5650== valgrind: Unrecognised instruction at address 0x108a78. ==5650==at 0x108A78: knl_bug (c0.f90:15) ==5650==by 0x108A78: main (c0.f90:17) ==5650== Your program just tried to execute an instruction that Valgrind ==5650== did not recognise. There are two possible reasons for this. ==5650== 1. Your program has a bug and erroneously jumped to a non-code ==5650==location. If you are running Memcheck and you just saw a ==5650==warning about a bad jump, it's probably your program's fault. ==5650== 2. The instruction is legitimate but Valgrind doesn't handle it, ==5650==i.e. it's Valgrind's fault. If you think this is the case or ==5650==you are not sure, please let us know and we'll try to fix it. ==5650== Either way, Valgrind will now raise a SIGILL signal which will ==5650== probably kill your program. Program received signal SIGILL: Illegal instruction. Backtrace for this error: #0 0x4e582da in ??? #1 0x4e57503 in ??? #2 0x525af1f in ??? #3 0x108a78 in ??? #4 0x523db96 in ??? #5 0x108bc9 in ??? #6 0x in ??? ==5650== ==5650== Process terminating with default action of signal 4 (SIGILL) ==5650==at 0x525AE75: raise (raise.c:46) ==5650==by 0x525AF1F: ??? (in /lib/x86_64-linux-gnu/libc-2.27.so) ==5650==by 0x108A77: knl_bug (c0.f90:15) ==5650==by 0x108A77: main (c0.f90:17) ==5650== ==5650== HEAP SUMMARY: ==5650== in use at exit: 5,484 bytes in 18 blocks ==5650== total heap usage: 22 allocs, 4 frees, 13,624 bytes allocated ==5650== ==5650== LEAK SUMMARY: ==5650==definitely lost: 0 bytes in 0 blocks ==5650==indirectly lost: 0 bytes in 0 blocks ==5650== possibly lost: 0 bytes in 0 blocks ==5650==still reachable: 5,484 bytes in 18 blocks ==5650== suppressed: 0 bytes in 0 blocks ==5650== Rerun with --leak-check=full to see details of leaked memory ==5650== ==5650== For counts of detected and suppressed errors, rerun with: -v ==5650== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Illegal instruction (core dumped)
[Bug target/86828] [7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828 --- Comment #9 from janus at gcc dot gnu.org --- (In reply to Richard Biener from comment #8) > More details are needed here. What exactly do you need? $ gfortran-7 -march=knl -Ofast -g c0.f90 $ gdb ./a.out [..] (gdb) run Starting program: /home/janus/fort/gfortran_bugs/86828_knl/a.out Program received signal SIGSEGV, Segmentation fault. s (n=..., n=...) at c0.f90:26 26liKOB = Y(n%list) (gdb) bt #0 s (n=..., n=...) at c0.f90:26 #1 0x4a9b in knl_bug () at c0.f90:17 #2 main (argc=argc@entry=1, argv=0x7fffe53a) at c0.f90:17 #3 0x77626b97 in __libc_start_main (main=0x4800 , argc=1, argv=0x7fffe298, init=, fini=, rtld_fini=, stack_end=0x7fffe288) at ../csu/libc-start.c:310 #4 0x4bca in _start ()
[Bug fortran/87597] [7/8/9 Regression] wrong result with matmul inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87597 --- Comment #9 from janus at gcc dot gnu.org --- Tobias, are you going to backport the fix to the release branches? Jakub's comment 8 sounds like it might already be too late for 6.5, but it would be great to have this at least on the 7 and 8 branches!
[Bug fortran/87597] [6/7/8/9 Regression] wrong result with matmul inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87597 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-12 CC||janus at gcc dot gnu.org Known to work||5.5.0 Summary|wrong result with matmul|[6/7/8/9 Regression] wrong |inlining|result with matmul inlining Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0, 8.0.1 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed with version 6.4 and above. 5.5 and earlier seems to work.
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943
--- Comment #6 from janus at gcc dot gnu.org ---
Actually the patch is better expressed as:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index a2beb7fc90a..4710b7d2975 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -13433,8 +13433,9 @@ resolve_typebound_procedure (gfc_symtree* stree)
goto error;
}
- if (CLASS_DATA (me_arg)->ts.u.derived
- != resolve_bindings_derived)
+ if ((CLASS_DATA (me_arg)->ts.u.derived != resolve_bindings_derived) &&
+ !(resolve_bindings_derived->attr.pdt_template
+ && CLASS_DATA (me_arg)->ts.u.derived->attr.pdt_type))
{
gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of"
" the derived-type %qs", me_arg->name, proc->name,
But one still needs to make sure that the PDT template and the PDT type
actually belong to each other and enforce another condition: "All length type
parameters of the passed object dummy argument must be assumed." (as ifort puts
it)
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943
--- Comment #5 from janus at gcc dot gnu.org ---
One can get around the error with a patch like this:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index a2beb7fc90a..6b6e34c0d86 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -13433,8 +13433,9 @@ resolve_typebound_procedure (gfc_symtree* stree)
goto error;
}
- if (CLASS_DATA (me_arg)->ts.u.derived
- != resolve_bindings_derived)
+ if ((CLASS_DATA (me_arg)->ts.u.derived != resolve_bindings_derived) &&
+ !(resolve_bindings_derived->attr.pdt_template
+ && gfc_str_startswith (CLASS_DATA (me_arg)->ts.u.derived->name,
"Pdt")))
{
gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of"
" the derived-type %qs", me_arg->name, proc->name,
It is sufficient to accept the code in comment #4, but otherwise not fully
complete. With this patch, the code in comment #0 is still rejected:
29 |call b%foo()
| 1
Error: ‘foo’ at (1) is not a member of the ‘pdttypedef’ structure
