[flang] Issue with save-temps and labels in certain columns and long procedure names

[mathomp4]

Summary

In testing some code with Flang 22, I encountered an issue with -save-temps. Well, first I found #119624 (fixing #58587) telling me I had to also add -fno-integrated-as to use it. But after that, the compiler kept randomly failing on valid Fortran.

Essentially, when compiling free-form Fortran code with flang, enabling -save-temps (or -save-temps=obj / -save-temps=cwd) can cause an indented statement label to be lost depending on the number of spaces in the indent, producing:

error: Label '101' was not found

The same source compiles successfully without -save-temps.

---

Compiler Version

> flang --version
flang version 22.1.0 (git@github.com:GEOS-ESM/build-llvm-flang.git 337c2cab67836c0beb2910664cf02d1df1e27609)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /gpfsm/dnb10/projects/p50/comp/SLES-15/llvm-flang/22.1.0/bin

---

Minimal Reproducer

write(*, fmt=101) 12
    101 format(i0)
end

Note that the label 101 is indented (four leading spaces), which is valid in free-form Fortran.

---

Commands

Baseline (works):

flang -O0 -g -c repro.F90

With -save-temps (fails):

flang -O0 -g -fno-integrated-as -save-temps -c repro.F90

Error:

> flang -O0 -g -fno-integrated-as -save-temps repro.F90
error: Semantic errors in repro.i
./repro.F90:1:7: error: Label '101' was not found
        write(*, fmt=101) 12
        ^^^^^^^^^^^^^^^^^^^^

---

Additional Observations

The failure depends on the indentation of the statement label. Using a small script (see https://gist.github.com/mathomp4/b073a15ca4eaea4bdcc0cad00266cadb) to generate different indent levels produced the following results:

> ./run_indent_matrix.sh
spaces | label_col  | rc   | result
-------+------------+------+------------------------------
0      | 1          | 0    | OK
1      | 2          | 0    | OK
2      | 3          | 0    | OK
3      | 4          | 1    | FAIL: label 101 not found
4      | 5          | 1    | FAIL: label 101 not found
5      | 6          | 1    | FAIL: error: Could not parse obj/repro_indent_5.i
6      | 7          | 0    | OK
7      | 8          | 0    | OK
8      | 9          | 0    | OK

Wrote:
  Sources/logs: obj/repro_indent_*.F90 / .log
  Table TSV:    obj/results.tsv

[klausler]

I'm not sure what save-temps does, but it sure looks like it caused free-form source to be scanned as if it were fixed-form (possibly after preprocessing). You'll need a flang-new driver expert for this one.

[mathomp4]

@klausler Yeah, that's my guess...and I found another bug!

This code:

subroutine this_module_has_a_really_long_name_that_might_be_excessive_but

implicit none
integer :: i = 10

write (*, fmt=101) 'i = ', i

101 format (a, i0)

end subroutine this_module_has_a_really_long_name_that_might_be_excessive_but

is valid Fortran as the procedure name is less than 64 characters (it's 63) and "plain flang" is happy:

> flang -O0 -g -c test.F90
> echo $?
0

But flang with -save-temps does not like it:

> flang -O0 -g -fno-integrated-as -save-temps -c test.F90
error: Could not scan test.i
./test.F90:10:7: error: Program unit END statement may not be continued in fixed form source
        end subroutine this_module_has_a_really_long_name_that_might_be_ex&
        ^^^

[klausler]

The fellow who wrote the driver no longer works on flang-new, and I don't know much about how it works since my company doesn't use this driver. I'll ask around and try to find somebody elsewhere to look at this.

[tarunprabhu]

I can take a look at this.

[mathomp4]

I can take a look at this.

If you need anyone to help push along #119624, let me know. We are looking at getting flang to be one of our main compilers for our code. We are really liking the warnings you all produce.

save-temps isn't necessary for us, but we do like it. We have a lot of preprocessor macros in our code, so often looking at the processed code is useful.

One question for you @tarunprabhu (or @klausler): Is there a "legend" for the files you get out? For example I see:

test.i
test-fir.mlir
test-llvmir.mlir
test.bc
test.s

The .i seems to be the processed code and the .s is assembly, but what are the other three? And would they ever be useful to me (someone who is not a compiler engineer). I know the usefulness of processed and assembly (and it's nice you get both, though the inode quota on my cluster might disagree), but is there value in the other two I don't know yet?

[klausler]

We are really liking the warnings you all produce.

How has your experience been with porting codes to flang-new? If you've run into any portability issues, please please file them as bugs. We don't get a whole lot of feedback.

[klausler]

*.mlir files are not likely to be useful to you -- they're in an intermediate language used by the optimizer for communication between its parts, basically. *.bc files are input to the LLVM code generator and not even human-readable.

[mathomp4]

We are really liking the warnings you all produce.

How has your experience been with porting codes to flang-new? If you've run into any portability issues, please please file them as bugs. We don't get a whole lot of feedback.

So far, not bad. It found a standards violation in MOM6 (mom-ocean/MOM6#1692) that both ifx (https://community.intel.com/t5/Intel-Fortran-Compiler/Possible-Fortran-Standards-Violation-in-ifx-2025-3/m-p/1739740#M178455) and gnu do not flag. (and I need to notify GNU about that...)

We had issues with flang 21, but you all fixed the main bugs we had. And I used to have to build flang from git develop but now I can at least build from a tag. I still have to build from scratch on Linux though because the linux tarfile releases here are for too new a glibc for our clusters.¹ For macOS, the tarfiles don't have flang but homebrew does have it now, so that's easy.

We are seeing one issue currently with flang on macOS that we are tracking down. Seems to be some sort of string issue? Maybe? Weirdly flang on linux doesn't show the issue, so that puzzles us.

But I am still trying to work out what flags we want to use with pretty good performance so it's also possible I have a mix of flags on my machines and I need to stabilize. I'll soon tackle our "Aggressive" flags. I'll probably ask on the discourse about "What flags are good for 'I want max speed!'?" 😄

Footnotes

1. I keep hoping I can build a MUSL build, but I am not good enough to do that. Someday... ↩

[mathomp4]

*.mlir files are not likely to be useful to you -- they're in an intermediate language used by the optimizer for communication between its parts, basically. *.bc files are input to the LLVM code generator and not even human-readable.

@klausler Thanks. I did just try looking at the .bc and binary fun!

I suppose once the -save-temps is happy and working, I might make a feature request to allow us to limit the temps saved. Maybe a "simple" for just .i and .s and and "expert" mode for all of them?

[klausler]

I find it weird that save-temps even emits some of these, especially the *.I files. This compiler never uses an external preprocessor, it just kind of does source preprocessing along the way while scanning text prior to parsing. So emitting a *.I file must be something that the driver is going out of its way to do, as if the compiler had a distinct preprocessing phase that it actually doesn't have.

(Please read the I suffix above as if it were lower-case. GitHub insisted on capitalizing them and I gave up trying to fix them.)

[eugeneepshteyn]

I did just try looking at the .bc and binary fun!

FYI: to get LLVM IR from .bc, use llvm-dis tool. (This tool needs to be compatible with the flang version used. For example, on some systems there may be an older LLVM distribution installed with clang compiler, so if llvm-dis is used from that distribution, it may not be able to read .bc generated by later flang version.)