[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-09-05 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #17 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-12, and backported to 11-branch.  Closing.

Thanks for the report!

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-09-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

--- Comment #16 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:71013e5fb844cab1865a65373fdc32aa5b87a525

commit r11-8962-g71013e5fb844cab1865a65373fdc32aa5b87a525
Author: Harald Anlauf 
Date:   Tue Aug 31 21:00:53 2021 +0200

Fortran - extend set of substring expressions handled in length
simplification

gcc/fortran/ChangeLog:

PR fortran/100950
* simplify.c (substring_has_constant_len): Minimize checks for
substring expressions being allowed.

gcc/testsuite/ChangeLog:

PR fortran/100950
* gfortran.dg/pr100950.f90: Extend coverage.

(cherry picked from commit e4cb3bb9ac11b4126ffa718287dd509a4b10a658)

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-09-05 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

--- Comment #15 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:c94755c7734c6aac9e114fb69ca23aed524e2450

commit r11-8961-gc94755c7734c6aac9e114fb69ca23aed524e2450
Author: Harald Anlauf 
Date:   Thu Aug 19 21:00:45 2021 +0200

Fortran - simplify length of substring with constant bounds

gcc/fortran/ChangeLog:

PR fortran/100950
* simplify.c (substring_has_constant_len): New.
(gfc_simplify_len): Handle case of substrings with constant
bounds.

gcc/testsuite/ChangeLog:

PR fortran/100950
* gfortran.dg/pr100950.f90: New test.

(cherry picked from commit d881460deb1f0bdfc3e8fa2d391a03a9763cbff4)

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-08-31 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:e4cb3bb9ac11b4126ffa718287dd509a4b10a658

commit r12-3273-ge4cb3bb9ac11b4126ffa718287dd509a4b10a658
Author: Harald Anlauf 
Date:   Tue Aug 31 21:00:53 2021 +0200

Fortran - extend set of substring expressions handled in length
simplification

gcc/fortran/ChangeLog:

PR fortran/100950
* simplify.c (substring_has_constant_len): Minimize checks for
substring expressions being allowed.

gcc/testsuite/ChangeLog:

PR fortran/100950
* gfortran.dg/pr100950.f90: Extend coverage.

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-08-20 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:12f22906d3c025e7edb60e3264dc9cd27a49e3e1

commit r12-3043-g12f22906d3c025e7edb60e3264dc9cd27a49e3e1
Author: Harald Anlauf 
Date:   Fri Aug 20 13:38:00 2021 +0200

Fortran - use temporary char buffer for passing HOST_WIDE_INT to gfc_error

gcc/fortran/ChangeLog:

PR fortran/100950
* simplify.c (substring_has_constant_len): Fix format string of
gfc_error, pass HOST_WIDE_INT bounds values via char buffer.

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-08-19 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:d881460deb1f0bdfc3e8fa2d391a03a9763cbff4

commit r12-3033-gd881460deb1f0bdfc3e8fa2d391a03a9763cbff4
Author: Harald Anlauf 
Date:   Thu Aug 19 21:00:45 2021 +0200

Fortran - simplify length of substring with constant bounds

gcc/fortran/ChangeLog:

PR fortran/100950
* simplify.c (substring_has_constant_len): New.
(gfc_simplify_len): Handle case of substrings with constant
bounds.

gcc/testsuite/ChangeLog:

PR fortran/100950
* gfortran.dg/pr100950.f90: New test.

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-06-11 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

--- Comment #11 from anlauf at gcc dot gnu.org ---
The variant with typespec and non-constant length is incorrectly rejected:

program p
  integer :: n = 2
  print *, [character(n) :: 'a', 'b']
end

All versions since at least gcc-7 give:

pr100950-z3.f90:3:0:

   print *, [character(n) :: 'a', 'b']

Error: size of variable 'A.1' is too large

Maybe the issue here is somewhere in trans-array.c(gfc_walk_array_constructor),
but that is unrelated to the issue with constant substring length.

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-06-09 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

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 #10 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2021-June/056146.html

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-06-09 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #50967|0   |1
is obsolete||

--- Comment #9 from anlauf at gcc dot gnu.org ---
Created attachment 50973
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50973&action=edit
Corrected patch

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-06-08 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

--- Comment #8 from anlauf at gcc dot gnu.org ---
Created attachment 50967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50967&action=edit
Tentativ fix

This patch would fix the testcase.  It is inspired by code in primary.c,
match_string_constant.  Not regtested.

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-06-08 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

--- Comment #7 from anlauf at gcc dot gnu.org ---
Setting a breakpoint in gfc_simplify_len, it appears that the substring length
is not properly set:

(gdb) p e->ref->type
$4 = REF_SUBSTRING
(gdb) p *e->ref->u.ss.start->value.integer._mp_d
$15 = 1
(gdb) p *e->ref->u.ss.end->value.integer._mp_d
$16 = 2
(gdb) p *e->ref->u.ss.length->length->value.integer._mp_d 
$17 = 8

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-06-08 Thread sgk at troutmask dot apl.washington.edu via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

--- Comment #6 from Steve Kargl  ---
On Tue, Jun 08, 2021 at 05:09:05PM +, gs...@t-online.de wrote:
> 
> It should be valid, type-spec is explicitly given and the ac-values
> are type compatible (see e.g. F2018 7.8). With len(x(1:2))==2 the
> following simplified example works :
> 

Thanks for the leg work with the standard.  I was heading
out the door for work when I saw Richard's comment.  I
simply wanted to confirm that it is indeed a FE bug.

Likely, needed to check array.c(walk_array_constructor)
to see how the typespec/conversion is handled and possibly
array.c(gfc_match_array_constructor).

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-06-08 Thread gscfq--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

--- Comment #5 from G. Steinmetz  ---

It should be valid, type-spec is explicitly given and the ac-values
are type compatible (see e.g. F2018 7.8). With len(x(1:2))==2 the
following simplified example works :


$ cat zz1.f90
program p
   print *, [character(2) :: 'a', 'b']
   print *
   print *, 'len :', len ([character(3) :: 'a', 'bc', 'def', 'last'])
   print *, 'size:', size([character(3) :: 'a', 'bc', 'def', 'last'])
   print *, [character(3) :: 'a', 'bc', 'def', 'last']
end


$ gfortran zz1.f90 && ./a.out
 a b

 len :   3
 size:   4
 a  bc deflas

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-06-08 Thread kargl at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> So we hit
> 
> /* Check if a STRING_CST fits into the field.
>Tolerate only the case when the NUL termination
>does not fit into the field.   */
> 
> static bool
> check_string_literal (tree string, unsigned HOST_WIDE_INT size)
> {
> ...
>   if (mem_size != size)
> return false;
> 
> so in this case the NUL termination is missing.  TREE_STRING_LENGTH is 1
> but the field size is 2.  The CTOR is
> 
> {"a", "b"}
> 
> and has a type of char[2][2].  Looks like a FE bug to me.

Yes, it's a FE bug.

If the line is changed to 

   print *, [character(len(x(1:2))) :: 'a ', ' b']

or

   print *, [character(len(x(1:1))) :: 'a', 'b']

the code compiles and runs as expected.  The type
declaration is set to 2 while the elements in the
constructor have a len of 1.  The FE should likely
check for too short of an element and blank pad.

However, someone needs to check if this is a valid
structure constructor, because technically the 
elements are type incompatible with declared type
(ie., different type kind parameters).

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-06-08 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

--- Comment #3 from Richard Biener  ---
So we hit

/* Check if a STRING_CST fits into the field.
   Tolerate only the case when the NUL termination
   does not fit into the field.   */

static bool
check_string_literal (tree string, unsigned HOST_WIDE_INT size)
{
...
  if (mem_size != size)
return false;

so in this case the NUL termination is missing.  TREE_STRING_LENGTH is 1
but the field size is 2.  The CTOR is

{"a", "b"}

and has a type of char[2][2].  Looks like a FE bug to me.

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-06-07 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-06-07
 Status|UNCONFIRMED |NEW
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Very interesting.

No ICE when the declared length of x is 2 for gcc >= 9.4.1,
but ICE otherwise.

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

2021-06-07 Thread gscfq--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from G. Steinmetz  ---

Works with a parameter :


$ cat z2.f90
program p
   character(4), parameter :: x = '1234'
   print *, [character(len(x(1:2))) :: 'a', 'b']
end


$ gfortran-12-20210606 z2.f90 && ./a.out
 a b