On Fri, Aug 21, 2020 at 10:54:57AM -0700, Linus Torvalds wrote: > On Fri, Aug 21, 2020 at 10:29 AM Arvind Sankar <nivedita@xxxxxxxxxxxx> wrote: > > > > This one is slightly different from the previous one. The first case is > > really a call to __builtin_free(). > > No, the first case is a disgrace and a compiler bug. > > We've had a situation where gcc complained about a static function > called "free()", without any header file inclusion, and then > complained about it not matching its idea of what "free()" is. > > Which is pure and utter garbage. > > It's like you have a local variable "int free", and the compiler says > "hey, this doesn't match the prototype that I know this name should > have". It's BS. You just saw the user not just *use* that name, but > *define* it, and do it in a scope where the complaint is irrelevant > and stupid, and when we hadn't even included the header that would > have resulted in conflicts. > > IOW, it's an example of a compiler that thinks "it knows better". > > It's a broken compiler. And it's an example of the kind of breakage > that compilers absolutely shouldn't do. That's -Wbuiltin-declaration-mismatch, and can be turned off, and it won't warn if you have -fno-builtin-free. I don't completely agree with you, though warning for static functions is a bit overzealous. For an external function, especially something more obscure like stpcpy(), I appreciate the warning. > > The second example is from clang doesn't something horribly horribly stupid. Calm down man :) > > > This one is turning something that wasn't a function call into > > __builtin_bzero(), and I would hope that no-builtin-bzero would stop it > > as well. OTOH, the compiler is free to turn it into memset(), just like > > it could for structure/array initializers. > > The whole "the compiler is free to do X" argument is pure BS. Stop > repeating that bogus argument. > > Of COURSE a compiler can do whatever the hell it wants. > > That doesn't change the fact that certain things are broken beyond > words and utterly stupid, and a compiler that does them is a *BAD* > compiler. > > Turning four stores into a memset() is garbage. Just admit it, instead > of trying to say that it's allowed. > Look, four stores into memset(), yeah that's a bit weird. I didn't think you meant "four" literally. But in any case, that has nothing to do with the topic at hand. It would be just as bad if it was a 16-byte structure being initialized with an out-of-line memset() call. But coming back to the actual topic: it is fine if the compiler turns four stores into __builtin_memset(). A size-16 or -32 __builtin_memset() will get inlined anyway. There's a lot of garbage here if you look closely: check out what gcc does to initialize a 7-character array with zeros at -Os.
