Certain floating-point constants and flags cause nominally constant initializers to be executed at runtime

[tpwrules]

I have a program which needs constant static data tables to be constant-initialized so they are available for global constructors and external parsing of the binary. This turns out to break if all of the following are true:

• The initialization also involves an expression which is not constexpr
• The flag -ftrapping-math is passed
• A double precision float literal is assigned to a single precision float member

In this case, Clang decides to initialize the data tables with zero in the binary and fill them in at runtime, which is a problem.

I don't know if this is a bug, but it's unexpected and not something GCC does. I've prepared a godbolt example which demonstrates the problem and explains how to mitigate the problem by removing one of the above factors: https://godbolt.org/z/fs8v7h1hx . But I don't think we should have to apply any mitigation and there may be an issue in the compiler.

In the broken case, the table is zero and there's a bunch of extra code:

Container::data:
        .zero   64

In the working case, the table is filled out:

Container::data:
        .quad   .str
        .quad   0
        .long   0x3ed70a3d
        .zero   4
        .zero   40

[tpwrules]

Simpler reproducer: https://godbolt.org/z/s71znvx4c . In this case the not-constexpr thing is a non-constexpr constructor instead of a reinterpret_cast.

[keinflue]

Neither of these initializations are constant expressions, so it is unspecified whether or not they are purely statically initialized.

If you want to force pure static initialization you should make the initializations constant expressions with the fixes you suggested and by adding constinit on the variable definition to let the compiler verify it (or make the variable constexpr instead).

Also, the OFFSETOF macro does have undefined behavior (well technically implementation-defined behavior), while the standard offsetof macro doesn't, though it is conditionally-supported for the non-standard-layout class. (This was changed in C++17 from undefined behavior.)

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Thomas Watson (tpwrules)

Details

I have a program which needs constant static data tables to be constant-initialized so they are available for global constructors and external parsing of the binary. This turns out to break if all of the following are true: * The initialization also involves an expression which is not constexpr * The flag `-ftrapping-math` is passed * A double precision float literal a single precision float member

In this case, Clang decides to initialize the data tables with zero in the binary and fill them in at runtime, which is a problem.

I don't know if this is a bug, but it's unexpected and not something GCC does. I've prepared a godbolt example which demonstrates the problem and explains how to mitigate the problem by removing one of the above factors: https://godbolt.org/z/fs8v7h1hx . But I don't think we should have to apply any mitigation and there may be an issue in the compiler.

In the broken case, the table is zero and there's a bunch of extra code:

Container::data:
        .zero   64

In the working case, the table is filled out:

Container::data:
        .quad   .str
        .quad   0
        .long   0x3ed70a3d
        .zero   4
        .zero   40

[tpwrules]

Thanks for the input. I found constexpr would indeed diagnose this issue.

Regarding the OFFSETOF macro, this is an old codebase from before that standard modification, thanks for the knowledge about an improvement. We still compile in C++11 mode but -ftrapping-math is the new flag in our codebase that introduced this problem.

Are there UB issues using the builtin offsetof macro in this case? Is the new definition "backported" when the compiler is using an older standard specified with -std? I tried it in our codebase and found it does not change the object code at all in either GCC or Clang, which is a good sign. I also found some existing code in LLVM's libcxx which suggests this is safe, but could not corroborate it with any documentation:

llvm-project/libcxx/include/__type_traits/datasizeof.h

Lines 38 to 46 in bada581

	// _FirstPaddingByte<> is sometimes non-standard layout.
	// It is conditionally-supported to use __builtin_offsetof in that case, but GCC and Clang allow it.
	_LIBCPP_DIAGNOSTIC_PUSH
	_LIBCPP_CLANG_DIAGNOSTIC_IGNORED("-Winvalid-offsetof")
	_LIBCPP_GCC_DIAGNOSTIC_IGNORED("-Winvalid-offsetof")
	template <class _Tp>
	inline const size_t __datasizeof_v = __builtin_offsetof(_FirstPaddingByte<_Tp>, __first_padding_byte_);
	_LIBCPP_DIAGNOSTIC_POP
	#endif // __has_extension(datasizeof)

If you can shed additional light on the above I would be grateful.

[keinflue]

Are there UB issues using the builtin offsetof macro in this case? Is the new definition "backported" when the compiler is using an older standard specified with -std?

Earlier I was referring to the standard library offsetof, not Clang's __builtin_offsetof.

The change from it having undefined behavior to being conditionally-supported if the class is not standard-layout means that the compilers now have to diagnose if they do not support it with the given class, meaning that there can't be silent unexpected behavior in these cases.

This was changed as a result of LWG issue 2709, but I am not entirely sure whether it is intended to be a defect report that applies to pre-C++17 as well. If not, then technically an implementation could still not diagnose the issue in e.g. C++11 mode and silently cause unexpected behavior, but I can't see any implementation intentionally doing that specifically for those modes when there must be a diagnostic in C++17 mode and above.

However, the standard macro still has undefined behavior if applied to a static data member or a member function. See [support.types.layout]p1.

---

It is not necessarily the case that the standard library implementation will use __builtin_offsetof for offsetof in all cases. However because that is the only way to make it work in constant expressions, which is required since C++11, in practice the standard library has to use that built-in at least sometimes and has no reason to not use it always as a consequence.

Clang comes with a <stddef.h> implementation which defines offsetof to use __builtin_offset since that file was first introduced and the equivalent file from GCC does so since 2004 (gcc-mirror/gcc@7a3ea20). The only issue could see are old or unusual libc implementations that provide their own implementation of offsetof in their own <stddef.h>. But in that case you are unlikely to get decent standard conformance anyway.

The Clang built-in itself, as far as I can tell, has always supported non-standard-layout classes (and same for GCC I suppose). There is currently still a warning seemingly implying that the use of the built-in in these cases is invalid, but that is as far as I know an issue with the diagnostic only. See #45267. Maybe @AaronBallman and @pinskia can confirm though.

[frederick-vs-ja]

The UB/ill-formedness about offsetof seems to be off-topic. In the posted examples, only standard-layout classes are invented, so you can reliably use offsetof.

Clang's -ftrapping-math seemingly blocks constant folding when an inexact floating-point literals of type double is converted to float. E.g. 0.42 triggers this issue, while 0.42f and 0.25 don't.

[jcranmer-intel]

Broadly speaking, in the non-constexpr case, we have to evaluate an expression as if at runtime, so we can only turn it into compile-time initialization if we know that the user can't tell that it didn't happen at runtime.

When you enable -ftrapping-math, you say that you care about floating-point exceptions. That means that any floating-point operation that may cause an exception--which is almost all of them--cannot be guaranteed to evaluate at compile-time. Note that converting a double of 0.42 to a float will raise the FE_INEXACT exception at runtime.

[tpwrules]

That makes sense, but I'm not sure it's the full explanation for what is happening.

For one, GCC uses -ftrapping-math by default but does not have this behavior. I am not sure if it respects FE_INEXACT? Is there a way to tell Clang I don't care about FE_INEXACT and don't have it turned on?

I also looked in the Clang manual and found -ffp-exception-behavior=maytrap which says "The compiler avoids transformations that may raise exceptions that would not have been raised by the original code. Constant folding performed by the compiler is exempt from this option.". But it made no change to the observed behavior. Does operating in non-constexpr or converting a double to a float not count as constant folding? This of course assumes "exempt" means the compiler does not care if constant folding ops may raise exceptions.

Finally, the second reproducer I posted (re-linked here) does not have value-dependent behavior. It always does runtime evaluation even for a value like 0.25, whereas the original will do the evaluation at compile time if that value is used instead of 0.42. The only difference is the thing that is non-constexpr.

[dzaima]

gcc very often just does not handle -ftrapping-math properly (or, at least, relative to what clang attempts to guarantee with that flag); e.g. float foo() { return 1.1; } would raise inexact, but gcc optimizes it out. Similar with other exceptions in void foo(float a) { a+a; } and float foo(float a) { return a-0; } etc.

this claims it having a goal of not introducing more exceptions, which would match the clang maytrap option; looks like llvm just doesn't constfold truncations (nor some other things like float foo() { return 1; }) which I think would be fine to? Which I think should count as a missed optimization. No clue if that's relevant to the whole constexpr thing though.