[Bug c/79459] Please add enable_if and diagnose_if attributes (from clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79459 corentinjabot at gmail dot com changed: What|Removed |Added CC||corentinjabot at gmail dot com --- Comment #2 from corentinjabot at gmail dot com --- This could be used to implement SFINAE friendly, warning free operators See https://github.com/llvm/llvm-project/pull/79465 https://godbolt.org/z/1xr9Wx38T
[Bug c++/102609] [C++23] P0847R7 - Deducing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
corentinjabot at gmail dot com changed:
What|Removed |Added
CC||corentinjabot at gmail dot com
--- Comment #25 from corentinjabot at gmail dot com ---
Hey folks.
Congrats on landing support for deducing this in GCC.
While there is no spec for it, after discussion here,
https://github.com/itanium-cxx-abi/cxx-abi/issues/148 explicit objects
parameters are mangled with `H`
This is the form that has been adopted for Clang.
The reason we need mangling is because WG21 made the following well-formed (and
that was reaffirmed. In fact, some complexity was added by P2797)
struct S {
static void f(S);
void f(this S);
};
And we need a way to distinguish both functions
I wasn't sure you were aware of this; I hope that form of mangling will work
for you.
Thanks
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348 --- Comment #16 from corentinjabot at gmail dot com --- (In reply to Jakub Jelinek from comment #15) > Now implemented for GCC 14. Thanks for working on this > As I wrote already in the PR, in addition to looking through the paper > I looked at the clang++ testcase for this feature implemented there from > paper's author and on godbolt played with various parts of the testcase > coverage below, and there are some differences between what the patch > implements and what clang++ implements. > > The first is that clang++ diagnoses if M.size () or M.data () methods > are present, but aren't constexpr; while the paper introduction talks > about > that, the standard wording changes don't seem to require that, all they > say > is that those methods need to exist (assuming accessible and the like) > and be implicitly convertible to std::size_t or const char *, but rest is > only if the static assertion fails. If there is intent to change that > wording, the question is how far to go, e.g. while M.size () could be > constexpr, they could e.g. return some class object which wouldn't have > constexpr conversion operator to size_t/const char * and tons of other > reasons why the constant evaluation could fail. Without actually > evaluating > it I don't see how we could guarantee anything for non-failed > static_assert. Clang always evaluate if i recall, the error is actually a warning that defaults to error. > > The second difference is that > static_assert (false, "foo"_myd); > in the testcase is normal failed static assertion and > static_assert (true, "foo"_myd); > would be accepted, while clang++ rejects it. IMHO > "foo"_myd doesn't match the syntactic requirements of unevaluated-string > as mentioned in http://eel.is/c++draft/dcl.pre#10 , and because > a constexpr udlit operator can return something which is valid, it > shouldn't > be rejected just in case. Seems like a bug in Clang indeed, I will investigate. > Last is clang++ ICEs on non-static data members size/data. You have a reproducer for that ?
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348
corentinjabot at gmail dot com changed:
What|Removed |Added
CC||corentinjabot at gmail dot com
--- Comment #9 from corentinjabot at gmail dot com ---
(In reply to Jakub Jelinek from comment #3)
> I wonder if the paper wording isn't incorrect, or at least comparing the
> clang++
> implementation vs. the paper gives some differences.
>
> One (minor) is that they emit errors when the size () and/or data () members
> aren't constexpr, while the paper as voted in only requires that
> "- the expression M.size() is implicitly convertible to std::size_t, and
> - the expression M.data() is implicitly convertible to ”pointer to const
> char”."
> unless the static assertion fails. The WIP patch doesn't do that, only
> effectively diagnoses it during constant evaluation of those when the static
> assertion fails.
During review in clang we felt that it diagnosing it it all cases
would be preferable to our users, as otherwise errors only manifest when the
static assertion fails,
likely at a point where the person getting the diagnostic would not be able to
act on it.
So we made it a warning that defaults to an error.
Note that core felt strongly we should not check for constant expressions at
the time,
but maybe opinions changed?
>
> More important, they have in the testcase something similar to what I filed
> in PR22, but let's use what works also in GCC:
> struct T {
> const char *d = init ();
> constexpr int size () const { return 2; }
> constexpr const char *data () const { return d; }
> constexpr const char *init () const { return new char[2] { 'o', 'k' }; }
> constexpr ~T () { delete[] d; }
> };
> constexpr int a = T{}.size (); // Ok, a = 2
> constexpr int b = T{}.data ()[0]; // Ok, b = 'o'
> constexpr const char *c = T{}.data (); // Not constant expression, because
> it returns
> // address from new which is later in the dtor deleted.
> static_assert (false, T{}); // Valid?
See https://github.com/cplusplus/CWG/issues/350, because i was confused too.
`data()` is a core constant expression. the implementation should behave _as
if_ `T{}.data ()[N]` is evaluated for each `N`
even if that would be pretty bad implementation strategy.
>
> "- M.data(), implicitly converted to the type ”pointer to const char”, shall
> be a core
> constant expression and let D denote the converted expression,
>
> – for each i where 0 ≤ i < N , D[i] shall be an integral constant
> expression, and"
>
> Now, I believe T{}.data () is not a core constant expression exactly because
> it returns address of later deleted heap object, but sure, both T{}.data
> ()[0] and T{}.data ()[1]
> are integral constant expressions.
>
> I don't know how std::format if constexpr (is it?) or string_view etc. work,
> do they
> need M.data () not be actual constant expression and only M.data ()[0]
> through M.data ()[M.size () - 1] constant expressions? In the patch I can
> surely try to constant expr evaluate M.data () quietly and if it isn't
> constant expression, just use a slower way which will ask for each character
> individually. More important question is what is the intention for the
> standard...
[Bug c++/110535] New: Internal error when performing a surrogate call with unsatisfied constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110535
Bug ID: 110535
Summary: Internal error when performing a surrogate call with
unsatisfied constraints
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: corentinjabot at gmail dot com
Target Milestone: ---
Consider
int f1(int);
template
struct A {
using F = int(int);
operator F*() requires N { return f1; }
};
int i = A{}(0); // Fine
int j = A{}(0); // Crash
This affects tip of trunk on CE https://godbolt.org/z/7vahavxv6
[Bug libstdc++/105291] include/c++/12.0.1/debug/safe_unordered_container.h:71:28: error: captured variable '__local_end' cannot appear here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105291 corentinjabot at gmail dot com changed: What|Removed |Added CC||corentinjabot at gmail dot com --- Comment #4 from corentinjabot at gmail dot com --- Agreed, clang should implement the proposed resolution to CWG2569 very soon so there isn't anything that needs to change in libstdc++
[Bug c/56523] New: -Wunitialized is described to be enabled -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56523 Bug #: 56523 Summary: -Wunitialized is described to be enabled -Wall Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: corentinja...@gmail.com The online docs ( http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html ) and the gcc 4.7 man page state incorrectly that -Wall enable -Wunitialized. The docs also state -Wunitialized is enable by -Wextra, and that is the observed and correct behaviour.
[Bug c/56523] -Wunitialized is described to be enabled by -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56523
--- Comment #2 from corentinjabot at gmail dot com 2013-03-04 17:33:26 UTC ---
Actually after a few more test it works correctly but the statement This
enables some extra warning flags that are not enabled by -Wall. is confusing
since the to set of options overlap.
I also tested with the following c++ snippet:
#include iostream
class A {
public:
A() {}
bool foo;
void bar() {
if(foo)
std::cout Foo\n;
}
};
int main () {
A a;
a.bar();
return 0;
}
The uninitialized variable is detected only with -O1. It is vaguely documented
but that behavior seems quite odd and unexpected when you are not aware of it.
