On 2018-05-09 20:04, Wols Lists wrote: > > As mentioned, I wonder why gcc/clang do not yet support this > > horribly slow but spectre-safe option. It can't be that hard to > > implement in the actual code-producing back-end. > > Given the response by the gcc team to security people complaining that > gcc was optimising out security-sensitive code (namely, a two-fingered > salute near enough), I doubt the gcc team would have any interest in > optimisations that SLOWED DOWN the resultant code. > > I suspect that might be one of the forces driving the kernel towards > CLANG - a development team that is not obsessed with performance at > the expense of breaking any code that uses undefined features.
I'm afraid I side with the gcc people in this interminable flamewar. Code may be "security-sensitive" but buggy. Is the compiler writer really responsible for guessing what the programmer meant to accomplish with buggy code? It would of course be preferable if the compiler could just abort with an error when it detects UB, but that turns out to be very hard to impossible in the case of C. That's just a built in problem with the language. Further, I don't think the llvm/clang position on these cases is all that different, although there may be a difference in emotional attitude. > Unfortunately, when dealing with hardware, one is forced to rely on > undefined features. A strong point of C, until the compiler decides to > go "rogue" on you ... I don't understand what you mean here. In the disputed cases there was always a well-defined way (slightly more verbose but not prohibitively so) to code the desired behavior. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
