lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


>>>>> "Philippe" == Philippe Verdy <verdy_p@wanadoo.fr> writes:

 >> Possibly unfortunately, this is not a bug. The program invokes
 >> undefined behavior when it does n=-n on the the value shown; the
 >> compiler is entitled to produce any output at all as a result.
 >> 
 >> In this case it's fairly obvious what happened: after seeing the line
 >> 
 >> if (n<0) n=-n;
 >> 
 >> the compiler is entitled to assume that n>=0 is true regardless of
 >> the prior value of n, since only undefined behavior could cause that
 >> not to be the case and the compiler is allowed to assume that
 >> undefined behavior never occurs. So in the second fprintf, the
 >> compiler can optimize (n>=0) to a constant 1, and (n<0) to a
 >> constant 0, while still computing the remaining tests.

 Philippe> Such compiler assumption is wrong

The language standards disagree. Now you might choose to disagree with
those standards, but they are what they are.

 Philippe> But with your code I do not get the same result as you,

What exactly did you compile and how, and with what?

I don't keep a large supply of compilers on hand, but putting the code
on godbolt and looking at the output for various compiler versions, it's
clear that the optimization I described above is in effect for gcc
versions back to at least 4.9, and clang from 7.0 onwards (notably,
clang 6.0 does _not_ do it). See for example line 46 of the assembler
output of https://godbolt.org/z/vE8qCi where the "pushq $1" shows that
a constant 1 was pushed for the result of the >= test.

It _looks_ like neither icc nor msvc do this optimization (but I'm not
sure I got sufficient optimization flags in, I don't use either of those
myself).

 Philippe> Finally, not just the compiler version is important here: you
 Philippe> may have used some advanced (but experimental) optimizing
 Philippe> options on its command line

For both clang and gcc a simple -O is sufficient to show the issue.
Obviously if optimization is entirely disabled, the problem does not
occur.

 Philippe> My opinion is that your GCC compiler version has a bug or you
 Philippe> used some unsupported options or non-standard/untested patch,
 Philippe> or your Linux distribution is not reliable and delivers you
 Philippe> very badly compiled products: change your Linux update source
 Philippe> or switch to a reliable distribution.

Since I'm not even using linux, and the issue is easily demonstrated
with compiler comparison tools, your "opinion" here is based on false
assumptions and therefore worthless.

-- 
Andrew.