[Bug c++/116167] New: "static_cast" of member function pointer (non-noexcept) to noexcept erroneously succeeds if not overloaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116167
Bug ID: 116167
Summary: "static_cast" of member function pointer
(non-noexcept) to noexcept erroneously succeeds if not
overloaded
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at hexadigm dot com
Target Milestone: ---
The following code correctly fails to compile based on my research (though I
can't find the passage in the standard itself so still unconfirmed), but
successfully compiles when the "Whatever" overload taking a double is commented
out (so "Whatever" is no longer overloaded). I believe it should (likely) still
fail whether overloaded or not. It does so in Clang and MSVC though in Clang
(didn't check MSVC) the error is slightly different when it's not overloaded vs
when it is but it still "correctly" fails nevertheless. Tested the scenario in
C++17, C++20 and C++23.
The issue is that the "static_cast" from a non-noexcept function to one that is
"noexcept" is illegal to the best of my knowledge (?) so it should always fail
AFAIK (the issue is a bit fuzzy however but it would be surprising if the
standard supports two different behaviors for this scenario based on whether
the "static_cast" is targeting an overloaded function or not).
class Test
{
public:
void Whatever(float)
{
}
void Whatever(double)
{
}
};
int main()
{
constexpr auto pWhatever = static_cast(&Test::Whatever);
return 0;
}
[Bug c++/116167] "static_cast" of member function pointer (non-noexcept) to noexcept erroneously succeeds if not overloaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116167 --- Comment #2 from Larry Smith --- Thanks for the quick reply. Probably a very rare scenario so a fix maybe low priority, but for my purposes the situation is required in a particular SFINAE context for an open source function traits library (https://github.com/HexadigmAdmin/FunctionTraits). Am depending on the failure to determine if a non-static member function is declared noexcept but it fails to work if the function isn't overloaded (due to the issue). Fortunately I can work around it for now (on GCC only will test if it's overloaded and defer to the "static_cast" as-is - if not overloaded I can determine if it's noexcept using other means). Thanks again.
[Bug c++/116639] New: "private" access specifier not respected in overloaded SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116639
Bug ID: 116639
Summary: "private" access specifier not respected in overloaded
SFINAE context
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at hexadigm dot com
Target Milestone: ---
Given the following code (run it at https://godbolt.org/z/cqv78Pdda), where
"Base::Whatever" is private (both overloads), GCC (incorrectly) fails to
compile when overloaded but correctly compiles when not overloaded (when you
comment out the 2nd occurrence of "Whatever"). The other two compilers I tested
both compile though Clang produces one wrong result when overloaded (I reported
the issue to them as well). MSVC appears to be correct for all cases. See the
behavior table further below (Clang first in the table since I reported it to
them first).
This appears to be erroneous behavior but it's a fuzzy area in this SFINAE
context (but a bug seems likely).
#include
#include
class Base
{
private: // Defaults to this anyway but being explicit
void Whatever(int)
{
}
/
// Compilation erroneously fails but works when
// commented out (so no longer overloaded)
/
void Whatever(int, float)
{
}
};
class Derived : public Base
{
};
template
struct HasFuncWhatever : std::false_type
{
};
template
struct HasFuncWhatever(&T::Whatever))>
>
: std::true_type
{
};
int main()
{
using T = Derived;
using U = void (int);
std::cout << std::boolalpha << HasFuncWhatever::value;
return 0;
}
Here's the behavior of the 3 compilers I tested (only MSVC presumably gets it
right):
T "Whatever" overloaded? Clang DisplaysMSVC Displays GCC
Displays
- -- ---
Base No false (correct) false (correct) false
(correct)
Base Yes false (correct) false (correct) Fails
compilation due to private access (incorrect)
DerivedNo false (correct) false (correct) false
(correct)
DerivedYes true (incorrect) false (correct) Fails
compilation due to private access (incorrect)
Unless this is explicitly mentioned in the standard somewhere, or it's
considered undefined behavior (implementation defined), the call to
"&T::Whatever" in the partial specialization of "HasFuncWhatever" should always
presumably fail since "Whatever" is private. The primary template should
therefore always kick in so the code should always display false (and since GCC
does in fact display false in the non-overloaded case but fails to compile when
overloaded it appears to be broken behavior).
[Bug c++/116639] "private" access specifier not respected in overloaded SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116639 --- Comment #1 from Larry Smith --- FYI that the behavior table I posted above is a bit long but appeared correct in the preview window when I submitted it (after expanding it using the window's sizing grip). Wrapping now occurring instead in the final posted version (there's no sizing grip in that window but copying and pasting it into a text editor still shows it correctly)
[Bug c++/116639] "private" access specifier not respected in overloaded SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116639 --- Comment #3 from Larry Smith --- Thanks for the quick turnaround (and reference to the similar issue a few years back). Appreciated. I see you also found (and cited) my Clang post. Credit for your thoroughness :)
[Bug c++/114990] New: Compiler errors in compiling a module-based app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990
Bug ID: 114990
Summary: Compiler errors in compiling a
module-based app
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at hexadigm dot com
Target Milestone: ---
Hi there,
This is a bit lengthy (code to reproduce reasonably short though) but intended
to provide sufficient detail. I'm getting numerous errors in the
(standard) header in V14.1 of GCC. It's a module-based app and the code below
is stripped down to the minimum required to demonstrate the issue (stripped
down so does nothing but should at least compile AFAIK - it doesn't). You can
run it in Compiler Explorer at https://godbolt.org/z/sh3c3TK8Y (same code
posted below but link itself relies on CMake - read on). See errors in top
executable window at latter link (targeting GCC 14.1) but compiles fine in
bottom executable window (targeting latest Clang). Also compiles in MSVC (not
shown at above link).
Note that if you simply comment out the #include statement seen
in "TypeTraits.h" OR the #include statement seen in
"CompilerVersions.h" the errors disappear.
Unfortunately I have little experience in GCC (I specialize on MSFT platforms)
and don't have my own machine set up to test the situation (in GCC) so I depend
on CMake in the Compiler Explorer environment (not too experienced with CMake
either for that matter but very experienced in C++ - modules still relatively
new to most though).
Note that the "CMakeLists.txt" file at the above link is a bit elaborate
(didn't strip that particular file down) but it handles Clang and MSVC without
issue, and should handle GCC as well (designed to assuming no errors). It does
in fact when I compile a header-based version of the app (not module-based)
which I can control via switches passed to CMake. Presumably (hopefully) it's
not a CMake issue in the module version (or perhaps some issue with Compiler
Explorer) but I don't have access to a pure GCC environment to test things
further. Someone at your end will have to (sorry) but at this point it looks
like a GCC issue.
Here's the code (5 very short files):
###
$ cat CompilerVersions.h
#ifndef COMPILER_VERSIONS
#define COMPILER_VERSIONS
// #defined in "CompilerVersions.cppm" so only when that file is building
(and no other time)
#if !defined(STDEXT_BUILDING_MODULE_COMPILERVERSIONS)
import CompilerVersions;
#define DECLARE_MACROS_ONLY
#endif
#if !defined(DECLARE_MACROS_ONLY)
#include
#endif
#endif
###
$ cat CompilerVersions.cppm
module;
#define STDEXT_BUILDING_MODULE_COMPILERVERSIONS
#include "CompilerVersions.h"
#undef STDEXT_BUILDING_MODULE_COMPILERVERSIONS
export module CompilerVersions;
###
$ cat TypeTraits.h
#ifndef TYPETRAITS
#define TYPETRAITS
#include "CompilerVersions.h"
// #defined in "TypeTraits.cppm" so only when that file is building (and no
other time)
#if !defined(STDEXT_BUILDING_MODULE_TYPETRAITS)
#include
import TypeTraits;
#endif
#endif
###
$ cat TypeTraits.cppm
module;
#define STDEXT_BUILDING_MODULE_TYPETRAITS
#include "TypeTraits.h"
#undef STDEXT_BUILDING_MODULE_TYPETRAITS
export module TypeTraits;
###
$ cat Main.cpp
#include "TypeTraits.h"
int main()
{
return 0;
}
I'm not sure what the command line is to compile the above code directly in GCC
(again, not a GCC developer - some should verify it) but presumably the
following or something similar (or all consolidated into one command if doable,
but would have to research it):
Compile the module interface units:
$ g++ -std=c++20 -fmodules-ts --module-interface -c CompilerVersions.cppm -o
CompilerVersions.o
$ g++ -std=c++20 -fmodules-ts --module-interface -c TypeTraits.cppm -o
TypeTraits.o
Compile the main program:
$ g++ -std=c++20 -fmodules-ts Main.cpp CompilerVersions.o TypeTraits.o -o Main
In Compiler Explorer itself (again, where I'm using CMake instead), many errors
result in but I'd expect the same or similar errors when running
the above GCC commands directly (TBD). Some of them are redefinition errors
which is suspicious given the nature of headers and modules in the same app. To
this end, and I have no idea if it actually has anything to do with the
problem, the "import CompilerVersions;" statement seen in "CompilerVersions.h"
does wind up in the global module fragment section of "TypeTraits.cppm" (where
headers normally go, not import statements), so I'm wondering if that has
something to do wi
[Bug c++/114990] Compiler errors in compiling a module-based app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990 --- Comment #2 from Larry Smith --- Thanks for the (very) fast turn-around (!). I'll look into the situation over the coming days and reply further (so if you can keep the issue alive for now, thanks). Just briefly though, can you (or anyone) confirm that the "include-after-import" issue you cited as the probable cause will be rectified eventually or is the situation permanent. Thanks again (appreciated).
[Bug c++/113129] New: "using declaration" not detected as "exported" in exported namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129
Bug ID: 113129
Summary: "using declaration" not detected as "exported" in
exported namespace
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: admin at hexadigm dot com
Target Milestone: ---
Hi there,
See https://godbolt.org/z/MdToP8nP8 for a demo (self-explanatory and very
short). GCC version fails in top window (see error there), while Clang succeeds
in bottom window (also succeeds in MSVC - haven't test any others).
Issue is that the "using" declaration seen in "Consts.cppm" compiles
successfully but the variable being declared ("Test_v") isn't being exported
even though its "Const" namespace is exported. "Test_v" is therefore
inaccessible to any client that imports the "Consts" module (resulting in the
GCC compiler error seen in the top window).
I don't see any obvious reason why it shouldn't compile however unless it's a
GCC bug (but like so many I'm new to modules and this particular construct is a
fuzzy area - maybe Clang and MSVC got it wrong but read on).
Please note that this technique is very useful since it allows existing C++
headers to be easily used in C++ modules without any changes to the headers
themselves (so correcting it would be highly desirable to many). Users
therefore have the choice to either #include the existing header ("Consts.h" in
this example) or import the module instead ("Consts" in this example). The
module just defers to the header itself by applying "using" declarations as
seen in this example (to export whatever it needs from the header, in this case
"Test_v").
[Bug c++/113129] "using declaration" not detected as "exported" in exported namespace (C++ modules)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129 --- Comment #2 from Larry Smith --- @Andrew Thanks for the feedback. I don't work in Unix-like environments though normally (including Linux) so CMake, make, and shell commands are something I rarely work with (I specialize on Microsoft platforms). TBH I don't have the time to look into it and the equivalent Microsoft code wouldn't be appreciated for GCC I assume (only working with GCC now as the author of https://github.com/HexadigmSystems/FunctionTraits which is platform neutral so it targets GCC among others). The issue is very simple though and the test code very short. The Compiler Explorer link should suffice IMHO unless someone more experienced than myself on GCC wants to attach those few files in the format you've requested (whatever is most appropriate in this forum). Thanks
[Bug c++/113129] "using declaration" not detected as "exported" in exported namespace (C++ modules)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129 --- Comment #3 from Larry Smith --- UPDATE: This issue is presumably the same as this (didn't come across it when I searched for any similar bugs prior to posting): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109679 Agree with Nicolai Josuttis in above post however, issue is important to fix (modules still under development in GCC presumably).
[Bug c++/109679] export using for functions does not work as specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109679 Larry Smith changed: What|Removed |Added CC||admin at hexadigm dot com --- Comment #3 from Larry Smith --- Likely the same issue I reported here (didn't see yours before posting): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113129
[Bug c++/116167] "static_cast" of member function pointer (non-noexcept) to noexcept erroneously succeeds if not overloaded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116167
--- Comment #3 from Larry Smith ---
Just a follow-up (discovered since original post), if the function in question
is inherited then the issue disappears:
class BaseClass
{
public:
// Same as example in my original post but now
// inherited so "static_cast" below successfully
// fails compilation (unlike original example where
// it wasn't inherited - move this back to class
// "Test" below that is and it erroneously succeeds
// compilation as per my original post)
void Whatever(float)
{
}
};
class Test : public BaseClass
{
public:
};
int main()
{
constexpr auto pWhatever = static_cast(&Test::Whatever);
return 0;
}
