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 I believe
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
doesn't
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
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?
- which if
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 which is reliably
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?
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 select
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
- 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
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
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 gcc@gcc.gnu.org, [EMAIL PROTECTED]
Subject: Re: Ada front-end depends on signed overflow
You
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 (normative) IEC
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() {
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 example
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 are no
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 seemingly
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 generated for well
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 GCC.
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/predictable
result.
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 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
* 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.
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
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
* 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
* 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 certainly
* 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
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
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
of real
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
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.
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. Assuming no
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;
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 overflow of
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 sizeof u; i++)
u.u
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
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 undefined
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
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
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
otherwise be
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,
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:
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
* 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
* 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 wrap,
* 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
* 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 problems.
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
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
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 of the
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 commonly ignored,
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
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
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
54 matches
Mail list logo
