[PATCH] Recognize the VideoCore 4 processor

[John Ericson]

This is supported in this GCC fork. [1] It has been packaged in Nixpkgs
since 2019. [2]

Their change to `config.sub` [3] is similar, but also includes a `vc4`
-> `vc4-unknown-elf` shorthand; I don't see any reasons to add any new
legacy 1-component short-hands, so I just skipped that part.

[1]: https://github.com/itszor/vc4-toolchain

[2]: https://github.com/NixOS/nixpkgs/pull/72657

[3]: 
https://github.com/itszor/gcc-vc4/commit/91278afabe61808c0b02078c078e758d69f94aff

* config.sub (vc4-*): Recognize.
* testsuite/config-sub.data (vc4-unknown-none-elf): New entries.
---
 config.sub| 1 +
 testsuite/config-sub.data | 1 +
 2 files changed, 2 insertions(+)

diff --git a/config.sub b/config.sub
index defe52c..b727399 100755
--- a/config.sub
+++ b/config.sub
@@ -1253,6 +1253,7 @@ case $cpu-$vendor in
| ubicom32 \
| v70 | v850 | v850e | v850e1 | v850es | v850e2 | 
v850e2v3 \
| vax \
+   | vc4 \
| visium \
| w65 \
| wasm32 | wasm64 \
diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
index f36bea2..0cdaca6 100644
--- a/testsuite/config-sub.data
+++ b/testsuite/config-sub.data
@@ -854,6 +854,7 @@ v850e2v3-elf
v850e2v3-unknown-elf
 v850es v850es-unknown-none
 v850es-elf v850es-unknown-elf
 vaxvax-dec-ultrix4.2
+vc4-unknown-none-elf   vc4-unknown-none-elf
 vaxv   vax-dec-sysv
 visium visium-unknown-none
 visium-elf visium-unknown-elf
-- 
2.40.1

[PATCH 1/3] config.sub: Start moving code into functions

[John Ericson]

The idea is to be explicit about the different steps, and also separate
the more regular parts from the more irregular parts.

This is a large diff, but simple code motion. Anything that less
trivially preserves behavior would done separately so it is reasonably
possible to review.
---
 config.sub | 350 +
 1 file changed, 189 insertions(+), 161 deletions(-)

diff --git a/config.sub b/config.sub
index 77e1631..79a960d 100755
--- a/config.sub
+++ b/config.sub
@@ -59,6 +59,190 @@ timestamp='2023-09-19'
 # even some reasonably current systems (Solaris 10 as case-in-point) still
 # have a pre-POSIX /bin/sh.
 
+###
+# Functions
+###
+
+# Recognize the canonical CPU types
+#
+# Param 1: CPU
+validate_cpu () {
+   case "$1" in
+   1750a | 580 \
+   | a29k \
+   | aarch64 | aarch64_be | aarch64c | arm64ec \
+   | abacus \
+   | alpha | alphaev[4-8] | alphaev56 | alphaev6[78] \
+   | alpha64 | alpha64ev[4-8] | alpha64ev56 | alpha64ev6[78] \
+   | alphapca5[67] | alpha64pca5[67] \
+   | am33_2.0 \
+   | amdgcn \
+   | arc | arceb | arc32 | arc64 \
+   | arm | arm[lb]e | arme[lb] | armv* \
+   | avr | avr32 \
+   | asmjs \
+   | ba \
+   | be32 | be64 \
+   | bfin | bpf | bs2000 \
+   | c[123]* | c30 | [cjt]90 | c4x \
+   | c8051 | clipper | craynv | csky | cydra \
+   | d10v | d30v | dlx | dsp16xx \
+   | e2k | elxsi | epiphany \
+   | f30[01] | f700 | fido | fr30 | frv | ft32 | fx80 \
+   | javascript \
+   | h8300 | h8500 \
+   | hppa | hppa1.[01] | hppa2.0 | hppa2.0[nw] | hppa64 \
+   | hexagon \
+   | i370 | i*86 | i860 | i960 | ia16 | ia64 \
+   | ip2k | iq2000 \
+   | k1om \
+   | kvx \
+   | le32 | le64 \
+   | lm32 \
+   | loongarch32 | loongarch64 \
+   | m32c | m32r | m32rle \
+   | m5200 | m68000 | m680[012346]0 | m68360 | m683?2 | m68k \
+   | m6811 | m68hc11 | m6812 | m68hc12 | m68hcs12x \
+   | m88110 | m88k | maxq | mb | mcore | mep | metag \
+   | microblaze | microblazeel \
+   | mips* \
+   | mmix \
+   | mn10200 | mn10300 \
+   | moxie \
+   | mt \
+   | msp430 \
+   | nds32 | nds32le | nds32be \
+   | nfp \
+   | nios | nios2 | nios2eb | nios2el \
+   | none | np1 | ns16k | ns32k | nvptx \
+   | open8 \
+   | or1k* \
+   | or32 \
+   | orion \
+   | picochip \
+   | pdp10 | pdp11 | pj | pjl | pn | power \
+   | powerpc | powerpc64 | powerpc64le | powerpcle | powerpcspe \
+   | pru \
+   | pyramid \
+   | riscv | riscv32 | riscv32be | riscv64 | riscv64be \
+   | rl78 | romp | rs6000 | rx \
+   | s390 | s390x \
+   | score \
+   | sh | shl \
+   | sh[1234] | sh[24]a | sh[24]ae[lb] | sh[23]e | she[lb] | 
sh[lb]e \
+   | sh[1234]e[lb] |  sh[12345][lb]e | sh[23]ele | sh64 | sh64le \
+   | sparc | sparc64 | sparc64b | sparc64v | sparc86x | sparclet \
+   | sparclite \
+   | sparcv8 | sparcv9 | sparcv9b | sparcv9v | sv1 | sx* \
+   | spu \
+   | tahoe \
+   | thumbv7* \
+   | tic30 | tic4x | tic54x | tic55x | tic6x | tic80 \
+   | tron \
+   | ubicom32 \
+   | v70 | v850 | v850e | v850e1 | v850es | v850e2 | v850e2v3 \
+   | vax \
+   | visium \
+   | w65 \
+   | wasm32 | wasm64 \
+   | we32k \
+   | x86 | x86_64 | xc16x | xgate | xps100 \
+   | xstormy16 | xtensa* \
+   | ymp \
+   | z8k | z80)
+   return 0
+   ;;
+
+   *)
+   return 1
+   ;;
+   esac
+}
+
+# Choose a default vendor given a CPU and OS types
+#
+# Param 1: CPU
+# Param 2: OS
+#
+# Sets: vendor
+default_vendor_from_cpu_os () {
+   case $1-$2 in
+   *-riscix*)
+   vendor=acorn
+   ;;
+   *-sunos*)
+   vendor=sun
+   ;;
+   *-cnk* | *-aix*)
+   vendor=ibm
+   ;;
+   *-beos*)
+   vendor=be
+   ;;
+   *-hpux*)
+   vendor=hp
+   ;;
+   

[PATCH 2/3] config.sub: Factor out `invalid_config` function

[John Ericson]

There were indeed some cases we displayed the message but then forgot to
exit!
---
 config.sub | 44 +---
 1 file changed, 21 insertions(+), 23 deletions(-)

diff --git a/config.sub b/config.sub
index 79a960d..7d6c7be 100755
--- a/config.sub
+++ b/config.sub
@@ -63,6 +63,15 @@ timestamp='2023-09-19'
 # Functions
 ###
 
+# Invalid configuration; display a message and exit
+#
+# Param 1: configuration
+# Param 2: message
+invalid_config () {
+   echo "Invalid configuration '$1': $2" 1>&2
+   exit 1
+}
+
 # Recognize the canonical CPU types
 #
 # Param 1: CPU
@@ -314,8 +323,7 @@ IFS=$saved_IFS
 # Separate into logical components for further validation
 case $1 in
*-*-*-*-*)
-   echo "Invalid configuration '$1': more than four components" >&2
-   exit 1
+   invalid_config "$1" "more than four components"
;;
*-*-*-*)
basic_machine=$field1-$field2
@@ -1362,10 +1370,8 @@ case $cpu-$vendor in
*)
# Recognize the canonical CPU types that are allowed with any
# company name.
-   if ! validate_cpu "$cpu"; then
-   echo "Invalid configuration '$1': machine 
'$cpu-$vendor' not recognized" 1>&2
-   exit 1
-   fi
+   validate_cpu "$cpu" \
+   || invalid_config "$1" "machine '$cpu-$vendor' not 
recognized"
;;
 esac
 
@@ -1878,12 +1884,11 @@ case $os in
'')
if test x"$obj" = x
then
-   echo "Invalid configuration '$1': Blank OS only allowed 
with explicit machine code file format" 1>&2
+   invalid_config "$1" "Blank OS only allowed with 
explicit machine code file format"
fi
;;
*)
-   echo "Invalid configuration '$1': OS '$os' not recognized" 1>&2
-   exit 1
+   invalid_config "$1" "OS '$os' not recognized"
;;
 esac
 
@@ -1894,8 +1899,7 @@ case $obj in
# empty is fine
;;
*)
-   echo "Invalid configuration '$1': Machine code format '$obj' 
not recognized" 1>&2
-   exit 1
+   invalid_config "$1" "Machine code format '$obj' not recognized"
;;
 esac
 
@@ -1908,8 +1912,7 @@ case $cpu-$os in
javascript-ghcjs)
;;
javascript-* | *-ghcjs)
-   echo "Invalid configuration '$1': cpu '$cpu' is not valid with 
os '$os$obj'" 1>&2
-   exit 1
+   invalid_config "$1" "cpu '$cpu' is not valid with os '$os$obj'"
;;
 esac
 
@@ -1928,20 +1931,16 @@ case $kernel-$os-$obj in
-dietlibc*- | -newlib*- | -musl*- | -relibc*- | -uclibc*- | -mlibc*- )
# These are just libc implementations, not actual OSes, and thus
# require a kernel.
-   echo "Invalid configuration '$1': libc '$os' needs explicit 
kernel." 1>&2
-   exit 1
+   invalid_config "$1" "libc '$os' needs explicit kernel."
;;
-kernel*- )
-   echo "Invalid configuration '$1': '$os' needs explicit kernel." 
1>&2
-   exit 1
+   invalid_config "$1" "'$os' needs explicit kernel."
;;
*-kernel*- )
-   echo "Invalid configuration '$1': '$kernel' does not support 
'$os'." 1>&2
-   exit 1
+   invalid_config "$1" "'$kernel' does not support '$os'."
;;
*-msvc*- )
-   echo "Invalid configuration '$1': '$os' needs 'windows'." 1>&2
-   exit 1
+   invalid_config "$1" "'$os' needs 'windows'."
;;
kfreebsd*-gnu*- | kopensolaris*-gnu*-)
;;
@@ -1964,8 +1963,7 @@ case $kernel-$os-$obj in
# Blank kernel and OS with real machine code file format is 
always fine.
;;
*-*-*)
-   echo "Invalid configuration '$1': Kernel '$kernel' not known to 
work with OS '$os'." 1>&2
-   exit 1
+   invalid_config "$1" "Kernel '$kernel' not known to work with OS 
'$os'."
;;
 esac
 
-- 
2.40.1

[PATCH 3/3] config.sub: Factor out single-field shorthands

[John Ericson]

This is another "big case" that deserves to be in its own function.

These are rather legacy cases so it is use to have them "out of the way"
when reading the code too.
---
 config.sub | 914 +++--
 1 file changed, 464 insertions(+), 450 deletions(-)

diff --git a/config.sub b/config.sub
index 7d6c7be..2c79c1a 100755
--- a/config.sub
+++ b/config.sub
@@ -168,6 +168,469 @@ validate_cpu () {
esac
 }
 
+# Handle a single-field shorthand.
+#
+# Param 1: The single field
+#
+# Sets: basic_machine, basic_os
+#
+# Recognizes a bunch of ad-hoc special cases, otherwise sets
+# `basic_machine` as single comonent, and `basic_is` as empty string.
+#
+# These are never normal forms.
+single_field () {
+   case $1 in
+   386bsd)
+   basic_machine=i386-pc
+   basic_os=bsd
+   ;;
+   a29khif)
+   basic_machine=a29k-amd
+   basic_os=udi
+   ;;
+   adobe68k)
+   basic_machine=m68010-adobe
+   basic_os=scout
+   ;;
+   alliant)
+   basic_machine=fx80-alliant
+   basic_os=
+   ;;
+   altos | altos3068)
+   basic_machine=m68k-altos
+   basic_os=
+   ;;
+   am29k)
+   basic_machine=a29k-none
+   basic_os=bsd
+   ;;
+   amdahl)
+   basic_machine=580-amdahl
+   basic_os=sysv
+   ;;
+   amiga)
+   basic_machine=m68k-unknown
+   basic_os=
+   ;;
+   amigaos | amigados)
+   basic_machine=m68k-unknown
+   basic_os=amigaos
+   ;;
+   amigaunix | amix)
+   basic_machine=m68k-unknown
+   basic_os=sysv4
+   ;;
+   apollo68)
+   basic_machine=m68k-apollo
+   basic_os=sysv
+   ;;
+   apollo68bsd)
+   basic_machine=m68k-apollo
+   basic_os=bsd
+   ;;
+   aros)
+   basic_machine=i386-pc
+   basic_os=aros
+   ;;
+   aux)
+   basic_machine=m68k-apple
+   basic_os=aux
+   ;;
+   balance)
+   basic_machine=ns32k-sequent
+   basic_os=dynix
+   ;;
+   blackfin)
+   basic_machine=bfin-unknown
+   basic_os=linux
+   ;;
+   cegcc)
+   basic_machine=arm-unknown
+   basic_os=cegcc
+   ;;
+   convex-c1)
+   basic_machine=c1-convex
+   basic_os=bsd
+   ;;
+   convex-c2)
+   basic_machine=c2-convex
+   basic_os=bsd
+   ;;
+   convex-c32)
+   basic_machine=c32-convex
+   basic_os=bsd
+   ;;
+   convex-c34)
+   basic_machine=c34-convex
+   basic_os=bsd
+   ;;
+   convex-c38)
+   basic_machine=c38-convex
+   basic_os=bsd
+   ;;
+   cray)
+   basic_machine=j90-cray
+   basic_os=unicos
+   ;;
+   crds | unos)
+   basic_machine=m68k-crds
+   basic_os=
+   ;;
+   da30)
+   basic_machine=m68k-da30
+   basic_os=
+   ;;
+   decstation | pmax | pmin | dec3100 | decstatn)
+   basic_machine=mips-dec
+   basic_os=
+   ;;
+   delta88)
+   basic_machine=m88k-motorola
+   basic_os=sysv3
+   ;;
+   dicos)
+   basic_machine=i686-pc
+   basic_os=dicos
+   ;;
+   djgpp)
+   basic_machine=i586-pc
+   basic_os=msdosdjgpp
+   ;;
+   ebmon29k)
+   basic_machine=a29k-amd
+   basic_os=ebmon
+   ;;
+   

Re: [PATCH] config.sub: Accept LLVM-style $cpu-$vendor-windows-cygnus

[John Ericson]

On 9/21/23 09:35, Dmitry V. Levin wrote:


On Wed, Sep 20, 2023 at 09:59:22AM -0400, John Ericson wrote:

Of course config.sub can provide a canonicalization of 
windows-cygnus into cygwin if it helps.


I was worried that would close off the possibility of adding them as 
normal forms later, but maybe it's better to just do it, if otherwise 
we wouldn't support it at all.


I wouldn't say that would help adding them later, but that certainly 
wouldn't block them either, so I suggest adding an alias as it seems 
to be the best thing we can currently do.



On 9/21/23 08:47, Zack Weinberg wrote:

+1 from me on the general principle that if LLVM accepts a name then 
config.sub should know about it, and map it to an existing GNU name 
that means the same thing, if any.


OK, thank you both for the encouragement, I will submit patches for that 
soon.



For what it's worth, we could imagine someday something like 
--std=2024 to have versioned normalizations, allowing packages to opt 
into doing the opposite normalizations


If you want to work on this, I suggest that your first step should be 
to try to make config.sub and config.guess as table-driven as 
possible. Right now, adding *any* sort of alternative mode for output 
is going to be an exercise in frustration, since both scripts are big 
balls of mud (in the classic sense of that term -- 
http://www.laputan.org/mud/mud.html). Given the extreme limitations of 
portable shell scripting, this may only be possible if you convert 
them to be generated from a more flexible source. zw


Yes I absolutely agree refactors before new features. If you check the 
git history, you can see that I've been reworking config.sub for quite a 
while :). I do have some more things in mind for that, and would happily 
do them before returning to this.


John

[PATCH] config.sub: Fix some inconsistent indentation

[John Ericson]

From: John Ericson 

A mix of spaces and tabs were used here instead of tabs.

I would certainly not oppose switching from tabs to spaces everywhere,
but right now most things use tabs, so I went with that.
---
 config.sub | 44 ++--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/config.sub b/config.sub
index defe52c..77e1631 100755
--- a/config.sub
+++ b/config.sub
@@ -813,11 +813,11 @@ case $basic_machine in
cpu=mips
vendor=sgi
case $basic_os in
-   irix*)
-   ;;
-   *)
-   basic_os=irix4
-   ;;
+   irix*)
+   ;;
+   *)
+   basic_os=irix4
+   ;;
esac
;;
miniframe)
@@ -838,16 +838,16 @@ case $basic_machine in
cpu=m68k
vendor=next
case $basic_os in
-   openstep*)
-   ;;
-   nextstep*)
-   ;;
-   ns2*)
- basic_os=nextstep2
-   ;;
-   *)
- basic_os=nextstep3
-   ;;
+   openstep*)
+   ;;
+   nextstep*)
+   ;;
+   ns2*)
+   basic_os=nextstep2
+   ;;
+   *)
+   basic_os=nextstep3
+   ;;
esac
;;
np1)
@@ -1486,13 +1486,13 @@ case $os in
# particular features comes up, bare metal
# configurations are quite functional.
case $cpu in
-   arm*)
-   os=eabi
-   ;;
-   *)
-   os=
-   obj=elf
-   ;;
+   arm*)
+   os=eabi
+   ;;
+   *)
+   os=
+   obj=elf
+   ;;
esac
;;
aout* | coff* | elf* | pe*)
-- 
2.40.1

Re: [PATCH] config.sub: Accept LLVM-style $cpu-$vendor-windows-cygnus

[John Ericson]

On Wed, Sep 20, 2023, at 6:01 AM, Dmitry V. Levin wrote:
> The issue with adding new names duplicating already supported ones is that
> every piece of software that handles the old name would have to be patched
> eventually to handle the new name as well.

Yes, that is true. I have no good answer for that.

> Of course config.sub can provide a canonicalization of windows-cygnus into
> cygwin if it helps.

I was worried that would close off the possibility of adding them as normal 
forms later, but maybe it's better to just do it, if otherwise we wouldn't 
support it at all.

For what it's worth, we could imagine someday something like --std=2024 to have 
versioned normalizations, allowing packages to opt into doing the opposite 
normalizations (cygwin -> windows-cygnus rather than vice versa). That would 
keep my dream of unifying with LLVM alive without impacting any programs which 
didn't pas the flag. If that is a possibility, then I need not fear adding the 
windows-cygnus -> cygwin normalization now.

John

Re: [PATCH] config.sub: Accept LLVM-style $cpu-$vendor-windows-cygnus

[John Ericson]

On 9/19/23 20:19, Dmitry V. Levin wrote:


On Wed, Aug 16, 2023 at 10:46:26AM -0400, John Ericson wrote:

In 91f6a7f616b161c25ba2001861a40e662e18c4ad I supported `windows-gnu` 
and `windows-msvc`, but I forgot about the last one: `windows-cygnus`.


Is windows-cygnus a new name for something already supported by 
config.sub, or is it a new thing?


Yes, it is new name for something already supported. In particular, it 
is a synonym for `cygwin`, just like `windows-gnu` is a synonym for 
`mingw*`. (See 
https://github.com/llvm/llvm-project/commit/edbdd2e5df8b59dac8ae5f45059407f8a79850d6 
for the origin of those and `windows-msvc` in LLVM, all in the same commit.)


If you mean to not accept duplicates where the original isn't 
defunct/abandoned (like `winnt` is), then yes the consistent thing to do 
is reject this patch too.


On the other hand, if duplicate normal forms provided those normal forms 
don't have other issues, then this patch is fine.


I knew this duplicating, the point was for (a) more LLVM/Rust/other 
tools convergence and (b) ergonomic `windows-*` grouping/case-matching. 
And indeed I believe that `windows-cygnus` has no other issues; no on 
objected to `windows-cygnus` as misleading the way that many (correctly) 
pointed out that `windows-gnu` is misleading. However, whereas LLVM does 
not recognize `winnt`, it does recognize `cygwin` and `mingw*`, so 
neither of these other `windows-*` normal forms are strictly necessary 
for LLVM compat, just for my dream of converging normal forms between 
projects.


Hope that clarifies everything; I'll live with whatever you choose to do :).

Cheers,

John

Re: Rethinking configuration tuples

[John Ericson]

On 9/19/23 21:07, Po Lu wrote:

Why not?

I have on my hand several programs which use -winnt*, such as many old
releases of Emacs.  And users should be capable of replacing config.sub
and config.guess with newer versions without ill effect.


At no point has anyone proposed removing *-winnt-*. And while I think a 
deprecation message is a good idea, no one has submitted yet a patch for 
that either.


With Dmitry's plan, you can still upgrade config.sub in those old 
versions of Emacs if you like without any issue.


John

Re: Rethinking configuration tuples

[John Ericson]

Thanks Dmitry. This is an acceptable outcome to me. It is a nice middle 
ground between Po Lu's and my first choice options.


John

On 9/19/23 19:58, Dmitry V. Levin wrote:

On Thu, Sep 14, 2023 at 12:55:06AM -0400, John Ericson wrote:

OK here we go:

  1. https://github.com/ericson2314/gnu-config/commit/windows-mingnu.patch
  2. https://github.com/ericson2314/gnu-config/commit/windows-mingw.patch
  3. https://github.com/ericson2314/gnu-config/commit/no-windows-gnu.patch

I tried to honestly argue for each of them the best I could in the
commit message. I know I prefer (1); I am guessing Jacob prefers (2),
and Po Lu prefers (3).

Have fun, Dmitry :).

I'm inclined to remove windows-gnu from config.sub instead of renaming or
canonicalizing it because, firstly, there is no GNU libc on windows, and,
secondly, windows-gnu as used by LLVM means MinGW, but for that we already
have mingw*, and we should avoid adding new canonical names for the same
thing.  We could add canonicalization of windows-mingw* into mingw*, but
if nobody uses the former, why bother?

At the same time, I'm inclined to leave windows-msvc as is because,
unlike windows-gnu, it does exist, and the only one who objected against
windows-msvc and suggested to canonicalize windows-msvc into winnt was
Po Lu, but the arguments provided against windows-msvc were not convincing.

Re: Whither windows-msvc

[John Ericson]

Very nicely put Zack. I agree completely; this is what I was trying to 
discuss with Jacob earlier but much more elegantly stated. It is also 
what Adam was saying.


Thanks for writing this,

John

On 9/19/23 17:58, Zack Weinberg wrote:

On Mon, Sep 18, 2023, at 8:02 PM, Po Lu wrote:

linux-musl is so named because there is no canonical name for a
Musl-based Linux system.  The "musl" represents "musl-based operating
system", not merely the libc itself.  Ditto for ulibc.

I'm gonna push back real hard on this specific aspect of what you are saying.

The terminology used by config.* was laid down at a time when it was extremely unusual 
for the kernel, the C library, the C compiler, and the base set of " user 
space" system software to be developed by four (or more!) independent organizations. 
It is now, IMHO, more appropriate to think of $host_os (the shell variable set by 
AC_CANONICAL_HOST) as specifying the part of the ABI that *isn't* defined by the ISA. 
(Ignoring historical inconsistencies about whether to specify ABI-relevant ISA variants 
in $xxx_cpu or $xxx_os.)

In particular, I claim that it is correct to use "linux-musl" to describe *any* system 
built on top of the Linux kernel and musl libc, and similarly "linux-gnu" to describe any 
system built on top of the Linux kernel and GNU libc, regardless of what other software is included.

In general, I claim that components of a complete system that do not affect its 
C ABI should not be considered *at all* in defining its canonical system name.

zw

Re: Whither windows-msvc

[John Ericson]

On 9/18/23 20:02, Po Lu wrote:


John Ericson  writes:

It is defunct because using Autotools with Microsoft's own compilers 
basically impossible. Everything that supports Microsoft's own tools 
is now using CMake or Meson for that, and bypassing GNU config and 
the rest completely. LLVM however offers both GCC- and MSVC-style 
CLIs, and so it is actually feasible to combine LLVM targeting 
`windows-msvc` with Autotools. (Cross compiling from Unix also helps 
make things easier too.)


This is incorrect. There are two wrapper scripts which provide 
Unix-compatible cc and CC, by translating its command line arguments 
into options understood by cl.exe.



OK I take it back then, not "basically impossible". That could work.

emacs gave up on that! If anyone else is still using `winnt` we'll 
here about it if we do a deprecation. We must not obsolete or remove 
a triplet that has served us faithfully for eons, as recently as a 
decade ago. Deprecation doesn't break anything. There is no problem 
with deprecation. It is just a warning saying that something is no 
longer encouraged.


It is not our place to demand action from our users. Do you recognize 
how ubiquitous config.* are? Users expect to be capable of replacing 
config.* in any Autoconf program with their latest versions, without 
superfluous diagnostics or erroneous results being generated.


I challenge you to find me a public project where this `winnt` is still 
in use.


Of course, there are many private projects too. I'll furthermore take a 
bet that if we add a deprecation notice that no one will write an email 
complaining this broke their code, where if I mistaken I'll do some 
few-days-long drudgery task of your choice for Emacs.


Everyone else that supported changing/removing `windows-gnu` like you 
also wrote that `windows-msvc` sounded useful and we should keep it.



My point is, winnt already exists. Does LLVM define _MSC_VER?

Yes Clang does define it, see 
https://clang.llvm.org/docs/UsersManual.html#microsoft-extensions. If it 
didn't, Clang would be failing in its goal to compile software written 
for Microsoft's tools with as few modifications as possible.


You do realize that GNU config already parses "operating system 
identifiers" that are blatantly not operating systems, and has done 
so for years? "elf", "coff", "musl", "uclibc" are all currently valid 
examples that are blatantly not OSes; but expediently accepted as 
OSes in order to support certain configs. We should continue to be 
practical and support `windows-msvc` just as we previously supported 
things like `linux-musl`.


linux-musl is so named because there is no canonical name for a 
Musl-based Linux system. The "musl" represents "musl-based operating 
system", not merely the libc itself. Ditto for ulibc.


ELF and COFF are aberrations inasmuch as there is _no_ operating system.

Neither of the foregoing conditions applies to MSVC, where the 
operating system is MS-Windows. Compounding all of that, this is not a 
court of law: the mere existence of one folly, or one adjudication 
made in the past, is not grounds upon which to permit more analogous 
mistakes to transpire


I have proposed a way to turn those follies into non-follies, which 
would also help with this, and do so without breaking backwards 
compatibility. I don't think config.sub ever made any formal guarantees 
about what its output would look like anyways. I don't think I have any 
more to say on this part.


John

Re: Whither windows-msvc

[John Ericson]

On 9/18/23 10:57, Po Lu wrote:


John Ericson  writes:


You just said it is a defunct attempt


Only inasmuch as MSVC became intractable for Emacs's own purposes.

It is defunct because using Autotools with Microsoft's own compilers 
basically impossible. Everything that supports Microsoft's own tools is 
now using CMake or Meson for that, and bypassing GNU config and the rest 
completely.LLVM however offers both GCC- and MSVC-style CLIs, and so it 
is actually feasible to combine LLVM targeting `windows-msvc` with 
Autotools. (Cross compiling from Unix also helps make things easier too.)


There is no Emacs-specific story in what I wrote above. No doubt perhaps 
Emacs did encounter some unique problems in addition, but pain along 
these lines would affect everyone using `winnt` in this way. These 
multiple better options (Autotools with LLVM, CMake, Meson) obviate 
using `winnt` completely.


emacs gave up on that! If anyone else is still using `winnt` we'll 
here about it if we do a deprecation.


We must not obsolete or remove a triplet that has served us faithfully 
for eons, as recently as a decade ago.


Deprecation doesn't break anything. There is no problem with 
deprecation. It is just a warning saying that something is no longer 
encouraged.


Use llvmmsvc or something similar, if distinguishing between MSVC and 
LLVM is truly of such paramount importance.


LLVM's `windows-msvc` *is* the real `windows-msvc`; no one is trying to 
distinguish LLVM vs Microsoft's own tools in GNU config, just as no one 
is distinguishing GCC vs LLVM in GNU config.


Microsoft's own tools do not use GNU configs or anything like that, so 
the choice of triple doesn't matter; that is why winnt was fine a decade 
ago. LLVM however does support similar configs, and people add configs 
to GNU configs for LLVM all the time, not just I. (For example, the 
recent requests for "arm64ec" and "arm64_32" are things that *only* LLVM 
supports, not GCC.) LLVM *does not support* any `*winnt*` configs; you 
must use `windows-msvc` with it. So if GNU config does not this triple 
and instead just supports the likely abandoned and unused `winnt`, it is 
actively hostile to the one extant free software toolchain that targets 
this platform.


Everyone else that supported changing/removing `windows-gnu` like you 
also wrote that `windows-msvc` sounded useful and we should keep it.


And in any case, `windows-msvc' is a no-go: there is a dash in 
between, rendering the msvc an operating system identifier.


You do realize that GNU config already parses "operating system 
identifiers" that are blatantly not operating systems, and has done so 
for years? "elf", "coff", "musl", "uclibc" are all currently valid 
examples that are blatantly not OSes; but expediently accepted as OSes 
in order to support certain configs. We should continue to be practical 
and support `windows-msvc` just as we previously supported things like 
`linux-musl`.


The whole point of the massive other thread in spitting out KEY=value\n 
is so that that we can improve our categorization without any breakages, 
and relieve downstream projects like autotools from reverse engineering 
what we do. There are two choices: accept these "fake" OSes and other 
lies, or admit that the dash-separated format is ambiguous because 
sometime we do kernel-abi / os-abi not kernel-os. Let's go with the 
second, which can allow us to stop pretending musl, msvc, etc. are OSes 
internally, and share their now-corrected categorization with the rest 
of the world.


John

Re: Whither windows-msvc

[John Ericson]

On 9/15/23 20:52, Po Lu wrote:


John Ericson  writes:


This `winnt`is but more detritus from such defunct attempts. I would
deprecate it so it no longer confuses people. (Deprecation I think is
better than sudden removal.)

It is not.  Emacs used *-*-winnt4.0 to designate MSVC until support for
the MSVC build was removed as a whole, some time in the 2010s.


You just said it is a defunct attempt --- emacs gave up on that! If 
anyone else is still using `winnt` we'll here about it if we do a 
deprecation.

Whither windows-msvc

[John Ericson]

Note that `windows-msvc` is not supported by GCC. It is only supported 
by Microsoft's own proprietary tools, and LLVM. Thus, the only free 
software implementation of this target calls it `windows-msvc`.


`winnt` I do see in config.log, but I have never seen used in the wild. 
I think it is just detritus from some obscure Alpha CPU thing. It is (a) 
untested, and (b) almost removed in 
554e3feb158dbde3193c05fddec422c3c93531cd.


See 
https://lists.gnu.org/archive/html/config-patches/2017-09/msg0.html 
for first message in the thread that led to that commit; In Ben's own 
words (in a reply to that original message):



Thanks. I'm not normally inclined to remove triplets (because I find
it a useful way to preserve the history!) but in this case, it's too
confusing for all of these defunct attempts to do Unix on Windows.


This `winnt`is but more detritus from such defunct attempts. I would 
deprecate it so it no longer confuses people. (Deprecation I think is 
better than sudden removal.)


John

Re: Rethinking configuration tuples

[John Ericson]

I used to do that, but see commit 
f0f728324021f38b0d31de399b9974535300167c : Dmitry opted to switch to 
just using Git's commit messages as the source of truth, and providing a 
make rule to generate the ChangeLog.


The document you linked endorses such a choice, saying

Projects that maintain such VCS repositories can decide not to 
maintain separate change log files, and instead rely on the VCS to 
keep the change log.
If you decide not to maintain separate change log files, you should 
still consider providing them in the release tarballs [...].


I think doing this is a fine decision.

John

On 9/14/23 01:37, Po Lu wrote:

John Ericson  writes:


I had meant to just deal with windows-gnu in those 3 options,
otherwise we have a combinatorial explosion of patches (and commit
messages) for me to write :). Once we deal with that one we can deal
with the others, right?

Incidentally, if you want to make it easier for others to interpret your
patches, please provide ChangeLog entries along with them.  Refer to
`(standards)Change Logs':

   https://www.gnu.org/prep/standards/standards.html#Change-Logs

Re: Rethinking configuration tuples

[John Ericson]

I had meant to just deal with windows-gnu in those 3 options, otherwise 
we have a combinatorial explosion of patches (and commit messages) for 
me to write :). Once we deal with that one we can deal with the others, 
right?


John

On 9/14/23 01:00, Po Lu wrote:

John Ericson  writes:


OK here we go:

1 https://github.com/ericson2314/gnu-config/commit/windows-mingnu.patch
2 https://github.com/ericson2314/gnu-config/commit/windows-mingw.patch
3 https://github.com/ericson2314/gnu-config/commit/no-windows-gnu.patch

I tried to honestly argue for each of them the best I could in the commit 
message. I know I prefer (1); I am guessing Jacob prefers (2),
and Po Lu prefers (3).

I prefer eliminating windows-msvc too.  It's also a misnomer, and we
already have *-winnt*, which represents MSVC.

Re: Rethinking configuration tuples

[John Ericson]

OK here we go:

1. https://github.com/ericson2314/gnu-config/commit/windows-mingnu.patch
2. https://github.com/ericson2314/gnu-config/commit/windows-mingw.patch
3. https://github.com/ericson2314/gnu-config/commit/no-windows-gnu.patch

I tried to honestly argue for each of them the best I could in the 
commit message. I know I prefer (1); I am guessing Jacob prefers (2), 
and Po Lu prefers (3).


Have fun, Dmitry :).

I suppose rather than just idly speculating on how nice it would be to 
standardize with LLVM, this might be a good time to actually post to 
their Discourse instance and solicit feedback. If anyone else agrees I 
will happily do so.


Cheers,

John

On 9/11/23 17:55, John Ericson wrote:
I can submit two patches (effectively amending my prior, landed patch) 
with options that I think people would prefer. Will do that shortly.


On 9/11/23 17:53, Dmitry V. Levin wrote:

Hi,

On Mon, Sep 11, 2023 at 10:11:39AM +0800, Po Lu wrote:

Where are the config maintainers?  Karl Barry and company?
(I don't remember his e-mail nor do I have it at hand.)

I would expect them to be actively reading this list, but instead my
original request has been left twisting in the wind.

I'm the maintainer and I'm actively reading this list now,
a bit surprised to find so many messages at this time of year. :)

Apparently, you don't quite like commit
91f6a7f616b161c25ba2001861a40e662e18c4ad that added
$cpu-$vendor-windows-{gnu,msvc} support to config.sub, but I'm not sure
I understood what exactly do you suggest to change in this case.

Re: Rethinking configuration tuples

[John Ericson]

Oops I had this email as draft and didn't hit send. The conversation has 
moved on since a bit, but I'll send it anyways.


John



On 9/6/23 19:46, Jacob Bachmeyer wrote:

The problem is that system(3) probably /does/ exist in that 
configuration, but such a system is only usable as a cross-compilation 
target, since building the GNU tools requires a shell.


Agree! This is exactly what I mean of "ops time" vs build time question: 
if we do have system(3) we don't know what shell it will be hooked up to 
in general (cross compilation is the general case).


I would say even if we are native compiling, and we find that the shell 
via system(3) supports x y z, we shouldn't bake the results of a 
configure-time check for that in at build time --- the installed binary 
might be copied to another system with the same libc but a different 
shell, and then system(3) would do something else.


I think configs are mainly useful for the host and target systems, and 
thus should focus on information needed for them. Sounds like we agree 
that "do we have a shell [that can do x y z]" is question that is fine 
to ask of the build platform, but not really appropriate to ask of the 
host or target platform. Thus, things like "presence of shell" are not 
really good to include in configs.


This is all to say that telling apart OSes (as opposed to merely libcs) 
seems too fraught to configs for me.


Maybe this could go in the config per the "arbitrary many components, 
finer distinctions to the right" "converging sequence" approach, but 
then I would want this further to the right, e.g. 
aarch64-unknown-musl-noshell not aarch64-unknown-noshell-musl.


The idea of lacking a shell was intended as an example of something 
that would make a Free system /very/ different from the GNU system, 
enough that it cannot be considered a GNU variant.  In other words, a 
Linux-based system that is clearly /not/ GNU/Linux.
Agreed it is not GNU/Linux. But I think anything that uses glibc should 
use "gnu" in the config because configs have evolved to be about libc 
more than OS.
The choice of system service management is orthogonal to this, 
since it has minimal impact on user programs.  (Unless systemd 
gets even more outrageously invasive...)

Agreed, just wanted to double check.
Of course, if systemd *does* get sufficiently outrageously invasive, 
we might need a *-*-linux-systemd-glibc tuple... (Since systemd 
gleefully makes extensive use of Linux-kernel-specific features, it 
cannot possibly be a standard on the GNU system, which supports 
multiple Free kernels.)


Yes I agree systemd probably can't be "bonafide GNU OS", but I take 
the opposite conclusion that this is evidence for the "gnu" for glibc 
is more important than the "gnu" for "true GNU OS".


In this hypothetical (that needs to *stay* hypothetical) example, 
"systemd" has somehow become an "OS" distinct from the GNU system.

Yes.


Except configure usually does not need a "fully disambiguated" 
form---the canonical form produced by config.sub is fine, since 
configure is usually matching against the full tuple using shell 
case patterns.  The flat list with a defined order is optimal for 
this strategy, since it allows to easily check for the presence of 
any tag or combination of tags.
Shell case patterns can be a bit of a footgun. For example, a 
common mistake is doing * instead of *-*.


If the allowed pattern elements are sufficiently unambiguous, there 
is no mistake, since `*' matches text including `-'.  In fact, when 
testing n "is tag FOO present?" predicate `*-foo-* | *-foo' would be 
correct.  (I assume that a CPU type will remain required and will 
remain first in the list.)


Sorry I meant as part of a larger pattern. With things like *-stuff-* 
vs *-*-stuff-*-*, the extra dashes are needed to make sure "stuff" 
matches the right component, and even then it only works if one knows 
the exact number of components (which can be accomplished by *-*... 
and the ordering of patterns). It is quite subtle!


For the "converging sequence" model, omitting the extra dashes is 
important, since the number of tags prior to a "floating tag" can 
vary.  (I would actually suggest making "gnu" such a floating tag in 
this model, with an exact definition to be obtained from a later 
discussion that would need to include RMS.)
Yeah I just mean the more components we have, the more a "sparse" 
representation is desirable, vs `something--another_thing` 
explicitly skipping things, because the latter is so annoying (needing 
to count). But that also creates ambiguities.


Allow the hypothetical --parse option to accept a PREFIX argument 
and you are pretty much there:


$ ./config.sub --parse=host x86_64-linux-gnu
host=x86_64-pc-linux-gnu
host_cpu=x86_64
host_vendor=pc
host_kernel=linux
host_os=gnu
$

That form should be both easily parsed by other tools and suitable 
for `eval` in shell scripts.

Yup! We're in agreement.


I agree testing is more robust, 

Re: Rethinking configuration tuples

[John Ericson]

I can submit two patches (effectively amending my prior, landed patch) 
with options that I think people would prefer. Will do that shortly.


On 9/11/23 17:53, Dmitry V. Levin wrote:

Hi,

On Mon, Sep 11, 2023 at 10:11:39AM +0800, Po Lu wrote:

Where are the config maintainers?  Karl Barry and company?
(I don't remember his e-mail nor do I have it at hand.)

I would expect them to be actively reading this list, but instead my
original request has been left twisting in the wind.

I'm the maintainer and I'm actively reading this list now,
a bit surprised to find so many messages at this time of year. :)

Apparently, you don't quite like commit
91f6a7f616b161c25ba2001861a40e662e18c4ad that added
$cpu-$vendor-windows-{gnu,msvc} support to config.sub, but I'm not sure
I understood what exactly do you suggest to change in this case.

Re: Rethinking configuration tuples

[John Ericson]

On 8/30/23 22:24, Jacob Bachmeyer wrote:


John Ericson wrote:

Err I mean, is there am example of a *-*-linux-$nongnu-musl?


I would expect that to name an embedded environment using Musl libc 
and the Linux kernel, but that is not a full system. (Example:  may 
not even have a shell at all)


I suppose except for the system() function in libc, I would consider 
this a distinction not needed for configs. The choice of what other 
programs to run (be they init or shell) feels to me not like a 
build-time / development configuration decision, but a a runtime / ops 
configuration decision. They aren't "viral" decisions in the way that 
the choice of libc is (since all shared objects that may be combined 
together need to agree on their deps, most notably libc).


Maybe this could go in the config per the "arbitrary many components, 
finer distinctions to the right" "converging sequence" approach, but 
then I would want this further to the right, e.g. 
aarch64-unknown-musl-noshell not aarch64-unknown-noshell-musl.


The choice of system service management is orthogonal to this, since 
it has minimal impact on user programs.  (Unless systemd gets even 
more outrageously invasive...)

Agreed, just wanted to double check.
Of course, if systemd *does* get sufficiently outrageously invasive, 
we might need a *-*-linux-systemd-glibc tuple...  (Since systemd 
gleefully makes extensive use of Linux-kernel-specific features, it 
cannot possibly be a standard on the GNU system, which supports 
multiple Free kernels.)


Yes I agree systemd probably can't be "bonafide GNU OS", but I take the 
opposite conclusion that this is evidence for the "gnu" for glibc is 
more important than the "gnu" for "true GNU OS".


Except configure usually does not need a "fully disambiguated" 
form---the canonical form produced by config.sub is fine, since 
configure is usually matching against the full tuple using shell 
case patterns.  The flat list with a defined order is optimal for 
this strategy, since it allows to easily check for the presence of 
any tag or combination of tags.
Shell case patterns can be a bit of a footgun. For example, a common 
mistake is doing * instead of *-*.


If the allowed pattern elements are sufficiently unambiguous, there is 
no mistake, since `*' matches text including `-'.  In fact, when 
testing n "is tag FOO present?" predicate `*-foo-* | *-foo' would be 
correct.  (I assume that a CPU type will remain required and will 
remain first in the list.)


Sorry I meant as part of a larger pattern. With things like *-stuff-* vs 
*-*-stuff-*-*, the extra dashes are needed to make sure "stuff" matches 
the right component, and even then it only works if one knows the exact 
number of components (which can be accomplished by *-*... and the 
ordering of patterns). It is quite subtle!


Allow the hypothetical --parse option to accept a PREFIX argument and 
you are pretty much there:


$ ./config.sub --parse=host x86_64-linux-gnu
host=x86_64-pc-linux-gnu
host_cpu=x86_64
host_vendor=pc
host_kernel=linux
host_os=gnu
$

That form should be both easily parsed by other tools and suitable for 
`eval` in shell scripts.

Yup! We're in agreement.


I agree testing is more robust, but for better or worse I still do 
see scripts using those host_* variables mentioned above. (Testing is 
possible but requires more care to get right for cross-compilation, 
for one.)




In this case the test is `case $host in ... esac`.

I would say it is better to case on (combinations of `host_*` variables 
than `$host`, because then knows exactly what components are being cased 
upon; there is no ambiguity. I think one should basically only use 
`host` as a block-box identifier (e.g. prefixing binaries) and and other 
time one would like to use `host` they should use the `host_*` variables 
instead.


The problem is still getting it /into/ config.sub:  config.sub expects 
a single command-line argument, while pre-parsed form spans a few lines.


I don't think that is so hard. config.sub accepts --gnu-long-args 
already )without confusing them as configs) so we can simply do 
something like


./config.sub --pre-categorized cpu=x86_64 vendor=pc kernel=linux os=gnu

and then there is no confusing the two forms of input.


[...]
I am not entirely certain why, but I know that there is some reason 
we call the common GNU/Linux systems *-*-linux-gnu instead of 
*-*-linux.


To be honest, I think this is basically the "call it GNU/Linux not 
Linux" controversy --- i.e. at the time it was done for social not 
technical reasons. I don't mind, since now that we have multiple 
libcs there /is/ a technical reason to distinguish. But this circles 
back to my hunch that Kernel (syscall interface) + libc (ABI) 
determines OS uniquely enough for config.sub's purposes.




That is possible, but still a valid reason for the GNU Project 

Re: Rethinking configuration tuples

[John Ericson]

On 8/27/23 23:59, Jacob Bachmeyer wrote:
>> I am OK with duck-typing, but what is "all meaningful ways"? Sure, POSIX is 
>> meaningful, the exact output of uname is not, etc. but where do we draw the 
>> line?
> That is a question for which I do not currently have a certain answer.  :/
Thanks, we'll keep trying to tease one out.

>>> This is also the framework in which *-*-linux-gnu-musl makes sense for a 
>>> system that uses Musl libc but is otherwise a GNU/Linux system.
>> 
>> Right but again where do we draw the line? For example, can one use systemd 
>> and its large entourage of intertwined software, or must one use GNU 
>> Shepherd or System V init?
>> 
> 
> In the case of *-*-linux-gnu and *-*-linux-gnu-musl, the difference is the C 
> runtime library (GNU libc vs. Musl libc) such that shared objects linked for 
> one ABI are not compatible with the other.  If Musl libc were exactly 100% 
> binary compatible with GNU libc, then there would be no *-*-linux-gnu-musl 
> platform, since it would be indistinguishable from *-*-linux-gnu.
Err I mean, is there am example of a *-*-linux-$nongnu-musl?

Agreed that if Musl was binary compatible with glibc, there would be no need to 
distinguish at the config level.

> The choice of system service management is orthogonal to this, since it has 
> minimal impact on user programs.  (Unless systemd gets even more outrageously 
> invasive...)
Agreed, just wanted to double check.

> Except configure usually does not need a "fully disambiguated" form---the 
> canonical form produced by config.sub is fine, since configure is usually 
> matching against the full tuple using shell case patterns.  The flat list 
> with a defined order is optimal for this strategy, since it allows to easily 
> check for the presence of any tag or combination of tags.
Shell case patterns can be a bit of a footgun. For example, a common mistake is 
doing * instead of *-*. I would rather case on disambiguated variables. Indeed, 
AC_CANONICAL_HOST computes host_cpu, host_vendor, and host_os for precisely 
that purpose. If config.sub could split out the disambiguated form, those 
variables could be defined more simply and robustly.

> Note that config.sub is itself a shell script, and handling JSON in shell is 
> a giant pain.  The most we could reasonably do is what config.sub already 
> does:  determine each component as a separate variable and then output that 
> by substituting text into a template.
>> Yes I agree config.sub in its current form (must be highly portable across 
>> different Bourne-shell derivatives) has no hope of parsing JSON. It could 
>> output it or it could also output your ${key}=${value}\n format, and it 
>> could also consume your format. Your format is ideal for it!
> Adding a prefix to each key in the key=value format is trivial and would 
> further help shell scripts that want to "parse by eval" but configure itself 
> tests predicates rather than caring exactly what part of the configuration 
> tuple means what.  Put another way, configure is usually looking for a yes/no 
> answer, so a pre-parsed form is less useful than a single string that can be 
> used for pattern matches.
I agree testing is more robust, but for better or worse I still do see scripts 
using those host_* variables mentioned above. (Testing is possible but requires 
more care to get right for cross-compilation, for one.)

> There is no reasonable way to feed the key=value format *into* config.sub: 
> configuration tuples are hyphen-delimited lists.
I think there is. The overall algorithm is roughly "(a) decide which component 
is which, (b) sanitize and normalize components decision to that decision". We 
would skip step (a) and go straight to step (b) in order to do this.

This indicates part of the value of doing this: rather than just "system 
testing" the entirety of config.sub, we would now have something closer to a 
"unit test" of part of it in isolation.

FWIW, this is similar to a rearranging the code to a support a mode where 
non-normal-form configs are rejected instead of normalized.

> Producing key=value format using config.sub's knowledge of valid tuples might 
> be reasonable for *other* systems to use instead of needing their own parsers.
Yes it is definitely necessary for that, and that is a good use-case for sure.

>>> Thank you; as I mentioned above, the goal is to best support heterogeneous 
>>> multi-arch systems, but recognizing a tension here.  For configure, the 
>>> configuration tuple should not contain information that can be determined 
>>> by testing, but for storing multiple binary sets, ABIs do need to be part 
>>> of the name, even if they can be determined by configure tests.
>> 
>> Agreed configure tests are better for the "long tail" of other attributes. 
>> (IMO if we were to define "operating system", it would be something like the 
>> "limit" of all configure checks.) 
>> 
>> But a big part of my "kernel-libc" thinking (and I think also Connor's) is 

Re: Rethinking configuration tuples

[John Ericson]

On 8/27/23 01:06, Jacob Bachmeyer wrote:
As I understand the history, Linux was the first clearly Free kernel 
available.  At the time, BSD still had a dark cloud hanging over it 
due to its (distant) origins at AT the BSD and AT UNIX codebases 
would not be legally recognized as separate until February 1994, 
although BSD had honestly (almost?) completely diverged from the AT 
codebase in June 1991 with Net/2.  Mach was still proprietary; RMS was 
(or would later be) campaigning for its liberation, which would not 
occur until some years later.  It is worth noting that Linux was 
originally a toy kernel, and it only attracted the effort it did and 
grew like it did because it was basically the last missing piece for 
fully Free systems at the time.


Yes that is how I understand it too

Ah sorry, I shouldn't have made reference to JSON at all --- what I 
really was getting at is the /abstract syntax/. In particular, rather 
than having an abstract syntax of "list of strings" (parsing today's 
concrete syntax by breaking on dash), where the meaning of each 
string is ambiguous / context-sensative, we have of "keys mapped to 
enumerations", i.e. one always knows the meaning of each component 
explicitly / without inspecting it or its context.


JSON or your flat list in canonical ordering (where I assume we are 
careful to never skip a type of component) are both valid concrete 
syntaxes that can be parsed / printed from this abstract syntax.




JSON is far too complicated to use here, except possibly as a 
"pre-parsed" form that config.sub could output on request for programs 
that want a structured form instead of parsing the tuple themselves.  
But for that case, why use JSON instead of a trivial multi-line 
key=value format?


Hypothetical Example:
$ config.sub --parse x86_64-linux-gnu
cpu=x86_64
vendor=pc
kernel=linux
os=gnu
$

Note that this example both canonicalizes and parses.


Yes that looks great to me. This shares the abstract syntax with what I 
had in mind, and anything that understands JSON can easily convert back 
and forth between the two.


I argue for "duck-typing" here from the user's perspective:  if and 
only if the system in all meaningful ways appears to be the GNU 
system, there should be a *-gnu* somewhere in the configuration tuple.


I am OK with duck-typing, but what is "all meaningful ways"? Sure, POSIX 
is meaningful, the exact output of uname is not, etc. but where do we 
draw the line?


This is also the framework in which *-*-linux-gnu-musl makes sense for 
a system that uses Musl libc but is otherwise a GNU/Linux system.


Right but again where do we draw the line? For example, can one use 
systemd and its large entourage of intertwined software, or must one use 
GNU Shepherd or System V init?



Effectively, a different libc is a different ABI.


Agreed, especially when the syscall interface isn't stable, like with 
many non-Windows kernels.


My larger goal here is to smooth the way for multi-arch systems, with 
/usr/CPU-VENDOR-KERNEL-OS-ABI or so as the --prefix for binaries built 
for each architecture.  This means that configuration tuples should be 
detailed enough to allow the needed distinctions, but not so detailed 
as to themselves become an artificial incompatibility.  In larger 
networked environments, even KERNEL and OS could vary.


It's a great goal, and mine too! :)


Yeah whatever windows-something we settle on for MinGW, I promise my 
offer still stands to try to get get LLVM to (a) accept it, and (b) 
steer people away from windows-gnu towards it.

Thanks.

No problem! :)
This is the major expectation that using *-*-windows-gnu for MinGW 
violates:  GNU implements POSIX and MinGW does not.  Using *-mingnu 
still leaves considerable room for confusion in my view, which using 
*-mingw avoids. 


That is fine with me. Agreed "mingnu" takes the proper noun and turns it 
back into a common noun phrase --- i.e. "minimal GNU" has many valid 
interpretations while "MinGW" avoids that be being a known quantity.


After that, I think we are close enough to convene a working group 
for a JSON/whatever explicit standard. And that would be amazing.


I still oppose JSON because it is way too verbose for this: 
configuration tuples need to be both expressive and simple enough to 
type at a shell prompt as arguments to configure. Using JSON by 
default would also be a very nasty "flag day" that would break all 
existing programs that use config.sub. Perhaps config.sub could 
accept an --as=json parameter for JSON output?
Yes exactly, JSON is a no-go for prefixed binaries, but probably 
better for things like Autoconf which needs to parse the output of 
config.sub either way.
No, because Autoconf uses the shell and JSON is a [*profanity elided*] 
to parse using shell constructs.  A flat list of hyphen-delimited tags 
is almost ideal for the parsing that configure needs to do.  In fact, 
with a few restrictions (met by using canonical ordering) this is what 

Re: Rethinking configuration tuples (was: Re: config.sub should normalize *-*-windows-*)

[John Ericson]

On 8/24/23 23:54, Jacob Bachmeyer wrote:

John Ericson wrote:


This is why I opened with "Operating System" lacks a coherent 
objective definition.


[...]


As I understand, historically, "operating systems" were proprietary 
monoliths and the GNU Project originally expected to produce another 
monolith, but /our/ monolith would be Free Software.  As an interim 
measure, the GNU utilities were designed to be widely portable across 
the various individually-monolithic proprietary operating systems then 
in use across a wide variety of hardware.  The broader Free Software 
Movement unexpectedly shattered that state of affairs, leading to the 
4-element configuration tuple form, when the Linux kernel became 
available and it was noticed that---oops!---GNU on Linux and GNU on 
HURD would have significant differences that at least some of the GNU 
packages would need to handle.  (For example, GNU libc is very 
different between Linux, where POSIX I/O maps fairly directly to 
underlying syscalls, and HURD, where POSIX I/O must be translated to 
Mach IPC, but both of these are Free GNU systems.)


This means that the GNU system is a somewhat blurry category, with 
many variants possible, and is orthogonal to "Linux":  there are 
GNU/Linux systems, GNU systems using other kernels, and Linux-based 
systems not using GNU at all.  This latter category is fairly common 
in embedded systems, where the GNU utilities are often eschewed for 
lighter-weight alternatives to save flash space (or, less honorably, 
to avoid GPL3).


Yes I agree with this state of affairs. I sometimes (but not always!) 
detect a sort of "Linux Scooped us" sentiment in GNU quarters, but as I 
see it portability and diversity of distros was pretty much inevitable 
--- replacing propriety Unix userlands with GNU software was a huge 
point in how GNU got going in academic/institutional environments in the 
early days, and even if Hurd got there before Linux there would be no 
reason to rip out that portability.


JSON is pretty much a hard no for me:  it is far too complex for what 
really needs to be a simple structure.  Flat strings work very well 
for the way that GNU software typically expects to parse a 
configuration tuple using shell constructs.  Perhaps it would be 
better to redefine configuration tuples as a flat list of tags with a 
canonical ordering?  (The reason for a canonical ordering is in part 
to ensure that all existing coherent configuration tuple strings 
remain valid and to ensure that text-based pattern matching continues 
to work.)


Ah sorry, I shouldn't have made reference to JSON at all --- what I 
really was getting at is the /abstract syntax/. In particular, rather 
than having an abstract syntax of "list of strings" (parsing today's 
concrete syntax by breaking on dash), where the meaning of each string 
is ambiguous / context-sensative, we have of "keys mapped to 
enumerations", i.e. one always knows the meaning of each component 
explicitly / without inspecting it or its context.


JSON or your flat list in canonical ordering (where I assume we are 
careful to never skip a type of component) are both valid concrete 
syntaxes that can be parsed / printed from this abstract syntax.





---

Concretely, I think these are pretty clear configs:

CPU-VENDOR-windows-mingnu # MinGW, MS C + GNU C++ and other GNU-ish 
things, TODO distinguish between MSVCRT and UCRT




I say that this one really should just be *-mingw.


Sure. I went with mingnu because the "w" is redundant with the 
"windows", but ultimately I care more about the pattern than the exact 
choice of identifiers / enumeration tags. (As we way in programming 
language land, I care about the thing "up to alpha-renaming").


Note that there are both MinGW32 and MinGW64, corresponding to 32-bit 
and 64-bit Windows APIs.  Should that be included or should the CPU 
type be used to distinguish?  (e.g.  i686-pc-windows-mingw is MinGW32 
and x86_64-pc-windows-mingw is MinGW64?)


Yes I think so. If you look at https://www.mingw-w64.org/downloads/ one 
even sees |x86_64-w64-mingw32| which is quite something, and 64-bit!


I think what happened is that "w32" to was chosen to mean the then-new 
win32 API/ABI, as opposed to DOS. Win64 as I understand is necessarily a 
new ABI because of the change in CPU arch, but not really a new API, 
being more of a "let's make the minimal amount of changes so the 
source/headers are portable" situation. So a combination of "same API" 
and "too lazy to update GNU config" made "mingw32" stick around.


f16804b79ee5a23a9994a1cdc760cd9ba813148a added mingw64 to GNU config in 
2012, which is far after the advent of 64-bit Windows.


In the proposed five-element form, MSVCRT and UCRT are easily 
distinguished.  Example:


i686-pc-windows-mingw-msvcrt
i686-pc-windows-mingw-ucrt
x86_64-pc-wind

Re: config.sub should normalize *-*-windows-*

[John Ericson]

Thanks Connor. I think we are both on the same page!

On 8/24/23 14:51, connor horman wrote:

It seems to me reading this thread that we've come into two 
conflicting realities:

* There exists targets that need to be distinguished, and
* They are not distinct in any component that config.sub has, 
therefore they cannot and should not be distinguished.


mingw and msvc both use the NT kernel, and the windows operating 
system. So it seems to me that windows, the OS, is the correct way to 
describe them. According to the discussions on this thread, they 
should thusly both canonicalize to the same target. And yet, not only 
is there desire to separate these targets, they already are.
Agreed. We can have our cake and eat it to both both: (a) distinguishing 
things which are already distinguished and (b) having configs follow 
consistent conventions.


LLVM (as well as my own target parsing tool) refer to the last two 
components as "sys" with two subcomponents (of which at least one 
exists), being os and env. IMO, this seems a far more coherent 
definition that satisfies the requirements, and even more correctly 
matches targets that already exist.

Agreed!


musl is another extreme example: There is no musl OS. The last 
component being musl refers to the use of the musl libc. The resulting 
binary can then be used on either a GNU system or a non-GNU linux 
system like alpine, void, or iglunix. Thus musl cannot be regarded as 
an "OPERATING_SYSTEM" but rather an an environment.

Agreed!


Even on linux-gnu the definition is murky at best. While I won't 
dispute the existence of a GNU operating system running atop the linux 
kernel, in many cases, the actual linux-gnu tag merely refers to 
glibc. Few things using targets nowadays actually cares about the rest 
of the tools, and when they do care that they exist (on --host or even 
--target), they typically don't care that they're provided by GNU, and 
even may not care that they match the interface of the tool provided 
by GNU. Only on --build are the tools really cared about, and I don't 
see many things matching the build tuple or even canonicalizing it. If 
we thus define an "Operating System" as "kernel+libc+tools atop that" 
it becomes clear to me that few things written nowadays care about the 
"GNU Operating System" and only really care about the "GNU Environment".


Agreed! Well put --- even if we were to find a rigorous objective 
definition for "Operating System" in general, encompassing a long tail 
of auxiliary interfaces, it would be overly specific what what things 
inspecting the output of config.sub actually care about.


(FWIW I am also fine saying there exists the "GNU Operating System", but 
to me "Operating System" is always an exercise in branding, tying 
together disparate components which always in principle (e.g. if we had 
the source code) could be mixed-and-matched in other ways.)


I would like this very much to happen, along with the Rust project 
which has it's own target defs (but similar as well).


I am glad I am not the only one!

John

Re: config.sub should normalize *-*-windows-*

[John Ericson]

This is why I opened with "Operating System" lacks a coherent objective 
definition.


The more pugilistic message is to say the rest of the world doesn't 
think the GNU operating system exists --- that there is simply a choice 
of kernel (Linux, k*BSD, Hurd, something else...) and choices of 
libraries and system components on top of that, and many combinations 
are possible. The rest of the world might say this in a mean way, but I 
say it is actually a /good/ thing --- software freedom means one /can/ 
choose my components à la carte, and only a lack of software freedom 
results in a kernel and mass of libraries outside one's control blurring 
together into a scary "take it or leave it" monolith we call an 
operating system.


On 8/24/23 08:51, Adam Joseph wrote:

Quoting Jacob Bachmeyer (2023-08-21 19:35:05)

No, we are not.  CPU-VENDOR-KERNEL-OS-LIBCABI, with at least one of the

If you want to redefine existing terms, please be forthright about the fact that
your proposal does so.

This usage is in conflict with the existing definition; LIBC and ABI are
subfields of OS.  It isn't resolving any "technical debt" -- it's sowing mass
confusion.

 From config.sub:

# The goal of this file is to map all the various variations of a given
# machine specification into a single specification in the form:
#   CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
# or in some cases, the newer four-part form:
#   CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
# It is wrong to echo any other type of specification.

The variable name "LIBCABI" comes from config.guess, where it is not described,
but is always parsed as a refinement of the OPERATING_SYSTEM field.  There is
never a hyphen between OPERATING_SYSTEM and LIBCABI because they are in fact
different parsings of the same string.


I'll add that all linux-* configs in config.guess use LIBC/LIBCABI. I 
take this as further evidence that distinguishing OSes atop Linux is 
useless. Per the above, I think this is good!



config tuples were originally triplets and now often feature a 4-element
CPU-VENDOR-KERNEL-OS form

Yes, we've had ~20 years to appreciate the confusion it caused, and now we know
better than to do something like that again.


Adam are you saying you prefer the state of 3-component configs?


It seems like a lot of the proposals in this thread are being evaluated not
based on whether or not they are coherent, but rather on whether or not they
take us a few nanometers closer to whatever happens to whatever LLVM's internal
implementation details happen to be this week.


I care about coherence, the reason I like to see what LLVM does that 
working from a parsed representation forces the software to be much more 
honest. Since GNU config doesn't reveal its categories but just spits 
out another opaque string, there is no external pressure for its 
categorization to be any good. LLVM, on the other hand, dispenses with 
strings entirely and just uses the enums, so it is forced to make sure 
those enums make sense and work for the branching the program has to do.


LLVM parsing of configs is ad-hoc Postel's law stuff like everyone else, 
but its internal representation is actually quite stable. Parsing is the 
ugly nasty part that gets to the pristine clear ontology on the other side.


Ultimately I would like to convene everyone to commit to an agreed upon 
internal representation too. E.g. clang and GNU config could both spit 
out some JSON that is unambiguous and should match. I think that would 
alleviate a lot of Adam's concerns about "following LLVM". But I don't 
think it is possible to convene the working group needed to standardize 
such a format yet, because there is little trust between parties. Moving 
us a "a few nanometers closer" on each side demonstrates that there is 
willingness to compromise.


---

Concretely, I think these are pretty clear configs:

CPU-VENDOR-windows-mingnu # MinGW, MS C + GNU C++ and other GNU-ish 
things, TODO distinguish between MSVCRT and UCRT


CPU-VENDOR-windows-cygnus # Cygwin

CPU-VENDOR-windows-msys # MSYS2, a lot like Cygwin

CPU-VENDOR-windows-msvc # MS C + MS C++

CPU-VENDOR-linux-gnu # gnu libc

CPU-VENDOR-linux-musl # musl libc

CPU-VENDOR-linux-android # bionic libc

I know Po Lu doesn't like them, because they overlap with existing ones. 
But what about you two, Adam and Jacob? I am trying to compromise 
between what various things do already, and and also correct things like 
windows-gnu (even if there is no such thing as the GNU operating system 
(only multiple GNU Hurd-supporting distros), I agree that MinGW is 
clearly not a complete enough of set of GNU software to earn the right 
to drop the "minimal" part).


If we can accept these, I think I will have no problem getting LLVM to 
accept windows-mingnu, and perhaps even warn/deprecate windows-gnu. 
After that, I think we are close enough to convene a working group for a 
JSON/whatever explicit standard. And that would be amazing.

Re: config.sub should normalize *-*-windows-*

[John Ericson]

On Mon, Aug 21, 2023, at 1:17 AM, Po Lu wrote:
> Jacob Bachmeyer  writes:
> 
> > No:  MinGW is Windows native "Win32" API while a future `windows-gnu'
> > would be the GNU system's POSIX API on an NT kernel.  These are *very*
> > different configurations; `windows-gnu' would more closely resemble
> > Cygwin.
> 
> This is not what the `x86_64-pc-windows-gnu' configuration presently
> canonicalized by config.sub represents.

I have offered multiple times to change it to windows-mingnu or something else. 
Let's not be hung up on this, it is just making a straw man of the broader 
project of making configs that are more consistent.

> > I say it would be more appropriate to accept `x86_64-pc-mingw64' as a
> > short form for `x86_64-pc-windows-mingw64', since Wine could enable a
> > `x86_64-pc-linux-mingw64' platform to exist.  (Wine's goal is that
> > that platform should be indistinguishable from
> > `x86_64-pc-windows-mingw64', but it is certainly a distinct
> > configuration from the user's perspective.)
> 
> Wine is a compatibility layer that emulates the MS-Windows kernel.  It
> is not config's role to report the intricacies of the operating system
> implementation, only details that affect user programs running under
> that operating system.

You have misunderstood Jacob's point, which is that the MinGW *interface* has 
multiple implementations, namely top Windows itself and via Wine. Indeed see 
https://manpages.ubuntu.com/manpages/kinetic/man1/winegcc-development.1.html, 
this already exists via winelib and GCC. (MinGW is basically "modify MS headers 
so they work with GCC", and thus the same modifications are needed whether we 
are going to run on windows or on some Unix with winelib.)

We never want to distinguish implementations that present the exact same 
interface (indeed, that defeats the point of re-implementing the same 
interface, going down this road yields a cat-and-mouse of endless lies like 
browser user-agent strings), but we *do* want to distinguish different 
interfaces.

> > But they already have drifted:  config tuples were originally triplets
> > and now often feature a 4-element CPU-VENDOR-KERNEL-OS form
> 
> Only as a result of a technical need to distinguish Linux-based GNU
> systems from other GNU systems.  Absent that requirement, we would
> simply call GNU/Linux systems *-*-gnu, Alpine *-*-alpine, and Android
> *-*-android.

You just said it! We have the exact same "technical need" on Windows as with 
Linux of identifying different platforms that share the same syscall interface. 
For the same reason we don't want people to have to write *-*-gnu | *-*-alpine 
| *-*-android (an endlessly growing list of special cases) to use e.g. the 
clone system call, we don't want them to have to maintain a big and ever 
growing list of Windows variants for a conditional that is just about Windows 
in general.

As a Nixpkgs developer, my goal is to see all the free software in the world 
packaged in a single way which will run (or can be cross-compiled to 
everywhere). This is very ambitious, and the only way it will work is if it is 
easy for upstream software to be portable. And it way to make it easy to be 
portable supporting all the variations is if we clean up foot-guns like this 
where upstream software has to maintain every-growing disjunctions rather than 
future-proof wildcards.

Sure, this sort of tech debt OCDing I am doing freely admit seems over kill for 
just one package (emacs) and one windows platform (MinGW), but please believe 
me when I say when considering all the variations and all the package it *does* 
become something worth practically caring about.

John

Re: config.sub should normalize *-*-windows-*

[John Ericson]

On 8/21/23 00:39, Po Lu wrote:

John Ericson  writes:


Thanks Jacob,

That's absolutely right that Win NT supports multiple personalities
and so all sorts of things are possible. (Indeed that is how WSL1
worked.)

MinGW stands for "Minimalist GNU for Windows" [1], and I suspect that
is why Saleem choose windows-gnu in that commit almost a decade ago. I
supposed we could say that "minimalist GNU" is not "GNU", and do
windows-mingnu or something, and then I could submit an LLVM patch to
try to support that. But I suppose I lean towards support configs that
at least one of GCC or Clang supports already, rather than making up
completely new stuff.

GNU config is part of the GNU project, developing the GNU operating
system, which opted for ``mingw'' many, many moons ago.  We are under no
obligation to adhere to LLVM standards, especially when they require us
to misrepresent the nature of a specific system configuration.


I agree the GNU project is not under any such obligation, and that's why 
I proposed windows-mingw as a compromise. It is more work for me to go 
make both GCC and LLVM support, but I rather do that than be stuck with 
plain mingw32.



Also, I would like to point out that the "scales to more variations"
argument is not at all hypothetical. If one looks at [2] one will see
that MSYS is a variation of Cygwin, and a mingw-style environments can
be made from the newer ucrt or older msvcrt. Today there are just too
many subtle variations to capture them all with sensible. It looks
like MSYS [3] reuses a triple for multiple configurations, and just
relies on users getting the PATH right, but that clearly isn't
ideal. Creating windows-* variants to handle them all in a consistent
and predictable manner is much better.

We can create new triplets for new environments once they do come into
existence.  But they should not duplicate existing ones, and they must
conform to the existing naming convention for configuration triplets.


There is no existing convention for windows. So far every time a new 
"brand name" 3rd position component has been chosen without any sort of 
pattern. Now that I've made (over the past few years) GNU config be more 
structured and more easily support longer configs, it is time to 
establish a convention. windows-* makes sense, and has precedent.


John

Re: config.sub should normalize *-*-windows-*

[John Ericson]

Thanks Jacob,

That's absolutely right that Win NT supports multiple personalities and 
so all sorts of things are possible. (Indeed that is how WSL1 worked.)


MinGW stands for "Minimalist GNU for Windows" [1], and I suspect that is 
why Saleem choose windows-gnu in that commit almost a decade ago. I 
supposed we could say that "minimalist GNU" is not "GNU", and do 
windows-mingnu or something, and then I could submit an LLVM patch to 
try to support that. But I suppose I lean towards support configs that 
at least one of GCC or Clang supports already, rather than making up 
completely new stuff.


Also, I would like to point out that the "scales to more variations" 
argument is not at all hypothetical. If one looks at [2] one will see 
that MSYS is a variation of Cygwin, and a mingw-style environments can 
be made from the newer ucrt or older msvcrt. Today there are just too 
many subtle variations to capture them all with sensible. It looks like 
MSYS [3] reuses a triple for multiple configurations, and just relies on 
users getting the PATH right, but that clearly isn't ideal. Creating 
windows-* variants to handle them all in a consistent and predictable 
manner is much better.


John

P.S. I've also CC'd Martin Storjso who has worked on LLVM MinGW things 
recently


[1]: https://en.wikipedia.org/wiki/MinGW

[2]: https://www.msys2.org/docs/environments/

[3]: https://packages.msys2.org/package/mingw-w64-x86_64-gcc 
https://packages.msys2.org/package/mingw-w64-ucrt-x86_64-gcc


On 8/20/23 22:40, Po Lu wrote:

Jacob Bachmeyer  writes:


At this time, yes.  However, the GNU utilities are designed to be
fairly portable and the NT kernel was designed to support multiple
ABIs, so a hypothetical port of GNU to run under MS-Windows is within
the realm of possibility.  (In fact, the underlying architecture of NT
should have all of the primitives needed to support HURD or a closely
related system.)  It is more likely that this would be implemented on
ReactOS (which aims for ABI compatibility with NT 5.1, is a stable
target, and is Free) first, but a hypothetical `x86_64-pc-windows-gnu'
(or perhaps `x86_64-pc-reactos-gnu') config tuple *is* a future
possibility.

This hypothesizing is not relevant here.  x86_64-pc-windows-* represents
MinGW, and should be normalized correspondingly.


And what would we canonicalize `x86_64-pc-windows-gnu' to, other than
itself, currently?

x86_64-pc-mingw64, which I mentioned at the outset of this thread.


It appears that config tuples may be drifting towards a 5-element
CPU-VENDOR-KERNEL-OS-LIBCABI form, with each of the last three
elements potentially optional, which makes any real tuple ambiguous,
except that the valid strings for KERNEL, OS, and LIBCABI are from
distinct sets.

Configuration tuples don't ``drift'', and they certainly should not
change or duplicate other triplets.

Re: config.sub should normalize *-*-windows-*

[John Ericson]

On Fri, Aug 18, 2023, at 8:24 PM, Po Lu wrote:
> GNU is an operating system.  Musl-based systems are not GNU, so -musl
> represents a ``musl-based operating system''.
> 
> > I do not think this is something to be frowned upon because "Operating
> > System.", after all, also lacks any rigorous objective definition.  
> 
> It does not, within the GNU project at least.  GNU is one operating
> system; Android is another, as are Musl-based systems.  And MS-Windows
> is a single operating system.

If Musl, GNU Libc, and Android are all different operating systems, why are 
MSVCRT, MinGW, and Cygwin not different operating systems? Listing off examples 
is *not* providing an objective definition.

The simplest reading of history that doesn't require any contortions is that 
MinGW and Cygwin predated configs with more than 3 components, but Android did 
not. Had those Windows-based platforms been introduced later, something like 
the configs that Saleem added to LLVM would have been used from the get go --- 
grouping the Windows-based platforms and grouping the Linux-based platforms are 
both advantageous ways of categorizing things, and advantageous for the same 
reasons.

> How is that worse than forcing every program wishing to support MS-Windows to
> introduce express support for 2 or 3 disparate and incorrect triplets?

As I said in the other email, I am not forcing anyone to do anything.

> Anyway, I plan to merge the latest config.* into Emacs soon.  So
> speaking as someone responsible, in part, for keeping the MS-Windows
> port of Emacs in working order, I would like to see the change I
> illustrated installed ASAP.

You can take the latest version and do nothing else. Anyone that uses 
*-windows-gnu will have their build fail, just as it fails today. There is no 
problem.

John

Re: triple stability, request for release tags

[John Ericson]

My intention was never to force every project to support both. You are free to 
only suport -mingw* for emacs if you want. I would submit patches to projects 
to have them support both, but those projects are free to reject those patches 
too. If no project wants to accept those patches, then, yes, my change to GNU 
config should be reverted.

On the other hand, some other project leaders may agree with me that the burden 
of adding a second normal form is worth the benefit pf having a more consistent 
convention for Windows that makes it (a) easy to add more variations if they 
come up in the future (b) easy to not care which variation with a -windows-* 
wildcard, rather than explicitly listing *mingw* | ??? | ….  Having the entries 
I added is necessary to unblock me and like-minded projects working to support 
these configs for these purposes.

Two normal forms is not ideal, but its the only way I see that allows us trying 
to clean up this longstanding technical debt of ad-hoc windows configs without 
breaking backwards compatibility.

Ultimately this tradeoff is a manner of opinion; I don't think there is a 
clear-cut policy that my accepted changes should be reverted. I would 
appreciate you, Po Lu, not implying my changes are an obvious affront, and 
instead we can weigh all sides.

John

On Sat, Aug 19, 2023, at 1:37 AM, Po Lu wrote:
> Adam Joseph  writes:
> 
> > Quoting Zack Weinberg (2023-08-18 04:42:32)
> >> On Thu, Aug 17, 2023, at 8:34 PM, Po Lu wrote:
> >> > ... such blunders should be ignored, or at least normalized...
> >>
> >> Even more important than this is the principle that config.sub canonical 
> >> names
> >> are *never* changed, even if they are wrong according to some external
> >> standard.
> >
> > The stability of the set of accepted triples is precious to me as well.
> >
> > However the patch in question [1] was applied [2] less than seven days 
> > after it
> > was submitted.  It is a bit unfair to quash Po Lu's concerns simply because 
> > he
> > happened to be on vacation that particular week.
> 
> I believe Zack was speaking in favor of canonicalizing the -windows-*
> names.  But if he wasn't, then consider that the recently introduced
> ``triplets'' actually duplicate existing ones -- and by doing so,
> constitute a change to the canonicalized names produced by config.sub.
> 
> So now Emacs will need to accept:
> 
>   # MinGW64
>   x86_64-*-* )
> case "${canonical}" in
>   *-mingw* )
>   *-windows-gnu )
> 
> in addition to just *-mingw*.  Analogous modifications to configure must
> even be retroactively effected on previous releases of Emacs, since we
> recommend that config.sub and config.guess always be updated to their
> latest versions.
> 
> 

Re: config.sub should normalize *-*-windows-*

[John Ericson]

On 8/18/23 07:42, Zack Weinberg wrote:

> On Thu, Aug 17, 2023, at 8:34 PM, Po Lu wrote:
> ...
> 
>> Given that the MinGW ABI does not constitute the GNU operating system
>> executing on the MS-Windows kernel, and MSVC is not an operating system,
>> such blunders should be ignored, or at least normalized...
In fairness I just recently submitted the patches added them, so absent a clear 
notion of GNU config releases I think a grace period where we can reconsider 
recently added changes is acceptable.

> Even more important than this is the principle that config.sub canonical 
> names are *never* changed, even if they are wrong according to some external 
> standard.
That said, I don't think we should so normalize them. I took them from LLVM, 
which has supported them for years and normalized in the *other* direction 
(i.e. to these), and Rust which follows LLVM's lead. I knew we couldn't change 
the old ones to normalize to the new ones, so I thought a fair middle ground 
was that neither would normalize to the other.

For the record LLVM, Rust, and even sometimes GNU config don't treat 
*-*-foo-bar as *-*-$kernel-$os, but rather *-*-$kernel-$abi. Where ABI is a 
sort of catch-all residual. This is why e.g. riscv-unknown-linux-musl is 
accepted --- no one would think the Musl libc is an operating system! Rather 
"gnu" is interpreted to be mean "glibc, libstdcxx++, etc.".

I do not think this is something to be frowned upon because "Operating 
System.", after all, also lacks any rigorous objective definition. At the end 
of the day there is:

 1. The syscall interface to communicate with "the outside world". (By "kernel" 
we really mean syscall interface, it is possible for two different 
implementations, like the actual Windows kernel, and Wine, to support the same 
syscall interface.)
 2. Other code linked into the same process. ABI covers the "most important" 
parts of this, especially when the userland ABI is *more* stable than the 
syscall ABI (Many BSDs, some Windows NT things, etc.)
And even ignoring all that, the *windows*-* convention makes clear that these 
are variations of extra stuff atop on Windows. In many instances, it doesn't 
matter which one of them is in use. Using the new triples makes it easier for 
that agnostic code to roll with the punches.



My intention in adding these to GNU config was to then rework our Windows cross 
compilation in Nixpkgs to use them, which would mean likewise submitting 
patches to GCC and other things to accept them too. Normalizing them away would 
prevent me from doing all these other yak shaves, and trying to get the various 
flavors of Windows cross to work more consistently, because everything 
downstream from config.sub invocations would work the same way as before. IMO 
that would basically defeat the purpose of accepting them at all in GNU config 
--- better to reject that do a normalization that may not be desired.

Cheers,

John

P.S. CCing Saleem Abdulrasool who originally added them to LLVM in 
https://reviews.llvm.org/D2947, and who has continued to work on LLVM-land 
Windows support, e.g. for Swift. (I imagine Swift, like Rust, also uses the 
*windows*-* ones.) Perhaps he may have some additional insight to add.

[PATCH] config.sub: Accept LLVM-style $cpu-$vendor-windows-cygnus

[John Ericson]

In 91f6a7f616b161c25ba2001861a40e662e18c4ad I supported `windows-gnu`
and `windows-msvc`, but I forgot about the last one: `windows-cygnus`.

This LLVM commit [1] introduced all 3. (I wish I had found it before!)
But at least we can use it to ensure I am not missing one now.

This came up in this Nixpkgs PR [2] where I was told my previous patch
only partially solved the problem, because I forgot about this case.

[1]: 
https://github.com/llvm/llvm-project/commit/edbdd2e5df8b59dac8ae5f45059407f8a79850d6

[2]: https://github.com/NixOS/nixpkgs/pull/249090
---
 config.sub| 6 +++---
 testsuite/config-sub.data | 1 +
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/config.sub b/config.sub
index 6ae2502..bea4f3a 100755
--- a/config.sub
+++ b/config.sub
@@ -1744,7 +1744,7 @@ case $os in
;;
none)
;;
-   kernel* | msvc* )
+   kernel* | msvc* | cygnus* )
# Restricted further below
;;
*)
@@ -1763,7 +1763,7 @@ case $kernel-$os in
;;
managarm-mlibc* | managarm-kernel* )
;;
-   windows*-gnu* | windows*-msvc*)
+   windows*-gnu* | windows*-msvc* | windows*-cygnus* )
;;
-dietlibc* | -newlib* | -musl* | -relibc* | -uclibc* | -mlibc* )
# These are just libc implementations, not actual OSes, and thus
@@ -1779,7 +1779,7 @@ case $kernel-$os in
echo "Invalid configuration '$1': '$kernel' does not support 
'$os'." 1>&2
exit 1
;;
-   *-msvc* )
+   *-msvc* | *-cygnus* )
echo "Invalid configuration '$1': '$os' needs 'windows'." 1>&2
exit 1
;;
diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
index ba934b6..3752f0d 100644
--- a/testsuite/config-sub.data
+++ b/testsuite/config-sub.data
@@ -887,6 +887,7 @@ x86_64-twizzler 
x86_64-pc-twizzler
 x86_64-unknown-ptx x86_64-sequent-ptx
 x86_64-windows x86_64-pc-windows
 x86_64-windows-gnu x86_64-pc-windows-gnu
+x86_64-windows-cygnus  x86_64-pc-windows-cygnus
 x86_64-windows-msvcx86_64-pc-windows-msvc
 x86_64-wrs-vxworks x86_64-wrs-vxworks
 x86_64-wrs-vxworks-simlinuxx86_64-wrs-vxworks-simlinux
-- 
2.40.1

[PATCH] Systematize parsing of machine code formats

[John Ericson]

Instead of treating them as OSes, we treat them as their own category.
This is modeled on what LLVM does with its `ObjectFormatType` enum [1],
advancing my long-running project of trying to nudge GNU config and LLVM
towards each other, taking the best ideas of both.

Currently, my emphasis is just on code cleanup. There are just a few
tests for newly supported changes that fall out of this. But down the
road, this also opens the door to parsing configs with more than 4
components, like [2].

[1]:
https://llvm.org/doxygen/classllvm_1_1Triple.html#a83e907e55fa50e093caa96a0aff96201

[2]:
https://github.com/llvm/llvm-project/blob/a18266473be1439d324059afa0e8b124f0466428/llvm/unittests/TargetParser/TripleTest.cpp#L1873C50-L1873C77
added in
https://github.com/llvm/llvm-project/commit/28b82bc39ef076527c07718724913f70b5d60b69
---
 config.sub| 133 ++
 testsuite/config-sub.data |   2 +
 2 files changed, 92 insertions(+), 43 deletions(-)

diff --git a/config.sub b/config.sub
index 6ae2502..c8dc08d 100755
--- a/config.sub
+++ b/config.sub
@@ -1284,11 +1284,12 @@ esac
 
 # Decode manufacturer-specific aliases for certain operating systems.
 
-if test x$basic_os != x
+if test x"$basic_os" != x
 then
 
 # First recognize some ad-hoc cases, or perhaps split kernel-os, or else just
 # set os.
+obj=
 case $basic_os in
gnu/linux*)
kernel=linux
@@ -1488,10 +1489,16 @@ case $os in
os=eabi
;;
*)
-   os=elf
+   os=
+   obj=elf
;;
esac
;;
+   aout* | coff* | elf* | pe*)
+   # These are machine code file formats, not OSes
+   obj=$os
+   os=
+   ;;
*)
# No normalization, but not necessarily accepted, that comes 
below.
;;
@@ -1510,12 +1517,15 @@ else
 # system, and we'll never get to this point.
 
 kernel=
+obj=
 case $cpu-$vendor in
score-*)
-   os=elf
+   os=
+   obj=elf
;;
spu-*)
-   os=elf
+   os=
+   obj=elf
;;
*-acorn)
os=riscix1.2
@@ -1525,28 +1535,35 @@ case $cpu-$vendor in
os=gnu
;;
arm*-semi)
-   os=aout
+   os=
+   obj=aout
;;
c4x-* | tic4x-*)
-   os=coff
+   os=
+   obj=coff
;;
c8051-*)
-   os=elf
+   os=
+   obj=elf
;;
clipper-intergraph)
os=clix
;;
hexagon-*)
-   os=elf
+   os=
+   obj=elf
;;
tic54x-*)
-   os=coff
+   os=
+   obj=coff
;;
tic55x-*)
-   os=coff
+   os=
+   obj=coff
;;
tic6x-*)
-   os=coff
+   os=
+   obj=coff
;;
# This must come before the *-dec entry.
pdp10-*)
@@ -1568,19 +1585,24 @@ case $cpu-$vendor in
os=sunos3
;;
m68*-cisco)
-   os=aout
+   os=
+   obj=aout
;;
mep-*)
-   os=elf
+   os=
+   obj=elf
;;
mips*-cisco)
-   os=elf
+   os=
+   obj=elf
;;
mips*-*)
-   os=elf
+   os=
+   obj=elf
;;
or32-*)
-   os=coff
+   os=
+   obj=coff
;;
*-tti)  # must be before sparc entry or we get the wrong os.
os=sysv3
@@ -1589,7 +1611,8 @@ case $cpu-$vendor in
os=sunos4.1.1
;;
pru-*)
-   os=elf
+   os=
+   obj=elf
;;
*-be)
os=beos
@@ -1670,10 +1693,12 @@ case $cpu-$vendor in
os=uxpv
;;
*-rom68k)
-   os=coff
+   os=
+   obj=coff
;;
*-*bug)
-   os=coff
+   os=
+   obj=coff
;;
*-apple)
os=macos
@@ -1691,7 +1716,8 @@ esac
 
 fi
 
-# Now, validate our (potentially fixed-up) OS.
+# Now, validate our (potentially fixed-up) individual pieces (OS, OBJ).
+
 case $os in
# Sometimes we do "kernel-libc", so those need to count as OSes.
musl* | newlib* | relibc* | uclibc*)
@@ -1719,11 +1745,11 @@ case $os in
 | mirbsd* | netbsd* | dicos* | openedition* | ose* \
 | 

[PATCH] Accept $cpu-$vendor-none-{coff,elf}

[John Ericson]

These are not real OSes, they are object file formats. There is a
longstanding tradition of using them for embedded/freestanding
programming, so it makes sense to parse them with `kernel=none`.

(I have a WIP future patch that systematizes parsing these non-OSes a
bit more. That also opens the door to parsing a 5th component as LLVM
can do.)

This change unblocks an issue we've been having with Nixpkgs (see
https://github.com/NixOS/nixpkgs/issues/165836 for the longer version).
---
 config.sub| 4 
 testsuite/config-sub.data | 4 
 2 files changed, 8 insertions(+)

diff --git a/config.sub b/config.sub
index 9865d6e..86fbf47 100755
--- a/config.sub
+++ b/config.sub
@@ -1816,6 +1816,10 @@ case $kernel-$os in
;;
*-eabi* | *-gnueabi*)
;;
+   none-coff* | none-elf*)
+   # None (no kernel, i.e. freestanding / bare metal),
+   # can be paired with an output format "OS"
+   ;;
-*)
# Blank kernel with real OS is always fine.
;;
diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
index bb19dc2..c696919 100644
--- a/testsuite/config-sub.data
+++ b/testsuite/config-sub.data
@@ -91,7 +91,9 @@ arm-sysgo-pikeos  arm-sysgo-eabi
 arm-tirtos arm-unknown-tirtos
 arm-uclinux-uclibcgnueabi  
arm-unknown-uclinux-uclibcgnueabi
 arm-unknown-netbsdelf7.0   arm-unknown-netbsdelf7.0
+arm-unknown-none-coff  arm-unknown-none-coff
 arm-unknown-none-eabi  arm-unknown-none-eabi
+arm-unknown-none-elf   arm-unknown-none-elf
 arm-unknown-riscos arm-unknown-riscos
 arm-zephyr arm-unknown-zephyr
 arm64-apple-darwin20.0.0   aarch64-apple-darwin20.0.0
@@ -110,6 +112,7 @@ armv6-unknown-netbsdelf7.0  
armv6-unknown-netbsdelf7.0
 armv6-unknown-netbsdelf7.0-eabi
armv6-unknown-netbsdelf7.0-eabi
 armv6-unknown-netbsdelf7.0-eabihf  
armv6-unknown-netbsdelf7.0-eabihf
 armv6-unknown-none-eabiarmv6-unknown-none-eabi
+armv6-unknown-none-eabiarmv6-unknown-none-eabi
 armv6eb-unknown-netbsdelf7.0   armv6eb-unknown-netbsdelf7.0
 armv6eb-unknown-netbsdelf7.0-eabi  
armv6eb-unknown-netbsdelf7.0-eabi
 armv6eb-unknown-netbsdelf7.0-eabihf
armv6eb-unknown-netbsdelf7.0-eabihf
@@ -639,6 +642,7 @@ riscv32be-elf   
riscv32be-unknown-elf
 riscv32be-linux
riscv32be-unknown-linux-gnu
 riscv64riscv64-unknown-none
 riscv64-company-elfriscv64-company-elf
+riscv64-company-none-elf   riscv64-company-none-elf
 riscv64-elfriscv64-unknown-elf
 riscv64-hcos   riscv64-unknown-hcos
 riscv64-linux  riscv64-unknown-linux-gnu
-- 
2.40.1

Re: [PATCH] config.sub: Accept LLVM-style `$cpu-$vendor-windows-{gnu, mingw}`

[John Ericson]

Thank you very much Dmitry, and apologies for the duplicate emails. I 
seem to always forget I am subscribed with list@... not git@... :).


Cheers,

John

On 7/3/23 15:50, Dmitry V. Levin wrote:

On Mon, Jun 26, 2023 at 07:56:57PM -0400, John Ericson wrote:

In older times, MinGW (GCC toolchain with modified windows headers) was
the only free software toolchain for Windows. But now, LLVM has
excellent support both for MinGW ABI and Microsoft's own. (The
distinction matters for C++ more than C.)

LLVM[1], Rust[2], and other projects have taken to differentiating these
two as `...windows-gnu` vs `...windows-msvc`. I think that makes a lot
of sense, as it correctly identifiers both their commonalities and their
differences.

I agree that makes sense.
I've corrected the commit message a bit and applied.

Thanks,

[PATCH] config.sub: Accept LLVM-style `$cpu-$vendor-windows-{gnu, mingw}`

[John Ericson]

In older times, MinGW (GCC toolchain with modified windows headers) was
the only free software toolchain for Windows. But now, LLVM has
excellent support both for MinGW ABI and Microsoft's own. (The
distinction matters for C++ more than C.)

LLVM[1], Rust[2], and other projects have taken to differentiating these
two as `...windows-gnu` vs `...windows-msvc`. I think that makes a lot
of sense, as it correctly identifiers both their commonalities and their
differences.

A lot of MinGW-supporting software, most notably GCC itself, will
presumably continue to use configs like `x86_64-pc-mingw32` and
`i686-pc-mingw32`. That's fine; this patch doesn't normalize them away
(like LLVM does) or remove them! If and when that software wants to
support the MSVC ABI without requiring MSVC itself, they can switch to
these newer configurations.

[1]: 
https://github.com/llvm/llvm-project/blob/a18266473be1439d324059afa0e8b124f0466428/llvm/unittests/TargetParser/TripleTest.cpp#L1907-L1951

[2]: 
https://github.com/rust-lang/rust/blob/36fb58e433c782e27dd41034284e157cf86d587f/compiler/rustc_target/src/spec/mod.rs#L1255-L1271
---
 config.sub| 11 +--
 testsuite/config-sub.data |  2 ++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/config.sub b/config.sub
index f6ede1d..f7e93ce 100755
--- a/config.sub
+++ b/config.sub
@@ -145,7 +145,8 @@ case $1 in
nto-qnx* | linux-* | uclinux-uclibc* \
| uclinux-gnu* | kfreebsd*-gnu* | knetbsd*-gnu* | 
netbsd*-gnu* \
| netbsd*-eabi* | kopensolaris*-gnu* | cloudabi*-eabi* \
-   | storm-chaos* | os2-emx* | rtmk-nova* | managarm-*)
+   | storm-chaos* | os2-emx* | rtmk-nova* | managarm-* \
+   | windows-* )
basic_machine=$field1
basic_os=$maybe_os
;;
@@ -1766,7 +1767,7 @@ case $os in
;;
none)
;;
-   kernel* )
+   kernel* | msvc* )
# Restricted further below
;;
*)
@@ -1785,6 +1786,8 @@ case $kernel-$os in
;;
managarm-mlibc* | managarm-kernel* )
;;
+   windows*-gnu* | windows*-msvc*)
+   ;;
-dietlibc* | -newlib* | -musl* | -relibc* | -uclibc* | -mlibc* )
# These are just libc implementations, not actual OSes, and thus
# require a kernel.
@@ -1799,6 +1802,10 @@ case $kernel-$os in
echo "Invalid configuration '$1': '$kernel' does not support 
'$os'." 1>&2
exit 1
;;
+   *-msvc* )
+   echo "Invalid configuration '$1': '$os' needs 'windows'." 1>&2
+   exit 1
+   ;;
kfreebsd*-gnu* | kopensolaris*-gnu*)
;;
vxworks-simlinux | vxworks-simwindows | vxworks-spe)
diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
index 3b622ab..bb19dc2 100644
--- a/testsuite/config-sub.data
+++ b/testsuite/config-sub.data
@@ -865,6 +865,8 @@ x86_64-sortix   
x86_64-pc-sortix
 x86_64-twizzlerx86_64-pc-twizzler
 x86_64-unknown-ptx x86_64-sequent-ptx
 x86_64-windows x86_64-pc-windows
+x86_64-windows-gnu x86_64-pc-windows-gnu
+x86_64-windows-msvcx86_64-pc-windows-msvc
 x86_64-wrs-vxworks x86_64-wrs-vxworks
 x86_64-wrs-vxworks-simlinuxx86_64-wrs-vxworks-simlinux
 x86_64-wrs-vxworks-simwindows  x86_64-wrs-vxworks-simwindows
-- 
2.40.1

Re: [PATCH] config.sub: Accept LLVM-style `$cpu-$vendor-windows-{gnu, mingw}`

[John Ericson]

For the record, this came out of https://github.com/NixOS/nixpkgs/pull/235230. 
I am one of the original/main authors of Nixpkgs/NixOS's platform specification 
system, and also a few years back contributed a major refactor/systematization 
of GNU config. (Look no further than the recent 
63acb96f92473ceb5e21d873d7c0aee266b3d6d3 which fixed a spelling of mine. Sorry!)

It has been a long, slow project of mind to slowly nudge all the major platform 
specification systems in the world towards each other and a more systematic 
middle ground. This could be considered another small step in that journey.

I have yet to investigate but my co-contributor who authored that pull request 
may have also found some bugs in GNU config too. We'll be happy to submit 
patches if so.

John

On Mon, Jun 26, 2023, at 7:56 PM, John Ericson wrote:
> In older times, MinGW (GCC toolchain with modified windows headers) was
> the only free software toolchain for Windows. But now, LLVM has
> excellent support both for MinGW ABI and Microsoft's own. (The
> distinction matters for C++ more than C.)
> 
> LLVM[1], Rust[2], and other projects have taken to differentiating these
> two as `...windows-gnu` vs `...windows-msvc`. I think that makes a lot
> of sense, as it correctly identifiers both their commonalities and their
> differences.
> 
> A lot of MinGW-supporting software, most notably GCC itself, will
> presumably continue to use configs like `x86_64-pc-mingw32` and
> `i686-pc-mingw32`. That's fine; this patch doesn't normalize them away
> (like LLVM does) or remove them! If and when that software wants to
> support the MSVC ABI without requiring MSVC itself, they can switch to
> these newer configurations.
> 
> [1]: 
> https://github.com/llvm/llvm-project/blob/a18266473be1439d324059afa0e8b124f0466428/llvm/unittests/TargetParser/TripleTest.cpp#L1907-L1951
> 
> [2]: 
> https://github.com/rust-lang/rust/blob/36fb58e433c782e27dd41034284e157cf86d587f/compiler/rustc_target/src/spec/mod.rs#L1255-L1271

[PATCH] config.sub: Accept LLVM-style `$cpu-$vendor-windows-{gnu, mingw}`

[John Ericson]

In older times, MinGW (GCC toolchain with modified windows headers) was
the only free software toolchain for Windows. But now, LLVM has
excellent support both for MinGW ABI and Microsoft's own. (The
distinction matters for C++ more than C.)

LLVM[1], Rust[2], and other projects have taken to differentiating these
two as `...windows-gnu` vs `...windows-msvc`. I think that makes a lot
of sense, as it correctly identifiers both their commonalities and their
differences.

A lot of MinGW-supporting software, most notably GCC itself, will
presumably continue to use configs like `x86_64-pc-mingw32` and
`i686-pc-mingw32`. That's fine; this patch doesn't normalize them away
(like LLVM does) or remove them! If and when that software wants to
support the MSVC ABI without requiring MSVC itself, they can switch to
these newer configurations.

[1]: 
https://github.com/llvm/llvm-project/blob/a18266473be1439d324059afa0e8b124f0466428/llvm/unittests/TargetParser/TripleTest.cpp#L1907-L1951

[2]: 
https://github.com/rust-lang/rust/blob/36fb58e433c782e27dd41034284e157cf86d587f/compiler/rustc_target/src/spec/mod.rs#L1255-L1271
---
 config.sub| 11 +--
 testsuite/config-sub.data |  2 ++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/config.sub b/config.sub
index f6ede1d..f7e93ce 100755
--- a/config.sub
+++ b/config.sub
@@ -145,7 +145,8 @@ case $1 in
nto-qnx* | linux-* | uclinux-uclibc* \
| uclinux-gnu* | kfreebsd*-gnu* | knetbsd*-gnu* | 
netbsd*-gnu* \
| netbsd*-eabi* | kopensolaris*-gnu* | cloudabi*-eabi* \
-   | storm-chaos* | os2-emx* | rtmk-nova* | managarm-*)
+   | storm-chaos* | os2-emx* | rtmk-nova* | managarm-* \
+   | windows-* )
basic_machine=$field1
basic_os=$maybe_os
;;
@@ -1766,7 +1767,7 @@ case $os in
;;
none)
;;
-   kernel* )
+   kernel* | msvc* )
# Restricted further below
;;
*)
@@ -1785,6 +1786,8 @@ case $kernel-$os in
;;
managarm-mlibc* | managarm-kernel* )
;;
+   windows*-gnu* | windows*-msvc*)
+   ;;
-dietlibc* | -newlib* | -musl* | -relibc* | -uclibc* | -mlibc* )
# These are just libc implementations, not actual OSes, and thus
# require a kernel.
@@ -1799,6 +1802,10 @@ case $kernel-$os in
echo "Invalid configuration '$1': '$kernel' does not support 
'$os'." 1>&2
exit 1
;;
+   *-msvc* )
+   echo "Invalid configuration '$1': '$os' needs 'windows'." 1>&2
+   exit 1
+   ;;
kfreebsd*-gnu* | kopensolaris*-gnu*)
;;
vxworks-simlinux | vxworks-simwindows | vxworks-spe)
diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
index 3b622ab..bb19dc2 100644
--- a/testsuite/config-sub.data
+++ b/testsuite/config-sub.data
@@ -865,6 +865,8 @@ x86_64-sortix   
x86_64-pc-sortix
 x86_64-twizzlerx86_64-pc-twizzler
 x86_64-unknown-ptx x86_64-sequent-ptx
 x86_64-windows x86_64-pc-windows
+x86_64-windows-gnu x86_64-pc-windows-gnu
+x86_64-windows-msvcx86_64-pc-windows-msvc
 x86_64-wrs-vxworks x86_64-wrs-vxworks
 x86_64-wrs-vxworks-simlinuxx86_64-wrs-vxworks-simlinux
 x86_64-wrs-vxworks-simwindows  x86_64-wrs-vxworks-simwindows
-- 
2.40.1

Re: Target Compatibility: Targets accepted by rustc but not config.sub

[John Ericson]

Hi,

I've been hoping this sort of target-normalizing effort would occur at some 
point, so glad to see your email! I largely rewrote config.sub in recent years 
to make it's parsing more systematic, and have tried to organize the platforms 
for my distro (NixOS) too, so the friction between various software here has 
bugged me for a while. I would try to rope in LLVM too, to really get this done 
once and for all. (Maybe we can make some structured e.g. JSON normalizations 
too :)).

I think the biggest sticking point will be how the 3rd and 4th components are 
handled. config.sub conventionally treats the 4th as the OS, and the 3rd is 
extra kernel info. LLVM treats the 3rd as the OS, and the 4tht as extra ABI 
info. (I think this confusion arose due to different interpretations of 
"..linux-gnu"!)

The LLVM way appears to be winning, and thus config.sub now has some special 
cases to support it, but nothing systematic yet.

Cheers,

John

On Thu, Jul 22, 2021, at 12:08 PM, connor horman wrote:
> Hello.
> Based on some discussion on the rust-lang zulip forum "Deprecating 
> target_vendor" 
> ,
>  a couple weeks ago I compiled a list of targets which are accepted by the 
> official rust compiler, rustc (https://github.com/rust-lang/rust, 
> https://doc.rust-lang.org/nightly/rustc/targets/index.html), but not by 
> config.sub, however I neglected to post the list anywhere.
> 
> Of the 167 targets that rustc accepts, 52 are not accepted. Attached is the 
> list of the unaccepted targets (unsupported). I have also attached the output 
> from config.sub in the failing cases (comprehensive), as well as the script 
> used to generate the list (test-rustc-targets). 
> 
> *Attachments:*
>  * comprehensive
>  * unsupported
>  * test-rustc-targets

Re: [PATCH] Add phantomos targets

[John Ericson]

Would you mind adding a test for phantom-kernel too?

On 2/1/21 10:45 PM, connor horman wrote:

Hello,
This patch adds support to config.sub for the PhantomOS target, an 
operating system project which I am developing. In particular this 
adds support for two basic_os names: phantom-kernel (the target for 
building the kernel, and modules for the kernel), and phantom-user 
(which is the default and canonical userspace), as well as 
canonicalizing the name phantom into phantom-user.

It also adds a test to ensure that the target is parsed properly.

Output from make check (note: MAKEFLAGS=-j4 in environment):
cd testsuite && bash config-guess.sh && rm uname
cd testsuite && bash config-sub.sh
PASS: config.sub checks (847 tests)
PASS: config.sub idempotency checks (784 tests)
PASS: config.sub canonicalise each config.guess testcase (134 tests)
PASS: config.guess checks (134 tests)

Re: config.sub patch: recognize four-part configuration name for VxWorks OS

[John Ericson]

OK here is the my alternative that passes the same tests.

In case any is interested, let me talk about underlying issue that makes 
this so non-intuitive (more than I initially expected!) is that there is 
a tension between gnu config thinking


$kernel-$os

and other tools thinking

$os-$extra_info

(Even though the $kernel $os env vars are new from me in ~ last 2 years, 
config.sub was informally parsing that way for decades.)


This tension basically arose I think when someone reinterpreted 
linux-gnu not as GNU/linux, but Linux (an OS) + glibc ABI.


The result is config.sub to cope is calling things like `eabihf` or 
`musl` valid OSs to be filtered later, which is awkward and unintuitive.


Hopefully this can be untangled someday. (I would love to sit down with 
a bunch of interested parties and come up with e.g. a new JSON 
convention or something.)


John

On 1/7/21 10:13 AM, John Ericson wrote:


I don't this this patch is right. You are adding another "ad hoc" 
case, but we should strive not to do that. I will submit an 
alternative in a moment.


On 1/7/21 12:16 AM, Xin, Peixing wrote:


Hi ,

This patch is to recognize four-part configuration name for VxWorks. 
For example:


    armv7m-wrs-vxworks-eabihf

    armv7-wrs-vxworks-eabihf

    i686-wrs-vxworks-simlinux

    i686-wrs-vxworks-simwindows

    powerpc-wrs-vxworks-spe

    x86_64-wrs-vxworks-simlinux

    x86_64-wrs-vxworks-simwindows

    It's my check result on Ubuntu 18.04:

    $ make check

    cd testsuite && bash config-guess.sh && rm uname

    PASS: config.guess checks (131 tests)

    cd testsuite && bash config-sub.sh

    PASS: config.sub checks (846 tests)

    PASS: config.sub idempotency checks (783 tests)

    PASS: config.sub canonicalise each config.guess testcase (131 tests)

    * config.sub: Recognize four-part configuration name for VxWorks.

    * testsuite/config-sub.data: Add test cases.

Thanks,

Peixing

>From e5689c76d68d5b52a8aa9355c2e2633b1faf3072 Mon Sep 17 00:00:00 2001
From: Alan Modra 
Date: Thu, 7 Jan 2021 10:25:28 +1030
Subject: [PATCH] Recognize four-part configuration name for VxWorks.
For example:

  armv7m-wrs-vxworks-eabihf
  armv7-wrs-vxworks-eabihf
  i686-wrs-vxworks-simlinux
  i686-wrs-vxworks-simwindows
  powerpc-wrs-vxworks-spe
  x86_64-wrs-vxworks-simlinux
  x86_64-wrs-vxworks-simwindows

It's our check results (on Ubuntu 18.04 and NixOS 20.09):

  $ make check
  cd testsuite && bash config-guess.sh && rm uname
  PASS: config.guess checks (131 tests)
  cd testsuite && bash config-sub.sh
  PASS: config.sub checks (846 tests)
  PASS: config.sub idempotency checks (783 tests)
  PASS: config.sub canonicalise each config.guess testcase (131 tests)

* config.sub: Recognize four-part configuration name for VxWorks.
* testsuite/config-sub.data: Add test cases.

Co-authored-by: John Ericson 
---
 config.sub|  4 +++-
 testsuite/config-sub.data | 14 ++
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/config.sub b/config.sub
index b0f8492..caf34fb 100755
--- a/config.sub
+++ b/config.sub
@@ -1684,7 +1684,7 @@ fi
 # Now, validate our (potentially fixed-up) OS.
 case $os in
 	# Sometimes we do "kernel-abi", so those need to count as OSes.
-	musl* | newlib* | uclibc*)
+	musl* | newlib* | uclibc* | simlinux | simwindows | spe)
 		;;
 	# Likewise for "kernel-libc"
 	eabi* | gnueabi*)
@@ -1751,6 +1751,8 @@ case $kernel-$os in
 		;;
 	kfreebsd*-gnu* | kopensolaris*-gnu*)
 		;;
+	vxworks-simlinux | vxworks-simwindows | vxworks-spe)
+		;;
 	nto-qnx*)
 		;;
 	os2-emx)
diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
index 60cf4fd..1f72e4e 100644
--- a/testsuite/config-sub.data
+++ b/testsuite/config-sub.data
@@ -18,6 +18,7 @@ aarch64-genode	aarch64-unknown-genode
 aarch64-linux	aarch64-unknown-linux-gnu
 aarch64-unknown-elfaarch64-unknown-elf
 aarch64-unknown-linuxaarch64-unknown-linux-gnu
+aarch64-wrs-vxworksaarch64-wrs-vxworks
 aarch64_be	aarch64_be-unknown-none
 aarch64_be-bme	aarch64_be-unknown-bme
 aarch64_be-elf	aarch64_be-unknown-elf
@@ -97,6 +98,7 @@ armv7-apple-ios	armv7-apple-ios
 armv7-unknown-netbsdelf7.0			armv7-unknown-netbsdelf7.0
 armv7-unknown-netbsdelf7.0-eabi			armv7-unknown-netbsdelf7.0-eabi
 armv7-unknown-netbsdelf7.0-eabihf		armv7-unknown-netbsdelf7.0-eabihf
+armv7-wrs-vxworks-eabihf			armv7-wrs-vxworks-eabihf
 armv7a		armv7a-unknown-none
 armv7a-linux-gnueabiarmv7a-unknown-linux-gnueabi
 armv7eb-unknown-netbsdelf7.0			armv7eb-unknown-netbsdelf7.0
@@ -104,6 +106,7 @@ armv7eb-unknown-netbsdelf7.0-eabi		armv7eb-unknown-netbsdelf7.0-eabi
 armv7eb-unknown-netbsdelf7.0-eabihf		armv7eb-unknown-netbsdelf7.0-eabihf
 armv7m		armv7m-unknown-none
 armv7m-unknown-none-eabiarmv7m-unknown-none-eabi
+armv7m-wrs-vxworks-eabihfarmv7m-wrs-vxworks-eabihf
 armv7r		armv7r-unknown-none
 armv8a		armv8a-un

Re: config.sub patch: recognize four-part configuration name for VxWorks OS

[John Ericson]

I don't this this patch is right. You are adding another "ad hoc" case, 
but we should strive not to do that. I will submit an alternative in a 
moment.


On 1/7/21 12:16 AM, Xin, Peixing wrote:


Hi ,

This patch is to recognize four-part configuration name for VxWorks. 
For example:


    armv7m-wrs-vxworks-eabihf

    armv7-wrs-vxworks-eabihf

    i686-wrs-vxworks-simlinux

    i686-wrs-vxworks-simwindows

    powerpc-wrs-vxworks-spe

    x86_64-wrs-vxworks-simlinux

    x86_64-wrs-vxworks-simwindows

    It's my check result on Ubuntu 18.04:

    $ make check

    cd testsuite && bash config-guess.sh && rm uname

    PASS: config.guess checks (131 tests)

    cd testsuite && bash config-sub.sh

    PASS: config.sub checks (846 tests)

    PASS: config.sub idempotency checks (783 tests)

    PASS: config.sub canonicalise each config.guess testcase (131 tests)

    * config.sub: Recognize four-part configuration name for VxWorks.

    * testsuite/config-sub.data: Add test cases.

Thanks,

Peixing

Re: [PATCH] config.sub: Normalize arm64-* to aarch64-*

[John Ericson]

I'll second that this is a good idea; Apple's "aarm64" has caused much 
trouble and is wholly unnecessary as Keno says.


Also, If we apply this first, the previous email with the macOS aarch64 
config.guess support can be made more minimal.


On 7/9/20 2:02 AM, Keno Fischer wrote:

Apple tools use arm64-* in their triples to indicate an aarch64 CPU.
E.g. macOS 11.0 on aarch64 is `arm64-apple-darwin20.0.0`. That said,
these tools do accept the `aarch64-*` just fine as well (LLVM
normalizes internally). For config.sub, I think it makes sense to
normalize arm64-* to aarch64-*, since the latter is the established
way to refer to this architecture and likely what various configure
scripts, etc. are checking for. I tried this change on a few
autotools-based projects with `--build=arm64-apple-darwin` and
the builds seemed to go through well.
---
  ChangeLog | 4 
  config.sub| 3 +++
  testsuite/config-sub.data | 2 ++
  3 files changed, 9 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index c787ce9..f995b31 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2020-07-09  Keno Fischer  
+
+   * config.sub: Normalize arm64-* to aarch64-*
+
  2020-06-28  John Ericson  
  
  	* config.sub: Properly parse the KERNEL-OS case.

diff --git a/config.sub b/config.sub
index ce89d5c..0634942 100755
--- a/config.sub
+++ b/config.sub
@@ -1104,6 +1104,9 @@ case $cpu-$vendor in
xscale-* | xscalee[bl]-*)
cpu=`echo "$cpu" | sed 's/^xscale/arm/'`
;;
+   arm64-*)
+   cpu=aarch64
+   ;;
  
  	# Recognize the canonical CPU Types that limit and/or modify the

# company names they are paired with.
diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
index d9639bc..197fffc 100644
--- a/testsuite/config-sub.data
+++ b/testsuite/config-sub.data
@@ -103,6 +103,8 @@ armv8a  
armv8a-unknown-none
  armv8b-linux-gnueabi  armv8b-unknown-linux-gnueabi
  armv8marmv8m-unknown-none
  armv8rarmv8r-unknown-none
+arm64-apple-darwin20.0.0   aarch64-apple-darwin20.0.0
+arm64-apple-iosaarch64-apple-ios
  aros  i386-pc-aros
  asmjs asmjs-unknown-none
  asmjs-emscripten  asmjs-unknown-emscripten

Re: * config.sub: Properly parse the KERNEL-OS case.

[John Ericson]

Sorry! It is indeed incomprehensible---I must have been more tired than 
I thought.


Here is a new version with a ChangeLog entry that's hopefully actually 
understandable.


Thanks,

John

On 6/26/20 8:39 AM, Ben Elliston wrote:

John,


I guess I am getting back to the refactoring I was doing before for one last
round, so now finally no two components are ever conflated:

     * config.sub: Properly parse the KERNEL-OS case.

     I previous parsed basic_machine into separate `cpu` and `kernel`
     variables, I parse `basic_os` (a rename of `os` when used early on) into
     `kernel` and `os`.

     Like before, this does make thins a bit longer, but I think it makes the
     code understand and more robust, and so is worth the cost.

Can you please re-write the above? It makes no sense to me.

Thanks,
Ben
>From 8074863028ad652db6add94d4c26e86acb19092c Mon Sep 17 00:00:00 2001
From: John Ericson 
Date: Tue, 23 Jun 2020 18:01:06 -0400
Subject: [PATCH] 	* config.sub: Properly parse the KERNEL-OS case.

	I previously refactored the code to parse `basic_machine` into
	separate `cpu` and `vendor` variables. This is a kindred refactor
	where `basic_os` (a rename of `os` when used early on) is now
	parsed into into `kernel` and `os`.

	Like the previous refactor, this does make things a bit longer.
	But I think the change makes the code easier to understand and
	more robust, so it is worth the cost of the increased size.
---
 ChangeLog  |  13 ++
 config.sub | 517 +
 2 files changed, 293 insertions(+), 237 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index c8f6d72..fd28f11 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2020-06-27  John Ericson  
+
+	* config.sub: Properly parse the KERNEL-OS case.
+
+	I previously refactored the code to parse `basic_machine` into
+	separate `cpu` and `vendor` variables. This is a kindred refactor
+	where `basic_os` (a rename of `os` when used early on) is now
+	parsed into into `kernel` and `os`.
+
+	Like the previous refactor, this does make things a bit longer.
+	But I think the change makes the code easier to understand and
+	more robust, so it is worth the cost of the increased size.
+
 2020-06-26  John Ericson  
 
 	* config.sub: Move OS whitelist to the bottom of the case as
diff --git a/config.sub b/config.sub
index 186616a..62f65e0 100755
--- a/config.sub
+++ b/config.sub
@@ -124,28 +124,27 @@ case $1 in
 		;;
 	*-*-*-*)
 		basic_machine=$field1-$field2
-		os=$field3-$field4
+		basic_os=$field3-$field4
 		;;
 	*-*-*)
 		# Ambiguous whether COMPANY is present, or skipped and KERNEL-OS is two
 		# parts
 		maybe_os=$field2-$field3
 		case $maybe_os in
-			nto-qnx* | linux-gnu* | linux-android* | linux-dietlibc \
-			| linux-newlib* | linux-musl* | linux-uclibc* | uclinux-uclibc* \
+			nto-qnx* | linux-* | uclinux-uclibc* \
 			| uclinux-gnu* | kfreebsd*-gnu* | knetbsd*-gnu* | netbsd*-gnu* \
 			| netbsd*-eabi* | kopensolaris*-gnu* | cloudabi*-eabi* \
 			| storm-chaos* | os2-emx* | rtmk-nova*)
 basic_machine=$field1
-os=$maybe_os
+basic_os=$maybe_os
 ;;
 			android-linux)
 basic_machine=$field1-unknown
-os=linux-android
+basic_os=linux-android
 ;;
 			*)
 basic_machine=$field1-$field2
-os=$field3
+basic_os=$field3
 ;;
 		esac
 		;;
@@ -154,7 +153,7 @@ case $1 in
 		case $field1-$field2 in
 			decstation-3100)
 basic_machine=mips-dec
-os=
+basic_os=
 ;;
 			*-*)
 # Second component is usually, but not always the OS
@@ -162,7 +161,7 @@ case $1 in
 	# Prevent following clause from handling this valid os
 	sun*os*)
 		basic_machine=$field1
-		os=$field2
+		basic_os=$field2
 		;;
 	# Manufacturers
 	dec* | mips* | sequent* | encore* | pc533* | sgi* | sony* \
@@ -175,11 +174,11 @@ case $1 in
 	| microblaze* | sim | cisco \
 	| oki | wec | wrs | winbond)
 		basic_machine=$field1-$field2
-		os=
+		basic_os=
 		;;
 	*)
 		basic_machine=$field1
-		os=$field2
+		basic_os=$field2
 		;;
 esac
 			;;
@@ -191,451 +190,451 @@ case $1 in
 		case $field1 in
 			386bsd)
 basic_machine=i386-pc
-os=bsd
+basic_os=bsd
 ;;
 			a29khif)
 basic_machine=a29k-amd
-os=udi
+basic_os=udi
 ;;
 			adobe68k)
 basic_machine=m68010-adobe
-os=scout
+basic_os=scout
 ;;
 			alliant)
 basic_machine=fx80-alliant
-os=
+basic_os=
 ;;
 			altos | altos3068)
 basic_machine=m68k-altos
-os=
+basic_os=
 ;;
 			am29k)
 basic_machine=a29k-none
-os=bsd
+basic_os=bsd
 ;;
 			amdahl)
 basic_machine=580-amdahl
-os=sysv
+basic_os=sysv
 ;;
 			amiga)
 basic_machine=m68k-unknown
-os=
+basic_os=
 ;;
 			amigaos | amigados)
 basic_machine=m68k-unknown
-os=amigaos
+basic_os=amigaos
 ;;
 			amigaunix | amix)
 basic_machine=m68k-unknown
-os=sysv4
+basic_os=sy

Re: [PATCH] * config.sub (s390|s390x): Fix vendor output for s390/s390x.

[John Ericson]

Ah, sorry I didn't notice that. Here then is patch making the change 
which I requested, for your consideration.


Thanks,

John

On 6/26/20 8:19 AM, Ben Elliston wrote:

On Wed, Jun 24, 2020 at 10:56:08AM -0400, John Ericson wrote:


(disclaimer: I am not the official maintainer, just someone who put
a in a bunch of time reorganizing `config.sub`.)

I applied Alexander's patch last Sunday.

Ben
>From a0a90e796221c6dadc10de1af304a8e0b182bdf6 Mon Sep 17 00:00:00 2001
From: John Ericson 
Date: Sat, 27 Jun 2020 11:16:11 -0400
Subject: [PATCH 1/2] 	* config.sub: Allow CPU to influence vendor defaulting
 too.

---
 ChangeLog  |  4 
 config.sub | 46 +++---
 2 files changed, 27 insertions(+), 23 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index c8f6d72..0e33f9d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2020-06-27  John Ericson  
+
+	* config.sub: Allow CPU to influence vendor defaulting too.
+
 2020-06-26  John Ericson  
 
 	* config.sub: Move OS whitelist to the bottom of the case as
diff --git a/config.sub b/config.sub
index 186616a..304e71d 100755
--- a/config.sub
+++ b/config.sub
@@ -1720,71 +1720,71 @@ fi
 # manufacturer.  We pick the logical manufacturer.
 case $vendor in
 	unknown)
-		case $os in
-			riscix*)
+		case $cpu-$os in
+			*-riscix*)
 vendor=acorn
 ;;
-			sunos*)
+			*-sunos*)
 vendor=sun
 ;;
-			cnk*|-aix*)
+			*-cnk* | *-aix*)
 vendor=ibm
 ;;
-			beos*)
+			*-beos*)
 vendor=be
 ;;
-			hpux*)
+			*-hpux*)
 vendor=hp
 ;;
-			mpeix*)
+			*-mpeix*)
 vendor=hp
 ;;
-			hiux*)
+			*-hiux*)
 vendor=hitachi
 ;;
-			unos*)
+			*-unos*)
 vendor=crds
 ;;
-			dgux*)
+			*-dgux*)
 vendor=dg
 ;;
-			luna*)
+			*-luna*)
 vendor=omron
 ;;
-			genix*)
+			*-genix*)
 vendor=ns
 ;;
-			clix*)
+			*-clix*)
 vendor=intergraph
 ;;
-			mvs* | opened*)
+			*-mvs* | *-opened*)
 vendor=ibm
 ;;
-			os400*)
+			*-os400*)
 vendor=ibm
 ;;
-			ptx*)
+			*-ptx*)
 vendor=sequent
 ;;
-			tpf*)
+			*-tpf*)
 vendor=ibm
 ;;
-			vxsim* | vxworks* | windiss*)
+			*-vxsim* | *-vxworks* | *-windiss*)
 vendor=wrs
 ;;
-			aux*)
+			*-aux*)
 vendor=apple
 ;;
-			hms*)
+			*-hms*)
 vendor=hitachi
 ;;
-			mpw* | macos*)
+			*-mpw* | *-macos*)
 vendor=apple
 ;;
-			*mint | mint[0-9]* | *MiNT | MiNT[0-9]*)
+			*-*mint | *-mint[0-9]* | *-*MiNT | *-MiNT[0-9]*)
 vendor=atari
 ;;
-			vos*)
+			*-vos*)
 vendor=stratus
 ;;
 		esac
-- 
2.25.4

>From 7865fcc9131ba149f0518b88e3b03f6323851a32 Mon Sep 17 00:00:00 2001
From: John Ericson 
Date: Sat, 27 Jun 2020 12:14:10 -0400
Subject: [PATCH 2/2] 	* config.sub: Restore s390{,x} IBM defaulting

---
 ChangeLog | 15 +++
 config.sub|  3 +++
 testsuite/config-sub.data | 10 ++
 3 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 0e33f9d..ca18be2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,18 @@
+2020-06-27  John Ericson  
+
+	* config.sub: Restore s390{,x} IBM defaulting.
+
+	Previously, "ibm" was *forced*, which caused problems when someone wanted
+	to use "busybox" as a vendor and cross compile with a slightly different
+	toolchain. But the fix changed behavior such that without any vendor, it
+	would use to plain "unknown" rather than "IBM" was before.
+
+	This patch tries to compromise between the old and new behavior by making
+	"ibm" a *default* for those CPUs when no vendor is specified, but if the
+	user explicitly gives a vendor that is used instead. This sort of vendor
+	defaulting has plenty of precedent in config.sub, already, so it seemed
+	like a good appraoch.
+
 2020-06-27  John Ericson  
 
 	* config.sub: Allow CPU to influence vendor defaulting too.
diff --git a/config.sub b/config.sub
index 304e71d..6093b0b 100755
--- a/config.sub
+++ b/config.sub
@@ -1763,6 +1763,9 @@ case $vendor in
 			*-os400*)
 vendor=ibm
 ;;
+			s390-* | s390x-*)
+vendor=ibm
+;;
 			*-ptx*)
 vendor=sequent
 ;;
diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
index c4fe79d..d9639bc 100644
--- a/testsuite/config-sub.data
+++ b/testsuite/config-sub.data
@@ -581,10 +581,12 @@ rs6000		rs6000-ibm-aix
 rx-linux	rx-unknown-linux-gnu
 rx		rx-unknown-none
 s12z		s12z-unknown-none
-s390		s390-unknown-none
-s390x		s390x-unknown-none
-s390-linux	s390-unknown-linux-gnu
-s390x-linux	s390x-unknown-linux-gnu
+s390		s390-ibm-none
+s390x		s390x-ibm-none
+s390-linux	s390-ibm-linux-gnu
+s390x-linux	s390x-ibm-linux-gnu
+s390-busybox-linuxs390-busybox-linux-gnu
+s390x-busybox-linuxs390x-busybox-linux-gnu
 s390-ibm-zvmoe	s390-ibm-zvmoe
 s390x-ibm-zvmoe	s390x-ibm-zvmoe
 sa29200		a29k-amd-udi
-- 
2.25.4

Re: [PATCH] * config.sub (s390|s390x): Fix vendor output for s390/s390x.

[John Ericson]

Alexander,

(disclaimer: I am not the official maintainer, just someone who put a in 
a bunch of time reorganizing `config.sub`.)


If go to the bottom of config.sub, there is a section where the vendor 
is inferred for none was provided. I recommend adding the IBM logic 
there, so we go from forcing IBM to defaulting it, rather than forcing 
IBM to nothing at all.


John

On 6/20/20 7:30 AM, Alexander Egorenkov wrote:

Setting vendor always to 'ibm' causes problems with gcc
and glibc when building a cross-compiler on s390x host for
s390x target, e.g. in case of buildroot.

See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712

Signed-off-by: Alexander Egorenkov 
---
  config.sub | 11 ++-
  1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/config.sub b/config.sub
index 0820805..fcd21a1 100755
--- a/config.sub
+++ b/config.sub
@@ -2,7 +2,7 @@
  # Configuration validation subroutine script.
  #   Copyright 1992-2020 Free Software Foundation, Inc.
  
-timestamp='2020-06-18'

+timestamp='2020-06-20'
  
  # This file is free software; you can redistribute it and/or modify it

  # under the terms of the GNU General Public License as published by
@@ -1146,14 +1146,6 @@ case $cpu-$vendor in
cpu=mipsallegrexel
vendor=sony
;;
-   s390-*)
-   cpu=s390
-   vendor=ibm
-   ;;
-   s390x-*)
-   cpu=s390x
-   vendor=ibm
-   ;;
tile*-*)
os=${os:-linux-gnu}
;;
@@ -1237,6 +1229,7 @@ case $cpu-$vendor in
| pyramid \
| riscv | riscv32 | riscv64 \
| rl78 | romp | rs6000 | rx \
+   | s390 | s390x \
| score \
| sh | shl \
| sh[1234] | sh[24]a | sh[24]ae[lb] | sh[23]e | she[lb] 
| sh[lb]e \

* config.sub: Properly parse the KERNEL-OS case.

[John Ericson]

Hi Ben,

I guess I am getting back to the refactoring I was doing before for one 
last round, so now finally no two components are ever conflated:


    * config.sub: Properly parse the KERNEL-OS case.

    I previous parsed basic_machine into separate `cpu` and `kernel`
    variables, I parse `basic_os` (a rename of `os` when used early on) 
into

    `kernel` and `os`.

    Like before, this does make thins a bit longer, but I think it 
makes the

    code understand and more robust, and so is worth the cost.

    * config.sub: Move OS whitelist to bottom of case. This is in 
preparation

    for the following commit.

Hope it looks good to you.

Cheers,

John


>From 0acc28ec790029961d103b5bd77e90d721486d83 Mon Sep 17 00:00:00 2001
From: John Ericson 
Date: Tue, 23 Jun 2020 17:15:53 -0400
Subject: [PATCH 1/2] * config.sub: Move OS whitelist to bottom of
 case. This is in preparation 	for the following commit.

---
 ChangeLog  |  5 
 config.sub | 82 +-
 2 files changed, 49 insertions(+), 38 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index a6451d9..ddbebbe 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2020-06-23  John Ericson 
+
+	* config.sub: Move OS whitelist to bottom of case. This is in preparation
+	for the following commit.
+
 2020-06-21  Alexander Egorenkov  
 	Ben Elliston  
 
diff --git a/config.sub b/config.sub
index fcd21a1..186616a 100755
--- a/config.sub
+++ b/config.sub
@@ -1335,41 +1335,6 @@ case $os in
 	psos*)
 		os=psos
 		;;
-	# Now accept the basic system types.
-	# The portable systems comes first.
-	# Each alternative MUST end in a * to match a version number.
-	# sysv* is not here because it comes later, after sysvr4.
-	gnu* | bsd* | mach* | minix* | genix* | ultrix* | irix* \
-	 | *vms* | esix* | aix* | cnk* | sunos | sunos[34]*\
-	 | hpux* | unos* | osf* | luna* | dgux* | auroraux* | solaris* \
-	 | sym* | kopensolaris* | plan9* \
-	 | amigaos* | amigados* | msdos* | newsos* | unicos* | aof* \
-	 | aos* | aros* | cloudabi* | sortix* | twizzler* \
-	 | nindy* | vxsim* | vxworks* | ebmon* | hms* | mvs* \
-	 | clix* | riscos* | uniplus* | iris* | isc* | rtu* | xenix* \
-	 | knetbsd* | mirbsd* | netbsd* \
-	 | bitrig* | openbsd* | solidbsd* | libertybsd* | os108* \
-	 | ekkobsd* | kfreebsd* | freebsd* | riscix* | lynxos* \
-	 | bosx* | nextstep* | cxux* | aout* | elf* | oabi* \
-	 | ptx* | coff* | ecoff* | winnt* | domain* | vsta* \
-	 | udi* | eabi* | lites* | ieee* | go32* | aux* | hcos* \
-	 | chorusrdb* | cegcc* | glidix* \
-	 | cygwin* | msys* | pe* | moss* | proelf* | rtems* \
-	 | midipix* | mingw32* | mingw64* | linux-gnu* | linux-android* \
-	 | linux-newlib* | linux-musl* | linux-uclibc* \
-	 | uxpv* | beos* | mpeix* | udk* | moxiebox* \
-	 | interix* | uwin* | mks* | rhapsody* | darwin* \
-	 | openstep* | oskit* | conix* | pw32* | nonstopux* \
-	 | storm-chaos* | tops10* | tenex* | tops20* | its* \
-	 | os2* | vos* | palmos* | uclinux* | nucleus* \
-	 | morphos* | superux* | rtmk* | windiss* \
-	 | powermax* | dnix* | nx6 | nx7 | sei* | dragonfly* \
-	 | skyos* | haiku* | rdos* | toppers* | drops* | es* \
-	 | onefs* | tirtos* | phoenix* | fuchsia* | redox* | bme* \
-	 | midnightbsd* | amdhsa* | unleashed* | emscripten* | wasi* \
-	 | nsk* | powerunix* | genode*)
-	# Remember, each alternative MUST END IN *, to match a version number.
-		;;
 	qnx*)
 		case $cpu in
 		x86 | i*86)
@@ -1394,18 +1359,21 @@ case $os in
 	linux-dietlibc)
 		os=linux-dietlibc
 		;;
-	linux*)
-		os=`echo $os | sed -e 's|linux|linux-gnu|'`
-		;;
 	lynx*178)
 		os=lynxos178
 		;;
 	lynx*5)
 		os=lynxos5
 		;;
+	lynxos*)
+		# don't get caught up in next wildcard
+		;;
 	lynx*)
 		os=lynxos
 		;;
+	mach)
+		# don't get caught up in next wildcard
+		;;
 	mac*)
 		os=`echo "$os" | sed -e 's|mac|macos|'`
 		;;
@@ -1514,6 +1482,44 @@ case $os in
 		;;
 	*-eabi)
 		;;
+	# Now accept the basic system types.
+	# The portable systems comes first.
+	# Each alternative MUST end in a * to match a version number.
+	# sysv* is not here because it comes later, after sysvr4.
+	gnu* | bsd* | mach* | minix* | genix* | ultrix* | irix* \
+	 | *vms* | esix* | aix* | cnk* | sunos | sunos[34]*\
+	 | hpux* | unos* | osf* | luna* | dgux* | auroraux* | solaris* \
+	 | sym* | kopensolaris* | plan9* \
+	 | amigaos* | amigados* | msdos* | newsos* | unicos* | aof* \
+	 | aos* | aros* | cloudabi* | sortix* | twizzler* \
+	 | nindy* | vxsim* | vxworks* | ebmon* | hms* | mvs* \
+	 | clix* | riscos* | uniplus* | iris* | isc* | rtu* | xenix* \
+	 | knetbsd* | mirbsd* | netbsd* \
+	 | bitrig* | openbsd* | solidbsd* | libertybsd* | os108* \
+	 | ekkobsd* | kfreebsd* | freebsd* | riscix* | lynxos* \
+	 | bosx* | nextstep* | cxux* | aout* | elf* | oabi* \
+	 | ptx* | coff* | e

Re: More recognizing NetBSD CPUs (Super-H, MIPS 64bit)

[John Ericson]

Yes broken by me by chance sounds right. I recall there were two differing big sets of regexes I had to unify (with and without -*) in this case, and so it makes sense I messed it up. Sorry!John___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

Re: config.sub breaks configuration on Solaris 10

[John Ericson]

In GNU bash, -r, turns off special escape code handling. Configs don't have escape codes so it makes sense do this. Without that flag then, valid input stays valid, but some invalid input becomes valid too. So skipping that is unfortunate for GNU bash, but certainly makes sense for whatever odd shell you have.___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

Re: [PATCH] * config.sub: Deduplicate `basic_machine` by always allowing the vendor

[John Ericson]

On 08/20/18 02:54, Ben Elliston wrote:

I am still seeing Shellcheck problems and testsuite failures with the
2nd _and_ 3rd patches applied.  Please don't break the testsuite, even
temporarily.


Weird. I do see those problems not on my branch with `make shellcheck 
check-sub`. Here's fresh patches in case I didn't `git format-patch` the 
most recent version.


Cheers,
John
>From 6afaff4b3a5218c781b8f8d892276f11f02f51eb Mon Sep 17 00:00:00 2001
Message-Id: 
<6afaff4b3a5218c781b8f8d892276f11f02f51eb.1534748527.git.John.Ericson@Obsidian.Systems>
From: John Ericson 
Date: Tue, 14 Aug 2018 13:35:59 -0400
Subject: [PATCH 1/2] * config.sub: Move the big patterns to the bottom
To: config-patches@gnu.org

---
 ChangeLog  |   8 +
 config.sub | 422 +++--
 2 files changed, 220 insertions(+), 210 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 4fb5346..c654bb1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2018-08-20  John Ericson  
+
+   * config.sub: Move the big patterns to the bottom
+
+   This is done in preparation for deduplication. It causes shellcheck
+   to see more overlapping patterns, and breaks some tests. I need
+   somebody else to resolve the fallout and then I can procede.
+
 2018-08-20  John Ericson  
 
* testsuite/config-sub.data: Add legacy test cases.
diff --git a/config.sub b/config.sub
index 6e8fa65..7df77e0 100755
--- a/config.sub
+++ b/config.sub
@@ -699,222 +699,13 @@ case $basic_machine in
basic_machine=xps100-honeywell
;;
 
-   # Recognize the basic CPU types without company name.
-   # Some are omitted here because they have special meanings below.
-   1750a | 580 \
-   | a29k \
-   | aarch64 | aarch64_be \
-   | abacus \
-   | alpha | alphaev[4-8] | alphaev56 | alphaev6[78] | alphapca5[67] \
-   | alpha64 | alpha64ev[4-8] | alpha64ev56 | alpha64ev6[78] | 
alpha64pca5[67] \
-   | am33_2.0 \
-   | arc | arceb \
-   | arm | arm[bl]e | arme[lb] | armv[2-8] | armv[3-8][lb] | armv6m | 
armv[78][arm] \
-   | avr | avr32 \
-   | asmjs \
-   | ba \
-   | be32 | be64 \
-   | bfin \
-   | c4x | c8051 | clipper | csky \
-   | d10v | d30v | dlx | dsp16xx \
-   | e2k | epiphany \
-   | fido | fr30 | frv | ft32 \
-   | h8300 | h8500 | hppa | hppa1.[01] | hppa2.0 | hppa2.0[nw] | hppa64 \
-   | hexagon \
-   | i370 | i860 | i960 | ia16 | ia64 \
-   | ip2k | iq2000 \
-   | k1om \
-   | le32 | le64 \
-   | lm32 \
-   | m32c | m32r | m32rle | m68000 | m68k | m88k \
-   | m6811 | m68hc11 | m6812 | m68hc12 | m68hcs12x | nvptx | picochip \
-   | maxq | mb | microblaze | microblazeel | mcore | mep | metag \
-   | mips | mipsbe | mipseb | mipsel | mipsle \
-   | mips16 \
-   | mips64 | mips64el \
-   | mips64octeon | mips64octeonel \
-   | mips64orion | mips64orionel \
-   | mips64r5900 | mips64r5900el \
-   | mips64vr | mips64vrel \
-   | mips64vr4100 | mips64vr4100el \
-   | mips64vr4300 | mips64vr4300el \
-   | mips64vr5000 | mips64vr5000el \
-   | mips64vr5900 | mips64vr5900el \
-   | mipsisa32 | mipsisa32el \
-   | mipsisa32r2 | mipsisa32r2el \
-   | mipsisa32r6 | mipsisa32r6el \
-   | mipsisa64 | mipsisa64el \
-   | mipsisa64r2 | mipsisa64r2el \
-   | mipsisa64r6 | mipsisa64r6el \
-   | mipsisa64sb1 | mipsisa64sb1el \
-   | mipsisa64sr71k | mipsisa64sr71kel \
-   | mipsr5900 | mipsr5900el \
-   | mipstx39 | mipstx39el \
-   | mn10200 | mn10300 \
-   | moxie \
-   | mt \
-   | msp430 \
-   | nds32 | nds32le | nds32be \
-   | nfp \
-   | nios | nios2 | nios2eb | nios2el \
-   | ns16k | ns32k \
-   | open8 | or1k | or1knd | or32 \
-   | pdp10 | pj | pjl \
-   | powerpc | powerpc64 | powerpc64le | powerpcle \
-   | pru \
-   | pyramid \
-   | riscv | riscv32 | riscv64 \
-   | rl78 | rx \
-   | score \
-   | sh | sh[1234] | sh[24]a | sh[24]aeb | sh[23]e | sh[234]eb | sheb | 
shbe | shle | sh[1234]le | sh[23]ele \
-   | sh64 | sh64le \
-   | sparc | sparc64 | sparc64b | sparc64v | sparc86x | sparclet | 
sparclite \
-   | sparcv8 | sparcv9 | sparcv9b | sparcv9v \
-   | spu \
-   | tahoe | tic4x | tic54x | tic55x | tic6x | tic80 | tron \
-   | ubicom32 \
-   | v850 | v850e | v850e1 | v850e2 | v850es | v850e2v3 \
-   | visium \
-   | wasm32 \
-   | x86 | xc16x | xstormy16 | xgate | xtensa \
-   | z8k | z80)
-   basic_machine=$basic_machine-unknown
-   ;;
-   c54x)
-   basic_machine=tic54x-unknown
-   ;;
-   c55x)
-   basic_machine=tic55x-unknown
-   ;;
-   c6x)
-   basic_machine=tic6x-unknown
-   ;;
-   leon|leon[3-9])
-   basic_machine=sparc-$basi

Re: [PATCH] * config.sub: Deduplicate `basic_machine` by always allowing the vendor

[John Ericson]

Here are the last 3 patches, revised

Yes the * is probably just a cut and paste artifact. I suppose it is 
harmless and could hint to the human what the expected behavior, but for 
simplicity I just removed it. The crx- * test I deleted from the first 
patch too. That leaves the 1st patch working properly.


The 2nd patch is exactly as before. It still breaks things, but that is 
intentional, with the 3rd patch fixing the breakage and the crx test 
instead. I could have combined them, but I suspect they'll be easier to 
read separately so I kept them separate. If you want to apply them 
together that is fine with me.


Thanks,

John


On 08/20/18 00:34, Ben Elliston wrote:

On Tue, Aug 14, 2018 at 01:53:37PM -0400, John Ericson wrote:


Message-Id: 
<7aa195016503d03125cdcbaf0a53788322ea7dc6.1534269204.git.John.Ericson@Obsidian.Systems>
From: John Ericson 
Date: Tue, 14 Aug 2018 13:25:58 -0400
Subject: [PATCH 1/2] * testsuite/config-sub.data: Add legacy test cases
To: config-patches@gnu.org

This is a bit weird:


@@ -140,8 +142,13 @@ dec3100
mips-dec-ultrix4.2
  decstationmips-dec-ultrix4.2
  decstation-3100   mips-dec-ultrix4.2
  decstatn  mips-dec-ultrix4.2
+decsystem10*   pdp10-dec-tops10
+dec10* pdp10-dec-tops10
+decsystem20*   pdp10-dec-tops20
+dec20* pdp10-dec-tops20
  dicos i686-pc-dicos

Why are you adding test cases with asterisks in them?  Looks like too
much copying and pasting?

Also, the revised testsuite does not pass:

Invalid configuration `crx-unknown-elf': machine `crx-unknown' not recognized
FAIL: crx-unknown-elf -> , but crx-unknown-elf should map to itself

Please remove the failing tests until you submit a patch that fixes
the problem (and the test case can accompany that patch).

Thanks,
Ben


>From 8186ffa46fa80dc9bdfc9824225bdeb99bfa33b2 Mon Sep 17 00:00:00 2001
Message-Id: 
<8186ffa46fa80dc9bdfc9824225bdeb99bfa33b2.1534744813.git.John.Ericson@Obsidian.Systems>
From: John Ericson 
Date: Tue, 14 Aug 2018 13:25:58 -0400
Subject: [PATCH 1/3] * testsuite/config-sub.data: Add legacy test cases
To: config-patches@gnu.org

---
 ChangeLog |  4 
 testsuite/config-sub.data | 19 +++
 2 files changed, 23 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index b06386f..0703309 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2018-08-14  John Ericson  
+
+   * testsuite/config-sub.data: Add legacy test cases
+
 2018-08-14  John Ericson  
 
* config.sub (sequent): Make this a one-component alias.
diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
index 2c6771a..266175d 100644
--- a/testsuite/config-sub.data
+++ b/testsuite/config-sub.data
@@ -122,6 +122,7 @@ c6x-unknown-coff
tic6x-unknown-coff
 c6x-unknown-elftic6x-unknown-elf
 c8051  c8051-unknown-elf
 c8051-elf  c8051-unknown-elf
+c90c90-cray-unicos
 cegcc  arm-unknown-cegcc
 clipperclipper-unknown-none
 clipper-clix   clipper-intergraph-clix
@@ -140,8 +141,13 @@ dec3100
mips-dec-ultrix4.2
 decstation mips-dec-ultrix4.2
 decstation-3100mips-dec-ultrix4.2
 decstatn   mips-dec-ultrix4.2
+decsystem10pdp10-dec-tops10
+dec10  pdp10-dec-tops10
+decsystem20pdp10-dec-tops20
+dec20  pdp10-dec-tops20
 dicos  i686-pc-dicos
 djgpp  i586-pc-msdosdjgpp
+dpx2xxxm68k-bull-sysv3
 dlxdlx-unknown-none
 dsp16xxdsp16xx-unknown-none
 e2ke2k-unknown-none
@@ -151,6 +157,10 @@ e500v2-elf 
powerpc-unknown-elfspe
 e500v2-vxworksae   powerpc-wrs-vxworksaespe
 e500v2-wrs-linux   powerpc-wrs-linux-gnuspe
 e500v2-wrs-vxworks powerpc-wrs-vxworksspe
+elxsi  elxsi-elxsi-bsd
+encore ns32

Re: [PATCH] * config.sub: Deduplicate `basic_machine` by always allowing the vendor

[John Ericson]

On 08/14/18 13:53, John Ericson wrote:

I think I need you to resolve these problems as you see fit.

Here's a tentative resolution of those issues.
>From f8b614809cfabd6f98cfc02b7cf90bf2f68d30cf Mon Sep 17 00:00:00 2001
Message-Id: 

In-Reply-To: 

References: 
<7aa195016503d03125cdcbaf0a53788322ea7dc6.1534272803.git.John.Ericson@Obsidian.Systems>
    

From: John Ericson 
Date: Tue, 14 Aug 2018 14:52:46 -0400
Subject: [PATCH 3/3] Tenative fixes to issues arriving from previous commit
To: config-patches@gnu.org

---
 config.sub| 22 ++
 testsuite/config-sub.data | 13 +++--
 2 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/config.sub b/config.sub
index 7df77e0..562f38f 100755
--- a/config.sub
+++ b/config.sub
@@ -692,6 +692,9 @@ case $basic_machine in
mac | mpw | mac-mpw)
basic_machine=m68k-apple
;;
+   microblaze | microblazeel)
+   basic_machine=$basic_machine-xilinx
+   ;;
pmac | pmac-mpw)
basic_machine=powerpc-apple
;;
@@ -706,10 +709,6 @@ case $basic_machine in
  basic_machine=$basic_machine-pc
  ;;
 
-   # Recognize the basic CPU types without company name, with glob match.
-   xtensa*)
-   basic_machine=$basic_machine-unknown
-   ;;
# Recognize the various machine names and aliases which stand
# for a CPU type and a company and sometimes even an OS.
3b1 | 7300 | 7300-att | att-7300 | pc7300 | safari | unixpc)
@@ -755,6 +754,9 @@ case $basic_machine in
cris | cris-* | etrax*)
basic_machine=cris-axis
;;
+   crx-*)
+   os=${os:-elf}
+   ;;
crx)
basic_machine=crx-unknown
os=${os:-elf}
@@ -870,9 +872,6 @@ case $basic_machine in
basic_machine=m68k-`echo "$basic_machine" | sed 's/^[^-]*-//'`
os=linux
;;
-   microblaze*)
-   basic_machine=microblaze-xilinx
-   ;;
miniframe)
basic_machine=m68000-convergent
;;
@@ -1063,9 +1062,8 @@ case $basic_machine in
vpp*|vx|vx-*)
basic_machine=f301-fujitsu
;;
-   w65*)
+   w65)
basic_machine=w65-wdc
-   os=none
;;
w89k-*)
basic_machine=hppa1.1-winbond
@@ -1206,7 +1204,7 @@ case $basic_machine in
| lm32 \
| m32c | m32r | m32rle | m68000 | m68k | m88k \
| m6811 | m68hc11 | m6812 | m68hc12 | m68hcs12x | nvptx | picochip \
-   | maxq | mb | microblaze | microblazeel | mcore | mep | metag \
+   | maxq | mb | mcore | mep | metag \
| mips | mipsbe | mipseb | mipsel | mipsle \
| mips16 \
| mips64 | mips64el \
@@ -1254,7 +1252,7 @@ case $basic_machine in
| v850 | v850e | v850e1 | v850e2 | v850es | v850e2v3 \
| visium \
| wasm32 \
-   | x86 | xc16x | xstormy16 | xgate | xtensa \
+   | x86 | xc16x | xstormy16 | xgate | xtensa* \
| z8k | z80)
basic_machine=$basic_machine-unknown
;;
@@ -1270,7 +1268,7 @@ case $basic_machine in
leon|leon[3-9])
basic_machine=sparc-$basic_machine
;;
-   m88110 | m680[12346]0 | m683?2 | m68360 | m5200 | v70 | w65)
+   m88110 | m680[12346]0 | m683?2 | m68360 | m5200 | v70)
;;
m9s12z | m68hcs12z | hcs12z | s12z)
basic_machine=s12z-unknown
diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
index 8323a6b..5603920 100644
--- a/testsuite/config-sub.data
+++ b/testsuite/config-sub.data
@@ -285,12 +285,13 @@ mep-elf   
mep-unknown-elf
 mepmep-unknown-elf
 metag-linuxmetag-unknown-linux-gnu
 metag  metag-unknown-none
-microblazeel-elf   microblazeel-unknown-elf
-microblaze-elf microblaze-unknown-elf
-microblazeel-linux microblazeel-unknown-linux-gnu
-microblazeel   microblazeel-unknown-none
-microblaze-linux   microblaze-unknown-linux-gnu
-microblaze microblaze-unknown-none
+microblazeel-elf   microblazeel-xilinx-elf
+microblazeel-foobar-elfmicroblazeel-foobar-elf
+microblaze-elf microblaze-xilinx-elf
+microblazeel-linux microblazeel-xilinx-linux-gnu
+microblazeel   microblazeel-xilinx-none
+microblaze-linux   microbla

Re: [PATCH] * config.sub: Deduplicate `basic_machine` by always allowing the vendor

[John Ericson]

Oops, I just saw #3 was slightly bigger because I accidentally reverted 
a previous patch of mine. Here's it all pulled out.


On 08/13/18 20:15, Ben Elliston wrote:

I have applied patches 0001 and 0002, thanks. 0003 is quite large and
I want to spend some time examining it more closely.
Sound good. I might pull out more single component things, more 
aggressively now too as the canonicalization tests can keep us safer.

You know, a bit of awk or Perl would allow us to write out a list of
accepted patterns from which we could make the testsuite exhaustive.
Heh, well if only we had arrays of arrays, I'd put the 
patterns->normalization in as data, and then just source it to build the 
test cases. But yes, some automation would be nice. I think that would 
be easier after the refactors so I'll get cranking pulling out those 
single-component ones.


John
>From 22015b2837e53a9f310a0973adfca112884bcfe1 Mon Sep 17 00:00:00 2001
Message-Id: 
<22015b2837e53a9f310a0973adfca112884bcfe1.1534206979.git.John.Ericson@Obsidian.Systems>
From: John Ericson 
Date: Fri, 22 Jun 2018 17:40:14 -0400
Subject: [PATCH] * config.sub: Deduplicate `basic_machine` by filling in a
 stub vendor.
To: config-patches@gnu.org

---
 ChangeLog  |  24 ++
 config.sub | 212 ++---
 2 files changed, 78 insertions(+), 158 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b06386f..14dce34 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,27 @@
+2018-08-14  John Ericson  
+
+   * config.sub: Deduplicate `basic_machine` by filling in a stub vendor.
+
+   Instead of having both `foo` and `foo-*` as redundant patterns, we
+   always make sure basic_machine is initialized in the form `*-*` by
+   adding a trailing `-unknown` where needed.
+
+   There was one complication to doing this that should be noted. For
+   x86, the default is `-pc` instead of `-unknown`. That means we
+   can't just always append 1-component `basic_machine`s with
+   `-unknown` and assume 2-component everywhere.  Furthermore, an
+   explicitly passed `*-unknown` for x86 is not normalized by that
+   rule but instead left as-is. That means we cannot just append and
+   also conditionally replace `-unknown` with `-pc` as a final step,
+   either.
+
+   The solution is to continue duplicating the rules which would
+   output a `(i386|x86_64)-pc` so we can ensure the special case is
+   maintained, while defaulting to `-unknown` otherwise so the `*-*`
+   rules are sufficient. This isn't ideal, but at least most of the
+   `basic_machine` rules aren't implicated and can still be
+   deduplicated.
+
 2018-08-14  John Ericson  
 
* config.sub (sequent): Make this a one-component alias.
diff --git a/config.sub b/config.sub
index 6e8fa65..8264524 100755
--- a/config.sub
+++ b/config.sub
@@ -639,15 +639,45 @@ case $1 in
;;
 esac
 
+case $basic_machine in
+   *-*)
+   ;;
+   # We use `pc' rather than `unknown'
+   # because (1) that's what they normally are, and
+   # (2) the word "unknown" tends to confuse beginning users.
+   i*86 | x86_64)
+   basic_machine=$basic_machine-pc
+   ;;
+   # These rules are duplicated from below for sake of the special case 
above;
+   # i.e. things that normalized to x86 arches should also default to "pc"
+   pc98)
+   basic_machine=i386-pc
+   ;;
+   x64 | amd64)
+   basic_machine=x86_64-pc
+   ;;
+   # These are improper single component basic machines, as they should
+   # drop the vendor for just the CPU instead of the CPU for just the
+   # vendor as they in fact do. But they are tested to occur as part of
+   # multi-component configs, so we can't move them to the single
+   # component alises whitelist above.
+   sde)
+   basic_machine=mipsisa32-sde
+   os=${os:-elf}
+   ;;
+   *)
+   basic_machine=$basic_machine-unknown
+esac
+
 # Decode aliases for certain CPU-COMPANY combinations.
 case $basic_machine in
# Here we handle the default manufacturer of certain CPU types.  It is 
in
# some cases the only manufacturer, in others, it is the most popular.
-   craynv)
+   craynv-unknown)
basic_machine=craynv-cray
os=${os:-unicosmp}
;;
-   fx80)
+   fx80-unknown)
basic_machine=fx80-alliant
;;
w89k)
@@ -659,31 +689,31 @@ case $basic_machine in
op60c)
basic_machine=hppa1.1-oki
;;
-   romp)
+   romp-unknown)
basic_machine=romp-ibm
;;
-   mmix)
+   mmix-unknown)
basic_machine=mmix-knuth
;;
-   rs6000)
+   rs6000-unknown)

Re: [PATCH] * config.sub: Deduplicate `basic_machine` by always allowing the vendor

[John Ericson]

Good catch. Thank you for the tests. I fixed that, and another thing 
that was nagging me about sequent, so I think the next two patches pass 
muster fine.


That just leave the deduplicate one, and the dead code it induces. I 
like this two-step process of 1. bolster tests and 2. refactor. So if we 
can make tests to decide which of the remaining special 1-component 
patterns make sense as actual basic-machine rules, and which just makes 
sense as 1-component rules, I can then fix up the 3rd patch one final time.


Thanks again for your reviewing and testing,

John


On 08/13/18 00:52, Ben Elliston wrote:

On Mon, Aug 13, 2018 at 12:12:56AM -0400, John Ericson wrote:


Hmm bummer. Sorry about that. Here's them all again, with that and
another hopefully "non controversial" one moved to the front.

0001 and 0002 have been applied.

0003 fails to recognise decstation-3100, whereas it did before.

Ben


>From 8881955310c5f58a066d846a0d1890eb4b35e409 Mon Sep 17 00:00:00 2001
Message-Id: 
<8881955310c5f58a066d846a0d1890eb4b35e409.1534177617.git.John.Ericson@Obsidian.Systems>
From: John Ericson 
Date: Mon, 30 Jul 2018 13:08:12 -0400
Subject: [PATCH 1/3] * config.sub: Move some erroneous `foo-*` to be
 1-comp aliases
To: config-patches@gnu.org

---
 ChangeLog  | 30 +
 config.sub | 79 +++---
 2 files changed, 76 insertions(+), 33 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 366..125ca35 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,33 @@
+2018-08-08  John Ericson  
+
+   * config.sub: Move some erroneous `foo-*` to be 1-comp aliases
+
+   The `foo-*` versions were introduced in
+   5347fada50a3a3e689c2654515145457af92965e
+   1bf0fb0812846ace88f93937e90162e2835c6b11
+   ab3a1065d559246c2c0422513e04369f49639c62, and then right after
+   augmented with the `foo` versions in
+   1d62957bb23205508ea3eb7c790e431646fad6ae right after.
+
+   I think that commit didn't go far enough, in in that the original
+   `foo-*` verions should have also been removed:
+
+- "foo" is closer to a company name than arch name, so they are
+  in no way a proper 2-component basic name. That would mean
+  there's one companny name in the original `basic_machine`
+  that's ignored, and the other that is defaulted with some arch.
+  That seems arbitrary.
+
+- "foo-*" being radically normalized, but "foo" not being, is
+  just inconsistent.
+
+   In addition, I also move the rest to be single component aliases
+   as they are company names or product lines.
+
+   This is a breaking change, but not one I'd expect to matter since
+   all these machines are ancient and the tests still pass without
+   modification.
+
 2018-08-13  Ben Elliston  
 
* testsuite/config-sub.data: Add legacy test cases for cydra,
diff --git a/config.sub b/config.sub
index c19e671..be1d6cc 100755
--- a/config.sub
+++ b/config.sub
@@ -149,29 +149,39 @@ case $1 in
esac
;;
*-*)
-   # Second component is usually, but not always the OS
-   case $field2 in
-   # Prevent following clause from handling this valid os
-   sun*os*)
-   basic_machine=$field1
-   os=$field2
-   ;;
-   # Manufacturers
-   dec* | mips* | sequent* | encore* | pc532* | sgi* | 
sony* \
-   | att* | 7300* | 3300* | delta* | motorola* | sun[234]* 
\
-   | unicom* | ibm* | next | hp | isi* | apollo | altos* \
-   | convergent* | ncr* | news | 32* | 3600* | 3100* | 
hitachi* \
-   | c[123]* | convex* | sun | crds | omron* | dg | ultra 
| tti* \
-   | harris | dolphin | highlevel | gould | cbm | ns | 
masscomp \
-   | apple | axis | knuth | cray | microblaze* \
-   | sim | cisco | oki | wec | wrs | winbond)
-   basic_machine=$field1-$field2
+   # A lone config we happen to match not fitting any patern
+   case $field1-$field2 in
+   decstation-3100)
+   basic_machine=mips-dec
os=
;;
-   *)
-   basic_machine=$field1
-   os=$field2
-   ;;
+   *-*)
+   # Second component is usually, but not always 
the OS
+   case $field2 in
+   # Prevent following clause from 
handling this valid 

Re: [PATCH] * config.sub: Deduplicate `basic_machine` by always allowing the vendor

[John Ericson]

Hmm bummer. Sorry about that. Here's them all again, with that and 
another hopefully "non controversial" one moved to the front.


Cheers,

John


On 08/12/18 21:34, Ben Elliston wrote:

On Sun, Aug 12, 2018 at 09:01:37PM -0400, John Ericson wrote:


I'm rebasing and retesting them all now, but you could just skip
that and apply the next one (on craynv), which is simple and makes
config.sub strictly more accepting, in the meantime.

No, that doesn't apply cleanly either.

Ben


From 22af8b94e9b892db3a82bfd1fd9004ee846dfc7a Mon Sep 17 00:00:00 2001
Message-Id: 
<22af8b94e9b892db3a82bfd1fd9004ee846dfc7a.1534130227.git.John.Ericson@Obsidian.Systems>
From: John Ericson 
Date: Mon, 30 Jul 2018 13:00:25 -0400
Subject: [PATCH 1/5] * config.sub: Move back craynv as a `basic_machine`
 pattern * testsuite/config-sub.data: Add test for craynv
To: config-patches@gnu.org

---
 ChangeLog | 10 ++
 config.sub|  8 
 testsuite/config-sub.data |  1 +
 3 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index bce9d4b..770d4b1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2018-08-08  John Ericson  
+
+   * config.sub: Move back craynv as a `basic_machine` pattern
+   * testsuite/config-sub.data: Add test for craynv
+
+   This is in fact a valid archecture, even though it also contains
+   "cray" the company name, and thus may look like some shorthand.
+   Adding a test to make sure we accept it (tested via the
+   ideompotency check).
+
 2018-08-13  Ben Elliston  
 
* testsuite/config-sub.data: Add some legacy test cases.
diff --git a/config.sub b/config.sub
index c1b397a..e4226de 100755
--- a/config.sub
+++ b/config.sub
@@ -238,10 +238,6 @@ case $1 in
basic_machine=j90-cray
os=unicos
;;
-   craynv)
-   basic_machine=craynv-cray
-   os=unicosmp
-   ;;
delta88)
basic_machine=m88k-motorola
os=sysv3
@@ -566,6 +562,10 @@ esac
 case $basic_machine in
# Here we handle the default manufacturer of certain CPU types.  It is 
in
# some cases the only manufacturer, in others, it is the most popular.
+   craynv)
+   basic_machine=craynv-cray
+   os=${os:-unicosmp}
+   ;;
w89k)
basic_machine=hppa1.1-winbond
;;
diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
index aca8634..81472be 100644
--- a/testsuite/config-sub.data
+++ b/testsuite/config-sub.data
@@ -130,6 +130,7 @@ cr16-random-elf 
cr16-unknown-elf
 crds   m68k-crds-unos
 cris-linux cris-axis-linux-gnu
 crisv32-linux  crisv32-axis-linux-gnu
+craynv craynv-cray-unicosmp
 csky-linux csky-unknown-linux-gnu
 d10v   d10v-unknown-none
 d30v   d30v-unknown-none
-- 
2.17.1

From cc5dbc1a535d69c87ba70822a1442d3ebb99d6fc Mon Sep 17 00:00:00 2001
Message-Id: 

In-Reply-To: 
<22af8b94e9b892db3a82bfd1fd9004ee846dfc7a.1534130227.git.John.Ericson@Obsidian.Systems>
References: 
<22af8b94e9b892db3a82bfd1fd9004ee846dfc7a.1534130227.git.John.Ericson@Obsidian.Systems>
From: John Ericson 
Date: Thu, 9 Aug 2018 02:31:04 -0400
Subject: [PATCH 2/5] * config.sub: Combine match arms
To: config-patches@gnu.org

---
 ChangeLog  |  6 ++
 config.sub | 16 
 2 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 770d4b1..71fd90a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2018-08-08  John Ericson  
+
+   * config.sub: Combine match arms
+
+   These need no special handling.
+
 2018-08-08  John Ericson  
 
* config.sub: Move back craynv as a `basic_machine` pattern
diff --git a/config.sub b/config.sub
index e4226de..5795377 100755
--- a/config.sub
+++ b/config.sub
@@ -643,6 +643,7 @@ case $basic_machine in
| le32 | le64 \
| lm32 \
| m32c | m32r | m32rle | m68000 | m68k | m88k \
+   | m6811 | m68hc11 | m6812 | m68hc12 | m68hcs12x | nvptx | picochip \
| maxq | mb | microblaze | microblazeel | mcore | mep | metag \
| mips | mipsbe | mipseb | mipsel | mipsle \
| mips16 \
@@ -691,7 +692,7 @@ case $basic_machine in
| v850 | v850e | v850e1 | v850e2 | v850es | v850e2v3 \
| visium \
| wasm32 \
-   | x86 | xc16x | xstormy16 | xtensa \
+   | x86 | xc16x | xstormy16 | xgate | xtensa \
| z8

Re: [PATCH] * config.sub: Deduplicate `basic_machine` by always allowing the vendor

[John Ericson]

OK, now that the idempotency checks are in, here is a new version of the 
deduplication. I broke it up more, and added often-extensive notes on 
each step in the ChangeLog. All of them past the testsuite, but the last 
one (alone) make some basic_machine patterns not in the form 
`vendor-machine` as dead code. We should triage those cases before that 
patch is applied.


Cheers,
John
From 630d61c8e93b2ecbf88534c3dfce68668426d410 Mon Sep 17 00:00:00 2001
Message-Id: 
<630d61c8e93b2ecbf88534c3dfce68668426d410.1533797562.git.John.Ericson@Obsidian.Systems>
From: John Ericson 
Date: Mon, 30 Jul 2018 10:36:00 -0400
Subject: [PATCH 1/6] * config.sub: Move manufacture-defaultint patterns to
 the top
To: config-patches@gnu.org

---
 ChangeLog  |  10 ++
 config.sub | 103 +++--
 2 files changed, 62 insertions(+), 51 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index f79ad5f..e6bad15 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,13 @@
+2018-08-08  John Ericson  
+
+   * config.sub: Move manufacture-defaultint patterns to the top
+
+   Eventually the glob patterns should always go last. That way
+   previous patterns can refine them by being more specific. These
+   manufacture-defaulting patterns right now are in the form `foo`,
+   but would eventually be in the form `foo-unknown` so as to default
+   the vendor without overriding it more completely.
+
 2018-08-08  John Ericson  
 
* config.sub: Eliminate some dead code for SH targets.
diff --git a/config.sub b/config.sub
index 97d38aa..3a7b60c 100755
--- a/config.sub
+++ b/config.sub
@@ -564,6 +564,57 @@ esac
 
 # Decode aliases for certain CPU-COMPANY combinations.
 case $basic_machine in
+   # Here we handle the default manufacturer of certain CPU types.  It is 
in
+   # some cases the only manufacturer, in others, it is the most popular.
+   w89k)
+   basic_machine=hppa1.1-winbond
+   ;;
+   op50n)
+   basic_machine=hppa1.1-oki
+   ;;
+   op60c)
+   basic_machine=hppa1.1-oki
+   ;;
+   romp)
+   basic_machine=romp-ibm
+   ;;
+   mmix)
+   basic_machine=mmix-knuth
+   ;;
+   rs6000)
+   basic_machine=rs6000-ibm
+   ;;
+   vax)
+   basic_machine=vax-dec
+   ;;
+   pdp11)
+   basic_machine=pdp11-dec
+   ;;
+   we32k)
+   basic_machine=we32k-att
+   ;;
+   cydra)
+   basic_machine=cydra-cydrome
+   ;;
+   i370-ibm* | ibm*)
+   basic_machine=i370-ibm
+   ;;
+   orion)
+   basic_machine=orion-highlevel
+   ;;
+   orion105)
+   basic_machine=clipper-highlevel
+   ;;
+   mac | mpw | mac-mpw)
+   basic_machine=m68k-apple
+   ;;
+   pmac | pmac-mpw)
+   basic_machine=powerpc-apple
+   ;;
+   xps | xps100)
+   basic_machine=xps100-honeywell
+   ;;
+
# Recognize the basic CPU types without company name.
# Some are omitted here because they have special meanings below.
1750a | 580 \
@@ -718,7 +769,7 @@ case $basic_machine in
| h8300-* | h8500-* \
| hppa-* | hppa1.[01]-* | hppa2.0-* | hppa2.0[nw]-* | hppa64-* \
| hexagon-* \
-   | i*86-* | i860-* | i960-* | ia16-* | ia64-* \
+   | i370-* | i*86-* | i860-* | i960-* | ia16-* | ia64-* \
| ip2k-* | iq2000-* \
| k1om-* \
| le32-* | le64-* \
@@ -956,9 +1007,6 @@ case $basic_machine in
hp9k8[0-9][0-9] | hp8[0-9][0-9])
basic_machine=hppa1.0-hp
;;
-   i370-ibm* | ibm*)
-   basic_machine=i370-ibm
-   ;;
i*86v32)
basic_machine=`echo "$1" | sed -e 's/86.*/86-pc/'`
os=sysv32
@@ -1218,9 +1266,6 @@ case $basic_machine in
x64)
basic_machine=x86_64-pc
;;
-   xps | xps100)
-   basic_machine=xps100-honeywell
-   ;;
xscale-* | xscalee[bl]-*)
basic_machine=`echo "$basic_machine" | sed 's/^xscale/arm/'`
;;
@@ -1228,50 +1273,6 @@ case $basic_machine in
basic_machine=none-none
;;
 
-# Here we handle the default manufacturer of certain CPU types.  It is in
-# some cases the only manufacturer, in others, it is the most popular.
-   w89k)
-   basic_machine=hppa1.1-winbond
-   ;;
-   op50n)
-   basic_machine=hppa1.1-oki
-   ;;
-   op60c)
-   basic_machine=hppa1.1-oki
-   ;;
-   romp)
-   basic_machine=romp-ibm
-   ;;
-   mmix)
- 

Re: [PATCH] * config.sub: Remove some approximately sh* dead code

[John Ericson]

Sorry! I added it the the patterns above for consistency, and added a 
test so I won't forget this case in the future :).



On 08/07/18 22:06, Ben Elliston wrote:

On Wed, Aug 01, 2018 at 11:39:11PM -0400, John Ericson wrote:


+2018-08-01  John Ericson  
+
+   * config.sub: Remove some approximately sh* dead code
+
+Evidentally this has been dead since its original incarnation in
+cedea588f577fdf78ff4645543907ee6f7babae5.

Approximately is correct. ;-) You can't delete the sh[23]ele cases
here without covering them somewhere else.

Cheers, Ben


>From f03da559e3ac2cf9eba3b297c7fcc6850b3fc31c Mon Sep 17 00:00:00 2001
Message-Id: 

From: John Ericson 
Date: Fri, 3 Aug 2018 15:58:00 -0400
Subject: [PATCH]* config.sub: Remove some approximately sh* dead code
To: config-patches@gnu.org

Evidentally this has been dead since its original incarnation in
cedea588f577fdf78ff4645543907ee6f7babae5.
---
 ChangeLog | 7 +++
 config.sub| 7 ++-
 testsuite/config-sub.data | 2 ++
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 2d68917..80b41d1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2018-08-01  John Ericson  
+
+   * config.sub: Remove some approximately sh* dead code
+
+Evidentally this has been dead since its original incarnation in
+cedea588f577fdf78ff4645543907ee6f7babae5.
+
 2018-08-08  John Ericson  
 
* config.sub (tile*): Only set 'os' to -linux-gnu if unset.
diff --git a/config.sub b/config.sub
index 27d..97d38aa 100755
--- a/config.sub
+++ b/config.sub
@@ -630,7 +630,7 @@ case $basic_machine in
| riscv | riscv32 | riscv64 \
| rl78 | rx \
| score \
-   | sh | sh[1234] | sh[24]a | sh[24]aeb | sh[23]e | sh[234]eb | sheb | 
shbe | shle | sh[1234]le | sh3ele \
+   | sh | sh[1234] | sh[24]a | sh[24]aeb | sh[23]e | sh[234]eb | sheb | 
shbe | shle | sh[1234]le | sh[23]ele \
| sh64 | sh64le \
| sparc | sparc64 | sparc64b | sparc64v | sparc86x | sparclet | 
sparclite \
| sparcv8 | sparcv9 | sparcv9b | sparcv9v \
@@ -769,7 +769,7 @@ case $basic_machine in
| rl78-* | romp-* | rs6000-* | rx-* \
| score-* \
| sh-* | sh[1234]-* | sh[24]a-* | sh[24]ae[lb]-* | sh[23]e-* | 
she[lb]-* | sh[lb]e-* \
-   | sh[1234]e[lb]-* |  sh[12345][lb]e-* | sh3ele-* | sh64-* | sh64le-* \
+   | sh[1234]e[lb]-* |  sh[12345][lb]e-* | sh[23]ele-* | sh64-* | sh64le-* 
\
| sparc-* | sparc64-* | sparc64b-* | sparc64v-* | sparc86x-* | 
sparclet-* \
| sparclite-* \
| sparcv8-* | sparcv9-* | sparcv9b-* | sparcv9v-* | sv1-* | sx*-* \
@@ -1257,9 +1257,6 @@ case $basic_machine in
we32k)
basic_machine=we32k-att
;;
-   sh[1234] | sh[24]a | sh[24]aeb | sh[34]eb | sh[1234]le | sh[23]ele)
-   basic_machine=sh-unknown
-   ;;
cydra)
basic_machine=cydra-cydrome
;;
diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
index 96d805b..1491c40 100644
--- a/testsuite/config-sub.data
+++ b/testsuite/config-sub.data
@@ -454,6 +454,8 @@ sh2le   
sh2le-unknown-none
 sh2sh2-unknown-none
 sh3eb-elf  sh3eb-unknown-elf
 sh3e-elf   sh3e-unknown-elf
+sh2ele-elf sh2ele-unknown-elf
+sh2ele sh2ele-unknown-none
 sh3ele-elf sh3ele-unknown-elf
 sh3ele sh3ele-unknown-none
 sh3-elfsh3-unknown-elf
-- 
2.17.1

___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

Re: [PATCH] config.sub is not idempotent

[John Ericson]

Oh OK. Here is another version of the 3rd patch.

Firstly, I realized my own other mistake:  I had improperly limited the 
*-* patterns in a few case when fixing shellcheck errors. Existing globs 
shouldn't be restricted. [I had been narrowly extending the "special 
case" rules below to just additionally match normalized things and 
nothing more, and then "solved" some shellcheck errors the wrong way.]


The intent with the 3rd patch is: if "food" is accepted then "foo-*" 
should also be. If we allow skipping the vendor we should also allow it 
to be provided, even if this isn't excised by the new canonicalization 
tests.


Secondly, fixed the testsuite to match that. That seems simpler, actually.

John

On 07/30/18 01:57, Ben Elliston wrote:
There are now two separate tests for config.sub. I would like the test 
results tracked separately.


Perhaps it is time to switch to a Dejagnu test harness. 

Ben
From 548e5b3d8e44f7d92bc89ab89c160bd84a94b2bc Mon Sep 17 00:00:00 2001
Message-Id: 
<548e5b3d8e44f7d92bc89ab89c160bd84a94b2bc.1532930564.git.John.Ericson@Obsidian.Systems>
In-Reply-To: 
<9051a145bff67a2a8da7b666a95106c78fb4bc5c.1532930564.git.John.Ericson@Obsidian.Systems>
References: 
<5a1abdc6448184ae853dec84bb22f97237588e21.1532930564.git.John.Ericson@Obsidian.Systems>

<9051a145bff67a2a8da7b666a95106c78fb4bc5c.1532930564.git.John.Ericson@Obsidian.Systems>
From: John Ericson 
Date: Sun, 29 Jul 2018 22:18:29 -0400
Subject: [PATCH 3/3] * config.sub: Make idemopotent *
 testsuite/config-sub.sh: Add ideompotency tests
To: config-patches@gnu.org

---
 ChangeLog   |  5 
 config.sub  | 57 +++--
 testsuite/config-sub.sh | 41 -
 3 files changed, 77 insertions(+), 26 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 1db8ff9..c239b50 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2018-07-30  John Ericson  
+
+   * config.sub: Make idemopotent
+   * testsuite/config-sub.sh: Add ideompotency tests
+
 2018-07-30  John Ericson  
 
* testsuite/config-*.sh: Use `local rc` for better scoping
diff --git a/config.sub b/config.sub
index 52eb02e..893b60b 100755
--- a/config.sub
+++ b/config.sub
@@ -569,12 +569,14 @@ case $basic_machine in
1750a | 580 \
| a29k \
| aarch64 | aarch64_be \
+   | abacus \
| alpha | alphaev[4-8] | alphaev56 | alphaev6[78] | alphapca5[67] \
| alpha64 | alpha64ev[4-8] | alpha64ev56 | alpha64ev6[78] | 
alpha64pca5[67] \
| am33_2.0 \
| arc | arceb \
| arm | arm[bl]e | arme[lb] | armv[2-8] | armv[3-8][lb] | armv6m | 
armv[78][arm] \
| avr | avr32 \
+   | asmjs \
| ba \
| be32 | be64 \
| bfin \
@@ -654,6 +656,9 @@ case $basic_machine in
leon|leon[3-9])
basic_machine=sparc-$basic_machine
;;
+   m6811-* | m68hc11-* | m6812-* | m68hc12-* | m68hcs12x-* | nvptx-* | 
picochip-*)
+   os=${os:-none}
+   ;;
m6811 | m68hc11 | m6812 | m68hc12 | m68hcs12x | nvptx | picochip)
basic_machine=$basic_machine-unknown
os=${os:-none}
@@ -664,6 +669,10 @@ case $basic_machine in
basic_machine=s12z-unknown
os=${os:-none}
;;
+   m9s12z-* | m68hcs12z-* | hcs12z-* | s12z-*)
+   basic_machine=s12z-`echo "$basic_machine" | sed 's/^[^-]*-//'`
+   os=${os:-none}
+   ;;
ms1)
basic_machine=mt-unknown
;;
@@ -674,6 +683,9 @@ case $basic_machine in
basic_machine=$basic_machine-unknown
os=${os:-none}
;;
+   xgate-*)
+   os=${os:-none}
+   ;;
xscaleeb)
basic_machine=armeb-unknown
;;
@@ -689,22 +701,26 @@ case $basic_machine in
  basic_machine=$basic_machine-pc
  ;;
# Recognize the basic CPU types with company name.
-   580-* \
+   1750a-* | 580-* \
| a29k-* \
| aarch64-* | aarch64_be-* \
+   | abacus-* \
| alpha-* | alphaev[4-8]-* | alphaev56-* | alphaev6[78]-* \
| alpha64-* | alpha64ev[4-8]-* | alpha64ev56-* | alpha64ev6[78]-* \
-   | alphapca5[67]-* | alpha64pca5[67]-* | arc-* | arceb-* \
-   | arm-*  | armbe-* | armle-* | armeb-* | armv*-* \
+   | alphapca5[67]-* | alpha64pca5[67]-* \
+   | am33_2.0-* \
+   | arc-* | arceb-* \
+   | arm-*  | arm[lb]e-* | arme[lb]-* | armv*-* \
| avr-* | avr32-* \
+   | asmjs-* \
| ba-* \
| be32-* | be64-* \
| bfin-* | bs2000-* \
| c[123]* | c30-* | [cjt]90-* | c4x-* \
| c8051-* | clipper-* | craynv-* | csky-* | cydra-* \
-   | d10v-* | d30v-* | dlx-* \
-   | e2k-* | elxsi-* \
-   | f30[0

Re: [PATCH] config.sub is not idempotent

[John Ericson]

I made it print either "PASS...\nPASS..." for both successful, or 
nothing otherwise, which was my best guess for what you meant. I also 
added 2 more cleanups of the testsuite go in 2 prior commits.


Cheers,

John

On 07/29/18 21:03, John Ericson wrote:
I'll get to this is a few hours. What do you want it to say if the 
checks succeed and idempotency checks fail, or vice versa? (Maybe 
there should be a 3rd line for overall success?)


John


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches


From 5a1abdc6448184ae853dec84bb22f97237588e21 Mon Sep 17 00:00:00 2001
Message-Id: 
<5a1abdc6448184ae853dec84bb22f97237588e21.1532923899.git.John.Ericson@Obsidian.Systems>
From: John Ericson 
Date: Sun, 29 Jul 2018 22:12:56 -0400
Subject: [PATCH 1/3] * testsuite/config-*.sh: Reindent with tabs
To: config-patches@gnu.org

---
 ChangeLog |  4 +++
 testsuite/config-guess.sh | 54 +++
 testsuite/config-sub.sh   | 28 ++--
 3 files changed, 45 insertions(+), 41 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index f606e2d..1acd48d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2018-07-30  John Ericson  
+
+   * testsuite/config-*.sh: Reindent with tabs
+
 2018-07-30  Ben Elliston  
 
* Makefile (check-guess, check-sub): Run tests under bash.
diff --git a/testsuite/config-guess.sh b/testsuite/config-guess.sh
index d59d28e..0648c81 100644
--- a/testsuite/config-guess.sh
+++ b/testsuite/config-guess.sh
@@ -13,14 +13,14 @@ PATH=$(pwd):$PATH
 
 run_config_guess()
 {
-rc=0
-while IFS='|' read -r machine release system version processor triplet ; do
-   sed \
-   -e "s,@MACHINE@,$machine," \
-   -e "s,@RELEASE@,$release," \
-   -e "s,@SYSTEM@,$system," \
-   -e "s,@VERSION@,$version," \
-   -e "s,@PROCESSOR@,$processor," > uname << EOF
+   rc=0
+   while IFS='|' read -r machine release system version processor triplet 
; do
+   sed \
+   -e "s,@MACHINE@,$machine," \
+   -e "s,@RELEASE@,$release," \
+   -e "s,@SYSTEM@,$system," \
+   -e "s,@VERSION@,$version," \
+   -e "s,@PROCESSOR@,$processor," > uname << EOF
 #!/bin/sh
 [ \$# -ne 1 ] && exec sh \$0 -s
 [ \$1 = -m ] && echo "@MACHINE@" && exit 0
@@ -29,29 +29,29 @@ run_config_guess()
 [ \$1 = -v ] && echo "@VERSION@" && exit 0
 [ \$1 = -p ] && echo "@PROCESSOR@" && exit 0
 EOF
-   chmod +x uname
-   output=$(sh -eu ../config.guess 2>/dev/null)
-   if test $? != 0 ; then
-   echo "FAIL: unable to guess $machine:$release:$system:$version"
-   rc=1
-   continue
-   fi
-   if test "$output" != "$triplet" ; then
-   echo "FAIL: $output (expected $triplet)"
-   rc=1
-   continue
-   fi
-   $verbose && echo "PASS: $triplet"
-done
-return $rc
+   chmod +x uname
+   output=$(sh -eu ../config.guess 2>/dev/null)
+   if test $? != 0 ; then
+   echo "FAIL: unable to guess 
$machine:$release:$system:$version"
+   rc=1
+   continue
+   fi
+   if test "$output" != "$triplet" ; then
+   echo "FAIL: $output (expected $triplet)"
+   rc=1
+   continue
+   fi
+   $verbose && echo "PASS: $triplet"
+   done
+   return $rc
 }
 
 if sed 's, | ,|,g' < config-guess.data | run_config_guess ; then
-  numtests=$(wc -l config-guess.data | cut -d' ' -f1)
-  $verbose || echo "PASS: config.guess checks ($numtests tests)"
+   numtests=$(wc -l config-guess.data | cut -d' ' -f1)
+   $verbose || echo "PASS: config.guess checks ($numtests tests)"
 else
-  echo "Unexpected failures."
-  exit 1
+   echo "Unexpected failures."
+   exit 1
 fi
 
 exit 0
diff --git a/testsuite/config-sub.sh b/testsuite/config-sub.sh
index c5b09f6..0b1d232 100644
--- a/testsuite/config-sub.sh
+++ b/testsuite/config-sub.sh
@@ -13,24 +13,24 @@ verbose=false
 
 run_config_sub()
 {
-rc=0
-while read -r alias canonical ; do
-   output=$(sh -eu ../config.sub "$alias")
-   if test "$output" != "$canonical" ; then
-   echo "FAIL: $alias -> $output, but expected $canonical"
-   rc=1
-   else
-   $verbose &am

Re: [PATCH] config.sub is not idempotent

[John Ericson]

I'll get to this is a few hours. What do you want it to say if the checks succeed and idempotency checks fail, or vice versa? (Maybe there should be a 3rd line for overall success?)John___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

Re: [PATCH] config.sub is not idempotent

[John Ericson]

Glad you like it! Just let me know if there's any way I can assist with 
the improvements.


Cheers,

John


On 07/26/18 19:49, Ben Elliston wrote:

On Tue, Jul 24, 2018 at 11:57:27PM -0400, John Ericson wrote:


A canonical form is defined as one that maps to itself. I decided to
check whether the config.sub test suite's canonical configurations
actually did, and many of them did not, or weren't even accepted at
all!

This is a good patch, thanks. I have a few things that I would like to
improve in the test case, but nothing major.

Cheers,
Ben



___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

[PATCH] config.sub is not idempotent

[John Ericson]

A canonical form is defined as one that maps to itself. I decided to 
check whether the config.sub test suite's canonical configurations 
actually did, and many of them did not, or weren't even accepted at all!


I checked this by extending the test suite with a new function, which is 
the most important part of this patch. I also hurriedly fixed config.sub 
so that it passed the improved testsuite. Those fixes however should be 
checked over as I wasn't always sure on the best way to fix things (e.g. 
what vendors to allow)


Ben, you might notice that many of these fixes overlap with my 
deduplication patch. That is because the duplication necessary 
frequently is forgotten, leading to bugs. I point this out to show how 
deduplication is not only a good idea for cleanliness, but also for 
correctness. Let's try to land this (with improve fixed) before that, 
however, as I'll be able to redo the deduplication patch with higher 
quality way once this is dealt with.


Thanks,

John
From f9f647479997cdb1fd96f0e9c39e6c2e24943151 Mon Sep 17 00:00:00 2001
Message-Id: 

From: John Ericson 
Date: Tue, 24 Jul 2018 23:18:35 -0400
Subject: [PATCH] * config.sub: Make idemopotent *
 testsuite/config-sub.sh: Add ideompotency tests
To: config-patches@gnu.org

---
 ChangeLog   |  5 
 config.sub  | 65 -
 testsuite/config-sub.sh | 20 -
 3 files changed, 62 insertions(+), 28 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index d90aa1e..a96c520 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2018-07-25  John Ericson  
+
+   * config.sub: Make idemopotent
+   * testsuite/config-sub.sh: Add ideompotency tests
+
 2018-07-25  John Ericson  
 
* config.sub: Fix some more i386-pc-* defaults.
diff --git a/config.sub b/config.sub
index 52eb02e..7300b4f 100755
--- a/config.sub
+++ b/config.sub
@@ -569,12 +569,14 @@ case $basic_machine in
1750a | 580 \
| a29k \
| aarch64 | aarch64_be \
+   | abacus \
| alpha | alphaev[4-8] | alphaev56 | alphaev6[78] | alphapca5[67] \
| alpha64 | alpha64ev[4-8] | alpha64ev56 | alpha64ev6[78] | 
alpha64pca5[67] \
| am33_2.0 \
| arc | arceb \
| arm | arm[bl]e | arme[lb] | armv[2-8] | armv[3-8][lb] | armv6m | 
armv[78][arm] \
| avr | avr32 \
+   | asmjs \
| ba \
| be32 | be64 \
| bfin \
@@ -654,13 +656,16 @@ case $basic_machine in
leon|leon[3-9])
basic_machine=sparc-$basic_machine
;;
+   m6811-* | m68hc11-* | m6812-* | m68hc12-* | m68hcs12x-* | nvptx-* | 
picochip-*)
+   os=${os:-none}
+   ;;
m6811 | m68hc11 | m6812 | m68hc12 | m68hcs12x | nvptx | picochip)
basic_machine=$basic_machine-unknown
os=${os:-none}
;;
m88110 | m680[12346]0 | m683?2 | m68360 | m5200 | v70 | w65)
;;
-   m9s12z | m68hcs12z | hcs12z | s12z)
+   m9s12z | m68hcs12z | hcs12z | s12z | s12z-*)
basic_machine=s12z-unknown
os=${os:-none}
;;
@@ -670,7 +675,10 @@ case $basic_machine in
strongarm | thumb | xscale)
basic_machine=arm-unknown
;;
-   xgate)
+   xgate-*)
+   os=${os:-none}
+   ;;
+   xgate | xgate-*)
basic_machine=$basic_machine-unknown
os=${os:-none}
;;
@@ -689,22 +697,26 @@ case $basic_machine in
  basic_machine=$basic_machine-pc
  ;;
# Recognize the basic CPU types with company name.
-   580-* \
+   1750a-* | 580-* \
| a29k-* \
| aarch64-* | aarch64_be-* \
+   | abacus-* \
| alpha-* | alphaev[4-8]-* | alphaev56-* | alphaev6[78]-* \
| alpha64-* | alpha64ev[4-8]-* | alpha64ev56-* | alpha64ev6[78]-* \
-   | alphapca5[67]-* | alpha64pca5[67]-* | arc-* | arceb-* \
-   | arm-*  | armbe-* | armle-* | armeb-* | armv*-* \
+   | alphapca5[67]-* | alpha64pca5[67]-* \
+   | am33_2.0-* \
+   | arc-* | arceb-* \
+   | arm-*  | arm[lb]e-* | arme[lb]-* | armv*-* \
| avr-* | avr32-* \
+   | asmjs-* \
| ba-* \
| be32-* | be64-* \
| bfin-* | bs2000-* \
| c[123]* | c30-* | [cjt]90-* | c4x-* \
| c8051-* | clipper-* | craynv-* | csky-* | cydra-* \
-   | d10v-* | d30v-* | dlx-* \
-   | e2k-* | elxsi-* \
-   | f30[01]-* | f700-* | fido-* | fr30-* | frv-* | fx80-* \
+   | d10v-* | d30v-* | dlx-* | dsp16xx-* \
+   | e2k-* | elxsi-* | epiphany-* \
+   | f30[01]-* | f700-* | fido-* | fr30-* | frv-* | ft32-* \
| h8300-* | h8500-* \
| hppa-* | hppa1.[01]-* | hppa2.0-* | hppa2.0[nw]-* | hppa64-* \
| hexagon-* \
@@ -714,8 +726,8 @@ case $basic_machine in
| le32-* | le64-* \
| lm32-* \
| m32c-* | m32r-* | m32rle

[PATCH] * config.sub: Deduplicate `basic_machine` by always allowing the vendor

[John Ericson]

Instead of having both `foo` and `foo-*` as redundant patterns, we
always make sure basic_machine is initialized in the form `*-*` by
adding a trailing `-unknown` where needed.

There were two complications to doing this however, but they were worked
around:

The first is that for some reason `basic_machine`s in the form
`*-unknown` are always accepted, dating back to
3836f7b0c4f252e56aa1124a9b235ba62c2a45da. It is important that we don't
allow the inferred `-unknown` to allow nonsense one-component basic
machines to pass for the first time.

The second is that for x86, the default is `-pc` instead of `-unknown`.
That said, an explicitly passed `-unknown` is not normalized by that
rule and left as-is. Two tests were nevertheless changed but:

-vsta   i386-unknown-vsta
+vsta   i386-pc-vsta

Seems like fixing a blatant inconsistency, while:

-x86_64-ptx x86_64-pc-ptx
+x86_64-ptx x86_64-sequent-ptx

Fixes a small regression I previously introduced.

The solution in both cases is to distinguish explicit user given from
inferred/defaulted `-unknown`s, and use that to implement the existing
behavior. For this purpose, the `vendor_inferred` variable was added.

For what it's worth, I personally feel we should consider ripping that
distinction if it's OK. But I also feel that if we do chose to do that,
the change belongs in a separate revision, so this patch is the right
first step either way.

John
---
 ChangeLog |   4 +
 config.sub| 320 +-
 testsuite/config-sub.data |   4 +-
 3 files changed, 123 insertions(+), 205 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 372559c..8586152 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2018-06-22  John Ericson  
+
+   * config.sub: Deduplicate `basic_machine` by always allowing the vendor
+
 2018-05-24  Ben Elliston  
 
* testsuite/config-sub.data: Add tests for Sequent and DYNIX/ptx.
diff --git a/config.sub b/config.sub
index d1f5b54..8b6e358 100755
--- a/config.sub
+++ b/config.sub
@@ -2,7 +2,7 @@
 # Configuration validation subroutine script.
 #   Copyright 1992-2018 Free Software Foundation, Inc.
 
-timestamp='2018-05-24'
+timestamp='2018-06-22'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -124,6 +124,7 @@ case $1 in
*-*-*-*)
basic_machine=$field1-$field2
os=$field3-$field4
+   vendor_inferred=
;;
*-*-*)
# Ambiguous whether COMPANY is present, or skipped and 
KERNEL-OS is two
@@ -135,16 +136,19 @@ case $1 in
| uclinux-gnu* | kfreebsd*-gnu* | knetbsd*-gnu* | 
netbsd*-gnu* \
| netbsd*-eabi* | kopensolaris*-gnu* | cloudabi*-eabi* \
| storm-chaos* | os2-emx* | rtmk-nova*)
-   basic_machine=$field1
+   basic_machine=$field1-unknown
os=$maybe_os
+   vendor_inferred=1
;;
android-linux)
basic_machine=$field1-unknown
os=linux-android
+   vendor_inferred=
;;
*)
basic_machine=$field1-$field2
os=$field3
+   vendor_inferred=
;;
esac
;;
@@ -153,8 +157,9 @@ case $1 in
case $field2 in
# Prevent following clause from handling this valid os
sun*os*)
-   basic_machine=$field1
+   basic_machine=$field1-unknown
os=$field2
+   vendor_inferred=1
;;
# Manufacturers
dec* | mips* | sequent* | encore* | pc532* | sgi* | 
sony* \
@@ -167,19 +172,22 @@ case $1 in
| sim | cisco | oki | wec | wrs | winbond)
basic_machine=$field1-$field2
os=
+   vendor_inferred=
;;
*)
-   basic_machine=$field1
+   basic_machine=$field1-unknown
os=$field2
+   vendor_inferred=1
;;
esac
;;
*)
+   vendor_inferred=1
# Convert single-component short-hands not valid as part

Re: [PATCH] Add "riscv" as an alias for "riscv32"

[John Ericson]

DJ's and Karsten's concerns match my config-for-target vs 
config-for-toolchain distinction.


arm*- riscv-* and x86-* do make sense as compiler prefixes that indicate 
toolchain support for a set of targets. But when we think of a toolchain 
+ a set of standard libraries (without multilib), only a single target 
makes sense, so those 3 are all bad.


On the other hand riscv32 is bad because, as I just learned, there are 
*3* base ISAs, not *2*, and riscv32e and riscv32i are totally 
incompatible. So for targets we need riscv32e-* riscv32i-* riscv64e-*. 
riscv{32,64} may be what uname does, but uname's output is the most 
harmful of here: it's too vague for actual targets, and too specific for 
stdlib-less embedded compiler prefixes, so both camps are left wanting.


As to riscv-* I see the exact-target and toolchain use-cases as 
fundamentally irreconcilable, so GNU config should just learn the 
difference so as to satisfy everyone *without* compromise. If we can 
agree on this I volunteer to immediately do all the work---I now have 
enough information from this thread.


And finally, the original patch is no good in my mind even as a first 
incremental step, as the unconditional riscv- to riscv32- desugar is 
also wrong for embedded and desktop/distro alike.


John

P.S. Sorry to be basically repeating myself, but I think I was too wordy 
the first time / lost within the fast pace of the thread the first time 
around


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

[PATCH] * config.sub: Consolidate OS version checking

[John Ericson]

This is all that remains of the case at the top, and it can now be
straight-forwardly merged with the rest down at the bottom.
---
 ChangeLog  |   4 ++
 config.sub | 130 +++--
 2 files changed, 61 insertions(+), 73 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 03bb272..7809c9d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2018-05-23  John Ericson  <john.ericson@obsidian.systems>
+
+   * config.sub: Consolidate OS version checking
+
 2018-05-23  John Ericson  <john.ericson@obsidian.systems>
 
* config.sub: Don't force basic_machine based on $os just for
diff --git a/config.sub b/config.sub
index ecc5c5e..9100b8d 100755
--- a/config.sub
+++ b/config.sub
@@ -562,68 +562,6 @@ case $1 in
;;
 esac
 
-### Let's recognize common machines as not being operating systems so
-### that things like config.sub decstation-3100 work.  We also
-### recognize some manufacturers as not being operating systems, so we
-### can provide default operating systems below.
-case $os in
-   bluegene*)
-   os=cnk
-   ;;
-   scout)
-   ;;
-   chorusos*)
-   os=chorusos
-   basic_machine=$1
-   ;;
-   chorusrdb)
-   os=chorusrdb
-   basic_machine=$1
-   ;;
-   hiux*)
-   os=hiuxwe2
-   ;;
-   sco6)
-   os=sco5v6
-   ;;
-   sco5)
-   os=sco3.2v5
-   ;;
-   sco4)
-   os=sco3.2v4
-   ;;
-   sco3.2.[4-9]*)
-   os=`echo $os | sed -e 's/sco3.2./sco3.2v/'`
-   ;;
-   sco3.2v[4-9]*)
-   # Don't forget version if it is 3.2v4 or newer.
-   ;;
-   sco5v6*)
-   # Don't forget version if it is 3.2v4 or newer.
-   ;;
-   sco*)
-   os=sco3.2v2
-   ;;
-   isc)
-   os=isc2.2
-   ;;
-   lynx*178)
-   os=lynxos178
-   ;;
-   lynx*5)
-   os=lynxos5
-   ;;
-   lynx*)
-   os=lynxos
-   ;;
-   ptx*)
-   basic_machine=`echo "$1" | sed -e 's/86-.*/86-sequent/'`
-   ;;
-   psos*)
-   os=psos
-   ;;
-esac
-
 # Decode aliases for certain CPU-COMPANY combinations.
 case $basic_machine in
# Recognize the basic CPU types without company name.
@@ -1357,6 +1295,9 @@ case $os in
auroraux)
os=auroraux
;;
+   bluegene*)
+   os=cnk
+   ;;
solaris1 | solaris1.*)
os=`echo $os | sed -e 's|solaris1|sunos4|'`
;;
@@ -1373,26 +1314,57 @@ case $os in
es1800*)
os=ose
;;
+   # Some version numbers need modification
+   chorusos*)
+   os=chorusos
+   ;;
+   isc)
+   os=isc2.2
+   ;;
+   sco6)
+   os=sco5v6
+   ;;
+   sco5)
+   os=sco3.2v5
+   ;;
+   sco4)
+   os=sco3.2v4
+   ;;
+   sco3.2.[4-9]*)
+   os=`echo $os | sed -e 's/sco3.2./sco3.2v/'`
+   ;;
+   sco3.2v[4-9]* | sco5v6*)
+   # Don't forget version if it is 3.2v4 or newer.
+   ;;
+   scout)
+   # Don't match below
+   ;;
+   sco*)
+   os=sco3.2v2
+   ;;
+   psos*)
+   os=psos
+   ;;
# Now accept the basic system types.
# The portable systems comes first.
# Each alternative MUST end in a * to match a version number.
# sysv* is not here because it comes later, after sysvr4.
gnu* | bsd* | mach* | minix* | genix* | ultrix* | irix* \
-| *vms* | sco* | esix* | isc* | aix* | cnk* | sunos | sunos[34]*\
+| *vms* | esix* | aix* | cnk* | sunos | sunos[34]*\
 | hpux* | unos* | osf* | luna* | dgux* | auroraux* | solaris* \
 | sym* | kopensolaris* | plan9* \
 | amigaos* | amigados* | msdos* | newsos* | unicos* | aof* \
 | aos* | aros* | cloudabi* | sortix* \
 | nindy* | vxsim* | vxworks* | ebmon* | hms* | mvs* \
 | clix* | riscos* | uniplus* | iris* | rtu* | xenix* \
-| hiux* | knetbsd* | mirbsd* | netbsd* \
+| knetbsd* | mirbsd* | netbsd* \
 | bitrig* | openbsd* | solidbsd* | libertybsd* \
 | ekkobsd* | kfreebsd* | freebsd* | riscix* | lynxos* \
 | bosx* | nextstep* | cxux* | aout* | elf* | oabi* \
 | ptx* | coff* | ecoff* | winnt* | domain* | vsta* \
 | udi* | eabi* | lites* | ieee* | go32* | aux* | hcos* \
-| chorusos* | chorus

[PATCH 6/6] * config.sub: Consolidate OS version checking

[John Ericson]

This is all that remains of the case at the top, and it can now be
straight-forwardly merged with the rest down at the bottom.
---
 ChangeLog  |   1 +
 config.sub | 127 +++--
 2 files changed, 58 insertions(+), 70 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 0d00a3a..75249ff 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -6,6 +6,7 @@
* config.sub: No more os-driven subsitiion of -pc with sed
* config.sub: No more forced "-sequent" in the `basic_machine` for "ipx"
* config.sub: Don't Force `basic_machine` based on `os` just for "mint" 
and "clix"
+   * config.sub: Consolidate OS version checking
 
 2018-05-19  Ben Elliston  
 
diff --git a/config.sub b/config.sub
index 99bf891..7e701bf 100755
--- a/config.sub
+++ b/config.sub
@@ -562,65 +562,6 @@ case $1 in
;;
 esac
 
-### Let's recognize common machines as not being operating systems so
-### that things like config.sub decstation-3100 work.  We also
-### recognize some manufacturers as not being operating systems, so we
-### can provide default operating systems below.
-case $os in
-   bluegene*)
-   os=cnk
-   ;;
-   scout)
-   ;;
-   chorusos*)
-   os=chorusos
-   basic_machine=$1
-   ;;
-   chorusrdb)
-   os=chorusrdb
-   basic_machine=$1
-   ;;
-   hiux*)
-   os=hiuxwe2
-   ;;
-   sco6)
-   os=sco5v6
-   ;;
-   sco5)
-   os=sco3.2v5
-   ;;
-   sco4)
-   os=sco3.2v4
-   ;;
-   sco3.2.[4-9]*)
-   os=`echo $os | sed -e 's/sco3.2./sco3.2v/'`
-   ;;
-   sco3.2v[4-9]*)
-   # Don't forget version if it is 3.2v4 or newer.
-   ;;
-   sco5v6*)
-   # Don't forget version if it is 3.2v4 or newer.
-   ;;
-   sco*)
-   os=sco3.2v2
-   ;;
-   isc)
-   os=isc2.2
-   ;;
-   lynx*178)
-   os=lynxos178
-   ;;
-   lynx*5)
-   os=lynxos5
-   ;;
-   lynx*)
-   os=lynxos
-   ;;
-   psos*)
-   os=psos
-   ;;
-esac
-
 # Decode aliases for certain CPU-COMPANY combinations.
 case $basic_machine in
# Recognize the basic CPU types without company name.
@@ -1354,6 +1295,9 @@ case $os in
auroraux)
os=auroraux
;;
+   bluegene*)
+   os=cnk
+   ;;
solaris1 | solaris1.*)
os=`echo $os | sed -e 's|solaris1|sunos4|'`
;;
@@ -1370,26 +1314,57 @@ case $os in
es1800*)
os=ose
;;
+   # Some version numbers need modification
+   chorusos*)
+   os=chorusos
+   ;;
+   isc)
+   os=isc2.2
+   ;;
+   sco6)
+   os=sco5v6
+   ;;
+   sco5)
+   os=sco3.2v5
+   ;;
+   sco4)
+   os=sco3.2v4
+   ;;
+   sco3.2.[4-9]*)
+   os=`echo $os | sed -e 's/sco3.2./sco3.2v/'`
+   ;;
+   sco3.2v[4-9]* | sco5v6*)
+   # Don't forget version if it is 3.2v4 or newer.
+   ;;
+   scout)
+   # Don't match below
+   ;;
+   sco*)
+   os=sco3.2v2
+   ;;
+   psos*)
+   os=psos
+   ;;
# Now accept the basic system types.
# The portable systems comes first.
# Each alternative MUST end in a * to match a version number.
# sysv* is not here because it comes later, after sysvr4.
gnu* | bsd* | mach* | minix* | genix* | ultrix* | irix* \
-| *vms* | sco* | esix* | isc* | aix* | cnk* | sunos | sunos[34]*\
+| *vms* | esix* | aix* | cnk* | sunos | sunos[34]*\
 | hpux* | unos* | osf* | luna* | dgux* | auroraux* | solaris* \
 | sym* | kopensolaris* | plan9* \
 | amigaos* | amigados* | msdos* | newsos* | unicos* | aof* \
 | aos* | aros* | cloudabi* | sortix* \
 | nindy* | vxsim* | vxworks* | ebmon* | hms* | mvs* \
 | clix* | riscos* | uniplus* | iris* | rtu* | xenix* \
-| hiux* | knetbsd* | mirbsd* | netbsd* \
+| knetbsd* | mirbsd* | netbsd* \
 | bitrig* | openbsd* | solidbsd* | libertybsd* \
 | ekkobsd* | kfreebsd* | freebsd* | riscix* | lynxos* \
 | bosx* | nextstep* | cxux* | aout* | elf* | oabi* \
 | ptx* | coff* | ecoff* | winnt* | domain* | vsta* \
 | udi* | eabi* | lites* | ieee* | go32* | aux* | hcos* \
-| chorusos* | chorusrdb* | cegcc* | glidix* \
-| cygwin* | msys* | 

[PATCH 4/6] * config.sub: No more forced "-sequent" in the `basic_machine` for "ipx"

[John Ericson]

   "unknown" will be defaulted to "sequent" per existing code below.
   "pc" won't be, but I rather handle that inconsistency separately ---
   e.g. should we default to "pc" at all, or if we do should we allow
   vendor refinement anyways.
---
 ChangeLog  | 1 +
 config.sub | 3 ---
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 99a80b7..eaf8ee7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -4,6 +4,7 @@
* config.sub: Cordon off two component aliases
* config.sub: Simplify *-wrs hanlding
* config.sub: No more os-driven subsitiion of -pc with sed
+   * config.sub: No more forced "-sequent" in the `basic_machine` for "ipx"
 
 2018-05-19  Ben Elliston  
 
diff --git a/config.sub b/config.sub
index b0eae2c..80d2b1c 100755
--- a/config.sub
+++ b/config.sub
@@ -619,9 +619,6 @@ case $os in
lynx*)
os=lynxos
;;
-   ptx*)
-   basic_machine=`echo "$1" | sed -e 's/86-.*/86-sequent/'`
-   ;;
psos*)
os=psos
;;
-- 
2.16.3


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

[PATCH 5/6] * config.sub: Don't Force `basic_machine` based on `os` just for "mint" and "clix"

[John Ericson]

   I just got rid of this forcing, as it can hide the user's errors from
   the user and is unlike how other OSes are treated. I added fallbacks
   for clix (MiNT already had some) such that at least the following
   stil work:

   $ ./config.sub clipper-clix
   clipper-intergraph-clix

   $ ./config.sub m68k-mint
   m68k-atari-mint

   $ ./config.sub mint
   m68k-atari-mint

   "clix" (as opposed to "nonsense-clix", i.e. with at least one "-"
   before) never worked, so I didn't add a short-hand to make it work
   like "mint".
---
 ChangeLog  |  1 +
 config.sub | 13 ++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index eaf8ee7..0d00a3a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -5,6 +5,7 @@
* config.sub: Simplify *-wrs hanlding
* config.sub: No more os-driven subsitiion of -pc with sed
* config.sub: No more forced "-sequent" in the `basic_machine` for "ipx"
+   * config.sub: Don't Force `basic_machine` based on `os` just for "mint" 
and "clix"
 
 2018-05-19  Ben Elliston  
 
diff --git a/config.sub b/config.sub
index 80d2b1c..99bf891 100755
--- a/config.sub
+++ b/config.sub
@@ -607,9 +607,6 @@ case $os in
isc)
os=isc2.2
;;
-   clix*)
-   basic_machine=clipper-intergraph
-   ;;
lynx*178)
os=lynxos178
;;
@@ -622,10 +619,6 @@ case $os in
psos*)
os=psos
;;
-   mint | mint[0-9]*)
-   basic_machine=m68k-atari
-   os=mint
-   ;;
 esac
 
 # Decode aliases for certain CPU-COMPANY combinations.
@@ -1583,6 +1576,9 @@ case $basic_machine in
c8051-*)
os=elf
;;
+   clipper-intergraph)
+   os=clix
+   ;;
hexagon-*)
os=elf
;;
@@ -1776,6 +1772,9 @@ case $basic_machine in
genix*)
vendor=ns
;;
+   clix*)
+   vendor=intergraph
+   ;;
mvs* | opened*)
vendor=ibm
;;
-- 
2.16.3


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

[PATCH 2/6] * config.sub: Simplify *-wrs hanlding

[John Ericson]

"wrs" is just a vendor that can be handled with all the other vendors
exceptions for two component cases. `wrs) os=vxworks` can instead be put
with the other OS defaults down below.
---
 ChangeLog  | 1 +
 config.sub | 9 -
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 6e937e6..dbb62cf 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -2,6 +2,7 @@
 
* testsuite/config-sub.data: Add clipper-clix and m68k-mint tests.
* config.sub: Cordon off two component aliases
+   * config.sub: Simplify *-wrs hanlding
 
 2018-05-19  Ben Elliston  
 
diff --git a/config.sub b/config.sub
index c36dd49..9c219af 100755
--- a/config.sub
+++ b/config.sub
@@ -164,7 +164,7 @@ case $1 in
| c[123]* | convex* | sun | crds | omron* | dg | ultra 
| tti* \
| harris | dolphin | highlevel | gould | cbm | ns | 
masscomp \
| apple | axis | knuth | cray | microblaze* \
-   | sim | cisco | oki | wec | winbond)
+   | sim | cisco | oki | wec | wrs | winbond)
basic_machine=$field1-$field2
os=
;;
@@ -572,10 +572,6 @@ case $os in
;;
scout)
;;
-   wrs)
-   os=vxworks
-   basic_machine=$1
-   ;;
chorusos*)
os=chorusos
basic_machine=$1
@@ -1749,6 +1745,9 @@ case $basic_machine in
*-atari*)
os=mint
;;
+   *-wrs)
+   os=vxworks
+   ;;
*)
os=none
;;
-- 
2.16.3


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

[PATCH 3/6] * config.sub: No more os-driven subsitiion of -pc with sed

[John Ericson]

I'm not sure why this was originally added. It's certainly not needed anymore
because the `os` will never be duplicated onto the send of the `basic_machine`.
If the user passed `unknown` or no vender, this will already be filled in. If
they passed something more specific, it's customary to respect that.
---
 ChangeLog  |  1 +
 config.sub | 14 --
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index dbb62cf..99a80b7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -3,6 +3,7 @@
* testsuite/config-sub.data: Add clipper-clix and m68k-mint tests.
* config.sub: Cordon off two component aliases
* config.sub: Simplify *-wrs hanlding
+   * config.sub: No more os-driven subsitiion of -pc with sed
 
 2018-05-19  Ben Elliston  
 
diff --git a/config.sub b/config.sub
index 9c219af..b0eae2c 100755
--- a/config.sub
+++ b/config.sub
@@ -585,45 +585,31 @@ case $os in
;;
sco6)
os=sco5v6
-   basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
;;
sco5)
os=sco3.2v5
-   basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
;;
sco4)
os=sco3.2v4
-   basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
;;
sco3.2.[4-9]*)
os=`echo $os | sed -e 's/sco3.2./sco3.2v/'`
-   basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
;;
sco3.2v[4-9]*)
# Don't forget version if it is 3.2v4 or newer.
-   basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
;;
sco5v6*)
# Don't forget version if it is 3.2v4 or newer.
-   basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
;;
sco*)
os=sco3.2v2
-   basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
-   ;;
-   udk*)
-   basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
;;
isc)
os=isc2.2
-   basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
;;
clix*)
basic_machine=clipper-intergraph
;;
-   isc*)
-   basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
-   ;;
lynx*178)
os=lynxos178
;;
-- 
2.16.3


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

[PATCH 1/6] * config.sub: Cordon off two component aliases

[John Ericson]

Instead of just catching manufactures as OSes across the board, catch
them just as the second of two components. The prevent nonsense like:

$ ./config.sub amd64-unknown-ibm
x86_64-unknown-ibm-aix
---
 ChangeLog  |  1 +
 config.sub | 45 +
 2 files changed, 26 insertions(+), 20 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index f21c330..6e937e6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,6 +1,7 @@
 2018-05-21  John Ericson  <john.ericson@obsidian.systems>
 
* testsuite/config-sub.data: Add clipper-clix and m68k-mint tests.
+   * config.sub: Cordon off two component aliases
 
 2018-05-19  Ben Elliston  <b...@gnu.org>
 
diff --git a/config.sub b/config.sub
index f38250f..c36dd49 100755
--- a/config.sub
+++ b/config.sub
@@ -2,7 +2,7 @@
 # Configuration validation subroutine script.
 #   Copyright 1992-2018 Free Software Foundation, Inc.
 
-timestamp='2018-05-19'
+timestamp='2018-05-21'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -149,8 +149,30 @@ case $1 in
esac
;;
*-*)
-   basic_machine=$field1
-   os=$field2
+   # Second component is usually, but not always the OS
+   case $field2 in
+   # Prevent following clause from handling this valid os
+   sun*os*)
+   basic_machine=$field1
+   os=$field2
+   ;;
+   # Manufacturers
+   dec* | mips* | sequent* | encore* | pc532* | sgi* | 
sony* \
+   | att* | 7300* | 3300* | delta* | motorola* | sun[234]* 
\
+   | unicom* | ibm* | next | hp | isi* | apollo | altos* \
+   | convergent* | ncr* | news | 32* | 3600* | 3100* | 
hitachi* \
+   | c[123]* | convex* | sun | crds | omron* | dg | ultra 
| tti* \
+   | harris | dolphin | highlevel | gould | cbm | ns | 
masscomp \
+   | apple | axis | knuth | cray | microblaze* \
+   | sim | cisco | oki | wec | winbond)
+   basic_machine=$field1-$field2
+   os=
+   ;;
+   *)
+   basic_machine=$field1
+   os=$field2
+   ;;
+   esac
;;
*)
# Convert single-component short-hands not valid as part of
@@ -545,26 +567,9 @@ esac
 ### recognize some manufacturers as not being operating systems, so we
 ### can provide default operating systems below.
 case $os in
-   sun*os*)
-   # Prevent following clause from handling this invalid input.
-   ;;
-   dec* | mips* | sequent* | encore* | pc532* | sgi* | sony* | \
-   att* | 7300* | 3300* | delta* | motorola* | sun[234]* | \
-   unicom* | ibm* | next | hp | isi* | apollo | altos* | \
-   convergent* | ncr* | news | 32* | 3600* | 3100* | hitachi* |\
-   c[123]* | convex* | sun | crds | omron* | dg | ultra | tti* | \
-   harris | dolphin | highlevel | gould | cbm | ns | masscomp | \
-   apple | axis | knuth | cray | microblaze*)
-   os=
-   basic_machine=$1
-   ;;
bluegene*)
os=cnk
;;
-   sim | cisco | oki | wec | winbond)
-   os=
-   basic_machine=$1
-   ;;
scout)
;;
wrs)
-- 
2.16.3


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

[PATCH] * config.sub: Simplify OS checking

[John Ericson]

The removed case did a variety of things. Here's each and what I did:

 - Prevent manufacture from being treated as OS:

   Made that a special case just for two component patterns.

 - Defaulted, removed, or elaborated trailing version numbers:

   Moved down below to the main OS checking

 - Substituted some "-pc" in the `basic_machine` with sed:

   Removed as this isn't really necessary. If the user passed `unknown`
   or no vender, this will already be filled in. If they passed
   something more specific, it's customary to respect that.

 - Substituted "-sequent" in the `basic_machine` for "ipx":

   Removed. "unknown" will be defaulted to "sequent" per existing code
   below.

 - Forced `basic_machine` based on `os`, just for "mint" and "clix":

   I just got rid of this forcing, as it can hide the user's errors from
   the user and is unlike how other OSes are treated. I added fallbacks
   for clix (MiNT already had them) such that at least the following
   stil work:

   $ ./config.sub clipper-clix
   clipper-intergraph-clix

   $ ./config.sub m68k-mint
   m68k-atari-mint

   $ ./config.sub mint
   m68k-atari-mint

   "clix" (as opposed to "nonsense-clix", i.e. with at least one "-"
   before) never worked, so I didn't add a short-hand to make it work
   like "mint".
---
 ChangeLog |   4 +
 config.sub| 211 --
 testsuite/config-sub.data |   2 +
 3 files changed, 99 insertions(+), 118 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 88bab97..a08c477 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2018-05-19  John Ericson  <john.ericson@obsidian.systems>
+
+   * config.sub: Simplify OS checking
+
 2018-05-19  Ben Elliston  <b...@gnu.org>
 
* testsuite/config-sub.data: Sort.
diff --git a/config.sub b/config.sub
index f38250f..98c44ef 100755
--- a/config.sub
+++ b/config.sub
@@ -149,8 +149,35 @@ case $1 in
esac
;;
*-*)
-   basic_machine=$field1
-   os=$field2
+   # Second component is usually, but not always the OS
+   case $field2 in
+   # Prevent following clause from handling this valid os
+   sun*os*)
+   basic_machine=$field1
+   os=$field2
+   ;;
+   # Manufacturers
+   dec* | mips* | sequent* | encore* | pc532* | sgi* | 
sony* \
+   | att* | 7300* | 3300* | delta* | motorola* | sun[234]* 
\
+   | unicom* | ibm* | next | hp | isi* | apollo | altos* \
+   | convergent* | ncr* | news | 32* | 3600* | 3100* | 
hitachi* \
+   | c[123]* | convex* | sun | crds | omron* | dg | ultra 
| tti* \
+   | harris | dolphin | highlevel | gould | cbm | ns | 
masscomp \
+   | apple | axis | knuth | cray | microblaze* \
+   | sim | cisco | oki | wec | wrs | winbond)
+   basic_machine=$field1-$field2
+   os=
+   ;;
+   # Machine models
+   bluegene*)
+   basic_machine=$field1-ibm
+   os=cnk
+   ;;
+   *)
+   basic_machine=$field1
+   os=$field2
+   ;;
+   esac
;;
*)
# Convert single-component short-hands not valid as part of
@@ -540,110 +567,6 @@ case $1 in
;;
 esac
 
-### Let's recognize common machines as not being operating systems so
-### that things like config.sub decstation-3100 work.  We also
-### recognize some manufacturers as not being operating systems, so we
-### can provide default operating systems below.
-case $os in
-   sun*os*)
-   # Prevent following clause from handling this invalid input.
-   ;;
-   dec* | mips* | sequent* | encore* | pc532* | sgi* | sony* | \
-   att* | 7300* | 3300* | delta* | motorola* | sun[234]* | \
-   unicom* | ibm* | next | hp | isi* | apollo | altos* | \
-   convergent* | ncr* | news | 32* | 3600* | 3100* | hitachi* |\
-   c[123]* | convex* | sun | crds | omron* | dg | ultra | tti* | \
-   harris | dolphin | highlevel | gould | cbm | ns | masscomp | \
-   apple | axis | knuth | cray | microblaze*)
-   os=
-   basic_machine=$1
-   ;;
-   bluegene*)
-   os=cnk
-   ;;
-   sim | cisco | oki | wec | winbond)
-   os=
-  

Re: [PATCH] * config.sub: Cordon off single-component aliases

[John Ericson]

To be really precise, with my change:

$ ./config.sub 386bsd-linux
Invalid configuration `386bsd-linux': machine `386bsd' not recognized

$ ./config.sub 386bsd
i386-pc-bsd

$ ./config.sub mingw32-bsd
Invalid configuration `mingw32-bsd': machine `mingw32' not recognized

$ ./config.sub mingw32
i686-pc-mingw32

John

On 05/18/18 13:11, John Ericson wrote:
"mingw32" would still work. Indeed I do not want to break 
compatability on intended short-hands like that. But "mingw32-vms" or 
something rediculous like that will no longer. (The "vms" is ignored 
currently.)


John

On May 18, 2018 10:00 AM, Earnie <ear...@users.sourceforge.net> wrote:



    On 5/17/2018 5:57 PM, John Ericson wrote:
> Currently, there are number of aliases that expand both on their
own and as
> part of multi-component configurations. For example:
>
> $ ./config.sub 386bsd-linux
> i386-pc-bsd
>
> This change moves all of those to just trigger on a single field
branch,
> preventing their matching as part of larger components:
>
> $ ./config.sub 386bsd-linux
> Invalid configuration `386bsd-linux': machine `386bsd' not
recognized
>

This would not be kind.  I expect that config.sub gives the proper
triplet when doing ./config.sub mingw32.  Or am I not
understanding you?

The reason ./config.sub mingw32 returns the proper triplet is because
historically people, including many developers, have no idea what
i386-pc-mingw32 means when GCC and binutils creates a directory so
--host=mingw32 is given to create a mingw32 directory instead.

-- 
Earnie


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches




___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches



___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

Re: [PATCH] * config.sub: Cordon off single-component aliases

[John Ericson]

"mingw32" would still work. Indeed I do not want to break compatability on intended short-hands like that. But "mingw32-vms" or something rediculous like that will no longer. (The "vms" is ignored currently.)JohnOn May 18, 2018 10:00 AM, Earnie <ear...@users.sourceforge.net> wrote:



On 5/17/2018 5:57 PM, John Ericson wrote:

> Currently, there are number of aliases that expand both on their own and as

> part of multi-component configurations. For example:

> 

> 	$ ./config.sub 386bsd-linux

> 	i386-pc-bsd

> 

> This change moves all of those to just trigger on a single field branch,

> preventing their matching as part of larger components:

> 

> 	$ ./config.sub 386bsd-linux

> 	Invalid configuration `386bsd-linux': machine `386bsd' not recognized

> 



This would not be kind.  I expect that config.sub gives the proper

triplet when doing ./config.sub mingw32.  Or am I not understanding you?



The reason ./config.sub mingw32 returns the proper triplet is because

historically people, including many developers, have no idea what

i386-pc-mingw32 means when GCC and binutils creates a directory so

--host=mingw32 is given to create a mingw32 directory instead.



-- 

Earnie



___

config-patches mailing list

config-patches@gnu.org

https://lists.gnu.org/mailman/listinfo/config-patches


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

[PATCH] * config.sub: Cordon off single-component aliases

[John Ericson]

Currently, there are number of aliases that expand both on their own and as
part of multi-component configurations. For example:

$ ./config.sub 386bsd-linux
i386-pc-bsd

This change moves all of those to just trigger on a single field branch,
preventing their matching as part of larger components:

$ ./config.sub 386bsd-linux
Invalid configuration `386bsd-linux': machine `386bsd' not recognized

This should increase correctness, and avoid needless work in the common case
(as much of these are very very old).

I was very conservative in deciding which patterns which such single component
aliases, as this does make config.sub less forgiving than before. My criteria
for patterns in this `case $basic_machine in` were:

- The pattern doesn't contain any `-`
- The pattern doesn't contain any `*`
- `os` was assigned in the match body
- basic_machine wasn't essentially left as is.

The first rule is simple, if it contains a `-` it's not a single-component
pattern. The second rule is because any `$basic_machine` pattern with an
asterisk (`*`) could conceivable match a two component string, even if the
actual code strongly signaled that was not the intent. The third rule was to
indicate no `os` was expected, as it is valid to omit a vendor in the two
component case so `basic_machine` is just one component without being the
entire configuration.

The 4th and last rule is the trickiest, and most fuzzy human. If the
basic_machine was left as as, or appended with a vendor, I considered the
pattern less an alias, and more a defaulting of a canonical or near canonical
name. This seemed like a "higher quality" short-hand and thus one that is valid
as part of a larger config. Instead of just hard-assigning `os`, however, I
changed it to default `os` with

os=${os:-DEFAULT}

so as to respect any more information the user passed. This gives us
more pleasant absurdities like:

$ ./config.sub j90
j90-cray-unicos

$ ./config.sub j90-linux
j90-cray-linux-gnu

rather than deceitful:

$ ./config.sub j90-linux
j90-cray-unicos

Whether we want to even allow things like `j90-linux` I leave as less-
conservative follow-up work.

Cheers,

John
---
 ChangeLog  |   4 +
 config.sub | 791 +++--
 2 files changed, 404 insertions(+), 391 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 59f787a..d42bf56 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2018-05-14  John Ericson  <john.ericson@obsidian.systems>
+
+   * config.sub: Cordon off single-component aliases.
+
 2018-05-14  John Ericson  <john.ericson@obsidian.systems>
 
* config.sub: Don't prepend $os with '-' everywhere. Include it in
diff --git a/config.sub b/config.sub
index 0b4a950..c491d7d 100755
--- a/config.sub
+++ b/config.sub
@@ -2,7 +2,7 @@
 # Configuration validation subroutine script.
 #   Copyright 1992-2018 Free Software Foundation, Inc.
 
-timestamp='2018-05-14'
+timestamp='2018-05-17'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -153,8 +153,390 @@ case $1 in
os=$field2
;;
*)
-   basic_machine=$1
-   os=
+   # Convert single-component short-hands not valid as part of
+   # multi-component configurations.
+   case $field1 in
+   386bsd)
+   basic_machine=i386-pc
+   os=bsd
+   ;;
+   a29khif)
+   basic_machine=a29k-amd
+   os=udi
+   ;;
+   adobe68k)
+   basic_machine=m68010-adobe
+   os=scout
+   ;;
+   am29k)
+   basic_machine=a29k-none
+   os=bsd
+   ;;
+   amdahl)
+   basic_machine=580-amdahl
+   os=sysv
+   ;;
+   amigaos | amigados)
+   basic_machine=m68k-unknown
+   os=amigaos
+   ;;
+   amigaunix | amix)
+   basic_machine=m68k-unknown
+   os=sysv4
+   ;;
+   apollo68)
+   basic_machine=m68k-apollo
+   os=sysv
+   ;;
+   apollo68bsd)
+   basic_machine=m68k-apollo
+   

[PATCH 1/2] * config.sub: Blow up on >4 component configs

[John Ericson]

I think it's better to catch this early rather than in individual
logical components.
---
 ChangeLog  | 4 
 config.sub | 9 -
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 7295df3..099af21 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2018-05-11  John Ericson  <john.ericson@obsidian.systems>
+
+   * config.sub: Blow up on >4 component configs
+
 2018-05-05  Ben Elliston  <b...@gnu.org>
 
* config.sub: Simplify an if expression.
diff --git a/config.sub b/config.sub
index 0a518c3..8e517e7 100755
--- a/config.sub
+++ b/config.sub
@@ -117,6 +117,10 @@ EOF
 
 # Separate into logical components for further validation
 case $1 in
+   *-*-*-*-*)
+   echo Invalid configuration \`"$1"\': more than 4 components >&2
+   exit 1
+   ;;
*-*-*-*)
basic_machine=$field1-$field2
os=-$field3-$field4
@@ -385,11 +389,6 @@ case $basic_machine in
i*86 | x86_64)
  basic_machine=$basic_machine-pc
  ;;
-   # Object if more than one company name word.
-   *-*-*)
-   echo Invalid configuration \`"$1"\': machine 
\`"$basic_machine"\' not recognized 1>&2
-   exit 1
-   ;;
# Recognize the basic CPU types with company name.
580-* \
| a29k-* \
-- 
2.16.3


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

[PATCH 2/2] * config.sub: Remove leading `-' from OS

[John Ericson]

This takes out some pointless noise, and also allows removing a sed
invocation. It's a big diff but conceptually simple one that (at
least to me) improves readabiltiy.
---
 config.sub | 756 ++---
 1 file changed, 377 insertions(+), 379 deletions(-)

diff --git a/config.sub b/config.sub
index 8e517e7..9c95ed3 100755
--- a/config.sub
+++ b/config.sub
@@ -123,7 +123,7 @@ case $1 in
;;
*-*-*-*)
basic_machine=$field1-$field2
-   os=-$field3-$field4
+   os=$field3-$field4
;;
*-*-*)
# Ambiguous whether COMPANY is present, or skipped and 
KERNEL-OS is two
@@ -136,21 +136,21 @@ case $1 in
| netbsd*-eabi* | kopensolaris*-gnu* | cloudabi*-eabi* \
| storm-chaos* | os2-emx* | rtmk-nova*)
basic_machine=$field1
-   os=-$maybe_os
+   os=$maybe_os
;;
android-linux)
basic_machine=$field1-unknown
-   os=-linux-android
+   os=linux-android
;;
*)
basic_machine=$field1-$field2
-   os=-$field3
+   os=$field3
;;
esac
;;
*-*)
basic_machine=$field1
-   os=-$field2
+   os=$field2
;;
*)
basic_machine=$1
@@ -163,102 +163,102 @@ esac
 ### recognize some manufacturers as not being operating systems, so we
 ### can provide default operating systems below.
 case $os in
-   -sun*os*)
+   sun*os*)
# Prevent following clause from handling this invalid input.
;;
-   -dec* | -mips* | -sequent* | -encore* | -pc532* | -sgi* | -sony* | \
-   -att* | -7300* | -3300* | -delta* | -motorola* | -sun[234]* | \
-   -unicom* | -ibm* | -next | -hp | -isi* | -apollo | -altos* | \
-   -convergent* | -ncr* | -news | -32* | -3600* | -3100* | -hitachi* |\
-   -c[123]* | -convex* | -sun | -crds | -omron* | -dg | -ultra | -tti* | \
-   -harris | -dolphin | -highlevel | -gould | -cbm | -ns | -masscomp | \
-   -apple | -axis | -knuth | -cray | -microblaze*)
+   dec* | mips* | sequent* | encore* | pc532* | sgi* | sony* | \
+   att* | 7300* | 3300* | delta* | motorola* | sun[234]* | \
+   unicom* | ibm* | next | hp | isi* | apollo | altos* | \
+   convergent* | ncr* | news | 32* | 3600* | 3100* | hitachi* |\
+   c[123]* | convex* | sun | crds | omron* | dg | ultra | tti* | \
+   harris | dolphin | highlevel | gould | cbm | ns | masscomp | \
+   apple | axis | knuth | cray | microblaze*)
os=
basic_machine=$1
;;
-   -bluegene*)
-   os=-cnk
+   bluegene*)
+   os=cnk
;;
-   -sim | -cisco | -oki | -wec | -winbond)
+   sim | cisco | oki | wec | winbond)
os=
basic_machine=$1
;;
-   -scout)
+   scout)
;;
-   -wrs)
-   os=-vxworks
+   wrs)
+   os=vxworks
basic_machine=$1
;;
-   -chorusos*)
-   os=-chorusos
+   chorusos*)
+   os=chorusos
basic_machine=$1
;;
-   -chorusrdb)
-   os=-chorusrdb
+   chorusrdb)
+   os=chorusrdb
basic_machine=$1
;;
-   -hiux*)
-   os=-hiuxwe2
+   hiux*)
+   os=hiuxwe2
;;
-   -sco6)
-   os=-sco5v6
+   sco6)
+   os=sco5v6
basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
;;
-   -sco5)
-   os=-sco3.2v5
+   sco5)
+   os=sco3.2v5
basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
;;
-   -sco4)
-   os=-sco3.2v4
+   sco4)
+   os=sco3.2v4
basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
;;
-   -sco3.2.[4-9]*)
+   sco3.2.[4-9]*)
os=`echo $os | sed -e 's/sco3.2./sco3.2v/'`
basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
;;
-   -sco3.2v[4-9]*)
+   sco3.2v[4-9]*)
# Don't forget version if it is 3.2v4 or newer.
basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
;;
-   -sco5v6*)
+   sco5v6*)
# Don't forget version if it is 3.2v4 or newer.
basic_machine=`echo "$1" | sed -e 's/86-.*/86-pc/'`
 

Re: [PATCH 2/2] * config.sub (arm*-*-none-eabi): Recognise

[John Ericson]

Both good points; my bad. I'd be happy to submit a patch to remove or 
add back with those two fixed then.


John


On 05/11/18 21:19, Ben Elliston wrote:

On Fri, May 11, 2018 at 12:04:33PM -0400, John Ericson wrote:


I just noticed you removed my check against non-arm eabi (look for
"-*-eabi)"). Then the rest of the case doesn't so anything at all,
so it can be removed?

Yes, good point. Thanks.

I removed the check against non-ARM EABI for two reasons: (1) there is
a non-ARM EABI, the PowerPC embedded API, and (2) you were emitting an
error message to standard out and not standard error.

Cheers, Ben



___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

Re: [PATCH 2/2] * config.sub (arm*-*-none-eabi): Recognise

[John Ericson]

I just noticed you removed my check against non-arm eabi (look for 
"-*-eabi)"). Then the rest of the case doesn't so anything at all, so it 
can be removed?


Alternatively, I think it would be useful to also test which ones are 
rejected? Programs might rely on config.sub to reject certain configs, 
in addition to normalizing them.


John


On 05/05/18 07:12, Ben Elliston wrote:

On Sat, Apr 21, 2018 at 11:09:20PM -0400, John Ericson wrote:


2018-04-24  John Ericson  <john.ericson@obsidian.systems>

* config.sub (arm*-*-none-eabi): Recognise.

Applied, thanks.

Cheers,
Ben



___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

[PATCH 2/2] * config.sub (arm*-*-none-eabi): Recognise

[John Ericson]

---
 ChangeLog | 6 ++
 config.sub| 9 +
 testsuite/config-sub.data | 3 +++
 3 files changed, 18 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 1931be3..4686a1e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2018-04-24  John Ericson  <john.ericson@obsidian.systems>
+
+   * config.sub (arm*-*-none-eabi): Recognise.
+
+   These targets are useful for embedded systems.
+
 2018-04-24  John Ericson  <john.ericson@obsidian.systems>
 
* config.sub: Properly recognise configs with 4 components.
diff --git a/config.sub b/config.sub
index 9992b9c..8c0bf8c 100755
--- a/config.sub
+++ b/config.sub
@@ -1550,6 +1550,15 @@ case $os in
;;
-none)
;;
+   -*-eabi)
+   case $basic_machine in
+ arm*)
+   ;;
+ *)
+   echo \`eabi\` is only a valid ABI for ARM
+   ;;
+   esac
+   ;;
*)
# Get rid of the `-' at the beginning of $os.
os=`echo $os | sed 's/[^-]*-//'`
diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
index 28acb03..fa56587 100644
--- a/testsuite/config-sub.data
+++ b/testsuite/config-sub.data
@@ -59,6 +59,7 @@ arm-sysgo-pikeos  arm-sysgo-eabi
 arm-tirtos arm-unknown-tirtos
 arm-unknown-netbsdelf7.0   arm-unknown-netbsdelf7.0
 arm-unknown-riscos arm-unknown-riscos
+arm-unknown-none-eabi  arm-unknown-none-eabi
 armv2  armv2-unknown-none
 armv3l armv3l-unknown-none
 armv6-cloudabi-eabihf  armv6-unknown-cloudabi-eabihf
@@ -70,6 +71,7 @@ armv6m
armv6m-unknown-none
 armv6-unknown-netbsdelf7.0 armv6-unknown-netbsdelf7.0
 armv6-unknown-netbsdelf7.0-eabi
armv6-unknown-netbsdelf7.0-eabi
 armv6-unknown-netbsdelf7.0-eabihf  
armv6-unknown-netbsdelf7.0-eabihf
+armv6-unknown-none-eabiarmv6-unknown-none-eabi
 armv7a armv7a-unknown-none
 armv7a-linux-gnueabi   armv7a-unknown-linux-gnueabi
 armv7-apple-iosarmv7-apple-ios
@@ -81,6 +83,7 @@ armv7r
armv7r-unknown-none
 armv7-unknown-netbsdelf7.0 armv7-unknown-netbsdelf7.0
 armv7-unknown-netbsdelf7.0-eabi
armv7-unknown-netbsdelf7.0-eabi
 armv7-unknown-netbsdelf7.0-eabihf  
armv7-unknown-netbsdelf7.0-eabihf
+armv7m-unknown-none-eabi   armv7m-unknown-none-eabi
 armv8a armv8a-unknown-none
 armv8b-linux-gnueabi   armv8b-unknown-linux-gnueabi
 armv8m armv8m-unknown-none
-- 
2.16.3


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

[PATCH 1/2] * config.sub: Properly recognise configs with 4 components

[John Ericson]

---
 ChangeLog  | 27 ++
 config.sub | 65 ++
 2 files changed, 67 insertions(+), 25 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index e32c2c5..1931be3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,30 @@
+2018-04-24  John Ericson  <john.ericson@obsidian.systems>
+
+   * config.sub: Properly recognise configs with 4 components.
+
+   The old logic was a bit hard to follow due to lots of sed and
+   unintuitive collapsing of cases. The code now works like this
+
+   * 4 components is always parsed as
+ CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
+
+   * 2 components is always parsed as
+ CPU_TYPE-OPERATING_SYSTEM
+
+   * 1 component is always parsed as
+ CPU_TYPE
+
+   * 3 components is ambiguous and parsed as either
+ CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
+ CPU_TYPE-KERNEL-OPERATING_SYSTEM
+
+   The old code differed semantically in that
+
+   * The 4-case was awkwardly folded into the 3-case disambiguation
+
+   * The "android-linux" ad-hoc fixdup did something different in
+ the non-3 cases, but isn't intended to apply in those cases.
+
 2018-05-01  Ben Elliston  <b...@gnu.org>
 
* config.sub (maybe_os): Reindent this block.
diff --git a/config.sub b/config.sub
index 703b313..9992b9c 100755
--- a/config.sub
+++ b/config.sub
@@ -110,33 +110,48 @@ case $# in
 exit 1;;
 esac
 
-# Separate what the user gave into CPU-COMPANY and OS or KERNEL-OS (if any).
-# Here we must recognize all the valid KERNEL-OS combinations.
-maybe_os=`echo "$1" | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'`
-case $maybe_os in
-   nto-qnx* | linux-gnu* | linux-android* | linux-dietlibc | linux-newlib* 
| \
-   linux-musl* | linux-uclibc* | uclinux-uclibc* | uclinux-gnu* | 
kfreebsd*-gnu* | \
-   knetbsd*-gnu* | netbsd*-gnu* | netbsd*-eabi* | \
-   kopensolaris*-gnu* | cloudabi*-eabi* | \
-   storm-chaos* | os2-emx* | rtmk-nova*)
-   os=-$maybe_os
-   basic_machine=`echo "$1" | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`
-   ;;
-android-linux)
-   os=-linux-android
-   basic_machine=`echo "$1" | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`-unknown
-   ;;
-*)
-   basic_machine=`echo "$1" | sed 's/-[^-]*$//'`
-   case $1 in
-   *-*)
-   os=`echo "$1" | sed 's/.*-/-/'`
-   ;;
-   *)
+# Physical components of config
+IFS="-" read comp1 comp2 comp3 comp4 <https://lists.gnu.org/mailman/listinfo/config-patches

[PATCH 2/2] * config.sub (arm*-*-none-eabi): Recognise

[John Ericson]

---
 ChangeLog | 6 ++
 config.sub| 9 +
 testsuite/config-sub.data | 3 +++
 3 files changed, 18 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 1931be3..4686a1e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2018-04-24  John Ericson  <john.ericson@obsidian.systems>
+
+   * config.sub (arm*-*-none-eabi): Recognise.
+
+   These targets are useful for embedded systems.
+
 2018-04-24  John Ericson  <john.ericson@obsidian.systems>
 
* config.sub: Properly recognise configs with 4 components.
diff --git a/config.sub b/config.sub
index 7a05648..a7f9382 100755
--- a/config.sub
+++ b/config.sub
@@ -1551,6 +1551,15 @@ case $os in
;;
-none)
;;
+   -*-eabi)
+   case $basic_machine in
+ arm*)
+   ;;
+ *)
+   echo \`eabi\` is only a valid ABI for ARM
+   ;;
+   esac
+   ;;
*)
# Get rid of the `-' at the beginning of $os.
os=`echo $os | sed 's/[^-]*-//'`
diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
index 28acb03..fa56587 100644
--- a/testsuite/config-sub.data
+++ b/testsuite/config-sub.data
@@ -59,6 +59,7 @@ arm-sysgo-pikeos  arm-sysgo-eabi
 arm-tirtos arm-unknown-tirtos
 arm-unknown-netbsdelf7.0   arm-unknown-netbsdelf7.0
 arm-unknown-riscos arm-unknown-riscos
+arm-unknown-none-eabi  arm-unknown-none-eabi
 armv2  armv2-unknown-none
 armv3l armv3l-unknown-none
 armv6-cloudabi-eabihf  armv6-unknown-cloudabi-eabihf
@@ -70,6 +71,7 @@ armv6m
armv6m-unknown-none
 armv6-unknown-netbsdelf7.0 armv6-unknown-netbsdelf7.0
 armv6-unknown-netbsdelf7.0-eabi
armv6-unknown-netbsdelf7.0-eabi
 armv6-unknown-netbsdelf7.0-eabihf  
armv6-unknown-netbsdelf7.0-eabihf
+armv6-unknown-none-eabiarmv6-unknown-none-eabi
 armv7a armv7a-unknown-none
 armv7a-linux-gnueabi   armv7a-unknown-linux-gnueabi
 armv7-apple-iosarmv7-apple-ios
@@ -81,6 +83,7 @@ armv7r
armv7r-unknown-none
 armv7-unknown-netbsdelf7.0 armv7-unknown-netbsdelf7.0
 armv7-unknown-netbsdelf7.0-eabi
armv7-unknown-netbsdelf7.0-eabi
 armv7-unknown-netbsdelf7.0-eabihf  
armv7-unknown-netbsdelf7.0-eabihf
+armv7m-unknown-none-eabi   armv7m-unknown-none-eabi
 armv8a armv8a-unknown-none
 armv8b-linux-gnueabi   armv8b-unknown-linux-gnueabi
 armv8m armv8m-unknown-none
-- 
2.16.3


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

[PATCH 3/4] * config.sub: Properly recognise configs with 4 components

[John Ericson]

---
 ChangeLog  | 27 +++
 config.sub | 46 +++---
 2 files changed, 58 insertions(+), 15 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 0655aad..7e675c9 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,30 @@
+2018-04-24  John Ericson  <john.ericson@obsidian.systems>
+
+   * config.sub: Properly recognise configs with 4 components.
+
+   The old logic was a bit hard to follow due to lots of sed and
+   unintuitive collapsing of cases. The code now works like this
+
+   * 4 components is always parsed as
+ CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
+
+   * 2 components is always parsed as
+ CPU_TYPE-OPERATING_SYSTEM
+
+   * 1 component is always parsed as
+ CPU_TYPE
+
+   * 3 components is ambiguous and parsed as either
+ CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
+ CPU_TYPE-KERNEL-OPERATING_SYSTEM
+
+   The old code differed semantically in that
+
+   * The 4-case was awkwardly folded into the 3-case disambiguation
+
+   * The "android-linux" ad-hoc fixdup did something different in
+ the non-3 cases, but isn't intended to apply in those cases.
+
 2018-05-01  John Ericson  <john.ericson@obsidian.systems>
 
* config.sub (os, maybe_os): Normalize indentation to match rest of
diff --git a/config.sub b/config.sub
index 5e5eac2..06c755b 100755
--- a/config.sub
+++ b/config.sub
@@ -110,33 +110,49 @@ case $# in
 exit 1;;
 esac
 
-# Separate what the user gave into CPU-COMPANY and OS or KERNEL-OS (if any).
-# Here we must recognize all the valid KERNEL-OS combinations.
-maybe_os=`echo "$1" | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'`
-case $maybe_os in
+# Physical components of config
+comp1=`echo "$1" | sed 's/^\([^-]*\).*$/\1/'`
+comp2=`echo "$1" | sed 's/^[^-]*-\([^-]*\).*$/\1/'`
+comp3=`echo "$1" | sed 's/^[^-]*-[^-]*-\([^-]*\).*$/\1/'`
+comp4=`echo "$1" | sed 's/^[^-]*-[^-]*-[^-]*-\([^-]*\).*$/\1/'`
+
+# Separate into logical components for further validation
+case $1 in
+   *-*-*-*)
+   basic_machine=$comp1-$comp2
+   os=-$comp3-$comp4
+   ;;
+   *-*-*)
+   # Ambiguous whether COMPANY is present, or skipped and 
KERNEL-OS is two
+   # parts
+   maybe_os=$comp2-$comp3
+   case $maybe_os in
nto-qnx* | linux-gnu* | linux-android* | linux-dietlibc 
\
| linux-newlib* | linux-musl* | linux-uclibc* | 
uclinux-uclibc* \
| uclinux-gnu* | kfreebsd*-gnu* | knetbsd*-gnu* | 
netbsd*-gnu* \
| netbsd*-eabi* | kopensolaris*-gnu* | cloudabi*-eabi* \
| storm-chaos* | os2-emx* | rtmk-nova*)
+   basic_machine=$comp1
os=-$maybe_os
-   basic_machine=`echo "$1" | sed 
's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`
;;
android-linux)
+   basic_machine=$comp1-unknown
os=-linux-android
-   basic_machine=`echo "$1" | sed 
's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`-unknown
;;
*)
-   basic_machine=`echo "$1" | sed 's/-[^-]*$//'`
-   case $1 in
-   *-*)
-   os=`echo "$1" | sed 's/.*-/-/'`
-   ;;
-   *)
-   os=
-   ;;
-   esac
+   basic_machine=$comp1-$comp2
+   os=-$comp3
;;
+   esac
+   ;;
+   *-*)
+   basic_machine=$comp1
+   os=-$comp2
+   ;;
+   *)
+   basic_machine=$1
+   os=
+   ;;
 esac
 
 ### Let's recognize common machines as not being operating systems so
-- 
2.16.3


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

Re: [PATCH 2/4] Indent maybe_os stuff ahead of refactor

[John Ericson]

Sure, but I'm a bit confused on what you intended. There's a mix of tabs 
and spaces which leads me to think you are using 4 space indent with a 
tab for every 8 spaces? But the rest of the file looks like it is using 
a tab per indent level (such that the spaces/tab doesn't matter), where 
4 spaces/tab is intended so the indent visually matches what you did.


Also, I meant to _over_ indent so the next patch would be less noisy. 
Sorry my commit message was very confusing as to that intention.


Not knowing what you want, I'll do 4 patches:

1. Make all indent exclusively tab-based like the majority of the file,
   and with `| ` leading successive lines of big, multi-line case patterns.
2. Add more tabs to _properly_ :) over-indent this time preparation of (3)
3. My 4 component patch from before
4. My `arm*-*-none-eabi` patch from before

I'll fix the commit messages to match the `* config.sub ...` style too.

Let me know if you want anything additional/different.

Cheers,

John

On 05/01/18 01:46, Ben Elliston wrote:

This change is fine in principle, but I didn't agree with your
indenting rules. ;-) Please re-do your patch #3 using current master.

Cheers, Ben



___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

Fwd: Re: [PATCH 1/4] Rewrite basic_machine `if` with `case`

[John Ericson]

My bad, forgot to also reply to list-- Forwarded message --From: John Ericson <john.ericson@obsidian.systems>Date: Apr 27, 2018 12:35 AMSubject: Re: [PATCH 1/4] Rewrite basic_machine `if` with `case`To: Ben Elliston <b...@air.net.au>Cc: Indeed it didn't. Is this set good with you in that regard? Conceptually, it's 3 patches in the first change and one in the second change, which is why there are only 2 change log entries, and in the 3rd and 4th commits. Feel free to squash.I wrote it the way I did to make the diff more readable. It took a bit to work it out what was going on before, find the refactor, and convince myself that it was backwards compatible, and breaking it up into steps like this helped me. But let me know if you rather have 2 patches (or 1!) than 4 instead.JohnOn Apr 26, 2018 9:18 PM, Ben Elliston <bje@air.net.au> wrote:On Sat, Apr 21, 2018 at 10:01:26PM -0400, John Ericson wrote:



> OK the last email didn't contain the [PATCH] and attatchments

> instead, which may be less convenient.



It also didn't contain ChangeLog entries ..



Ben


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

[PATCH 1/4] Rewrite basic_machine `if` with `case`

[John Ericson]

OK the last email didn't contain the [PATCH] and attatchments instead,
which may be less convenient. Also, with my armv6m patch merged
(thanks!) there are some trivial conflicts and I realized I forgot to
include any change log entries (which you kindly added for that). So I
am now resubmitting a rebased version with change log entries.

Hope this is more convenient,

John

--
This hopefully makes the condition more readable
---
 config.sub | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/config.sub b/config.sub
index ba37cf9..ca94006 100755
--- a/config.sub
+++ b/config.sub
@@ -128,9 +128,14 @@ case $maybe_os in
 ;;
   *)
 basic_machine=`echo "$1" | sed 's/-[^-]*$//'`
-if [ "$basic_machine" != "$1" ]
-then os=`echo "$1" | sed 's/.*-/-/'`
-else os=; fi
+case $1 in
+  *-*)
+os=`echo "$1" | sed 's/.*-/-/'`
+;;
+  *)
+os=
+;;
+esac
 ;;
 esac
 
-- 
2.16.2


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

[PATCH] Add more ARM variants

[John Ericson]

 - arm6m: Add support for this mobile arch variant backport to ARM 6.
 - arm7[arm]: Already existed, but test more
 - arm8[arm]: Add support and likewise test.
---
 config.sub| 2 +-
 testsuite/config-sub.data | 6 ++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/config.sub b/config.sub
index 657a862..94760ad 100755
--- a/config.sub
+++ b/config.sub
@@ -249,7 +249,7 @@ case $basic_machine in
| alpha64 | alpha64ev[4-8] | alpha64ev56 | alpha64ev6[78] | 
alpha64pca5[67] \
| am33_2.0 \
| arc | arceb \
-   | arm | arm[bl]e | arme[lb] | armv[2-8] | armv[3-8][lb] | armv7[arm] \
+   | arm | arm[bl]e | arme[lb] | armv[2-8] | armv[3-8][lb] | armv6m | 
armv[78][arm] \
| avr | avr32 \
| ba \
| be32 | be64 \
diff --git a/testsuite/config-sub.data b/testsuite/config-sub.data
index 474dce8..f609e18 100644
--- a/testsuite/config-sub.data
+++ b/testsuite/config-sub.data
@@ -61,6 +61,7 @@ arm-unknown-netbsdelf7.0  
arm-unknown-netbsdelf7.0
 arm-unknown-riscos arm-unknown-riscos
 armv2  armv2-unknown-none
 armv3l armv3l-unknown-none
+armv6m armv6m-unknown-none
 armv6-cloudabi-eabihf  armv6-unknown-cloudabi-eabihf
 armv6eb-unknown-netbsdelf7.0   armv6eb-unknown-netbsdelf7.0
 armv6eb-unknown-netbsdelf7.0-eabi  
armv6eb-unknown-netbsdelf7.0-eabi
@@ -70,6 +71,8 @@ armv6-unknown-netbsdelf7.0
armv6-unknown-netbsdelf7.0
 armv6-unknown-netbsdelf7.0-eabi
armv6-unknown-netbsdelf7.0-eabi
 armv6-unknown-netbsdelf7.0-eabihf  
armv6-unknown-netbsdelf7.0-eabihf
 armv7a armv7a-unknown-none
+armv7r armv7r-unknown-none
+armv7m armv7m-unknown-none
 armv7a-linux-gnueabi   armv7a-unknown-linux-gnueabi
 armv7-apple-iosarmv7-apple-ios
 armv7eb-unknown-netbsdelf7.0   armv7eb-unknown-netbsdelf7.0
@@ -79,6 +82,9 @@ armv7-unknown-netbsdelf7.0
armv7-unknown-netbsdelf7.0
 armv7-unknown-netbsdelf7.0-eabi
armv7-unknown-netbsdelf7.0-eabi
 armv7-unknown-netbsdelf7.0-eabihf  
armv7-unknown-netbsdelf7.0-eabihf
 armv8b-linux-gnueabi   armv8b-unknown-linux-gnueabi
+armv8a armv8a-unknown-none
+armv8r armv8r-unknown-none
+armv8m armv8m-unknown-none
 aros   i386-pc-aros
 asmjs  asmjs-unknown-none
 avr32  avr32-unknown-none
--
2.16.2


___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches

4-component parsing, and arm*-*-none-eabi in particular

[John Ericson]

Hello,

I've long noticed that configs like `armv7m-unknown-none-eabi`, though 
supported by LLVM, are not supported by gnu-config. [LLVM would treat 
"none" as the kernel, and "eabi" as the OS/ABI.] I recently found the 
time to go investigate why, and this is what I found and patched.


The problem is the way 4-component configs (i.e. 3 dashes) are parsed. 
Commit b7ab42761455e051a57876252740cb398aa952eb is the source of this 
support, which works by special-casing certain KERNEL-OPERATING_SYSTEM 
pairs, to disambiguate between CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM 
and CPU_TYPE-KERNEL-OPERATING_SYSTEM.


This is fine for 3-component triples, but is overkill in the 4-component 
case where the config is always unambiguously 
CPU_TYPE-KERNEL-OPERATING_SYSTEM. Additionally, the original `if [ 
$basic_machine != $1 ]` check to disambiguate between 1- and 2-component 
configs is a bit obtuse.


I rewrote the whole chunk of code in what I hope you all agree is a more 
readable manner, using sed only to pull out the (up to 4) components and 
then doing everything else with simple pure bash. Finally, I whitelisted 
and tested `arm*-*-none-eabi`, which I hope a conservative starting point.


Hopefully this all makes sense, and the commit messages add additional 
clarity.


Thanks,

John

From 2b71b72b78fa9097c2fd2a8b45ad6d6555e2ca56 Mon Sep 17 00:00:00 2001
From: John Ericson <John.Ericson@Obsidian.Systems>
Date: Sat, 21 Apr 2018 22:01:26 -0400
Subject: [PATCH 1/3] Rewrite basic_machine `if` with `case`

This hopefully makes the condition more readable
---
 config.sub | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/config.sub b/config.sub
index 657a862..721d1dc 100755
--- a/config.sub
+++ b/config.sub
@@ -128,9 +128,14 @@ case $maybe_os in
 ;;
   *)
 basic_machine=`echo "$1" | sed 's/-[^-]*$//'`
-if [ "$basic_machine" != "$1" ]
-then os=`echo "$1" | sed 's/.*-/-/'`
-else os=; fi
+case $1 in
+  *-*)
+os=`echo "$1" | sed 's/.*-/-/'`
+;;
+  *)
+os=
+;;
+esac
 ;;
 esac
 
-- 
2.16.2

From 1a9d4e86538b2c8dbd8ad11c4333f0db64febd50 Mon Sep 17 00:00:00 2001
From: John Ericson <John.Ericson@Obsidian.Systems>
Date: Sat, 21 Apr 2018 22:58:24 -0400
Subject: [PATCH 2/3] Rewrite logic handling n `-`-separated components

The old logic was a bit hard to follow due to lots of sed and
unintuitive collapsing of cases. The code now works like this

 - 4 components is always parsed as
   CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM

 - 2 components is always parsed as
   CPU_TYPE-OPERATING_SYSTEM

 - 1 component is always parsed as
   CPU_TYPE

 - 3 components is ambiguous and parsed as either
   CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
   CPU_TYPE-KERNEL-OPERATING_SYSTEM

The old code differed semantically in that

 - The 4-case was awkwardly folded into the 3-case disambiguation

 - The "android-linux" ad-hoc fixdup did something different in the
   non-3 cases, but isn't intended to apply in those cases.
---
 config.sub | 60 ++--
 1 file changed, 38 insertions(+), 22 deletions(-)

diff --git a/config.sub b/config.sub
index 721d1dc..24ffe7c 100755
--- a/config.sub
+++ b/config.sub
@@ -110,33 +110,49 @@ case $# in
 exit 1;;
 esac
 
-# Separate what the user gave into CPU-COMPANY and OS or KERNEL-OS (if any).
-# Here we must recognize all the valid KERNEL-OS combinations.
-maybe_os=`echo "$1" | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'`
-case $maybe_os in
-  nto-qnx* | linux-gnu* | linux-android* | linux-dietlibc | linux-newlib* | \
-  linux-musl* | linux-uclibc* | uclinux-uclibc* | uclinux-gnu* | 
kfreebsd*-gnu* | \
-  knetbsd*-gnu* | netbsd*-gnu* | netbsd*-eabi* | \
-  kopensolaris*-gnu* | cloudabi*-eabi* | \
-  storm-chaos* | os2-emx* | rtmk-nova*)
-os=-$maybe_os
-basic_machine=`echo "$1" | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`
-;;
-  android-linux)
-os=-linux-android
-basic_machine=`echo "$1" | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`-unknown
+c1=`echo "$1" | sed 's/^\([^-]*\).*$/\1/'`
+c2=`echo "$1" | sed 's/^[^-]*-\([^-]*\).*$/\1/'`
+c3=`echo "$1" | sed 's/^[^-]*-[^-]*-\([^-]*\).*$/\1/'`
+c4=`echo "$1" | sed 's/^[^-]*-[^-]*-[^-]*-\([^-]*\).*$/\1/'`
+
+# Fix android-linux to be linux-android KERNEL-OS with unknown COMPANY
+if [ "$c2-$c3" = "android-linux" ]; then
+  c2=unknown
+  c3=linux
+  c4=android
+  set $c1-$c2-$c3-$c4
+fi
+
+case $1 in
+  *-*-*-*)
+basic_machine=$c1-$c2
+os=-$c3-$c4
 ;;
-  *)
-basic_machine=`echo "$1" | sed 's/-[^-]*$//'`
-case $1 in
-  *-*)
-os=`echo "$1" | sed 's/.*-/-/'`
+  *-*-*)
+# Ambiguous whether COMPANY is present, or skipped and KERNEL-OS is two 
parts
+maybe_os=$c2-$c3
+case