https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #41 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:69dc042f91c70458ffb6e7b147f093799cee2100
commit r10-5927-g69dc042f91c70458ffb6e7b147f093799cee2100
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #40 from Jonathan Wakely ---
I'm not sure if we really need these builtins in constexpr functions now, as we
can use is_constant_evaluated to avoid dispatching to optimised implementations
using memcmp. Maybe we can close this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #39 from Jonathan Wakely ---
It seems that clang doesn't support using __builtin_constant_p this way, so
using char_traits in constant expressions isn't going to work until
they implement is_constant_evaluated.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #38 from Jonathan Wakely ---
char_traits now uses either __builtin_constant_p or
__builtin_is_constant_evaluated to avoid using wcslen in constant expressions.
If that isn't working with clang for some reason that's a separate issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
janisozaur+gcc at gmail dot com changed:
What|Removed |Added
CC||janisozaur+gcc at gmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #36 from Jakub Jelinek ---
(In reply to Marc Glisse from comment #35)
> I just noticed that Jonathan has already written such a patch in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590#c28 but didn't commit it
> (maybe because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #35 from Marc Glisse ---
I just noticed that Jonathan has already written such a patch in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590#c28 but didn't commit it
(maybe because is_constant_evaluated was not committed yet, or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #34 from Jakub Jelinek ---
Created attachment 45467
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45467=edit
gcc9-pr86590.patch
Untested patch to use __builtin_is_constant_evaluated() here. I believe it
should help, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #33 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #8)
> I think there was a bug report in the last month or so asking for some
> builtin to detect when we're in a constexpr context.
Now that we have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #32 from Pedro Alves ---
In that case, I think the "something something" you're looking for can be
char_trait's __constant_char_array_p:
+ if (__constant_char_array_p(__first1, __len)
+ &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #31 from Jonathan Wakely ---
(In reply to Pedro Alves from comment #28)
> So back to the constexpr __builtin_memcmp, or __constexpr_memcmp ideas.
>
> Though I still don't see how __constexpr_memcmp would make a difference wrt
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #30 from Pedro Alves ---
> I suspect that wouldn't work, because we'd need to check whether the
> elements the iterator range point-to are themselves constant.
I would like to add that the char_traits trick handles this by doing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #29 from Pedro Alves ---
OK, our messages crossed. Thanks for the clarification. I can't really
comment on the optimizers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #28 from Pedro Alves ---
> Looking at the code, it does sound like you instead would want to
> tweak __equal_aux to end up with __simple==false when all __equal_aux's
> arguments are constant.
I suspect that wouldn't work, because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #27 from Jonathan Wakely ---
(In reply to Pedro Alves from comment #26)
> I'm confused then -- how does making __builtin_memcmp natively work on
> constexpr contexts address the "but then we'd have *three* versions" concern?
Because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #26 from Pedro Alves ---
I'm confused then -- how does making __builtin_memcmp natively work on
constexpr contexts address the "but then we'd have *three* versions" concern?
Looking at the code, it does sound like you instead would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #25 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #24)
> Also, the more work that the algorithm does, the more concerned I'd be that
> although the inputs are constant (and so we use the naive for-loop) the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #24 from Jonathan Wakely ---
Yes, but then we'd have *three* versions of std::equal: the default
implementation using a for-loop, the optimized one using memcmp for PODs, and
the constexpr form of the latter which also uses a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #23 from Pedro Alves ---
I think support in the compiler directly is likely to have better compile-time
performance, and I've stated from the beginning that I'd prefer that, FWIW.
OTOH, meanwhile, AFAICT, there's nothing preventing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #22 from Jonathan Wakely ---
No, it worked around it by implementing char_traits a different way.
We also use these functions in , e.g. std::equal uses
__builtin_memcmp, and that needs to be constexpr too.
We could keep using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #20 from Jonathan Wakely ---
Author: redi
Date: Tue Sep 12 16:27:01 2017
New Revision: 252030
URL: https://gcc.gnu.org/viewcvs?rev=252030=gcc=rev
Log:
Finish implementing P0426R1 "Constexpr for std::char_traits" for C++17
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #19 from palves at gcc dot gnu.org ---
Author: palves
Date: Mon Jun 12 22:22:39 2017
New Revision: 249137
URL: https://gcc.gnu.org/viewcvs?rev=249137=gcc=rev
Log:
Finish implementing P0426R1 "Constexpr for std::char_traits" for C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #18 from Pedro Alves ---
I sent a patch using the __builtin_constant_p idea:
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00983.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #17 from Marc Glisse ---
(In reply to Jason Merrill from comment #16)
> (In reply to Marc Glisse from comment #13)
> > it seems better than abusing __builtin_constant_p, which is getting
> > contradictory requirements from its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #16 from Jason Merrill ---
(In reply to Marc Glisse from comment #13)
> it seems better than abusing __builtin_constant_p, which is getting
> contradictory requirements from its various uses:
> - constexpr (forces very early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #15 from Jason Merrill ---
(In reply to Pedro Alves from comment #6)
> Hmm. I'd argue that __builtin_constant_p (s) should return true in that case,
> since we're in a constexpr?
No, the compiler is right; the address of the local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #14 from Pedro Alves ---
AFAIK, the "if constexpr()" proposal was sent back for more work [1], seems
premature to support it, while I'd hope that the __builtin_constant_p approach
would allow supporting constexpr char_traits in GCC7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #13 from Marc Glisse ---
If we need the "if constexpr()" that is proposed for C++20, we might as well
implement that (and enable it in system headers for C++17 if that's useful), it
seems better than abusing __builtin_constant_p,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #12 from Pedro Alves ---
This seems to work equally well (or better):
// true if the whole string is known at compile time.
static inline constexpr bool constant_string(const char *s)
{
while (__builtin_constant_p (*s) && *s)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #11 from Pedro Alves ---
Ok, so s[2] is not constant, while s[0] is, in that case.
AFAICS, changing constexpr_strlen to this:
constexpr size_t constexpr_strlen(const char* s)
{
const char *p = s;
while (__builtin_constant_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #10 from Jakub Jelinek ---
I don't think it works that well.
Consider:
int
str6 (int a)
{
char s[] = "strabcdefgh";
s[2] = a;
return ce_char_traits::length(s);
}
int
str7 (int a)
{
char s[] = "strabcdefgh";
s[2] = a;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #9 from Pedro Alves ---
FWIW, I've tried to poke a bit more at this, to try to make it _not_ work, but
couldn't. It seems to always do what we need. These all work/compile too:
constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #8 from Jonathan Wakely ---
I think there was a bug report in the last month or so asking for some builtin
to detect when we're in a constexpr context.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #7 from Pedro Alves ---
TBH, though I do think being able to use different algorithms for
compile/runtime is useful and a good idea, making the __builtin_strlen etc.
builtins works OOTB would of course be great. I'm merely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #6 from Pedro Alves ---
Hmm. I'd argue that __builtin_constant_p should return true in that case,
since we're in a constexpr?
In any case, changing the test like this:
- if (__builtin_constant_p (s))
+ if (__builtin_constant_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #5 from Jonathan Wakely ---
That doesn't work in this case:
constexpr bool str()
{
char s[] = "str";
return ce_char_traits::length(s) == 3;
}
static_assert( str() );
i.e. it works OK for C++11-style constant expressions, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
Pedro Alves changed:
What|Removed |Added
CC||palves at redhat dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #3 from Jakub Jelinek ---
Perhaps we then need some helper function partly similar to cxx_eval_array_ref,
that would for an object (or address of it?) and some uhwi index attempt to
return some byte from the object, and then if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #2 from Richard Biener ---
I think you need to handle some of the builtin folding in the C++ FE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
42 matches
Mail list logo
