[Bug libstdc++/78905] Add a macro to determine that the library is implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905 --- Comment #9 from Matt Clarkson --- (In reply to Jonathan Wakely from comment #7) > GCC 7 now defines _GLIBCXX_RELEASE (with the same value as __GNUC__ has, > i.e. the GCC major version, as an integer constant, but defined by the > library headers not the compiler). > > If that macro is present you have a version of libstdc++ that provides a > working . To be really sure you could check it's defined to a value > >= 5, in order to handle (hypothetical) unofficial 4.7 or 4.8 builds that > have the patch backported. Sweet! Will update the snippet on Stack Overflow. Thank you for this, you the man ;)
[Bug libstdc++/78905] Add a macro to determine that the library is implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905 --- Comment #4 from Matt Clarkson --- That's OK. I'm not particularly looking for the macro to be backported to 4.9. Just as we move forward the new macro is available. If not it's not the end of the world I can always maintain the snippet internally.
[Bug libstdc++/78905] New: Add a macro to determine that the library is implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905 Bug ID: 78905 Summary: Add a macro to determine that the library is implemented Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mattyclarkson at gmail dot com Target Milestone: --- libstdc++ 4.7 and 4.8 shipped with a incomplete implementation. Detecting this is a bit of a pain. I did my best to attempt a detection snippet with: #include #if __cplusplus >= 201103L && \ (!defined(__GLIBCXX__) || (__cplusplus >= 201402L) || \ (defined(_GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMIT) || \ defined(_GLIBCXX_REGEX_STATE_LIMIT))) #define HAVE_WORKING_REGEX 1 #else #define HAVE_WORKING_REGEX 0 #endif This uses internal macros that are not guaranteed to exist. Would it be possible to include a _GLIBCXX_REGEX_IMPLEMENTED (or similar) that would be supported in future versions of the library so that the snippet can be updated so that it doesn't break for future versions of the library? I wrote a more lengthy description of the solution on stackoverflow: http://stackoverflow.com/a/41186162/192993
[Bug libstdc++/78905] Add a macro to determine that the library is implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905 --- Comment #2 from Matt Clarkson --- Because wehen I compile with clang against the libstdc++ the problem will still occur and __GNUC__ will not be defined. This happens on any distro where GCC is the default but ships clang as an alternative compiler.
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
Matt Clarkson mattyclarkson at gmail dot com changed:
What|Removed |Added
CC||mattyclarkson at gmail dot com
--- Comment #12 from Matt Clarkson mattyclarkson at gmail dot com ---
Did that patch resolve this bug? I'm using MinGW-builds-4.8.1-x64-posix-seh
and building a project and ended up with the following error:
value.hpp:33:31: error: external linkage required for symbol
'_ZTIN3udp8keystone6binary9arguments5ValueIZNS1_4Main17GetParsedArgumentERKSsE5DummyEE'
because of 'dllexport' attribute class UDP_KEYSTONE_DLL_PUBLIC Value final :
public ValueBase {
Which translates to missing 'dllexport' attribute on 'typeinfo for
udp::keystone::binary::arguments::Value'
But both my Value class and ValueBase classes are marked with
'UDP_KEYSTONE_DLL_PUBLIC' that expands to '__attribute__((dllexport))'
If this is a similar bug and not my error (which I presume it is) I will
resolve a test delta.
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068 --- Comment #13 from Matt Clarkson mattyclarkson at gmail dot com --- Created attachment 30814 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30814action=edit missing dllexport on typeinfo output Added an attachment for the full compiler output.
[Bug c++/57588] New: [C++11][constexpr] static constexpr in class fails to link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588
Bug ID: 57588
Summary: [C++11][constexpr] static constexpr in class fails to
link
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mattyclarkson at gmail dot com
The following code, links in optimisation modes but not others:
#include iostream
///
class Literal {
private:
Literal() = delete;
Literal(const Literal) = delete;
Literal(Literal) = delete;
Literal operator=(const Literal) = delete;
Literal operator=(Literal) = delete;
~Literal() = default;
public:
constexpr Literal(const int i);
public:
constexpr operator int() const;
private:
int int_;
};
constexpr Literal::Literal(const int i) : int_(i) {};
constexpr Literal::operator int() const {
return int_;
}
///
class Test {
private:
Test(const Test) = delete;
Test(Test) = delete;
Test operator=(const Test) = delete;
Test operator=(Test) = delete;
~Test() = default;
public:
static constexpr const Literal kLiteral = Literal(99);
public:
constexpr Test();
public:
constexpr operator int() const;
private:
int int_;
};
constexpr Test::Test() : int_(kLiteral) {};
constexpr Test::operator int() const {
return int_;
}
///
int main() {
std::cout Literal(15) std::endl;
std::cout Test() std::endl;
return 0;
}
Has some odd compilation on my machine:
[matt test] uname -a
Linux office.acer-m5810 3.8.13-100.fc17.x86_64 #1 SMP Mon May 13 13:36:17 UTC
2013 x86_64 x86_64 x86_64 GNU/Linux
[matt test] g++ -std=c++11 test.cpp -o test -O0 -g ./test
/tmp/ccZtV9ku.o: In function `Test::Test()':
/home/matt/test/test.cpp:51: undefined reference to `Test::kLiteral'
collect2: error: ld returned 1 exit status
[matt test] g++ -std=c++11 test.cpp -o test -O1 -g ./test
15
99
[matt test] g++ -std=c++11 test.cpp -o test -O2 -g ./test
15
99
[matt test] g++ -std=c++11 test.cpp -o test -O3 -g ./test
15
99
However, on gcc.godbolt.org and ideone.com I cannot get the same compilation
error with 4.7.2. I'm assuming I'm not being a donkey and doing something
against the standard? :/
If I can help with any debugging, please ask.
[Bug c++/57588] [C++11][constexpr] static constexpr in class fails to link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588 --- Comment #3 from Matt Clarkson mattyclarkson at gmail dot com --- Thanks for that link, its very informative :) I can see why it fails to link now. About the private destructor, I'd expect it to not compile, but it does. I actually didn't even realise I'd made it private as I was just hacking together a quick testcase. Is that a bug?
[Bug c++/55942] [C++11] sorry, unimplemented: calling a member function of the object being constructed in a constant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55942 Matt Clarkson mattyclarkson at gmail dot com changed: What|Removed |Added CC||mattyclarkson at gmail dot ||com --- Comment #1 from Matt Clarkson mattyclarkson at gmail dot com 2013-05-07 17:04:11 UTC --- I just came across this too.
[Bug libstdc++/57158] New: std::list.erase(const_iterator pos) not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57158
Bug #: 57158
Summary: std::list.erase(const_iterator pos) not implemented
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mattyclark...@gmail.com
#include list
int main() {
std::listint list;
list.emplace_back(15);
list.emplace_back(14);
list.erase(list.begin()); // OK
list.erase(list.cbegin()); // Not implemented
return 0;
}
As per 23.3.5.4 of the standard.
The other containers need implementations too.
Not the end of the world and it might be already on your roadmap for the
library.
[Bug libstdc++/57158] std::list.erase(const_iterator pos) not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57158 --- Comment #3 from Matt Clarkson mattyclarkson at gmail dot com 2013-05-03 12:21:22 UTC --- Thanks, glad it's been reported.
[Bug libstdc++/57047] New: [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57047
Bug #: 57047
Summary: [C++11] stl_pair.h:137:64: internal compiler error:
Segmentation fault in constexpr constructor
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mattyclark...@gmail.com
templateclass _U1, class _U2, class = typename
enable_if__and_is_convertible_U1, _T1,
is_convertible_U2, _T2::value::type
constexpr pair(_U1 __x, _U2 __y)
: first(std::forward_U1(__x)), second(std::forward_U2(__y)) { }
Fails for my program when compiled with the following command line:
/usr/lib64/ccache/g++ -m64 -std=c++11 -Wall -Wextra -pedantic -pthread -flto
-DNDEBUG -O3 -Werror -pedantic-errors -fvisibility=hidden
-fvisibility-inlines-hidden -I/home/matt/svn/KS/lib
-I/home/matt/svn/KS/build/release/lib -I/home/matt/svn/KS/build/release/include
-I/home/matt/svn/KS/include -I/usr/include ../../lib/messaging/tests/task.cpp
-c -o lib/messaging/tests/task.cpp.4.o
With the following error:
In file included from
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_algobase.h:65:0,
from
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/char_traits.h:41,
from
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/string:42,
from
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/stdexcept:40,
from ../../lib/messaging/tests/task.cpp:15:
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_pair.h:
In instantiation of ‘constexpr std::pair_T1, _T2::pair(_U1, _U2) [with
_U1 = const char ()[35]; _U2 = const char ()[11]; template-parameter-2-3 =
void; _T1 = udp::ks::messaging::Id; _T2 = udp::ks::messaging::Id]’:
../../lib/messaging/tests/task.cpp:371:7: required from here
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_pair.h:137:64:
in constexpr expansion of ‘((std::pairudp::ks::messaging::Id,
udp::ks::messaging::Id*)this)-std::pairudp::ks::messaging::Id,
udp::ks::messaging::Id::first.udp::ks::messaging::Id::Id(((const
char*)std::forwardconst char ()[35]((* __x’
/home/matt/svn/KS/include/udp/keystone/messaging/id.hpp:260:30: in constexpr
expansion of ‘udp::ks::messaging::Name::Validate(((const Char*)string))’
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_pair.h:137:64:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla for instructions.
Preprocessed source stored into /tmp/cc99Hnms.out file, please attach this to
your bugreport.
Have attached the preprocessed output.
[Bug libstdc++/57047] [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57047 --- Comment #1 from Matt Clarkson mattyclarkson at gmail dot com 2013-04-23 12:53:18 UTC --- Created attachment 29919 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29919 The preprocessed output before the ICE
[Bug c++/57047] [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57047 --- Comment #5 from Matt Clarkson mattyclarkson at gmail dot com 2013-04-23 13:42:50 UTC --- Jonathan, apologies for putting it under libstdc++ and also for putting it as a blocker. I didn't do that because I thought it was blocking my work but more because I thought an ICE is a blocker for a release. Will make sure to remember this with any future bug reports. I am currently trying to get this down to a nice reproducible test case. Currently trying to get a single main.cpp that reproduces. Will post if I can get that, otherwise I'll reduce the code. Get the same error with tuple. So I'm sure it is in the Name::Validate constexpr function.
[Bug c++/57047] [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57047 --- Comment #7 from Matt Clarkson mattyclarkson at gmail dot com 2013-04-23 13:53:04 UTC --- Created attachment 29920 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29920 A simplified reproducible test case
[Bug c++/57047] [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57047 --- Comment #8 from Matt Clarkson mattyclarkson at gmail dot com 2013-04-23 14:07:44 UTC --- Created attachment 29921 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29921 A very short reproducible test case (85 loc)
[Bug c++/57047] [C++11] stl_pair.h:137:64: internal compiler error: Segmentation fault in constexpr constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57047 --- Comment #9 from Matt Clarkson mattyclarkson at gmail dot com 2013-04-23 14:17:10 UTC --- This is a problem with both 4.7.2 and 4.8.0. Checked on http://coliru.stacked-crooked.com/
[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466 --- Comment #12 from Matt Clarkson mattyclarkson at gmail dot com 2012-11-14 14:24:11 UTC --- @Dodji, thanks for fixing this :) What release will this be in? 4.8.1?
[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466 --- Comment #7 from Matt Clarkson mattyclarkson at gmail dot com 2012-10-17 08:19:20 UTC --- Sorry about the bloated bug report - that was how I came across it. In the future I'll submit smaller test cases. Thanks for looking into this.
[Bug c++/54466] Recursive Type Alias, Member Function Pointer, Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466 --- Comment #1 from Matt Clarkson mattyclarkson at gmail dot com 2012-10-16 15:46:31 UTC --- This is still an error on 4.7.2. It is the const before the std::shared_ptrconst T that is the problem: templatetypename T #if (__GNUC__ = 4) (__GNUC_MINOR__ = 7) (__GNUC_PATCHLEVEL__ = 2) using CallbackPtr = std::shared_ptrconst T; #else // This causes a segmentation fault on G++ 4.7.2 // Bug Report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466 using CallbackPtr = const std::shared_ptrconst T; #endif
[Bug c++/54466] New: Recursive Type Alias, Member Function Pointer, Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466
Bug #: 54466
Summary: Recursive Type Alias, Member Function Pointer,
Segmentation Fault
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mattyclark...@gmail.com
Created attachment 28122
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28122
The preprocessed dump from the error.
The following code fails with a segmentation fault:
#include memory
templatetypename T
using CallbackPtr = const std::shared_ptrconst T;
templatetypename C, typename T
using CallbackFunPtr = void (C::*)(CallbackPtrT);
int main () {
return 0;
}
[matt test] g++ --std=c++11 -Wall -Wextra -Werror -pedantic -pedantic-errors
main.cpp
main.cpp:7:49: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla for instructions.
Preprocessed source stored into /tmp/ccuw4zjD.out file, please attach this to
your bugreport.
However changing CallbackFunPtr to:
templatetypename C, typename T
using CallbackFunPtr = void (C::*)(const std::shared_ptrconst T);
It's OK.
[matt test] uname -r
3.5.2-3.fc17.x86_64
[matt test] gcc --version
gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5)
Copyright (C) 2012 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.
