"John David Anglin" <[EMAIL PROTECTED]> writes:
> > No, the ISO C standard is clear that the value of an uninitialized
> > variable is indeterminate. It may be a trap representation, or it may
> > be an unspecified value. In the latter case it must have the correct
> > type. But there is no oth
> No, the ISO C standard is clear that the value of an uninitialized
> variable is indeterminate. It may be a trap representation, or it may
> be an unspecified value. In the latter case it must have the correct
> type. But there is no other restriction on it, and the standard
> specifically say
"John David Anglin" <[EMAIL PROTECTED]> writes:
| > > This seems pretty clear. C99 requires that storage be allocated
| > >
| > >for uninitialized objects, that an indeterminate value be stored
| > >in the object when the declarator for the object is reached in the
| > >block, that the last-stored
Steven Bosscher wrote:
It has absolutely _noting_ to do with unitialized variables or undefined
behavior. Nothing. Zilch. Zero.
Gr.
Steven
OK, I got the message!
> >For what it's worth, it annoys me to no end that you have managed to
> >turn more than a day of hard work to understand and fix PR24626 into
> >a discussion about defining undefined behavior. I don't think I'll
> >ever look at HPPA bugs anymore if they don't affect me.
>
> Well we have to under
On Sun, 14 Jan 2006, Ian Lance Taylor wrote:
> gcc assumes that if a variable is uninitialized, it can use any value
> whatsoever for any use of the variable. gcc does not assume that all
> uses of an uninitialized variable must have the same value.
Indeed, the rulings on DR#260 are perfectly cl
John David Anglin wrote:
#include
unsigned char
T (unsigned char x)
{
static int first = 1;
static unsigned char firstx;
if (first)
{
first = 0;
firstx = x;
return ~x;
}
if (x == firstx)
printf ("Behavior is pre GCC 4.0\n");
else
printf ("Behavior is GCC 4.0 an
Steven Bosscher wrote:
On Sunday 15 January 2006 22:13, John David Anglin wrote:
#include
unsigned char
T (unsigned char x)
{
static int first = 1;
static unsigned char firstx;
if (first)
{
first = 0;
firstx = x;
return ~x;
}
if (x == firstx)
printf ("Behavior
On Sunday 15 January 2006 22:13, John David Anglin wrote:
> #include
> unsigned char
> T (unsigned char x)
> {
> static int first = 1;
> static unsigned char firstx;
>
> if (first)
> {
> first = 0;
> firstx = x;
> return ~x;
> }
>
> if (x == firstx)
> printf (
> > This seems pretty clear. C99 requires that storage be allocated
> >
> >for uninitialized objects, that an indeterminate value be stored
> >in the object when the declarator for the object is reached in the
> >block, that the last-stored value be retained for the duration of
> >the block.
> >
Gabriel Dos Reis wrote:
Robert,
Recently you have expressed the opinion that sounds to me that GCC is
taking too much a cavalier approach to "undefined behaviour".
However, as long as you feed that line of thought with reasoning like
above, I don't see how the current trend will change. Or di
Robert Dewar <[EMAIL PROTECTED]> writes:
| John David Anglin wrote:
|
| > This seems pretty clear. C99 requires that storage be allocated
| >
| >for uninitialized objects, that an indeterminate value be stored
| >in the object when the declarator for the object is reached in the
| >block, that th
John David Anglin wrote:
As far as I know, GCC doesn't support a trap representation for
"int *" types. Thus, an "indeterminate value" is simply an unspecified
value.
You can't reason this way either. The implementation may behave "as if" the
variable contained a trap representation regardl
John David Anglin wrote:
This seems pretty clear. C99 requires that storage be allocated
for uninitialized objects, that an indeterminate value be stored
in the object when the declarator for the object is reached in the
block, that the last-stored value be retained for the duration of
the bloc
I've looked at the draft version of C99 that I have and it's
clear that there are some significant differences between the
draft that I have and the final. So, take what I say with a
grain of salt ;)
> I believe Dave's program results in undefined behavior by implication.
> That is, even though C
> From: Ian Lance Taylor
>> Paul Schlie <[EMAIL PROTECTED]> writes:
>> Given that it would appear that the only time the compiler may attempt
>> to optimize the allocation/use of an un-initialized variable, is when it
>> knows for certain it hasn't been initialized; might it be preferable to
>> th
Paul Schlie wrote:
- Thank you, I'll give it a try; although may attempt to name it:
-force-deterministic-semantics
Please don't, that's a dubious term, since it is
contentious, and detracts from the useful nature of this
proposition.
presuming its longer term intent would be to warrant
> From: Michael Veksler <[EMAIL PROTECTED]>
> In theory you could be right:
> ...
> Now, consider the case where the compiler can prove that
> is_debug_enabled(i) is always zero. So `a' is never initialized.
> Why can't the compiler assume that is_debug_verbose_enabled(i) is
> zero as well? By igno
Ian Lance Taylor wrote:
It would be perfectly reasonable to have a command line option to
initialize automatic variables to zero, of course.
Ada has a pragma Normalize_Scalars that causes all scalars to be
normalized (to an out of range
value where possible).
Even more useful is the GNAT
Paul Schlie <[EMAIL PROTECTED]> writes:
> Given that it would appear that the only time the compiler may attempt
> to optimize the allocation/use of an un-initialized variable, is when it
> knows for certain it hasn't been initialized; might it be preferable to
> then assign it a deterministic che
Paul Schlie <[EMAIL PROTECTED]> writes:
| Thank you for the explanation.
|
| Given that it would appear that the only time the compiler may attempt
| to optimize the allocation/use of an un-initialized variable, is when it
| knows for certain it hasn't been initialized; might it be preferable to
Paul,
In theory you could be right:
Quoting Paul Schlie <[EMAIL PROTECTED]>:
[...]
> Given that it would appear that the only time the compiler may attempt
> to optimize the allocation/use of an un-initialized variable, is when it
> knows for certain it hasn't been initialized; might it be prefer
Ian Lance Taylor writes:
| Paul Schlie <[EMAIL PROTECTED]> writes:
|
| > As a simple example, although x may be indeterminate -1 < sin(x) < +1
| > is unconditionally true, as must be tan(x) = sin(x)/cos(x), and x^x = 0;
|
| No, the ISO C standard is clear that an uninitialized variable may
Andreas Schwab <[EMAIL PROTECTED]> writes:
| Steven Bosscher <[EMAIL PROTECTED]> writes:
|
| > A more explicit statement about using uninitialized variables is in
| > appendix J.2 ("Undefined behavior"):
| >
| > "The behavior is undefined in the following circumstances:
| > (...snip...)
| > - Th
Thank you for the explanation.
Given that it would appear that the only time the compiler may attempt
to optimize the allocation/use of an un-initialized variable, is when it
knows for certain it hasn't been initialized; might it be preferable to
then assign it a deterministic cheap value such as
Paul Schlie wrote:
(or might it actually make substantially more sense for a compiler to
do what the code logically specified in absents of any more reliably
predictable alternative; under the premise that consistency is good.)
Paul, the semantics of C programs is given by the C standard, no
Ian Lance Taylor wrote:
Paul Schlie <[EMAIL PROTECTED]> writes:
As a simple example, although x may be indeterminate -1 < sin(x) < +1
is unconditionally true, as must be tan(x) = sin(x)/cos(x), and x^x = 0;
No, the ISO C standard is clear that an uninitialized variable may be
set t
So following through with this philosophy to its natural conclusion,
all programs which contain reachable non-portable undefined code should
have arbitrary behavior? Or should arbitrary potentially catastrophic
otherwise unexpected behavior only be invoked upon reaching such code?
(or might it act
Paul Schlie <[EMAIL PROTECTED]> writes:
> As a simple example, although x may be indeterminate -1 < sin(x) < +1
> is unconditionally true, as must be tan(x) = sin(x)/cos(x), and x^x = 0;
No, the ISO C standard is clear that an uninitialized variable may be
set to a trap representation (6.7.8,
Steven Bosscher <[EMAIL PROTECTED]> writes:
> A more explicit statement about using uninitialized variables is in
> appendix J.2 ("Undefined behavior"):
>
> "The behavior is undefined in the following circumstances:
> (...snip...)
> - The value of an object with automatic storage duration is used
Paul Schlie wrote:
tools which indiscriminately alter non-portable observable
behavior during optimization aren't doing anyone any favors.
What we want from a compiler is that it correctly executes
and interprets correct programs. What we want from
programmers is correct programs. Programmer
On Sunday 15 January 2006 10:35, Robert Dewar wrote:
> >- I believe that it is a grave mistake to conclude that a well defined
> > semantic operation on an indeterminate value, has undefined semantics.
>
> Well the standards committee made the grave mistake if it is one, so if
> you want to challe
tools which indiscriminately alter non-portable observable
behavior during optimization aren't doing anyone any favors.
conversely, tools which focus on optimizing portable behavior, while
attempting to preserve non-portable behavior, are always preferable.
> From: Robert Dewar <[EMAIL PROTECTED]
Paul Schlie wrote:
Ian Lance Taylor writes:
gcc assumes that if a variable is uninitialized, it can use any value
whatsoever for any use of the variable. gcc does not assume that all
uses of an uninitialized variable must have the same value.
It is of course possible to write a correct progra
> Ian Lance Taylor writes:
>
> gcc assumes that if a variable is uninitialized, it can use any value
> whatsoever for any use of the variable. gcc does not assume that all
> uses of an uninitialized variable must have the same value.
>
> It is of course possible to write a correct program which us
"John David Anglin" <[EMAIL PROTECTED]> writes:
> I have a question about storage for uninitialized objects.
>
> I made the mistake of looking at the code being generated for
> testcase #2 in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626.
> I noticed that reload used the same register r3 for
36 matches
Mail list logo
