https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117913
--- Comment #4 from Alisdair Meredith ---
In this case, clang and MSVC are not even considering the destroying delete
within the noexcept operator within a static_assert --- I am not sure at what
point that breaks down though. The runtime tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117913
--- Comment #3 from Alisdair Meredith ---
Clang and MSVC have bigger bugs that I am filing bug reports on shortly!
EDG gets this correct and passes all parts of the test, including the
"expected" undefined behavior:
https://godbolt.org/z/EG3EP5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117913
--- Comment #1 from Alisdair Meredith ---
Sorry, I made no effort to verify how far back this bug goes, but I expect it
has been an issue ever since destroying delete was first implemented.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
According to [except.spec] 14.5p9, "A deallocation function (6.7.6.5.3) with no
explicit noexcept-specifier has a non-thr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535
--- Comment #15 from Alisdair Meredith ---
I suggest either INVALID or WONTFIX would be appropriate, depending on whether
you think the original report on a change of behavior was valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92034
--- Comment #6 from Alisdair Meredith ---
Minor update: in the current standard, the paragraph number is now p12, and per
my last comment, I still believe the use of "shall" makes this ill-formed, and
without "no diagnostic required" wording it s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71029
--- Comment #4 from Alisdair Meredith ---
Revisiting some of my old bug reports, I can confirm that this performance
issue is resolved. I verified it was still present in gcc 10 so that it was
not a failure to reproduce on my part, and then stop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287
--- Comment #7 from Alisdair Meredith ---
Late comment: according to [intro.multithread.general] it is a requirement for
hosted implementations to support more than one thread of execution, but
implementation defined for a free-standing implement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90960
--- Comment #4 from Alisdair Meredith ---
I now believe my original bug report is invalid, due to a rarely consulted
paragraph of the standard, [temp.spec.general]p8.
If a function declaration acquired its function type through a dependent type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
Alisdair Meredith changed:
What|Removed |Added
CC||alisdairm at me dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43144
--- Comment #2 from Alisdair Meredith ---
gcc 4.5 and later correctly report errors, as the language specification for
rvalue and forwarding references changed between 4.4 and 4.5.
I'm not sure what ADL bug I thought I was hitting, but with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98038
--- Comment #1 from Alisdair Meredith ---
The following example code gives an internal compiler error, I suspect due to
the invalid attempt to call `operator()` recursively on the lambda object. Use
the -std=c++20 language flag:
#include
#incl
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95153
--- Comment #3 from Alisdair Meredith ---
Sorry, thought I had confirmed that I agree with the analysis above - this is a
(perhaps surprising) change to the specification of C++20.
What is the best way to withdraw this report as invalid?
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
Created attachment 48834
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48834&action=edit
Validate allocator propagat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535
--- Comment #13 from Alisdair Meredith ---
As this has shipped for two releases now (gcc9 and 10) I recommend closing as
Works As Designed, citing C standard paper N2322 as reason for the change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95153
--- Comment #1 from Alisdair Meredith ---
Forgot to add this is specific to -std=c++20 too.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
In general, we do not expect array types to be copyable according to the
'is_copy_constructible_v' trait. However, the following started passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535
--- Comment #10 from Alisdair Meredith ---
And double-checking the C++ Standard again, I think I have wording in favor of
my report and contradicting the recommended best practice for the pending C
standard:
[cpp.line]p2 "The line number of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535
--- Comment #9 from Alisdair Meredith ---
(In reply to Martin Sebor from comment #7)
> The following proposal was accepted into C2X last year:
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2322.htm
> It seems to me like it's about the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535
--- Comment #8 from Alisdair Meredith ---
(In reply to Andrew Pinski from comment #6)
> Why not do this:
> static_assert(X == 3 || X == 4);
>
> There that works for both cases.
The code example was intended to the be smallest reproducible examp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535
--- Comment #4 from Alisdair Meredith ---
(In reply to Andrew Pinski from comment #3)
> I miss-remembered the issue, the issue was only with preprocessor directives
> inside macro functions (this changed in GCC 3.3 and above really).
>
> But I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94535
--- Comment #2 from Alisdair Meredith ---
Thanks for the speedy response, really appreciated!
I believe this is well-defined behavior, but can accept that the value of
__LINE__ may be unspecified - I do struggle with pre-processor wording.
Ther
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
Given the following simple program, the line that static_asserts changed from
gcc 8 to gcc 9 (and remains so for current trunk
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
C++ currently has two deprecated C++ headers, and .
For quite a while, gcc has warned on #include with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93257
--- Comment #2 from Alisdair Meredith ---
I am trying to use these extensively as ways to collect related static
assertions in my test suite for and . By using
consteval rather then constexpr, I get notified if any code is unexpectedly
deferred
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
The following simple program is accepted by Clang (trunk) and rejected by
current gcc (trunk) at the time of filing:
template
cons
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
We are seeing a bogus warning on the default constructor for a class template
that wraps a data mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67228
Alisdair Meredith changed:
What|Removed |Added
CC||alisdairm at me dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287
Alisdair Meredith changed:
What|Removed |Added
CC||alisdairm at me dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92138
Alisdair Meredith changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
According to [cpp.predefined], the __CPP_THREADS__ macro should be (implicitly)
predefined "if and only if a program can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92034
--- Comment #4 from Alisdair Meredith ---
(In reply to Jonathan Wakely from comment #3)
> I'm not sure if a diagnostic is required. The standard doesn't specifically
> say it's ill-formed to do this. By my reading it's undefined, and so
> silentl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92034
--- Comment #1 from Alisdair Meredith ---
Sorry, link to Compiler Explorer showing the right compiler test (Clang 9):
https://godbolt.org/z/9QIIrE
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
According to [temp.explicit] p15, final sentence (after the note), 'extern
template' declarations cannot have intern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83534
Alisdair Meredith changed:
What|Removed |Added
CC||alisdairm at me dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91958
Alisdair Meredith changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
The following program should compile and run without error when built as C++17
or later. However, current versions of g++ will
++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
Per several existing bug reports (e.g.,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38433) in phase one of
translation, when mapping source character set to basic character set, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90960
--- Comment #2 from Alisdair Meredith ---
I agree the second problem looks like a dupe.
It has since been pointed out to me that the first error is indeed correct, and
simply the error message is less than helpful:
[temp.spec]p8 of C++17 says:
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
Note that this bug is a real corner case unlikely to occur in production code,
but bit us in experimental coding
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
According to the current standard, is_default_constructible_v is true if
is_constructible_v is true. The current libstdc++ disagrees
iority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
This is a tale of woe in the standard, but boils down to the following simple
test program, which compiles and passes with the current Microsoft
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71029
--- Comment #3 from Alisdair Meredith ---
And for reference, -ftime-report on the same file without -Wall:
time g++ -std=c++2a main.cpp -ftime-report
Time variable usr sys wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71029
--- Comment #2 from Alisdair Meredith ---
Having just discovered -ftime-report due to recent blog posts, I thought I
would repeat the experiment, and can confirm it is still an issue in the latest
development gcc available to me through MacPorts,
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
According to the formula for 'common_type', as an abominable function type does
not have a valid retu
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
The following simple program complains about duplicate definitions for two
different template instantiations:
template void fn() {}
int main() {
fn();
fn
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alisdairm at me dot com
Target Milestone: ---
Created attachment 38456
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38456&action=edit
file is very slow compiled with Wall
The attached file uses a simp
48 matches
Mail list logo
