Removed undefined use of union in libminifloat#35054
Conversation
Testing showed use of memcpy produced identical assembly code.
|
The test case can be tried here |
|
Using a union to switch between bit representation is undefined behavior in C and C++. The only allowed way to do that is through When we can use C++ 20, we can switch to |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-35054/24928
|
|
A new Pull Request was created by @Dr15Jones (Chris Jones) for master. It involves the following packages:
@jpata, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
please test |
it looks like these are from #34860, but better to rerun after the new IB shows up |
|
@cmsbuild please test |
|
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-8bba71/18114/summary.html Comparison SummarySummary:
|
| } | ||
|
|
||
| private: | ||
| //in C++20 we can use std::bit_cast which is constexpr |
There was a problem hiding this comment.
is it worthwhile to fold this in #ifndef __cpp_lib_bit_cast and #include <bit> at the top if it's defined?
There was a problem hiding this comment.
I took a look at https://en.cppreference.com/w/cpp/feature_test and it seems to me like the feature test system is really meant for libraries which are meant to support many different C++ versions simultaneously. That isn't what we really do. Once we validate C++20 option for our compilers (which we haven't even started since no compiler supports all the items we might want) we will not need to compile that code with an older compiler.
So personally, I don't see a compelling reason to add 10+ lines of code (as a guess) which are only useful during the short window between the C++17 to C++20 transition. If you really want that ability, I will change the code.
There was a problem hiding this comment.
@slava77 are you 'OK' with my reasoning about not using the test feature or would you prefer them to be added to the code?
There was a problem hiding this comment.
I have a more broad question: what are we going to do with all other use cases of union?
e.g. DataFormats/Math/interface/FastMath.h, SIMDVec.h, approx_math.h
the bit decoding is also used quite extensively in DataFormats/GEMDigi, e.g. interface/GEMVFAT.h; is that part OK, or does it need to switch to memcpy as well?
There was a problem hiding this comment.
@slava77 I'm of the opinion that we should change all the uses of union for bit decoding eventually. It would be nice to have the bit_cast for that but I'd be OK with doing the memcpy.
The only place we discovered memcpy to be a problem is when used with the NVidia compiler as that one still calls the memcpy function rather than replacing it with inlined machine code. So for GPU shared code, we have to wait for the bit_cast support (in gcc/clang and ncc) before we can remove the undefined behavior.
There was a problem hiding this comment.
I was thinking that just calling memcpy in the other cases directly was how I was going to handle it. I first tried it that way here, but there was so much repetition that I switched to defining a bit_cast (which drastically simplified the code, surprisingly).
If we were to have our own bit_cast it would more likely be put in FWCore/Utilities since we've often put soon to come to std items there in the past.
There was a problem hiding this comment.
As for the other places in DataFormat/Math I'm not sure the compilers are smart enough to be able to vectorize the replacements for memcpy they use. So I'd skip those for now.
There was a problem hiding this comment.
If we were to have our own
bit_castit would more likely be put inFWCore/Utilitiessince we've often putsoon to come to stditems there in the past.
I'm certainly fine with FWCore/Utilities
There was a problem hiding this comment.
Do you want us to make the bit_cast separately for this pull request or can we wait until we see a need?
There was a problem hiding this comment.
Do you want us to make the
bit_castseparately for this pull request or can we wait until we see a need?
from #35054 (comment)
I concluded that there is a need (there just isn't another PR yet that addresses other use cases of a union).
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-35054/25010
|
|
Pull request #35054 was updated. @smuzaffar, @Dr15Jones, @makortel, @cmsbuild, @slava77, @jpata can you please check and sign again. |
|
@cmsbuild please test |
|
-1 Failed Tests: RelVals-INPUT RelVals-INPUT
Comparison SummarySummary:
|
|
+core |
|
This pull request is fully signed and it will be integrated in one of the next master IBs (but tests are reportedly failing). This pull request will now be reviewed by the release team before it's merged. @perrotta, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2) |
|
+1 |
|
merge |
PR description:
Testing showed use of memcpy produced identical assembly code.
PR validation:
Code compiles and unit test pass.