@cr1901 @RichFelker The adoption of link-time optimization will uncover a lot of these issues too. Not just compiler improvements.
-
-
Replying to @CopperheadOS
@CopperheadSec@cr1901 Indeed, most UB is undetectable by the compiler without explicit runtime checks since extern acts as compiler barrier2 replies 0 retweets 0 likes -
-
Replying to @cr1901
@cr1901@RichFelker Functions from other files (other than inline in headers) are opaque to the compiler without link-time optimization.1 reply 0 retweets 0 likes -
Replying to @CopperheadOS
@cr1901@RichFelker But with LTO, the compiler can optimize the program as a whole and that makes subtle cases of UB much more dangerous.1 reply 0 retweets 0 likes -
Replying to @CopperheadOS
@cr1901@RichFelker Without LTO, issues are usually confined to a single source file if there's no memory corruption.1 reply 0 retweets 0 likes -
Replying to @CopperheadOS
@CopperheadSec@RichFelker Oh, you're assuming the compiler can prove that signed overflow can't occur if it knows all the places >>1 reply 0 retweets 0 likes -
Replying to @cr1901
@CopperheadSec@RichFelker where side effects to an extern signed int occurs globally?1 reply 0 retweets 0 likes -
Replying to @cr1901
@cr1901@RichFelker For example, a call to foo(a, b). Lets say it does a + b internally. Now foo(a, b) is a guarantee to the compiler.1 reply 0 retweets 0 likes -
Replying to @CopperheadOS
@cr1901@RichFelker Without LTO, these kinds of assumptions can't be made across source files. It greatly limits the potential for breakage.2 replies 0 retweets 0 likes
@CopperheadSec @cr1901 Non-aliasing assumptions and resulting reordering are an even bigger issue buggy programs face with LTO.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.