Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.lang.fortran
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Transfer and variables that don't use all their storage space.
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Brooks Moses  
View profile  
 More options Apr 8 2007, 10:46 pm
Newsgroups: comp.lang.fortran
From: Brooks Moses <bmoses-nos...@cits1.stanford.edu>
Date: Sun, 08 Apr 2007 19:46:19 -0700
Local: Sun, Apr 8 2007 10:46 pm
Subject: Re: Transfer and variables that don't use all their storage space.
Print | View thread | Show original | Report this message | Find messages by this author

Richard Maine wrote:
> Brooks Moses <bmoses-nos...@cits1.stanford.edu> wrote:
>> A naive reading of the double-transfer requirement would claim that, if
>> E is some number other than 1 or 0, then the processor is required to
>> feed that into D's storage space and leave it there, so that it can then
>> be converted back into the same number by the outer transfer statement.
>>   In particular, according to this reading, the inner transfer statement
>> cannot "normalize" the bit representation into one of the canonical
>> LOGICAL forms, because then the outer transfer statement would return
>> either 1 or 0, neither of which is equal to E.

> I think I agree with that. I'm not sure what is naive about it. It is
> pretty explicit that all transfer does is copy bits - not convert them.
> The bit that you quoted about transfer(transfer(e,d),e) is more of an
> elaboration of what you'd expect (in simple cases) to result from
> transfering the bits. I think it belongs as a note instead of as
> normative text. (And it probably should be corrected with
> qualifications, even as a note.)

I mean "naive" in the sense of looking just at that paragraph, without
considering context or outside knowledge.  I don't mean that I think
it's necessarily wrong.

>> I would contend that this reading is incorrect -- that, in particular,
>> if E has a bit representation that is not one of the canonical bit
>> representations for a logical variable, then the inner transfer
>> statement is illegal according to the comments in the beginning of
>> section 13.7 which state that a program is not allowed to invoke an
>> intrinsic with arguments that produce out-of-range results.  And further
>> that the double-transfer identity requirement obviously is only meant to
>> apply when both transfer calls, taken independently, are legal.

> I agree, except with your comment that the para before is incorrect.
> These two paras don't seem inconsistent to me. I think *BOTH* of them
> are right. The first para describes what the standard requires to happen
> (that the bits just get copied without change). The second para
> correctly (in my view) notes that this requires disallowed behavior in
> some cases. I agree with the conclusion that the code is illegal on
> machines where the resulting bit pattern is an invalid one.

I think I'm confused as to what it means, in practical terms, when "the
standard ... requires disallowed behavior".  I'm not sure how to write a
compiler that disappears in a puff of logic in such cases!  :)

Perhaps it would be useful for me to elaborate a bit more on why I'm
asking this question.  GFortran currently, in its handling of
initialization expressions, treats all logical variables as simple
booleans, stored for convenience in whatever the host considers to be a
default integer (which is usually 4 bytes).  However, it supports 8-byte
logical variables.  Thus, consider the following program-piece:

   logical(kind=8) :: L
   integer :: A( -transfer(transfer(-5_8, L), -5_8) )

(Note that, in GFortran, KIND=8 logicals and integers are 8-byte.)

In order to do the initialization-expression handling to reliably
produce a 5-element array out of this, the constant-folder for the inner
transfer evaluation needs to store all eight bytes of the result.

Doing that would either require that the entire initialization-
expression evaluation mechanism store all logical variables in a way
that records all eight bytes of "target storage" even though they are
almost never meaningful, or else the parser has to recognize this
particular idiom and handle it specially.  Neither of these is a very
appealing option, and that's just one of the simpler cases.

However, if this is illegal code, then I would think that it would be
entirely standard-conforming for the compiler to do just about anything
with this code, and thus such measures are unnecessary.

If I understand your above comments correctly, you've agreed that this
is illegal code, but you also explicitly agreed with the second half of
my first paragraph (the bit starting with "In particular," which says
that transfer(transfer(-5_8, L), -5_8) must return -5, not 1.  It seems
completely counterintuitive to me that the compiler is required to
produce a specific result for illegal code.  However, that's what I'm
understanding you to be saying.

Would it be allowable, at least, for a compiler to throw an error and
refuse to compile "transfer(transfer(-5_8, L), -5_8)" at all?

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google