Dave Korn wrote:
You can have both, correctness and uninitialised local
variables. For an impression of the difference in performance,
and for a way to ensure correctness, I tried this
(switch register/volatile in the declaration lines in comp
and r to see the effects).
I didn't get
Paul Schlie wrote:
From: Georg Bauhaus [EMAIL PROTECTED]
Paul Schlie wrote:
From: Robert Dewar [EMAIL PROTECTED]
this would mean you could not put local variables in
registers. the effect on code quality woul be awful!
Why would anyone care about the
From: Georg Bauhaus [EMAIL PROTECTED]
2) if putting local variables in registers becomes impossible
there will be a significant cost. I wanted to get an impression
of the cost. That's the reason for writing volatile in the
declaration lines. Just for demo.)
I believe that was just a
Paul Schlie wrote:
In that case you may want to stick with -O0. There are *lots* of
things GCC does that alter undefined cases. How about the undefined
behavior when aliasing rules are violated? Would you want to make
-fno-strict-aliasing be the only supported setting?
- Isn't the
Georg Bauhaus wrote:
(There are at least two bugs in this :-/ but corrections
won't change the picture. Neither will initialisation.)
#define BUFFER_SIZE 1000 // must be 0
#define ITERATIONS 10 // must be 0
assert(hi 0);
for (size_t c=0; c hi + 2; ++c) {
if (a[c]) {
Original Message
From: Georg Bauhaus
Sent: 15 July 2005 14:21
You can have both, correctness and uninitialised local
variables. For an impression of the difference in performance,
and for a way to ensure correctness, I tried this
(switch register/volatile in the declaration lines in
From: Georg Bauhaus [EMAIL PROTECTED]
Paul Schlie wrote:
From: Robert Dewar [EMAIL PROTECTED]
Paul Schlie wrote:
I don't contest that it may, I simply don't believe it should.
you can't seriously mean that with respect to uninitialized
variables. this would mean you could not put local
Paul Schlie wrote:
As optimization seems to be a non-argument, as by analogy all
optimizations which are available for unsigned arithmetic are
correspondingly available for signed integer operations; as any signed
value may then be thought of as being unsigned for the purposes of
computation
Matthew == Matthew Woodcraft [EMAIL PROTECTED] writes:
Matthew Paul Schlie wrote:
As optimization seems to be a non-argument, as by analogy all
optimizations which are available for unsigned arithmetic are
correspondingly available for signed integer operations; as any
signed value may
Matthew Woodcraft writes:
Paul Schlie wrote:
As optimization seems to be a non-argument, as by analogy all
optimizations which are available for unsigned arithmetic are
correspondingly available for signed integer operations; as any signed
value may then be thought of as being unsigned for the
Paul Schlie wrote:
What about optimising x*2/2 to x?
Given that C requires the above be evaluated as (x*2)/2, as the language
specifies that the syntax defines the precedence of the operations, and that
no optimization should alter the behavior as specified by the program; I'd
say that
From: Robert Dewar [EMAIL PROTECTED]
Paul Schlie wrote:
What about optimising x*2/2 to x?
Given that C requires the above be evaluated as (x*2)/2, as the language
specifies that the syntax defines the precedence of the operations, and that
no optimization should alter the behavior as
Paul Schlie wrote:
I don't contest that it may, I simply don't believe it should.
you can't seriously mean that with respect to uninitialized
variables. this would mean you could not put local variables in registers.
the effect on code quality woul be awful!
From: Robert Dewar [EMAIL PROTECTED]
Paul Schlie wrote:
I don't contest that it may, I simply don't believe it should.
you can't seriously mean that with respect to uninitialized
variables. this would mean you could not put local variables in
registers. the effect on code quality woul be
Paul == Paul Schlie [EMAIL PROTECTED] writes:
From: Robert Dewar [EMAIL PROTECTED]
Paul Schlie wrote:
What about optimising x*2/2 to x?
Given that C requires the above be evaluated as (x*2)/2, as the
language specifies that the syntax defines the precedence of the
operations, and
From: Paul Koning [EMAIL PROTECTED]
Paul == Paul Schlie [EMAIL PROTECTED] writes:
From: Robert Dewar [EMAIL PROTECTED]
Paul Schlie wrote:
What about optimising x*2/2 to x?
Given that C requires the above be evaluated as (x*2)/2, as the
language specifies that the syntax defines the
... A computation involving unsigned operands can never overflow, because
a result that cannot be represented by the resulting unsigned integer type
is reduced modulo the number that is one greater than the largest value that
can be represented by the resulting type.
Although I don't intend
Paul Schlie wrote:
Although I don't intend to extend the debate; doesn't anyone find it curious
that given this hard requirement, combined with the fact that all current
machine architectures rely on 2's complement signed integer representation
to eliminate the otherwise necessity for distinct
From: Robert Dewar [EMAIL PROTECTED]
Paul Schlie wrote:
Although I don't intend to extend the debate; doesn't anyone find it curious
that given this hard requirement, combined with the fact that all current
machine architectures rely on 2's complement signed integer representation
to
On Mon, Jul 11, 2005 at 09:58:36AM -0500, Nicholas Nethercote wrote:
Hi,
There was recently a very long thread about the overflow behaviour of
signed integers in C. Apparently this is undefined according to the C
standard. I searched the standard on this matter, and while I did find
Hi,
There was recently a very long thread about the overflow behaviour of
signed integers in C. Apparently this is undefined according to the C
standard. I searched the standard on this matter, and while I did find
some paragraphs that described how unsigned integers must wrap around upon
Original Message
From: Nicholas Nethercote
Sent: 11 July 2005 15:59
Hi,
There was recently a very long thread about the overflow behaviour of
signed integers in C. Apparently this is undefined according to the C
standard. I searched the standard on this matter, and while I did
On Monday 11 July 2005 15:58, Nicholas Nethercote wrote:
Also, does anyone know what the required behaviour for Fortran integers is
on overflow?
Section 7.1.7 Evaluation of operation
The evaluation of any numeric operation whose result is not defined by the
arithmetic used by the processor[1]
On Mon, 11 Jul 2005, Dave Korn wrote:
There was recently a very long thread about the overflow behaviour of
signed integers in C. Apparently this is undefined according to the C
standard. I searched the standard on this matter, and while I did find
some paragraphs that described how unsigned
Original Message
From: Nicholas Nethercote
Sent: 11 July 2005 17:08
On Mon, 11 Jul 2005, Dave Korn wrote:
There was recently a very long thread about the overflow behaviour of
signed integers in C. Apparently this is undefined according to the C
standard. I searched the standard
25 matches
Mail list logo
