Could you elaborate on this?

Maybe this should be a cmake option that is off by default and I can turn it for my builds?

As a downstream packager of libclang, I really like the SONAME not changing in libclang. It makes it possible for us to package things like qt that depend on libclang, but not have to rebuild qt for every major revision of LLVM.
It's not clear to me what the reason for removing this is. Can someone help me understand why this useful feature was removed?

Should this be backported to release/12.x branch? Otherwise openmp on macos is broken in 12.x series.

Is there a way to re-run the unit tests that are failing. I don't think they are related.

Update patch for monorepo

It's already done for clang at https://github.com/llvm/llvm-project/blob/d480f968ad8b56d3ee4a6b6df5532d485b0ad01e/clang/CMakeLists.txt#L55

Move adding CMAKE_CURRENT_BINARY_DIR to tablegen function

Rebased on top of master and fixes for new directories

Is there any interest in this? If so, I can rebase this on top of master and send it.

Is 128 for the path size enough?

In D84334#2208010, @sscalpone wrote:

This commit has broken the out of tree builds.

This probably needs to include CMAKE_CURRENT_BINARY_DIR as a include directory.

What's the reason for keeping these? IMO, the lines should be removed and let FLANG_ENABLE_WERROR cmake option add it if a developer needs it.

@ro, there are some red pre-merge checks. Not sure what those are about. Any ideas?

I'd like to see the -lpthread issue getting fixed before merging this.

I already have merge access, but haven't merged any flang commits till now. It's in now.

Yes, please. Shall I merge this? I don't know what the protocol is in merging.

Closing in favour of https://reviews.llvm.org/D81328

Works for me.

@silvas, mlir_tablegen(IR/ShapeCanonicalization.inc -gen-rewriters) is the only call in the MLIR project with a folder (IR) in it. Others look like mlir_tablegen(SPIRVEnums.h.inc -gen-enum-decls)

https://reviews.llvm.org/D81283

I was doing a CMake in-tree build of a out-of-llvm-tree flang. I can reproduce with a CMake out-of-tree build of a out-of-llvm-tree flang and fixed it here.

Use include_directories instead of target_include_directories

This commit breaks building MLIR for me. You need to create the directory IR in the build directory in mlir/lib/Dialect/Shape/CMakeLists.txt. Otherwise mlir-tblgen fails with a file not found error.

Shouldn't the solution be to suppress the warning by adding -Wno-array-bounds if GCC < 8? Or do something like

It has global effects, that is -DDEBUGF18 will be added to all LLVM projects in debug builds, not just flang

Yes, I'd like this to be merged. My email address is isuruf@gmail.com.

@mehdi_amini, after this is merged, I will make a new differential to change the default and people can argue there.
I'd really like to get this merged and this doesn't change the status quo.

@mehdi_amini, I'm sorry, what issue is this?

Simplify logic

I've added a FLANG_ENABLE_WERROR which is turned on by default on non MSVC builds.

Fix MSVC flag

Turn on -Werror by default on non MSVC platforms

On the call we proposed a compromise of keeping -Werror on by default for Flang but having a local Flang CMake flag to disable it that folks can use that. @isuruf would that unblock you and fix the issue that caused you to submit the patch originally?

Prefer compiler builtin over C++ standard library

I've only used this from clang. How do I set it using clang's gnu driver?

Not until https://reviews.llvm.org/D76997 goes in

LLVM headers need fixes to make sure they work with MSVC setting __cplusplus to anything above 201402. For eg: https://reviews.llvm.org/D76997

@tskeith, no. That can only be done in an out-of-tree build. LLVM doesn't have a mechanism to do it for a specific subproject and adding it here would mean copying that code from LLVM here.
(Using the current code in master is not desirable as the flags in master do not work for some compilers like MSVC.)

This is ready from my end. Just needs a decision on what to do about werror. My preference is to not enable it by default, but others may disagree.

That's fair. Let me know what you think should happen here.

I reverted back. After this is accepted I will make a new differential to change the default where it can be discussed.
This change allows MSVC builds to proceed further and I don't want this to be held back by a decision on the default for werror.

Revert to werror on for standalone builds

Let me know what to do here (I can revert to the commit where Werror is turned on by default to non-MSVC platforms)

If Windows, are we able to make this change conditional on Windows?

Don't enable -Werror by default even on standalone builds

Remove last change

Add option for enable exceptions and rtti

Enable pedantic on standalone build and disable werror on msvc

Remove -Wno-unused-parameter as LLVM adds it anyways

Add a new field originalMxcsr and restore it along with originalFenv

Refactor

Thanks @sscalpone for the review. Looks like originalFenv_ is still used for restoring the original state. Shall I change the type of originalFenv_ to be unsigned int on x86_64? (Or maybe a union?)
From what I understand originalFenv_ is used for changing and restoring the __mxcsr value (or its equivalents on aarch64).

Remove MSVC mentions

Use _mm_getcsr/_mm_setcsr in all x86_64