User Details
- User Since
- Mar 16 2020, 6:35 AM (119 w, 4 d)
Today
Thanks
LGTM
LGTM
Yesterday
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.
Wed, Jun 29
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
Tue, Jun 28
LGTM
Thanks !
Hi @kazu, thanks for making a review and making the code style consistent. It seems part of the change is breaking builds (see bots).
Mon, Jun 27
Thanks for finding this bug and proposing a fix.
LGTM, thanks
Thu, Jun 23
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.
Wed, Jun 22
LGTM
Tue, Jun 21
LGTM (I am not sure why the patch application failed with the bots).
Mon, Jun 20
LGTM
Fri, Jun 17
Thu, Jun 16
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:
Wed, Jun 15
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?
Tue, Jun 14
LGTM
It will result in fatal internal error when collecting host association variables if not folded. Here is the example: ....
LGTM
Mon, Jun 13
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
Wed, Jun 8
Thanks
LGTM
LGTM, thanks
LGTM, thanks
May 18 2022
May 17 2022
LGTM
May 16 2022
Is the above analysis the right direction? Is there someone working on this?
May 11 2022
LGTM
Looks good
clang-format should be run on lib/Lower/ConvertExpr.cpp, otherwise LGTM.
May 10 2022
LGTM
May 9 2022
Looks good
LGTM
Looks good
May 6 2022
Thanks a lot @peixin, it is great to have this code shared and to have more regression tests here !
May 5 2022
May 4 2022
Thanks for the bug fix
Thanks
May 2 2022
Apr 29 2022
- 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?
Apr 28 2022
LGTM, thanks for the update
Apr 27 2022
Apr 26 2022
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.
Apr 25 2022
LGTM
Looks good