Joseph Myers writes:
> On Tue, 25 Mar 2014, Matthew Fortune wrote:
>
> > Can you envisage any way of us raising a warning/error if INVALID
> > exceptions get enabled in this hybrid NaN world? I believe that is the
> > only major problem area with mixing NaNs. I.e. It should be possible
> > to int
On Tue, 25 Mar 2014, Matthew Fortune wrote:
> Can you envisage any way of us raising a warning/error if INVALID
> exceptions get enabled in this hybrid NaN world? I believe that is the
> only major problem area with mixing NaNs. I.e. It should be possible to
> introduce a magic symbol if LD mer
Matthew Fortune writes:
> Joseph Myers writes:
>> On Tue, 25 Mar 2014, Rich Fuhler wrote:
>>
>> > Hi Richard, we talked about (a.) originally - it was the design of the
>> > libraries. Joseph, as I recollect, you raised language issues with
>> > requirements for compile-time constant values for
Joseph Myers writes:
> On Tue, 25 Mar 2014, Rich Fuhler wrote:
>
> > Hi Richard, we talked about (a.) originally - it was the design of the
> > libraries. Joseph, as I recollect, you raised language issues with
> > requirements for compile-time constant values for NaNs. Would you
> > accept a non
On Tue, 25 Mar 2014, Rich Fuhler wrote:
> Hi Richard, we talked about (a.) originally - it was the design of the
> libraries. Joseph, as I recollect, you raised language issues with
> requirements for compile-time constant values for NaNs. Would you accept
> a non-constant NaN implementation in
> The easiest way to do that is to add a flag that either (a) stops the
> compiler emitting a .nan at all or (b) gets it to emit ".nan legacy"
> regardless of the actual encoding used. It's really just a slight
> variation on (2), the difference being that we might be using 2008
> under the covers
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> > Maciej W. Rozycki writes:
>> >> On Sat, 22 Mar 2014, Richard Sandiford wrote:
>> >>
>> >> > > Thanks Joseph. I guess I'm not really pushing to have don't-care
>> >> > > supported as it would take a lot of effort
"Maciej W. Rozycki" writes:
> What I'm concerned the most about is the matter is so obscure to people
> outside a narrow group of hardware/kernel/toolchain/library experts (that
> regrettably does not include distribution packagers) that once that "don't
> care" approach is set in the environm
On Mon, 24 Mar 2014, Matthew Fortune wrote:
> Yes this is a lot simpler than the 3rd mode but disabling the NAN2008 ELF
> Flag checks is even more honest as that is what would happen at the
> kernel-userland boundary anyway, so why enforce it elsewhere.
>
> I know I am pushing hard on this topic
Richard Sandiford writes:
> Matthew Fortune writes:
> > Maciej W. Rozycki writes:
> >> On Sat, 22 Mar 2014, Richard Sandiford wrote:
> >>
> >> > > Thanks Joseph. I guess I'm not really pushing to have don't-care
> >> > > supported as it would take a lot of effort to determine when code
> >> > >
Matthew Fortune writes:
> Maciej W. Rozycki writes:
>> On Sat, 22 Mar 2014, Richard Sandiford wrote:
>>
>> > > Thanks Joseph. I guess I'm not really pushing to have don't-care
>> > > supported as it would take a lot of effort to determine when code
>> > > does and does not care, you rightly poin
Maciej W. Rozycki writes:
> On Sat, 22 Mar 2014, Richard Sandiford wrote:
>
> > > Thanks Joseph. I guess I'm not really pushing to have don't-care
> > > supported as it would take a lot of effort to determine when code
> > > does and does not care, you rightly point out more cases to deal
> > > w
On Sat, 22 Mar 2014, Richard Sandiford wrote:
> > Thanks Joseph. I guess I'm not really pushing to have don't-care
> > supported as it would take a lot of effort to determine when code does
> > and does not care, you rightly point out more cases to deal with
> > too. I'm not sure if the benefit wo
Matthew Fortune writes:
> Thanks Joseph. I guess I'm not really pushing to have don't-care
> supported as it would take a lot of effort to determine when code does
> and does not care, you rightly point out more cases to deal with
> too. I'm not sure if the benefit would then be worth it or not as
tor.com)
> Subject: RE: [RFC, MIPS] Relax NaN rules
>
>
> Coprocessor loads (LWC1/LDC1/MTC1/MTHC1/DMTC1) and stores
> (SWC1/SDC1/MFC1/MFHC1/DMFC1) are not arithmetic and never trap on any bit
> patterns. I reckon GCC already takes advantage of this and stores
> integers tempora
On Fri, 21 Mar 2014, Joseph S. Myers wrote:
> > I ask this for another reason as well: since we're adding IFUNC
> > capability to MIPS, we may need to harden the dynamic loader to protect
> > $f12 and $f14. If signaling NaN was raised on the load, then we have
> > more problems to deal with...
On Fri, 21 Mar 2014, Rich Fuhler wrote:
> Hi Joseph, as I remember from conversations last year, there is also an
> issue if the programmer specifically enables the FPU exceptions. If the
> FPU, kernel emulator, or bare-metal emulator (CS3's for example) did
> raise a signaling NaN, then the in
> From: Matthew Fortune
> Sent: Tuesday, March 18, 2014 08:06
> To: Joseph Myers
> Cc: Richard Sandiford; ma...@codesourcery.com; dal...@aerifal.cx; Andrew
> Pinski (pins...@gmail.com); gcc@gcc.gnu.org; Rich Fuhler; Moore, Catherine
> (catherine_mo...@mentor.com)
> Subject:
Joseph Myers writes:
> > 1) There is no way to mark a module as "don't care/not relevant". At a
> > minimum this could be done via inspection of the GNU FP ABI attribute
> > and when its value is 'Any' then NaNs don't matter. Better still would
> > be that modules with floating point only require
On Tue, 18 Mar 2014, Matthew Fortune wrote:
> 1) There is no way to mark a module as "don't care/not relevant". At a
> minimum this could be done via inspection of the GNU FP ABI attribute
> and when its value is 'Any' then NaNs don't matter. Better still would
> be that modules with floating p
Hi,
I've sent this email to everyone who had opinions about the introduction of
nan-2008 for mips according to the mailing list archives...
The NaN linkage rules introduced with -mnan=2008 enforce a strict rule that all
code be built with either legacy NaN or 2008 NaN. This impacts both static
21 matches
Mail list logo
