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

[Reed Kotler]

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.
>
I don't think patching gcc is going to solve this problem in the general 
sense.

But I think it would be valid to change the llvm configure script to not 
allow the use of any known
open source components that are going to cause problems (not just gcc). 
Configure is supposed
to sort out such issues typically.

The problem however is that when  llvm is built, we don't know what the 
user intends to use clang/llvm for.

Not everyone does "make check" so it's better to just not let them build 
the compiler in the first place.

Another possibility is to record some information inside the llvm/clang 
binary as to what it was built with and then if someone tries to compile 
code for the mips architecture, they get a warning if gcc x.y was used 
to build it and x.y is not a supported compiler. Or maybe not a warning 
even, just have the compiler abort.


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