Re: Is this a gcc bug?

Re: Is this a gcc bug?

[dewar]

<<undefined behavior: expression modifies `x' multiple times
>>

Of course it is also improper to write

 x + x++

and it would seem peculiar to say that this modifies x multiple times!

Re: Is this a gcc bug?

[Alexandre Oliva]

On Jan 13, 2001, dewar@gnat.com wrote:

> <<undefined behavior: expression modifies `x' multiple times
>>> 

> Of course it is also improper to write

>  x + x++

> and it would seem peculiar to say that this modifies x multiple times!

Ouch!  I thought of that yesterday, but I couldn't think of it today
:-(

I'm now inclined to have:

undefined behavior: incompatible uses of `x' between sequence points

`undefined behavior: ' might be omitted.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Is this a GCC bug?

[Bingfeng Mei]

Hello,
I encountered a problem in porting GCC (4.3.0) when I tried to make
contructor/destructor work. The following is the error message compiling
crtstuff.c.  

../../src/gcc/crtstuff.c: In function 'call___do_global_ctors_aux': 
../../src/gcc/crtstuff.c:562: error: expected string literal before '('
token 

Line 562 is:
...
CRT_CALL_STATIC_FUNCTION (INIT_SECTION_ASM_OP, __do_global_ctors_aux)
...

The following is how the macro CRT_CALL_STATIC_FUNCTION is defined. 

#ifndef CRT_CALL_STATIC_FUNCTION
# define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC) \
static void __attribute__((__used__))   \
call_ ## FUNC (void)     \
{       \
  asm (SECTION_OP);     \
  FUNC ();      \
  FORCE_CODE_SECTION_ALIGN    \
  asm (TEXT_SECTION_ASM_OP);    \
}
#endif

Here is the C code of line 562 after preprocessing in our porting:
static void __attribute__((__used__)) call___do_global_ctors_aux (void)
{ asm ("\t.section\t.init"); __do_global_ctors_aux (); asm
((firepath_fnsc ? "\t.section .textc, \"axC\"" : "\t.section .text,
\"axU\"")); }


The error is because inline asm only accepts string literal, not an
expression.  Our definitiion of TEXT_SECTION_ASM_OP is a string depends
on one of our particular targets. 

According to GCC internal manual, it is clearly stated that
TEXT_SECTION_ASM_OP can be an expression. 

TEXT_SECTION_ASM_OP
A C expression whose value is a string, including spacing, containing
the assembler
operation that should precede instructions and read-only data. Normally
"\t.text"
is right.

So I guess either internal manual or crtstuff.c is wrong. Or I am making
some stupid mistake here. Could someone have a look at this?  Thanks in
advance.

Cheers,
Bingfeng Mei
Broadcom UK

RE: Is this a GCC bug?

[Bingfeng Mei]

I realized I probably need to write CRT_CALL_STATIC_FUNCTION myself.
That should solve the issue. 

-----Original Message-----
From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On Behalf Of
Bingfeng Mei
Sent: 16 June 2008 14:01
To: gcc@gcc.gnu.org
Subject: Is this a GCC bug?

Hello,
I encountered a problem in porting GCC (4.3.0) when I tried to make
contructor/destructor work. The following is the error message compiling
crtstuff.c.  

../../src/gcc/crtstuff.c: In function 'call___do_global_ctors_aux': 
../../src/gcc/crtstuff.c:562: error: expected string literal before '('
token 

Line 562 is:
...
CRT_CALL_STATIC_FUNCTION (INIT_SECTION_ASM_OP, __do_global_ctors_aux)
...

The following is how the macro CRT_CALL_STATIC_FUNCTION is defined. 

#ifndef CRT_CALL_STATIC_FUNCTION
# define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC) \
static void __attribute__((__used__))   \
call_ ## FUNC (void)     \
{       \
  asm (SECTION_OP);     \
  FUNC ();      \
  FORCE_CODE_SECTION_ALIGN    \
  asm (TEXT_SECTION_ASM_OP);    \
}
#endif

Here is the C code of line 562 after preprocessing in our porting:
static void __attribute__((__used__)) call___do_global_ctors_aux (void)
{ asm ("\t.section\t.init"); __do_global_ctors_aux (); asm
((firepath_fnsc ? "\t.section .textc, \"axC\"" : "\t.section .text,
\"axU\"")); }


The error is because inline asm only accepts string literal, not an
expression.  Our definitiion of TEXT_SECTION_ASM_OP is a string depends
on one of our particular targets. 

According to GCC internal manual, it is clearly stated that
TEXT_SECTION_ASM_OP can be an expression. 

TEXT_SECTION_ASM_OP
A C expression whose value is a string, including spacing, containing
the assembler
operation that should precede instructions and read-only data. Normally
"\t.text"
is right.

So I guess either internal manual or crtstuff.c is wrong. Or I am making
some stupid mistake here. Could someone have a look at this?  Thanks in
advance.

Cheers,
Bingfeng Mei
Broadcom UK

Re: Is this a gcc bug?

[Axel Kittenberger]

Falk Hueffner wrote:
> > 
> > Michael Eager <eager@mvista.com> writes:
> > 
> > > My sugguestion:
> > >
> > >       undefined behavior:  value of expression using 'x' is undefined
> > 
> > This would seem to imply that the behaviour is undefined because one
> > uses an undefined value. But that's not the case: the standard says
> > program behaviour is undefined even if you say x = ++x and never look
> > at x again. (At least IIRC.)
> 
> It is the result of the expression (including any side effects) which is 
> undefined.  An expression has a value, even if you never use it.
> 
> There are many constructs with undefined behavior.  Some can be
> recognized at compile time; most cannot.  

How about the compile-error:
"detected undefined behaviour: [some actual explanation]"?

..if gcc is able to see it in this case?

-- 
Sent through GMX FreeMail - http://www.gmx.net

Re: Is this a gcc bug?

[dewar]

<<I don't think that even a brilliant optimizer can make any conclusion
about j's value, based on the assumption that j!=4 is the only situation
where the expression is well defined.
>>

On the contrary. The logic goes like this:

1. If j == 4, then the program does undefined things, it can do anything
it wants.

2. The compiler therefore has complete freedom to generate any code it
likes if j==4.

3. One special case of this freedom is that it can generate code that does
the same thing as if j != 4.

4. This is a good choice since it eliminates a test.

So an optimizer can indeed make this assumption, and it is quite difficult
to word an informal standard to avoid this (it may be even harder to word
a formal standard to prevent this).

undefined is a nasty semantic concept :-)

Re: Is this a gcc bug?

[dewar]

<<It doesn't follow, though, that the printf output is not interleaved
with the mandatory diagnostics (if any).
>>

That's different from my reading, my reading is that the mandatory
diagnostics have to come out even if the section of code is not run.

The printf output comes out only if the section of code is run.

Of course if there are mandatory diagnostics, then exeution is
undefined in any case.

Re: Is this a gcc bug?

[Dave Korn]

----- Original Message -----
From: <dewar@gnat.com>
Sent: Monday, January 15, 2001 12:14 AM


> <<It doesn't follow, though, that the printf output is not interleaved
> with the mandatory diagnostics (if any).
> >>
>
> That's different from my reading, my reading is that the mandatory
> diagnostics have to come out even if the section of code is not run.
>
> The printf output comes out only if the section of code is run.
>
> Of course if there are mandatory diagnostics, then exeution is
> undefined in any case.

  So when compiling a case like this, we could print out a short and
obtuse error message, and output an executable which when run prints the
long sermon explanation to stderr :)

   DaveK

Re: Is this a gcc bug?

[dewar]

<<The standard doesn't distinguish between 'run time' and 'compile
time'.
>>

That's a misunderstanding, yes, of course the standard distinguishes
between dynamic and static semantics. When you write a printf statement,
it does not generate output at compile time, and the standard is pretty
clear on this point :-)

Re: Is this a gcc bug?

[Geoff Keating]

> From: dewar@gnat.com
> Cc: gcc@gcc.gnu.org
> Date: Sun, 14 Jan 2001 08:31:57 -0500 (EST)
> 
> <<The standard doesn't distinguish between 'run time' and 'compile
> time'.
> >>
> 
> That's a misunderstanding, yes, of course the standard distinguishes
> between dynamic and static semantics. When you write a printf statement,
> it does not generate output at compile time, and the standard is pretty
> clear on this point :-)

It doesn't follow, though, that the printf output is not interleaved
with the mandatory diagnostics (if any).

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Is this a gcc bug?

[dewar]

<<For the Mercury compiler, many error messages have two different forms,
one of which includes additional information such as hints about possible
causes of the error.  By default, the compiler prints the concise versions,
plus a line at the end of the compiler output saying "For more information,
recompile with `-E'", which is the compiler option to enable the more
verbose messages.  I think this is a good compromise.
>>

But that's a response about verbosity, my question which I repeat:

> So the question is, should an error message like this try to educate,
> or just take the simple minded non-determinstic viewpoint.

is about point of view. These are orthogonal issues.

Re: Is this a gcc bug?

[Fergus Henderson]

On 12-Jan-2001, dewar@gnat.com <dewar@gnat.com> wrote:
> <<For the Mercury compiler, many error messages have two different forms,
> one of which includes additional information such as hints about possible
> causes of the error.  By default, the compiler prints the concise versions,
> plus a line at the end of the compiler output saying "For more information,
> recompile with `-E'", which is the compiler option to enable the more
> verbose messages.  I think this is a good compromise.
> >>
> 
> But that's a response about verbosity, my question which I repeat:
> 
> > So the question is, should an error message like this try to educate,
> > or just take the simple minded non-determinstic viewpoint.
> 
> is about point of view. These are orthogonal issues.

They're not entirely orthogonal, since if you're restricted to using
only concise error messages, then often you don't have sufficient room
to educate.

The simple-minded viewpoint could easily mislead the user,
while the correct viewpoint could confuse the uneducate user.
If the choice is between being misled or being confused,
I think it is better to leave the user confused, so long as
we give them a hint about how to obtain more information.
With a `--verbose-diagnostics' option, as outlined above,
that is quite feasible.  So I vote for trying to educate.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: Is this a gcc bug?

[dewar]

<<undefined behavior: expression may modify `x' multiple times
>>

That's probably OK in practice, but it is of course a lie, at least
one of omission, the sentence after the colon does represent a
possible outcome. But we could also write:

undefined behavior: expression may not modify x at all.

Now both are equally correct semantically, though of course the first
one is more likely to represent what the code does EXCEPT that clever
optimizers can make all sorts of assumptions that result in strange
behavior. For example:

    x = y[4]++ + y[j]++;

the optimizer is allowed to conclude that j!=4, and to propagate this
information both forwards and backwards. The backwards propagation
can be especially surprising. Suppose that just before is the statement:

   if (j != 4) delete_system_disk();

then the compiler could in theory call delete system disk without 
testing the value of j at all :-)

So the question is, should an error message like this try to educate,
or just take the simple minded non-determinstic viewpoint.

One of the things that happens as C compilers optimize more, is that people
who make improper assumptions can run into serious trouble, so I think there
is some argument for education here.

Re: Is this a gcc bug?

[Joseph S. Myers]

On Fri, 12 Jan 2001 dewar@gnat.com wrote:

> So the question is, should an error message like this try to educate,
> or just take the simple minded non-determinstic viewpoint.

The manual already documents sequence points (under -Wsequence-point) -
perhaps error messages that might confuse should reference the manual
rather than attempting to do their own education within the constraints of
an error message of reasonable length?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Is this a gcc bug?

[Alexandre Oliva]

On Jan 13, 2001, dewar@gnat.com wrote:

> <<undefined behavior: expression may modify `x' multiple times
>>> 

> That's probably OK in practice, but it is of course a lie, at least
> one of omission, the sentence after the colon does represent a
> possible outcome. But we could also write:

> undefined behavior: expression may not modify x at all.

I knew I should have written:

undefined behavior: expression modifies `x' multiple times

but then I recalled there might be false positives...

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Is this a gcc bug?

[Fergus Henderson]

On 12-Jan-2001, dewar@gnat.com <dewar@gnat.com> wrote:
> 
> So the question is, should an error message like this try to educate,
> or just take the simple minded non-determinstic viewpoint.

For the Mercury compiler, many error messages have two different forms,
one of which includes additional information such as hints about possible
causes of the error.  By default, the compiler prints the concise versions,
plus a line at the end of the compiler output saying "For more information,
recompile with `-E'", which is the compiler option to enable the more
verbose messages.  I think this is a good compromise.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: Is this a gcc bug?

[James Dennett]

dewar@gnat.com wrote:

> <<undefined behavior: expression may modify `x' multiple times
> 
> 
> That's probably OK in practice, but it is of course a lie, at least
> one of omission, the sentence after the colon does represent a
> possible outcome. But we could also write:
> 
> undefined behavior: expression may not modify x at all.
> 
> Now both are equally correct semantically, though of course the first
> one is more likely to represent what the code does EXCEPT that clever
> optimizers can make all sorts of assumptions that result in strange
> behavior. For example:
> 
>     x = y[4]++ + y[j]++;
> 
> the optimizer is allowed to conclude that j!=4, and to propagate this
> information both forwards and backwards. The backwards propagation
> can be especially surprising. Suppose that just before is the statement:
> 
>    if (j != 4) delete_system_disk();
> 
> then the compiler could in theory call delete system disk without 
> testing the value of j at all :-)

Nice example of plausibility.  (Can you do the same to show how the
compiler can produce nasal demons?)

> 
> So the question is, should an error message like this try to educate,
> or just take the simple minded non-determinstic viewpoint.

Education Good, ignorance Bad.

SGI's C++ compiler, with appropriate flags, gives short sermons when
code is broken according to the relevant Standards, and I have found
that this goes some way

> One of the things that happens as C compilers optimize more, is that people
> who make improper assumptions can run into serious trouble, so I think there
> is some argument for education here.

My experience is that most programmers don't realize how much they
are relying on non-portable features of dumb optimizers.  Where
possible, good (even verbose) warning/error messages are helpful.

-- James Dennett <jdennett@acm.org>

Re: Is this a gcc bug?

[Michael Eager]

dewar@gnat.com wrote:
> 
> <<undefined behavior: expression may modify `x' multiple times
> >>
> 
> That's probably OK in practice, but it is of course a lie, at least
> one of omission, the sentence after the colon does represent a
> possible outcome. But we could also write:
> 
> undefined behavior: expression may not modify x at all.
> 
> Now both are equally correct semantically, though of course the first
> one is more likely to represent what the code does EXCEPT that clever
> optimizers can make all sorts of assumptions that result in strange
> behavior. For example:
> 
>     x = y[4]++ + y[j]++;
> 
> the optimizer is allowed to conclude that j!=4, and to propagate this
> information both forwards and backwards. The backwards propagation
> can be especially surprising. Suppose that just before is the statement:
> 
>    if (j != 4) delete_system_disk();
> 
> then the compiler could in theory call delete system disk without
> testing the value of j at all :-)

I don't think that even a brilliant optimizer can make any conclusion 
about j's value, based on the assumption that j!=4 is the only situation 
where the expression is well defined.  

From logic:  undefined ==> anything,  not undefined ==> something

At best, the compiler could determine that the value of the expression
is not defined under some circumstances.

> So the question is, should an error message like this try to educate,
> or just take the simple minded non-determinstic viewpoint.

My preference is for messages which succinctly say what the problem
is, without trying to guess too much about what the code is doing.
The more guessing, in my opinion, the less clear the message.

My sugguestion:  

	undefined behavior:  value of expression using 'x' is undefined 

> 
> One of the things that happens as C compilers optimize more, is that people
> who make improper assumptions can run into serious trouble, so I think there
> is some argument for education here.

-- 

Michael Eager
Senior Tools Developer	  Phone: (408) 328-8426
MontaVista Software, Inc.   Fax: (408) 328-9204
1237 E. Arques Avenue	    Web: www.hardhatlinux.com
Sunnyvale, CA 94085	  Email: eager@mvista.com

Re: Is this a gcc bug?

[Falk Hueffner]

Michael Eager <eager@mvista.com> writes:

> My sugguestion:  
> 
> 	undefined behavior:  value of expression using 'x' is undefined 

This would seem to imply that the behaviour is undefined because one
uses an undefined value. But that's not the case: the standard says
program behaviour is undefined even if you say x = ++x and never look
at x again. (At least IIRC.)

BTW, I would really like to mention the warning "sequence point" so
people have something to look up.

	Falk

Re: Is this a gcc bug?

[Michael Eager]

Falk Hueffner wrote:
> 
> Michael Eager <eager@mvista.com> writes:
> 
> > My sugguestion:
> >
> >       undefined behavior:  value of expression using 'x' is undefined
> 
> This would seem to imply that the behaviour is undefined because one
> uses an undefined value. But that's not the case: the standard says
> program behaviour is undefined even if you say x = ++x and never look
> at x again. (At least IIRC.)

It is the result of the expression (including any side effects) which is 
undefined.  An expression has a value, even if you never use it.

There are many constructs with undefined behavior.  Some can be
recognized at compile time; most cannot.  

-- 

Michael Eager
Senior Tools Developer	  Phone: (408) 328-8426
MontaVista Software, Inc.   Fax: (408) 328-9204
1237 E. Arques Avenue	    Web: www.hardhatlinux.com
Sunnyvale, CA 94085	  Email: eager@mvista.com

Re: Is this a gcc bug?

[Axel Kittenberger]

yuppi, a warning brainstorming :-)

how about: 
-----------
bug.i:8: unpredictable behaviour due to undefined evaluation sequence of
'x'
-----------
it's not the shortest, but I think it's both correct and understanding.

I donnot know how gcc warning polices are, but wouldn't it be desirable
having this warning enabled by default? since the original syntax is never
correct c.

-- 
Sent through GMX FreeMail - http://www.gmx.net

Re: Is this a gcc bug?

[Alexandre Oliva]

On Jan 12, 2001, Axel Kittenberger <Anshil@gmx.net> wrote:

> bug.i:8: unpredictable behaviour due to undefined evaluation sequence of
> 'x'

It's the behavior that is undefined.  How about:

undefined behavior: expression may modify `x' multiple times

> I donnot know how gcc warning polices are, but wouldn't it be desirable
> having this warning enabled by default? since the original syntax is never
> correct c.

I'm inclined to agree.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Is this a gcc bug?

[Fergus Henderson]

On 13-Jan-2001, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jan 12, 2001, Axel Kittenberger <Anshil@gmx.net> wrote:
> 
> > bug.i:8: unpredictable behaviour due to undefined evaluation sequence of
> > 'x'
> 
> It's the behavior that is undefined.  How about:
> 
> undefined behavior: expression may modify `x' multiple times

You also get the warning for cases like

	printf("%d %d\n", x++, x);

where cause of the undefined behaviour is not that `x' was modified
multiple times, but that `x' was both modified and read.  The warning
that you suggest would not be appropriate in these cases.

It might be good to give different warnings for these two different
kinds of problems, depending on whether they violate the first
sentence of C99 6.5 #2, or the second:

 | 	Between the previous and next sequence point an object
 | 	shall have its stored value modified at  most  once  by  the
 | 	evaluation  of  an expression.  Furthermore, the prior value
 | 	shall be read only to determine the value to be stored.70)

For those that violate the first sentence, your suggested warning sounds OK.
But for those that violate the second, something like

	warning: undefined behavior: expression modifies `x' and reads `x'

would be better.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: Is this a gcc bug?

[Richard Earnshaw]

> On Jan 12, 2001, Axel Kittenberger <Anshil@gmx.net> wrote:
> 
> > bug.i:8: unpredictable behaviour due to undefined evaluation sequence of
> > 'x'
> 
> It's the behavior that is undefined.  How about:
> 
> undefined behavior: expression may modify `x' multiple times

But it may not modify `x' multiple times, yet it can still be undefined.  
Consider (as I posted before)

	y = x++ + x;

Since Dewar didn't like my has multiple interpretations suggestion how 
about

	expression containing 'x' has undefined value.

R.

Re: Is this a gcc bug?

[dewar]

<<Expression containing 'x' has undefined meaning (more than one
interpretation possible).
>>

I find that wrong enough to be confusing, the problem is not that
there are multiple interpretations, it is that the result is
undefined. You do NOT want to teach people, incorrectly, that
this has non-deterministic (but otherwise defined) semantics,
since that's not what the standard says. The current error
message is better than the above suggestion.

Re: Is this a gcc bug?

[dewar]

<<How about, multiple side-effects on 'x' between sequence points?
>>

That seems at the wrong level to me, someone who knows what a sequence
point is will understand the original message, someone who does not
will be mystefied. I would say something like "in a single statement".
Yes, it's not accurate, but trying to be too accurate can confused
the uninitiated :-)

Re: Is this a gcc bug?

[dewar]

<<I must say this is a very confusing error message, especally to
someone who does is not aware of the problem.  I'm not sure I could
even begin to guess what it meant!
>>

Well it is hard to make error messages meaningful in a case where someone
does not know the language. At the very least this warning will warn someone
that this is the case (that there is something they don't know about). For
anyone who knows C, this is certainly an OK message.

I am all in favor of trying to make the message a little clearer if possible,
but the important thing is to have SOME warning come out that will warn
someone that they either are doing something wrong that they will understand
immediately, or that they need help because there is something they don't
understand.

it is always tricky to know whether to aim messages at someone who knows
the language or someone who does not, or somewhere in between.

(reminds me of when my son worked at Tower Records, in the classical
dept, and when someone would ask "what's playing", he had to make a
judgment on whether to say

Beethoven's Fifth

or

This is the remastered Berlin Philharmonic performance with Karjan conducting

and if he got it wrong, he got either a blank stare, or annoyance :-)

RE: Is this a gcc bug?

[David Korn]

>> > How about something like:
>> >         warning: 'x' may have unexpected value because of 
>side-effects
>> > or
>> >         warning: side-effects make value of 'x' undefined
>> > or
>> >         warning: undefined order of side-effects on 'x'
>> > One might replace "side-effects" by "updates" or "changes to".
>> 
>> How about, multiple side-effects on 'x' between sequence points?
>
>"sequence points" is standardese and doesn't mean anything to 
>most users.
>Even "side-effects" may be surprising -- I don't think a user thinks
>of the increment of x in x++ as a "side effect".
>
>How about:
>
>warning: the order of the modifications to 'x' is undefined

  How about:

warning: extra-nasal demons invoked on line #xxx, please report to 
comp.lang.c to be flamed.

       DaveK  <g>

ps. Of course, we'd be within the language spec to emit code to format the
user's hard drive at that point, but let's be merciful. Maybe it should
just kick off nethack, or compile a quick version of wumpus or somesuch....
-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anything 
offered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to large 
numbers of others. This is my contribution to the survival of the online
community." 


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: Is this a gcc bug?

[Andy Walker]

David Korn wrote:

> <clip>
>   How about:
>
> warning: extra-nasal demons invoked on line #xxx, please report to
> comp.lang.c to be flamed.
>
>        DaveK  <g>
>
> ps. Of course, we'd be within the language spec to emit code to format the
> user's hard drive at that point, but let's be merciful. Maybe it should
> just kick off nethack, or compile a quick version of wumpus or somesuch....

or

Warning: Multiple uses of 'x' in statement modifying 'x'.  Statement results
are implementation dependant.  Randomizer invoked to minimize predicability.
Attempting to reformat all Hard Drives: Failed.

Just because you warn that you are doing it does not mean you have to succeed.

    Andy

Re: Is this a gcc bug?

[Joern Rennecke]

> Warning: Multiple uses of 'x' in statement modifying 'x'.  Statement results
> are implementation dependant.  Randomizer invoked to minimize predicability.
> Attempting to reformat all Hard Drives: Failed.

The standard only talks about undefined behaviour at program run time, not
at compile time.

Of course, you could argue that the standard doesn't forbid you to reformat
all hard drives at compilation time, but then, you could do that irrespective
of the input program.  I'd say that's a quality of implementation issue.

Re: Is this a gcc bug?

[Geoff Keating]

Joern Rennecke <amylaar@cambridge.redhat.com> writes:

> > Warning: Multiple uses of 'x' in statement modifying 'x'.  Statement results
> > are implementation dependant.  Randomizer invoked to minimize predicability.
> > Attempting to reformat all Hard Drives: Failed.
> 
> The standard only talks about undefined behaviour at program run time, not
> at compile time.

The standard doesn't distinguish between 'run time' and 'compile
time'.

> Of course, you could argue that the standard doesn't forbid you to reformat
> all hard drives at compilation time, but then, you could do that irrespective
> of the input program.  I'd say that's a quality of implementation issue.

I agree.  It's better that the compiler doesn't do weird stuff, no
matter what the input---the compiler should not dump core, should not
crash your system, and should always print a helpful error message on
invalid input.  Indeed, this is a QoI issue.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

RE: Is this a gcc bug?

[dewar]

<<Already there.  You just have to turn on warnings.
>>

Fair enough, I did not realize this particular warning was there (since
I have never written any code that did that myself :-)

RE: Is this a gcc bug?

[dewar]

it seems like it would not be hard to implement a warning for the case where
a variable is incremented or decremented somewhere in a statement, and
referenced elsewhere (this is not all the difficult cases, but is a very
high fraction of them). This would also catch macros where this happens
less visibly.

RE: Is this a gcc bug?

[Bernd Schmidt]

On Thu, 11 Jan 2001 dewar@gnat.com wrote:

> it seems like it would not be hard to implement a warning for the case where
> a variable is incremented or decremented somewhere in a statement, and
> referenced elsewhere (this is not all the difficult cases, but is a very
> high fraction of them). This would also catch macros where this happens
> less visibly.

Already there.  You just have to turn on warnings.


$ ./cc1 bug.i -Wall
 main
bug.i: In function `main':
bug.i:8: warning: implicit declaration of function `printf'

bug.i:8: warning: operation on `x' may be undefined

bug.i:8: warning: operation on `x' may be undefined

bug.i:8: warning: operation on `x' may be undefined


Bernd

Re: Is this a gcc bug?

[Per Bothner]

On Thu, 11 Jan 2001 dewar@gnat.com wrote:
> it seems like it would not be hard to implement a warning for the case where
> a variable is incremented or decremented somewhere in a statement, and
> referenced elsewhere

Bernd Schmidt <bernds@redhat.com> writes:
> Already there.  You just have to turn on warnings.
>
> $ ./cc1 bug.i -Wall
>  main
> bug.i: In function `main':
> bug.i:8: warning: operation on `x' may be undefined

I must say this is a very confusing error message, especally to
someone who does is not aware of the problem.  I'm not sure I could
even begin to guess what it meant!

How about something like:
        warning: 'x' may have unexpected value because of side-effects
or
        warning: side-effects make value of 'x' undefined
or
        warning: undefined order of side-effects on 'x'
One might replace "side-effects" by "updates" or "changes to".
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: Is this a gcc bug?

[Richard Earnshaw]

> How about something like:
>         warning: 'x' may have unexpected value because of side-effects
> or
>         warning: side-effects make value of 'x' undefined
> or
>         warning: undefined order of side-effects on 'x'
> One might replace "side-effects" by "updates" or "changes to".

How about, multiple side-effects on 'x' between sequence points?

Re: Is this a gcc bug?

[Alexandre Oliva]

On Jan 11, 2001, Richard Earnshaw <rearnsha@arm.com> wrote:

>> How about something like:
>> warning: 'x' may have unexpected value because of side-effects
>> or
>> warning: side-effects make value of 'x' undefined
>> or
>> warning: undefined order of side-effects on 'x'
>> One might replace "side-effects" by "updates" or "changes to".

> How about, multiple side-effects on 'x' between sequence points?

I think it's too technical.  How about `evaluation order of `x' is
undefined'?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Is this a gcc bug?

[Joe Buck]

> 
> > How about something like:
> >         warning: 'x' may have unexpected value because of side-effects
> > or
> >         warning: side-effects make value of 'x' undefined
> > or
> >         warning: undefined order of side-effects on 'x'
> > One might replace "side-effects" by "updates" or "changes to".
> 
> How about, multiple side-effects on 'x' between sequence points?

"sequence points" is standardese and doesn't mean anything to most users.
Even "side-effects" may be surprising -- I don't think a user thinks
of the increment of x in x++ as a "side effect".

How about:

warning: the order of the modifications to 'x' is undefined

Re: Is this a gcc bug?

[Bernd Schmidt]

On Thu, 11 Jan 2001, Joe Buck wrote:

> >
> > > How about something like:
> > >         warning: 'x' may have unexpected value because of side-effects
> > > or
> > >         warning: side-effects make value of 'x' undefined
> > > or
> > >         warning: undefined order of side-effects on 'x'
> > > One might replace "side-effects" by "updates" or "changes to".
> >
> > How about, multiple side-effects on 'x' between sequence points?
>
> "sequence points" is standardese and doesn't mean anything to most users.
> Even "side-effects" may be surprising -- I don't think a user thinks
> of the increment of x in x++ as a "side effect".
>
> How about:
>
> warning: the order of the modifications to 'x' is undefined

Possibly "may be undefined".  I think the wording "may" was put there
intentionally because the first versions of this code tended to generate
false positives now and then.  This can probably still happen with the
current version in some rare cases.


Bernd

Re: Is this a gcc bug?

[Richard Earnshaw]

> On Thu, 11 Jan 2001, Joe Buck wrote:
> 
> > >
> > > > How about something like:
> > > >         warning: 'x' may have unexpected value because of side-effects
> > > > or
> > > >         warning: side-effects make value of 'x' undefined
> > > > or
> > > >         warning: undefined order of side-effects on 'x'
> > > > One might replace "side-effects" by "updates" or "changes to".
> > >
> > > How about, multiple side-effects on 'x' between sequence points?
> >
> > "sequence points" is standardese and doesn't mean anything to most users.
> > Even "side-effects" may be surprising -- I don't think a user thinks
> > of the increment of x in x++ as a "side effect".
> >
> > How about:
> >
> > warning: the order of the modifications to 'x' is undefined
> 
> Possibly "may be undefined".  I think the wording "may" was put there
> intentionally because the first versions of this code tended to generate
> false positives now and then.  This can probably still happen with the
> current version in some rare cases.

Well, I don't know if we catch it, but "x++ + x" is also undefined, but 
there is only one modification.  How about:

Expression containing 'x' has undefined meaning (more than one 
interpretation possible).

R.

Re: Is this a gcc bug?

[Neil Booth]

Per Bothner wrote:-

> I must say this is a very confusing error message, especally to
> someone who does is not aware of the problem.  I'm not sure I could
> even begin to guess what it meant!

I agree!

> How about something like:
>         warning: 'x' may have unexpected value because of side-effects

IMO that's the clearest.

Neil.

Re: Is this a gcc bug?

[dewar]

  I would expect the result to be "0, 5, 7, 22".

That's the only strange thing here, you have no right to expect this. You
are assuming left to right semantics, but there is no such requirement in
C. 

RE: Is this a gcc bug?

[David Korn]

>From: Uros Bizjak [ mailto:uros@kss-loka.si ]
>Sent: 11 January 2001 10:11

>  This code produces a strange result on Solaris 2.5.1 with gcc 2.8.1:
>
>--cut here--
>
>#include <stdio.h>
>int main()
>{
>        int x = 0;
>        int y = 5;
>        int z = 15;
>
>        printf ("%i, %i, %i, %i\n", x,  x += y, x += 2, x += z); 
>        return 0;
>}
>
>--cut here--
>
>  It displays "22, 5, 7, 22".
>  I would expect the result to be "0, 5, 7, 22".

  The code isn't valid.  It is part of the language specification that you
cannot rely on the order of evaluation of arguments to a function call, nor
can you rely on when the side effects take place.  There's a technical
thing about these things called sequence points and how you're only allowed
to change the value of a variable once between them, but that's quite 
in-depth.  If you called 

   printf("%d %d %d\n", x++, x++, x++);

the compiler is free to pass the same value for all three occurrences of x
and add three to it after the function call, or to evaluate the arguments
from left to right and pass 0, 1, 2, or from right to left and pass 2, 1, 0,
or indeed (since the language spec says this is undefined behaviour) to 
output a program that plays space invaders when you run it.  Steer clear
of such ambiguous constructs and you'll be ok.

      DaveK
-- 
The Boulder Pledge: "Under no circumstances will I ever purchase anything 
offered to me as the result of an unsolicited email message. Nor will I 
forward chain letters, petitions, mass mailings, or virus warnings to large 
numbers of others. This is my contribution to the survival of the online
community." 


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Is this a gcc bug?

[Uros Bizjak]

Hello!

  This code produces a strange result on Solaris 2.5.1 with gcc 2.8.1:

--cut here--

#include <stdio.h>
int main()
{
        int x = 0;
        int y = 5;
        int z = 15;

        printf ("%i, %i, %i, %i\n", x,  x += y, x += 2, x += z); 
        return 0;
}

--cut here--

  It displays "22, 5, 7, 22".
  I would expect the result to be "0, 5, 7, 22".

	Uros.

Re: Is this a gcc bug?

[Alexandre Oliva]

On Jan 11, 2001, Uros Bizjak <uros@kss-loka.si> wrote:

>         printf ("%i, %i, %i, %i\n", x,  x += y, x += 2, x += z); 

>   It displays "22, 5, 7, 22".
>   I would expect the result to be "0, 5, 7, 22".

Undefined behavior.  A variable is modified more than once without
intervening sequence points.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me