Please test with "L" embedded in a CHARACTER that is used as a format.

What is intrinsics_gen?

Isn't this actually the fortran name and not a name arising from a bind c? If that's true, do we have to overload the meaning of bind c do the needful?

Nice!

Perhaps causing https://github.com/llvm/llvm-project/issues/60356

@mnadeem Please update the documentation llvm-project/flang/docs/Directives.md to include dir$ loop count. Thank you!

In D137812#4055519, @peixin wrote:

Thanks @sscalpone for providing this case. The case of allocate array with scalar source is missed in this patch. Can I file a ticket for this case and support this in next patch?

How is the scalar source handled? Here is what I see:

For the information that is being removed, e.g. "do concurrent" or the description of ResolveNames -- is this obsolete or repeated in another document?

Hi Pete!

@peixin It seems these code snippets from Intel are part of a copyrighted file, owned by Intel. Do you know if LLVM has a policy about including such code, even in a code review like this?

Bold changes Pete!

@dblaikie Try -DLLVM_ENABLE_PROJECTS="clang;mlir;flang"

My preference is that the reference output match the output of flang with the default settings. Would that work with the gfortran + the provided FP_TOLERANCE? The consensus was not to include fcvs in the llvm-project tree; we can revisit that decision if you'd like to start a thread in discourse or on of the weekly calls.

How does fpcmp fit into this issue? Is that in the checker?

I'm fine with removing or renaming the existing flang shell script.

Recommend that you contact NAG for more info on the test suite. Here's the only reference that I could find: https://fortran-lang.discourse.group/t/fortran-compiler-testing-framework/1573/10

This solution looks reasonable for stop messages. I presume it kicks in when running individual tests as well as the suite.

My proposal is:

Are you able to use the environment variable NO_STOP_MESSAGE=1 instead?

My belief is that we should wait until f18 hits a reasonable quality bar for executables before making flang-new the default. My reasoning seems not to have carried the day.

I build openmp

As I said this morning, I prefer to wait with this patch until the upstreaming is finished. The reason is not only to do with upstreaming, but also with a concurrent effort to button up any assertion and runtime errors so the initial user experience is better. While some posit the the news of your patch won't be heard around the world, I think it is a major accomplishment & the user community will be thrilled to try flang. My preference is for that first wave of users to come a way with the impression that flang is a high-quality work in progress.

Looks good! Works in my testbed.

Tested and executed. Works for me!

@Meinersbur I understand.

Time to upgrade to C++20?
https://en.cppreference.com/w/cpp/types/endian

Looks good! Thanks

Worked for me. Thanks!

@PeteSteinfeld Doc to build docs https://github.com/llvm/llvm-project/tree/main/flang#how-to-generate-documentation

Builds and passed tests for me.

Built & passed tests for me.

Are these warning problems? Is there a reason these aren’t errors? Or have associated file names and line numbers?

Are you able to make a small table for us to look at the whole list of supported fixed and free form sources?

@awarzynski, perhaps I am being too dramatic by wondering if we are compromising support for one or the other language in order to support a common definition. In the case of -I, there are language-specific semantics that are important and interesting, such as the relationship in clang between -I and -isystem, and the relationship in flang between -I and -module. Maybe the right answer is to allow the definition of duplicate options that are differentiated by language?

Flang supports include files and module files. The search path is used to look for both include files and module files. The help text doesn't include info about module files.

I can see how these messages can be useful for a compiler developer; however, perhaps these messages are redundant for end users because other error messages have been issued.

Nice simplification!

Thanks Pete!

@sameeranjoshi Please consider fixing this issue in the conversion tool (maybe commonmark.py) & propagating the fix to llvm.org?

Why?

@Meinersbur. Hi Michael, I believe you prefer @klausler to make the patch, so he's going ahead with it.

The install target required me to build all of the documentation. I do not think that is related to this change. Otherwise, the web pages rendered nicely.

Please add a note to the overview about this requirement:

After this patch the markdown docmentation must be written using guide in-
llvm/docs/MarkdownQuickstartTemplate.md

Looks good!

Sorry, I'm not sure what to do next. I'm using cmake vesion 3.18.0 and gcc 9.3.0.

I think you missed one.

Did this work for you?

This worked for me:

I think md is the wave of the future. Other llvm subproject use md. Let's stick with what we have unless there's a compelling advantage to using rst or another format.

This commit has broken the out of tree builds.

out of place as in for a different directive where it is not supported?

OK

The gfortran options is -fimplicit-none. It doesn't appear to have an inverse, but following the convention would be -fno-implicit-none. I think there is value using the same spelling for this option.

Here are the clang definitions:

Do you have a negative test that checks for an out-of-place allocate?

Fix fm324 and fm333. Thanks

No objection to first moving documentation to docs. If someone takes this on, there are links that need to be updated, relatively in the project and in for example Gary's call notes.

Hi Rich, sorry not to have replied to your other review. No one on the NV team needs f18 to read from stdin.