On Fri, 18 Jan 2013, Michael Zolotukhin wrote:
> Sure, the tests are of utmost importance here. By the way, in what
> suite should they be?
I suspect that things such as testing for both -mfpmath=387 and
-mfpmath=sse indicate a new .exp file. That may also help for other
things such as running
Sure, the tests are of utmost importance here. By the way, in what
suite should they be?
As for the changes in the compiler itself - what do you think about
introduction of a fake variable, reflecting rounding mode (similar
variables could be introduced for exception flags and other
properties). H
I should add that the recent observation of bugs on some platforms with
unordered comparisons being wrongly used instead of ordered ones
illustrates my point about the value of having proper test coverage for
each individual operation, even though some bugs will only show in more
complicated co
On Fri, Jan 11, 2013 at 5:41 PM, Joseph S. Myers
wrote:
> On Fri, 11 Jan 2013, Michael Zolotukhin wrote:
>
>> > Personally I'd think a natural starting point on the compiler side would
>> > be to write a reasonably thorough and systematic testsuite for such
>> > issues. That would cover all opera
On Fri, 11 Jan 2013, Michael Zolotukhin wrote:
> > Personally I'd think a natural starting point on the compiler side would
> > be to write a reasonably thorough and systematic testsuite for such
> > issues. That would cover all operations, for all floating-point types
> > (including ones such as
> Yes, doing much related to rounding modes really requires making the
> compiler respect them properly for -frounding-math. That's not quite
> calls being optimization barriers in general, just for floating point.
>
> * General calls may set, clear or test exceptions, or manipulate the
> rounding
On Thu, 10 Jan 2013, Michael Zolotukhin wrote:
> Thanks for the responses!
> I'll think about your warnings and decide whether I could afford such
> effort or not, but anyway, I wanted to start from GCC, not glibc.
> Am I getting it right, that before any other works we need to fix PR
> 34678 (tha
Thanks for the responses!
I'll think about your warnings and decide whether I could afford such
effort or not, but anyway, I wanted to start from GCC, not glibc.
Am I getting it right, that before any other works we need to fix PR
34678 (that's correct number, thanks Mark!), making all passes take
On Fri, 14 Dec 2012, Michael Zolotukhin wrote:
> Currently, I think the problem could be tackled in the following way:
> In gimple we'll need to add a pass that would a) find regions with
> constant, compile-time known rounding mode, b) replace operations with
> subcodes like plus/minus/div/etc. w
On Tue, Dec 18, 2012 at 4:34 PM, Richard Henderson wrote:
> On 12/14/2012 04:20 AM, Richard Biener wrote:
>> Exposing known rounding modes as new operation codes may sound like
>> a good idea (well, I went a similar way with trying to make operations with
>> undefined overflow explicit ... but the
On 12/14/2012 04:20 AM, Richard Biener wrote:
> Exposing known rounding modes as new operation codes may sound like
> a good idea (well, I went a similar way with trying to make operations with
> undefined overflow explicit ... but the fallout was quite large even though
> there is only one kind of
On Fri, 14 Dec 2012, Michael Zolotukhin wrote:
I found quite an old bug PR34768 and was thinking of doing what was
suggested there.
Wrong bug number? 34678 probably.
Particularly, I was wondering about adding new subcodes to gimple and
rtl for describing operations with rounding.
Currently,
On Fri, Dec 14, 2012 at 12:16 PM, Michael Zolotukhin
wrote:
> Hi,
> I found quite an old bug PR34768 and was thinking of doing what was
> suggested there.
> Particularly, I was wondering about adding new subcodes to gimple and
> rtl for describing operations with rounding.
>
> Currently, I think t
13 matches
Mail list logo
