[Bug c++/109294] New: Inconsistent exp function implementations for compile time and run time evaluation
jdavidpeter at gmail dot com
gcc-bugzilla@gcc.gnu.org
Mon Mar 27 09:54:56 GMT 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109294
Bug ID: 109294
Summary: Inconsistent exp function implementations for compile
time and run time evaluation
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jdavidpeter at gmail dot com
Target Milestone: ---
Created attachment 54764
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54764&action=edit
Raw and preprocessed source file reproducing the problem on WSL Ubuntu 20.04.5
LTS
Implementation for exp function provides different results for certain inputs
based on whether the call is evaluated compile time (e.g. constexpr) or
runtime.
Refer to the GodBolt link in PS as well as the attached, raw and preprocessed
source.
# System info:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.5 LTS
Release: 20.04
Codename: focal
$ g++ --version
g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# Repro steps:
g++ bug.cpp -O0 -save-temps -o O0
g++ bug.cpp -O3 -save-temps -o O3
$ ./O0
d9bd1a4d
d9bd1a4d
d9bd1a4e
$ ./O3
d9bd1a4d
d9bd1a4e
d9bd1a4e
In the example, there are 3 calls to exp with the same input.
1. The first will always use the runtime implementation due to the volatile
keyword on the variable.
2. The second uses runtime implementation in -O0 and compile time in -O3.
3. The third always uses compile time implementation based on the GodBolt
assembly.
Based on the calls, the same binary will provide different results for use case
1 vs 3 which is a bug.
Also, the result will be different for use case 2 in -O0 and -O3, which is also
a bug.
I also question if the third call should be always optimized to a registry
operation instead of calling the actual runtime exp.
However, I didn't find any documentation on optimizations done in -O0, so this
might be intentional.
Would be less of a problem if the compile time and runtime implementation would
yield the same input.
This bug also manifests in gcc12.
This isn't an issue for clang 16.0.
PS:
https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYTStJg1DIApACYAQuYukl9ZATwDKjdAGFUtAK4sGIAGwAnKSuADJ4DJgAcj4ARpjEIGYAHKQADqgKhE4MHt6%2BAcEZWY4C4ZExLPGJKbaY9qUMQgRMxAR5Pn5BdQ05za0E5dFxCUmpCi1tHQXdEwNDldVjAJS2qF7EyOwcAPQ7ANQAKgCeaZj7x%2BvE%2B2hY%2BwgJmKT7JPu0qEzo%2B4b7mKqsaXoADoTBoAILmADMEWQ3juJkhbicE2ImFYCOwoIhZmhDFhXnhiOQLCYBAQGKxUJhcPOCKRmQp4KxXiyRn2zDYCjSTC2%2Bwm6ARViZTJxWBokX2AEkoso5Id9gBaDSqLhAzBcSGQqjJJhmTAafxmSRpBWSSnggBuqDwXzSxAiBAAEn8IOh1rF6PtVMt9iYAOxCsH7YM3dYEX2Iun3P4RtxR1EOhJ2zAEAD6ogmdK8DCywEiArM/gxEG9sajrlogspfoAIuawQ79iSIhBltXA1iQ/srQZHJ63V4Pece6S6JhJQw0l5wwia1KZXKq%2BCuwOh/sIlOZ5C59LZYclxDlyHV56/mlUyO%2B%2BPJ9OI3OzxBL2OJ5u25DAyv3afVOeN7fZ78P4QH%2BBBvh%2Bx5fucZ6prucp3oBaQQLBhxgfWXZ2g6zqqBA0FPvQL7TmB%2Bx7PsbhiLQCj7EQ%2BzENmjhsOuLCApgbCCKOAidiGGGCFhOE/qmIFESRZG0BRVGoKGTFjlReAMbJzGsS0jTrgwioAPKQs8tGCLJ5zyfQinsapETqRonHBtxToutByFCQcYK0AA7kwxyUaIomUdRaBSZ69F6UxBmMEpORoSGJEAEqYAoXi0OG/DXN5aTSX53wMF82kpfpLFBUZLxUAh3yoipaA5ngExBSCwpBiGqIEBsqlme%2B1Y1hwqy0JwACsvB%2BBwWikKgnBxpY1h8lcvJQjwpAEJorWrAA1iAmpApqK2rWt/j6JwkjdTN/WcLwCggBoU0zascCwDAiAoKgPkJOQlCJWOiTAFwZhmKQWAWngWwAGp4JgjlqWcPWTTQsUJIdECxLtsQRK0xycJNsPMMQxxqbE2iYA4iO8N5ilqQwtAI71vBYCSRjiCTH14KiDh4BaUW7X8WPTtsfWJu1VO0HgsTEPDHhYLtBD2iwOOrFQBjAAof0A0DjA4zIggiGI7BSIr8hKGou26Fw%2BiGMY1jWPoPOHZAqyoGkjSHRwCpqX1dhY40LhpdMfi62EETDFUoy68U2QCK7eh%2B40CwjIkusO3TAj9FMnidHokeNDHgye4sPu2JM7RxwUEeZ6H3vh6sChjarbWdTtVMDRwXrJP4Cr%2BJI%2BzAMgyD7K9QJmPsEC4IQrwTcsvDTSTyzzUkHWbRw22kKL/jJECUgaB1ySBB1QRcP4XAaLrPV9VXB1HSdw%2BkOdV1hpu90QI99DEFErDbKotf143zet%2B3Zi8Jg%2BBEPa6B6PwSvuVVtIf%2BGsVDqCpjrUgjk%2BZpDFhPLqpAd68Crmpacm48o1zrg3JuLc25mA7l3Dwt1rj90HqdVYDxPijFbBPKeotISqmSB1QIkhN6SEhBoZIkJghIL2hwfex0h5aBHqQBaS01oSJWhtTmkIK6732ofYRx9LonwgEgK%2Bd0KCXxukla%2BIAXpvQ%2BpgL6v1/qA2BgrMGBAIaUGhlTZG8MFYONRujTG2NuC4xuvjQmxM%2Bpk31pTPxNNHb00ZlTZmyBWa7Q5rtbmvN%2BYYDZoPEWcCJZMCljLcx8sPHq2VuINWIDFBgO1kkPWRgUCG0sMbWIpsaEWytpwW2sieghOcDhF22c3YhDSvnJYvtMj%2B1yJ0oOAyQ6pzDgneorSmiZ0DhHKZUcZnzHGQXBOszhm52WRUCZXAi4lwkGXDgCDeFV0wU/HBr98Gd27l/PuOJdlkOHqPcRkiJHSK2rwGec8NBmD9GYTeyRkjsI6pCP00gTkKMOoI06yj4BqJAGfacF8NE3zvpwB%2BWDn64Lfh/W5P8/6yDyUA9WRStYQNKdApgsCPGHOObtFBaDbyoHyhi85L88EEIgEQ3RCRfQ4jMAPRRs1SCUKwIkGhnM6GLVVIEP5fpl5cC4KvSQhoNoQv4bYA%2BQjhViMhMtV560J7NPVY84Rhz36IPpQo7VIiGbECyM4SQQA%3D%3D%3D
More information about the Gcc-bugs
mailing list