It's also a great example of how your defenses create bugs out of thin air ;-)
-
-
no, the bug was human error, whereas the defense was automated.
1 reply 0 retweets 1 like -
The first bug was defense error, the workaround for it had a human error, triggering defense.
1 reply 0 retweets 0 likes -
no, the first problem (not bug per se) was due to gcc internals, the defense itself was fine.
1 reply 0 retweets 0 likes -
It's not a GCC bug, it's a problem with the defense making wrong assumptions.
2 replies 0 retweets 0 likes -
You don't get to blame the project you depend on for the failings/limitations of your approach.
2 replies 0 retweets 0 likes -
"if GCC didn't do foo" - but it does, and *you* are responsible for dealing with it.
1 reply 0 retweets 0 likes -
and when did i not deal with 'it'? (your not reading the docs isn't my fault but yours)
1 reply 0 retweets 1 like -
Papering over the issue with endless kernel patches isn't "dealing with it". Fix the plugin.
2 replies 0 retweets 0 likes -
gcc's plugin architecture makes it impossible, but i told you that before, didn't i?
1 reply 0 retweets 0 likes
You did. It's still not an excuse for enabling fundamentally broken plugins by default.
-
-
good thing we don't have any such plugins ;).
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.