> From: Georg Bauhaus <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>> - How is it necessary or desirable to define that the result is undefined
>> vs. being target defined?
>
> What does C say about how a target performs an instruction?
> And why shouldn't GCC take advantage of this?
- In essence
Paul Schlie wrote:
- How is it necessary or desirable to define that the result is undefined
vs. being target defined?
What does C say about how a target performs an instruction?
And why shouldn't GCC take advantage of this?
Paul Schlie <[EMAIL PROTECTED]> wrote on 08/06/2005 21:16:46:
> > From: Michael Veksler <[EMAIL PROTECTED]>
> >> Paul Schlie wrote on 08/06/2005 17:53:04:
> >> - I would have if someone could provide a concrete example of an
> >> undefined behavior which produces a reliably useful/predicta
> From: Michael Veksler <[EMAIL PROTECTED]>
>> Paul Schlie wrote on 08/06/2005 17:53:04:
>> - I would have if someone could provide a concrete example of an
>> undefined behavior which produces a reliably useful/predictable result.
>>
> Well this is a simple hackery quiz, which is irrelevant to
> From: Bernd Schmidt <[EMAIL PROTECTED]>
> Paul Schlie wrote:
>>> From: Robert Dewar <[EMAIL PROTECTED]>
>>> You keep saying this over and over, but it does not make it true. Once
>>> again, the whole idea of making certain constructs undefined, is to
>>> ensure that efficient code can be generate
> From: Joe Buck <[EMAIL PROTECTED]>
>> On Wed, Jun 08, 2005 at 10:53:04AM -0400, Paul Schlie wrote:
>>> From: Robert Dewar <[EMAIL PROTECTED]>
>>> There is nothing imprecise about IEEE floating-point operations
>>
>> - agreed, however nor is it mandated by most language specifications,
>> so se
On Wed, Jun 08, 2005 at 10:53:04AM -0400, Paul Schlie wrote:
> > From: Robert Dewar <[EMAIL PROTECTED]>
> > There is nothing imprecise about IEEE floating-point operations
>
> - agreed, however nor is it mandated by most language specifications,
> so seemingly irrelevant.
In real life, there ar
Paul Schlie wrote:
From: Robert Dewar <[EMAIL PROTECTED]>
You keep saying this over and over, but it does not make it true. Once
again, the whole idea of making certain constructs undefined, is to
ensure that efficient code can be generated for well defined constructs.
- Can you give an exampl
Paul Schlie wrote on 08/06/2005 17:53:04:
>
> - I would have if someone could provide a concrete example of an
undefined
> behavior which produces a reliably useful/predictable result.
>
Well this is a simple hackery quiz, which is irrelevant to GCC.
1: int a, b;
2: int f()
Original Message
>From: Paul Schlie
>Sent: 08 June 2005 15:53
>> From: Robert Dewar
>> There is nothing imprecise about IEEE floating-point operations
>
> - agreed, however nor is it mandated by most language specifications,
> so seemingly irrelevant.
I refer you to "Annex F (normativ
> From: Robert Dewar <[EMAIL PROTECTED]>
> Date: Wed, 08 Jun 2005 10:16:23 -0400
> To: Paul Schlie <[EMAIL PROTECTED]>
> Cc: Florian Weimer <[EMAIL PROTECTED]>, Andrew Pinski <[EMAIL PROTECTED]>,
> GCC List , <[EMAIL PROTECTED]>
> Subject: Re: Ada
Robert Dewar <[EMAIL PROTECTED]> writes:
[...]
| You are really just digging yourself into a hole here. It is clear
| that you know very little about floating-point arithmetic.
[...]
| More complete nonsense.
[...]
| Are you saying they are all idiots and you know better, or are you
| willing
- Can you give an example of an operation which may yield an undefined
non-deterministic result which is reliably useful for anything?
Hm. int foo (const char *x, int y) { return printf (x, y); }
Lassi
--
If you would know the value of money, go try to borrow some.
--Ben Franklin
Paul Schlie wrote:
What's silly, is claiming that such operations are bit exact when even
something as basic as their representational base radix number systems
isn't even defined by the standard, nor need necessarily be the same
between different FP types; thereby an arbitrary value
Dave Korn wrote:
I didn't say "Pseudo random number generation". I said "Random number
generation".
which once again has nothing whatever to do with non-determinism.
TO illustrate this, suppose I have a language which has sets of
integers. I have an operator ARB whose semantics is to selec
Paul Schlie wrote:
From: Dave Korn <[EMAIL PROTECTED]>
Original Message
From: Paul Schlie
Sent: 08 June 2005
- Can you give an example of an operation which may yield an undefined
non-deterministic result which is reliably useful for anything?
Random number generation?
rando
Original Message
>From: Paul Schlie
>Sent: 08 June 2005 14:49
>> From: Dave Korn <[EMAIL PROTECTED]>
>> Original Message
>>> From: Paul Schlie
>>> Sent: 08 June 2005 14:40
>>
>>> - Can you give an example of an operation which may yield an undefined
>>> non-deterministic result
> From: Dave Korn <[EMAIL PROTECTED]>
> Original Message
>> From: Paul Schlie
>> Sent: 08 June 2005 14:40
>
>> - Can you give an example of an operation which may yield an undefined
>> non-deterministic result which is reliably useful for anything?
>
> Random number generation?
- wh
Original Message
>From: Paul Schlie
>Sent: 08 June 2005 14:40
> - Can you give an example of an operation which may yield an undefined
> non-deterministic result which is reliably useful for anything?
Random number generation?
cheers,
DaveK
--
Can't think of a witty .s
> From: Robert Dewar <[EMAIL PROTECTED]>
> Paul Schlie wrote:
>
>> - yes, it certainly enables an implementation to generate more efficient
>> code which has no required behavior; so in effect basically produce more
>> efficient programs which don't reliably do anything in particular; which
>>
On Tue, Jun 07, 2005 at 05:49:54PM -0400, Robert Dewar wrote:
> * Paul Schlie:
>
> > (With an exception being FP optimization, as FP is itself based
> > only on the approximate not absolute representation of values.)
>
> Floating-point arithmetic is not simply some inaccurate representation
> o
Paul Schlie wrote:
- yes, it certainly enables an implementation to generate more efficient
code which has no required behavior; so in effect basically produce more
efficient programs which don't reliably do anything in particular; which
doesn't seem particularly useful?
You keep saying
* Paul Schlie:
(With an exception being FP optimization, as FP is itself based
only on the approximate not absolute representation of values.)
Floating-point arithmetic is not simply some inaccurate representation
of real arithmetic. It can be used this way by the programmer, but in
fact f
* Paul Schlie:
>> But the assertion is trivially true. If you impose fewer constraints
>> on an implementation by leaving some cases undefined, it always has
>> got more choices when generating code, and some choices might yield
>> better code. So code generation never gets worse.
>
> - yes, it
> From: Florian Weimer <[EMAIL PROTECTED]>
> * Paul Schlie:
>
>> - I'm not attempting to design a language, but just defend the statement
>> that I made earlier; which was in effect that I contest the assertion
>> that undefined evaluation semantics enable compilers to generate more
>> effic
* Paul Schlie:
> - I'm not attempting to design a language, but just defend the statement
> that I made earlier; which was in effect that I contest the assertion
> that undefined evaluation semantics enable compilers to generate more
> efficient useful code by enabling them to arbitrarily de
> From: Robert Dewar <[EMAIL PROTECTED]>
> Paul Schlie wrote:
> Fine, but then you are designing a different language from C.
- I'm not attempting to design a language, but just defend the statement
that I made earlier; which was in effect that I contest the assertion
that undefined evaluation
Florian Weimer wrote:
* Robert Dewar:
Defintiely not, integer overflow generates async traps on very few
architectures. Certainly synchronous traps can be generated (e.g.
with into on the x86).
Or the JO jump instruction. Modern CPUs choke on the INTO
instruction.
Well INTO is still the
* Robert Dewar:
> Defintiely not, integer overflow generates async traps on very few
> architectures. Certainly synchronous traps can be generated (e.g.
> with into on the x86).
Or the JO jump instruction. Modern CPUs choke on the INTO
instruction.
Paul Schlie wrote:
- Agreed, I would classify any expression as being ambiguous if any of
it's operand values (or side effects) were sensitive to the allowable
order of evaluation of it's remaining operands, but not otherwise.
But this predicate cannot be evaluated at compile time!
Now y
> From: Robert Dewar <[EMAIL PROTECTED]>
> Paul Schlie wrote:
>
>> Similar arguments has been given in support an undefined order of
>> evaluation; which is absurd, as the specification of a semantic order
>> of evaluation only constrains the evaluation of expressions which would
>> otherw
Eric Botcazou wrote:
Once again, have you actually examined how awtul the code we
generate now is?
Yes, I have. Indeed not pretty, but suppose that we managed to cut the
overhead in half, would that make -gnato really more attractive?
Yes, it would definitely make the difference, given the
Paul Schlie wrote:
Similar arguments has been given in support an undefined order of
evaluation; which is absurd, as the specification of a semantic order
of evaluation only constrains the evaluation of expressions which would
otherwise be ambiguous, as expressions which are insensitive
> From: Robert Dewar <[EMAIL PROTECTED]>
> Paul Schlie wrote:
>
>> - So technically as such semantics are undefined, attempting to track
>> and identify such ambiguities is helpful; however the compiler should
>> always optimize based on the true semantics of the target, which is
>> what the
Paul Schlie wrote:
- So technically as such semantics are undefined, attempting to track
and identify such ambiguities is helpful; however the compiler should
always optimize based on the true semantics of the target, which is
what the undefined semantics truly enable (as pretending a targ
On 6/6/05, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
> > Better use a union for the (final) conversion, i.e
> >
> > int conv(unsigned char *c)
> > {
> > unsigned int i;
> > union {
> > unsigned int u;
> > int i;
> > } u;
> >
> > u.u = 0;
> > for (i = 0; i < s
> From: Andrew Pinski <[EMAIL PROTECTED]>
>>> No they should be using -ftrapv instead which traps on overflow and then
>>> make sure they are not trapping when testing.
>>
>> - why? what language or who's code/target ever expects such a behavior?
> Everyone's who writes C/C++ should know that over
Better use a union for the (final) conversion, i.e
int conv(unsigned char *c)
{
unsigned int i;
union {
unsigned int u;
int i;
} u;
u.u = 0;
for (i = 0; i < sizeof u; i++)
u.u = (u.u << 8) + c[i];
return u.i;
}
This is not portable, though; access
On 6/6/05, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
> > There's also a fair amount of code whih relies on -1 ==
> > (int)0x.
> >
> > Or is there any truly portable and efficient way to convert a sequence
> > of bytes (in big-endian order) to a signed integer?
>
> Of course there is.
> Once again, have you actually examined how awtul the code we
> generate now is?
Yes, I have. Indeed not pretty, but suppose that we managed to cut the
overhead in half, would that make -gnato really more attractive?
> Well of course that's just a plain bug, should be addressed as such.
> Obvi
There's also a fair amount of code whih relies on -1 ==
(int)0x.
Or is there any truly portable and efficient way to convert a sequence
of bytes (in big-endian order) to a signed integer?
Of course there is. Assuming no padding bits:
int conv(unsigned char *c)
{
unsigned int
Eric Botcazou wrote:
Of course, it is not so dumb as to blatantly violate its specification.
If we use -ftrapv, then we have to make sure that operations labeled by the
front end as not requiring an overflow check are transformed into unsigned
operations by gigi.
I think it would be dange
> > Right, the code generated by the front end is not pretty either, but at
> > least the front-end knows what it is doing Ada-wise. -ftrapv is so dumb
> > at the moment that it emits checks for virtually anything.
>
> No, it just emits it for signed operations.
Of course, it is not so dumb as to
Eric Botcazou wrote:
-ftrapv is not practically usable because (1) it generates awful code and
(2) it badly interacts with the RTL optimizers.
please before you say this compare it with the truly awful front end
code we generate, which for sure inteferes badly with the optimizers.
Right, the
> > -ftrapv is not practically usable because (1) it generates awful code and
> > (2) it badly interacts with the RTL optimizers.
>
> please before you say this compare it with the truly awful front end
> code we generate, which for sure inteferes badly with the optimizers.
Right, the code generat
Eric Botcazou wrote:
For Ada, I propose we make the following changes:
- by default, enable overflow checks using -ftrapv
-ftrapv is not practically usable because (1) it generates awful code and (2)
it badly interacts with the RTL optimizers.
please before you say this compare it with
> For Ada, I propose we make the following changes:
>- by default, enable overflow checks using -ftrapv
-ftrapv is not practically usable because (1) it generates awful code and (2)
it badly interacts with the RTL optimizers.
--
Eric Botcazou
Geert Bosch wrote:
For Ada, I propose we make the following changes:
- by default, enable overflow checks using -ftrapv
This won't work, we generate plenty of cases of operations
where we definitely don't want a check, and we don't set the
flag, but currently the flag is ignored by gcc/gigi,
On Jun 3, 2005, at 09:02, Florian Weimer wrote:
It probably makes sense to turn on -fwrapv for Ada because even
without -gnato, the behavior is not really undefined:
| The reason that we distinguish overflow checking from other kinds of
| range constraint checking is that a failure of an overfl
On Fri, 2005-06-03 at 13:03 -0400, Paul Schlie wrote:
> > From: Joe Buck <[EMAIL PROTECTED]>
> >> On Fri, Jun 03, 2005 at 11:43:32AM -0400, Andrew Pinski wrote:
> >> Everyone's who writes C/C++ should know that overflow of signed is
> >> undefined.
> >
> > In practice, however, this issue is comm
> From: Joe Buck <[EMAIL PROTECTED]>
>> On Fri, Jun 03, 2005 at 11:43:32AM -0400, Andrew Pinski wrote:
>> Everyone's who writes C/C++ should know that overflow of signed is undefined.
>
> In practice, however, this issue is commonly ignored, because people code
> in a hurry, then test the behavior
> Everyone's who writes C/C++ should know that overflow of signed is undefined.
>
> Now in Java it is defined, which is the reason why -fwrapv exists in the
> place since GCC has a "Java" compiler.
Right. I also believe that it is conceptually wrong to enable this for
Ada, so until this issue is
On Fri, Jun 03, 2005 at 06:25:27PM +0200, Florian Weimer wrote:
> There's also a fair amount of code whih relies on -1 ==
> (int)0x.
While that is not portable, -(1U) is portably all-ones, even on 36 bit
one's complement machines or other oddball architectures, since unsigned
types are req
* Joe Buck:
> I'm sure there are plenty of production codes that assume signed integer
> overflow wraps, or at least make the weaker assumption that in
>
>a = b + c + d;
>
> where all variables are integers, if one of the intermediate terms
> can't be represented in an integer, we still ge
On Fri, Jun 03, 2005 at 11:43:32AM -0400, Andrew Pinski wrote:
> Everyone's who writes C/C++ should know that overflow of signed is undefined.
In practice, however, this issue is commonly ignored, because people code
in a hurry, then test the behavior of the executable code, and if on all
platform
* Paul Schlie:
>> No they should be using -ftrapv instead which traps on overflow and then
>> make sure they are not trapping when testing.
>
> - why? what language or who's code/target ever expects such a behavior?
I think Andrew wants programmers to fix their code, instead of
papering over prob
>
> > No they should be using -ftrapv instead which traps on overflow and then
> > make sure they are not trapping when testing.
>
> - why? what language or who's code/target ever expects such a behavior?
Everyone's who writes C/C++ should know that overflow of signed is undefined.
Now in Java i
> From: Andrew Pinski <[EMAIL PROTECTED]>
(Without -fwrapv, integer overflow is undefined, and subsequent range
checks can be optimized away, so that it might cause erroneous
behavior.)
>>>
>>> - Since for all practical purposes most (if not all) target's use
>>> 2's complement in
>
> * Paul Schlie:
>
> >> (Without -fwrapv, integer overflow is undefined, and subsequent range
> >> checks can be optimized away, so that it might cause erroneous
> >> behavior.)
> >
> > - Since for all practical purposes most (if not all) target's use
> > 2's complement integer representation
* Paul Schlie:
>> (Without -fwrapv, integer overflow is undefined, and subsequent range
>> checks can be optimized away, so that it might cause erroneous
>> behavior.)
>
> - Since for all practical purposes most (if not all) target's use
> 2's complement integer representations which naturally "
> (Without -fwrapv, integer overflow is undefined, and subsequent range
> checks can be optimized away, so that it might cause erroneous
> behavior.)
- Since for all practical purposes most (if not all) target's use
2's complement integer representations which naturally "wrap", might
it be sim
* Andrew Pinski:
> The Ada front-end is still being missed compiled by VRP but VRP is doing
> the correct thing as the type is signed and overflow on signed is
> undefined
> (-fwrapv is not turned on by default for Ada).
It probably makes sense to turn on -fwrapv for Ada because even
without -gn
62 matches
Mail list logo
