> Date: Mon, 22 Jan 2024 14:33:59 -0500 > From: Marek Polacek <pola...@redhat.com>
Oh, there was more... Also, I think I misinterpreted your reply as meaning that the test-case is ice-on-invalid and I wrongly replied in agreement to that misinterpretation. :) (For others at a comparable level of (lack of) C++ knowledge to me: my reading of https://en.cppreference.com/w/cpp/language/constexpr is that a constexpr function can be validly called with an expression that isn't "constexpr" (compile-time computable, immediately computable, core constant expressions or whatever the term), and the test-case is a valid example (of two such invocations). So, an expression calling such a function is only truly "constexpr" with the "right" parameters. I know this isn't C++ 102, but many of us hacking gcc aren't originally c++ hackers; that was just happenstance. I was about to write "aren't C++ hackers" but then again, C++ happened to gcc, and c++11 at that.) > On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson wrote: > The problem seems to be more about conversion so > g++.dg/conversion/reinterpret5.C > or g++.dg/cpp0x/constexpr-reinterpret3.C seems more appropriate. I briefly considered one of the cpp[0-9a-z]* subdirectories but found no rule. Isn't constexpr c++11 and therefor cpp0x isn't a good match (contrary to the many constexpr tests therein)? What *is* the actual rule for putting a test in g++.dg/cpp0x, cpp1x and cpp1y (et al)? (I STFW but found nothing.) > > +++ b/gcc/testsuite/g++.dg/expr/pr113545.C > > @@ -0,0 +1,49 @@ > > Please add > > PR c++/113545 Certainly if the test is to change name and even if not ("git grep" wouldn't catch the file name). Will do. > > + unsigned const char c = swbar(reinterpret_cast<__UINTPTR_TYPE__>(&foo)); > > + xyzzy(c); > > + unsigned const char d = ifbar(reinterpret_cast<__UINTPTR_TYPE__>(&foo)); > > I suppose we should also test a C-style cast (which leads to a > reinterpret_cast > in this case). > > Maybe check we get an error when c/d are constexpr (that used to ICE). But the expressions aren't declared constexpr, just const (as in "here 'const' means run-time evaluation due to the weirdness that is C++"). ...oh, I see what you mean, these are valid, but you suggest adding tests declared constexpr to check that they get a matching error (not ICE :) ! Thanks again for the review, I think I'll at least re-work the test-case into two separate ones. brgds, H-P
