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

[Duncan Sands]

Hi Reed, I'm not sure I understand what you are trying to say.  All I'm saying
is: if gcc-4.5 is buggy then don't use it.  Another solution would have been to
back-port the fix to gcc-4.5 so it would turn up in gcc-4.5.5 but unfortunately
the gcc-4.5 release branch has now been closed so it is too late: there will be
no more point releases.

Ciao, Duncan.

PS: In order to stop other people using it for MIPS, you can add it to the list
of broken compilers in GettingStarted.html and add a testcase that will fail if
someone does try to build LLVM using MIPS gcc-4.5.  Then you can point them to
the broken compilers list when they report the failing test.

PPS: All that said, if this is the only issue you are having with gcc-4.5 then
I'm not going to lart you if you commit the llvm_unreachable change.

On 25/07/12 12:34, Reed Kotler wrote:
> So we are testing the llvm tip of tree every day to make sure it passes all of
> our test suites at Mips.
>
> In that way, if someone pulls from llvm tip of tree and wants to build things
> for Mips processors, then there is a high degree of certainty that the compiler
> will work.
>
> Of course, when Mips starts to make it's own product cycle for Mips released
> tool chains, it's possible to have the usual local patches at Mips and very long
> test cycles in order to get the most stable and highest quality compiler. I'm
> sure that Apple has some internal group that is doing just this for their Arm
> and X86 compilers. Such a level of testing is never possible when someone is
> just pulling from the daily tip of tree at llvm.
>
>
> On 07/25/2012 03:15 AM, Reed Kotler wrote:
>> 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
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>