Once the bug is found, the fix is obvious. Briefly,
in a typespec, ts.u.cl and ts.u.pad are in the same
union. When parsing a Hollerith, ts.u.pad is is set
to a nonzero value. Later, when resolving the array
constructor with Hollerith entities, a reference to
ts.u.cl is made which is a mangled non-NULL pointer.
The fix is to clear ts.u.pad in the hollerith to
character conversion function.
Regression tested on x86_64-*-freebsd.
2017-11-08 Steven G. Kargl <ka...@gcc.gnu.org>
PR fortran/82884
* arith.c (gfc_hollerith2character): Clear pad.
2017-11-08 Steven G. Kargl <ka...@gcc.gnu.org>
PR fortran/82884
* gfortran.dg/hollerith_character_array_constructor.f90: New test.
Index: gcc/fortran/arith.c
===================================================================
--- gcc/fortran/arith.c (revision 254461)
+++ gcc/fortran/arith.c (working copy)
@@ -2604,6 +2604,7 @@ gfc_hollerith2character (gfc_expr *src, int kind)
result = gfc_copy_expr (src);
result->ts.type = BT_CHARACTER;
result->ts.kind = kind;
+ result->ts.u.pad = 0;
result->value.character.length = result->representation.length;
result->value.character.string
Index: gcc/testsuite/gfortran.dg/hollerith_character_array_constructor.f90
===================================================================
--- gcc/testsuite/gfortran.dg/hollerith_character_array_constructor.f90
(nonexistent)
+++ gcc/testsuite/gfortran.dg/hollerith_character_array_constructor.f90
(working copy)
@@ -0,0 +1,11 @@
+! { dg-do run }
+! { dg-options "-w" }
+! PR fortran/82884
+! Original code contributed by Gerhard Steinmetz
+program p
+ character :: c(4) = [1h(, 1hi, 1h4, 1h)]
+ if (c(1) /= '(') call abort
+ if (c(2) /= 'i') call abort
+ if (c(3) /= '4') call abort
+ if (c(4) /= ')') call abort
+end
--
Steve
