@Meinersbur any feedback on this update?

@chandlerc / @bkramer any thought on this fix?

LGTM, that's super nice!

Updated test case.

Up :-)

Up?

We should keep tests as broad as possible to maximize the likelihood that it fails if someone breaks this (or a similar) case in the future.

Successfully tested on my box! I'd just use

@Hahnfeld I missed your previous answer, sorry about that

@Hahnfeld https://reviews.llvm.org/D67319 contains a potential fix. Can you give it a try?

And that's what I don't understand

Mmmmh the whole point of the test is to test how asan behaves when meeting a symbol like __cxa_throw in a dlopened library when the calling compilation unit is not linked against libstdc++. Previous behavior was a segfault, we should now get a reasonable error. By defining __cxa_throw in the c file, you remove the origin of the bug, so sure it works, but it no longer tests the faulty situation. Maybe tehre's a symbol defined in both libcxx and libstdc++ the same way?

@davezarzycki I tend to agree with you. We can just remove 35:44 and just keep the hostname.

Could you add some documentation, probably in docs/MIRLangRef.rst? Also you lack a test case, probably in ./CodeGen/MIR/Generic/

Is that summary correct?

@Hahnfeld : I understand your concern. However this test case is meant to test handling of stdlib exceptions, so it doesn't look strange to disable it if stdlib is not used, right? Do you know of another feature we could use?

@Meinersbur patch rebased. I removed the linker trick (which only work for global variables, not function, anyway), as it's no longer needed:

@Hahnfeld : I failed to reproduce the issue locally, but I assume the following patch may solve your issue:

I guess we're suppressing the warning by rinsing the string literals through StringRef, so GCC can't see the source string size.

Take into account @rnk's review.

The gcc analysis is not interprocedural.

Sorry for the long delay, this LGTM

Adding @hfinkel to the thread to confirm it's okay to add this behavior, as he authored an RFC on the subject (see https://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html)

@Meinersbur up!

ok, it's probably a regex issue for the test, I'll check that.

LGTM

Also fix symbol redefinition during static builds on Windows

@Meinersbur nop, forgot that one, I'll have a look, thanks for pointing that out.

Make validation more resilient depending on shared/static build.

@Meinersbur I've updated the test case to test extension point if the extension is linked in, this is not so intrusive, I'm happy with the solution.

• Test extension point registration when extension is built-in
• Correctly handle -DLLVM_LINK_LLVM_DYLIB=0
• Fix a few details

@Meinersbur what about linking with LLVM-IR linker in your shared module?

Added a Bye project in examples/
Fixed linking of plugins into core tools
Fixed dependency issue

Fix test requires + asan calls

@chandlerc any chance you could have a look at this?

Update test according to @kcc remark.

LGTM then, please get another feedback though, I'm not comfortable with that code area

@vitalybuka / @kcc : up?

Following @yln question, improve the CHECK of the associated test case

• Test added
• Comment added
• make the change more localized, closer to the origin of the issue

check-asan works just fine

@kcc tested on the bug test case and it now raises a decent error, not tested on compiler-rt test suite (yet)

@Meinersbur your comment and my devs crossed, but this should be fine. This update enables new PM static plugin support for clang, something that was lacking to polly previously. I've tested it a bit and it builds fine with static setup, still need to test it with more config.

@mehdi_amini up ;-)

Thanks @jkorous for the fast review o/

Mostly documentation update + helper function renaming.

LGTM. Can you add a test case in lit/tests for that?

@beanz : In addition to your suggested changes, I've renamed the cmake utility into add_llvm_pass_plugin to match other functions from AddLLVM.cmake

Using @beanz idea, provide an option to add_llvm_executable to declare it as receiving plugins, which provides lower coupling with actual plugins

In D61446#1532848, @Meinersbur wrote:

Just an idea: We could avoid the explicit calls to 'initializeXYZPass' in opt/bugpoint/clang by adding Polly.cpp as a source file or object library to the executables. This would guarantee that its static initializer is called without dynamic library.

@Meinersbur Itested with the following configuration

• do not set category for positional argument

remove category of positional argument

@mehdi_amini up :-)