Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
g++, tried trunk on CE along with 10.2 and 10.1 will say the following code is
not more specialized when JSONNAMETYPE is a CNTTP
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
Adding the attributes likely or unlikely can cause a function to be a constant
expression
https://gcc.godbolt.org/z/DGzPoa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92343
--- Comment #1 from Darrell Wright ---
On compiler explorer this affects 9.1/9.2/trunk
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
It looks like there is a regression in trunk(20171107 on CE) that allows
reinterpret_casts in constant expressions.
https
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
I accidently produced this invalid code and it worked as intended until I
tested further. However, the integer_sequence should never have been deduced
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92551
--- Comment #2 from Darrell Wright ---
The Args... is in a non deduced context because it isn't at the end.
http://eel.is/c++draft/temp.deduct#type-5.7
With that, I think only trailing packs can be defaulted to empty
http://eel.is/c++draft/temp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92551
--- Comment #3 from Darrell Wright ---
I think this can be closed and sorry for wasting time. It was explained how
this is ok to me https://bugs.llvm.org/show_bug.cgi?id=44034#c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92411
--- Comment #1 from Darrell Wright ---
sorry, posted incorrect CE link, but code below demonstrates it
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
As seen here https://gcc.godbolt.org/z/FvHncw. One cannot express
friend class Parent;
when parent is templated from a nested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91418
--- Comment #1 from Darrell Wright ---
The template isn't part of it,
https://gcc.godbolt.org/z/KCok90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91418
--- Comment #4 from Darrell Wright ---
The weird part is, other than compilers don't agree, but the lookup finds it if
you put the template argument in
template
struct A {
auto func( ) {
class B {
B( ) = default;
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
The following invalid code is UB but accepted by gcc. The life of x has not
started yet, https://eel.is/c++draft/basic.life#1.2 , but it is accessed.
constexpr void init(int &am
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
clang is unable to remove the memset in code like
std::vector foo() {
auto result = std::vector(SZ);
int *ptr = result.data();
for (std::size_t n = 0; n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104276
--- Comment #3 from Darrell Wright ---
(In reply to Andrew Pinski from comment #2)
> >clang is unable to remove the memset in code like
>
> I think you mean GCC there :).
:) both are true. This optimization would remove the need for things
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
Would it be possible to get a builtin that marks an object as invalid until it
is overwritten and make it IF if the object is used other than destruction,
assignment
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
The error generated when a variable template instantiation failure happens is
unhelpful. Clang provides more context in their error output.
With the following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104276
--- Comment #8 from Darrell Wright ---
What about something like a __builtin_overwrite( ptr, size_t ) that tells the
compiler that the range specified will be written. It forms a contract to do
so with the compiler and would allow the memset to
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
Because many of the cmath functions are constexpr, even in conformance mode of
the compiler, this can lead to ODR issues. It is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102916
--- Comment #2 from Darrell Wright ---
The constexpr value returned is different depending on the compiler. If one
uses clang and gcc this leads to an ODR issue as
void bar( ) {
if constexpr( foo<[]{ return std::sqrt( 4.0 ); }>( ) ) {
d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102916
--- Comment #3 from Darrell Wright ---
Also http://eel.is/c++draft/library#constexpr.functions-1
An issue is that it's high level observable and not just an optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102916
--- Comment #6 from Darrell Wright ---
Right, mostly it can fall under as-if(if it wasn't explicitly disallowed) but
because it's observable it can lead to some interesting behaviour differences
when libstdc++ is compiled with gcc and clang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102916
--- Comment #11 from Darrell Wright ---
(In reply to Jonathan Wakely from comment #7)
> C++23 is making these constexpr anyway so I'm not very inclined to change
> this now.
That is good to hear, I thought I had read/heard that there was a lot o
++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
std::make_shared in libstdc++ prior to c++20 doesn't fail.
The minimal example is
#include
int func( ) {
auto sp = std::make_shared( 55 );
return *sp.get( );
}
will retu
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
The following code produces an error
struct Thing0 {
volatile int a;
constexpr Thing0( int v ): a{v} {}
constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99535
--- Comment #1 from Darrell Wright ---
I was wrong, http://eel.is/c++draft/expr.const#5.8
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
The following valid code fails to compile in gcc-trunk on
https://foo.godbolt.org/z/vGMGbv8oP
auto a = requires{
[]( int b ) consteval
26 matches
Mail list logo
