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

[Reed Kotler]

I think that what Petar is saying is that all the Mips gcc compilers 
that are generally accessible have a problem with this construct.

If we apply what Petar says is a 2 line patch, then there is no problem.

Otherwise, there is a lot of work for us to do.

Are we at an impasse here?

You don't want to take the patch, even conditionally while this problem 
gets resolved in gcc?

Apparently there are other problems with this construct for Mips beyond 
what are published.

The problem I think can be resolved over a period of time by getting the 
proper patch for all the Mips cross compilers but that is going to take 
at least 3-6 months. Sometimes it can be longer if there is a lot of 
disagreement in the gcc community as to how to fix the problem.

Reed

On 07/25/2012 03:48 AM, Duncan Sands wrote:
> 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
>>
>