https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #20 from Thiago Macieira ---
And:
$ cat /tmp/test.cpp
#include
bool tbit(std::atomic )
{
return i.fetch_xor(CONSTANT, std::memory_order_relaxed) & (CONSTANT);
}
$ ~/dev/gcc/bin/gcc "-DCONSTANT=(1LL<<63)" -S -o - -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #22 from Thiago Macieira ---
(In reply to H.J. Lu from comment #21)
> Created attachment 51559 [details]
> The new v3 patch
>
> The new v3 patch to check invalid mask.
v3? We were already up to v6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #24 from Thiago Macieira ---
(In reply to H.J. Lu from comment #23)
> I renamed the commit title. The new v3 is the v6 + fixes.
Got it. Still no issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #26 from Thiago Macieira ---
(In reply to H.J. Lu from comment #25)
> Can you get some performance improvement data on real workloads?
Will ask.
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Simple test:
$ cat test.cpp
#include
bool tbit(std::atomic )
{
return i.fetch_or(1, std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #7 from Thiago Macieira ---
(In reply to H.J. Lu from comment #5)
> Created attachment 51536 [details]
> A patch
>
> Please try this.
Give me an hour (will try v2).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #8 from Thiago Macieira ---
$ cat /tmp/test.cpp
#include
bool tbit(std::atomic )
{
return i.fetch_or(1, std::memory_order_relaxed) & 1;
}
$ ~/dev/gcc/bin/gcc -S -o - -O2 /tmp/test.cpp
.file "test.cpp"
.text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #9 from Thiago Macieira ---
Looks like it doesn't work for the sign bit.
$ cat /tmp/test.cpp
#include
bool tbit(std::atomic )
{
return i.fetch_or(CONSTANT, std::memory_order_relaxed) & CONSTANT;
}
$ ~/dev/gcc/bin/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #12 from Thiago Macieira ---
Commit 7e0c0500808d58bca5b8e23cbd474022c32234e4 + your patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #11 from Thiago Macieira ---
$ for ((i=0;i<32;++i)); do ~/dev/gcc/bin/gcc "-DCONSTANT=(1<<$i)" -S -o - -O2
/tmp/test.cpp | grep bts; done
lock btsl $0, (%rdi)
lock btsl $1, (%rdi)
lock btsl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #15 from Thiago Macieira ---
Works now for the failing case. Additionally:
bool tbit(std::atomic )
{
return i.fetch_and(~CONSTANT, std::memory_order_relaxed) & (CONSTANT);
}
Will properly produce LOCK BTR (CONSTANT=2):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #19 from Thiago Macieira ---
(In reply to H.J. Lu from comment #17)
> Created attachment 51558 [details]
> The v6 patch
>
> Please try this.
Confirmed for all inputs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103750
--- Comment #6 from Thiago Macieira ---
It got worse. Now I'm seeing:
.L807:
vmovdqu16 (%rsi), %ymm2
vmovdqu16 32(%rsi), %ymm3
vpcmpuw $6, %ymm0, %ymm2, %k2
vpcmpuw $6, %ymm0, %ymm3, %k3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103750
--- Comment #8 from Thiago Macieira ---
Update again: looks like the issue was the next line I didn't paste, which was
performing _kortestz_mask32_u8 on an __mmask16. The type mismatch was causing
this problem.
If I Use the correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103750
--- Comment #7 from Thiago Macieira ---
I should add the same is not happening for Char == char, meaning the returned
type is an __mmask32 (unsigned)
vmovdqu8(%rsi), %ymm2
vmovdqu832(%rsi), %ymm3
vpcmpub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103750
--- Comment #5 from Thiago Macieira ---
Maybe this is running afoul of GCC's thinking that a simple register-register
move is free? I've seen it save a constant in an opmask register, but kmov{d,q}
is not free like mov{l,q} is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103774
Thiago Macieira changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49001
--- Comment #7 from Thiago Macieira ---
Hack to workaround:
asm(
".macro vmovapd args:vararg\n"
"vmovupd \\args\n"
".endm\n"
".macro vmovaps args:vararg\n"
"vmovups \\args\n"
".endm\n"
".macro vmovdqa
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
I don't know how widespread this is. Seen in the code generated at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103066
--- Comment #10 from Thiago Macieira ---
You're right that emitting more penalises those who have done their job and
written proper code.
The problem we're seeing is that such code appears to be the minority. Or,
maybe put differently, the bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103069
--- Comment #2 from Thiago Macieira ---
See also bug 103090 for a few more (restricted) possibilities to replace a
cmpxchg loop with a LOCK RMW operation.
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Disclaimer: I don't know this code actually exists anywhere. But I've just come
up with it.
In Bug 102566, we optimised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #29 from Thiago Macieira ---
New suggestion in bug 103090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103090
--- Comment #1 from Thiago Macieira ---
One more:
bool tsign3(std::atomic )
{
// any two or more bits, so long as the sign bit is one of them
// (or the compiler doesn't know what's in the variable)
int bits = 1 | signbit;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103069
--- Comment #1 from Thiago Macieira ---
(the assembly doesn't match the source code, but we got your point)
Another possible improvement for the __atomic_fetch_{and,nand,or} functions is
that it can check whether the fetched value is already
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Testcase:
const char16_t *qustrchr(char16_t *n, char16_t *e, char16_t c) noexcept
{
__m256i mch256 = _mm256_set1_epi16(c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103069
--- Comment #20 from Thiago Macieira ---
I think there will be cases where the relaxation makes sense and others where
it doesn't because the surrounding code already does it. So I'd like to control
per emission.
If I can't do it per code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103069
--- Comment #14 from Thiago Macieira ---
I'd restrict relaxations to loops emitted by the compiler. All other atomic
operations shouldn't be modified at all, unless the user asks for it. That
includes non-looping atomic operations (like LOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103069
--- Comment #16 from Thiago Macieira ---
Can this option be enabled and disabled with a _Pragma?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103069
--- Comment #18 from Thiago Macieira ---
(In reply to Jakub Jelinek from comment #17)
> _Pragma("GCC target \"relax-cmpxchg-loop\"")
> should do that (ditto target("relax-cmpxchg-loop") attribute).
The attribute is applied to a function. I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104243
--- Comment #7 from Thiago Macieira ---
(In reply to Martin Liška from comment #6)
> Anyway, upstream removed the pure attribute as we suggested:
> https://codereview.qt-project.org/c/qt/qtbase/+/392357
Can we be assured the pure attribute
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Created attachment 52399
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52399=edit
qfutureinterface.cpp preprocessed
In:
static inl
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Created attachment 52409
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52409=e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103069
--- Comment #10 from Thiago Macieira ---
(In reply to H.J. Lu from comment #9)
> nptl/nptl_setxid.c in glibc has
>
> do
> {
> flags = THREAD_GETMEM (self, cancelhandling);
> newval = THREAD_ATOMIC_CMPXCHG_VAL (self,
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
In
long long f1(long long n, long long d)
{
return n / d;
}
GCC generates:
movq%rdi, %rax
cqto
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Test:
$ cat fstest.cpp
#include
#include
int main(int argc, char **argv)
{
for (int i = 1; i < argc; ++i) {
std::filesys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111244
--- Comment #2 from Thiago Macieira ---
(In reply to Andrew Pinski from comment #1)
> Except the code page could be tuned via a manifest file even.
> For an example GCC embeds a manifest into its own compiler to work around
> this issue and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111244
--- Comment #5 from Thiago Macieira ---
(In reply to Jonathan Wakely from comment #3)
> Somebody else will have to fix this, I've already wasted too much of my life
> making std:: filesystem (mostly) work on Windows.
Same here.
(In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111244
--- Comment #7 from Thiago Macieira ---
(In reply to Costas Argyris from comment #6)
> At this point I just meant embedding it in your example a.out executable
> file, just to check if it will work correctly.
Ah, got it. But that is not the
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
This compiles with GCC 11:
struct QArrayData
{
static void free(void *);
__attribute__((malloc(QArrayData
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105348
--- Comment #1 from Thiago Macieira ---
Qt workaround: https://codereview.qt-project.org/c/qt/qtbase/+/407217
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Testcase:
#include
char empty;
void sink(int);
bool cond(size_t);
void f(const char *s, size_t l)
{
int n;
if (cond(l)) {
memcpy(, s, sizeof(n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105348
--- Comment #3 from Thiago Macieira ---
I understand. I'm just trying to avoid having to add code for a corner-case.
People don't usually parse empty buffers, so it's usually fine to allow it to
proceed and discover an EOF condition.
Anyway,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105348
--- Comment #4 from Thiago Macieira ---
One more Qt workaround, for the record:
https://codereview.qt-project.org/c/qt/qtbase/+/413730
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Given a template like:
template struct __attribute__((visibility("hidden"))) S
{
static constexpr int n = 0;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106023
Thiago Macieira changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77306
Thiago Macieira changed:
What|Removed |Added
CC||thiago at kde dot org
--- Comment #3
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
__attribute__((dllimport)) void f();
class S
{
private:
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
The following code:
_Float16 f = 12.34f16;
compiles as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107456
Thiago Macieira changed:
What|Removed |Added
CC||thiago at kde dot org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
--- Comment #9 from Thiago Macieira ---
I can't be certain for other architectures' performance, but my feeling is that
indeed they would benefit from this. The option that was added as an -m should
be an -f (and match Clang's option).
However,
: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Probably similar to many other bugs related to -E -fdirectives-only. This
option is used by icecc <https://github.com/icecc/icecream>.
Test:
g++ -std=c++17 -i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108216
--- Comment #3 from Thiago Macieira ---
In bug 70644, the pointer to Base was passed to Base's constructor, so the
conversion from the derived type to the virtual base Base happened clearly
before said base was constructed.
In this example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
--- Comment #19 from Thiago Macieira ---
(In reply to Richard Biener from comment #15)
> Thanks, it's still the same reason - we isolate a nullptr case and end up
> with
>
> __atomic_or_fetch_4 (184B, 64, 0); [tail call]
>
> The path we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
--- Comment #14 from Thiago Macieira ---
Created attachment 54015
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54015=edit
qfutureinterface.cpp preprocessed [gcc trunk-20221205]
(In reply to Richard Biener from comment #13)
> There's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107456
--- Comment #4 from Thiago Macieira ---
(In reply to Thiago Macieira from comment #3)
> With the Remote Atomic Operations (RAO) of AAND, AOR and AXOR, we can do
> something.
Correcting myself: the RAO instructions don't give us the result back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
--- Comment #7 from Thiago Macieira ---
The duplicate "note:" disappeared. But now there's no warning at all on the
same file, with the same options. Was that intended?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
--- Comment #6 from Thiago Macieira ---
Testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
--- Comment #9 from Thiago Macieira ---
Ah, got it. That also explains why I couldn't find anything wrong with my code,
and nothing I did that could likely be it made the warning go away.
Thanks for the quick turnaround.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Warning options:
-Wall -Wextra -fno-exceptions -mno-direct-extern-access -Werror -Wno-error=cpp
-Wno-error=deprecated-declarations -Wno-error=strict-overflow
-Wno-error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
--- Comment #1 from Thiago Macieira ---
GCC 13 (trunk) built today.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
In:
#include
bool increment_if(int *ptr, int v)
{
return _cmpccxadd_epi32(ptr, v, 1, _CMPCCX_Z) == v;
}
GCC generates (and current Clang
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Follow up from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
The x86 locked ALU operations always set PF, ZF and SF, so
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Reference: https://bugreports.qt.io/browse/QTBUG-113603
Code in question:
const auto paramCount
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
In the following code:
struct S
{
char buf[47]; // weird size
};
void *f(unsigned long paramCount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106409
--- Comment #8 from Thiago Macieira ---
(In reply to Andrew Pinski from comment #7)
> See PR 58525 also which added that code path.
That explains why it won't call __cxa_throw_bad_array_new_length, but not why
it will call operator new[](-1).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106409
--- Comment #6 from Thiago Macieira ---
Suggestion: add a function to libgcc to be called instead of
__cxa_throw_bad_array_new_length when exceptions are disabled. That function
can be a mere two instructions, but it provides two advantages:
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109896
--- Comment #5 from Thiago Macieira ---
(In reply to Andrew Pinski from comment #4)
> If you are that picky for cycles, these cycles are not going to be a problem
> compared to the dynamic allocation that is just about to happen ..
Yeah, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109896
--- Comment #3 from Thiago Macieira ---
(In reply to H.J. Lu from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I suspect the overflow code was added before __builtin_*_overflow were added
> > which is why the generated code is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109896
--- Comment #7 from Thiago Macieira ---
(In reply to Jonathan Wakely from comment #6)
> With placement-new there's no allocation:
> https://gcc.godbolt.org/z/68e4PaeYz
Is the exception expected there, though?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99277
--- Comment #17 from Thiago Macieira ---
(In reply to Thomas Rodgers from comment #16)
> The original implementation came from Olvier Giroux and is part of libc++.
> The libc++ implementation also does not use a type that futex or
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99277
--- Comment #19 from Thiago Macieira ---
(In reply to Jonathan Wakely from comment #18)
> We have not committed to a stable ABI for C++20 yet.
That was my argument when creating this bug report two years ago: if it's
available in the standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99277
Thiago Macieira changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99277
--- Comment #21 from Thiago Macieira ---
I understand that. I don't think it's a reason to repeat the policy, though.
Anyway, I don't have any new arguments than when we discussed this two years
ago, so I won't pursue this matter further.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99277
--- Comment #15 from Thiago Macieira ---
> > 5) std::barrier implementation also uses a type that futex(2) can't handle
> barrier still uses a 1-byte enum for the atomic waits.
That can only now be fixed for libstdc++.so.7, then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113465
--- Comment #4 from Thiago Macieira ---
(In reply to Andrew Pinski from comment #3)
> See PR 54483 .
>
> *** This bug has been marked as a duplicate of bug 54483 ***
I don't think that's the same. That situation over there is C++11, where the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113465
--- Comment #5 from Thiago Macieira ---
> I don't think that's the same. That situation over there is C++11, where the
> constexpr variable is *not* static.
I meant not *inline*.
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Related to explicit instantiation of templates bugs:
Bug 89088, Bug 109380
though I'd argue that since that has a special
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54483
--- Comment #13 from Thiago Macieira ---
(In reply to Andrew Pinski from comment #11)
> You still need:
> constexpr float A::val;
In C++11 mode, yes.
C++17 made all static constexpr data members implicitly inline, which change
the situation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113465
--- Comment #6 from Thiago Macieira ---
Mind if I ask you reconsider the decision for inline variables (which all
constexpr ones are)?
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Actually, GCC doesn't have __builtin_wcslen, but Clang does. Providing these
extra two builtins would allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114088
--- Comment #3 from Thiago Macieira ---
> But __builtin_strlen *does* get optimized when the input is a string literal.
> Not sure about wcslen though.
It appears not to, in the test above. std::char_trait::length() calls
wcslen() whereas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114576
--- Comment #4 from Thiago Macieira ---
(In reply to Jakub Jelinek from comment #3)
> vaesenc etc. instructions can be used even if just -maes -mavx, not just
> -mvaes -mavx512vl.
Correct, that's just VEX-prefixed AESNI instructions.
VAES
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Re: https://bugreports.qt.io/browse/QTBUG-123965
Re: https://bugzilla.redhat.com/show_bug.cgi?id=2262640
201 - 284 of 284 matches
Mail list logo
