LGTM

LGTM. It looks like D147237 was not pulled into the testing.

LGTM

In D145808#4199315, @DavidTruby wrote:

In D145808#4197028, @kiranchandramohan wrote:

@jdoerfert Would using functions from compiler-rt cause issues with target offloading?
Context: We are thinking of using functions from compiler-rt for implementing the complex division operation. The existing implementations in Flang (an inline one) and the one on MLIR both have precision issues whereas the compiler-rt ones work fine.

I think these functions exist for target offloading too, I've used complex numbers in omp regions in C/C++ before and it has worked, and afaict clang just calls these functions. At least for Nvidia there's clang/lib/Headers/__clang_cuda_complex_builtins.h which contains them.

In D141820#4221238, @peixin wrote:

Hi @vzakhari , are you still working on box/type descriptor such as type_desc_4/5/6? Or do you plan to work on that later? I am studying some optimizations which may benefit from the complete tbaa.

LGTM
Please address @awarzynski's comment about the test.

Thank you for the update!

Yes, I think the option to control ctlz conversion will do. The default is up to you.

Hi @j2kun, welcome to MLIR code base :)

Thank you for working on this!

Thank you for the update!

Got rid of FLANG_BUILD_EXAMPLES in favor of LLVM_BUILD_EXAMPLES.

FYI, "Invalid shuffle vector instruction operands!" assertion kicks in with both first and second commits: https://github.com/llvm/llvm-project/issues/61395

In D145992#4190978, @PeteSteinfeld wrote:

Thanks, Slava. You're a prince!

All builds and tests correctly and looks good.

I wonder whether intermediate computations generated by ComplexToStandard conversion complex::DivOp honor the range of the element's data type. Maybe we can think of replacing the FIR operation with the one from the Complex dialect?

In D145653#4189049, @clementval wrote:

Fine for me if this is the intended behavior.

Thanks!

One minor thing, otherwise, looks good.

LGTM

LGTM

Thanks!

Thanks!

LGTM

The new tests fail to link:

flang-new: warning: The warning option '-Wextra' is not supported
/usr/bin/ld: cannot find -lFortran_main
/usr/bin/ld: cannot find -lFortranRuntime
/usr/bin/ld: cannot find -lFortranDecimal

Thank you for the review, Pete!

FYI, Flang Intrinsics/math-codegen failure should be resolved by D144523

LGTM

LGTM

Thanks!

Thank you, @gysit! LGTM

FYI, the build is failing due to missing dependency: https://lab.llvm.org/buildbot/#/builders/181/builds/14278
I will merge the fix shortly.

Thank you!

Thank you!

In D142279#4096350, @foad wrote:

In D142279#4090165, @rovka wrote:

EDIT: I asked on the flang slack instance, hopefully we'll get an opinion from someone more actively involved.

Thanks! The consensus on slack seemed to be that we should disable assertions (maybe just libstdc++ assertions?) in the runtime library. Does anyone know how to implement that in cmake? I experimented with remove_definitions(_GLIBCXX_ASSERTIONS) in flang/runtime/CMakeLists.txt but couldn't get it to work.

LGTM. Thanks!

Fixes the test to work with D142548