@modocache: fixed by 8d019cda851a1031fbce3c50be0975438147f11d

@modocache : thanks for the heads up, I'm investigating the issue.

Renamed registration constructor to use a more llvm-ish name.

@MaskRay no longer a WIP ;-)

@MaskRay gentle up :-)

@MaskRay are you ok with that version?

@MaskRay

because that will cause duplicate registration of llvm::cl::opt flags.

Cleaned up code, using a few macros to avoid duplication.

@MaskRay The library version prooved to be a bad path: we wanted clang-cpp to always link to a shared library, which interacts in ungraceful ways with BUILD_SHARED_LIBS.

@grimar ok, change added to the commit.

This passes the following configurations:

Fix lto-test bugs + convert more files, still not ready for review.

Recommited as of 1454c27b60447d969d0c1ecaf20b2186fe9d85ec

LGTM

For the record: test patched by b52355f8a196b5040dc2e42870bf8c459306cfaa

Update test case, according to @efriedma suggestion.

Add a test case that exhibits the overflow in previous implementation + minor nits from @hokein

In D75057#1895550, @hokein wrote:

thanks for doing this! didn't look into details yet. Could you explain what was the bug in the previous code?

@nhaehnle : something like

Up?

@andrew.w.kaylor / @efriedma : comments taken into account.

@lhames is that okay like this?

Thanks @leonardchan

Thanks for working on this! I ran into this once and manually undefined the macro, so the workaround looks decent. However, I share @hans concerns about the detection part. You most likely want to compile minimal C++ program using std::min (and maybe other functions) to detect if the actual standard library used matches our requirements.

In D71959#1860286, @jkorous wrote:

@serge-sans-paille The test was still failing on macOS.

Obsoleted by https://reviews.llvm.org/D74878

llvm-go is still a thing, this patch is no longer needed

Fix include order

Use the <deque> approach

In D75110#1891890, @lhames wrote:

Thanks very much for this Serge!

Is the std::deque fix a one-liner? This shouldn't be very performance sensitive, so I'd be inclined to go with that.

Nice work, LGTM too.

Other copy/paste typo.

As a side note, pre-reserving the buffer size gives interesting speedup, see http://quick-bench.com/Lp6OwO2etW1YEmJayVWn3U8JDiY

Fix typo

Restore duplication, fix the bug in two separate locations.

In D74878#1889460, @jeroen.dobbelaere wrote:

Will this also give a warning when passing a .ll file to a release clang, without explicitly passing the '-fdiscard-value-names' ? Is this what we want it to be ?

@Meinersbur LGTM, thanks

As hinted by @efriedma , only remove lowering to *_finite calls in Codegen.

Let's go that way then. @xur I leave it to you to add the appropriate warning at least on the clang side? Feel free to just use the code from https://reviews.llvm.org/D74871?id=245594.

Add a configure feature test to filter out tests that depend on platform linker, as hinted by @MaskRay

For the record: http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l/builds/4749/steps/test-check-clang/logs/FAIL%3A%20Clang%3A%3Ariscv64-toolchain.c fails

@lebedev.ri maybe we should at least warn the user if there was a flag at clang level to force discarding? That's what I've been doing in https://reviews.llvm.org/D74871?id=245594

Other approach to the problem: modify Value::SetNameImpl

Finally, the test case :-)

Added test case.

In D74871#1883884, @EricWF wrote:

Why is this not a bug in w/e is handling the IR?

Take @Meinersbur review into account.

I'll revert and propose an updated patch then.

Reverted through b8bea9346af4f2644c9a1bd29710c5e3efbbd7d3

Tested without standalone build with polly linked statically and dynamically with success.