# Different CPUTYPE for clang and gcc



## Invarianz (Apr 27, 2020)

I have problems building gcc9 and certain packages depending on gcc9. The issue seems to be the line `CPUTYPE?= penryn` in my /etc/make.conf. Whereas clang correctly knows that CPU type, gcc doesnt. Is there any way to change the `CPUTYPE` for packages that need to be build with gcc?
The closest `CPUTYPE` matching my architecture in gcc would be `core2`


----------



## Eric A. Borisch (Apr 27, 2020)

Have you tried `native`?


----------



## rigoletto@ (Apr 28, 2020)

Are you sure penryn is the right one? You can confirm running[1]:

`sh -c "clang -v -fsyntax-only -march=native -x c /dev/null 2>&1 | grep -e '-target-cpu' | sed -e 's|.*-target-cpu \([[:alnum:]]*\) .*|\1|'"`

Also, I build ports for a `penryn` target processor and everything build fine, at least did the last time I built. Then I suppose that may not be the problem. 

[1] however the worng parameter is unlikely to make the build fail.


----------



## Eric A. Borisch (Apr 28, 2020)

rigoletto@ said:


> Are you sure penryn is the right one? You can confirm running[1]:
> 
> `sh -c "clang -v -fsyntax-only -march=native -x c /dev/null 2>&1 | grep -e '-target-cpu' | sed -e 's|.*-target-cpu \([[:alnum:]]*\) .*|\1|'"`
> 
> ...



I literally have this in my make.conf:


```
CPUTYPE ?= native
```

any reason to not use that? Recent (last 3 years?) gcc and clang both support it.


----------



## rigoletto@ (Apr 28, 2020)

Apparently, in some circumstances, `native` may pass the wrong result but please don't cote me on that, I am just talking what I have been told a few times in the past.


----------



## Invarianz (May 3, 2020)

It seems that the `CPUTYPE` Parameter is not the one failing the build. The build only fails on gcc9 and consequently on all packages depending on it. I'm using `CPUTYPE ?= penryn` because I'm building on a server to distribute to my target machines. The target machines have an older architecture then my server, consequently I'm not using `native`.
For now I'm avoiding everything depending on gcc9 and will use the regular repository for those packages..
Here are the relevant lines from the log; maybe you can provide a hint on what goes wrong there:

```
checking for suffix of object files... configure: error: in `/wrkdirs/usr/ports/lang/gcc9/work/.build/x86_64-portbld-freebsd12.1/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details
gmake[3]: *** [Makefile:16762: configure-stage1-target-libgcc] Error 1
gmake[3]: Leaving directory '/wrkdirs/usr/ports/lang/gcc9/work/.build'
gmake[2]: *** [Makefile:22474: stage1-bubble] Error 2
gmake[2]: Leaving directory '/wrkdirs/usr/ports/lang/gcc9/work/.build'
gmake[1]: *** [Makefile:22806: bootstrap-lean] Error 2
gmake[1]: Leaving directory '/wrkdirs/usr/ports/lang/gcc9/work/.build'
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
```


----------



## memreflect (May 4, 2020)

Invarianz said:


> ```
> checking for suffix of object files... configure: error: in `/wrkdirs/usr/ports/lang/gcc9/work/.build/x86_64-portbld-freebsd12.1/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details
> ...


Any time you see this is never a good sign, and the message is often very misleading as the error may occur a bit prior to that.  If you can attach or link to your config.log in the libgcc directory, that would help a bit more.


----------



## diizzy (May 5, 2020)

rigoletto@ said:


> Are you sure penryn is the right one? You can confirm running[1]:
> 
> `sh -c "clang -v -fsyntax-only -march=native -x c /dev/null 2>&1 | grep -e '-target-cpu' | sed -e 's|.*-target-cpu \([[:alnum:]]*\) .*|\1|'"`
> 
> ...



That works to some extent.
Intel G3220 is a cutdown version of the Haswell "arch" meaning that lacks AVX2 instructions for instance yet the above suggests setting haswell as CPUTYPE.









						Product Specifications
					

quick reference guide including specifications, features, pricing, compatibility, design documentation, ordering codes, spec codes and more.




					ark.intel.com
				



vs








						Product Specifications
					

quick reference guide including specifications, features, pricing, compatibility, design documentation, ordering codes, spec codes and more.




					ark.intel.com


----------



## Invarianz (May 6, 2020)

I have produced a fresh failing config.log file and appened it to this post. However, I can confirm that without any settings in the relevant make.conf the build runs through. I also attached the make.conf.
I can now also confirm that the build fails with only the `CPUTYPE`,  `MAKE_SHELL` and `DEFAULT_VERSIONS` variables set and the rest commented out.


----------



## memreflect (May 6, 2020)

Invarianz said:


> I have produced a fresh failing config.log file and appened it to this post.


That's the config.log from the toplevel GCC build directory, which isn't the one failing here.  GCC uses multiple configure scripts, which means it will also generate multiple config.log files.  The one needed is in the libgcc build directory, which is shown in the error message you posted earlier:


```
configure: error: in `/wrkdirs/usr/ports/lang/gcc9/work/.build/x86_64-portbld-freebsd12.1/libgcc'
```

Judging by the config.log in the toplevel build directory you posted and that error, you needed to post /usr/ports/lang/gcc9/work/.build/x86_64-portbld-freebsd12.1/libgcc/config.log.  What fails the build is definitely the `CPUTYPE ?= penryn` line for me.  That's because GCC doesn't have a 'penryn' flag as you are apparently aware:


```
configure:3529: /usr/ports/lang/gcc/work/.build ... -march=penryn ...
cc1: error: bad value ('penryn') for '-march=' switch
cc1: note: valid arguments to '-march=' switch are: nocona core2 nehalem corei7 ...
```

The best fix here is to just use 'core2'.  Incidentally, pretty much all of the code in Clang/LLVM uses the same code as 'core2' when you specify 'penryn'.  The only exception is the availability of SSE4.1 with 'penryn', compared to SSSE3 with 'core2'.  GCC only has a couple of comments in the source code mentioning "Penryn", and the associated code considers it to be the same as 'core2'.  I'd say just use 'core2' instead of 'penryn' since the difference is so slight.  Any performance hit will likely be negligible.


----------



## Invarianz (May 7, 2020)

Thanks a lot for the support memreflect this was the solution. I should have stuck with my first assumption on the top. Using `CPUTYPE ?= core2` is a good enough solution since I'm only giving up SSE 4.1. However, does anyone know it if would be possible to define different `CPUTYPE` variables, depending on the compiler?


----------

