Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Weird compiler bug – Same code, different results

blog.zaita.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Weird compiler bug – Same code, different results

#21

Post by zaitanz »

wiml wrote: post #9
lysium wrote: post #3

I would have never thought that the output of some floating point operations depend on the „reset of the floating point package“. What gives?

Some kind of internal state specific to Microsoft's libm? It doesn't look like _fpreset() is present anywhere else. Though in general, IEEE-754 math does have a small amount of global state, for stuff like rounding modes and subnormals. Perhaps the spawned thread's fenv was unexpected. I'm not super convinced by this blog post anyway, since it immediately confuses associativity with commutativity.

Op here. Yea this only occurs on Windows with MinGW. Visual C++ and Clang do not have this issue. None of the Linux compilers I tested also had this issue.

And yea you're right on the associative mistake. Will correct this :)

Re: Weird compiler bug – Same code, different results

#22

Post by zaitanz »

titzer wrote: post #2

Do not use C/C++ for numerical code where accuracy is needed. These languages are not specified to conform to IEEE 754 and you are absolutely asking for trouble.

Op here. There is a huge amount of scientific code written in C++. Just have a look through https://www.coin-or.org/

This code was specifically C++ because we had the intention of integrating with libraries like CppAD and ADOL-C.

Re: Weird compiler bug – Same code, different results

#23

Post by qayxc »

parekhnish wrote: post #11
titzer wrote: post #2

Do not use C/C++ for numerical code where accuracy is needed. These languages are not specified to conform to IEEE 754 and you are absolutely asking for trouble.

So, what should be used?

The correct - but useless - answer is: any language that's IEC 60559:xxxx conformant.

Examples are: Fortran, R, C#, Java, D and many others.

You'd need to refer to a language's specification to find out, though some aren't very well defined. zig comes to mind; it supports the data types and offers strict mode, but doesn't explicitly state its IEE 754:2008 compliance.

Re: Weird compiler bug – Same code, different results

#24

Post by zaitanz »

brucehoult wrote: post #4

If you read the article you find that this is a bug in MinGW64 libraries. It's not a compiler bug, it's not a problem in C/C++, or even in IEEE-754 floating point math. The MinGW64 thread library simply forgot to initialize the FPU correctly. He'd have had the same problem if he wrote his code in assembly language and then ran it in a MinGW64 thread.

Yes this is technically true, but it manifests itself through use of the MinGW compiler. When I first noticed the problem, there was very little indication as to the cause.

TBH I accredit dumb luck more than anything to finding the cause of this. It took many hours.

Re: Weird compiler bug – Same code, different results

#25

Post by mhh__ »

titzer wrote: post #2

Do not use C/C++ for numerical code where accuracy is needed. These languages are not specified to conform to IEEE 754 and you are absolutely asking for trouble.

Keep in mind that C++ doesn't exist. The compilers all have ways of enforcing compliance.

Intel C++ seems to be pretty naughty in that it effectively has fast-math on by default.

Re: Weird compiler bug – Same code, different results

#26

Post by zaitanz »

lysium wrote: post #3

I would have never thought that the output of some floating point operations depend on the „reset of the floating point package“. What gives?

TBH. I had no idea this was a thing either. I was incredibly confused when I identified a single piece of code that was producing an variation in result.

Re: Weird compiler bug – Same code, different results

#27

Post by zaitanz »

jcranmer wrote: post #19
titzer wrote: post #18

Earlier quoted context omitted.

No, they consistently perform optimizations that violate IEEE 754 rules, such as reassociation and commutation of expressions. These are difficult to observe (unless you are in the habit of observing -0 vs 0), but yes, you can observe them. They are very precisely specified by IEEE 754 and C/C++ compilers perform illegal optimizations.

They do those optimizations when you enable fast-math flags. Some compilers (e.g., icc) enable those by default. When fast-math is not enabled, then the IEEE 754-violating optimizations are disabled. Source: I've been working on such optimizations this past week. And that means establishing precisely which flags I need to have enabled in order for optimization to kick in.

This is very true. Once upon a time -o3 would enable fast-math. We're very careful to ensure we use test models to verify the outputs of release binaries. Enabling fast-math as you have said optimises the equations in a way that produces different results.

Re: Weird compiler bug – Same code, different results

#28

Post by cozzyd »

cperciva wrote: post #7
lysium wrote: post #3

I would have never thought that the output of some floating point operations depend on the „reset of the floating point package“. What gives?

Probably the author is accidentally getting 80-bit "extended double" arithmetic.

That should be clear from looking at the assembly, shouldn't it? Don't think the floating point environment can change that but I could be wrong.

Floating-point rounding modes seem more likely to me. The author should be able to dump the floating point configuration to confirm, I'm sure.

Re: Weird compiler bug – Same code, different results

#29

Post by chrchang523 »

zaitanz wrote: post #21
wiml wrote: post #9

Earlier quoted context omitted.

Some kind of internal state specific to Microsoft's libm? It doesn't look like _fpreset() is present anywhere else. Though in general, IEEE-754 math does have a small amount of global state, for stuff like rounding modes and subnormals. Perhaps the spawned thread's fenv was unexpected. I'm not super convinced by this blog post anyway, since it immediately confuses associativity with commutativity.

Op here. Yea this only occurs on Windows with MinGW. Visual C++ and Clang do not have this issue. None of the Linux compilers I tested also had this issue. And yea you're right on the associative mistake. Will correct this :)

I currently build Windows binaries via cross-compilation on Linux using gcc-mingw-w64; I assume that is affected by the bug?

Re: Weird compiler bug – Same code, different results

#30

Post by zaitanz »

chrchang523 wrote: post #29
zaitanz wrote: post #21

Earlier quoted context omitted.

Op here. Yea this only occurs on Windows with MinGW. Visual C++ and Clang do not have this issue. None of the Linux compilers I tested also had this issue. And yea you're right on the associative mistake. Will correct this :)

I currently build Windows binaries via cross-compilation on Linux using gcc-mingw-w64; I assume that is affected by the bug?

Most likely. You can check with the pastebin code https://pastebin.com/thTapSgn . Local and Thread outputs should be the same.
Post reply on HN