[Bug c/111237] New: fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"

[Bug c/111237] New: fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237

            Bug ID: 111237
           Summary: fp-int-convert-float64x.c fails on x86_64-apple-darwin
                    with "ambiguous instructions require an explicit
                    suffix"
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fxcoudert at gcc dot gnu.org
  Target Milestone: ---

Many of these messages:

/var/folders/h8/9hx_fyj91053ksgdzb2w03vw0000gp/T//ccO1vBzR.s:16:2: error:
ambiguous instructions require an explicit suffix (could be 'filds', or
'fildl')
        fild    -8(%rbp)
        ^
/var/folders/h8/9hx_fyj91053ksgdzb2w03vw0000gp/T//ccO1vBzR.s:19:2: error:
ambiguous instructions require an explicit suffix (could be 'fisttps', or
'fisttpl')
        fisttp  -8(%rbp)
        ^


This is on a cross-compiler from aarch64-apple-darwin22 to
x86_64-apple-darwin22, but I think it would be the same on a native compiler.


Short reproducer:

$ cat toto.c 
int main(void)
{
  unsigned char ivin;
  unsigned char ivout;
  _Float64x fv1;
  _Float64x fv2;

  ivin = 0;
  fv1 = 0;
  fv2 = (_Float64x) ivin;
  ivout = (unsigned char) fv1;
}
$ ./bin/x86_64-apple-darwin22-gcc toto.c -c
/var/folders/h8/9hx_fyj91053ksgdzb2w03vw0000gp/T//ccn0Y3rC.s:14:2: error:
ambiguous instructions require an explicit suffix (could be 'filds', or
'fildl')
        fild    -66(%rbp)
        ^
/var/folders/h8/9hx_fyj91053ksgdzb2w03vw0000gp/T//ccn0Y3rC.s:17:2: error:
ambiguous instructions require an explicit suffix (could be 'fisttps', or
'fisttpl')
        fisttp  -66(%rbp)
        ^
$ ./bin/x86_64-apple-darwin22-gcc toto.c -S
$ cat toto.s 
        .text
        .globl _main
_main:
LFB0:
        pushq   %rbp
LCFI0:
        movq    %rsp, %rbp
LCFI1:
        movb    $0, -1(%rbp)
        fldz
        fstpt   -32(%rbp)
        movzbl  -1(%rbp), %eax
        movw    %ax, -66(%rbp)
        fild    -66(%rbp)
        fstpt   -48(%rbp)
        fldt    -32(%rbp)
        fisttp  -66(%rbp)
        movzwl  -66(%rbp), %eax
        movb    %al, -49(%rbp)
        movl    $0, %eax
        popq    %rbp
LCFI2:
        ret
LFE0:
        .section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
        .set L$set$0,LECIE1-LSCIE1
        .long L$set$0
LSCIE1:
        .long   0
        .byte   0x1
        .ascii "zR\0"
        .byte   0x1
        .byte   0x78
        .byte   0x10
        .byte   0x1
        .byte   0x10
        .byte   0xc
        .byte   0x7
        .byte   0x8
        .byte   0x90
        .byte   0x1
        .align 3
LECIE1:
LSFDE1:
        .set L$set$1,LEFDE1-LASFDE1
        .long L$set$1
LASFDE1:
        .long   LASFDE1-EH_frame1
        .quad   LFB0-.
        .set L$set$2,LFE0-LFB0
        .quad L$set$2
        .byte   0
        .byte   0x4
        .set L$set$3,LCFI0-LFB0
        .long L$set$3
        .byte   0xe
        .byte   0x10
        .byte   0x86
        .byte   0x2
        .byte   0x4
        .set L$set$4,LCFI1-LCFI0
        .long L$set$4
        .byte   0xd
        .byte   0x6
        .byte   0x4
        .set L$set$5,LCFI2-LCFI1
        .long L$set$5
        .byte   0xc
        .byte   0x7
        .byte   0x8
        .align 3
LEFDE1:
        .ident  "GCC: (GNU) 14.0.0 20230830 (experimental)"
        .subsections_via_symbols


For the record, the assembler is called as:


"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
-cc1as -triple x86_64-apple-macosx13.0.0 -filetype obj -main-file-name
ccImMDJg.s -target-cpu penryn -fdebug-compilation-dir=/tmp/irun
-dwarf-debug-producer "Apple clang version 14.0.3 (clang-1403.0.22.14.1)"
-dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm
-x86-pad-for-align=false -mllvm -disable-aligned-alloc-awareness=1 -o toto.o
/var/folders/h8/9hx_fyj91053ksgdzb2w03vw0000gp/T//ccImMDJg.s

[Bug c/111237] fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237

--- Comment #1 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
The failure was not seen on August 9 at
https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/793205.html on
x86_64-apple-darwin20, so either it is a regression, or the Apple assembler has
become more strict between darwin20 and darwin22.

[Bug target/111237] fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Or the detection to see if the suffix is not exactly working correctly.

[Bug target/111237] fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-08-30
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
HAVE_AS_IX86_FILDS should have been true.

Which comes from:
    gcc_GAS_CHECK_FEATURE([filds and fists mnemonics],
       gcc_cv_as_ix86_filds,,
       [filds (%ebp); fists (%ebp)],,
       [AC_DEFINE(HAVE_AS_IX86_FILDS, 1,
         [Define if your assembler uses filds and fists mnemonics.])])

Can you attach the config.log from inside the gcc directory?

[Bug target/111237] fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|WAITING                     |RESOLVED

--- Comment #4 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Hum, I think I understand what happens then. This is a cross-compiler from
aarch64-apple-darwin22 to x86_64-apple-darwin22, configured with:

configure --prefix=/tmp/irun --with-gmp=/opt/homebrew/opt/gmp
--with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc
--with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd
--target=x86_64-apple-darwin22
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk
AS_FOR_TARGET=/usr/bin/as LD_FOR_TARGET=/usr/bin/ld NM_FOR_TARGET=/usr/bin/nm
RANLIB_FOR_TARGET=/usr/bin/ranlib AR_FOR_TARGET=/usr/bin/ar
LIPO_FOR_TARGET=/usr/bin/lipo DSYMUTIL_FOR_TARGET=/usr/bin/dsymutil

The tests are using AS_FOR_TARGET but not passing the arch, which is necessary
because it's a multi-arch linker. The actual GCC cross-compiler knows that, and
systematically passes an arch argument, but gcc_GAS_CHECK_FEATURE does not know
that.

INVALID, then. I need a better way to create this cross-compiler.

[Bug target/111237] fp-int-convert-float64x.c fails on x86_64-apple-darwin with "ambiguous instructions require an explicit suffix"

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111237

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #4)


> INVALID, then. I need a better way to create this cross-compiler.

The way to build cross compilers for GCC is:
1. build a native compiler for source
2. build a cross compiler from the same sources using (1).

Trying to use clang as a cross-bootstrap for GCC is going to be (very)
unreliable at best and most likely will fail (I quite regularly get non-bugs
reported from attempts to do this).

I regularly build crosses and native crosses and (apart from one small amount
of magic needed to get the linker version passed to a native cross) it works
reliably (including Ada).