This is an archive of the discontinued LLVM Phabricator instance.

Headers: use C++ inline semantics in C++ mode
ClosedPublic

Authored by compnerd on Dec 9 2022, 4:38 PM.

Details

Summary

When building with the 17.5.0 preview toolset for MSVC and building with modules, the definition of _addcarry_u64 and _subborrow_u64 seem to cause issues due to the use of GNU inline semantics. Change the headers to prefer C++ inline semantics for C++ compilation, falling back to GNU inlining semantics for C compilation.

This is motivated by https://github.com/microsoft/STL/issues/2520.

Diff Detail

Event Timeline

compnerd created this revision.Dec 9 2022, 4:38 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 9 2022, 4:38 PM
compnerd requested review of this revision.Dec 9 2022, 4:38 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 9 2022, 4:38 PM
compnerd edited the summary of this revision. (Show Details)Dec 11 2022, 7:34 PM
compnerd added a reviewer: fsb4000.
fsb4000 accepted this revision.Dec 12 2022, 4:56 PM

I also asked at MS STL Discord(https://discord.gg/XWanNww) about the patch.

This revision is now accepted and ready to land.Dec 12 2022, 4:56 PM

@fsb4000 is my reading correct that MSVC will look into trying to handle static inline even though it is a GNUism? I wonder if we should consider limiting the use of static inline to C mode rather than including C++. I also wonder if I can loosen it similarly to avoid the issue I'm running into (which @STL_MSFT correctly identified - modules).

Seems that this alone is insufficient as some build does run into issues, so I may need to refine this further.

compnerd requested review of this revision.Dec 14 2022, 9:40 PM
compnerd updated this revision to Diff 483081.
compnerd retitled this revision from Headers: make a couple of builtins non-static to Headers: use C++ inline semantics in C++ mode.
compnerd edited the summary of this revision. (Show Details)
fsb4000 accepted this revision.Dec 15 2022, 3:43 AM
This revision is now accepted and ready to land.Dec 15 2022, 3:43 AM

@CaseyCarter created https://github.com/microsoft/STL/pull/3285
So MSVC STL don't use <intrin0.h> with Clang now. It should fix the issues too because Clang overrides <intrin.h> (and doesn't override<intrin0.h>)

Thanks @fsb4000 (and @CaseyCarter)! I think that due to the shipped version, it makes sense to do this still. Using standard semantics in general I think is preferable, since nothing prevents another compiler implementation to still do something similar.

This revision was landed with ongoing or failed builds.Apr 20 2023, 9:03 AM
This revision was automatically updated to reflect the committed changes.
rnk added a subscriber: hans.May 8 2023, 2:52 PM

This feels to me like we are still working around some incompatibilities between the MSVC intrin.h / intrin0.h model. I would prefer it if we could always use static inline consistently in our intrinsic headers so we don't have to worry about ODR violation problems. However, we're using always_inline so there's not much to worry about anyway.

Anyway, if it comes up again, we should try to come up with a better fix. +@hans