[Bug fortran/86468] [12/13/14/15 regression][Coarray] ICE verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86468 --- Comment #12 from Jürgen Reuter --- (In reply to Andre Vehreschild from comment #11) > Patch proposed: https://gcc.gnu.org/pipermail/fortran/2024-August/060882.html > Waiting for review. Hi Andre, great to see you back in action for gcc/gfortran! I am neither an expert on Coarrays (unfortunately) nor on the gimple structure of gcc, so I cannot judge whether this patch solves the ICE issue or simply shadows it. I had just reported this from a comp.lang.fortran discussion end of 2016. From my side, if the ICE is gone with the patch and no other test breaks, it seems good to me. Hopefully somebody more knowledgeable can comment on the issue. Cheers, JRR (Juergen)
[Bug fortran/115983] ICE on valid code in gfc_is_nodesc_array, at fortran/trans-types.cc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115983 --- Comment #3 from Jürgen Reuter --- Oops, sorry, I had to hurry and closed the laptop. I didn't think that the issue got already submitted. Here is the reproducer. gfortran -c state_matrices.f90 state_matrices.f90:76:23: 76 | t2 = t3_get_t2 (qn) | 1 internal compiler error: in gfc_is_nodesc_array, at fortran/trans-types.cc:1408 module m implicit none private type, abstract :: t1_t private contains generic :: assignment(=) => assign procedure (t1_assign), deferred :: assign end type t1_t type, extends (t1_t) :: t2_t private integer :: f = 0 contains procedure :: assign => t2_assign end type t2_t type :: t3_t private type(t2_t) :: f contains procedure :: get_t2 => t3_get_t2 end type t3_t type :: s_iterator_t private integer :: depth = 0 contains generic :: get_t2 => get_t2_single procedure :: get_t2_single => s_iterator_get_t2_single generic :: extract_t2 => extract_t2_multi procedure :: extract_t2_multi => s_iterator_extract_t2_multi end type s_iterator_t abstract interface subroutine t1_assign (q, q2) import class(t1_t), intent(inout) :: q class(t1_t), intent(in) :: q2 end subroutine t1_assign end interface interface module subroutine t2_assign (q, q2) class(t2_t), intent(inout) :: q class(t1_t), intent(in) :: q2 end subroutine t2_assign end interface interface assignment(=) module procedure t3_assign end interface assignment(=) interface impure elemental module function t3_get_t2 (qn) result (t2) type(t2_t) :: t2 class(t3_t), intent(in) :: qn end function t3_get_t2 module subroutine t3_assign (t1_out, t1_in) type(t3_t), intent(out) :: t1_out type(t3_t), intent(in) :: t1_in end subroutine t3_assign end interface contains function s_iterator_get_t2_single (it, k) result (t2) class(s_iterator_t), intent(in) :: it integer, intent(in) :: k type(t2_t) :: t2 end function s_iterator_get_t2_single subroutine s_iterator_extract_t2_multi (it, t2) class(s_iterator_t), intent(in) :: it type(t2_t), dimension(:), intent(out) :: t2 type(t3_t), dimension(size(t2)) :: qn t2 = t3_get_t2 (qn) end subroutine s_iterator_extract_t2_multi end module m
[Bug fortran/115983] ICE on valid code in gfc_is_nodesc_array, at fortran/trans-types.cc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115983 --- Comment #2 from Jürgen Reuter --- Created attachment 58703 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58703&action=edit Reproducer
[Bug fortran/115983] New: ICE on valid code in gfc_is_nodesc_array, at fortran/trans-types.cc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115983 Bug ID: 115983 Summary: ICE on valid code in gfc_is_nodesc_array, at fortran/trans-types.cc: Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- The following ICE appear in gfortran 14.1. and goes back to at least gfortran 9.4. The reproducer is somne 80 lines.
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #28 from Jürgen Reuter --- Richard, unfortunately the fix (it seems it was committed to gcc git master on last Friday) did not fix our problem yet. The original test case still segfaults: Backtrace for this error: #0 0x7f36f52a3a6c in ??? #1 0x7f36f52a2b45 in ??? #2 0x7f36f4fe204f in ??? #3 0x7f36f5c9b323 in curr_ at ../../../contrib/tauola/formf.f:501 #4 0x7f36f5cabc16 in dam4pi_ at ../../../contrib/tauola/tauola.f:4106 #5 0x7f36f5cacdb6 in dph4pi_ at ../../../contrib/tauola/tauola.f:4067 #6 0x7f36f5cb1330 in dadnew_ at ../../../contrib/tauola/tauola.f:3667 #7 0x7f36f5cb167c in dexnew_ at ../../../contrib/tauola/tauola.f:3592 #8 0x7f36f5cb7a4d in dexay_ at ../../../contrib/tauola/tauola.f:525 #9 0x7f36f5cb9e3a in initdk_ at ../../../contrib/tauola/tauola_photos_ini.f:452 #10 0x7f36f5aeebbc in __tauola_interface_MOD_wo_tauola_init_call at ../../../src/tauola/tauola_interface_sub.f90:903
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #27 from Jürgen Reuter --- (In reply to Jürgen Reuter from comment #26) > (In reply to Richard Biener from comment #24) > > (In reply to Jürgen Reuter from comment #23) > > > Created attachment 58486 [details] > > > Shorter reproducer > > > > > > This is a shorter reproducer, two files of a few hundred lines each. It > > > seems that the problem with the vectorization appears only if the call and > > > the double do loop are in two different files. > > > > Thanks, but see comment#21 where I already reduced a testcase. I've posted > > a fix already at > > https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655376.html > > So your reproducer doesn't segfault with the corresponding commit, it just > produces wrong code, right? Ok, forgot the -fno-inline. I really need to focus on the whole content. :(
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #26 from Jürgen Reuter --- (In reply to Richard Biener from comment #24) > (In reply to Jürgen Reuter from comment #23) > > Created attachment 58486 [details] > > Shorter reproducer > > > > This is a shorter reproducer, two files of a few hundred lines each. It > > seems that the problem with the vectorization appears only if the call and > > the double do loop are in two different files. > > Thanks, but see comment#21 where I already reduced a testcase. I've posted > a fix already at > https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655376.html So your reproducer doesn't segfault with the corresponding commit, it just produces wrong code, right?
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #25 from Jürgen Reuter --- (In reply to Richard Biener from comment #24) > (In reply to Jürgen Reuter from comment #23) > > Created attachment 58486 [details] > > Shorter reproducer > > > > This is a shorter reproducer, two files of a few hundred lines each. It > > seems that the problem with the vectorization appears only if the call and > > the double do loop are in two different files. > > Thanks, but see comment#21 where I already reduced a testcase. I've posted > a fix already at > https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655376.html Oh, yes, thanks, I should've read my emails in causal order. Thanks for the quick action. If the fix is pushed our CI will tell me Monday morning if everything works as expected again.
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #23 from Jürgen Reuter --- Created attachment 58486 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58486&action=edit Shorter reproducer This is a shorter reproducer, two files of a few hundred lines each. It seems that the problem with the vectorization appears only if the call and the double do loop are in two different files.
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #19 from Jürgen Reuter --- Created attachment 58476 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58476&action=edit First independent reproducer
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code since r15-1238-g1fe55a1794863b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #17 from Jürgen Reuter --- (In reply to Richard Biener from comment #16) > (In reply to Jürgen Reuter from comment #15) > > I fund the culprit commit in the gcc master, it is: > > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > > h=1fe55a1794863b5ad9eeca5062782834716016b2 > > by Richard Biener on the tree-optimization. Now I will try helping to get a > > smaller reproducer. > > Interesting, note the other commit had r15-1309-ge575b5c56137b1 as followup > fix already. > > The loop at contrib/tauola/formf.f:599 should be the problem, adding > > !GCC$ novector > > to it should avoid the issue (and also serve as confirmation to that). > > I wonder if you can then attach enough to be able to compile the > translation unit with the respective loop. Indeed, adding, as you suggested, !GCC$ novector before the double do-loop cures the segmentation fault. I saw the follow-up commit but apparently the daily bumps after that (e.g. from Monday morning, June 17, 0:18 am, or so, still had this issue. I try to get a shorter reproducer, but not sure when I will be able to do so.
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #15 from Jürgen Reuter --- I fund the culprit commit in the gcc master, it is: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1fe55a1794863b5ad9eeca5062782834716016b2 by Richard Biener on the tree-optimization. Now I will try helping to get a smaller reproducer.
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #14 from Jürgen Reuter --- (In reply to Jürgen Reuter from comment #13) > The daily bump in the morning of Friday, June 14, > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=028cd77db322d21312680c9a0a7c30565854f577 > shows the segmentation fault, so the culprit comment must have happened on > Thursday, June 13, my guess would be that it's one of these two: > 6 days agoRichard Biener tree-optimization/115385 - handle more gaps with > peelin... commit | commitdiff | tree > 6 days agoRichard Biener tree-optimization/114107 - avoid peeling for > gaps > in... commit | commitdiff | tree This was still fine on Thu June 13, 05:08: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=64cd70e315ed2cf0653cfdde96ae80c3f90a07f4
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #13 from Jürgen Reuter --- The daily bump in the morning of Friday, June 14, https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=028cd77db322d21312680c9a0a7c30565854f577 shows the segmentation fault, so the culprit comment must have happened on Thursday, June 13, my guess would be that it's one of these two: 6 days ago Richard Biener tree-optimization/115385 - handle more gaps with peelin... commit | commitdiff | tree 6 days ago Richard Biener tree-optimization/114107 - avoid peeling for gaps in... commit | commitdiff | tree
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #11 from Jürgen Reuter --- (In reply to Jürgen Reuter from comment #10) > (In reply to Jürgen Reuter from comment #9) > > Also at the daily bump shortly after midnight morning of June 11, > > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > > h=097bc0aebaed58c11c738ea61da723cca950e5b1 > > the reproducer still runs fine. > > Next landmark: > also the daily bump after Tuesday June 11 in the morning of June 12, > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=7fa4b335b1ae6824893528eae56fb01ec15b6bc5 > is still fine. Also the daily bump shortly after midnight of June 13 including all changes from Wednesday, June 12, https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=158ce8ade0a98443b8fc05cbdbed5c49ee8a13b7 is still fine.
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #10 from Jürgen Reuter --- (In reply to Jürgen Reuter from comment #9) > Also at the daily bump shortly after midnight morning of June 11, > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=097bc0aebaed58c11c738ea61da723cca950e5b1 > the reproducer still runs fine. Next landmark: also the daily bump after Tuesday June 11 in the morning of June 12, https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7fa4b335b1ae6824893528eae56fb01ec15b6bc5 is still fine.
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #9 from Jürgen Reuter --- Also at the daily bump shortly after midnight morning of June 11, https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=097bc0aebaed58c11c738ea61da723cca950e5b1 the reproducer still runs fine.
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #8 from Jürgen Reuter --- (In reply to Jürgen Reuter from comment #6) > (In reply to kargls from comment #5) > > (In reply to Jürgen Reuter from comment #4) > > > Created attachment 58462 [details] > > > Input file that triggers the test case with segmentation fault > > > > > > This test case needs Whizard 3.1.4 to be downloaded here, > > > http://whizard.hepforge.org/whizard-3.1.4.tar.gz > > > I avoided the need for OCaml being present, just do ./configure, make, > > > make > > > install. This will create a binary whizard, and then execute > > > whizard tauola_1.sin as attached. > > > > ./configure > > ... > > checking for OCaml version 408000... test: -ge: unexpected operator > > < 4.08.0 > > configure: error: * > > configure: error: found version , too old! > > configure: error: * > > Just do configure with --disable-ocaml. Out of curiosity, what OCaml version is on your system?
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #7 from Jürgen Reuter --- First data point: after the commit from Uros, https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8bb6b2f4ae19c3aab7d7a5e5c8f5965f89d90e01 at Sun, 9 Jun 2024 10:09:13 all was still fine.
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #6 from Jürgen Reuter --- (In reply to kargls from comment #5) > (In reply to Jürgen Reuter from comment #4) > > Created attachment 58462 [details] > > Input file that triggers the test case with segmentation fault > > > > This test case needs Whizard 3.1.4 to be downloaded here, > > http://whizard.hepforge.org/whizard-3.1.4.tar.gz > > I avoided the need for OCaml being present, just do ./configure, make, make > > install. This will create a binary whizard, and then execute > > whizard tauola_1.sin as attached. > > ./configure > ... > checking for OCaml version 408000... test: -ge: unexpected operator > < 4.08.0 > configure: error: * > configure: error: found version , too old! > configure: error: * Just do configure with --disable-ocaml.
[Bug middle-end/115528] [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #4 from Jürgen Reuter --- Created attachment 58462 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58462&action=edit Input file that triggers the test case with segmentation fault This test case needs Whizard 3.1.4 to be downloaded here, http://whizard.hepforge.org/whizard-3.1.4.tar.gz I avoided the need for OCaml being present, just do ./configure, make, make install. This will create a binary whizard, and then execute whizard tauola_1.sin as attached.
[Bug fortran/115528] [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 --- Comment #2 from Jürgen Reuter --- (In reply to Andrew Pinski from comment #1) > what options are you using to compile the source? > Does it work at -O0? You are right: the problem doesn't appear for -O0. Our defaults are the libtool defaults of -g -O2.
[Bug fortran/115528] New: [15 regression] segmentation fault in legacy F77 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115528 Bug ID: 115528 Summary: [15 regression] segmentation fault in legacy F77 code Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Some changes in gcc/gfortran between ca. June 10 and June 17, 2024 now leeds to segmenation faults in our application (Whizard v3.1.4, c.f. http://whizard.hepforge.org/whizard-3.1.4.tar.gz). Note that this appears in our functional testsuite which necessitates the OCaml compiler. The segmentation fault appears e.g. as #0 0x7f827594f51f in ??? at ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 #1 0x7f827a3cfd0a in curr_ at ../../../contrib/tauola/formf.f:599 #2 0x7f827a3e0e16 in dam4pi_ at ../../../contrib/tauola/tauola.f:4106 #3 0x7f827a3e1fb6 in dph4pi_ at ../../../contrib/tauola/tauola.f:4067 #4 0x7f827a3e6510 in dadnew_ at ../../../contrib/tauola/tauola.f:3667 #5 0x7f827a3e685c in dexnew_ at ../../../contrib/tauola/tauola.f:3592 #6 0x7f827a3ecc2d in dexay_ at ../../../contrib/tauola/tauola.f:525 #7 0x7f827a3eeffa in initdk_ at ../../../contrib/tauola/tauola_photos_ini.f:452 I need to come up with a workable reproducer, but that's not easy, and my time nowadays is awfully limited. :(
[Bug fortran/114475] [14.0 Regression] Regression with iso_c_binding and submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475 --- Comment #1 from Jürgen Reuter --- I suspect this commit here, https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=44c0398e65347def316700911a51ca8b4ec0a411 but not totally certain.
[Bug fortran/114475] New: [14.0 Regression] Regression with iso_c_binding and submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475 Bug ID: 114475 Summary: [14.0 Regression] Regression with iso_c_binding and submodules Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Between ca. March 18 and March 25, a regression has been introduced into the gfortran 14.0.1 code, which makes the following valid code fail to compile, cf. below: gfortran -c t1.f90 t1.f90:28:13: 28 | submodule (t1) t1_s | 1 Error: Variable ‘n_external’ cannot appear in the expression at (1) It would be cool if that could be fixed before the release of gcc 14.1 which I believe is very soon. module t1 use, intrinsic :: iso_c_binding !NODEP! implicit none private public :: t1_t integer :: N_EXTERNAL = 0 type :: t1_t contains procedure :: set_n_external => t1_set_n_external end type t1_t abstract interface subroutine ol_eval (id, pp, emitter) bind(C) import real(kind = c_double), intent(in) :: pp(5 * N_EXTERNAL) end subroutine ol_eval end interface interface module subroutine t1_set_n_external (object, n) class(t1_t), intent(inout) :: object integer, intent(in) :: n end subroutine t1_set_n_external end interface end module t1 submodule (t1) t1_s implicit none contains module subroutine t1_set_n_external (object, n) class(t1_t), intent(inout) :: object integer, intent(in) :: n N_EXTERNAL = n end subroutine t1_set_n_external end submodule t1_s
[Bug fortran/113471] [14 regression] wrong array bound check failure on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113471 --- Comment #3 from Jürgen Reuter --- (In reply to anlauf from comment #2) > The following patch fixes the reduced testcase for me, as well as the > full testcase in comment#0: > > diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc > index 26e7adaa03f..3e1a400fa33 100644 > --- a/gcc/fortran/trans-array.cc > +++ b/gcc/fortran/trans-array.cc > @@ -3600,7 +3600,9 @@ array_bound_check_elemental (gfc_se * se, gfc_ss * ss, > gfc_expr * expr) > continue; > } > > - if (ref->type == REF_ARRAY && ref->u.ar.dimen > 0) > + if (ref->type == REF_ARRAY > + && ref->u.ar.type == AR_SECTION > + && ref->u.ar.dimen > 0) > { > ar = &ref->u.ar; > for (dim = 0; dim < ar->dimen; dim++) > > Can you give it a spin? Thanks for the quick reaction, indeed with your fix, all our tests do work again when all check flags are switched on (we don't do it in our CI with gfortran, but with only with nagfor, so I just noticed it now).
[Bug fortran/113471] New: [14 regression] wrong array bound check failure on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113471 Bug ID: 113471 Summary: [14 regression] wrong array bound check failure on valid code Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Created attachment 57136 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57136&action=edit Reproducer, 154 lines Very likely in the time period between March and late fall 2023 a regression appeared with flags in the following reproducer a Fortran runtime error (invalidly, I'd say): Fortran runtime error: Index '3' of dimension 1 of array 'cc' outside of expected range (1:2) The code is here and attached, needs to be compiled with -fcheck=all or -fcheck=bounds: module cs implicit none type :: c_t integer, dimension(2) :: c1 = 0, c2 = 0 contains generic :: init => & c_init_trivial, & c_init_array, & c_init_arrays procedure, private :: c_init_trivial procedure, private :: c_init_array procedure, private :: c_init_arrays procedure :: init_col_acl => c_init_col_acl procedure :: add_offset => c_add_offset generic :: operator(.merge.) => merge_cs procedure, private :: merge_cs end type c_t contains pure subroutine c_init_trivial (col) class(c_t), intent(inout) :: col col%c1 = 0 col%c2 = 0 end subroutine c_init_trivial pure subroutine c_init_array (col, c1) class(c_t), intent(inout) :: col integer, dimension(:), intent(in) :: c1 col%c1 = pack (c1, c1 /= 0, [0,0]) col%c2 = col%c1 end subroutine c_init_array pure subroutine c_init_arrays (col, c1, c2) class(c_t), intent(inout) :: col integer, dimension(:), intent(in) :: c1, c2 if (size (c1) == size (c2)) then col%c1 = pack (c1, c1 /= 0, [0,0]) col%c2 = pack (c2, c2 /= 0, [0,0]) else if (size (c1) /= 0) then col%c1 = pack (c1, c1 /= 0, [0,0]) col%c2 = col%c1 else if (size (c2) /= 0) then col%c1 = pack (c2, c2 /= 0, [0,0]) col%c2 = col%c1 end if end subroutine c_init_arrays elemental subroutine c_init_col_acl (col, col_in, acl_in) class(c_t), intent(inout) :: col integer, intent(in) :: col_in, acl_in integer, dimension(0) :: null_array select case (col_in) case (0) select case (acl_in) case (0) call c_init_array (col, null_array) case default call c_init_array (col, [-acl_in]) end select case default select case (acl_in) case (0) call c_init_array (col, [col_in]) case default call c_init_array (col, [col_in, -acl_in]) end select end select end subroutine c_init_col_acl elemental subroutine c_add_offset (col, offset) class(c_t), intent(inout) :: col integer, intent(in) :: offset where (col%c1 /= 0) col%c1 = col%c1 + sign (offset, col%c1) where (col%c2 /= 0) col%c2 = col%c2 + sign (offset, col%c2) end subroutine c_add_offset elemental function merge_cs (col1, col2) result (col) type(c_t) :: col class(c_t), intent(in) :: col1, col2 call c_init_arrays (col, col1%c1, col2%c1) end function merge_cs function count_c_loops (col) result (count) integer :: count type(c_t), dimension(:), intent(in) :: col type(c_t), dimension(size(col)) :: cc integer :: i, n, offset, ii cc = col n = size (cc) offset = n call c_add_offset (cc, offset) count = 0 SCAN_LOOPS: do do i = 1, n if (any (cc(i)%c1 > offset)) then count = count + 1 ii = pick_new_line (cc(i)%c1, count, 1) cycle SCAN_LOOPS end if end do exit SCAN_LOOPS end do SCAN_LOOPS contains function pick_new_line (c, reset_val, sgn) result (line) integer :: line integer, dimension(:), intent(inout) :: c integer, intent(in) :: reset_val integer, intent(in) :: sgn integer :: i if (any (c == count)) then line = count else do i = 1, size (c) if (sign (1, c(i)) == sgn .and. abs (c(i)) > offset) then line = c(i) c(i) = reset_val return end if end do end if end function pick_new_line end function count_c_loops end module cs module cs_uti use cs implicit none private public :: c_1 contains subroutine c_1 (u) integer, intent(in) :: u type(c_t), dimension(4) :: col1, col2, col type(c_t), dimension(:), allocatable :: col3 type(c_t), dimension(:,:), allocatable :: col_array integer :: count, i call col1%init_col_acl ([1, 0, 2, 3], [0, 1, 3, 2]) col2 = col1 col = col1 .merge. col2 count = count_c_loo
[Bug fortran/112460] New: ICE with parameterized derived types (incorrect code, should be rejected)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112460 Bug ID: 112460 Summary: ICE with parameterized derived types (incorrect code, should be rejected) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- This is probably known (then it can be marked as duplicate), but let me report it nevertheless. The following code should be rejected, but leads to an ICE: 27 | print *, cc | 1 internal compiler error: Segmentation fault: 11 Reproducer: module color_propagator implicit none private public :: open_epsilon, closed_epsilon type :: open_epsilon integer, dimension(2) :: i end type open_epsilon type :: closed_epsilon integer, dimension(3) :: i end type closed_epsilon public :: t type :: t (n_in, n_out) integer, len :: n_in = 0, n_out = 0 logical :: is_ghost = .false. integer, dimension(n_in) :: in integer, dimension(n_out) :: out type(open_epsilon), dimension(:), allocatable :: open_eps, open_eps_bar type(closed_epsilon), dimension(:), allocatable :: closed_eps, closed_eps_bar end type t end module color_propagator program foo use color_propagator type(t(n_in=2,n_out=1)), save :: aa type(t(n_in=1,n_out=2)), save :: bb type(t), dimension(2), save :: cc cc = [aa, bb] print *, cc end program foo
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #56 from Jürgen Reuter --- What do we do now? We know the offending commit, and the commit that fixed (or "fixed") it. Closing? Do we understand what happened here, so why it went wrong and why it got fixed?
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #55 from Jürgen Reuter --- Actually, according to my testing, the last commit where the gfortran produced failing code, ishttps://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c496d15954cdeab7f9039328f94a6f62cf893d5f (Aldy Hernandez A singleton irange etc.) and the first one working again is https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1f7e5a7b91862b999aab88ee0319052aaf00f0f1 (Vladimir Makarov) that seems to have fixed it. The commit from Vladimir fixed an issue in RTL, but I am not sure what to conclude from this.
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #54 from Jürgen Reuter --- (In reply to Jürgen Reuter from comment #53) > Additional comment: the commit which fixed/"fixed" this offending commit > came between July 3 and July 10. Wildly speculating, it would be this commit maybe, https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=bdf2737cda53a83332db1a1a021653447b05a7e7 ???
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #53 from Jürgen Reuter --- Additional comment: the commit which fixed/"fixed" this offending commit came between July 3 and July 10.
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #52 from Jürgen Reuter --- (In reply to Jakub Jelinek from comment #51) > The easiest would be to bisect gcc in the suspected ranges, that way you'd > know for sure which git commit introduced the problem and which > fixed/"fixed" it. > If it is about what the compiler emits, one doesn't have to build whole gcc > from scratch each time, but can just --disable-bootstrap build it and during > bisection > whenever git is updated just ./config.status --recheck; ./config.status; > make -jN in libcpp, libiberty and gcc subdirectories and use f951/gfortran > binariers from that instead of the ones from the initial build to build your > project. This was the offending commit by Richard Sayle, on Saturday June 17: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=96c3539f2a38134cb76d8ab2e924e0dc70b2ccbd = i386: Two minor tweaks to ix86_expand_move. This patch splits out two (independent) minor changes to i386-expand.cc's ix86_expand_move from a larger patch, given that it's better to review and commit these independent pieces separately from a more complex patch. The first change is to test for CONST_WIDE_INT_P before calling ix86_convert_const_wide_int_to_broadcast. Whilst stepping through this function in gdb, I was surprised that the code was continually jumping into this function with operands that obviously weren't appropriate. The second change is to generalize the optimization for efficiently moving a TImode value to V1TImode (via V2DImode), to cover all 128-bit vector modes. Hence for the test case: typedef unsigned long uv2di __attribute__ ((__vector_size__ (16))); uv2di foo2(__int128 x) { return (uv2di)x; } we'd previously move via memory with: foo2: movq%rdi, -24(%rsp) movq%rsi, -16(%rsp) movdqa -24(%rsp), %xmm0 ret with this patch we now generate with -O2 (the same as V1TImode): foo2: movq%rdi, %xmm0 movq%rsi, %xmm1 punpcklqdq %xmm1, %xmm0 ret and with -O2 -msse4 the even better: foo2: movq%rdi, %xmm0 pinsrq $1, %rsi, %xmm0 ret The new test case is unimaginatively called sse2-v1ti-mov-2.c given the original test case just for V1TI mode was called sse2-v1ti-mov-1.c. 2023-06-17 Roger Sayle gcc/ChangeLog * config/i386/i386-expand.cc (ix86_expand_move): Check that OP1 is CONST_WIDE_INT_P before calling ix86_convert_wide_int_to_broadcast. Generalize special case for converting TImode to V1TImode to handle all 128-bit vector conversions. gcc/testsuite/ChangeLog * gcc.target/i386/sse2-v1ti-mov-2.c: New test case. === Now the question is, was this commit later reverted? Or changed in a different manner
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #50 from Jürgen Reuter --- How to proceed here? Since almost exactly a month the current gcc git master doesn't show this problem anymore, from our CI I can deduce that the version on July 3rd still failed, while the version on July 10th worked again. Since then the problem didn't show up again. My guess is that something has changed in the optimizer again (maybe because of a different problem/regression). Is it worth to find the offending commit and see when and how it was fixed (maybe even accidentally), or shall we add a gcc testsuite for regression testing, and close this issue?
[Bug bootstrap/110698] New: Bootstrap fails with [-Werror=unused-but-set-variable]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110698 Bug ID: 110698 Summary: Bootstrap fails with [-Werror=unused-but-set-variable] Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- This seems to be a very recent problem: last week (as of July 10) the bootstrap did still work with the gcc master, and now it is failing, cf. below. That should be pretty easy to find. #11 3096.5 /usr/src/gcc/gcc/expmed.cc: In function 'rtx_def* extract_bit_field_1(rtx, poly_uint64, poly_uint64, int, rtx, machine_mode, machine_mode, bool, bool, rtx_def**)': #11 3096.5 /usr/src/gcc/gcc/expmed.cc:1838:45: warning: '*(unsigned int*)((char*)&imode + offsetof(scalar_int_mode, scalar_int_mode::m_mode))' may be used uninitialized [-Wmaybe-uninitialized] #11 3096.5 1838 | rtx sub = extract_bit_field_as_subreg (mode1, op0, imode, #11 3096.5 | ^~~ #11 3096.5 1839 | bitsize, bitnum); #11 3096.5 | #11 3096.5 /usr/src/gcc/gcc/expmed.cc:1798:19: note: '*(unsigned int*)((char*)&imode + offsetof(scalar_int_mode, scalar_int_mode::m_mode))' was declared here #11 3096.5 1798 | scalar_int_mode imode; #11 3096.5 | ^ #11 3754.2 /usr/src/gcc/gcc/tree-ssa-loop-ivcanon.cc: In function 'bool try_peel_loop(loop*, edge, tree, bool, long int)': #11 3754.2 /usr/src/gcc/gcc/tree-ssa-loop-ivcanon.cc:1170:17: error: variable 'entry_count' set but not used [-Werror=unused-but-set-variable] #11 3754.2 1170 | profile_count entry_count = profile_count::zero (); #11 3754.2 | ^~~ #11 3758.5 cc1plus: all warnings being treated as errors
[Bug fortran/110691] Segmentation fault on valid F2018 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110691 --- Comment #1 from Jürgen Reuter --- Created attachment 55560 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55560&action=edit Shorter reproducer that gives bogus entries. This shorter reproducer gives (with gfortran 11.3) bogus output, and with gfortran 14.0 emty output. The expected output would be [] * Array of arrays [[h(0) h(1)]] [[h(0) h(1)] [h(-1) h(0)]]
[Bug fortran/110691] New: Segmentation fault on valid F2018 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110691 Bug ID: 110691 Summary: Segmentation fault on valid F2018 code Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Created attachment 7 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=7&action=edit Reproducer The attached code (which I believe to be valid F2018) leads to a segmentation violation with gfortran at least since version 11. (it also seg faults, probably with a different root case) in Intel oneAPI 21.9 (2023 v1), but works with nagfor. This is the backtrace of the segfault: Program received signal SIGSEGV, Segmentation fault. 0xd841 in __qn_containers_MOD_qn_array_copy () (gdb) bt #0 0xd841 in __qn_containers_MOD_qn_array_copy () #1 0xe3f3 in __qn_containers_MOD_qn_container_grow () #2 0xd2a5 in __qn_containers_MOD_qn_array_append () #3 0x55560742 in __qn_containers_uti_MOD_qn_containers_2 () #4 0x55563fb0 in __qn_containers_ut_MOD_qn_containers_test () #5 0x55563fc6 in MAIN__ () The reproducer of ca 1200 lines is attached.
[Bug fortran/110576] ICE on compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576 --- Comment #4 from Jürgen Reuter --- Created attachment 55526 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55526&action=edit Minimal reproducer, also as attachment
[Bug fortran/110576] ICE on compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576 --- Comment #3 from Jürgen Reuter --- Here is a mininal reproducer: module process_mci implicit none private public :: process_mci_entry_t type :: process_mci_entry_t integer :: i_mci = 0 integer, dimension(:), allocatable :: i_component integer :: n_it = 0 end type process_mci_entry_t end module process_mci module pcm_base use process_mci, only: process_mci_entry_t implicit none private public :: pcm_t public :: pcm_workspace_t type, abstract :: pcm_t integer :: n_components = 0 integer :: n_cores = 0 integer :: n_mci = 0 logical, dimension(:), allocatable :: component_selected logical, dimension(:), allocatable :: component_active integer, dimension(:), allocatable :: i_core integer, dimension(:), allocatable :: i_mci contains procedure(pcm_setup_mci), deferred :: setup_mci end type pcm_t type, abstract :: pcm_workspace_t logical :: bad_point = .false. end type pcm_workspace_t abstract interface subroutine pcm_setup_mci (pcm, mci_entry) import class(pcm_t), intent(inout) :: pcm type(process_mci_entry_t), & dimension(:), allocatable, intent(out) :: mci_entry end subroutine pcm_setup_mci end interface end module pcm_base module pcm use pcm_base use process_mci, only: process_mci_entry_t implicit none private public :: pcm_def_t type, extends (pcm_t) :: pcm_def_t contains procedure :: setup_mci => pcm_def_setup_mci end type pcm_def_t type, extends (pcm_workspace_t) :: pcm_def_workspace_t end type pcm_def_workspace_t interface module subroutine pcm_def_setup_mci (pcm, mci_entry) class(pcm_def_t), intent(inout) :: pcm type(process_mci_entry_t), & dimension(:), allocatable, intent(out) :: mci_entry end subroutine pcm_def_setup_mci end interface end module pcm submodule (pcm) pcm_s use process_mci, only: process_mci_entry_t implicit none contains module subroutine pcm_def_setup_mci (pcm, mci_entry) class(pcm_def_t), intent(inout) :: pcm type(process_mci_entry_t), & dimension(:), allocatable, intent(out) :: mci_entry integer :: i, i_mci allocate (mci_entry (pcm%n_mci)) end subroutine pcm_def_setup_mci end submodule pcm_s module process use pcm_base use pcm use process_mci implicit none private public :: process_t type :: process_t private class(pcm_t), allocatable :: & pcm type(process_mci_entry_t), dimension(:), allocatable :: & mci_entry contains procedure :: setup_mci => process_setup_mci end type process_t interface module subroutine process_setup_mci (process) class(process_t), intent(inout) :: process end subroutine process_setup_mci end interface end module process submodule (process) process_s implicit none contains module subroutine process_setup_mci (process) class(process_t), intent(inout) :: process integer :: i, i_mci associate (pcm => process%pcm) !!! This triggers the ICE call pcm%setup_mci (process%mci_entry) end associate end subroutine process_setup_mci end submodule process_s program main_ut implicit none end program main_ut
[Bug fortran/110576] ICE on compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576 Jürgen Reuter changed: What|Removed |Added Known to fail||11.3.0 --- Comment #2 from Jürgen Reuter --- This ICE is present since at least gfortran 11.3.
[Bug fortran/110576] ICE on compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576 --- Comment #1 from Jürgen Reuter --- Created attachment 55525 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55525&action=edit Simpler reproducer in a single file
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #49 from Jürgen Reuter --- (In reply to anlauf from comment #48) > (In reply to anlauf from comment #47) > > However, when I use -O2 together with an -march= flag, the code works. > > I've tested -march=sandybridge, -march=haswell, -march=skylake, > > -march=native. > > It FPEs without. > > And it FPEs with core2,nehalem,westmere! > > Next I tried: > > -march=sandybridge -mno-avx # FPE! > -march=sandybridge # OK. Yes, I can fully confirm your findings, also the ones from comment #47. I was looking at the commits in the period June 12-18 which could have caused this, some which seem potential candidates are: 2023-06-18 Honza PR tree-optimization/109849 2023-06-16 Jakub Jelinek PR tree-optimization/110271 * tree-ssa-math-opts.cc (math_opts_dom_walker::after_dom_children) : Ignore return value from match_arith_overflow, instead call match_uaddc_usubc only if gsi_stmt (gsi) is still stmt. (This one sounds pretty suspicious to me) 2023-06-16 Richard Biener PR tree-optimization/110269 * fold-const.cc (fold_binary_loc): Merge x != 0 folding 2023-06-13 Alexandre Oliva * range-op-float.cc (frange_nextafter): Drop inline. (frelop_early_resolve): Add static. (frange_float): Likewise 2023-06-12 Andrew MacLeod PR tree-optimization/110205 * range-op-float.cc (range_operator::fold_range): Add default FII fold routine. * range-op-mixed.h (class operator_gt): Add missing final overrides. * range-op.cc (range_op_handler::fold_range): Add RO_FII case. 2023-06-12 Andrew MacLeod * gimple-range-gori.cc (gori_compute::condexpr_adjust): Do not pass type. [...] (there is a long list of commits by Andrew on June 12) 2023-06-12 Andre Vieira PR middle-end/110142 * tree-vect-patterns.cc (vect_recog_widen_op_pattern): Don't pass subtype to vect_widened_op_tree and remove subtype parameter, also remove superfluous overloaded function definition. (vect_recog_widen_plus_pattern): Remove subtype parameter and dont pass to call to vect_recog_widen_op_pattern. (vect_recog_widen_minus_pattern): Likewise. (^^^ this one also looks suspicious to me) Any ideas which could have caused the changes?
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #46 from Jürgen Reuter --- (In reply to Jürgen Reuter from comment #45) > Created attachment 55492 [details] > Smaller stand-alone reproducer > > I will give more information in a comment, this contains 3 files and a > Makefile. This is a standalone reproducer with a total of 8k lines. It needs to be in three different files, as fusing the 2nd and 3rd file eliminates the optimizer problem of this issue, while fusing the 1st and the 2nd leeds to an ICE in trans-array.c (reported separately) and is independent of this problem here. The issue goes away with -O0, with -O1 and with -O2 -fno-tree-vectorize. I might want to find the offending commit in the week of June 12-19 in the tree-optimizer, but I don't know whether I have time to do so. Hopefully, with this smaller reproducer you can figure out what happens (and help solving it)
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #45 from Jürgen Reuter --- Created attachment 55492 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55492&action=edit Smaller stand-alone reproducer I will give more information in a comment, this contains 3 files and a Makefile.
[Bug fortran/110576] New: ICE on compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576 Bug ID: 110576 Summary: ICE on compilation Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Created attachment 55490 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55490&action=edit reproducer The following reproducer leads to an ICE which I see already with gfortran 11.3. It was intended to become a reproducer for the optimization bug in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 but this is a separate issue. I will work around this one in the reproducer for 110311. In the most recent master branch, 14.0.0, it leads to internal compiler error: Segmentation fault 0xd6eabf crash_signal ../../gcc/toplev.cc:314 0x7fe2411f151f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 0x844f2b structure_alloc_comps ../../gcc/fortran/trans-array.cc:9228 0x8459bf structure_alloc_comps ../../gcc/fortran/trans-array.cc:9167 0x847e8c gfc_deallocate_alloc_comp(gfc_symbol*, tree_node*, int, int) ../../gcc/fortran/trans-array.cc:10265 0x86980a gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.cc:6940 0x8b1952 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc/fortran/trans-stmt.cc:424 0x82f93b trans_code ../../gcc/fortran/trans.cc:2297 0x8b5c30 gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.cc:2351 0x82f887 trans_code ../../gcc/fortran/trans.cc:2325 0x85da69 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7717 0x833ec1 gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.cc:2651 0x7d42f5 translate_all_program_units ../../gcc/fortran/parse.cc:6914 0x7d42f5 gfc_parse_file() ../../gcc/fortran/parse.cc:7233 0x82c6ef gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229 Please submit a full bug report, with preprocessed source. Please include the complete backtrace with any bug report.
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #44 from Jürgen Reuter --- (In reply to anlauf from comment #43) > Mabye the fprem issue was a red herring from the beginning, pointing to a > problem in a different place. > > I recompiled each module in a loop with -O0 until the FPE went away. > > instances_sub.f90 seems the file someone wants to look at. > > Works at -O0, -O1, -Os, -O2 -fno-tree-vectorize > Fails at -O2, -O3 > > on x86_64-pc-linux-gnu. > > Jürgen: can you reduce this even more with this information? Thanks, this info is helpful. So it is the setting up of the full process via the instances module, which is in agreement with the fact that the simple test with only the RNG did not fail. I will be busy for several days, but hopefully in a week from now, I'll know more.
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #42 from Jürgen Reuter --- (In reply to Jakub Jelinek from comment #41) > > 0x04f5dc90 is pseudo NaN: > Pseudo Not a Number. The sign bit is meaningless. The 8087 and 80287 treat > this as a Signaling Not a Number. The 80387 and later treat this as an > invalid operand. > So, if that comes from some random number generator, I'd say that random > number generator should be fixed not to create the erroneous cases for > https://en.wikipedia.org/wiki/Extended_precision Hm, the example provided does not use extended precision.
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #38 from Jürgen Reuter --- At the moment unfortunately too busy to provide a smaller reproducer (which also still has a small dependency on a dynamic library), but one more info: inserting the explicit operations instead of the intrinsic mod function leads to no more NaNs with the gfortran 14, but still is numerically different from the one with previous gfortran versions: so it looks like it leads to a different random number sequence which is really disturbing.
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #29 from Jürgen Reuter --- (In reply to anlauf from comment #28) > Update: recompiling that file with 13-branch fails for me, too. > Playing with the one-line patch for pr86277 makes no difference, fortunately. > > Compiling the file with gfortran-12 seems to work ok. > > So is this really a 14-only regression, or is 13-branch already suspicious? We have gcc 13.1 in our CI, everything works fine there. I am still working on a smaller test, but have very bad connection rn.
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #26 from Jürgen Reuter --- (In reply to anlauf from comment #25) > Unfortunately, there is no main.f90, which is needed to build whizard. > Indeed, sorry, cf. below > The Makefile needs to be modified to take into account that pythia.f > needs preprocessing, e.g.: > > %.o: %.f > $(FC) $(FCFLAGS) -c $< -cpp > > Furthermore, one needs to compile serially; parallel make does not seem to > be supported. I changed the pythia.f to make the preprocessing unnecessary. > > Can you please provide the missing file? It is included here: https://www.desy.de/~reuter/downloads/repro002.tar.xz I am working on a smaller example right now.
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #24 from Jürgen Reuter --- Here is a first reproducer without the need for OCaml, unfortunately a bit too big to be uploaded, here is the link: https://www.desy.de/~reuter/downloads/repro001.tar.xz the tarball contains Fortran files that compile to two binaries, ./whizard and ./whizard_check. After compilation, perform ./whizard r1.sin to run the program. There will be NaNs generated in our RNG stream random number generator. They originate from an erroneous optimization by the gcc/gfortran tree-optimizer. This code resides in rng_stream_sub.f90, in the function mult_mod. Eliminating the intrinsic function mod and explicitly doing the calculation makes the problem go away. function mult_mod (a, b, c, m) result (v) real(default), intent(in) :: a real(default), intent(in) :: b real(default), intent(in) :: c real(default), intent(in) :: m real(default) :: v integer :: a1 real(default) :: a2 v = a * b + c if (v >= two53 .or. v <= -two53) then a1 = int (a / two17) a2 = a - a1 * two17 v = mmm_mod (a1 * b, m) v = v * two17 + a2 * b + c end if v = mmm_mod (v, m) if (v < 0.0_default) v = v + m contains elemental function mmm_mod (x1, x2) result (res) real(default), intent(in) :: x1, x2 real(default) :: res res = x1 - int(x1/x2) * x2 end function mmm_mod end function mult_mod
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #22 from Jürgen Reuter --- (In reply to anlauf from comment #21) > I forgot to mention that you need to check that the location where a symptom > is seen sometimes may not be the location of the cause. Indeed, I think you are right and the problem is elsewhere. I don't really know where to continue.
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #19 from Jürgen Reuter --- (In reply to anlauf from comment #18) > (In reply to Jürgen Reuter from comment #17) > > How would I set up such a bisection for the n git commits between June 12 to > > June 19? Unfortunately, I cannot really get a small reproducer > > I didn't mean that. I meant doing a bisection on the .o files of your code. > > But given that you have isolated a procedure, that is not necessary. > > You could try to defeat optimization by using a temporary v0 for v and > declare it as volatile. Would be interesting to see if that makes a > difference. I tried both things, or at least partially, didn't help. It also is a problem only when called in a very complicated setup in our program, in complicated setups, it works. I fear, we have to change the functionality in our program, sadly, if we are not to be stuck for all times to version of gcc < 14.
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #17 from Jürgen Reuter --- How would I set up such a bisection for the n git commits between June 12 to June 19? Unfortunately, I cannot really get a small reproducer
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #16 from Jürgen Reuter --- It seems that it is this function where the NaNs appear: function mult_mod (a, b, c, m) result (v) real(default), intent(in) :: a real(default), intent(in) :: b real(default), intent(in) :: c real(default), intent(in) :: m real(default) :: v integer :: a1 real(default) :: a2 v = a * b + c if (v >= two53 .or. v <= -two53) then a1 = int (a / two17) a2 = a - a1 * two17 v = mod (a1 * b, m) v = v * two17 + a2 * b + c end if v = mod (v, m) if (v < 0.0_default) v = v + m end function mult_mod particularly mod (v, m) gets evaluated to NaN, even if a replace it with v = mod (v0, m) to avoid potential aliasing problems. It appears only in a very complex setup, not in a 100 line program.
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #14 from Jürgen Reuter --- Did anybody manage to reproduce this? Download https://whizard.hepforge.org/downloads/?f=whizard-3.1.2.tar.gz You need OCaml as a prerequisite, though. Then configure, make, cd tests/functional_tests make check TESTS=nlo_9.run This will fail, as there are NaNs produced in our RNG module which are presumably caused by this regression in the tree-optimizer. At the moment I am deeply struggling with generating a reproducer but I don't know how tbh.
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #13 from Jürgen Reuter --- I changed the component from fortran to tree-optimization, as the problematic commit during that week was in that component. The only commit in the fortran component turns out to be unproblematic.
[Bug fortran/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #12 from Jürgen Reuter --- Any idea which commit could cause such an issue? At least I now understand that in our program the random number object gets undefined and produces NaNs.
[Bug fortran/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 Jürgen Reuter changed: What|Removed |Added Component|tree-optimization |fortran Keywords|wrong-code | Target|x86_64-linux-gnu| --- Comment #11 from Jürgen Reuter --- (In reply to manolis.tsamis from comment #6) > Hi, > > Due to the time frame mentioned (June 12-19), could you please test if the > offending commit is r14-1873-g6a2e8dcbbd4bab374b27abea375bf7a921047800 ? > This commit is now known to cause general issues, as also described in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110308. > > Thanks, > Manolis Unfortunately, this is not the problematic commit, the problem is still there when reverting this commit.
[Bug fortran/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #10 from Jürgen Reuter --- *** Bug 110326 has been marked as a duplicate of this bug. ***
[Bug fortran/110326] [14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110326 Jürgen Reuter changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jürgen Reuter --- Duplicate of 110311. *** This bug has been marked as a duplicate of bug 110311 ***
[Bug fortran/110326] [14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110326 --- Comment #2 from Jürgen Reuter --- Closed as a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
[Bug fortran/110326] [14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110326 --- Comment #1 from Jürgen Reuter --- This should be closed as a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
[Bug fortran/110311] [14 Regression] gfortran 14.0 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #9 from Jürgen Reuter --- (In reply to Andrew Pinski from comment #8) > (In reply to Jürgen Reuter from comment #7) > > The problem seems really connected to optimization, if I compile our code > > with -g -O0 or -g -O1, everything works ok. Next, I will try to check why it > > is actually failing (my guess, unconfirmed yet, is that some data structures > > are optimized away such that the program runs then on inconsistent data). > > Then I will check that specific commit. We are sure that it was introduced > > within this time frame, because we have a weekly CI that clones gcc, and > > then builds and runs our code and testsuite. That was working on the morning > > of June 12, but failed on the morning of June 19. > > Do you know if -fno-tree-vectorizer causes the issue to go away? Hi Andrew, you were right. Compiling and running with -fno-tree-vectorize does not show any issues. All our checks work without problems. Cheers, Juergen
[Bug fortran/110311] [14 Regression] gfortran 14.0 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #7 from Jürgen Reuter --- The problem seems really connected to optimization, if I compile our code with -g -O0 or -g -O1, everything works ok. Next, I will try to check why it is actually failing (my guess, unconfirmed yet, is that some data structures are optimized away such that the program runs then on inconsistent data). Then I will check that specific commit. We are sure that it was introduced within this time frame, because we have a weekly CI that clones gcc, and then builds and runs our code and testsuite. That was working on the morning of June 12, but failed on the morning of June 19.
[Bug fortran/110311] [14 Regression] gfortran 14.0 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #5 from Jürgen Reuter --- (In reply to anlauf from comment #4) > Jürgen, > > I'm afraid we need a reproducer. Or can you bisect the regression further? In principle, I could. But I just undid this commit of yours which is just one line in trans-array.cc, and that didn't solve the problem. So in the corresponding period of time between last Monday (June 12) and this week (June 19) there have not been any other commits to gcc/fortran or libgfortran, as far as I can say. So this seems to be a problem with tree-optimization, maybe.
[Bug tree-optimization/110326] New: [gcc 14.0 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110326 Bug ID: 110326 Summary: [gcc 14.0 regression] Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Hi, let me open up an issue already. I believe there was a regression introduced in gcc between June 11 and June 19, as our CI with a git-clone built gcc worked last week, and fails this week. Two out of our ca. 340 functional tests fail because they return zero results. I will try to boil this down to a smaller reproducer (fingers crossed), but if you want to play around already, checkout our code from here: https://gitlab.tp.nt.uni-siegen.de/whizard/public Note that you need noweb and OCaml besides gcc/gfortran. Do in the main directory ./build_master.sh and autoreconf, then in a build directory _build do ../configure, make -j4, make -C tests/functional_tests -j4 check. The failing tests are nlo_9.run and nlo_10.run in case you want to run them already now. There was a change in the Fortran directly, by this commit below, but this was not responsible for these failures. There was a lot of work on tree-optimization in the middle-end (?) last week, so I fear this might have caused this. At the moment I am struggling to boil down what is going on. Cheers, Juergen The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c1691509e5a8875f36c068a5ea101bf13f140948 commit r14-1795-gc1691509e5a8875f36c068a5ea101bf13f140948 Author: Harald Anlauf Date: Mon Jun 12 23:08:48 2023 +0200 Fortran: fix passing of zero-sized array arguments to procedures [PR86277] gcc/fortran/ChangeLog: PR fortran/86277 * trans-array.cc (gfc_trans_allocate_array_storage): When passing a zero-sized array with fixed (= non-dynamic) size, allocate temporary by the caller, not by the callee. gcc/testsuite/ChangeLog: PR fortran/86277 * gfortran.dg/zero_sized_14.f90: New test. * gfortran.dg/zero_sized_15.f90: New test. Co-authored-by: Mikael Morin
[Bug fortran/110311] [14 Regression] gfortran 14.0 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #3 from Jürgen Reuter --- I redid this change here: diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc index e1c75e9fe0266d760b635f0dc7869a00ce53bf48..e7c51bae052b1e0e3a60dee35484c093d28d4653 100644 (file) --- a/gcc/fortran/trans-array.cc +++ b/gcc/fortran/trans-array.cc @@ -1117,7 +1117,7 @@ gfc_trans_allocate_array_storage (stmtblock_t * pre, stmtblock_t * post, desc = info->descriptor; info->offset = gfc_index_zero_node; - if (size == NULL_TREE || integer_zerop (size)) + if (size == NULL_TREE || (dynamic && integer_zerop (size))) { /* A callee allocated array. */ gfc_conv_descriptor_data_set (pre, desc, null_pointer_node); and it seems this is not the cause of the problem :(
[Bug fortran/110311] [gfortran 14.0 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 Jürgen Reuter changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #2 from Jürgen Reuter --- Actually, it could have been this commit here: 2023-06-13 Harald Anlauf Mikael Morin PR fortran/86277 * trans-array.cc (gfc_trans_allocate_array_storage): When passing a zero-sized array with fixed (= non-dynamic) size, allocate temporary by the caller, not by the callee.
[Bug fortran/110311] [gfortran 14.0 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #1 from Jürgen Reuter --- It looks like there were no specific changes in the fortran backend or the libgfortran but a lot of optimization in the middle-end. Maybe that is responsible for this issue. Need to see what is going on.
[Bug fortran/110311] New: [gfortran 14.0 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 Bug ID: 110311 Summary: [gfortran 14.0 regression] Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Hi, let me open up an issue already. I believe there was a regression introduced in gfortran between June 11 and June 19, as our CI with a git-clone built gcc/gfortran worked last week, and fails this week. Two out of our ca. 340 functional tests fail because they return zero results. I will try to boil this down to a smaller reproducer (fingers crossed), but if you want to play around already, checkout our code from here: https://gitlab.tp.nt.uni-siegen.de/whizard/public Note that you need noweb and OCaml besides gcc/gfortran. Do in the main directory ./build_master.sh and autoreconf, then in a build directory _build do ../configure, make -j4, make -C tests/functional_tests -j4 check. The failing tests are nlo_9.run and nlo_10.run in case you want to run them already now. Cheers, Juergen
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #16 from Jürgen Reuter --- (In reply to Paul Thomas from comment #14) > For the record, the fix is: > > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc > index 1d973d12ff1..1a03e458d99 100644 > --- a/gcc/fortran/resolve.cc > +++ b/gcc/fortran/resolve.cc > @@ -11760,6 +11760,7 @@ generate_component_assignments (gfc_code **code, > gfc_namespace *ns) > of all kinds and allocatable components. */ >if (!gfc_bt_struct (comp1->ts.type) > || comp1->attr.pointer > + || comp1->attr.allocatable > || comp1->attr.proc_pointer_comp > || comp1->attr.class_pointer > || comp1->attr.proc_pointer) I confirm that all of our code compiles again with this fix, and all our tests pass. Thanks for the quick action, Paul, and also for the stamina to tackle the finalization!
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #10 from Jürgen Reuter --- (In reply to Tobias Burnus from comment #8) > The debugger shows for the example in comment 4 for the line > >69 | history_new(1:s) = res_set%history(1:s) > > the following expression: > > (gdb) p gfc_debug_expr(expr) > t3_set_expand:history_new(1:__convert_i4_i8[[((t3_set_expand:s))]]) % > resonances(FULL) > > That's F03:C614 - or in F2018: > > C919 (R911) There shall not be more than one part-ref with nonzero rank. A > part-name to the right of a part-ref with nonzero rank shall not have the > ALLOCATABLE or POINTER attribute. > > For the 'expr' shown in the debugger, that's violated as 'resonances' is > allocatable. > > > The 'expr' shown above is generated via >generate_component_assignments -> gfc_resolve_expr > -> resolve_variable -> gfc_resolve_ref > where generate_component_assignments's gfc_debug_code(*code) is > ASSIGN > t3_set_expand:history_new(1:__convert_i4_i8[[((t3_set_expand:s))]]) > t3_set_expand:res_set % history(1:__convert_i4_i8[[((t3_set_expand:s))]]) > which matches the user code and looks fine. > > (BTW: We should also check whether there is now an issue with generating > redundant (re)allocate on assignment code in trans*.cc.) Thanks for checking, Tobias. Are you saying that the code violates the standard, or the code generation after parsing by gcc/gfortran has generated code violating the standard?
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #9 from Jürgen Reuter --- (In reply to Jürgen Reuter from comment #4) > > module subroutine t3_set_expand (res_set) > class(t3_set_t), intent(inout) :: res_set > type(t3_t), dimension(:), allocatable :: history_new > integer :: s > s = size (res_set%history) > allocate (history_new (2 * s)) > history_new(1:s) = res_set%history(1:s) > call move_alloc (history_new, res_set%history) > end subroutine t3_set_expand > > end module resonances Actually, the 'module subroutine' here needs to be just 'subroutine'. gfortran accepts this, nagfor doesn't.
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #7 from Jürgen Reuter --- It looks like it is NOT Harald's and Tobias' commit, https://github.com/gcc-mirror/gcc/commit/901edd99b44976b3c2b13a7d525d9e315540186a I reverted that one, and still get the error.
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #6 from Jürgen Reuter --- Actually could be also this commit here: commit 901edd99b44976b3c2b13a7d525d9e315540186a Author: Harald Anlauf Date: Tue Mar 14 20:23:06 2023 +0100 Fortran: rank checking with explicit-/assumed-size arrays and CLASS [PR58331] gcc/fortran/ChangeLog: PR fortran/58331 * interface.cc (compare_parameter): Adjust check of array dummy arguments to handle the case of CLASS variables. gcc/testsuite/ChangeLog: PR fortran/58331 * gfortran.dg/class_dummy_10.f90: New test. Co-authored-by: Tobias Burnus
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #5 from Jürgen Reuter --- This could be either this commit commit d7caf313525a46f200d7f5db1ba893f853774aee Author: Paul Thomas Date: Sat Mar 18 07:56:23 2023 + /Fortran I think, it is NOT this one: commit 5889c7bd46a45dc07ffb77ec0d698e18e0b99840 Author: Paul Thomas Date: Mon Mar 20 06:13:54 2023 + Fortran: Allow external function from in an associate block [PR87127] NOR this one: commit 5426ab34643d9e6502f3ee572891a03471fa33ed Author: Harald Anlauf Date: Fri Mar 17 22:24:49 2023 +0100 Fortran: procedures with BIND(C) attribute require explicit interface [PR85877]
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #4 from Jürgen Reuter --- Here is the promised reproducer, which fails even when not using submodules: $ gfortran -c reproducer.f90 reproducer.f90:69:4: 69 | history_new(1:s) = res_set%history(1:s) |1 Error: Component to the right of a part reference with nonzero rank must not have the ALLOCATABLE attribute at (1) reproducer.f90:69:23: 69 | history_new(1:s) = res_set%history(1:s) | 1 Error: Component to the right of a part reference with nonzero rank must not have the ALLOCATABLE attribute at (1) module resonances implicit none private type :: t1_t integer, dimension(:), allocatable :: c contains procedure, private :: t1_assign generic :: assignment(=) => t1_assign end type t1_t type :: t3_t type(t1_t), dimension(:), allocatable :: resonances integer :: n_resonances = 0 contains procedure, private :: t3_assign generic :: assignment(=) => t3_assign end type t3_t type :: resonance_branch_t integer :: i = 0 integer, dimension(:), allocatable :: r_child integer, dimension(:), allocatable :: o_child end type resonance_branch_t type :: resonance_tree_t private integer :: n = 0 type(resonance_branch_t), dimension(:), allocatable :: branch end type resonance_tree_t type :: t3_set_t private type(t3_t), dimension(:), allocatable :: history type(resonance_tree_t), dimension(:), allocatable :: tree integer :: last = 0 contains procedure, private :: expand => t3_set_expand end type t3_set_t contains pure subroutine t1_assign & (t1_out, t1_in) class(t1_t), intent(inout) :: t1_out class(t1_t), intent(in) :: t1_in if (allocated (t1_out%c)) deallocate (t1_out%c) if (allocated (t1_in%c)) then allocate (t1_out%c (size (t1_in%c))) t1_out%c = t1_in%c end if end subroutine t1_assign subroutine t3_assign (res_hist_out, res_hist_in) class(t3_t), intent(out) :: res_hist_out class(t3_t), intent(in) :: res_hist_in if (allocated (res_hist_in%resonances)) then res_hist_out%resonances = res_hist_in%resonances res_hist_out%n_resonances = res_hist_in%n_resonances end if end subroutine t3_assign module subroutine t3_set_expand (res_set) class(t3_set_t), intent(inout) :: res_set type(t3_t), dimension(:), allocatable :: history_new integer :: s s = size (res_set%history) allocate (history_new (2 * s)) history_new(1:s) = res_set%history(1:s) call move_alloc (history_new, res_set%history) end subroutine t3_set_expand end module resonances
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #3 from Jürgen Reuter --- Created attachment 54713 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54713&action=edit Promised short reproducer, 73 lines
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #2 from Jürgen Reuter --- Created attachment 54712 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54712&action=edit Second, single-file reproducer, still 6295 lines Still further reducing, stay tuned.
[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 --- Comment #1 from Jürgen Reuter --- Created attachment 54710 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54710&action=edit First still pretty large reproducer I will provide a smaller reproducer soon.
[Bug fortran/109209] New: [13.0 regression] erroneous error on assignment of alloctables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209 Bug ID: 109209 Summary: [13.0 regression] erroneous error on assignment of alloctables Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Some commit between last week and now, so between March 12 and March 19, has created a regression, so gfortran throws a (presumably wrong) error message: resonances_sub.f90:816:4: 816 | history_new(1:s) = res_set%history(1:s) |1 Error: Component to the right of a part reference with nonzero rank must not have the ALLOCATABLE attribute at (1) resonances_sub.f90:816:23: 816 | history_new(1:s) = res_set%history(1:s) | 1 Error: Component to the right of a part reference with nonzero rank must not have the ALLOCATABLE attribute at (1) This is a first part of the code below, I will hopefully provide a full reproducer later one. 810module subroutine resonance_history_set_expand (res_set) 811 class(resonance_history_set_t), intent(inout) :: res_set 812 type(resonance_history_t), dimension(:), allocatable :: history_new 813 integer :: s 814 s = size (res_set%history) 815 allocate (history_new (2 * s)) 816 history_new(1:s) = res_set%history(1:s) 817 call move_alloc (history_new, res_set%history) 818end subroutine resonance_history_set_expand 58type :: resonance_info_t 59 type(flavor_t) :: flavor 60 type(resonance_contributors_t) :: contributors 61contains 62 procedure :: copy => resonance_info_copy 63 procedure :: write => resonance_info_write 64 procedure, private :: resonance_info_init_pdg 65 procedure, private :: resonance_info_init_flv 66 generic :: init => resonance_info_init_pdg, resonance_info_init_flv 67 procedure, private :: resonance_info_equal 68 generic :: operator(==) => resonance_info_equal 69 procedure :: mapping => resonance_info_mapping 70 procedure, private :: get_n_contributors => resonance_info_get_n_contributors 71 procedure, private :: contains => resonance_info_contains 72 procedure :: evaluate_distance => resonance_info_evaluate_distance 73 procedure :: evaluate_gaussian => resonance_info_evaluate_gaussian 74 procedure :: is_on_shell => resonance_info_is_on_shell 75 procedure :: as_omega_string => resonance_info_as_omega_string 76end type resonance_info_t 77 78type :: resonance_history_t 79 type(resonance_info_t), dimension(:), allocatable :: resonances 80 integer :: n_resonances = 0 81contains 82 procedure :: clear => resonance_history_clear 83 procedure :: copy => resonance_history_copy 84 procedure :: write => resonance_history_write 85 procedure, private :: resonance_history_assign 86 generic :: assignment(=) => resonance_history_assign 87 procedure, private :: resonance_history_equal 88 generic :: operator(==) => resonance_history_equal 89 procedure, private :: resonance_history_contains 90 generic :: operator(.contains.) => resonance_history_contains 91 procedure :: add_resonance => resonance_history_add_resonance 92 procedure :: remove_resonance => resonance_history_remove_resonance 93 procedure :: add_offset => resonance_history_add_offset 94 procedure :: contains_leg => resonance_history_contains_leg 95 procedure :: mapping => resonance_history_mapping 96 procedure :: only_has_n_contributors => & 97resonance_history_only_has_n_contributors 98 procedure :: has_flavor => resonance_history_has_flavor 99 procedure :: evaluate_distances => resonance_history_evaluate_distances 100 procedure :: evaluate_gaussian => resonance_history_evaluate_gaussian 101 procedure :: is_on_shell => resonance_history_is_on_shell 102 procedure :: as_omega_string => resonance_history_as_omega_string 103 procedure :: to_tree => resonance_history_to_tree 104end type resonance_history_t 129type :: resonance_history_set_t 130 private 131 logical :: complete = .false. 132 integer :: n_filter = 0 133 type(resonance_history_t), dimension(:), allocatable :: history 134 type(index_array_t), dimension(:), allocatable :: contains_this 135 type(resonance_tree_t), dimension(:), allocatable :: tree 136 integer :: last = 0 137 contains 138 procedure :: write => resonance_history_set_write 139 procedure :: i
[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 --- Comment #13 from Jürgen Reuter --- (In reply to Iain Sandoe from comment #12) . > > Next, I guess I'll pick up the xc 14.2 release. Sorry, my bad, I misplaced the position of the argument BOOT_CFLAGS, I erroneously (like for configure, where it doesn't matter) in front of the make command, not after the make command. In the second case, it works.
[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 --- Comment #10 from Jürgen Reuter --- (In reply to Iain Sandoe from comment #9) > (I don't have a macOS13 setup yet, limited hardware available here) > > ... so, if it is not fixed in the Xcode 14.x releases, we'll have to work > around it in the GCC sources. > > Work-around is to add this to the 'make' command line. > > BOOT_CFLAGS="-O2 -g -Wno-error=deprecated-declarations" > > I think we can arrange for that to be added automatically to the build > flags, it is intended to deal with this before 13 branches. Hm, this doesn't work for me, neither when adding to the configure line nor when adding it to the make command. Sorry for being ignorant, but how do I have to apply this?
[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 --- Comment #8 from Jürgen Reuter --- What is the status of this problem? I checked with Darwin 22.2 and XCode 14.2, and the problem still persists with the Git master, cf. below. Is there a workaround for the moment? Will this be resolved before the release of gcc14? /usr/local/packages/gcc_trunk/_build/./prev-gcc/xg++ -B/usr/local/packages/gcc_trunk/_build/./prev-gcc/ -B/usr/local/x86_64-apple-darwin22.2.0/bin/ -nostdinc++ -B/usr/local/packages/gcc_trunk/_build/prev-x86_64-apple-darwin22.2.0/libstdc++-v3/src/.libs -B/usr/local/packages/gcc_trunk/_build/prev-x86_64-apple-darwin22.2.0/libstdc++-v3/libsupc++/.libs -I/usr/local/packages/gcc_trunk/_build/prev-x86_64-apple-darwin22.2.0/libstdc++-v3/include/x86_64-apple-darwin22.2.0 -I/usr/local/packages/gcc_trunk/_build/prev-x86_64-apple-darwin22.2.0/libstdc++-v3/include -I/usr/local/packages/gcc_trunk/libstdc++-v3/libsupc++ -L/usr/local/packages/gcc_trunk/_build/prev-x86_64-apple-darwin22.2.0/libstdc++-v3/src/.libs -L/usr/local/packages/gcc_trunk/_build/prev-x86_64-apple-darwin22.2.0/libstdc++-v3/libsupc++/.libs -I../../libcpp -I. -I../../libcpp/../include -I./../intl -I../../libcpp/include -g -O2 -fno-checking -gtoggle -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -fno-exceptions -fno-rtti -I../../libcpp -I. -I../../libcpp/../include -I./../intl -I../../libcpp/include-c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../../libcpp/charset.cc ../../libcpp/charset.cc: In function ‘const uchar* convert_escape(cpp_reader*, const uchar*, const uchar*, _cpp_strbuf*, cset_converter, cpp_string_location_reader*, cpp_substring_ranges*)’: ../../libcpp/charset.cc:2207:18: error: ‘int sprintf(char*, const char*, ...)’ is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Werror=deprecated-declarations] 2207 | sprintf(buf, "%03o", (int) c); | ~~~^~ In file included from ../../libcpp/system.h:38, from ../../libcpp/charset.cc:21: /usr/local/packages/gcc_trunk/_build/prev-gcc/include-fixed/stdio.h:204:10: note: declared here 204 | int sprintf(char * __restrict, const char * __restrict, ...) __printflike(2, 3); | ^~~
[Bug bootstrap/107253] New: gcc does not compile with XCode 14.0.1 / clang 14.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107253 Bug ID: 107253 Summary: gcc does not compile with XCode 14.0.1 / clang 14.0.0 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- The linking during bootstrap on Darwin 21.6.0 with Xcode 14.0.1 chokes on the error message below, the configure line has been: ../configure --prefix=/usr/local/ --with-gmp=/usr/local/ --with-mpfr=/usr/local/ --with-mpr=/usr/local/ --with-isl=/usr/local/ --enable-checking=release --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk --enable-languages=c,c++,fortran,lto,objc,obj-c++ 0 0x101ac7ffa __assert_rtn + 139 1 0x1018fb28d mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions const&) + 4989 2 0x1018ebf8f mach_o::relocatable::Parser::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) + 207 3 0x1019629d4 ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool) + 2036 4 0x101965fa0 ___ZN2ld4tool10InputFilesC2ER7Options_block_invoke + 48 5 0x7ff806eb134a _dispatch_client_callout2 + 8 6 0x7ff806ec28f5 _dispatch_apply_invoke + 213 7 0x7ff806eb1317 _dispatch_client_callout + 8 8 0x7ff806ec0c0c _dispatch_root_queue_drain + 673 9 0x7ff806ec125c _dispatch_worker_thread2 + 160 10 0x7ff807064f8a _pthread_wqthread + 256 A linker snapshot was created at: /tmp/libstdc++.6.dylib-2022-10-13-180147.ld-snapshot ld: Assertion failed: (_file->_atomsArrayCount == computedAtomCount && "more atoms allocated than expected"), function parse, file macho_relocatable_file.cpp, line 2061. collect2: error: ld returned 1 exit status make[6]: *** [libstdc++.la] Error 1 make[5]: *** [all-recursive] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-stage1-target-libstdc++-v3] Error 2 make[1]: *** [stage1-bubble] Error 2 The failing link command was: libtool: link: /usr/local/packages/gcc_trunk/_build/./gcc/xgcc -shared-libgcc -B/usr/local/packages/gcc_trunk/_build/./gcc -nostdinc++ -L/usr/local/packages/gcc_trunk/_build/x86_64-apple-darwin21.6.0/libstdc++-v3/src -L/usr/local/packages/gcc_trunk/_build/x86_64-apple-darwin21.6.0/libstdc++-v3/src/.libs -L/usr/local/packages/gcc_trunk/_build/x86_64-apple-darwin21.6.0/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-apple-darwin21.6.0/bin/ -B/usr/local/x86_64-apple-darwin21.6.0/lib/ -isystem /usr/local/x86_64-apple-darwin21.6.0/include -isystem /usr/local/x86_64-apple-darwin21.6.0/sys-include -fno-checking -dynamiclib -o .libs/libstdc++.6.dylib .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o .libs/compatibility-thread-c++0x.o .libs/libstdc++.lax/libsupc++convenience.a/array_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/atexit_arm.o .libs/libstdc++.lax/libsupc++convenience.a/atexit_thread.o .libs/libstdc++.lax/libsupc++convenience.a/atomicity.o .libs/libstdc++.lax/libsupc++convenience.a/bad_alloc.o .libs/libstdc++.lax/libsupc++convenience.a/bad_array_length.o .libs/libstdc++.lax/libsupc++convenience.a/bad_array_new.o .libs/libstdc++.lax/libsupc++convenience.a/bad_cast.o .libs/libstdc++.lax/libsupc++convenience.a/bad_typeid.o .libs/libstdc++.lax/libsupc++convenience.a/class_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/cp-demangle.o .libs/libstdc++.lax/libsupc++convenience.a/del_op.o .libs/libstdc++.lax/libsupc++convenience.a/del_opa.o .libs/libstdc++.lax/libsupc++convenience.a/del_opant.o .libs/libstdc++.lax/libsupc++convenience.a/del_opnt.o .libs/libstdc++.lax/libsupc++convenience.a/del_ops.o .libs/libstdc++.lax/libsupc++convenience.a/del_opsa.o .libs/libstdc++.lax/libsupc++convenience.a/del_opv.o .libs/libstdc++.lax/libsupc++convenience.a/del_opva.o .libs/libstdc++.lax/libsupc++convenience.a/del_opvant.o .libs/libstdc++.lax/libsupc++convenience.a/del_opvnt.o .libs/libstdc++.lax/libsupc++convenience.a/del_opvs.o .libs/libstdc++.lax/libsupc++convenience.a/del_opvsa.o .libs/libstdc++.lax/libsupc++convenience.a/dyncast.o .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o .libs/libstdc++.lax/libsupc++convenience.a/eh_arm.o .libs/libstdc++.lax/libsupc++convenience.a/eh_aux_runtime.o .libs/libstdc++.lax/libsupc++convenience.a/eh_call.o .libs/libstdc++.lax/libsupc++convenience.a/eh_catch.o .libs/libstdc++.lax/libsupc++convenience.a/eh_exception.o .libs/libstdc++.lax/libsupc++convenience.a/eh_globals.o .libs/libstdc++.lax/libsupc++convenience.a/eh_personality.o .libs/libstdc++.lax/libsupc++convenience.a/eh_ptr.o .libs/libstdc++.lax/libsupc++convenience.a/e
[Bug bootstrap/106720] gcc does not compile with XCode 13.4.1 / clang 13.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106720 Jürgen Reuter changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jürgen Reuter --- Sorry, my mistake that I already made before: I had a non-vanishing C_/CPLUS_INCLUDE_PATH in my local variables which picked up a gcc, i.e. not the proper clang include files. Mea culpa.
[Bug bootstrap/106720] gcc does not compile with XCode 13.4.1 / clang 13.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106720 --- Comment #2 from Jürgen Reuter --- Hi Jakub, this is the compilation command: g++ -std=c++11 -I../../libcpp -I. -I../../libcpp/../include -I./../intl -I../../libcpp/include -g -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -fno-exceptions -fno-rtti -I../../libcpp -I. -I../../libcpp/../include -I./../intl -I../../libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../../libcpp/charset.cc In file included from ../../libcpp/charset.cc:22: This is the limits.h from XCode // -*- C++ -*- //===--- limits.h -===// // // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. // See https://llvm.org/LICENSE.txt for license information. // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception // //===--===// #ifndef _LIBCPP_LIMITS_H #define _LIBCPP_LIMITS_H /* limits.h synopsis Macros: CHAR_BIT SCHAR_MIN SCHAR_MAX UCHAR_MAX CHAR_MIN CHAR_MAX MB_LEN_MAX SHRT_MIN SHRT_MAX USHRT_MAX INT_MIN INT_MAX UINT_MAX LONG_MIN LONG_MAX ULONG_MAX LLONG_MIN // C99 LLONG_MAX // C99 ULLONG_MAX // C99 */ #include <__config> #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER) #pragma GCC system_header #endif #ifndef __GNUC__ #include_next #else // GCC header limits.h recursively includes itself through another header called // syslimits.h for some reason. This setup breaks down if we directly // #include_next GCC's limits.h (reasons not entirely clear to me). Therefore, // we manually re-create the necessary include sequence below: // Get the system limits.h defines (force recurse into the next level) #define _GCC_LIMITS_H_ #define _GCC_NEXT_LIMITS_H #include_next // Get the ISO C defines #undef _GCC_LIMITS_H_ #include_next #endif // __GNUC__ #endif // _LIBCPP_LIMITS_H
[Bug libgcc/106720] New: gcc does not compile with XCode 13.4.1 / clang 13.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106720 Bug ID: 106720 Summary: gcc does not compile with XCode 13.4.1 / clang 13.1.6 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Trying to compile the full gcc on Darwin x86_64 (not M1, darwin-arm64, not checked yet), the gcc 13.0.0 (git clone as of today) fails to compile with the following error message: ../../libcpp/include/cpplib.h:292:3: error: "Cannot find a least-32-bit signed integer type" # error "Cannot find a least-32-bit signed integer type" ^ ../../libcpp/include/cpplib.h:294:34: error: expected ';' after top level declarator typedef unsigned CPPCHAR_SIGNED_T cppchar_t; ^ ; ../../libcpp/include/cpplib.h:1163:8: error: unknown type name 'cppchar_t'; did you mean 'wchar_t'? extern cppchar_t cpp_interpret_charconst (cpp_reader *, const cpp_token *, ^ wchar_t ../../libcpp/include/cpplib.h:1180:8: error: unknown type name 'cppchar_t'; did you mean 'wchar_t'? extern cppchar_t cpp_host_to_exec_charset (cpp_reader *, cppchar_t); ^ wchar_t ../../libcpp/include/cpplib.h:1180:58: error: unknown type name 'cppchar_t'; did you mean 'wchar_t'? extern cppchar_t cpp_host_to_exec_charset (cpp_reader *, cppchar_t); ^ wchar_t ../../libcpp/include/cpplib.h:1361:8: error: unknown type name 'cppchar_t'; did you mean 'wchar_t'? extern cppchar_t cpp_parse_escape (cpp_reader *, const unsigned char ** pstr, ^ wchar_t ../../libcpp/include/cpplib.h:1492:3: error: unknown type name 'cppchar_t'; did you mean 'wchar_t'? cppchar_t m_ch;
[Bug fortran/104164] New: Bogus warning issued by -Wsurprising
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104164 Bug ID: 104164 Summary: Bogus warning issued by -Wsurprising Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- The code below (using iso_varying_string and a child module in the same module gives a bogus warning from -Wsurprsing reproducendum.f90:110:6: 110 | use diagnostics | 1 Warning: Type specified for intrinsic function ‘len’ at (1) is ignored [-Wsurprising] Depending on the order of the two use statements in the final module (os_interface), this warning appears either once or twice! Reproducer: module iso_varying_string implicit none integer, parameter, private :: GET_BUFFER_LEN = 1 type, public :: varying_string private character(LEN=1), dimension(:), allocatable :: chars end type varying_string interface assignment(=) module procedure op_assign_CH_VS module procedure op_assign_VS_CH end interface assignment(=) interface char module procedure char_auto module procedure char_fixed end interface char interface len module procedure len_ end interface len interface trim module procedure trim_ end interface trim public :: assignment(=) public :: char public :: len public :: trim private :: op_assign_CH_VS private :: op_assign_VS_CH private :: char_auto private :: char_fixed private :: len_ private :: trim_ contains elemental function len_ (string) result (length) type(varying_string), intent(in) :: string integer :: length if(ALLOCATED(string%chars)) then length = SIZE(string%chars) else length = 0 endif end function len_ elemental subroutine op_assign_CH_VS (var, exp) character(LEN=*), intent(out):: var type(varying_string), intent(in) :: exp end subroutine op_assign_CH_VS elemental subroutine op_assign_VS_CH (var, exp) type(varying_string), intent(out) :: var character(LEN=*), intent(in) :: exp end subroutine op_assign_VS_CH pure function char_auto (string) result (char_string) type(varying_string), intent(in) :: string character(LEN=len(string)) :: char_string integer :: i_char forall(i_char = 1:len(string)) char_string(i_char:i_char) = string%chars(i_char) end forall end function char_auto pure function char_fixed (string, length) result (char_string) type(varying_string), intent(in) :: string integer, intent(in) :: length character(LEN=length):: char_string char_string = char(string) end function char_fixed elemental function trim_ (string) result (trim_string) type(varying_string), intent(in) :: string type(varying_string) :: trim_string trim_string = TRIM(char(string)) end function trim_ end module iso_varying_string module diagnostics use iso_varying_string, string_t => varying_string implicit none private public :: int2char public :: int2fixed contains pure function int2fixed (i) result (c) integer, intent(in) :: i character(200) :: c end function int2fixed pure function int2char (i) result (c) integer, intent(in) :: i character(len (trim (int2fixed (i :: c end function int2char end module diagnostics module os_interface use iso_varying_string, string_t => varying_string use diagnostics end module os_interface
[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #35 from Jürgen Reuter --- Now that macOS 12.1 is out (and XCode 13.2) could someone please check whether the problem has been solved from the side of the Darwin kernel?
[Bug fortran/103115] [12 Regression] reallocation of character array fails when appending a constant size 4 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115 --- Comment #6 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #5) > I can confirm the ICE with current trunk both on x86_64 and > on POWER. > > x86_64: > > $ gfortran -v > Es werden eingebaute Spezifikationen verwendet. > COLLECT_GCC=gfortran > COLLECT_LTO_WRAPPER=/home/ig25/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto- > wrapper > Ziel: x86_64-pc-linux-gnu > Konfiguriert mit: ../trunk/configure --prefix=/home/ig25 > --enable-languages=c,c++,fortran --enable-maintainer-mode > Thread-Modell: posix > Unterstützte LTO-Kompressionsalgorithmen: zlib > gcc-Version 12.0.0 2026 (experimental) [master revision > e87559d202d:f4e6da6e8ac:36ec54aac7da134441c83248e14825381b8d6f17] (GCC) > $ gfortran a.f90 > a.f90:10:13: > >10 | ] > | 1 > interner Compiler-Fehler: tree check: expected integer_cst, have save_expr > in gfc_trans_array_constructor_value, at fortran/trans-array.c:2187 > 0x808a8a tree_check_failed(tree_node const*, char const*, int, char const*, > ...) > ../../trunk/gcc/tree.c:8701 > > POWER: > Really interesting, I don't get an ICE with the following setup: ../configure --prefix=/usr/local/ --with-gmp=/usr/local/ --with-mpfr=/usr/local/ --with-mp=/usr/local/ --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/ --enable-checking=release --enable-languages=c,c++,fortran,lto,objc,obj-c++ $ gfortran --version GNU Fortran (GCC) 12.0.0 2025 (experimental) Maybe the enable-checking setup!? I am compiling without any flags the code snippet in the very first post in this PR.
[Bug fortran/103115] [12 Regression] reallocation of character array fails when appending a constant size 4 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115 Jürgen Reuter changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #3 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #2) > I can confirm the bug with gcc 9 (didn't check any other > version). > > Current trunk gives me > > .f90:10:13: > >10 | ] > | 1 > interner Compiler-Fehler: tree check: expected integer_cst, have save_expr > in gfc_trans_array_constructor_value, at fortran/trans-array.c:2187 > 0x1002ebcf tree_check_failed(tree_node const*, char const*, int, char > const*, ...) > ../../trunk/gcc/tree.c:8689 > 0x101d89bf tree_int_cst_elt_check(tree_node*, int, char const*, int, char > const*) > ../../trunk/gcc/tree.h:3633 > 0x101d89bf tree_int_cst_elt_check(tree_node*, int, char const*, int, char > const*) > ../../trunk/gcc/tree.h:3629 > 0x101d89bf gfc_trans_array_constructor_value > ../../trunk/gcc/fortran/trans-array.c:2187 > 0x101d9563 trans_array_constructor > ../../trunk/gcc/fortran/trans-array.c:2900 > 0x101d9563 gfc_add_loop_ss_code > ../../trunk/gcc/fortran/trans-array.c:3180 > 0x101d9f6f gfc_conv_loop_setup(gfc_loopinfo*, locus*) > ../../trunk/gcc/fortran/trans-array.c:5430 > 0x102350db gfc_trans_assignment_1 > ../../trunk/gcc/fortran/trans-expr.c:11642 > 0x101ba337 trans_code > ../../trunk/gcc/fortran/trans.c:1916 > > Marking as regression for the ICE at least. Thomas, are you sure? I cannot see an ICE, neither with the master from September 21 nor with the master from yesterday.
[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #31 from Jürgen Reuter --- (In reply to Iain Sandoe from comment #29) > (In reply to Francois-Xavier Coudert from comment #28) > I've posted a fix for this (it is the fix for darwin21 DTORs in general) > however CAVEAT : there is No guarantee given by the GCC DTOR machinery about > the relative ordering of DTORs between different TUs, my fix will not solve > that. Does this now mean that this is fixed within the gcc trunk/master? Or just in a branch which has yet to be merged into the master? And will it be backported for 11.3, 10.4 as well?
[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #24 from Jürgen Reuter --- (In reply to Iain Sandoe from comment #23) > (In reply to Jürgen Reuter from comment #22) > > (In reply to Thomas Koenig from comment #20) > > > (In reply to Iain Sandoe from comment #16) > > > > (In reply to Thomas Koenig from comment #14) > > >Do we know that this will be > > fixed let's say for macOS 12.0.2 or so, and when will that come? > > I have filed a bug report, (FB9733712). It is impossible to know what the > OS release priorities are (or schedules), but I do know that the Apple OSS > folks are very supportive of gfortran, so I expect they will help. > Could you post the link to this bug report? I cannot find it. Or is this not publicly visible. > > At the > > moment these things do break quite a lot of build scripts for software that > > rely on redirecting output from test programs. Changing all those test > > programs to iso_fortan_env is tedious (but doable). I just started to look a bit, changing all of your configure script would be really tedious. So I really would prefer a fixed OS or a workaround inside gcc/gfortran.
[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #22 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #20) > (In reply to Iain Sandoe from comment #16) > > (In reply to Thomas Koenig from comment #14) > > There is always the reason of not breaking compatibility, a quick look > at close_units() shows that it is not meant to be called twice, > so combining both methods is likely to cause headaches. > > So, something for the next incompatible libgfortran update, maybe. > > Maybe flushing all units on program termination would be safer, but > I am not sure we should put in a workaround for what appears to > be a bug in the underlying system (hopefully soon to be fixed), > especially since there seems to be a workaround in user code. I agree that if this an OS bug, then workarounds in libgfortran that might jeopardize the integrity are hard to justify. Do we know that this will be fixed let's say for macOS 12.0.2 or so, and when will that come? At the moment these things do break quite a lot of build scripts for software that rely on redirecting output from test programs. Changing all those test programs to iso_fortan_env is tedious (but doable).
[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #21 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #19) > (In reply to Jürgen Reuter from comment #18) > > > write(0x1, " Hello, world!\\n\n\0", 0x11)= 17 0 > > Hmm, was this actually the string that you put into the Fortran > program, or is something very strange going on here? Yes, the program was program main print *, "Hello, world!\n" end program main sorry, about the backslash \n, that was accidental. Doing just program main print *, "Hello, world!" end program main # dtruss ./a.out > out.008 SYSCALL(args) = return Hello, world! access("/AppleInternal/XBS/.isChrooted\0", 0x0, 0x0) = -1 Err#2 bsdthread_register(0x7FF805E18020, 0x7FF805E1800C, 0x2000) = 1073742303 0 shm_open(0x7FF805CE6F5D, 0x0, 0x5CE57BA) = 3 0 fstat64(0x3, 0x7FF7BE646820, 0x0) = 0 0 mmap(0x0, 0x2000, 0x1, 0x40001, 0x3, 0x0) = 0x1019C9000 0 close(0x3) = 0 0 ioctl(0x2, 0x4004667A, 0x7FF7BE6468D4) = 0 0 mprotect(0x1019D, 0x1000, 0x0) = 0 0 mprotect(0x1019D7000, 0x1000, 0x0) = 0 0 mprotect(0x1019D8000, 0x1000, 0x0) = 0 0 mprotect(0x1019DF000, 0x1000, 0x0) = 0 0 mprotect(0x1019CB000, 0x90, 0x1) = 0 0 mprotect(0x1019CB000, 0x90, 0x3) = 0 0 mprotect(0x1019CB000, 0x90, 0x1) = 0 0 mprotect(0x1019E, 0x1000, 0x1) = 0 0 mprotect(0x1019E1000, 0x90, 0x1) = 0 0 mprotect(0x1019E1000, 0x90, 0x3) = 0 0 mprotect(0x1019E1000, 0x90, 0x1) = 0 0 mprotect(0x1019CB000, 0x90, 0x3) = 0 0 mprotect(0x1019CB000, 0x90, 0x1) = 0 0 mprotect(0x1019E, 0x1000, 0x3) = 0 0 mprotect(0x1019E, 0x1000, 0x1) = 0 0 issetugid(0x0, 0x0, 0x0) = 0 0 getentropy(0x7FF7BE6466D0, 0x20, 0x0) = 0 0 getentropy(0x7FF7BE646730, 0x40, 0x0) = 0 0 getpid(0x0, 0x0, 0x0) = 61408 0 stat64("/AppleInternal\0", 0x7FF7BE646DF0, 0x0) = -1 Err#2 csops_audittoken(0xEFE0, 0x7, 0x7FF7BE646920) = -1 Err#22 proc_info(0x2, 0xEFE0, 0xD) = 64 0 csops_audittoken(0xEFE0, 0x7, 0x7FF7BE646A10) = -1 Err#22 sysctlbyname(kern.osvariant_status, 0x15, 0x7FF7BE646E40, 0x7FF7BE646E38, 0x0) = 0 0 csops(0xEFE0, 0x0, 0x7FF7BE646E74) = 0 0 fstat64(0x0, 0x7FF7BE646BF0, 0x0) = 0 0 fstat64(0x1, 0x7FF7BE646BF0, 0x0) = 0 0 fstat64(0x2, 0x7FF7BE646BF0, 0x0) = 0 0 mprotect(0x1018C7000, 0x10, 0x1) = 0 0 sigaction(0x3, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0 sigaction(0x4, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0 sigaction(0x6, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0 sigaction(0x8, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0 sigaction(0xB, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0 sigaction(0xA, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0 sigaction(0xC, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0 sigaction(0x5, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0 sigaction(0x18, 0x7FF7BE647FA8, 0x7FF7BE647FD0) = 0 0 sigaction(0x19, 0x7FF7BE647FB8, 0x7FF7BE647FE0) = 0 0 write(0x1, " Hello, world!\n\0", 0xF) = 15 0
[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #18 from Jürgen Reuter --- (In reply to Thomas Koenig from comment #13) > Here is a complete strace of a "Hello, world" program on Linux, compiled > with -static-libgfortran (to remove some of the shared library loading :-) > and executed with > > $ strace ./a.out > hello.dat > > execve("./a.out", ["./a.out"], 0x7fff23679850 /* 52 vars */) = 0 > brk(NULL) = 0x55795af28000 > > Is it possible to run an equivalent command on MacOS to see > what is going on there? Seems that dtruss is doing the same under macOS, here I get this output for the Hello, world! program: SYSCALL(args)= return Hello, world!\n access("/AppleInternal/XBS/.isChrooted\0", 0x0, 0x0) = -1 Err#2 bsdthread_register(0x7FF805E18020, 0x7FF805E1800C, 0x2000) = 1073742303 0 shm_open(0x7FF805CE6F5D, 0x0, 0x5CE57BA) = 3 0 fstat64(0x3, 0x7FF7BDDDE820, 0x0)= 0 0 mmap(0x0, 0x2000, 0x1, 0x40001, 0x3, 0x0)= 0x102231000 0 close(0x3) = 0 0 ioctl(0x2, 0x4004667A, 0x7FF7BDDDE8D4) = 0 0 mprotect(0x102238000, 0x1000, 0x0) = 0 0 mprotect(0x10223F000, 0x1000, 0x0) = 0 0 mprotect(0x10224, 0x1000, 0x0) = 0 0 mprotect(0x102247000, 0x1000, 0x0) = 0 0 mprotect(0x102233000, 0x90, 0x1) = 0 0 mprotect(0x102233000, 0x90, 0x3) = 0 0 mprotect(0x102233000, 0x90, 0x1) = 0 0 mprotect(0x102248000, 0x1000, 0x1) = 0 0 mprotect(0x102249000, 0x90, 0x1) = 0 0 mprotect(0x102249000, 0x90, 0x3) = 0 0 mprotect(0x102249000, 0x90, 0x1) = 0 0 mprotect(0x102233000, 0x90, 0x3) = 0 0 mprotect(0x102233000, 0x90, 0x1) = 0 0 mprotect(0x102248000, 0x1000, 0x3) = 0 0 mprotect(0x102248000, 0x1000, 0x1) = 0 0 issetugid(0x0, 0x0, 0x0) = 0 0 getentropy(0x7FF7BDDDE6D0, 0x20, 0x0)= 0 0 getentropy(0x7FF7BDDDE730, 0x40, 0x0)= 0 0 getpid(0x0, 0x0, 0x0)= 61321 0 stat64("/AppleInternal\0", 0x7FF7BDDDEDF0, 0x0) = -1 Err#2 csops_audittoken(0xEF89, 0x7, 0x7FF7BDDDE920)= -1 Err#22 proc_info(0x2, 0xEF89, 0xD) = 64 0 csops_audittoken(0xEF89, 0x7, 0x7FF7BDDDEA10)= -1 Err#22 sysctlbyname(kern.osvariant_status, 0x15, 0x7FF7BDDDEE40, 0x7FF7BDDDEE38, 0x0) = 0 0 csops(0xEF89, 0x0, 0x7FF7BDDDEE74) = 0 0 fstat64(0x0, 0x7FF7BDDDEBF0, 0x0)= 0 0 fstat64(0x1, 0x7FF7BDDDEBF0, 0x0)= 0 0 fstat64(0x2, 0x7FF7BDDDEBF0, 0x0)= 0 0 mprotect(0x10212F000, 0x10, 0x1) = 0 0 sigaction(0x3, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0) = 0 0 sigaction(0x4, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0) = 0 0 sigaction(0x6, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0) = 0 0 sigaction(0x8, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0) = 0 0 sigaction(0xB, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0) = 0 0 sigaction(0xA, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0) = 0 0 sigaction(0xC, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0) = 0 0 sigaction(0x5, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0) = 0 0 sigaction(0x18, 0x7FF7BDDDFFA8, 0x7FF7BDDDFFD0) = 0 0 sigaction(0x19, 0x7FF7BDDDFFB8, 0x7FF7BDDDFFE0) = 0 0 write(0x1, " Hello, world!\\n\n\0", 0x11)= 17 0
[Bug tree-optimization/103007] [12 Regression] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722 since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007 --- Comment #8 from Jürgen Reuter --- (In reply to Jürgen Reuter from comment #6) > Created attachment 51716 [details] > gfortran appearance of the ICE Just for completeness, this example needs to be compiled with -O2, while -O0 and -O1 work fine.
[Bug tree-optimization/103007] [12 Regression] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722 since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007 --- Comment #6 from Jürgen Reuter --- Created attachment 51716 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51716&action=edit gfortran appearance of the ICE