This is the mail archive of the gcc@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: recent troubles with float vectors & bitwise ops


Andrew Pinski wrote:
> On 8/24/07, Mark Mitchell <mark@codesourcery.com> wrote:
>> Let "a" and "b" be floating-point operands of type F, where F is a
>> floating-point type.  Let N be the number of bytes in F.  Then, "a | b"
>> is defined as:
> 
> Yes that makes sense, not.  

I'm not following.  Are you agreeing or disagreeing?

> Since most of the time, you have a mask
> and that is what is being used.  Like masking the the sign bit or
> doing a selection.  The mask is most likely a NaN anyways so having
> that undefined just does not make sense.  

I'm not following.  What I meant was that if the result was a NaN,
whether or not floating-point exceptions were signalled was unspecified.
 Where does undefined come into it, and what does that have to do with
the mask?  If we think that no hardware will ever signal an exception in
this case, then we can say that the operation never signals an
exception.  But, I was afraid that might be too strong a constraint.

> So is this going to be on
> scalars?  If not, then we should still not accept it on vectors.

Yes, from a language-design point of view, it should be for both scalars
and vectors, so I wrote the strawman definition in terms of scalars.  Of
course, if where it's actually useful is vectors, then implementing it
for vectors is the important case, and whether or not we get around to
doing it on scalars is secondary.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


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