Re: svn commit: r285284 - head/lib/liblzma

2015-07-09 Thread David Chisnall
On 9 Jul 2015, at 03:53, NGie Cooper yaneurab...@gmail.com wrote:
 
 $ cat ~/has_immintrin.c
 #include sys/cdefs.h
 
 #if __has_include(immintrin.h)
 #error I have immintrin.h
 #else
 #error I don't have immintrin.h
 #endif
 $ clang -c ~/has_immintrin.c
 /home/ngie/has_immintrin.c:4:2: error: I have immintrin.h
 #error I have immintrin.h
 ^
 1 error generated.
 $ gcc -c ~/has_immintrin.c
 /home/ngie/has_immintrin.c:6:2: error: #error I don't have immintrin.h
 
 Sadly this macro wasn't added until gcc 5.x:
 https://gcc.gnu.org/gcc-5/changes.html

cdefs.h defines __has_include(x) to 0 if the compiler does not provide 
__has_include(), so this will also work with gcc in base (always claiming not 
to have immintrin.h).

David

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r285284 - head/lib/liblzma

2015-07-09 Thread NGie Cooper
On Thu, Jul 9, 2015 at 1:44 AM, David Chisnall thera...@freebsd.org wrote:
 On 9 Jul 2015, at 03:53, NGie Cooper yaneurab...@gmail.com wrote:

 $ cat ~/has_immintrin.c
 #include sys/cdefs.h

 #if __has_include(immintrin.h)
 #error I have immintrin.h
 #else
 #error I don't have immintrin.h
 #endif
 $ clang -c ~/has_immintrin.c
 /home/ngie/has_immintrin.c:4:2: error: I have immintrin.h
 #error I have immintrin.h
 ^
 1 error generated.
 $ gcc -c ~/has_immintrin.c
 /home/ngie/has_immintrin.c:6:2: error: #error I don't have immintrin.h

 Sadly this macro wasn't added until gcc 5.x:
 https://gcc.gnu.org/gcc-5/changes.html

 cdefs.h defines __has_include(x) to 0 if the compiler does not provide 
 __has_include(), so this will also work with gcc in base (always claiming not 
 to have immintrin.h).

Yes, but this case will fail for gcc 4.3 ~ 4.4 through 5.x if you use
my recommended method...
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r285284 - head/lib/liblzma

2015-07-09 Thread NGie Cooper
On Thu, Jul 9, 2015 at 2:23 AM, David Chisnall thera...@freebsd.org wrote:
 On 9 Jul 2015, at 10:19, NGie Cooper yaneurab...@gmail.com wrote:

 Yes, but this case will fail for gcc 4.3 ~ 4.4 through 5.x if you use
 my recommended method...

 I think that’s probably fine.  We basically have four cases that we care 
 about:

 - People who are using clang because it’s the system compiler [works]
 - People who are using new clang from ports / svn because it’s new and shiny 
 [works]
 - People who are using gcc from base because it’s the system compiler [works]
 - People who are using new gcc from ports / svn because it’s new and shiny 
 [works]

 The only people it doesn’t work for are the ones building FreeBSD using an 
 out-of-tree old GCC.  There probably aren’t too many of those…

Item 4. needs to be full understood when working with some features as
it could result in undefined behavior.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r285284 - head/lib/liblzma

2015-07-09 Thread David Chisnall
On 9 Jul 2015, at 10:19, NGie Cooper yaneurab...@gmail.com wrote:
 
 Yes, but this case will fail for gcc 4.3 ~ 4.4 through 5.x if you use
 my recommended method...

I think that’s probably fine.  We basically have four cases that we care about:

- People who are using clang because it’s the system compiler [works]
- People who are using new clang from ports / svn because it’s new and shiny 
[works]
- People who are using gcc from base because it’s the system compiler [works]
- People who are using new gcc from ports / svn because it’s new and shiny 
[works]

The only people it doesn’t work for are the ones building FreeBSD using an 
out-of-tree old GCC.  There probably aren’t too many of those…

David


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org

Re: svn commit: r285284 - head/lib/liblzma

2015-07-08 Thread Pedro Giffuni



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.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r285284 - head/lib/liblzma

2015-07-08 Thread Dimitry Andric
Check whether the path starts with /usr/bin, maybe?  Normally, you would
check for the existence of a random header in a configure script.  But
from within a C source file, it's not that easy.

That said, immintrin.h is available for all usable versions of clang,
and should be available in all versions of gcc = 4.4 (at least, if I
read gcc's commit history correctly).  And gcc in base is definitely not
4.4. :-)

-Dimitry

 On 09 Jul 2015, at 00:04, Adrian Chadd adrian.ch...@gmail.com wrote:
 
 Is there a blessed way to see whether the compiler we're using is an
 external compiler, or an internal one?
 
 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.)
 
 
 -a
 
 
 On 8 July 2015 at 14:09, Pedro Giffuni p...@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.
 
 



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: svn commit: r285284 - head/lib/liblzma

2015-07-08 Thread Adrian Chadd
Is there a blessed way to see whether the compiler we're using is an
external compiler, or an internal one?

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


-a


On 8 July 2015 at 14:09, Pedro Giffuni p...@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.

___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r285284 - head/lib/liblzma

2015-07-08 Thread Warner Losh
Not in this context, no. Nor should you want to in this context (inside the 
compiling module).
Generally in Makefiles it would be a bad idea too, but there’s sometimes you 
need to know.
But there’s currently not any such instances in the tree.

Warner

 On Jul 8, 2015, at 4:04 PM, Adrian Chadd adrian.ch...@gmail.com wrote:
 
 Is there a blessed way to see whether the compiler we're using is an
 external compiler, or an internal one?
 
 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.)
 
 
 -a
 
 
 On 8 July 2015 at 14:09, Pedro Giffuni p...@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.
 
 



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: svn commit: r285284 - head/lib/liblzma

2015-07-08 Thread Warner Losh
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.

Warner

 On Jul 8, 2015, at 4:28 PM, Adrian Chadd adrian.ch...@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 p...@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 p...@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.
 
 
 



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: svn commit: r285284 - head/lib/liblzma

2015-07-08 Thread NGie Cooper
On Wed, Jul 8, 2015 at 3:18 PM, Dimitry Andric d...@freebsd.org wrote:
 Check whether the path starts with /usr/bin, maybe?  Normally, you would
 check for the existence of a random header in a configure script.  But
 from within a C source file, it's not that easy.

 That said, immintrin.h is available for all usable versions of clang,
 and should be available in all versions of gcc = 4.4 (at least, if I
 read gcc's commit history correctly).  And gcc in base is definitely not
 4.4. :-)

$ cat ~/has_immintrin.c
#include sys/cdefs.h

#if __has_include(immintrin.h)
#error I have immintrin.h
#else
#error I don't have immintrin.h
#endif
$ clang -c ~/has_immintrin.c
/home/ngie/has_immintrin.c:4:2: error: I have immintrin.h
#error I have immintrin.h
 ^
1 error generated.
$ gcc -c ~/has_immintrin.c
/home/ngie/has_immintrin.c:6:2: error: #error I don't have immintrin.h

Sadly this macro wasn't added until gcc 5.x:
https://gcc.gnu.org/gcc-5/changes.html

Cheers,
-NGie
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r285284 - head/lib/liblzma

2015-07-08 Thread Pedro Giffuni



On 07/08/15 17:18, Dimitry Andric wrote:

Check whether the path starts with /usr/bin, maybe?  Normally, you would
check for the existence of a random header in a configure script.  But
from within a C source file, it's not that easy.

That said, immintrin.h is available for all usable versions of clang,
and should be available in all versions of gcc = 4.4 (at least, if I
read gcc's commit history correctly).  And gcc in base is definitely not
4.4. :-)


Ahh yes, it's probably gcc 4.4 (I stopped following their changes
long ago). Our internal gcc carries a couple of headers that were
introduced in gcc 4.3 before the license change.

Pedro.


-Dimitry


On 09 Jul 2015, at 00:04, Adrian Chadd adrian.ch...@gmail.com wrote:

Is there a blessed way to see whether the compiler we're using is an
external compiler, or an internal one?

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


-a


On 8 July 2015 at 14:09, Pedro Giffuni p...@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.



___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org



Re: svn commit: r285284 - head/lib/liblzma

2015-07-08 Thread Adrian Chadd
On 8 July 2015 at 15:34, Warner Losh i...@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.ch...@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 p...@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 p...@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.




___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r285284 - head/lib/liblzma

2015-07-08 Thread Adrian Chadd
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 p...@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 p...@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.


___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r285284 - head/lib/liblzma

2015-07-08 Thread Warner Losh
 
 On Jul 8, 2015, at 4:37 PM, Adrian Chadd adrian.ch...@gmail.com wrote:
 
 On 8 July 2015 at 15:34, Warner Losh i...@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.ch...@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 p...@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 p...@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.
 
 
 
 



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: svn commit: r285284 - head/lib/liblzma

2015-07-08 Thread Pedro Giffuni



On 07/08/15 17:28, Adrian Chadd wrote:

hi,

ok. would it be possible to add a blessed way to say this is the
freebsd modified compiler in-tree ?


Exactly why do you want this? We don't really have
many differences with the vendor versions.

Look at sys/sys/cdefs.h for examples on how we figure
out which features or attributes are available. I have been
exercising those in the libc headers extensively :).

Pedro.


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



___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r285284 - head/lib/liblzma

2015-07-08 Thread John-Mark Gurney
Pedro Giffuni wrote this message on Wed, Jul 08, 2015 at 16:09 -0500:
 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.

Looking at the header, immintrin.h, it looks like it's just a catch
all for various intrinsic headers...

And looking at the lzma code, the immintrin.h include could be replaced
w/ an emmintrin.h and things would be fine...

Though I don't see sse2 being enabled when compiling the library...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org


Re: svn commit: r285284 - head/lib/liblzma

2015-07-08 Thread Alexander Kabaev
On Wed, 8 Jul 2015 15:28:17 -0700
Adrian Chadd adrian.ch...@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
 

IIRC, FreeBSD's internal GCC defines __FreeBSD_cc_version, while stock
one does not.

-- 
Alexander Kabaev


pgph8eGhdprQc.pgp
Description: OpenPGP digital signature


Re: svn commit: r285284 - head/lib/liblzma

2015-07-08 Thread Pedro Giffuni



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



___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org