On C-optimizing compilers removing code that has undefined behavior

Re:On C-optimizing compilers removing code that has undefine... by mcherm on Saturday June 17, 2017 @05:46AM (#14575071)

I am 100% in agreement with the C standard committee on this one. Treating all use of uninitialized memory as undefined behavior is a reasonable limitation that gives compiler writers a great deal of flexibility to improve performance. If the only loss is the ability to use uninitialized memory as a source of entropy for random number generators, then that is an incredibly low price to pay for the increased performance.

[ Parent | on HN ]

Re:On C-optimizing compilers removing code that has undefine... by GedByrne on Saturday June 17, 2017 @05:49AM (#14575076)

Then why isn't the code being disallowed? Why is it being silently removed in the middle of the night through an optimization back door?

[ Parent | on HN ]

Re:On C-optimizing compilers removing code that has undefine... by pornel on Saturday June 17, 2017 @07:04AM (#14575305)

It is disallowed by the standard.

It's not disallowed by compilers, because they're deficient. In this case I'd guess compiler front-end doesn't track which values in an array are initialized, and when optimizing back-end sees UB it's too late to emit an error.

[ Parent | on HN ]

Re:On C-optimizing compilers removing code that has undefine... by vyodaiken on Tuesday June 20, 2017 @10:05PM (#14600112)

They are improving performance in what way? My compiler: read input; emit nop, improves performance too.

[ Parent | on HN ]

Re:On C-optimizing compilers removing code that has undefine... by mcherm on Monday June 26, 2017 @08:57AM (#14636376)

If your program ALSO compiles VALID programs correctly, and somehow those are faster because it replaces INVALID programs with a nop, that sounds great!

[ Parent | on HN ]