This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fold VIEW_CONVERT_EXPR <type, STRING_CST> generated by Fortran FE a lot (PR target/35366)


Hi,

Jakub wrote:
> So would the following be acceptable?  It will warn both for
> logical l
>   l = 4Hfoob
> and
>   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,
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/cf874197dc460679
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
  preserved

Thus, your patch is OK from the standard and common practice point of
view.

       if (expr->representation.string)
	{
+	  if (TREE_CODE (tmp) == INTEGER_CST)
+	  else

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
instead.

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".

Tobias


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]