[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 = >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=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 .merg
[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*) + 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*) + 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=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=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=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=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=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=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=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=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=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 con
[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/lib
[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=edit gfortran appearance of the ICE
[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 Jürgen Reuter changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #5 from Jürgen Reuter --- I can confirm this ICE also with (legacy) Fortran code, cf. below. The full code is attached. C*** C...PYQQBH C...Calculates the matrix element for the processes C...g + g or q + qbar -> Q + Qbar + H (normally with Q = t). C...REDUCE output and part of the rest courtesy Z. Kunszt, see C...Z. Kunszt, Nucl. Phys. B247 (1984) 339. SUBROUTINE PYQQBH(WTQQBH) C...Double precision and integer declarations. IMPLICIT DOUBLE PRECISION(A-H, O-Z) IMPLICIT INTEGER(I-N) INTEGER PYK,PYCHGE,PYCOMP C...Commonblocks. COMMON/PYDAT1/MSTU(200),PARU(200),MSTJ(200),PARJ(200) COMMON/PYDAT2/KCHG(500,4),PMAS(500,4),PARF(2000),VCKM(4,4) COMMON/PYPARS/MSTP(200),PARP(200),MSTI(200),PARI(200) COMMON/PYINT1/MINT(400),VINT(400) COMMON/PYINT2/ISET(500),KFPR(500,2),COEF(500,20),ICOL(40,4,2) SAVE /PYDAT1/,/PYDAT2/,/PYPARS/,/PYINT1/,/PYINT2/ C...Local arrays and function. DIMENSION PP(15,4),CLR(8,8),FM(10,10),RM(8,8),DX(8) DOT(I,J)=PP(I,4)*PP(J,4)-PP(I,1)*PP(J,1)-PP(I,2)*PP(J,2)- (I,3)*PP(J,3) C...Mass parameters. WTQQBH=0D0 ISUB=MINT(1) SHPR=SQRT(VINT(26))*VINT(1) PQ=PMAS(PYCOMP(KFPR(ISUB,2)),1) PH=SQRT(VINT(21))*VINT(1) SPQ=PQ**2 SPH=PH**2 C...Set up outgoing kinematics: 1=t, 2=tbar, 3=H. DO 100 I=1,2 PT=SQRT(MAX(0D0,VINT(197+5*I))) PP(I,1)=PT*COS(VINT(198+5*I)) PP(I,2)=PT*SIN(VINT(198+5*I)) 100 CONTINUE PP(3,1)=-PP(1,1)-PP(2,1) PP(3,2)=-PP(1,2)-PP(2,2) PMS1=SPQ+PP(1,1)**2+PP(1,2)**2 PMS2=SPQ+PP(2,1)**2+PP(2,2)**2 PMS3=SPH+PP(3,1)**2+PP(3,2)**2 PMT3=SQRT(PMS3) PP(3,3)=PMT3*SINH(VINT(211)) PP(3,4)=PMT3*COSH(VINT(211)) PMS12=(SHPR-PP(3,4))**2-PP(3,3)**2 PP(1,3)=(-PP(3,3)*(PMS12+PMS1-PMS2)+ (213)*(SHPR-PP(3,4))*VINT(220))/(2D0*PMS12) PP(2,3)=-PP(1,3)-PP(3,3) PP(1,4)=SQRT(PMS1+PP(1,3)**2) PP(2,4)=SQRT(PMS2+PP(2,3)**2) C...Set up incoming kinematics and derived momentum combinations. DO 110 I=4,5 PP(I,1)=0D0 PP(I,2)=0D0 PP(I,3)=-0.5D0*SHPR*(-1)**I PP(I,4)=-0.5D0*SHPR 110 CONTINUE DO 120 J=1,4 PP(6,J)=PP(1,J)+PP(2,J) PP(7,J)=PP(1,J)+PP(3,J) PP(8,J)=PP(1,J)+PP(4,J) PP(9,J)=PP(1,J)+PP(5,J) PP(10,J)=-PP(2,J)-PP(3,J) PP(11,J)=-PP(2,J)-PP(4,J) PP(12,J)=-PP(2,J)-PP(5,J) PP(13,J)=-PP(4,J)-PP(5,J) 120 CONTINUE C...Derived kinematics invariants. X1=DOT(1,2) X2=DOT(1,3) X3=DOT(1,4) X4=DOT(1,5) X5=DOT(2,3) X6=DOT(2,4) X7=DOT(2,5) X8=DOT(3,4) X9=DOT(3,5) X10=DOT(4,5) C...Propagators. SS1=DOT(7,7)-SPQ SS2=DOT(8,8)-SPQ SS3=DOT(9,9)-SPQ SS4=DOT(10,10)-SPQ SS5=DOT(11,11)-SPQ SS6=DOT(12,12)-SPQ SS7=DOT(13,13) DX(1)=SS1*SS6 DX(2)=SS2*SS6 DX(3)=SS2*SS4 DX(4)=SS1*SS5 DX(5)=SS3*SS5 DX(6)=SS3*SS4 DX(7)=SS7*SS1 DX(8)=SS7*SS4 C...Define colour coefficients for g + g -> Q + Qbar + H. IF(ISUB.EQ.121.OR.ISUB.EQ.181.OR.ISUB.EQ.186) THEN DO 140 I=1,3 DO 130 J=1,3 CLR(I,J)=16D0/3D0 CLR(I+3,J+3)=16D0/3D0 CLR(I,J+3)=-2D0/3D0 CLR(I+3,J)=-2D0/3D0 130 CONTINUE 140 CONTINUE DO 160 L=1,2 DO 150 I=1,3 CLR(I,6+L)=-6D0 CLR(I+3,6+L)=6D0 CLR(6+L,I)=-6D0 CLR(6+L,I+3)=6D0 150 CONTINUE 160 CONTINUE DO 180 K1=1,2 DO 170 K2=1,2 CLR(6+K1,6+K2)=12D0 170 CONTINUE 180 CONTINUE C...Evaluate matrix elements for g + g -> Q + Qbar + H. FM(1,1)=64*PQ**6+16*PQ**4*PH**2+32*PQ**4*(X1+2*X2+X4+X9+2* & X7+X5)+8*PQ**2*PH**2*(-X1-X4+2*X7)+16*PQ**2*(X2*X9+4*X2* & X7+X2*X5-2*X4*X7-2*X9*X7)+8*PH**2*X4*X7-16*X2*X9*X7 FM(1,2)=16*PQ**6+8*PQ**4*(-2*X1+X2-2*X3-2*X4-4*X10+X9-X8+2 & *X7-4*X6+X5)+8*PQ**2*(-2*X1*X2-2*X2*X4-2*X2*X10+X2*X7-2* & X2*X6-2*X3*X7+2*X4*X7+4*X10*X7-X9*X7-X8*X7)+16*X2*X7*(X4+ & X10) FM(1,3)=16*PQ**6-4*PQ**4*PH**2+8*PQ**4*(-2*X1+2*X2-2*X3-4* & X4-8*X10+X9+X8-2*X7-4*X6+2*X5)-(4*PQ**2*PH**2)*(X1+X4+X10 & +X6)+8*PQ**2*(-2*X1*X2-2*X1*X10+X1*X9+X1*X8-2*X1*X5+X2**2 & -4*X2*X4-5*X2*X10+X2*X8-X2*X7-3*X2*X6+X2*X5+X3*X9+2*X3*X7 & -X3*X5+X4*X8+2*X4*X6-3*X4*X5-5*X10*X5+X9*X8+X9*X6+X9*X5+ & X8*X7-4*X6*X5+X5**2)-(16*X2*X5)*(X1+X4+X10+X6) FM(1,4)=16*PQ**6+4*PQ**4*PH**2+16*PQ**4*(-X1+X2-X3-
[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 #12 from Jürgen Reuter --- I'm not an expert on the I/O system, but could it be that the unit to which the stdout of a compiled Fortran program goes does not provide the unit that the redirect function (now) expects under macOS 12?
[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 #10 from Jürgen Reuter --- Reassuringly, the gfortran 11.2 from Macports has the same problem as the gfortran 12.0.0 installed by hand: no redirecting into files.
[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 #9 from Jürgen Reuter --- I also tried that for a Fortran program ./a.out | less (pipe to less) works. It's just the redirection that does not work. I'm waiting for the compilation to check whether gfortran 11.2 from Macports shares the same problem.
[Bug libfortran/102992] Piping in a file does no longer work on macOS Monterey
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #5 from Jürgen Reuter --- I checked that the assembler code on macOS Big Sur and Monterey is identical (up to the date in the .ident line). So either the assembler works differently, or one of the routines from the libgfortran (_gfortrran_st_write, _gfortran_set_options, _gfortran_set_args, _gfortran_transfer_character_write) acts differently now.
[Bug libfortran/102992] Piping in a file does no longer work on macOS Monterey
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #4 from Jürgen Reuter --- The problem is not related to XCode 13.1 which appeared at roughly the same time. On Big Sur with XCode 13.1 still all works as expected.
[Bug fortran/102992] Piping in a file does no longer work on macOS Monterey
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 --- Comment #1 from Jürgen Reuter --- Using a C program compiled with the same version (recent trunk with the fix by Iain Sandoe for Monterey) leads to a program that can pipe to a file.
[Bug fortran/102992] New: Piping in a file does no longer work on macOS Monterey
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 Bug ID: 102992 Summary: Piping in a file does no longer work on macOS Monterey Product: gcc Version: 11.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: --- I don't know whether this is really an issue with gfortran or a screwed setting of my macOS installation, I have macOS 12.0.1 Monterey, Darwin 21.1.0, with XCode 13.1, and a simple file main.f90: program main print *, "42" end program main gfortran -o conftest main.f90 prints 42 in the shell, so to stdout. But when tryng pipe to a file this does not work, the file is always empty, i.e. ./conftest > bla.txt result in an empty file.
[Bug libgcc/102968] New: macOS Monterey not yet supported in configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102968 Bug ID: 102968 Summary: macOS Monterey not yet supported in configure Product: gcc Version: 12.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: --- Under macOS Monterey 12.0.1 Darwin 21.1.0 the configure doesn't work, but bails out with the message: "Error: configuring for an unreleased masOS version x86_64-apple-darwin21.1.0"
[Bug c/102304] New: Internal compiler error: in gen_lowpart_general, rtlhooks.c: 57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102304 Bug ID: 102304 Summary: Internal compiler error: in gen_lowpart_general, rtlhooks.c: 57 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- The compilation of gcc (using gcc-10.2.1 from Debian) fails with an Internal Compiler Error of .xgcc. I don't know whether this is an ICE problem inside gcc-10.2.1 or maybe a bootstrapping problem of the gcc trunk/master (v12). In any case, the problem didn't happen with the gcc trunk/master (v12) a week ago. This is the output: during RTL pass: expand In file included from /usr/src/gcc/libgcc/soft-fp/soft-fp.h:317, from /usr/src/gcc/libgcc/soft-fp/trunctfhf2.c:29: /usr/src/gcc/libgcc/soft-fp/trunctfhf2.c: In function '__trunctfhf2': /usr/src/gcc/libgcc/soft-fp/op-1.h:131:13: internal compiler error: in gen_lowpart_general, at rtlhooks.c:57 131 | (val) = _FP_PACK_RAW_1_flo.flt; \ | ~~^~~~ /usr/src/gcc/libgcc/soft-fp/half.h:146:7: note: in expansion of macro '_FP_PACK_RAW_1' 146 | _FP_PACK_RAW_1 (H, (val), X); \ | ^~ /usr/src/gcc/libgcc/soft-fp/trunctfhf2.c:48:3: note: in expansion of macro 'FP_PACK_SEMIRAW_H' 48 | FP_PACK_SEMIRAW_H (r, R); | ^ during RTL pass: expand In file included from /usr/src/gcc/libgcc/soft-fp/soft-fp.h:317, from /usr/src/gcc/libgcc/soft-fp/truncdfhf2.c:29: /usr/src/gcc/libgcc/soft-fp/truncdfhf2.c: In function '__truncdfhf2': /usr/src/gcc/libgcc/soft-fp/op-1.h:131:13: internal compiler error: in gen_lowpart_general, at rtlhooks.c:57 131 | (val) = _FP_PACK_RAW_1_flo.flt; \ | ~~^~~~ /usr/src/gcc/libgcc/soft-fp/half.h:146:7: note: in expansion of macro '_FP_PACK_RAW_1' 146 | _FP_PACK_RAW_1 (H, (val), X); \ | ^~ /usr/src/gcc/libgcc/soft-fp/truncdfhf2.c:48:3: note: in expansion of macro 'FP_PACK_SEMIRAW_H' 48 | FP_PACK_SEMIRAW_H (r, R); | ^ during RTL pass: expand In file included from /usr/src/gcc/libgcc/soft-fp/soft-fp.h:317, from /usr/src/gcc/libgcc/soft-fp/truncxfhf2.c:29: /usr/src/gcc/libgcc/soft-fp/truncxfhf2.c: In function '__truncxfhf2': /usr/src/gcc/libgcc/soft-fp/op-1.h:131:13: internal compiler error: in gen_lowpart_general, at rtlhooks.c:57 131 | (val) = _FP_PACK_RAW_1_flo.flt; \ | ~~^~~~ /usr/src/gcc/libgcc/soft-fp/half.h:146:7: note: in expansion of macro '_FP_PACK_RAW_1' 146 | _FP_PACK_RAW_1 (H, (val), X); \ | ^~ /usr/src/gcc/libgcc/soft-fp/truncxfhf2.c:48:3: note: in expansion of macro 'FP_PACK_SEMIRAW_H' 48 | FP_PACK_SEMIRAW_H (r, R); | ^ during RTL pass: expand In file included from /usr/src/gcc/libgcc/soft-fp/soft-fp.h:317, from /usr/src/gcc/libgcc/soft-fp/truncsfhf2.c:29: /usr/src/gcc/libgcc/soft-fp/truncsfhf2.c: In function '__truncsfhf2': /usr/src/gcc/libgcc/soft-fp/op-1.h:131:13: internal compiler error: in gen_lowpart_general, at rtlhooks.c:57 131 | (val) = _FP_PACK_RAW_1_flo.flt; \ | ~~^~~~ /usr/src/gcc/libgcc/soft-fp/half.h:146:7: note: in expansion of macro '_FP_PACK_RAW_1' 146 | _FP_PACK_RAW_1 (H, (val), X); \ | ^~ /usr/src/gcc/libgcc/soft-fp/truncsfhf2.c:44:3: note: in expansion of macro 'FP_PACK_SEMIRAW_H' 44 | FP_PACK_SEMIRAW_H (r, R); | ^ 0x12eea5d gen_lowpart_general(machine_mode, rtx_def*) /usr/src/gcc/gcc/rtlhooks.c:57 0xe06146 extract_bit_field_using_extv /usr/src/gcc/gcc/expmed.c:1581 0xe08a01 extract_integral_bit_field /usr/src/gcc/gcc/expmed.c:1993 0xe07ece extract_bit_field_1 /usr/src/gcc/gcc/expmed.c:1857 0xe0943b extract_bit_field(rtx_def*, poly_int<1u, unsigned long>, poly_int<1u, unsigned long>, int, rtx_def*, machine_mode, machine_mode, bool, rtx_def**) /usr/src/gcc/gcc/expmed.c:2129 0x12eea5d gen_lowpart_general(machine_mode, rtx_def*) /usr/src/gcc/gcc/rtlhooks.c:57 0x12eea5d gen_lowpart_general(machine_mode, rtx_def*) /usr/src/gcc/gcc/rtlhooks.c:57 0xe06146 extract_bit_field_using_extv /usr/src/gcc/gcc/expmed.c:1581 0xe49f54 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /usr/src/gcc/gcc/expr.c:11413 0xe3d78e expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /usr/src/gcc/gcc/expr.c:8752 0xe08a01 extract_integral_bit_field /usr/src/gcc/gcc/e
[Bug fortran/87980] ICE in gfc_conv_descriptor_data_get, at fortran/trans-array.c for assignment on allocatable polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87980 --- Comment #8 from Jürgen Reuter --- The actual workaround that I'm using (the code is from of our stale branches which recently became active again) is: [...] subroutine qn_string_set (qns, col) class(qn_string_t), intent(inout) :: qns class(col_t), dimension(:), intent(in), optional :: col class(col_t), allocatable :: col0 integer :: i do i = 1, qns%length if (present (col)) then col0 = col(i) call qns%qn(i)%set (col=col0) end if end do end subroutine qn_string_set end module quantum_numbers [...] This seems to work in our code, i.e. it compiles and it does what it should. But in the long run, would be great to get it fixed for gcc/gfortran 12.
[Bug fortran/87980] ICE in gfc_conv_descriptor_data_get, at fortran/trans-array.c for assignment on allocatable polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87980 --- Comment #7 from Jürgen Reuter --- Is anybody ever looked into this? Any updates?
[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 --- Comment #12 from Jürgen Reuter --- (In reply to Iain Sandoe from comment #11) > > 1. Update to XCode 12.5.1 (which apparently exists, but I don't know if it > > has the fixes?) > > not yet checked - but if someone has time I'd like to know ;) > > > a) was hoping for a fix [does anyone know if 12.5.1 fixes?] > I just checked with XCode 12.5.1, nothing fixed yet, the problem persists.
[Bug fortran/101199] program changes the value of a dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199 --- Comment #5 from Jürgen Reuter --- (In reply to ygal klein from comment #4) >) > > Thank you for the reply. > > After posting the bug report - I saw that implementing (inout) as your > number 1 suggestion - dodges the problem - though as you mentioned having > inout for this in an init routine is somewhat unnatural. > > The 2nd suggestion is something that I was trying to avoid in the first > place - i.e copying a whole type (this minimal example is a small type - but > originally it is a type with a lot of instances and procedures) > > In fact - I could have had advance as a function that returns a type - but > then I would be paying the price of copyin assignment of a big type. > > Anyway - you conclude that gfortran is behaving as it should and that the > fact that ifort works - is somewhat a coincidence? Let's see what the gfortran developers have to say about this. In any case it looks strange if you try to call an init routine from a different TBP of the same object. An init routine is usually called only at the very instantiation of the object. If you want a shallow copy then you need a pointer.
[Bug fortran/101199] program changes the value of a dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199 Jürgen Reuter changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #3 from Jürgen Reuter --- I think that indeed this is not something the compiler needs to do as expected, as it is an aliasing problem. In the advance TBP you are calling again the init routine. The init routines sets the value of this%var1 to the argument with which it is called. In this%advance you are calling the init routine with the argument this%var1. However, in the init routine, the struct1 type is intent(out), so it is not guaranteed that the value of struct1%var1 is accessible when calling the init routine from an earlier initialization of that type. That is the aliasing problem: advance calls the init routine, the init routine creates a new instance of struct1 and you are not guaranteed that you can access the struct1%var1 component. There are several ways out: (1) define this in the init routine as intent(inout), very unusual for an initializer, but then gfortran does what you expect (2) define a global instance of struct1 in the module, e.g. type(original_struct), save, public :: struct_global and in advance then call the (before initialized) this%init(struct_global%var1)
[Bug fortran/86206] ICE in gfc_resolve_forall, at fortran/resolve.c:9989
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86206 --- Comment #4 from Jürgen Reuter --- Still present in v12.0.
[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881 --- Comment #5 from Jürgen Reuter --- I checked again, and I don't see any issues any more. There might still be some memory leaks, I haven't checked. Would it make sense to close this one and open a new report in case there is a definite reproducer?
[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 --- Comment #8 from Jürgen Reuter --- (In reply to Iain Sandoe from comment #6) > > 1. (re-)install xcode 12.4 command line tools and select them for use > 2. disable debug comparison in the bootstrap ( --without-build-config ) Just to report that --without-build-config did successfully compile and bootstrap.
[Bug bootstrap/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 --- Comment #4 from Jürgen Reuter --- (In reply to Dominique d'Humieres from comment #3) > Confirmed. Merci, Dominique. Would you actually advise to compile without bootstrap and start using gcc, or wait until the reason for the bootstrap failure is understood and hopefully fixed?
[Bug bootstrap/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 --- Comment #2 from Jürgen Reuter --- I just check, with --disable-bootstrap, gcc compiles to the end. Just the checksums of the object files for bootstrap between stage 2 and 3 don't agree.
[Bug bootstrap/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 --- Comment #1 from Jürgen Reuter --- After update to macOS Big Sur 11.3 with XCode 12.5 and Apple Clang clang-1205.0.22.9, bootstrap doesn't work any more: Comparing stages 2 and 3 warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1objplus-checksum.o differs Bootstrap comparison failure! gcc/tree-ssa-operands.o differs gcc/tree-ssanames.o differs [...] lib/libz_a-deflate.o differs zlib/libz_a-gzread.o differs zlib/libz_a-inflate.o differs zlib/libz_a-crc32.o differs zlib/libz_a-inftrees.o differs
[Bug bootstrap/100340] New: Bootstrap fails with Clang 12.0.5 (XCode 12.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 Bug ID: 100340 Summary: Bootstrap fails with Clang 12.0.5 (XCode 12.5) Product: gcc Version: 11.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: ---
[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602 --- Comment #36 from Jürgen Reuter --- I can confirm that the push by Paul, 297363774e6a5dca2f46a85ab086f1d9e59431ac, does fix all compilations and tests in our code and test suite.
