Strange response from IFX compiler to /FA option

[mecej4]

The 2021.1 Ifort and 2021.1-beta Ifx compilers on Windows have the /FA option to produce an assembly listing, as stated in the documentation or in the response to the ifort /? and ifx /? commands. When this option is specified, the response of ifx is strange.

S:\lang>ifx /FA /c poipr.f90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2021.1 Beta Build 20201113
Copyright (C) 1985-2020 Intel Corporation. All rights reserved.

xfortcom: Unknown command line argument '-cc1as'.  Try: 'D:\lang\ONEAPI\compiler\latest\windows\bin\xfortcom --help'
xfortcom: Did you mean '--color'?

 Nevertheless, an assembly listing will have been produced. Even though the suffix of the file produced is .asm, the listing itself is the AT&T/GNU assembler format. 

Similarly, using the ifort driver with the /S option produces a MASM format assembly listing.

[Barbara_P_Intel]

That message from ifx is a driver bug. I filed a bug report on your behalf, CMPLRLLVM-25283.

Regarding GNU vs MASM assembly format, is the machine code itself acceptable? Or do you mean ifort creates prettier code?

[mecej4]

Barbara_P:

Thanks for filing the bug report.

Regarding the output assembler files, I have this comment. On Windows, past Intel Fortran compilers have always output MASM format files with /FA. On Linux, Ifort has in the past only output AT&T format files with -S. To most people, the suffix .asm implies MASM format, and .s implies AT&T format.

This is a minor quibble, but Intel Fortran has over the last two decades kept the compiler behavior  free of unwanted surprises. Sometimes one must break away from tradition, if it is worth doing.

[Lorri_M_Intel]

Hi mecej4 --

      I'm trying to understand what you see as the difference is between MASM format, and AT&T/GNU.   I'm all for minimizing the unwanted surprises, but alas I need a few clues.

      I looked at the output for "ifx" and for "ifort" on Windows, and I do see that the "ifort" output is prettier with line numbers, header information, etc.

    Did you mean this, or does one format actually assemble, and the other one not?

                    thanks --

                                             --Lorri

[mecej4]

Lorri, thanks for replying. Here is a test program source.

print *,'Hello Fortran'; end

On Windows, using either /Fa or /S with the ifort driver produces a MASM format assembler file, see the attached file pgm_ifort.asm in the Zip (I renamed the file to distinguish it from the assembler file produced by the ifx driver). With /Fa, it produces the .asm file but proceeds to produce an OBJ file and then an EXE. With /S, it stops after producing the .asm file. The length of the .asm file is 4,238 bytes.

On Windows again, using the ifx driver, compiling with the /Fa or the /S options produces a file named pgm.asm, but it is only 1022 bytes (file pgm_ifx.asm), and it is actually an .s format (AT&T assembler) file. With /S, the driver just produces the assembly file. With /Fa, it appears to try to continue to produce OBJ and EXE files, but fails because of the bug that I reported.

Here is a screenshot of the two files side-by-side.  On the left is the ifx-generated AT&T format, with % signs prefixed to register names. On the right is the Intel/MASM format, which is output by ifort. They are quite different, and few assemblers can digest both formats.

[Barbara_P_Intel]

One more tip with ifx. "ifx -qnextgen-diag" or "ifx /Qnextgen-diag" lists the compiler options that will be supported in the future and which ones will not be.

[Barbara_P_Intel · Accepted solution]

Regarding the format of the asm file, does this undocumented compiler option, -mllvm --x86-asm-syntax=intel, give you what you expect?

[mecej4]

Thank you for that undocumented option, it seems to do the job.

Any reason not to make that the default under Windows?

At any rate, please document this option.

[Lorri_M_Intel]

Well, we wouldn't document it,  we'd make it happen by default for Windows.  (If that made sense).

Thanks for confirming that doing this would resolve the "format" part of this problem; we'll work on the rest of it too.

                  --Lorri

[Barbara_P_Intel]

This issue is resolved in the latest Fortran compiler that is part of oneAPI 2022.3. Please give it a try.