++
Assignee: unassigned at gcc dot gnu.org
Reporter: public at alisdairm dot net
Target Milestone: ---
The following code fails to compile when the macro is defined:
#include
using namespace std::literals;
#if defined SHOW_BUG
auto x = 1'23s
#else
auto x = 123s;
#endif
I /think
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: public at alisdairm dot net
Target Milestone: ---
Created attachment 36999
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36999=edit
demonstrates requires clause d
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: public at alisdairm dot net
Target Milestone: ---
Created attachment 35841
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35841action=edit
C++ code that should compile in C++14 mode, but fails
The attached file
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: public at alisdairm dot net
Created attachment 35293
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35293action=edit
source for easy testing
The following simple code
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: public at alisdairm dot net
This bug looks looks obscure, but breaks our 'static assert' facility for C++03
compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448
--- Comment #11 from Alisdair Meredith public at alisdairm dot net ---
Created attachment 32298
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32298action=edit
Portable test of ADL on local type
Agreed, not-a-bug.
For completeness, I attach
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448
--- Comment #14 from Alisdair Meredith public at alisdairm dot net ---
Among other things, it lets fools like me write code relying on a behavior, not
realizing that the code is not portable. As a user I swing between the
convenience of having
++
Assignee: unassigned at gcc dot gnu.org
Reporter: public at alisdairm dot net
Created attachment 32286
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32286action=edit
Demonstrate swap_ranges does not find swap via ADL
The attached program does not correctly use ADL to find
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448
--- Comment #1 from Alisdair Meredith public at alisdairm dot net ---
Created attachment 32287
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32287action=edit
Cleaner tagging scheme for the local class
Simplified the example to more directly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60448
--- Comment #8 from Alisdair Meredith public at alisdairm dot net ---
I agree with Mark's analysis. I was trying to force use of swap on a local
class, and found a pattern that worked for libc++ but missed that neither
template would be more
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55564
Bug #: 55564
Summary: internal error using decltype of a template type
parameter for late-specified function result type
Classification: Unclassified
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54875
Bug #: 54875
Summary: Forward declare enums cannot be used as a template
argument
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52030
Bug #: 52030
Summary: ICE with decltype(make_tuple) is a late return type
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52030
--- Comment #2 from Alisdair Meredith public at alisdairm dot net 2012-01-28
23:06:53 UTC ---
IT could well be - I struggled to get a more minimal example when not using
'make_tuple', and it could well be doing something similar, especially
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51593
Bug #: 51593
Summary: alias templates fail in dependent contexts requiring
::template
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51593
--- Comment #2 from Alisdair Meredith public at alisdairm dot net 2011-12-16
23:18:27 UTC ---
Thanks, I thought I had tried that, but I guess not.
It seems reasonable to close this as user error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50853
Bug #: 50853
Summary: Internal Compiler Error returning a template type
using brace initialization
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50855
Bug #: 50855
Summary: Name mangling for late return types invoking
constructors not implemented
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50853
--- Comment #3 from Alisdair Meredith public at alisdairm dot net 2011-10-24
14:02:22 UTC ---
The original report was compiled with gcc 4.6.1 supplied by MacPorts. Could
you confirm if the not-supported error message occurs in trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50855
--- Comment #2 from Alisdair Meredith public at alisdairm dot net 2011-10-24
14:06:55 UTC ---
It might be. I still see an ICE for PR50853, but if that is giving the same
error now, then it is probably the same root cause. I'm still waiting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50853
--- Comment #5 from Alisdair Meredith public at alisdairm dot net 2011-10-24
14:10:38 UTC ---
Using built-in specs.
COLLECT_GCC=gcc-mp-4.6
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.6.1/lto-wrapper
Target: x86_64-apple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50855
--- Comment #3 from Alisdair Meredith public at alisdairm dot net 2011-10-24
14:13:31 UTC ---
And just to confirm - it sounds like the ICE in PR50853 is a bad compiler at my
end. I suggest keeping *this* PR open, as at least it reports
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50853
--- Comment #8 from Alisdair Meredith public at alisdairm dot net 2011-10-24
14:27:18 UTC ---
I am happy with closed - the ICE is resolved an PR50855 reports the
unimplemented error message, with (hopefully) a simpler test case.
It might
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50810
Bug #: 50810
Summary: c++0x-compat does not warn about narrowing conversions
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43947
--- Comment #3 from public at alisdairm dot net 2010-04-30 13:15 ---
Subject: Re: [C++0x] constexpr should allow declaration without a
definition
I am aware constexpr is not fully supported, and checked with Jason before
filing this issue.
We believe that constexpr should
at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40633
at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40639
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40306
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40307
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: public at alisdairm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40311
32 matches
Mail list logo
