Debug Flag Not Recognized During Compilation

[davis-matthew]

Hello Flang9 Team,

I am currently trying to build your tool and encounter this error of Unknown command line argument: debug 0 (see below) during the process. (Maybe it should be debug=0 instead?)

I am compiling this on an Ubuntu 18.04 docker container with 11GB RAM and 12 CPU cores. I am building with an already built copy of the original flang, and believe all other dependencies are installed properly. Any and all help is appreciated.

Thanks.

[ 81%] Building Fortran object tools/flang/runtime/flang/CMakeFiles/flang_static.dir/iso_c_bind.F95.o cd /src/flang-marvell/build/tools/flang/runtime/flang && /usr/local/bin/flang -DINLINE_MEMOPS -DLINUX -DMAXCPUS=256 -DMAXCPUSL=8 -DMAXCPUSR=8 -DNATIVE_FPCVT -DPGF90 -DPGFLANG -DPGI_LITTLE_ENDIAN -DTARGET_LINUX -DTARGET_LINUX_X8664 -DTARGET_LLVM -DTARGET_X8664 -D_GNU_SOURCE -DSTDC_CONSTANT_MACROS -DSTDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_LONG_LONG_INT -DINT32PTR64 -DTM_I8 -I/src/flang-marvell/build/tools/flang/runtime/flang -I/src/flang-marvell/flang9/tools/flang/runtime/flang -I/src/flang-marvell/flang9/tools/flang/include -I/src/flang-marvell/build/tools/flang/include -I/usr/include/libxml2 -I/src/flang-marvell/build/include -I/src/flang-marvell/flang9/include -I/src/flang-marvell/flang9/tools/flang/runtime/include -B /src/flang-marvell/build/./bin -D_REENTRANT -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DOMP_50=1 -g -O2 -pthread -Mallocatable=03 -Mreentrant -O3 -DNDEBUG -J../../include -fPIC -Mreentrant -c /src/flang-marvell/flang9/tools/flang/runtime/flang/iso_c_bind.F95 -o CMakeFiles/flang_static.dir/iso_c_bind.F95.o gmake[2]: Leaving directory '/src/flang-marvell/build' gmake -f tools/flang/runtime/flang/CMakeFiles/flang_shared.dir/build.make tools/flang/runtime/flang/CMakeFiles/flang_shared.dir/requires

---

F90-F-0000-Internal compiler error. Unknown command line argument: debug 0 F90/x86-64 Linux Flang - 1.5 2017-05-01: compilation aborted tools/flang/runtime/flang/CMakeFiles/flang_static.dir/build.make:5809: recipe for target 'tools/flang/runtime/flang/CMakeFiles/flang_static.dir/iso_c_bind.F95.o' failed gmake[3]: *** [tools/flang/runtime/flang/CMakeFiles/flang_static.dir/iso_c_bind.F95.o] Error 1

gmake[3]: Leaving directory '/src/flang-marvell/build' tools/flang/runtime/flang/CMakeFiles/flang_static.dir/build.make:9478: recipe for target 'tools/flang/runtime/flang/CMakeFiles/flang_static.dir/ieee_exceptions.F95.o.provides' failed gmake[2]: [tools/flang/runtime/flang/CMakeFiles/flang_static.dir/ieee_exceptions.F95.o.provides] Error 2 gmake[2]: Leaving directory '/src/flang-marvell/build' CMakeFiles/Makefile2:89827: recipe for target 'tools/flang/runtime/flang/CMakeFiles/flang_static.dir/all' failed gmake[1]: [tools/flang/runtime/flang/CMakeFiles/flang_static.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs....

[flang-cavium]

Hello Matthew,

To begin with: I no longer work at Marvell. I am keeping these GitHub repos around because I know that some people might still be interested in them, and because I've been paying for these GitHub repos from my own pocket all along. But that's about it. Insofar as working on flang is concerned. I'm not doing any work on flang any longer.

Even when I was at Marvell, and was testing flang on x86_64, I never ran into this problem. But I always used my own internal builds of flang.

I understand that you are building this flang with a freshly-built flang from PGI's GitHub repo. I do not know what's been going on with the flang from PGI.

Here's my first suggestion to try to solve this: is it possible for you to try building on Ubuntu 19.10 x86_64? I see that they have an official Ubuntu 19.10 build of flang for x86_64 in their official repo:

https://ubuntu.pkgs.org/19.10/ubuntu-universe-amd64/flang-7_20190329-3_amd64.deb.html

This might solve your current problem. I don't know if it will, because I'm not an Ubuntu guy, I'm a RedHat/Fedora guy. But I think it's worth a try.

--Stefan

---

On Wed, May 20, 2020 at 3:45 PM Matthew Davis notifications@github.com wrote:

Hello Flang9 Team,

I am currently trying to build your tool and encounter this error of Unknown command line argument: debug 0 (see below) during the process. I am compiling this on an Ubuntu 18.04 docker container with 11GB RAM and 12 CPU cores. I am building with the original flang, and believe all other dependencies are installed properly. Any and all help is appreciated.

Thanks.

[ 81%] Building Fortran object tools/flang/runtime/flang/CMakeFiles/flang_static.dir/iso_c_bind.F95.o cd /src/flang-marvell/build/tools/flang/runtime/flang && /usr/local/bin/flang -DINLINE_MEMOPS -DLINUX -DMAXCPUS=256 -DMAXCPUSL=8 -DMAXCPUSR=8 -DNATIVE_FPCVT -DPGF90 -DPGFLANG -DPGI_LITTLE_ENDIAN -DTARGET_LINUX -DTARGET_LINUX_X8664 -DTARGET_LLVM -DTARGET_X8664 -D_GNU_SOURCE -DSTDC_CONSTANT_MACROS -DSTDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_LONG_LONG_INT -DINT32PTR64 -DTM_I8 -I/src/flang-marvell/build/tools/flang/runtime/flang -I/src/flang-marvell/flang9/tools/flang/runtime/flang -I/src/flang-marvell/flang9/tools/flang/include -I/src/flang-marvell/build/tools/flang/include -I/usr/include/libxml2 -I/src/flang-marvell/build/include -I/src/flang-marvell/flang9/include -I/src/flang-marvell/flang9/tools/flang/runtime/include -B /src/flang-marvell/build/./bin -D_REENTRANT -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DOMP_50=1 -g -O2 -pthread -Mallocatable=03 -Mreentrant -O3 -DNDEBUG -J../../include -fPIC -Mreentrant -c /src/flang-marvell/flang9/tools/flang/runtime/flang/iso_c_bind.F95 -o CMakeFiles/flang_static.dir/iso_c_bind.F95.o gmake[2]: Leaving directory '/src/flang-marvell/build' gmake -f tools/flang/runtime/flang/CMakeFiles/flang_shared.dir/build.make tools/flang/runtime/flang/CMakeFiles/flang_shared.dir/requires

---

F90-F-0000-Internal compiler error. Unknown command line argument: debug 0 F90/x86-64 Linux Flang - 1.5 2017-05-01: compilation aborted tools/flang/runtime/flang/CMakeFiles/flang_static.dir/build.make:5809: recipe for target 'tools/flang/runtime/flang/CMakeFiles/flang_static.dir/iso_c_bind.F95.o' failed gmake[3]: *** [tools/flang/runtime/flang/CMakeFiles/flang_static.dir/iso_c_bind.F95.o] Error 1

---

gmake[3]: Leaving directory '/src/flang-marvell/build' tools/flang/runtime/flang/CMakeFiles/flang_static.dir/build.make:9478: recipe for target 'tools/flang/runtime/flang/CMakeFiles/flang_static.dir/ieee_exceptions.F95.o.provides' failed gmake[2]: [tools/flang/runtime/flang/CMakeFiles/flang_static.dir/ieee_exceptions.F95.o.provides] Error 2 gmake[2]: Leaving directory '/src/flang-marvell/build' CMakeFiles/Makefile2:89827: recipe for target 'tools/flang/runtime/flang/CMakeFiles/flang_static.dir/all' failed gmake[1]: [tools/flang/runtime/flang/CMakeFiles/flang_static.dir/all] Error 2 gmake[1]: *** Waiting for unfinished jobs....

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

-- Stefan Teleman stefan.teleman@gmail.com

[davis-matthew]

Hello Mr. Teleman,

Thank you for your help.

I attempted on x86_64 ubuntu 19.10 with the prebuilt flang package and received the same debug 0 error. If this helps you, I am not constrained to ubuntu, so if you have something put together like RedHat/Fedora build scripts I am open to switch over and test on that instead.

According to the log, the error seems to occur while dealing with the PGI's Flang static library directory. Perhaps this is something that PGI's Flang has updated since, making it incompatible? I'm not sure if this is the reason though considering their container on ubuntu had a 2019 release date.

[flang-cavium]

Hi Matthew,

I will find some time to build flang on x86_64 on my home projects laptop (Fedora 31) and figure out what's going on. It will take me a few days because, well, flang is no longer part of my daily responsibilities. :-)

PGI has indeed made several updates to their trunk. I don't know what these are, or what these do, because I haven't followed them.

One other thing you could try is to test every single compile-line flag that's being passed to flang at the trouble point and see which one causes the problem. Something like:

!/bin/bash

for flag in \ -g \ -O2 \ -pthread \ [ ... etc etc etc ... ] do /path/to/flang ${flag} ... done

I would imagine the -I and the -B flags are safe. But you never know ...

---

On Sun, May 24, 2020 at 7:34 PM Matthew Davis notifications@github.com wrote:

Hello Mr. Teleman,

Thank you for your help.

I attempted on x86_64 ubuntu 19.10 with the prebuilt flang package and received the same debug 0 error. If this helps you, I am not constrained to ubuntu, so if you have something put together like RedHat/Fedora build scripts I am open to switch over and test on that instead.

According to the log, the error seems to occur while dealing with the PGI's Flang static library directory. Perhaps this is something that PGI's Flang has updated since, making it incompatible? I'm not sure if this is the reason though considering their container on ubuntu had a 2019 release date.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/flang-cavium/flang9/issues/2#issuecomment-633316599, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJENIW26ODJQ6MLXLLHTMQDRTGVI7ANCNFSM4NGIFPOQ .

-- Stefan Teleman stefan.teleman@gmail.com

[davis-matthew]

Mr. Teleman,

Thanks for the suggestion. I had initially assumed that -DNDEBUG was the cause of the problems, but when I tested the flags individually, it seems that the debug info flag -g is the culprit. While removing this flag got rid of the debug 0 error, the build still failed on the command so I assume it's required.

It will take me a few days because, well, flang is no longer part of my daily responsibilities. :-)

No worries, any help you can give is very appreciated, and my coworker and I are going to dive deeper into this in the mean time.

[flang-cavium]

Hi Matthew,

You can compile without -g, but you won't get any debug symbols, therefore you will not be able to debug the resulting program or library.

But this is just a temporary drawback. What I mean is, you could do the following:

1. Compile Marvell LLVM/flang with the flang from PGI, without -g. Hopefully it works.
2. You get binaries for LLVM/Marvell flang, but without debug symbols (lack of -g).
3. Install the binaries of Marvell LLVM/flang, and then re-compile Marvell LLVM/flang with the newly built Marvell flang, which won't crash when you pass -g.
4. Re-install the newly built Marvell LLVM/clang/flang, this time around built with -g.

---

On Thu, May 28, 2020 at 9:26 PM Matthew Davis notifications@github.com wrote:

Mr. Teleman,

Thanks for the suggestion. I had initially assumed that -DNDEBUG was the cause of the problems, but when I tested the flags individually, it seems that the debug info flag -g is the culprit. While removing this flag got rid of the debug 0 error, the build still failed on the command so I assume it's required.

It will take me a few days because, well, flang is no longer part of my daily responsibilities. :-)

No worries, any help you can give is very appreciated, and my coworker and I are going to dive deeper into this in the mean time.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/flang-cavium/flang9/issues/2#issuecomment-635703652, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJENIW2EZDLWS24DTTXI56TRT4FMDANCNFSM4NGIFPOQ .

-- Stefan Teleman stefan.teleman@gmail.com

[davis-matthew]

Mr. Teleman,

I am currently in the process of doing these steps on a completely fresh container. I was reviewing the process that I did previously and noticed a few potential spots that may be causing the issues.

The GCC_RUNPATH variable in the Makefile.build could be wrong in my build. I set it as /usr/lib/gcc/x86_64-linux-gnu/9/, however I notice that the usr/lib and overall lib paths seem to contain the same content (see images below). I assumed either would be fine, but I was a little uncertain on what I was trying to find with the runpath, so I think it's best to check to make sure.

Secondly, when I was just starting building flang9 I encountered an error gcc: fatal error: cannot execute 'f951'. F951 is apparently the gfortran fortran 95 compiler's name internally used by gcc. I didn't expect gfortran to be a dependency, but when rebuilding I just installed gfortran first. Should I static link f951 to flang instead? Perhaps switching compilers for commands is causing some sort of compatibility issue.

[flang-cavium]

Hi Matthew,

You don't need gfortran at all for building flang. In fact, gfortran can't even compile one of the flang libraries - it bails out with an error. So, gfortran is really not that useful at all for building flang.

As a first step, you should try building the Marvell LLVM/flang with the flang from PGI you have already built. But without passing the -g flag.

After you have built the first version of the Marvell LLVM/flang -- with the flang from PGI, you can install the Marvell LLVM/flang somewhere on your system.

And then, you can re-build the Marvell LLVM/flang with the newly built Marvell LLVM/flang that you have just installed. This (second) time around you can pass -g to the newly installed Marvell flang. It should work.

--Stefan

---

On Mon, Jun 1, 2020 at 8:26 PM Matthew Davis notifications@github.com wrote:

Mr. Teleman,

I am currently in the process of doing these steps on a completely fresh container. I was reviewing the process that I did previously and noticed a few potential spots that may be causing the issues.

The GCC_RUNPATH variable in the Makefile.build could be wrong in my build. I set it as /usr/lib/gcc/x86_64-linux-gnu/9/, however I notice that the usr/lib and overall lib paths seem to contain the same content (see images below). I assumed either would be fine, but I was a little uncertain on what I was trying to find with the runpath, so I think it's best to check to make sure.

[image: image] https://user-images.githubusercontent.com/45373823/83465036-373ba100-a438-11ea-925f-6d7b50e5430d.png [image: image] https://user-images.githubusercontent.com/45373823/83465175-b03af880-a438-11ea-8aef-d43f37abcaa1.png

Secondly, when I was just starting building flang9 I encountered an error gcc: fatal error: cannot execute 'f951'. F951 is apparently the gfortran fortran 95 compiler's name internally used by gcc. I didn't expect gfortran to be a dependency, but when rebuilding I just installed gfortran first. Should I static link f951 to flang instead? Perhaps switching compilers for commands is causing some sort of compatibility issue.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/flang-cavium/flang9/issues/2#issuecomment-637196275, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJENIW7ZPXR4UBH7OEDI7ULRURBK5ANCNFSM4NGIFPOQ .

-- Stefan Teleman stefan.teleman@gmail.com

[dylantheriot]

Hi Stefan,

I have been working with Matthew on compiling flang9. Thank you so much for all of your help so far.

We have gotten farther along in the build script, which is awesome, but we're still failing to compile the flang in the flang9 repo with iso_c_bind.f95. The issue is different, however, and the message we receive now is:

/tmp/iso_c_bind-2eed6f.ll:117:100: error: invalid field 'spFlags' !21 = distinct !DISubprogram(file: !3, scope: !20, name: "compare_eq_cptrs", line: 158, type: !18, spFlags: 8, unit: !10, (null): 158)

Do you have any thoughts or suggestions on where this error can stem from? We've attempted examining the command with -verbose but it hasn't yielded any helpful results yet.

Also, is there any public documentation regarding how flang9 produces LLVM9 ir? Does it first generate LLVM7 ir and then convert it to newer IR, or is it done at the stage of converting Fortran to ILM?

[flang-cavium]

Hi Dylan,

This is a problem/error in the way flang generates DWARF debug info.

So, could you please give me a bit more details:

• which flang generates this error? Is it the flang built directly from PGI source, or is it the Marvell LLVM/flang 9.0.1?

If it's the flang build from PGI source, I'm afraid you have to give up on generating DWARF debug info. It's obviously very broken. PGI/NVIDIA has moved on and they aren't doing any significant work on the "old" flang. They are only focused on the "new" flang, the one that is now a bona fide LLVM project.

There is no public documentation on how the "old" flang (any version) produces LLVM IR. I've never seen one, I had to read the code. Flang does not use an AST that is understood by clang, therefore the LLVM IR generation does not go through clang's transformations. Flang generates LLVM IR directly from its own flang AST, and that is passed directly to LLVM.

---

On Tue, Jun 9, 2020 at 5:06 PM Dylan Theriot notifications@github.com wrote:

Hi Stefan,

I have been working with Matthew on compiling flang9. Thank you so much for all of your help so far.

We have gotten farther along in the build script, which is awesome, but we're still failing to compile the flang in the flang9 repo with iso_c_bind.f95. The issue is different, however, and the message we receive now is:

/tmp/iso_c_bind-2eed6f.ll:117:100: error: invalid field 'spFlags' !21 = distinct !DISubprogram(file: !3, scope: !20, name: "compare_eq_cptrs", line: 158, type: !18, spFlags: 8, unit: !10, (null): 158)

Do you have any thoughts or suggestions on where this error can stem from? We've attempted examining the command with -verbose but it hasn't yielded any helpful results yet.

Also, is there any public documentation regarding how flang9 produces LLVM9 ir? Does it first generate LLVM7 ir and then convert it to newer IR, or is it done at the stage of converting Fortran to ILM?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/flang-cavium/flang9/issues/2#issuecomment-641573899, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJENIWYKIEWRGWTZW2EOLYTRV2P47ANCNFSM4NGIFPOQ .

-- Stefan Teleman stefan.teleman@gmail.com

[dylantheriot]

Hi Stefan,

The flang that generates the previous error is PGI's flang while trying to compile the flang within flang9.

However, we are now trying a new angle. We were successfully able to compile Marvell's flang7 port using PGI's flang. We are now attempting to use flang7 to build flang8 (and then hope to use flang8 to build flang9), and are running into an issue regarding metadata. The following issue occurs when we try to compile either flang8 or flang9 using flang7:

/tmp/ieee_exceptions-c695db.ll:1230:8: error: expected metadata type !170 = !DIFortranSubrange(constLowerBound: 1, upperBound: !168, upperBoundExpression: !169)

We have found the Metadata.cpp file that should contain the metadata for DIFortranSubrange, but we are not quite sure how to include this. Do you have any additional thoughts on this?

Once again, thank you for all of the information. We are extremely appreciative of it!

[flang-cavium]

Hi Dylan,

Metadata.cpp is part of LLVM - and libLLVM (in lib/IR).

For compile-time, to get access to the DIFortranSubrange definition you need to #include <llvm/IR/DebugInfoMetadata.h>.

For link-time, other than linking with -lLLVM you shouldn't have to do anything special to import interfaces from this file.

But it looks to me like the error you get comes from flang7 - again - emitting wrong DWARF metadata info. The error happens during the transformation sequence of ieee_exceptions-.ll, which is a temporary LLVM IR file created by flang2.

I see that a flang issue related to this problem was opened at PGI Flang:

https://github.com/flang-compiler/flang/issues/781

The issue was marked as "resolved" earlier this year.

So it looks like a matter of bisection detective work to figure out which changes to flang code are necessary to solve this problem.

Did you by any chance configure flang with -DFLANG_LLVM_EXTENSIONS=ON in CMAKE_OPTIONS? I remember it used to cause tons of problems. And the PGI flang issue above (781) mentions it as well.

In fact, for the Marvell port of flang (any version) you don't need it. I already enabled all the required flang extensions to LLVM without the need for this CMake option / macro.

---

On Fri, Jun 12, 2020 at 5:53 PM Dylan Theriot notifications@github.com wrote:

Hi Stefan,

The flang that generates the previous error is PGI's flang while trying to compile the flang within flang9.

However, we are now trying a new angle. We were successfully able to compile Marvell's flang7 port using PGI's flang. We are now attempting to use flang7 to build flang8 (and then hope to use flang8 to build flang9), and are running into an issue regarding metadata. The following issue occurs when we try to compile either flang8 or flang9 using flang7:

/tmp/ieee_exceptions-c695db.ll:1230:8: error: expected metadata type !170 = !DIFortranSubrange(constLowerBound: 1, upperBound: !168, upperBoundExpression: !169)

We have found the Metadata.cpp file that should contain the metadata for DIFortranSubrange, but we are not quite sure how to include this. Do you have any additional thoughts on this?

Once again, thank you for all of the information. We are extremely appreciative of it!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

-- Stefan Teleman stefan.teleman@gmail.com