Thanks

LGTM

LGTM

Thanks

LGTM

I am not sure how to ask this question, but if I have an instance of Expr<SomeType> and I know that it is an array (through checking the rank of the argument) , is there a way to unpack the Expr<SomeType> so that I have something like an array of Expr<SomeType>, so that I can iterate over the array and do the check for a non-positive value? This is what I was trying to track down and I couldn't find. I would appreciate any advice or pointing towards portions of code that might be helpful for me to look at, thanks!

LGTM

Thanks for the update, preserving more constant shape information in the FIR types looks better to me.

Even if all the failed tests passed the execution. I am still worried if this patch will crash some other code

Looks good

Thanks

Thanks

LGTM

LGTM

Thanks !

In D128597#3614079, @peixin wrote:

The execution result for the test case in this patch would be 0 0 1 2 if you change it into one main program. The expected result is 1 2 3 4.

Hi @kazu, thanks for making a review and making the code style consistent. It seems part of the change is breaking builds (see bots).

Thanks for finding this bug and proposing a fix.

LGTM, thanks

Looks good, thanks

LGTM

Looks great to me thanks !

Thanks, it is great to be able to provide more compile time feedback. I think KindCode is not the right place to encode and complain about illegal argument values when they can be known and checked at compile time.

LGTM, maybe some leftover debugging in unittests/Evaluate/real.cpp though.

LGTM

LGTM (I am not sure why the patch application failed with the bots).

LGTM

Thanks for the answer Peixin, now I see what you meant. I however think that may be a "feature", not a bug. With your patch the following code would be rejected:

Looks good

LGTM

However, I think it still needs analyze the negate expression when it is not in module/submodule since doing the similar analysis as the unary plus expression is reasonable. What do you think? @jeanPerier Would it affect the lowering if the negate expression in execution part not analyzed?

LGTM

It will result in fatal internal error when collecting host association variables if not folded. Here is the example: ....

LGTM

LGTM

What is the motivation of this folding: is it required for semantics check, or does it lead to better code ?

Thanks

Looks good

LGTM

Thanks

LGTM

LGTM, thanks

LGTM, thanks

LGTM

Is the above analysis the right direction? Is there someone working on this?

LGTM

Looks good

clang-format should be run on lib/Lower/ConvertExpr.cpp, otherwise LGTM.

LGTM

Looks good

LGTM

Looks good

Thanks a lot @peixin, it is great to have this code shared and to have more regression tests here !

Thanks for the bug fix

Thanks

• Add note in docs/Extensions.md.
• Inlcude semantics.h in PFTBuilder.h instead of redefining the typdef
• Fix typos

Could you add comments to docs/Extensions.md to describe that (1) initializations of common outside BLOCK DATA and (2) initializations of blank COMMON are both non-standard, but are near-universal extensions that we have to support?

LGTM, thanks for the update

In D123520#3477672, @FruitClover wrote:

Windows buildbot failed https://lab.llvm.org/buildbot/#/builders/172/builds/11593 after this patch in flang\test\Semantics\select-rank.f90:
[...]
but for now I don't understand the root cause yet (no lbound/ubound in testcase)
(CC @jeanPerier / @klausler )

I am surprised because the dispatching uses host::FortranType<HostT> (at [1]) to avoid making assumptions regarding what the host floating points are. So I would have expected this code to automatically map long double to REAL(16) on ppc64le, but obviously, there is a bug/issue somewhere. Thanks for the fix.

LGTM

Looks good