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

[Duncan Sands]

Hi Reed,

> 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.

I did mention somewhere that I wouldn't lart you for it if you apply the patch!

> 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?

This is the bit that confuses me: I thought the problem had been resolved in gcc
already.  Is that not the case?

> 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.

If I read you right you are saying that every release of gcc (i.e. the latest
gcc-4.5, 4.6 and 4.7 releases) are all broken for MIPS right now, the breakage
being related to this construct - is that correct?

Ciao, Duncan.

>
> 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
>>>
>>
>