[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #13 from Patrick Palka --- Fixed for GCC 12
[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681 --- Comment #12 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:2793af17db239429ea3a2e26834e74daa6cff2c0 commit r12-6285-g2793af17db239429ea3a2e26834e74daa6cff2c0 Author: Patrick Palka Date: Thu Jan 6 10:42:50 2022 -0500 c++: Add testcase for recently fixed PR [PR69681] Fixed ever since r12-6188. PR c++/69681 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-compare2.C: New test.
[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681 Andrew Pinski changed: What|Removed |Added Severity|normal |major
[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681 --- Comment #11 from Andrew Pinski --- *** Bug 102267 has been marked as a duplicate of this bug. ***
[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681 Andrew Pinski changed: What|Removed |Added Blocks||55004 --- Comment #10 from Andrew Pinski --- This is starting to get more duplicates because of lamdbas and C++11 and constexprs. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 [Bug 55004] [meta-bug] constexpr issues
[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681 Andrew Pinski changed: What|Removed |Added CC||johelegp at gmail dot com --- Comment #9 from Andrew Pinski --- *** Bug 102249 has been marked as a duplicate of this bug. ***
[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681 Andrew Pinski changed: What|Removed |Added CC||ldalessandro at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 101155 has been marked as a duplicate of this bug. ***
[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681 --- Comment #7 from Jonathan Wakely --- There's no need to determine the addresses, only the truth of the inequality. The standard says distinct functions have distinct addresses. Yes, linker trickery can break that, but it's reasonable to rely on it because it's guaranteed by the standard. Code that cares about addresses of functions (typically when registering callbacks) is unlikely to care about comparing addresses of builtins or functions in libgcc, only for user code.
[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681 Georg-Johann Lay changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #6 from Georg-Johann Lay --- (In reply to Patrick Palka from comment #3) > Either way, such code still fails to compile. I still don't see how the compiler could determine the addresses of functions as they are only determined at link time. Just suppose functions drawn from a library or where you are def'ing symbols in the linker description file or by means of -Wl,--defsym,foo=bar. There are even cases where functions with different prototypes reside at the came address (because the functions are built-in, their implementation is in libgcc and the compiler knows that the binary code is exactly the same even though the prototypes are not. The avr back-end has an example of this, cf. PR78562 for an example). So even if there are situations where such expressions can be folded to a compile time constant, this is not possible in general. If an application relies on this, it's likely to have a design problem.
[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-16 Ever confirmed|0 |1 --- Comment #5 from Jonathan Wakely --- I agree that it's a bug in C++, but for C a conforming implementation is allowed to accept it, but not required to.
[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681 --- Comment #3 from Patrick Palka --- (In reply to Andrew Pinski from comment #2) > I don't think "(int)( != )" is a valid constant integer expression > in either C or C++. (definitely not in C). This is why GCC rejects it. Oops, good point. It is not a valid integer-constant-expression, but from what I read it is a valid constant-expression, in both C and C++. Thus, instead of doing int x[(int)( != )]; to check that the comparison evaluates to a constant, it is more correct to do const int x = != in the C frontend, and constexpr int x = != in the C++ frontend. Either way, such code still fails to compile.
[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681 --- Comment #2 from Andrew Pinski --- I don't think "(int)( != )" is a valid constant integer expression in either C or C++. (definitely not in C). This is why GCC rejects it.
[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- C requires that the bound of an array with static or thread storage duration with be an integer constant expression (this is in 6.7.6.2) whose subexpressions exclude the address expression (among many others). I suppose the code could be accepted in C as an extension (as Clang does), though I'm not sure I see the use case. I haven't read the C++ parts very carefully but based on a quick check it does look like it allows the array size to be a converted constant expression which include functions, so it seems the code is valid in C++ (I'd say regardless of whether the functions are defined).
[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69681
--- Comment #1 from Patrick Palka ---
(Sorry about the typos in the original comment. To fix them,
s/since both foo and bar/since both foo and bar are/
s/when comparing and pointers/when comparing pointers/
s/the subsequent declarations/then subsequent declarations/)
An interesting case is:
__attribute__ ((weak)) void foo () { }
void bar () { }
int x[(int)( != )];
Where just one of the functions is declared weak. Could foo be defined in
another CU as
__attribute__ ((alias ("bar")) void foo () { } ?
Apparently not, since the symbol being aliased must be defined in the same CU
as the alias. So I think " != " could be folded if only one of the
functions is declared weak.
