[Patch, fortran] PRs 70752 and 72709 - more deferred character length bugs

[Paul Richard Thomas]

This patch is a bit more complicated than some of the previous posts.
However, the ChangeLog explains the story pretty clearly.

Bootstraps and regtests on FC21/x86_64 - OK for trunk and 8-branch?

Again, better names for the testcases will be determined before committing.

Paul


2018-09-25 Paul Thomas <***@gcc.gnu.org>

PR fortran/70752
PR fortran/72709
* trans-array.c (gfc_conv_scalarized_array_ref): If this is a
deferred type and the info->descriptor is present, use the
info->descriptor
(gfc_conv_array_ref): Is the se expr is a descriptor type, pass
it as 'decl' rather than the symbol backend_decl.
(gfc_array_allocate): If the se string_length is a component
reference, fix it and use it for the expression string length.
Make use of component ref string lengths to set the descriptor
'span'.
(gfc_conv_expr_descriptor): For pointer assignment, do not set
the span field if gfc_get_array_span returns zero.
* trans.c (get_array_span): If the upper bound a character type
is zero, use the descriptor span if available.


2018-09-25 Paul Thomas <***@gcc.gnu.org>

PR fortran/70752
* gfortran.dg/pr70752.f90 : New test.

PR fortran/72709
* gfortran.dg/pr72709.f90 : New test.

[Janne Blomqvist]

On Tue, Sep 25, 2018 at 8:06 PM Paul Richard Thomas <

Post by Paul Richard Thomas
This patch is a bit more complicated than some of the previous posts.
However, the ChangeLog explains the story pretty clearly.
Bootstraps and regtests on FC21/x86_64 - OK for trunk and 8-branch?

+ if (expr->ts.kind != 1)
+ {
+ tmp = build_int_cst (gfc_array_index_type, expr->ts.kind);
+ tmp = fold_build2_loc (input_location, MULT_EXPR,
+ gfc_array_index_type,
+ se->string_length, tmp);
+ }

Is se->string_length guaranteed to be of type gfc_array_index_type_here? If
so, why? And if not, maybe a fold_convert is in order?

Otherwise, Ok.

[Dominique d'Humières]

Post by Janne Blomqvist
Is se->string_length guaranteed to be of type gfc_array_index_type_here?
If so, why? And if not, maybe a fold_convert is in order?

I don’t know if this related, but if I build gfortran with the patches for PRs 70752 and 72709, 70149, and 65677 with --enable-checking=yes, compiling the test in pr82617 gives an ICE:

pr82617.f90:68:0:

68 | items(i_item) = str(i0:i1-1)
|
internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'indirect_ref' in get_array_span, at fortran/trans.c:301

Cheers,

Dominique

[Paul Richard Thomas]

Hi Dominique,

Thanks for the heads up - I will check it out and fix it next week
before doing any commits.

Cheers

Paul

Post by Dominique d'Humières

Post by Janne Blomqvist
Is se->string_length guaranteed to be of type gfc_array_index_type_here?
If so, why? And if not, maybe a fold_convert is in order?

68 | items(i_item) = str(i0:i1-1)
|
internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'indirect_ref' in get_array_span, at fortran/trans.c:301
Cheers,
Dominique

[Paul Richard Thomas]

Hi Dominique,

It's the patch for pr70752 that causes the trouble, which I had
guessed from the point in trans.c where the ICE occurs. I am onto it.

Thanks again

Paul

Post by Dominique d'Humières

Post by Janne Blomqvist
Is se->string_length guaranteed to be of type gfc_array_index_type_here?
If so, why? And if not, maybe a fold_convert is in order?

68 | items(i_item) = str(i0:i1-1)
|
internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'indirect_ref' in get_array_span, at fortran/trans.c:301
Cheers,
Dominique

[Paul Richard Thomas]

Dear Dominique and Janne,

Putting the problem right turned out to be trivial. In the part of the
patch in gfc_conv_array_ref, what was being passed as 'decl' , in the
failing test from PR82617 was indeed an indirect reference. Applying
one dollop of indirection fixed it. The original testcase from PR82617
has been added to make sure that this does not break again. I also,
did the fold_convert, as recommended by Janne.

Committed as revision 264724 after regtesting.

Paul

2018-09-30 Paul Thomas <***@gcc.gnu.org>

PR fortran/70752
PR fortran/72709
* trans-array.c (gfc_conv_scalarized_array_ref): If this is a
deferred type and the info->descriptor is present, use the
info->descriptor
(gfc_conv_array_ref): Is the se expr is a descriptor type, pass
it as 'decl' rather than the symbol backend_decl.
(gfc_array_allocate): If the se string_length is a component
reference, fix it and use it for the expression string length
if the latter is not a variable type. If it is a variable do
an assignment. Make use of component ref string lengths to set
the descriptor 'span'.
(gfc_conv_expr_descriptor): For pointer assignment, do not set
the span field if gfc_get_array_span returns zero.
* trans.c (get_array_span): If the upper bound a character type
is zero, use the descriptor span if available.


2018-09-30 Paul Thomas <***@gcc.gnu.org>

PR fortran/70752
PR fortran/72709
* gfortran.dg/deferred_character_25.f90 : New test.
* gfortran.dg/deferred_character_26.f90 : New test.
* gfortran.dg/deferred_character_27.f90 : New test to verify
that PR82617 remains fixed.

On Sun, 30 Sep 2018 at 09:02, Paul Richard Thomas

Post by Paul Richard Thomas
Hi Dominique,
It's the patch for pr70752 that causes the trouble, which I had
guessed from the point in trans.c where the ICE occurs. I am onto it.
Thanks again
Paul

Post by Dominique d'Humières

Post by Janne Blomqvist
Is se->string_length guaranteed to be of type gfc_array_index_type_here?
If so, why? And if not, maybe a fold_convert is in order?

68 | items(i_item) = str(i0:i1-1)
|
internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'indirect_ref' in get_array_span, at fortran/trans.c:301
Cheers,
Dominique

--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein