[PATCH] D13642: [Bugpoint] Allow fallback to clang

Davide Italiano via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 14 08:33:52 PDT 2015


On Wed, Oct 14, 2015 at 8:31 AM, Davide Italiano <davide at freebsd.org> wrote:
> On Wed, Oct 14, 2015 at 6:02 AM, Rafael EspĂ­ndola
> <rafael.espindola at gmail.com> wrote:
>>>> +  // Try to fall-back to clang if the user didn't pass GCC as option.
>>>> +  if (GCCBinary == "")
>>>> +    GCCBinary = "clang";
>>>> +
>>
>> I was actually thinking of
>>
>>  if (GCCBinary.empty()) {
>>   if (gcc exists)
>>     GCCBinary = "gcc";
>>   else
>>     GCCBinary = "clang";
>> }
>>
>
> I don't mind changing that as you request but is there a real reason
> why we can't use clang if available and the user doesn't specify GCC?
> The only one I can think of is that this changes the default, and may
> be potentially a POLA violation, but is this something really
> important?
>

To be more precise, I'd rather prefer:

if (GCCBinary is not specified) {
  if (clang exists)
     GCCBinary = "clang";
   else
    GCCBinary = "gcc";
}

>>> This is still a little bit weird because all the variables have GCC as prefix.
>>> If you're fine with this, I'll do a sweep and rename all of them. I
>>> thought about 'CCBinary, class CC' rather than 'GCCBinary, class GCC'
>>> etc.. but I'm open to new suggestions.
>>
>> It is OK to rename it, but lets do it in another patch.
>>
>
> Are you fine with 'CCBinary' or do you prefer something else?
>
> Thanks,
>
> --
> Davide
>
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare



-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare


More information about the llvm-commits mailing list