[sr #110360] AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

2020-11-09 Thread Zack Weinberg
Update of sr #110360 (project autoconf):

  Status:None => Not Autoconf   
 Open/Closed:Open => Closed 

___

Follow-up Comment #11:

Despite the name, $host_cpu has always held a value more like the architecture
rather than the exact CPU.  Anyway, autoconf just passes through what
config.guess prints -- changing "armv7l" to "armcortex-aXX" (for instance)
will need to be taken up with the mailing list config-patc...@gnu.org (see
https://savannah.gnu.org/projects/config ).

> what is the recommended way to get a value for -mcpu in the GNU Toolchain?

We don't have a good answer to that question for cross-compilation right now. 
I'd recommend discussing that with the GCC development list (g...@gcc.gnu.org)
and getting their agreement first, then coming back to Autoconf if any changes
are needed here.

I don't think there's any further action for us to take in Autoconf right now
so I'm going to close this bug report.  

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110360] AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

2020-11-07 Thread Viktor Engelmann
Follow-up Comment #10, sr #110360 (project autoconf):

@Zack: you are right, that's a cleaner solution. I will do it like that, Thank
you very much :-)

Looking at https://en.wikipedia.org/wiki/ARM_Cortex-A and
https://en.wikipedia.org/wiki/ARM_architecture I would say that cortex-a53 is
a *CPU* (so should be admissible as value for $host_cpu) while armv7l is an
*architecture* and should not be an admissible value for $host_*cpu*.
armcortex-aXX or arm7cortex-aXX might be a compromise to not break scripts
that check for arm*
But that would have to be agreed on with the gcc folks, cf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70210

If $host_cpu isn't supposed to hold a fitting value for -mcpu, then what is
the recommended way to get a value for -mcpu in the GNU Toolchain? I don't
think that an application programmer should have to deal with that question.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110360] AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

2020-11-04 Thread Zack Weinberg
Follow-up Comment #9, sr #110360 (project autoconf):

I looked over spinhawk/configure.ac and I can now say with confidence that you
shouldn't override $host_cpu.  "armv7l" is *not* incorrect, just not
recognized as a -march= argument by GCC; changing it to start with "cortex"
will cause a whole bunch of "case $host_cpu in" blocks later in the configure
script to make the wrong choice.

I think the *proper* fix is for the code that sets $hc_cv_optimization_flags
(e.g. https://github.com/rbowler/spinhawk/blob/master/configure.ac#L1909)...


case "$host_cpu-$GCC" in
...
xscale-yes|arm*-yes)

hc_cv_is_intel_x86_arch=no
hc_cv_optimization_flags="$hc_cv_optimization_flags
-mcpu=$host_cpu -mtune=$host_cpu -frename-registers"
;;


to become aware that the value of $host_cpu is *not* necessarily usable as the
argument to either -mcpu= or -mtune=.  What I would recommend is for this
entire mess to be replaced with `-O2 -march=native -mtune=native` in native
compilation.  Cross compilation could continue to use $host_cpu as the
default, but a command-line option should be added (using AC_ARG_WITH) that
lets people set it to whatever specific thing they want.

I think this is not a bug in autoconf or automake, and should be re-filed as a
bug on spinhawk.  Viktor, it's probably best if you do that, but feel free to
cc: me on it (my Github handle is @zackw).

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110360] AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

2020-11-04 Thread Jannick
Follow-up Comment #8, sr #110360 (project autoconf):

[comment #7 comment #7:]
> The CPU names never contain underscores, do they? 
No, there are CPUs containing an underscore. 

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110360] AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

2020-11-04 Thread Viktor Engelmann
Follow-up Comment #7, sr #110360 (project autoconf):

It works on both models with

host_cpu=$(LANG=en_US lscpu | grep 'Model name' | cut -d: -f2 | tr '[:upper:]'
'[:lower:]')

I'm thinking about how you would cross-compile to Raspberry... you'd have to
set a --host, but couldn't set that to cortex-aXX. The CPU names never contain
underscores, do they? So you could specify --host=cortex_a53-os-abi or return
cortex_a53-os-abi from config.guess and sed s/_/-/g that somewhere in
AC_CANONICAL_HOST...

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110360] AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

2020-11-04 Thread Viktor Engelmann
Follow-up Comment #6, sr #110360 (project autoconf):

I have tested the most recent config.guess and config.sub on a Raspberry Pi 4
now - and I see "armv7l" there, too. That is a Cortex-A73, though.

Yes, I think $host_cpu is passed to -mcpu at least if it starts with "arm".
It's this project: 
https://github.com/rbowler/spinhawk/pull/96

I have the x-trick right in the configure.ac - I just mistyped it when I put
it here. Sorry for the noise.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110360] AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

2020-11-04 Thread Zack Weinberg
Follow-up Comment #5, sr #110360 (project autoconf):

Yeah, I don't think there will ever be an official CPU-COMPANY-SYSTEM triplet
where CPU contains a dash.  That would break far too many existing parsers. 
Also, there are dozens of programs out there that expect $host_cpu to start
with "arm" for *all* ARM32 CPUs; "cortex-a53" doesn't fit that pattern.

Do I understand correctly that this package assumes that $host_cpu will always
be directly usable as the argument to GCC's `-march=` switch?  If so, I think
that's a bug in the package.  GCC has never guaranteed that that will work, as
far as I know.

> AS_IF([test "x$host_cpu" = 'armv7l'],[host_cpu=cortex-a53])

* This should be `test "x$host_cpu" = xarmv7l`; the x-trick requires a leading
x on _both_ operands to the comparison.
** In this case you don't need the x-trick, you can use `test "$host_cpu" =
armv7l`. After AC_CANONICAL_HOST, $host_cpu is guaranteed to be nonempty, and
not to start with a dash.
* Not all "armv7l" CPUs are Cortex-A53s.  You might need to parse the output
of `lscpu` yourself here.

If you tell me which package this is, I might be able to make some more
specific suggestions.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110360] AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

2020-11-04 Thread Viktor Engelmann
Follow-up Comment #4, sr #110360 (project autoconf):

@Jannick
Thanks! I didn't want to pass a --host, because that would break
cross-platform compatibility. So I have put this into configure.ac

> 
> # override host_cpu in in special case (having dash)
> AS_IF([test "x$host_cpu" = 'armv7l'],[host_cpu=cortex-a53])
> AC_SUBST([host_cpu])
> 

That works without setting --host.
Not a perfect solution, but a suitable workaround.

I had tried something like that before, but had used BASH syntax, which hadn't
worked.

> @Zack:  Not sure if AC_CONONICAL_HOST and cousins should be prepared to be
able to digest also quadruplets config.sub might generate?

As I said, quadruples do produce an error

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110360] AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

2020-11-04 Thread Jannick
Follow-up Comment #3, sr #110360 (project autoconf):

As of now AC_CANONICAL_HOST, AC_CANONICAL_BUILD and AC_CANONICAL_TARGET expect
pure triplets.  The latest config.sub might return a triplet or a quadruplet
(see the header of config.sub).  It appears unlikely that a cpu having a dash
can meet the 3/4-plet nomenclature requirements in any way. 

Victor, this *evil* hackery might do the job in your case:  Add in
configure.ac (right below AC_CANONICAL_HOST)

# override host_cpu in in special case (having dash)
AS_IF([test "x$host_cpu" = 'xcortex_a53'],[host_cpu=cortex-a53])
AC_SUBST([host_cpu])

and smuggle the artificial triplet 'cortex_a53--' (with _vendor_
and _os_ set appropriately) into autoconf like so

./configure --build=cortex_a53--   


@Zack:  Not sure if AC_CONONICAL_HOST and cousins should be prepared to be
able to digest also quadruplets config.sub might generate?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110360] AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

2020-11-04 Thread Viktor Engelmann
Follow-up Comment #2, sr #110360 (project autoconf):

config.guess prints armv7l-unknown-linux-gnueabihf

I just pulled the most recent versions of config.guess and config.sub to be
sure. Same problem.

Not sure how these 2 CAN respond, to get a cpu with a dash through the rest of
autoconf...

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110360] AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

2020-11-03 Thread Zack Weinberg
Follow-up Comment #1, sr #110360 (project autoconf):

This is probably a bug in config.sub and config.guess, which would need to be
reported to config-patc...@gnu.org. To verify this, Viktor, could you please
report the output of running config.guess on your Pi3? No arguments are
required.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110360] AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

2020-11-03 Thread Viktor Engelmann
Additional Item Attachment, sr #110360 (project autoconf):

File name: config.log Size:299 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #110360] AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

2020-11-03 Thread Karl Berry
URL:
  

 Summary: AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry
Pi 3
 Project: Autoconf
Submitted by: karl
Submitted on: Tue 03 Nov 2020 02:27:50 PM PST
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

Received this report on Automake:

https://bugs.gnu.org/44422

Maybe it is really for Autoconf?
(I have no clue about arm architecture variants myself.)

I will copy the text here (unfortunately I expect it will be mangled by the
web form). The reporter is Viktor Engelmann 
googlemail.com>.


I'm trying to port a project to docker and I'm also testing it on my
Raspberry Pi 3B+

when I *./configure* and *make* the project, it fails with this message

gcc: error: unrecognized -mcpu target: armv7l
gcc: note: valid arguments are: arm8 arm810 strongarm [...] cortex-a53 [...]
gcc: error: missing argument to '-march='

lscpu says this:

Architecture:armv7l
Byte Order:  Little Endian
CPU(s):  4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):   1
Vendor ID:   ARM
Model:   4
Model name:  Cortex-A53
Stepping:r0p4
CPU max MHz: 1200.
CPU min MHz: 600.
BogoMIPS:38.40
Flags:   half thumb fastmult vfp edsp neon vfpv3 tls vfpv4
idiva idi
 vt vfpd32 lpae evtstrm crc32

So it seems to me that AC_CANONICAL_HOST sets $host_cpu to armv7l,
although that is the Architecture and should be passed to -march
instead. -mcpu should get the Model name.

I couldn't get it to accept the --host=cpu-os-abi parameter, because
cortex-a35 contains a dash and that seems to confuse autoconf (that
produces the error message Invalid configuration
`cortex-a53-unknown-linux-gnueabihf': machine `cortex-a53-unknown' not
recognized). I did manage to compile with
--host=native-unknown-linux-gnueabihf, but I'd rather not define a fixed
ABI, because that would break the cross-platform compatibility of the
Dockerfile.

I'm using autoconf 2.69 from the docker base image "ubuntu:latest".




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/