This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fold VIEW_CONVERT_EXPR <type, STRING_CST> generated by Fortran FE a lot (PR target/35366)
- From: Tobias Burnus <burnus at net-b dot de>
- To: gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org
- Date: Tue, 11 Nov 2008 23:34:29 +0100
- Subject: Re: [PATCH] Fold VIEW_CONVERT_EXPR <type, STRING_CST> generated by Fortran FE a lot (PR target/35366)
> So would the following be acceptable? It will warn both for
> logical l
> l = 4Hfoob
> l = transfer (42, .true.)
I think that would be sufficent. For completeness:
There is no warning given for
b = transfer(i, b)
I think that is OK, but one could also give one as NAG f95 does:
Warning: TRANSFER to LOGICAL might produce invalid value
I got the first replies to my c.l.f question,
and reading Glen Herrmannsfeldt's and Richard Maine's reply,
there should be no problem:
- Holleriths were usually used with integer since real/logical
are system dependent (e.g. normalization of REAL Holleriths)
- TRANSFER requires that the bit pattern matches
(Richard: "I think to be a mistake"), but
"even if you literally follow that requirement, there turn out to
be gaping loopholes that pretty much prevent the user from being
able to count on bit pattern preservation."
- Assignments, COMMON and EQUIVALENCE: No bit pattern needs to be
Thus, your patch is OK from the standard and common practice point of
+ if (TREE_CODE (tmp) == INTEGER_CST)
I think there is no possibility to ever enter the else branch:
expr->representation.string only occurs for either Holleriths
or for TRANSFER of constants; I would go for a gcc_assert
The patch is OK from my side.
Brooks Moses wrote:
+ gfc_warning ("Assigning value other than 0 or 1 to LOGICAL"
+ " at %L has undefined result", &expr->where);
> The warning could perhaps be edited a little, too, to reflect that the
> user isn't necessarily thinking of the input as an integer. Maybe:
> "Cannot assign value with bitwise representation other than 0x0 or 0x1
> to LOGICAL at %L".
I find the original string clearer than especially the "0x0 or 0x1".