This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: compilation error of odd C/C++ program
- To: tbrick at cs dot uoregon dot edu
- Subject: Re: compilation error of odd C/C++ program
- From: "Martin v. Loewis" <martin at mira dot isdn dot cs dot tu-berlin dot de>
- Date: Mon, 9 Aug 1999 23:25:33 +0200
- CC: gcc-bugs at gcc dot gnu dot org
- References: <NDBBLCJMJKPCFPJAIFPLKEGCCAAA.tbrick@cs.uoregon.edu>
> > I have attached the appropriate files (according to the "How to
> > Report Bugs" section of the faq). Due to the lack of a specified
> > order of evaluation in some arithmetic expressions in C/C++, this
> > program has more than one possible correct output. However, I'm
> > quite certain that the output it produces when compiled with g++,
> > with no optimization is not a possible correct output. I have
> > included that in the command line session I copied and pasted.
Thanks for your bug report. With gcc 2.95, on i486-pc-linux-gnu, I get
7
7
Nevertheless, either is correct with regard to the C++ standard. It
says, in 5 [expr]/4
>> Between the previous and next sequence point a scalar object shall
>> have its stored value modified at most once by the evaluation of an
>> expression. Furthermore, the prior value shall be accessed only to
>> determine the value to be stored. The requirements of this
>> paragraph shall be met for each allowable ordering of the
>> subexpressions of a full expression; otherwise the behavior is
>> undefined.
According to 1.4.13, [defns.undefined], undefined behaviour is defined
as
>> behavior, such as might arise upon use of an erroneous program
>> construct or of erroneous data, for which the Standard imposes no
>> requirements.
So the compiler could do anything, from re-formatting your hard drive
to rebooting the universe - it would still be "correct". The standard
elaborates
>> [Note: permissible undefined behavior ranges from ignoring the
>> situation completely with unpredictable results, to behaving during
>> translation or program execution in a documented manner
>> characteristic of the environment (with or without the issuance of
>> a diagnostic message), to terminating a translation or execution
>> (with the issuance of a diagnostic message). Note that many
>> erroneous program constructs do not engender undefined behavior;
>> they are required to be diagnosed. ]
Regards,
Martin