[Bug fortran/103368] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15668 since r12-4464-g017665f63047ce47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103368 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #6) > Created attachment 58277 [details] > Fix for this PR > > This was substantially fixed on 14-branch by the patch for PR49213. However, > there have been many subsequent changes to gfc_trans_structure_assign and > its subsidiary functions as the attachment demonstrates. > > I haven't attempted to do any weeding of the changes to separate those > responsible for fixing this PR. However, 13-branch regtests successfuly with > the patch applied. > > Should I commit this with a testcase or just close the PR? > > Paul Paul, can you summarize where you gathered the pieces of this patch from? >From a quick glance, r14-870 and r14-2160 (both yours) seem to be involved. Does it also fix any of the issues addressed by the respective PRs?
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.4 --- Comment #16 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #14) > Backporting to 13-branch requires backporting of r14-5931-gb247e917ff1332, > see pr110415. After a successful backport of the above, the present patch also applied smoothly to 13-branch. Closing. Thanks for the report!
[Bug fortran/110415] (Re)allocation on assignment to allocatable polymorphic variable from allocatable polymorphic function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110415 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |13.4 --- Comment #8 from anlauf at gcc dot gnu.org --- Backported to 13-branch after encouragement by Tobias off-list.
[Bug fortran/115193] using indices with character type within a select type causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115193 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED Keywords|wrong-code |ice-on-valid-code --- Comment #2 from anlauf at gcc dot gnu.org --- This bug has already been reported as pr114874 and just been fixed last week. *** This bug has been marked as a duplicate of bug 114874 ***
[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||ryan.mulhall at noaa dot gov --- Comment #12 from anlauf at gcc dot gnu.org --- *** Bug 115193 has been marked as a duplicate of this bug. ***
[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107
--- Comment #14 from anlauf at gcc dot gnu.org ---
(In reply to Natalie Perlin from comment #9)
> All rebuilt, gnu/14.1.0 with openmpi/4.1.6, revised configuration of the
> software stack (spack-stack). Still the same error with
> [-Wimplicit-function-declaration].
>
> Verified a build of the same stack with gnu/13.2.0 and openmpi/4.1.6. The
> same location in the code gives warning, instead of the error, during the
> build. Same package, different version of gcc. Please see below snippets of
> the builds:
>
> 1. Build with gnu/13.2.0 gives the following:
> ---
> ...
> /scratch2/NCEPDEV/stmp1/role.epic/spack-stack/spack-stack-1.6.0/spack/lib/
> spack/env/gcc/gcc -DHAVE_CONFIG_H -I. -I.
> -I../../../src/libjasper/include/jasper -I../../../src/libjasper/include -g
> -O2 -MT jas_getopt.lo -MD -MP -MF .deps/jas_getopt.Tpo -c jas_getopt.c -o
> jas_getopt.o
> jas_getopt.c: In function 'jas_getopt':
> jas_getopt.c:129:49: warning: implicit declaration of function
> 'jas_eprintf'; did you mean 'vsnprintf'? [-Wimplicit-function-declaration]
> 129 | jas_eprintf("unknown
> long option %s\n", s);
> | ^~~
> | vsnprintf
> ...
> ---
>
> 2. Build with gnu/14.1.0 gives the following:
> ---
> ...
> /scratch2/NCEPDEV/stmp1/role.epic/spack-stack/spack-stack-1.6.0_gnu14/spack/
> lib/spack/env/gcc/gcc -DHAVE_CONFIG_H -I. -I.
> -I../../../src/libjasper/include/jasper -I../../../src/libjasper/include -g
> -O2 -MT jas_getopt.lo -MD -MP -MF .deps/jas_getopt.Tpo -c jas_getopt.c -o
> jas_getopt.o
> jas_getopt.c: In function 'jas_getopt':
> jas_getopt.c:129:49: error: implicit declaration of function 'jas_eprintf';
> did you mean 'vsnprintf'? [-Wimplicit-function-declaration]
> 129 | jas_eprintf("unknown
> long option %s\n", s);
> | ^~~
> | vsnprintf
> make[4]: *** [Makefile:349: jas_getopt.lo] Error 1
> ...
> ---
>
> Any suggestions?..
The original jasper files look fine to me:
https://github.com/jasper-software/jasper/blob/master/src/libjasper/base/jas_getopt.c
which includes
https://github.com/jasper-software/jasper/blob/master/src/libjasper/include/jasper/jas_debug.h
Looks like spack either does not generate proper include paths, or a
bad include file is found.
> Has a version of gnu/13.3.0 become available that might have the ICE fix?..
See https://gcc.gnu.org/gcc-13/ .
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #14 from anlauf at gcc dot gnu.org --- Backporting to 13-branch requires backporting of r14-5931-gb247e917ff1332, see pr110415.
[Bug fortran/110415] (Re)allocation on assignment to allocatable polymorphic variable from allocatable polymorphic function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110415 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Andrew Jenner from comment #5) > Fixed on mainline and OG13. I will apply the commit to GCC 13 after the > grace period. This never happened... Are you still planning to do it?
[Bug fortran/115039] Statement function with inquiry refs rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115039 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |13.4 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed in gcc-15, and backported to 14.2 and 13.4.
[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Natalie Perlin from comment #6)
> (In reply to anlauf from comment #3)
> > The traceback is essentially identical to that in pr114467.
> >
> > Can you please try the 14-release like the other reporter, or the upcoming
> > 13.3 release next week?
>
> Thank you for the comment. Yes, this indeed looks similar to pr114467.
> I did try to use gnu/14.1.0 + openmpi/4.1.6, but was not able to build a
> software stack needed for building the model that produced the original
> error.
>
> The issue with the gnu/14.1.0 compiler was that it produced an error where
> the gnu/13.2.0 had only a warning. The error with the gnu/14.1.0 compiler
> was as shown below, and is related to -Wimplicit-function-declaration.
> Could it be that a certain compiler flag helps to avoid such an error?..
>
>
> And yes, I'd gladly try the upcoming v13.3 release next week!
>
>
> ===
> /scratch2/NCEPDEV/stmp1/role.epic/spack-stack/spack-stack-1.6.0_gnu14/spack/
> lib/spack/env/gcc/gcc -DHAVE_CONFIG_H -I. -I.
> -I../../../src/libjasper/include/jasper -I../../../src/libjasper/include -g
> -O2 -MT jas_getopt.lo -MD -MP -MF .deps/jas_getopt.Tpo -c jas_getopt.c -o
> jas_getopt.o
> jas_getopt.c: In function 'jas_getopt':
> jas_getopt.c:129:49: error: implicit declaration of function 'jas_eprintf';
> did you mean 'vsnprintf'? [-Wimplicit-function-declaration]
> 129 | jas_eprintf("unknown
> long option %s\n", s);
> | ^~~
> | vsnprintf
> make[4]: *** [Makefile:349: jas_getopt.lo] Error 1
> =
This looks like the header file jas_debug.h is not found or not included.
(On my Linux system it is /usr/include/jasper/jas_debug.h).
[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107 --- Comment #3 from anlauf at gcc dot gnu.org --- The traceback is essentially identical to that in pr114467. Can you please try the 14-release like the other reporter, or the upcoming 13.3 release next week?
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||clange001 at gmail dot com --- Comment #15 from anlauf at gcc dot gnu.org --- *** Bug 106317 has been marked as a duplicate of this bug. ***
[Bug fortran/106317] deferred-length character array pointer in derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106317 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #1) > Confirmed to fail on 13-branch at r13-7813, but working at r13-8592. > > Also 14-mainline is ok, so must have been fixed there and backported, > possibly as r13-7986. Indeed a duplicate of 67740. Thus fixed in 13.3 and later. *** This bug has been marked as a duplicate of bug 67740 ***
[Bug fortran/86100] Spurious error with -fcheck=bounds and allocatable class(*) array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86100 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Keywords||wrong-code --- Comment #4 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-May/060512.html
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070 --- Comment #2 from anlauf at gcc dot gnu.org --- Replacing the scalar argument 'obs' by something with rank > 0 avoids the ICE, but then assumed-rank is not accepted with intent(out). Another bug...
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||12.3.1 Ever confirmed|0 |1 Target Milestone|--- |13.3 Priority|P3 |P4 Last reconfirmed||2024-05-13 Known to fail||13.2.1, 14.1.0, 15.0 Summary|ICE using IEEE_ARITHMETIC |[13/14/15 Regression] ICE |in a derived type method|using IEEE_ARITHMETIC in a |with intent(out) statement |derived type method with ||class, intent(out) Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed as a regression. 12-branch works here, current 13-branch fails. Replacing class by type also avoids the ICE.
[Bug fortran/115072] Memory leak with unlimited polymorphic function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115072 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|Memory link with unlimited |Memory leak with unlimited |polymorphic function result |polymorphic function result Priority|P3 |P4 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org Last reconfirmed||2024-05-13 --- Comment #1 from anlauf at gcc dot gnu.org --- Runtime memleak confirmed, also seen with -fsanitize=address . Affects all versions up to 15-mainline.
[Bug fortran/115039] Statement function with inquiry refs rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115039 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-May/060500.html
[Bug fortran/115039] Statement function with inquiry refs rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115039 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Keywords||rejects-valid
[Bug fortran/115039] New: Statement function with inquiry refs rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115039 Bug ID: 115039 Summary: Statement function with inquiry refs rejected Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- As reported in: https://fortran-lang.discourse.group/t/real-and-imaginary-parts-of-complex-number/1113/18 an inquiry reference (%re, %im) is incorrectly reported as a recursive reference. Testcase: program testit implicit none complex :: x real:: img img(x) = x%im write (*, *) img((1.0,3.0) + (2.0,4.0)) end program testit Tentative fix: diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc index 66edad58278..94ec2ce21dd 100644 --- a/gcc/fortran/expr.cc +++ b/gcc/fortran/expr.cc @@ -5500,7 +5546,8 @@ gfc_traverse_expr (gfc_expr *expr, gfc_symbol *sym, break; case REF_INQUIRY: - return true; + /* An inquiry_ref does not collide with a symbol. */ + return false; default: gcc_unreachable ();
[Bug fortran/86100] Spurious error with -fcheck=bounds and allocatable class(*) array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86100 --- Comment #3 from anlauf at gcc dot gnu.org --- The code fragment in comment#2 was added in r7-3760-g92c5266bbd5378.
[Bug fortran/86100] Spurious error with -fcheck=bounds and allocatable class(*) array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86100
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
The problem seems to generally occur for class components of derived types.
program p
implicit none
type t
integer :: i = 0
end type t
type any_matrix
class(t), allocatable :: m(:,:)
end type any_matrix
type(any_matrix) :: a, b
allocate(a%m(3,4))
call foo ()
contains
subroutine foo ()
b = a ! Array bound mismatch for dimension 1 of array '<>'
(12/3)
!b%m = a%m ! no runtime error with -fcheck=bounds
end subroutine foo
end
This fails as indicated.
Note that 12=3*4 is the total size of the array, and 3 is the size of the
first dimension, which - along with the '<>' - points to
gfc_copy_class_to_class:
from_len = gfc_conv_descriptor_size (from_data, 1);
from_len = fold_convert (TREE_TYPE (orig_nelems), from_len);
tmp = fold_build2_loc (input_location, NE_EXPR,
logical_type_node, from_len, orig_nelems);
msg = xasprintf ("Array bound mismatch for dimension %d "
"of array '%s' (%%ld/%%ld)",
1, name);
gfc_trans_runtime_check (true, false, tmp, ,
_current_locus, msg,
fold_convert (long_integer_type_node,
orig_nelems),
fold_convert (long_integer_type_node,
from_len));
So we compare dimension 1 and the full size of the rhs?
Shouldn't we compare lhs and rhs shapes?
[Bug fortran/114922] fsyntax-only need the modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from anlauf at gcc dot gnu.org --- The documentation says: -fsyntax-only Check the code for syntax errors, but do not actually compile it. This will generate module files for each module present in the code, but no other output file. So if you do not provide the needed modules, you should get exactly the same errors as when compiling without -fsyntax-only.
[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Adding Paul, hoping that he can tell what changed for SELECT TYPE recently.
[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 --- Comment #2 from anlauf at gcc dot gnu.org --- The dump-fortran-original shows the following difference between 13 and 14: @@ -58,7 +58,7 @@ code: ASSIGN p:c 'abc' - BLOCK + SELECT TYPE symtree: '__tmp_CHARACTER_0_1'|| symbol: '__tmp_CHARACTER_0_1' type spec : (CHARACTER () 1) attributes: (VARIABLE SELECT-TYPE-TEMPORARY ASSOCIATE-VAR) @@ -66,7 +66,7 @@ type spec : (UNKNOWN 0) attributes: (LABEL ) -SELECT TYPE _loc[((p:c % _vptr))] +SELECT CASE _loc[((p:c % _vptr))] CASE (_loc[((p:__vtab_CHARACTER_1_))] 85893463) ASSOCIATE = p:c % _data @@ -74,11 +74,11 @@ type spec : (UNKNOWN 0) attributes: (LABEL ) WRITE UNIT=6 FMT=-1 - TRANSFER block@1:__tmp_CHARACTER_0_1(2:2) + TRANSFER block@1:__tmp_CHARACTER_0_1(UNKNOWN) DT_END END ASSOCIATE END SELECT - END BLOCK + END SELECT TYPE CONTAINS
[Bug fortran/114859] [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code --- Comment #17 from anlauf at gcc dot gnu.org --- For reference: the commit is r15-46-gbca41a8d55e830 commit bca41a8d55e830c882b0f39246afead4fcfae6f7 Author: Paul Thomas Date: Mon Apr 29 11:52:11 2024 +0100 Fortran: Fix regression caused by r14-9752 [PR114959] 2024-04-29 Paul Thomas gcc/fortran PR fortran/114959 * trans-expr.cc (gfc_trans_class_init_assign): Return NULL_TREE if the default initializer has all NULL fields. Guard this by a requirement that the code not be EXEC_INIT_ASSIGN and that the object be an INTENT_OUT dummy. * trans-stmt.cc (gfc_trans_allocate): Change the initializer code for allocate with mold to EXEC_ALLOCATE to allow an initializer with all NULL fields. gcc/testsuite/ PR fortran/114959 * gfortran.dg/pr114959.f90: New test.
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #11 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-April/060464.html
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #58048|0 |1 is obsolete|| Attachment #58056|0 |1 is obsolete|| Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #9 from anlauf at gcc dot gnu.org --- Created attachment 58061 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58061=edit Corrected patch This fixes the issue for scalar and array assignments and does not regress on intrinsic types when compiling with -fsanitize=address.
[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 --- Comment #1 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #0) > The following code fails for me with latest 14-branch/15-release candidate: Oops, I meant: 14-release candidate/15-mainline after branching...
[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||10.5.0, 11.4.1, 12.3.1, ||13.2.1 Keywords||ice-on-valid-code Priority|P3 |P4
[Bug fortran/114874] New: [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 Bug ID: 114874 Summary: [14/15 Regression] ICE with select type, type is (character(*)), and substring Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- The following code fails for me with latest 14-branch/15-release candidate: program p implicit none class(*), allocatable :: c c = 'abc' select type (c) type is (character(*)) print *, c print *, c(2:2) ! ICE end select end p __copy_character_1hhh.f90:8:22: 8 | print *, c(2:2) ! ICE | 1 internal compiler error: Segmentation fault 0x10c6f6f crash_signal ../../gcc-14/gcc/toplev.cc:319 0xa7e6f1 gfc_conv_scalarized_array_ref ../../gcc-14/gcc/fortran/trans-array.cc:3938 0xa7f596 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*) ../../gcc-14/gcc/fortran/trans-array.cc:4094 0xac25ea gfc_conv_variable ../../gcc-14/gcc/fortran/trans-expr.cc:3181 0xac5be2 gfc_conv_expr_reference(gfc_se*, gfc_expr*) ../../gcc-14/gcc/fortran/trans-expr.cc:9935 0xaf00b6 gfc_trans_transfer(gfc_code*) ../../gcc-14/gcc/fortran/trans-io.cc:2609 0xa73157 trans_code ../../gcc-14/gcc/fortran/trans.cc:2583 0xaed036 build_dt ../../gcc-14/gcc/fortran/trans-io.cc:2053 0xa73177 trans_code ../../gcc-14/gcc/fortran/trans.cc:2555 0xb1471f gfc_trans_block_construct(gfc_code*) ../../gcc-14/gcc/fortran/trans-stmt.cc:2377 0xa73337 trans_code ../../gcc-14/gcc/fortran/trans.cc:2459 0xb0abf7 gfc_trans_select_type_cases ../../gcc-14/gcc/fortran/trans-stmt.cc:3020 0xb15ff4 gfc_trans_select_type(gfc_code*) ../../gcc-14/gcc/fortran/trans-stmt.cc:3729 0xa730a7 trans_code ../../gcc-14/gcc/fortran/trans.cc:2479 0xb1471f gfc_trans_block_construct(gfc_code*) ../../gcc-14/gcc/fortran/trans-stmt.cc:2377 0xa73337 trans_code ../../gcc-14/gcc/fortran/trans.cc:2459 0xaa8ed1 gfc_generate_function_code(gfc_namespace*) ../../gcc-14/gcc/fortran/trans-decl.cc:7880 0xa1b65f translate_all_program_units ../../gcc-14/gcc/fortran/parse.cc:7099 0xa1b65f gfc_parse_file() ../../gcc-14/gcc/fortran/parse.cc:7413 0xa6fe7f gfc_be_parse_file ../../gcc-14/gcc/fortran/f95-lang.cc:241
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #8 from anlauf at gcc dot gnu.org --- Created attachment 58056 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58056=edit Patch part 2. This part fixes the array case. Needs further testing.
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- Created attachment 58048 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58048=edit Partial patch This patch fixes the scalar case in comment#0 by computing _size*_len and regtests cleanly. It does not cover the array case.
[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102620 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #13 from anlauf at gcc dot gnu.org --- Also fixed on 12-branch: commit r12-10398-gb482968801158116dd8ba3b15a4c29143b2a423a Author: Paul Thomas Date: Tue May 23 06:46:37 2023 +0100 Fortran: Fix assumed length chars and len inquiry [PR103716] 2023-05-23 Paul Thomas gcc/fortran PR fortran/103716 * resolve.cc (gfc_resolve_ref): Conversion of array_ref into an element should be done for all characters without a len expr, not just deferred lens, and for integer expressions. * trans-expr.cc (conv_inquiry): For len and kind inquiry refs, set the se string_length to NULL_TREE. gcc/testsuite/ PR fortran/103716 * gfortran.dg/pr103716.f90 : New test. (cherry picked from commit 842a432b02238361ecc601d301ac400a7f30f4fa) The ICE is gone. A remaining accepts-invalid on 11-branch could be fixed by backporting the above if needed. Thanks for the report to Gerhard, and to Paul for the above patch. Closing.
[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102620 --- Comment #12 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #11) > It would be splendid if you would backport the patch. In the last week or > so, I have built up quite a list of backports to do, which I will attend to > over the weekend. Hi Paul, I've checked and found that your r14-1082-g842a432b022383 also needs to be backported to get all testcases here fixed on 12-branch. When regtesting completes successfully, I will push it.
[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102620 --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #9) > (In reply to anlauf from comment #8) > > I get the same behavior at r13-8559 as 14-mainline. There seems to be > > another commit that fixed it independently. > > > > Removing 13-branch from the regression list. > > Mark as fixed or backport fixes? Either I did something wrong, or the bug reappeared on 13-branch... Anyway, I tried backporting Andre's patch to 13- and 12-branch. Works fine and regtests fine. How to proceed? I can push those changes, so that we are finally done with this PR.
[Bug fortran/114815] internal compiler error: Segmentation fault - on creating type with len parameter and dependent on it character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114815 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed||2024-04-24 Priority|P3 |P4 --- Comment #2 from anlauf at gcc dot gnu.org --- The code in comment#0 is invalid. Intel: pr114815.f90(5): error #8737: For a default initialized component every type parameter and array bound must be a constant expression. [GENDERS] end type Student_Group ^ NAG: Error: pr114815.f90, line 4: Type STUDENT_GROUP default-initialised component GENDERS has a non-constant array bound Errors in declarations, no further processing for LAB_1_4 When commenting the default initialization, the code compiles with gfortran.
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2024-04-24
Keywords||wrong-code
--- Comment #5 from anlauf at gcc dot gnu.org ---
Confirmed.
Two data points which give a hint what might be wrong:
1) the valgrind error count at runtime depends on the string length passed
to foo. I get no errors for a string of length 1.
2) the dump-tree of subroutine foo looks suspicious:
if (b->_data == 0B)
{
b->_data = __builtin_malloc (MAX_EXPR <(unsigned long)
rhs.1._vptr->_size, 1>);
It looks like _size comes from:
static struct __vtype_CHARACTER_1_ __vtab_CHARACTER_1_ = {._hash=85893463,
._size=1, ._extends=0B, ._def_init=0B, ._copy=__copy_character_1, ._final=0B};
and is always 1. On the other hand, subroutine run sets:
class.2._vptr = (struct __vtype__STAR * {ref-all})
&__vtab_CHARACTER_1_;
class.2._data = (void *) &"fubarfubarfubarfubarfubarfu"[1]{lb: 1 sz:
1};
class.2._len = 27;
but _len is used in foo for the _copy, but not for the allocation.
Thus the size allocated needs to be fixed.
Changing the character argument to use kind=4, I see that _size seems to
represent the element size.
The allocation size thus should be changed to (_size * _len).
Need to find the place where this happens... Anyone?
[Bug fortran/103496] [F2018][TS29113] C_SIZEOF – rejects now valid args with 'must be an interoperable data entity'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103496 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from anlauf at gcc dot gnu.org --- Pushed testcase. Closing.
[Bug fortran/102597] ICE in gfc_get_extern_function_decl, at fortran/trans-decl.c:2243 since r8-3365-gb89a63b916340ef2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102597 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||10.5.0, 11.4.1, 12.3.1 Status|NEW |WAITING Known to work||13.2.1, 14.0 --- Comment #2 from anlauf at gcc dot gnu.org --- Works on 14-mainline, and on 13-branch since at least r13-8285. Likely due to one of the associate-fixes. Updating known-to-work and known-to-fail. In principle this bug has been fixed and could be closed.
[Bug fortran/54389] [F2003/F2008 difference] PURE functions and pointer dummy arguments / DECL_PURE_P issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54389 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #6) > Compiling the test in comment 0 still gives the error > > ptr = ptr + 1 > 1 > Error: Variable 'ptr' can not appear in a variable definition context > (assignment) at (1) in PURE procedure > > at revision r229078 (trunk 6.0). That error looks correct to me. NAG rejects the code as well for any INTENT. To reconfirm: F2023 has "C15104 In a pure subprogram any designator with a base object that [...] is a pointer dummy argument of a pure function [...] shall not be used (1) in a variable definition context" There is no restriction on the INTENT of the pointer dummy. See also Note 4, 2nd paragraph for reasoning supporting this. Can we close this bug as fixed?
[Bug fortran/114781] Error in ALLOCATE with MOLD=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114781 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-04-19 CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Interestingly, replacing the lines ALLOCATE(arr(1), mold=sample) ! with localsample here it works CALL MOVE_ALLOC(arr, tmparr) by ALLOCATE(tmparr(1), mold=sample) which should be equivalent - the code works fine. The tree-dump for the MOVE_ALLOC part looks as if it misses a _len component that is otherwise set by the ALLOCATE. Not sure if that is relevant, but this is the first thing that caught my attention.
[Bug fortran/103471] [11/12/13/14 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103471
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #6)
> The current mainline and 13-branches now power through to the fatal error at
> trans-decl.cc:1800.
True, but the location does not look nice:
pr103471.f90:1:9:
1 | program p
| 1
Fatal Error: k at (1) has no default type
compilation terminated.
With the following tentative - but otherwise untested - change:
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index e160c5c98c1..602f35f0cab 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -1797,7 +1797,9 @@ gfc_get_symbol_decl (gfc_symbol * sym)
}
if (sym->ts.type == BT_UNKNOWN)
-gfc_fatal_error ("%s at %C has no default type", sym->name);
+//gfc_fatal_error ("%s at %C has no default type", sym->name);
+gfc_fatal_error ("%s at %L has no default type", sym->name,
+>declared_at);
if (sym->attr.intrinsic)
gfc_internal_error ("intrinsic variable which isn't a procedure");
we are back at:
pr103471.f90:3:21:
3 |print *, [real(x(k))]
| 1
Fatal Error: k at (1) has no default type
compilation terminated.
This looks more user friendly.
[Bug fortran/114739] [14 Regression] ice in gfc_find_derived_types, at fortran/symbol.cc:2458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- We're running into code in primary.cc modified at r14-9489-g3fd46d859cda10 which checks for inquiry references. CC'ing Paul.
[Bug fortran/114739] [14 Regression] ice in gfc_find_derived_types, at fortran/symbol.cc:2458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739 --- Comment #4 from anlauf at gcc dot gnu.org --- Reduced testcase: program main implicit complex(z) z2%re = 1. z2%im = 2. end
[Bug fortran/113793] malloc abort on character allocate with source argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14. Thanks for the report!
[Bug fortran/114467] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114467 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to thomas from comment #3) > (In reply to anlauf from comment #1) > > Can you attached a self-contained reproducer? > > > > The traceback looks familiar. Are you by chance using an associate > > construct? There has been a fix backported from 14-mainline to 13-branch > > after the release of 13.2, so it might have been fixed in the meantime. > > > > (Likely a dup of pr109948). > > Just to be on the safe side, would gcc 13.2.0 from 2023-07-27 be the right > version to test? No. The backport was applied to 13-branch on 2023-08-27. I'd recommend to use a more recent snapshot of 13-branch.
[Bug fortran/114739] [14 Regression] ice in gfc_find_derived_types, at fortran/symbol.cc:2458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code, ||rejects-valid Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P4 Last reconfirmed||2024-04-16 --- Comment #3 from anlauf at gcc dot gnu.org --- We fail to figure out that z2 is complex. Adding complex z2 avoid the issues. Not really a regression except for the ICE, since we falsely rejected the code up to 13.
[Bug fortran/95682] [11/12 Regression] Default assignment fails with allocatable array of deferred-length strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95682 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||13.2.1, 14.0 Summary|[11/12/13/14 Regression]|[11/12 Regression] Default |Default assignment fails|assignment fails with |with allocatable array of |allocatable array of |deferred-length strings |deferred-length strings Known to fail||12.3.0 Keywords||wrong-code --- Comment #7 from anlauf at gcc dot gnu.org --- Works on 14-mainline and on 13-branch (at r13-8285 and newer). Adjusting known-to work/known-to-fail versions.
[Bug fortran/113793] malloc abort on character allocate with source argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-April/060431.html
[Bug fortran/113793] malloc abort on character allocate with source argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Priority|P3 |P4
[Bug fortran/113793] malloc abort on character allocate with source argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #57931|0 |1 is obsolete|| --- Comment #4 from anlauf at gcc dot gnu.org --- Created attachment 57938 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57938=edit Enhanced patch This version add checks for standard conformance and a runtime check for equal length.
[Bug fortran/103496] [F2018][TS29113] C_SIZEOF – rejects now valid args with 'must be an interoperable data entity'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103496 --- Comment #5 from anlauf at gcc dot gnu.org --- Created attachment 57937 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57937=edit c_sizeof_8.f90 Here's a testcase derived from comment#0. Feel free to adapt it to your meet your needs, and push it.
[Bug fortran/113793] malloc abort on character allocate with source argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #57354|0 |1 is obsolete|| --- Comment #3 from anlauf at gcc dot gnu.org --- Created attachment 57931 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57931=edit Improved patch This patch fixes both the scalar and the array variants. Needs regtesting.
[Bug fortran/106500] ICE on function as an argument to c_sizeof()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106500 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14.
[Bug fortran/103496] [F2018][TS29113] C_SIZEOF – rejects now valid args with 'must be an interoperable data entity'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103496 --- Comment #3 from anlauf at gcc dot gnu.org --- The code in comment#0 compiles at r14-9893-gded646c91d2c0f and gives the indicated results.
[Bug fortran/114626] Very long time for compilation the attached program, depends on value of a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114626 --- Comment #3 from anlauf at gcc dot gnu.org --- Another option is to not declare max_sum as parameter but as variable. With integer :: max_sum = 2 * max_ij ** 3 the code compiles almost instantly, but it has noticeable runtime. (But it performs much better here than with Intel... :)
[Bug fortran/106500] ICE on function as an argument to c_sizeof()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106500 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-April/060419.html
[Bug fortran/106500] ICE on function as an argument to c_sizeof()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106500
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> What is unclear to me: when is an expression interoperable?
> Or rather when is it *not*?
>
> (Note that the standard text has not essentially changed since F2008,
> so we got this too strict from the beginning.)
Actually the following interp is very helpful:
https://j3-fortran.org/doc/year/22/22-101r1.txt
And while working on a fix, I found the following invalid code ICEing:
subroutine s ()
use, intrinsic :: iso_c_binding
implicit none
type(c_ptr) :: cPtr
call c_f_pointer (cPtr, p0)! { dg-error "function returning a
pointer" }
call c_f_pointer (cPtr, p1, shape=[2]) ! { dg-error "function returning a
pointer" }
contains
function p0 ()
integer, pointer :: p0
nullify (p0)
end
function p1 ()
integer, pointer :: p1(:)
nullify (p1)
end
end
[Bug fortran/106317] deferred-length character array pointer in derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106317 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||10.5.0, 11.4.1, 12.3.0, ||13.2.0 Priority|P3 |P4 CC||anlauf at gcc dot gnu.org Known to work||14.0 Keywords||wrong-code --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed to fail on 13-branch at r13-7813, but working at r13-8592. Also 14-mainline is ok, so must have been fixed there and backported, possibly as r13-7986.
[Bug fortran/114626] Very long time for compilation the attached program, depends on value of a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114626 anlauf at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97571 Priority|P3 |P4 --- Comment #1 from anlauf at gcc dot gnu.org --- Note that pack( [ (k, k = 1,max_sum)], & [ ( count( [((i**3+j**3, i = 1,j), j = 1,max_ij)] == k ) > 1, k = 1,max_sum )] ) is a constant expression that the frontend tries to simplify at compile time. I assume that most of the time goes into handling of the array constructors. There's no limit implemented that checks the complexity of such expressions and to give up if that limit is reached. An expression like the above could occur in a parameter definition, and a limit then might terminate the compilation with an error. Fortunately, you've already found a workaround. For a related PR see pr97571.
[Bug fortran/114474] [11/12/13/14 Regression] DATA statement with derived type, pointer component rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114474 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from anlauf at gcc dot gnu.org --- Backported to all open branches. Closing.
[Bug fortran/89925] [11 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #17 from anlauf at gcc dot gnu.org --- Backported as r11-11310-gb755a7af1f2ef1: commit b755a7af1f2ef1f5348d04db20f751e898abcd9d Author: Chung-Lin Tang Date: Fri Dec 3 17:27:17 2021 +0800 fortran: Fix setting of array lower bound for named arrays This patch fixes a case of setting array low-bounds, found for particular uses of SOURCE=/MOLD=. This adjusts the relevant part in gfc_trans_allocate() to set e3_has_nodescriptor only for non-named arrays. 2021-12-03 Tobias Burnus gcc/fortran/ChangeLog: * trans-stmt.c (gfc_trans_allocate): Set e3_has_nodescriptor to true only for non-named arrays. gcc/testsuite/ChangeLog: * gfortran.dg/allocate_with_source_26.f90: Adjust testcase. * gfortran.dg/allocate_with_mold_4.f90: New testcase. (cherry picked from commit 6262e3a22b3d86afc116480bc59a7bb30b0cfd40) Closing.
[Bug libfortran/114618] Format produces incorrect output when contains 1x, ok when uses " "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618 anlauf at gcc dot gnu.org changed: What|Removed |Added Component|fortran |libfortran See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109358 --- Comment #1 from anlauf at gcc dot gnu.org --- Likely a dup of pr109358.
[Bug fortran/106500] ICE on function as an argument to c_sizeof()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106500
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
CC||anlauf at gcc dot gnu.org
--- Comment #4 from anlauf at gcc dot gnu.org ---
I've looked some time into this and have the impression we have the checks
wrong.
E.g. testcase gfortran.dg/c_sizeof_6.f90 expects as error:
gcc/testsuite/gfortran.dg/c_sizeof_6.f90:11:16:
11 |i = c_sizeof(str2(1:3)) ! { dg-error "must be an interoperable data"
}
|1
Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be an interoperable
data entity: Only whole-arrays are interoperable
First, other compilers accept the code (Intel, NAG, Nvidia, flang), and also
the other testcases in the PR, plus they give the expected answers.
Second, the standard has:
! F2023:18.2.3.8 C_SIZEOF (X)
!
! X shall be a data entity with interoperable type and type parameters,
! and shall not be an assumed-size array, an assumed-rank array that
! is associated with an assumed-size array, an unallocated allocatable
! variable, or a pointer that is not associated.
and
! 3.41 data entity
! data object, result of the evaluation of an expression, or the
! result of the execution of a function reference
So, array sections could be interoperable, expressions, function results.
What is unclear to me: when is an expression interoperable?
Or rather when is it *not*?
(Note that the standard text has not essentially changed since F2008,
so we got this too strict from the beginning.)
[Bug fortran/89925] [11 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925 --- Comment #16 from anlauf at gcc dot gnu.org --- BTW: r12-5767 backports cleanly to 11-branch and regtests cleanly. I could push it if there are no objections, so that we can finally close this one.
[Bug fortran/89925] [11/12/13/14 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #15 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #14) > (In reply to anlauf from comment #13) > > Original testcase is fixed for allocate with mold as well as for allocate > > with source, and some test coverage is in r12-5767. > > > > There are remaining issues for allocatable character arrays, but these > > are tracked elsewhere, e.g. pr113793. > > > > I suggest to close this one with target milestone 12.x > > Seems like a good idea. Do you believe that original > testcase should be converted to a testcase and committed? Only if something reasonable is tested *beyond* those added/modified in r12-5767: gcc/testsuite/gfortran.dg/allocate_with_source_26.f90 gcc/testsuite/gfortran.dg/allocate_with_mold_4.f90 So what is missing here?
[Bug fortran/89925] [11/12/13/14 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||12.3.0, 13.2.1, 14.0 Known to fail||10.5.0, 11.4.1 Status|NEW |WAITING --- Comment #13 from anlauf at gcc dot gnu.org --- Original testcase is fixed for allocate with mold as well as for allocate with source, and some test coverage is in r12-5767. There are remaining issues for allocatable character arrays, but these are tracked elsewhere, e.g. pr113793. I suggest to close this one with target milestone 12.x
[Bug fortran/104585] incorrect error for dummy arguments with both VALUE and DIMENSION attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104585 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Bill Long from comment #2) > Bug 102369 was closed as a duplicate of THIS bug. > > Has this been fixed in a more recent version of gfortran? No. We need only one entry for a bug.
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278 --- Comment #31 from anlauf at gcc dot gnu.org --- I've just checked the various comments. What's left: - comment#2 : the testcase still fails. See also comment#7 about the invalid partial initialization - lack of diagnostics of overlapping initialization There is also some overlap with pr50410. The ICEs appear fixed, in particular the one in comment#31.
[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |REOPENED --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #5) > (In reply to anlauf from comment #4) > > This PR has been fixed as part of the large commit r14-9489-g3fd46d859cda10 > > . > > Not here. As far as I can tell the results remain exactly the same for both > character and numeric results from 'foo'. Oops, I only checked that comment#0 is fixed (-> gfortran.dg/associate_66.f90) and overlooked the other case in comment#1. Reopening. Regarding ALLOCATE with SOURCE and CHARACTER, I have a partial patch for pr113793. Need to look again into that one.
[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #5)
> The pointers to expr->symtree is NULL. This new patch catches your example.
It does, but behaves weird for some other cases. Try:
program main
complex :: c = 1.
complex, parameter :: z = 1.
print *, atan(c,c)
print *, atan(z,z)
end
This gives now:
pr113412.f90:4:18:
4 | print *, atan(c,c)
| 1
Error: 'c' argument of 'atan' intrinsic at (1) must be the same type and kind
as 'c'
pr113412.f90:5:18:
5 | print *, atan(z,z)
| 1
Error: 'z' argument of 'atan' intrinsic at (1) must be the same type and kind
as 'z'
I wonder whether we can reuse existing checks for atan2 for the 2-argument
version of atan.
I tried the following:
diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index c35f2bdd183..261d4229139 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -4370,6 +4370,11 @@ sort_actual (const char *name, gfc_actual_arglist **ap,
if (a == NULL)
goto do_sort;
+ if ((gfc_option.allow_std & GFC_STD_F2008) != 0
+ && strcmp(name, "atan") == 0
+ && !gfc_check_atan_2 (actual->expr, actual->next->expr))
+return false;
+
whoops:
gfc_error ("Too many arguments in call to %qs at %L", name, where);
return false;
This is indeed sort of hackish and produces for testcase:
program main
complex :: c = 1.
print *, atan (c,c)
print *, atan2(c,c)
end
pr113412.f90:3:17:
3 | print *, atan (c,c)
| 1
Error: 'x' argument of 'atan' intrinsic at (1) must be REAL
pr113412.f90:4:17:
4 | print *, atan2(c,c)
| 1
Error: 'y' argument of 'atan2' intrinsic at (1) must be REAL
Note that the name of the formal argument is now wrong, probably because
the association of actuals with formals is missing.
[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477 Bug 87477 depends on bug 113363, which changed state. Bug 113363 Summary: ICE on ASSOCIATE and unlimited polymorphic function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|NEW |RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- This PR has been fixed as part of the large commit r14-9489-g3fd46d859cda10 .
[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102620 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[12/13 Regression] ICE in |[12 Regression] ICE in |gfc_get_array_span, at |gfc_get_array_span, at |fortran/trans-array.c:865 |fortran/trans-array.c:865 |since |since |r12-1233-gd514626ee2566c68 |r12-1233-gd514626ee2566c68 --- Comment #8 from anlauf at gcc dot gnu.org --- I get the same behavior at r13-8559 as 14-mainline. There seems to be another commit that fixed it independently. Removing 13-branch from the regression list.
[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #3) > Created attachment 57109 [details] > patch > > The attached patch has been regtested. There were no regression. Steve, I just tried your patch. While it fixes comment#0, it misses: print *, atan(1.d0,1.0) end I get as traceback: f951: internal compiler error: Segmentation fault 0x1121b3f crash_signal ../../gcc-trunk/gcc/toplev.cc:319 0x9cde02 sort_actual ../../gcc-trunk/gcc/fortran/intrinsic.cc:4381 0x9ceac2 check_specific ../../gcc-trunk/gcc/fortran/intrinsic.cc:4795 0x9cf2f0 gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc-trunk/gcc/fortran/intrinsic.cc:5067 0xa350b1 resolve_unknown_f ../../gcc-trunk/gcc/fortran/resolve.cc:3039 0xa47ff0 resolve_function ../../gcc-trunk/gcc/fortran/resolve.cc:3396 0xa46df9 gfc_resolve_expr(gfc_expr*) ../../gcc-trunk/gcc/fortran/resolve.cc:7526 0xa5bc46 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.cc:12619 0xa5d0b2 gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.cc:11432 0xa5bbfe gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.cc:12609 0xa5ec88 resolve_codes ../../gcc-trunk/gcc/fortran/resolve.cc:18463 0xa4080b gfc_resolve(gfc_namespace*) ../../gcc-trunk/gcc/fortran/resolve.cc:18498 0xa26806 resolve_all_program_units ../../gcc-trunk/gcc/fortran/parse.cc:7034 0xa26ffd gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.cc:7290 0xa8f6df gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.cc:241
[Bug fortran/103368] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15668 since r12-4464-g017665f63047ce47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103368 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||14.0 Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE |ICE in gimplify_expr, at|in gimplify_expr, at |gimplify.c:15668 since |gimplify.c:15668 since |r12-4464-g017665f63047ce47 |r12-4464-g017665f63047ce47 --- Comment #4 from anlauf at gcc dot gnu.org --- Seems to ICE no longer at r14-9759, but 13-branch and older still fail. Adjusting summary. But is it really invalid code? Intel and NAG accept it.
[Bug fortran/113956] [13/14 Regression] ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956 --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #4) > (In reply to Paul Thomas from comment #3) > > I can see why the assert is there but it is manifestly wrong for both the > > assumed length target and a constant length. > > That's why I wanted to pass this on to you. I am not sure what the precise > logic should be. > > > I was thrown a bit by the > > distros nulling out the asserts so that it compiled just fine with the > > system gfortran. > > If the system gfortran is based on 13.2 *release* then the bug is not yet > there ;-) It entered 13-branch through backport r13-7986. > > > Your patch is perfect :- This compiles and runs correctly: Paul, if you want to commit the patch, consider it preapproved :-) Otherwise I would take it, but I fear possible subtleties in the logic involved that I do not see...
[Bug fortran/99852] Missing error "Arithmetic overflow" for some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99852 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org Last reconfirmed||2024-04-02 --- Comment #3 from anlauf at gcc dot gnu.org --- Confirming at last. Another testcase from pr104848#c1: program p integer, parameter :: a(2, 0) = 0 integer, parameter :: y(*) = minval(a, dim=2) print *, y ! no ICE print *, y-1 ! no ICE print *, y+1 ! ICE end
[Bug fortran/99852] Missing error "Arithmetic overflow" for some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99852 --- Comment #2 from anlauf at gcc dot gnu.org --- *** Bug 104848 has been marked as a duplicate of this bug. ***
[Bug fortran/104848] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104848 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #8 from anlauf at gcc dot gnu.org --- The remaining issues are covered by pr99852. *** This bug has been marked as a duplicate of bug 99852 ***
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|anlauf at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #22 from anlauf at gcc dot gnu.org --- Mikael, since you did the essential work and commit, I am reassigning to you.
[Bug fortran/106987] [11/12/13/14 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|11.5|13.3 Resolution|--- |FIXED --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to paul.richard.tho...@gmail.com from comment #8) > Hi Harald, > > After a lot of messing around, I managed to backport the patch; essentially > by hand. However, two of the testcases ICEd in trans-array.cc and so there > were obviously dependences that I had missed. > > I will not be backporting r14-1629, if for no other reason than it is not a > regression but also because the amount of work that would be involved > doesn't warrant it. It's a pity that I didn't keep 13-branch up to speed > with mainline on the associate fixes but we will just have to live with it > now. Hi Paul, no problem, I manually removed the conflict and pushed after regtesting. Thanks for trying! As I said before, I will close this one as fixed with target milestone 13.3, as it does not make sense to try to backport all needed dependencies to 12, and this one is an ICE-on-invalid. @Gerhard: thanks for the report!
[Bug fortran/103707] Stray "Array operands are incommensurate"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #10 from anlauf at gcc dot gnu.org --- I think the main issues are fixed for gcc-14 and on 13-branch. The "Division by zero" errors can be suppressed with -fno-range-check and are otherwise intentional IIUC. How shall we proceed? Close as fixed?
[Bug fortran/113799] gfc_replace_expr: double free detected ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.3 Status|ASSIGNED|RESOLVED --- Comment #11 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14, and backported to 13-branch, as this is needed for the backport of the fix for pr103707. Closing.
[Bug fortran/106987] [11/12/13/14 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #5) > Hi Harald, > > I am pinning this one on you since it needs backporting to 13-branch, at > least. It also keeps the audit trail clean. Hi Paul, this one is at the top of my backport list. It depends on backporting r14-8902 (mine), and has weak conflict if r14-1629 (yours) is not backported, as testcase gfortran.dg/pr99350.f90 was introduced in that commit. I could amend backporting the fix for the current PR as well as r14-8902 to 13-branch by removing the changes to pr99350.f90 from the backport. That is likely the most simple solution, as backporting r14-1629 might introduce regressions. Nevertheless, the current fixes can only be backported to 13-branch, as some of the infrastructure changes for better error recovery after arithmetic errors and when array ctors are involved are to risky to backport to 12-branch. What do you think?
[Bug fortran/50410] ICE in record_reference, pointer variable in data statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[11/12/13/14 Regression]|ICE in record_reference, |ICE in record_reference,|pointer variable in data |pointer variable in data|statement |statement | Keywords||diagnostic --- Comment #53 from anlauf at gcc dot gnu.org --- Removing the regression marker after the ICEs on the testcases are all resolved except: - comment#24 testcase z5: this is a coarray issue and has nothing to do with DATA initialization --> should be moved to a separate PR - missing diagnostics for overlapping initialization of DT components, and some sub-optimal error messages that could be improved So let's treat this PR further as any regular one.
[Bug fortran/113956] [13/14 Regression] ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #3) > I can see why the assert is there but it is manifestly wrong for both the > assumed length target and a constant length. That's why I wanted to pass this on to you. I am not sure what the precise logic should be. > I was thrown a bit by the > distros nulling out the asserts so that it compiled just fine with the > system gfortran. If the system gfortran is based on 13.2 *release* then the bug is not yet there ;-) It entered 13-branch through backport r13-7986. > Your patch is perfect :- This compiles and runs correctly: > module m > contains > subroutine test_array_char(p, x) > character(*), target :: x(:) > character(:), pointer :: p(:) > p => x > end subroutine > end module > > use m > character(:), allocatable, target :: chr(:) > character(:), pointer :: p(:) > chr = ["ab","cd"] > call test_array_char (p, chr) > print '(l2,i4,2a4)', loc(chr) == loc(p), len(p), p > end The original testcase attached here has a second subroutine that ICEd: subroutine test_array_char_remap(p, x) character(*), target :: x(100) character(:), pointer :: p(:, :) p(2:11, 3:12) => x end subroutine It is also fixed by the patch, and checking the bounds etc. in the caller shows that it works correct too :-) program main implicit none character(3) :: x(100) = "* #" character(:), pointer :: p(:), q(:,:) call test_array_char (p, x) print *, associated (p) print *, size (p) print *, len (p) print *, p(5)(1:1) call test_array_char_remap (q, x) print *, associated (q) print *, size (q) print *, len (q) print *, lbound(q), ubound(q) print *, q(5,5)(3:3) contains subroutine test_array_char(p, x) character(*), target :: x(100) character(:), pointer :: p(:) p => x end subroutine subroutine test_array_char_remap(p, x) character(*), target :: x(100) character(:), pointer :: p(:, :) p(2:11, 3:12) => x end subroutine end
[Bug fortran/113956] [13/14 Regression] ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.3
CC||anlauf at gcc dot gnu.org,
||pault at gcc dot gnu.org
Keywords||ice-on-valid-code
Last reconfirmed||2024-03-29
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Summary|[14 Regression] ice in |[13/14 Regression] ice in
|gfc_trans_pointer_assignmen |gfc_trans_pointer_assignmen
|t, at |t, at
|fortran/trans-expr.cc:10524 |fortran/trans-expr.cc:10524
--- Comment #2 from anlauf at gcc dot gnu.org ---
Reduced testcase:
subroutine test_array_char(p, x)
character(*), target :: x(100)
character(:), pointer :: p(:)
p => x
end subroutine
We hit an assert that can be worked around with the following patch:
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index d21e3956d6e..fa31f950363 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -10534,12 +10535,9 @@ gfc_trans_pointer_assignment (gfc_expr * expr1,
gfc_expr * expr2)
{
gfc_symbol *psym = expr1->symtree->n.sym;
tmp = NULL_TREE;
- if (psym->ts.type == BT_CHARACTER)
- {
- gcc_assert (psym->ts.u.cl->backend_decl
- && VAR_P (psym->ts.u.cl->backend_decl));
- tmp = psym->ts.u.cl->backend_decl;
- }
+ if (psym->ts.type == BT_CHARACTER
+ && psym->ts.u.cl->backend_decl)
+ tmp = psym->ts.u.cl->backend_decl;
else if (expr1->ts.u.cl->backend_decl
&& VAR_P (expr1->ts.u.cl->backend_decl))
tmp = expr1->ts.u.cl->backend_decl;
This fragment was touched by Paul's fix for pr67740 (r14-4583), so adding
him.
@Paul: can you please have a look?
[Bug fortran/114474] [11/12/13/14 Regression] DATA statement with derived type, pointer component rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114474 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-03-27 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-March/060381.html This is a much tighter restricted fix of the regression.
[Bug fortran/114474] [11/12/13/14 Regression] DATA statement with derived type, pointer component rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114474 --- Comment #2 from anlauf at gcc dot gnu.org --- Created attachment 57817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57817=edit Draft patch This adds a fixup of the expression type of the actual argument of the DT constructor which is often set to BT_PROCEDURE in match_actual_arg.
[Bug fortran/114475] [14 Regression] Regression with iso_c_binding and submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475 --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to Jürgen Reuter from comment #1) > I suspect this commit here, > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=44c0398e65347def316700911a51ca8b4ec0a411 > but not totally certain. The following patch fixes the apparent regression: diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc index 9a042cd7040..68d16a9a378 100644 --- a/gcc/fortran/expr.cc +++ b/gcc/fortran/expr.cc @@ -3517,6 +3563,7 @@ check_restricted (gfc_expr *e) if (e->error || sym->attr.in_common || sym->attr.use_assoc + || sym->attr.used_in_submodule || sym->attr.dummy || sym->attr.implied_index || sym->attr.flavor == FL_PARAMETER Looks like the commit actually uncovered a latent issue. Mikael, do you want to follow up?
[Bug fortran/114475] [14 Regression] Regression with iso_c_binding and submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC|anlauf at gmx dot de |anlauf at gcc dot gnu.org Last reconfirmed||2024-03-26
[Bug fortran/114474] [11/12/13/14 Regression] DATA statement with derived type, pointer component rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114474 --- Comment #1 from anlauf at gcc dot gnu.org --- Might have been caused by the fix for pr67804 (r10-10418).
[Bug fortran/114467] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114467 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2024-03-25 Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Can you attached a self-contained reproducer? The traceback looks familiar. Are you by chance using an associate construct? There has been a fix backported from 14-mainline to 13-branch after the release of 13.2, so it might have been fixed in the meantime. (Likely a dup of pr109948).
[Bug fortran/114474] [11/12/13/14 Regression] DATA statement with derived type, pointer component rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114474 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Known to fail||10.5.0, 11.4.1, 12.3.1, ||13.2.1, 14.0 Priority|P3 |P4 Known to work||7.5.0, 8.5.0, 9.5.0 Target Milestone|--- |11.5
[Bug fortran/114474] New: [11/12/13/14 Regression] DATA statement with derived type, pointer component rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114474 Bug ID: 114474 Summary: [11/12/13/14 Regression] DATA statement with derived type, pointer component rejected Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- While working on pr50410, I noticed that the following code works with gfortran <= 9.5.0, but fails with 10.5.0 and higher: program p implicit none integer, target :: zz = 42 ! initial data target type t integer, pointer :: h end type t type(t) :: x, y data x / t(null()) / ! OK data y / t(zz) / ! fails starting with gcc-10 if (associated (y% h)) print *, y% h end This works with NAG and older gfortran and prints "42". Current mainline gives: pr50410_ctor.f90:9:13: 9 | data y / t(zz) / ! fails starting with gcc-10 | 1 Error: The element in the structure constructor at (1), for pointer component 'h', is PROCEDURE but should be INTEGER
[Bug fortran/101135] Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101135 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.3 Status|NEW |RESOLVED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14, and backported to 13-branch. Closing. Thanks for the report and the draft patch!
[Bug fortran/114438] Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 --- Comment #3 from anlauf at gcc dot gnu.org --- The same text existed in F2018, so it is not new: F2018:C7103 and Note 1. Either every compiler developer team misunderstood that clause, or we need an interp, based on the example, to be able to convince all of them. (I know of developers who do overwrite default constructors, and it currently works "everywhere", so clarification is important.) What do you think?
[Bug fortran/114438] Missed constraint F2023:c7108
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114438 --- Comment #1 from anlauf at gcc dot gnu.org --- Can you be a little more explicit? If I extend the program as follows: type(params) :: p p = params( 0.1, 2.0 ) write(*,*) p p = params( 0.1, 2 ) write(*,*) p I get with all compilers I have access to (Intel, NAG, Nvidia, flang, gfortran) Not the structure constructor 0.10001 4. 0.10001 2. This is what I would have naively expected in accordance with "Note 1": The form ’name(...)’ is interpreted as a generic function-reference if possible; it is interpreted as a structure-constructor only if it cannot be interpreted as a generic function-reference. which gives a precedence to function-reference over structure-constructor, making it possible to override the default constructor. Are you saying that one cannot override the default constructor?
