[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103

["anlauf at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483

--- Comment #28 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #27)
> (In reply to anlauf from comment #25)
> > (In reply to Mikael Morin from comment #24)
> > > First, the ARITH_INVALID_TYPE should be renamed as it has now a broader
> > > usage (ARITH_OP_NOT_LITERAL_VALUE is a bit long, ARITH_OP_NOT_CONSTANT is a
> > > bit misleading, ARITH_OP_NOT_SIMPLIFIED not great either, any other idea?).
> > 
> > I think we should keep the enum ARITH_INVALID_TYPE for those cases where it
> > is appropriate,
> 
> Are there such cases remaining?  It seems that that value can't be returned
> any more.

Actually there is the fix for pr107217, and I found a couple of other similar
cases involving comparisons and logicals which are not yet handled.
I will submit a patch.

> > I was contemplating either ARITH_NOT_REDUCED or
> > ARITH_CANNOT_REDUCE,
> > and opted for the latter.
> > 
> I have a slight preference for the former but let's go with the latter if you
> prefer.  But please add a comment describing it in the definition.
> Most enum values have an obvious meaning there, this one less so.

Will do.

> > > Second, I'm wondering whether the check in reduce_binary_aa shouldn't be
> > > moved to reduce binary where it would be more clear.
> > 
> > I agree that it is preferable to have checks already in reduce_binary, see
> > updated patch.  After this one could remove the check from reduce_binary_aa,
> > as it would be redundant.
> > 
> And there is a redundant check in reduce_unary as well.

True.  I will submit an updated patch.