Re: Subtraction + comparison in one asm instruction?

"Vincent Lefevre" <vincent+news@vinc17.org> writes:


> Gabriel Dos Reis <gdr@soliton.integrable-solutions.net> wrote:
>
> > It is quite reasonable to expect an underflow trap/exception, if such
> > a thing is supported by the executing environment (e.g. conforming to
> > "Language Independent Arithmetic, part 1"). In that case, I would not
> > like to see the compiler deliberately suppress that expectation in my
> > codes.
>
> In all the cases I've tested, there was no support for underflow trap,


Then, you're not lucky enough :-)


Note that in most cases, "installing traps" happens behind the back of
the compilers (when it doesn't provide switch to tell). So, when the
compiler doesn't have direct knowledge of the CPU status, it just lets
things fall through and see what happens.


It is true that for floating point types (not your primary concern
here), C99 tries to rule the land through use of #pragmas and #dogmas.
But yes, GCC -- in your example -- has long road to make before making
consistent decisions based on predictable rules.


[...]


> If underflow/overflow traps are supported, there could
> be a compiler switch to allow the user to say that he has proved that
> there are no overflows in his program, so that such optimizations
> could be performed for speed-critical programs.


Yes, if underflow/overflow traps are *directly* supported by the
compiler, then indeed you have a point.


-- Gaby

Return to the comp.compilers page.
Search the comp.compilers archives again.