svn commit: r285284 - head/lib/liblzma

[Warner Losh]

> 
> On Jul 8, 2015, at 4:37 PM, Adrian Chadd <adrian.chadd at gmail.com> wrote:
> 
> 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..

I’m having trouble understanding when this would be generally useful.
If we have a situation where the exact same clang version as we have in the tree
is also the version of the compiler a vendor released and there’s some substantial
difference between the two such that you need conditional code to make it work
on both, that might be one scenario. But such a scenario hasn’t come up in the
past very often, and generally it has been resolved with an ifdef __arch__ sort of
thing because the in-tree compiler didn’t support that CPU well enough to use,
while the out of tree one did.

Warner

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20150708/90e32ca4/attachment.bin>