svn commit: r285284 - head/lib/liblzma

[Adrian Chadd]

On 8 July 2015 at 15:34, Warner Losh <imp at bsdimp.com> wrote:
> I doubt it would ever be useful.
> For gcc, just test for 4.2.1.
> For clang, what specific feature do you need to test for?
>
> Do you have a specific use case in mind?
>
> This strikes me as a really bad idea absent some use case that has a real example behind it.

Well, vendors have in the past shipped modified compilers for systems
they're doing bring-up on. So if there are differences between the
in-tree compiler for a given clang version and the vendor supplied
modified one, I'd like to know.

I know it's going to be a while until another CPU family with a
not-yet-upstream compiler comes out..



-a

> Warner
>
>> On Jul 8, 2015, at 4:28 PM, Adrian Chadd <adrian.chadd at gmail.com> wrote:
>>
>> hi,
>>
>> ok. would it be possible to add a blessed way to say "this is the
>> freebsd modified compiler in-tree" ?
>>
>> I'd like to see / play around with more external-toolchain driven
>> building and using it for port bringups.
>>
>> Thanks,
>>
>>
>> -adrian
>>
>>
>> On 8 July 2015 at 15:22, Pedro Giffuni <pfg at freebsd.org> wrote:
>>>
>>>
>>> On 07/08/15 17:04, Adrian Chadd wrote:
>>>>
>>>> Is there a blessed way to see whether the compiler we're using is an
>>>> external compiler, or an internal one?
>>>
>>>
>>> No blessed way: you still have to determine the version of
>>> the external compiler for most purposes anyways.
>>> The internal compiler (even clang) always reports itself
>>> as gcc 4.2.
>>>
>>>> eg, the version check isn't enough - it's just a number. how do I know
>>>> if it's freebsd clang versus upstream clang?
>>>> (Or in my instance, freebsd-gcc versus upstream-gcc.)
>>>
>>>
>>> If the compiler reports itself as gcc >= 4.3 it is surely an
>>> external compiler. The tricky part is that our internal gcc
>>> supports some gcc 4.3 flags and Apple extensions
>>> (blocks), but those are not causing a problem AFAICT.
>>>
>>> Pedro.
>>>
>>>
>>>>
>>>> -a
>>>>
>>>>
>>>> On 8 July 2015 at 14:09, Pedro Giffuni <pfg at freebsd.org> wrote:
>>>>>
>>>>>
>>>>> On 07/08/15 13:36, Luigi Rizzo wrote:
>>>>>>
>>>>>> Author: luigi
>>>>>> Date: Wed Jul  8 18:36:37 2015
>>>>>> New Revision: 285284
>>>>>> URL: https://svnweb.freebsd.org/changeset/base/285284
>>>>>>
>>>>>> Log:
>>>>>>    only enable immintrin when clang is used. The base gcc does not
>>>>>> support
>>>>>> it.
>>>>>>       Reviewed by:      delphij
>>>>>>
>>>>>> Modified:
>>>>>>    head/lib/liblzma/config.h
>>>>>>
>>>>>> Modified: head/lib/liblzma/config.h
>>>>>>
>>>>>>
>>>>>> ==============================================================================
>>>>>> --- head/lib/liblzma/config.h   Wed Jul  8 18:12:24 2015
>>>>>> (r285283)
>>>>>> +++ head/lib/liblzma/config.h   Wed Jul  8 18:36:37 2015
>>>>>> (r285284)
>>>>>> @@ -150,7 +150,8 @@
>>>>>>   #define HAVE_ICONV 1
>>>>>>     /* Define to 1 if you have the <immintrin.h> header file. */
>>>>>> -#if defined(__FreeBSD__) && defined(__amd64__)
>>>>>> +/* FreeBSD - only with clang because the base gcc does not support it
>>>>>> */
>>>>>> +#if defined(__clang__) && defined(__FreeBSD__) && defined(__amd64__)
>>>>>>   #define HAVE_IMMINTRIN_H 1
>>>>>>   #endif
>>>>>>
>>>>> FWIW, gcc 4.3+ does have it so this may some undesired (but hidden)
>>>>> effect when building with an external gcc.
>>>>>
>>>>> Pedro.
>>>>>
>>>
>>
>