Skip to content

[libcxx] [test] Fix odr_signature tests with optimizations enabled #144317

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

mstorsjo
Copy link
Member

@mstorsjo mstorsjo commented Jun 16, 2025

If optimization is enabled, the inline f() function actually gets inlined, meaning that the functions tu1() and tu2() trivially return 1 and 2, instead of actually referencing the potentially linker deduplicated function f(), which is what the test tries to test.

Therefore, this test previously actually failed to test what it was supposed to test, if optimization was enabled.

Mark the inline functions with TEST_NOINLINE to make sure that they don't get inlined even with optimizations enabled.

Also update the TODO comments to explain why we have an XFAIL for msvc mode here.

This avoids these tests unexpectedly passing if building in msvc mode, with optimizations enabled
(-DLIBCXX_TEST_PARAMS="optimization=speed").

@mstorsjo mstorsjo requested a review from a team as a code owner June 16, 2025 08:48
@llvmbot llvmbot added the libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi. label Jun 16, 2025
@llvmbot
Copy link
Member

llvmbot commented Jun 16, 2025

@llvm/pr-subscribers-libcxx

Author: Martin Storsjö (mstorsjo)

Changes

If optimization is enabled, the inline f() function actually gets inlined, meaning that the functions tu1() and tu2() trivially return 1 and 2, instead of actually referencing the potentially linker deduplicated function f(), which is what the test tries to test.

Therefore, this test previously actually failed to test what it was supposed to test, if optimization was enabled.

Mark the inline functions with __attribute__((noinline)) to make sure that they don't get inlined even with optimizations enabled.

Also update the TODO comments to explain why we have an XFAIL for msvc mode here.

This avoids these tests unexpectedly passing if building in msvc mode, with optimizations enabled
(-DLIBCXX_TEST_PARAMS="optimization=speed").


Full diff: https://github.com/llvm/llvm-project/pull/144317.diff

2 Files Affected:

  • (modified) libcxx/test/libcxx/odr_signature.exceptions.sh.cpp (+3-3)
  • (modified) libcxx/test/libcxx/odr_signature.hardening.sh.cpp (+5-5)
diff --git a/libcxx/test/libcxx/odr_signature.exceptions.sh.cpp b/libcxx/test/libcxx/odr_signature.exceptions.sh.cpp
index 6bf60b5e82d3c..8bc7f6cffbd0c 100644
--- a/libcxx/test/libcxx/odr_signature.exceptions.sh.cpp
+++ b/libcxx/test/libcxx/odr_signature.exceptions.sh.cpp
@@ -6,7 +6,7 @@
 //
 //===----------------------------------------------------------------------===//
 
-// TODO: Investigate
+// ABI tags have no effect in MSVC mode.
 // XFAIL: msvc
 
 // Test that we encode whether exceptions are supported in an ABI tag to avoid
@@ -21,14 +21,14 @@
 // -fno-exceptions
 #ifdef TU1
 #  include <__config>
-_LIBCPP_HIDE_FROM_ABI inline int f() { return 1; }
+_LIBCPP_HIDE_FROM_ABI __attribute__((noinline)) inline int f() { return 1; }
 int tu1() { return f(); }
 #endif // TU1
 
 // -fexceptions
 #ifdef TU2
 #  include <__config>
-_LIBCPP_HIDE_FROM_ABI inline int f() { return 2; }
+_LIBCPP_HIDE_FROM_ABI __attribute__((noinline)) inline int f() { return 2; }
 int tu2() { return f(); }
 #endif // TU2
 
diff --git a/libcxx/test/libcxx/odr_signature.hardening.sh.cpp b/libcxx/test/libcxx/odr_signature.hardening.sh.cpp
index 0dc280bf28182..e2ea6bf4a597a 100644
--- a/libcxx/test/libcxx/odr_signature.hardening.sh.cpp
+++ b/libcxx/test/libcxx/odr_signature.hardening.sh.cpp
@@ -6,7 +6,7 @@
 //
 //===----------------------------------------------------------------------===//
 
-// TODO: Investigate
+// ABI tags have no effect in MSVC mode.
 // XFAIL: msvc
 
 // Test that we encode the hardening mode in an ABI tag to avoid ODR violations
@@ -24,28 +24,28 @@
 // fast hardening mode
 #ifdef TU1
 #  include <__config>
-_LIBCPP_HIDE_FROM_ABI inline int f() { return 1; }
+_LIBCPP_HIDE_FROM_ABI __attribute__((noinline)) inline int f() { return 1; }
 int tu1() { return f(); }
 #endif // TU1
 
 // extensive hardening mode
 #ifdef TU2
 #  include <__config>
-_LIBCPP_HIDE_FROM_ABI inline int f() { return 2; }
+_LIBCPP_HIDE_FROM_ABI __attribute__((noinline)) inline int f() { return 2; }
 int tu2() { return f(); }
 #endif // TU2
 
 // debug hardening mode
 #ifdef TU3
 #  include <__config>
-_LIBCPP_HIDE_FROM_ABI inline int f() { return 3; }
+_LIBCPP_HIDE_FROM_ABI __attribute__((noinline)) inline int f() { return 3; }
 int tu3() { return f(); }
 #endif // TU3
 
 // No hardening
 #ifdef TU4
 #  include <__config>
-_LIBCPP_HIDE_FROM_ABI inline int f() { return 4; }
+_LIBCPP_HIDE_FROM_ABI __attribute__((noinline)) inline int f() { return 4; }
 int tu4() { return f(); }
 #endif // TU4
 

Comment on lines +9 to 10
// ABI tags have no effect in MSVC mode.
// XFAIL: msvc
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably document that we're not providing our per-TU guarantees on MSVC?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we should do that somewhere, yes.

@@ -21,14 +21,14 @@
// -fno-exceptions
#ifdef TU1
# include <__config>
_LIBCPP_HIDE_FROM_ABI inline int f() { return 1; }
_LIBCPP_HIDE_FROM_ABI __attribute__((noinline)) inline int f() { return 1; }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's use TEST_NOINLINE instead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, can do. These test files don't include anything before the #ifdef TU*, where we manually include <__config>, does it disturb something of that setup if we include "test_macros.h" globally before this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why it's this way in the first place TBH. I don't think it'll make a difference.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, changed to TEST_NOINLINE with an include of "test_macros.h" now.

If optimization is enabled, the inline `f()` function actually gets
inlined, meaning that the functions `tu1()` and `tu2()` trivially
return 1 and 2, instead of actually referencing the potentially
linker deduplicated function `f()`, which is what the test tries
to test.

Mark the inline functions with `TEST_NOINLINE` to make sure that
they don't get inlined even with optimizations enabled.

Also update the TODO comments to explain why we have an XFAIL for
msvc mode here.

This avoids these tests unexpectedly passing if building in
msvc mode, with optimizations enabled
(`-DLIBCXX_TEST_PARAMS="optimization=speed"`).
@mstorsjo mstorsjo force-pushed the libcxx-test-odr-signature branch from 8dc0e86 to 78b157b Compare June 16, 2025 09:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants