[llvm-commits] [PATCH] [MIPS] Avoid use of __builtin_unreachable() when compiling LLVM for MIPS.

[Reed Kotler]

Before launching into my diatribe here, I would say that another way to 
solve this particular problem may be to exclude certain gcc from the 
build process in the configure script.

If we want to deprecate the building of llvm with gcc (as opposed to 
clang) then we should do that in the configure scripts.

But getting back to the discussion ....

Sure, you don't want 100 pages of if defs for every gcc compiler 
starting with 2.95 but that said, there is a "modern window" of gcc 
released compilers that need to be supported as well as other open 
source tool chains.

I fight all the time to keep all the Mips llvm users pulling from llvm 
tip of tree and NOT having local patches. Otherwise life gets very 
complicated fast. We can't be testing and debugging all kinds of 
variants of the source tree. We have Google, the mclinker project and 
other users besides just Mips itself.

Whatever has not been tested "does not work" That's my experience in life.

Only at Mips, right now, is there enough infrastructure to adequately 
test a Mips LLVM compiler.
We are continually testing tip of tree against many variants of using 
the Mips compiler (x86 host,
mips host, direct object emtiter, not direct object emitter, pic, static 
,,....)

Once someone patches it, all bets are off. Maybe it will still work and 
maybe it won't.

I can't really understand this purest logic you are applying here; it 
just makes a lot of unneeded work and ignores the fundamental reality of 
living in the collective world of open source.

It's probably a valid point that we should be building llvm with clang 
and not with gcc but even if Mips starts to do that internally, we can't 
control what Google does. We can influence what Google does and in time 
if it makes sense, I'm sure they would go the same way.

I think that the most important thing is to not have patched compilers 
existing anywhere except perhaps internally at Mips, where can actually 
test another variant if we need to. So for example, if Mips wants to 
release a "product" that is a variant of some llvm release point, we can 
keep such a branch and thoroughly test it. Others pulling from open 
source cannot do this.

So if Google or anyone else is pulling from llvm tip of trip, as long as 
the llvm build scripts allow it to be built with gcc, then it should 
work. The configure scripts can possibly rule out versions of gcc that 
are known not work.



On 07/25/2012 02:51 AM, Duncan Sands wrote:
> Hi,
>
>> I don't think that's a quite accurate portrayal of the issue... it's more "our
>> host compilers are full of bugs w.r.t. __builtin_unreachable". I think that's an
>> issue w/ the host compiler, and folks should either A) find a better host
>> compiler, or B) bootstrap and use a Clang-built tree.
> having now read the GCC bug reports I have to agree with Chandler here.
>
> Ciao, Duncan.
>
>> If B doesn't work for some reason, you should work on that. ;] Patches very
>> welcome there.
>>
>> I don't think its reasonable to hack around these broken compilers inside the
>> LLVM codebase. Applying local patches to satisfy your build environment is a
>> common reality.
>>
>>
>> I actually have a lot of sympathy for Reed's comment, but the fact is that this
>> patch hacks around bugs in the host compiler. That is a very slippery slope, and
>> frankly we are already sliding. I don't want more and more hacks to satisfy a
>> host compiler. This is especially true if the host compiler with problems is
>> some specific toolchain that none else would be using. You should file bugs and
>> get that toolchain fixed, and/or you should come up with a bootstrap solution.
>>
>>      That said, I personally think it was a mistake to replace
>>      assert(false) with llvm_unreachable in places that may be reachable but
>>      shouldn't happen.
>>
>>
>> I think the current llvm_unreachable definition is very workable -- it has nice
>> asserting logic in debug builds.
>>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits