@chh I had a chance to try out your proposed changes. It's not causing us any trouble. In fact, __gcov_flush() is not even used at all (at least in LLVM 5.0.1).. I can recompile llvm, compiler_rt and clang and re-run all the tests with __gcov_flush commented out! No problem.

@sylvestre.ledru Thanks for the test!

Autodesk would also like to see this fix merged into LLVM 5.0.1 and we also agree about the importance of having a regression tests.

Abandoning this review. The fix has been submitted to the LLVM trunk (6.0 at this time) as r310522. Moreover, we will soon move to LLVM 5.0...

Just to let you know that I've requested commit access.

I will update this code review once https://reviews.llvm.org/D34448 is approved and submitted.

Re-organized and simplified test cases to address code review comments.

In D34448#792170, @tejohnson wrote:

Thanks and very thorough testing! I'm not sure all these combinations are needed though, I have some suggestions on paring it down. Once that is done, LGTM. Do you want me to commit for you, or did you want to get commit access?

Converted tests to use lit, llvm-link and FileCheck instead of being written as unit tests

Converted the test cases to Lit + llvm-link + FileCheck (instead of unit tests).

@zturner : Would you mind committing on my behalf ? (I don't have commit access...)

Delete the formatv_object copy constructor as suggested @zturner.

I wonder the exact same thing! We have no use for a copy constructor ourselves. Maybe, it's safer to delete it for now. We can always re-introduce it back if a clear need shows up.

Closing. This patch is now irrelevant.

I have run the entire LLVM & Clang regression test suite on OS X (both Debug & RelWithDebInfo) to ensure that no regressions were introduced.

Patch against llvm trunk revision 305867.

Thanks Lang, I will investigate some more next week. I'd like to go to the bottom of this issue and understand it thoroughly.

Wow! Thanks so much... I am downloading your proposed patch and testing it out inside our product on Windows 7, 8 and 10...

Thanks guys for the comments. I will experiment a little bit more and come back once I have a better understanding. It might also be a difference between the behaviour of the COFF vs ELF object files under Windows.

Adding Lang to the review so that he can comment on the MCJIT requirements...

majnemer wrote:

I'm a little confused here.

For example, in the x86_64 small code model, one call only use the 32-bit PC relative call to make calls within the same DLL. When calling a function residing in a different DLL, one still has to use a 64-bit safe relocation, which amount to either loading the 64-bit address directly, loading it for a GOT table or jumping to a PLT stub containing the 64-bit call.

AFAIU, the code model isn't imposed by the OS. One can use DLLs compiled with either code model on any versions of Windows. One chooses the code model for each DLL depending on whether he's expecting particular sections (.data and .text) of the DLL to be larger than 2^^24 bytes.

I believe that this should be performed in all memory models.

ping

Committed as http://llvm.org/viewvc/llvm-project?rev=226830&view=rev

No, I don't have direct commit access to the llvm repository. Would "arc land" work once the revision is approved ? (I'll be watching the build bots afterward...)

Added a FIXME notice as suggested by Rafael.

ping

ping

Thanks for taking the time to answer. My comment was by no-mean implying that I was requesting any immediate code change. I completely agree, as I mentioned, in my original comment, that calling report_fatal_error() is infinitely better than crashing on segfault.

Hi Everyone,

Let me know if your agree with the proposed solution or if an other approach would be more appropriate. I am willing to implement any suggested changes,

I will recreate a new review for this change. It got mixed up with an "arc diff" that was wrongly uploaded. Sorry for the noise. Beginner error...

Let me know if your agree with the proposed solution or if an other approach would be more appropriate. I am willing to implement any suggested changes,