Bug 223939 - USES=cargo doesn't respect CPUTYPE
Summary: USES=cargo doesn't respect CPUTYPE
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: FreeBSD Rust Team
URL:
Keywords: patch
Depends on:
Blocks: 223415
  Show dependency tree / graph
 
Reported: 2017-11-28 13:28 UTC by Jan Beich
Modified: 2017-11-29 11:07 UTC (History)
1 user (show)

See Also:
tobik: maintainer-feedback+

Attachments
v0 (723 bytes, patch)
2017-11-28 13:28 UTC, Jan Beich 		no flags Details | Diff
v1 (847 bytes, patch)
2017-11-29 03:47 UTC, Jan Beich 		no flags Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer freebsd_triage 2017-11-28 13:28:15 UTC 
Created attachment 188353 [details]
v0

C and C++ code can be built targeting newer CPUs if user defined CPUTYPE in make.conf. Let's opt-in for Rust as well.

For example, sysutils/exa built with CPUTYPE=core2 - http://sprunge.us/VKBj
Comment 1 Tobias Kortkamp freebsd_committer freebsd_triage 2017-11-28 13:57:56 UTC 
(In reply to Jan Beich from comment #0)
Can we not simply use CPUTYPE as is?  I don't see why it has to depend
on CFLAGS.

Seems ok to me otherwise.
Comment 2 Jan Beich freebsd_committer freebsd_triage 2017-11-28 14:47:39 UTC 
(In reply to Tobias Kortkamp from comment #1)
> Can we not simply use CPUTYPE as is?

bsd.cpu.mk accepts imaginary CPUTYPE values like "crusoe" or "k5" but doesn't like "native". Checking -march= also allows to respect NO_CPU_CFLAGS for free.
Comment 3 Jan Beich freebsd_committer freebsd_triage 2017-11-28 14:51:26 UTC 
Personally, I'd prefer to purge bsd.cpu.mk out of existence, at least CPU whitelist logic. ;)
Comment 4 Tobias Kortkamp freebsd_committer freebsd_triage 2017-11-28 17:34:40 UTC 
(In reply to Jan Beich from comment #2)

> bsd.cpu.mk accepts imaginary CPUTYPE values like "crusoe" or "k5" but
> doesn't like "native". Checking -march= also allows to respect
> NO_CPU_CFLAGS for free.

On aarch64 bsd.cpu.mk sets -mcpu= instead of -march= and then
target-cpu is not being set.  Is it a concern?
Comment 5 Jan Beich freebsd_committer freebsd_triage 2017-11-29 02:57:38 UTC 
(In reply to Tobias Kortkamp from comment #4)
Yes. I think, -mcpu= should be translated as well.

$ clang50 -march=exynos-m1 test.c
clang-5.0: error: the clang compiler does not support '-march=exynos-m1'
$ clang50 -mcpu=exynos-m1 test.c
$

$ gcc7 -march=exynos-m1 test.c
cc1: error: unknown value 'exynos-m1' for -march
$ gcc7 -mcpu=exynos-m1 test.c
$

$ rustc -C target-cpu=exynos-m1 test.rs
$
Comment 6 Jan Beich freebsd_committer freebsd_triage 2017-11-29 03:47:46 UTC 
Created attachment 188386 [details]
v1

On aarch64 rustc -C target-cpu= doesn't accept what clang -march= does. I guess, the same is true for armv6/armv7.
sparc64 and powerpc* don't support -march= at all. I have no clue about mips* or riscv*.

Let's fall back to -mcpu= and adjust in future if it breaks.
Comment 7 Tobias Kortkamp freebsd_committer freebsd_triage 2017-11-29 07:49:38 UTC 
(In reply to Jan Beich from comment #6)
Fine with me!
Comment 8 commit-hook freebsd_committer freebsd_triage 2017-11-29 11:07:09 UTC 
A commit references this bug:

Author: tobik
Date: Wed Nov 29 11:06:11 UTC 2017
New revision: 455101
URL: https://svnweb.freebsd.org/changeset/ports/455101

Log:
  Mk/Uses/cargo.mk: Respect CPUTYPE

  C and C++ code can be built targeting newer CPUs if user defined
  CPUTYPE in make.conf.  Let's opt-in for Rust as well.

  PR:		223939
  Submitted by:	jbeich

Changes:
  head/Mk/Uses/cargo.mk