Closed iv-m closed 2 weeks ago
It looks like the code in to_chars_hex
assumes that if the machine has float128
, it also has a supported long double
layout. But this machine has older weird long double layout that is not supported by Boost.Charconv.
Isn't this the same as: https://github.com/boostorg/charconv/issues/182#issuecomment-2069075260? Does it still build with GNU extensions turned off? I was never able to replicate that issue. After your issues with last release I added PPC64LE to the CI battery: https://github.com/boostorg/charconv/blob/develop/.github/workflows/qemu.yml#L43, and everything seems green. Are you able to send a patch for your specific platform?
Isn't this the same as: https://github.com/boostorg/charconv/issues/182#issuecomment-2069075260?
Well, I totally forgot about that comment. Yes, it looks like it's the same issue.
Are you able to send a patch for your specific platform?
Sure. I have a quck patch. I'll send a PR after some cleanup and more testing.
Sure. I have a quck patch. I'll send a PR after some cleanup and more testing.
Thank you
FTR, I am having the same issue with the ppc64le
architecture when using gcc 11
.
As for the fix, isn't this just a matter of putting the definition of struct ieee754_binary80
outside of a conditionally compiled block that is excluded from builds under the ppc64le
architecture?
Struct ieee754_binary80
is not actually used in this case, but the code needs it regardless as it's parts of an std::conditional
, hence the first error message.
I added PPC64LE to the CI battery [...] and everything seems green
@mborland I understand that some SFINEA mechanism might allow an undeclared/undefined symbol to be present in the "unused" part of std::conditional
, but it seems this is not happening with gcc-11.
Perhaps the CI is using a different gcc version?
FTR, I am having the same issue with the
ppc64le
architecture when usinggcc 11
.As for the fix, isn't this just a matter of putting the definition of struct
ieee754_binary80
outside of a conditionally compiled block that is excluded from builds under theppc64le
architecture? Structieee754_binary80
is not actually used in this case, but the code needs it regardless as it's parts of anstd::conditional
, hence the first error message.I added PPC64LE to the CI battery [...] and everything seems green
@mborland I understand that some SFINEA mechanism might allow an undeclared/undefined symbol to be present in the "unused" part of
std::conditional
, but it seems this is not happening with gcc-11. Perhaps the CI is using a different gcc version?
The CI is running gcc-13 and clang-17 on QEMU PPC64LE since we have no native machines to test on, and it's cost prohibitive. Can you please try the patch: https://github.com/boostorg/charconv/commit/8796af49a050edc51e29a4a0bd487e4f79d13854.patch from the linked PR, and let me know if it works? The CI PPC64LE run is still showing green with the change.
Can you please try the patch: https://github.com/boostorg/charconv/commit/8796af49a050edc51e29a4a0bd487e4f79d13854.patch from the linked PR, and let me know if it works? The CI PPC64LE run is still showing green with the change.
The patch looks fine and should work. Initially I came up with something like that, only I used BOOST_CHARCONV_UNSUPPORTED_LONG_DOUBLE
, not the platform, as the condition. Unfortunately, I can give it a real try only later this week.
Meanwhile, I pushed the patch I was working on as #222. For me, it fixes build on ppc64le machine, and does not break anything on x86_64 and aarch64 machines. Can you take a look? I hope what I'm doing there makes sense in general.
Can you please try the patch: https://github.com/boostorg/charconv/commit/8796af49a050edc51e29a4a0bd487e4f79d13854.patch from the linked PR, and let me know if it works? The CI PPC64LE run is still showing green with the change.
I agree with @iv-m that it looks like it should work and I myself need some time to test, I only have access to a machine in the cloud and it'll take me a while to apply the patch there.
I'd like to point out that the fixes I've seen all rely on using conditional compilation, which I think can be avoided. Keep in mind that the code works with other versions of gcc and I think this is because the code is correct, but relies on a SFINEA mechanism that is probably not fully implemented in the gcc-11 that we find for ppc64le
. The type ieee754_binary80
is never used for such architecture, replacing it with ieee754_binary64
using preprocessor logic is not really needed as it will never be used in any case. I would suggest to just move the definition of ieee754_binary80
close to the other ieee754_*
structs, outside of any conditionally compiled block, so that all versions of gcc will be happy and no preprocess gymmicks are needed.
This is only a suggestion, I am not the maintainer of this code and I'll be ok with any changes that fixes the issue.
@fedapo, the error message in the head of this issue I've got when compiling boost 1.86.0 with gcc 13.2.1. So it's not just gcc-11 issue.
I also don't see how SFINAE would work here. The constructions like
std::conditional<true, int, NON_EXISTENT_TYPE>::type
don't compile (e.g. https://godbolt.org/z/369cbqYTG), and I don't see such compilation errors can be avoided without the preprocessor.
I also don't see how SFINAE would work here. [...] I don't see such compilation errors can be avoided without the preprocessor.
@iv-m I have not tried it, so I'm keen to believe you. My hypothesis was based on the fact that the type ieee754_binary80
should not be defined for other toolchains that still run on ppc64le
, yet without error according to what I read. In this case, I'm fine with the preprocessor, of course; it was never a strong objection in any case.
Apologies for lengthening the discussion without need.
When trying to compile Boost 1.86.0 on my ppc64le machine, I get the following error: