- User Since
- Oct 10 2016, 10:44 AM (153 w, 6 d)
Wed, Sep 18
@Meinersbur any feedback on this update?
Fri, Sep 13
LGTM, that's super nice!
Thu, Sep 12
Updated test case.
Wed, Sep 11
Mon, Sep 9
Sun, Sep 8
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.
Sat, Sep 7
Successfully tested on my box! I'd just use
@Hahnfeld I missed your previous answer, sorry about that
And that's what I don't understand
Fri, Sep 6
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/
Thu, Sep 5
Tue, Sep 3
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?
Wed, Aug 28
@Meinersbur patch rebased. I removed the linker trick (which only work for global variables, not function, anyway), as it's no longer needed:
Tue, Aug 27
Aug 22 2019
@Hahnfeld : I failed to reproduce the issue locally, but I assume the following patch may solve your issue:
Aug 21 2019
I guess we're suppressing the warning by rinsing the string literals through StringRef, so GCC can't see the source string size.
Aug 20 2019
Take into account @rnk's review.
The gcc analysis is not interprocedural.
Aug 19 2019
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)
Aug 10 2019
ok, it's probably a regex issue for the test, I'll check that.
Aug 2 2019
Also fix symbol redefinition during static builds on Windows
Jul 31 2019
@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
Jul 26 2019
@Meinersbur what about linking with LLVM-IR linker in your shared module?
Jul 20 2019
Jul 19 2019
Jul 18 2019
Jul 17 2019
Added a Bye project in examples/
Fixed linking of plugins into core tools
Fixed dependency issue
Jul 16 2019
Fix test requires + asan calls
Jul 5 2019
@chandlerc any chance you could have a look at this?
Jul 4 2019
Jul 3 2019
Jul 2 2019
Update test according to @kcc remark.
LGTM then, please get another feedback though, I'm not comfortable with that code area
Jul 1 2019
Jun 28 2019
Following @yln question, improve the CHECK of the associated test case
Jun 27 2019
- 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)
Jun 26 2019
@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.
Jun 21 2019
@mehdi_amini up ;-)
Jun 20 2019
Thanks @jkorous for the fast review o/
Jun 18 2019
Mostly documentation update + helper function renaming.
Jun 17 2019
Jun 13 2019
LGTM. Can you add a test case in lit/tests for that?
Jun 12 2019
Jun 11 2019
@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
Jun 8 2019
Using @beanz idea, provide an option to add_llvm_executable to declare it as receiving plugins, which provides lower coupling with actual plugins
Jun 6 2019
Jun 5 2019
@Meinersbur Itested with the following configuration
- do not set category for positional argument
remove category of positional argument
@mehdi_amini up :-)