https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67435
--- Comment #12 from Maxim Egorushkin ---
gcc-13 and gcc-14 no longer align the last byte of a loop to the last byte of a
L1i-cache-line, when compiled with `-march=native -mtune=native` on Zen3 and
Zen4 CPUs.
I remember gcc-11 or gcc-12 aligni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67435
Maxim Egorushkin changed:
What|Removed |Added
CC||maxim.yegorushkin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #16 from Maxim Egorushkin ---
(In reply to Maxim Egorushkin from comment #14)
> (In reply to Andrew Pinski from comment #6)
>
> > It happens more often with vector instructions/registers due to the
> > different "modes" of the regis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #15 from Maxim Egorushkin ---
(In reply to Maxim Egorushkin from comment #14)
> (In reply to Andrew Pinski from comment #6)
>
> > It happens more often with vector instructions/registers due to the
> > different "modes" of the regis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #14 from Maxim Egorushkin ---
(In reply to Andrew Pinski from comment #6)
> It happens more often with vector instructions/registers due to the
> different "modes" of the registers that it can hold (subregs).
That's right, my empir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #13 from Maxim Egorushkin ---
(In reply to Andrew Pinski from comment #11)
> Let me try again:
>
> So we have:
> __v4di v4 = ymm0
> __v2di tmp = _mm256_extracti128_si256(v4, 1); // vextracti128
> __v2di tmp1 = _mm256_castsi256_si128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #10 from Maxim Egorushkin ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Maxim Egorushkin from comment #8)
> > (In reply to Andrew Pinski from comment #6)
> > > If you look at the difference between the 2 functions.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #8 from Maxim Egorushkin ---
(In reply to Andrew Pinski from comment #6)
> If you look at the difference between the 2 functions.
> vextracti128xmm1, ymm0, 0x1
>
> vs
> vmovdqa xmm1, xmm0
> vextracti128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #5 from Maxim Egorushkin ---
(In reply to Andrew Pinski from comment #2)
> Register allocation is NP complete problem after all.
vmovdqa instruction probably intends to turn a ymm register into a xmm register
by zeroing all the high
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118984
--- Comment #4 from Maxim Egorushkin ---
To add more context, I use Mula's AVX2 popcount function from
https://arxiv.org/abs/1611.07612
It produces 4 counts in a v4di register which should be summed into a scalar
total. Which brought me here.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
Unnecessary instructions are emitted when addition terms are in an unfortunate
order.
The following two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899
--- Comment #15 from Maxim Egorushkin ---
(In reply to Maxim Egorushkin from comment #14)
> (In reply to Marco Elver from comment #0)
> > On X86-64 the callee preserves all general purpose registers, except for
> > R11. R11 can be used as a scra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899
Maxim Egorushkin changed:
What|Removed |Added
CC||maxim.yegorushkin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #8 from Maxim Egorushkin ---
It was supposed to be one comment, but I kept clicking "save changes" button
because it provided no visual feedback that the comment was being posted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #7 from Maxim Egorushkin ---
> Can you provide the preprocessed source? Since I can't seem to reproduce it
> with the above.
It should be compiled with "-pthread -std=gnu++14 -O3 -Wall -Wextra -Werror" to
trigger the warning/error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #6 from Maxim Egorushkin ---
> Can you provide the preprocessed source? Since I can't seem to reproduce it
> with the above.
It should be compiled with "-pthread -std=gnu++14 -O3 -Wall -Wextra -Werror" to
trigger the warning/error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #4 from Maxim Egorushkin ---
Full context: https://github.com/max0x7ba/atomic_queue/issues/55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
Maxim Egorushkin changed:
What|Removed |Added
CC||maxim.yegorushkin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93897
--- Comment #3 from Maxim Egorushkin ---
It seems to get triggered by uint32_t, see also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96562
Any plans to fix this bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96562
--- Comment #5 from Maxim Egorushkin ---
(In reply to H.J. Lu from comment #2)
> Add -mavx to -O2 triggers this.
The bug seems to be caused by -msse4.1, -mno-sse4.1 fixes it.
Changing size from `unsigned` to `unsigned long` makes the bug disapp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96562
--- Comment #1 from Maxim Egorushkin ---
Correction:
Span f(unsigned char* p, unsigned char* q) {
return {p, static_cast(q - p)};
}
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
Rather poor assembly generated for trivial code.
The following code:
template
struct Span
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code:
#include
#include
namespace A {
inline uint64_t as_nanoseconds(struct timespec* ts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #19 from Maxim Egorushkin ---
(In reply to Jonathan Wakely from comment #17)
> At this time LWG 2381 is still open. Until the proposed fix (or some other
> fix) is resolved by making a change to the draft standard, I do not want to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91796
--- Comment #8 from Maxim Egorushkin ---
Another example
https://stackoverflow.com/questions/61975526/gcc-optimization-better-at-o0-than-o3
++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code:
struct A {
int a_;
A(int a) : a_(a) {}
};
struct B {
int a_;
constexpr B(int a) : a_(a
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code:
#include
struct B {
std::int64_t x;
std::int32_t y;
std::int32_t z;
};
B f(std::int64_t x, std::int32_t
++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code:
struct C {
C() { throw 1; }
static void* operator new(unsigned long);
static void operator delete(void*) = delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93622
--- Comment #4 from Maxim Egorushkin ---
I guess you are right, since clang compiles
bool f(int a, int b) { return a == b; }
into
f(int, int):
cmp edi, esi
seteal
ret
Where sete does't change the 7 high
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93622
--- Comment #2 from Maxim Egorushkin ---
(In reply to Jakub Jelinek from comment #1)
> clang doesn't follow the psABI.
How can it possibly do so while staying binary compatible?
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
bool register arguments are underspecified on x86_64
The following code:
#include
struct A {
int32_t a;
uint32_t b : 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91320
--- Comment #2 from Maxim Egorushkin ---
It reproduces with boost-1.64, https://godbolt.org/z/89HiMR
I don't have boost-1.64 currently available to generate a reprocessed source.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92149
--- Comment #3 from Maxim Egorushkin ---
System V ABI doesn't seem to require unused bytes to contain any specific
value.
There is a specific note for _Bool: When a value of type _Bool is returned or
passed in a register or on the stack, bit 0 c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92149
--- Comment #2 from Maxim Egorushkin ---
I notice that g++ always zeros out unused high-order bits. Clang++ never does.
Both follow the same System V ABI.
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code:
#include
#include
#include
using std::uint64_t;
using A = std::array;
template
constexpr A pack(T v) {
using C = unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91796
--- Comment #3 from Maxim Egorushkin ---
It seems to me that register allocation has been a weak spot in gcc for years.
gcc often allocates registers in such a way that extra register moves are
necessary, compared to competition, like in this p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92038
--- Comment #2 from Maxim Egorushkin ---
The competition often generates ideal code, but gcc team doesn't seem to care
at all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92038
--- Comment #1 from Maxim Egorushkin ---
I have reported a few bugs this year related to poor code generation:
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAI
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code:
#include
void f(std::variant);
void g() { f({}); }
When compiled with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91796
--- Comment #1 from Maxim Egorushkin ---
In addition, the code tries to generate avx_signbit using 2 instructions:
comparision vpcmpeqq and shift vpsllq to avoid loading anything from memory.
However, the compiler replaces the code with loading a
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code when compiled with `g++ -O3 -mavx2 -std=c++11`
__m256d copysign2_pd(__m256d from, __m256d to) {
auto a = _mm256_castpd_si256(from
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
Consider the following application comprised of an executable and a shared
library loaded
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code:
#include
__m256 copysign_ps(__m256 from, __m256 to) {
constexpr float signbit = -0.f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415
--- Comment #1 from Maxim Egorushkin ---
gcc-9.1 produces the same warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415
Bug ID: 91415
Summary: Invalid warning for C++17 sequencing of shift operator
E1<
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code:
#include
size_t g(boost::dynamic_bitset<> const& a, bool value) {
auto count
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following example:
#include
std::atomic a;
void foo_seq_cst(int b) { a = b; }
Compiles with `gcc-9.1 -O3 -std
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
Example:
#include
struct A {
template
A(Args&&... args) { std::printf("%s\n", _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972
--- Comment #14 from Maxim Egorushkin ---
(In reply to Jeffrey A. Law from comment #13)
> Folks where unhappy with various aspects of that patch. Bernd left Red Hat
> shortly thereafter and the patch hasn't been updated since his departure.
I h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972
Maxim Egorushkin changed:
What|Removed |Added
CC||maxim.yegorushkin at gmail dot
com
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
When the following code is compiled with `g++ --std=c++14 -O3`:
struct A { int a; };
struct B { int b; };
struct C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #13 from Maxim Egorushkin ---
(In reply to Uroš Bizjak from comment #9)
> (In reply to Maxim Egorushkin from comment #6)
>
> > This code underflows a signed integer, which is undefined behaviour, if I am
> > not mistaken. So, this wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #11 from Maxim Egorushkin ---
(In reply to jos...@codesourcery.com from comment #7)
> On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote:
>
> > This code underflows a signed integer, which is undefined behavi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #12 from Maxim Egorushkin ---
(In reply to jos...@codesourcery.com from comment #7)
> On Fri, 24 Nov 2017, maxim.yegorushkin at gmail dot com wrote:
>
> > This code underflows a signed integer, which is undefined behavi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #10 from Maxim Egorushkin ---
(In reply to Uroš Bizjak from comment #8)
> (In reply to jos...@codesourcery.com from comment #5)
> > Both 32-bit and 64-bit ABIs make the values of flags in EFLAGS (other than
> > DF) undefined on funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #6 from Maxim Egorushkin ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Maxim Egorushkin from comment #2)
>
> > Could you provide an example where that "dangerous optimization" would break
> > well-formed code please?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83133
--- Comment #2 from Maxim Egorushkin ---
(In reply to Uroš Bizjak from comment #1)
> (In reply to Maxim Egorushkin from comment #0)
> > g function assembly contains a superflous test instruction. It should not
> > generate that instruction, since
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
Consider the following code:
int negative(int);
int positive(int);
int nonnegative(int);
int nonpositive(int
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code successfully outputs double's in hexfloat format, but it
cannot read them back:
#include
#include
#include
int
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
Consider the following code:
struct A
{
long a;
bool b, c, d, e;
};
struct B
{
long a;
bool b, c, d, e
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
For the following function:
double f(int a, int b) {
return static_cast(a - b) / (a + b);
}
g++-7.2 with flags "-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71556
Maxim Egorushkin changed:
What|Removed |Added
CC||maxim.yegorushkin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79578
--- Comment #1 from Maxim Egorushkin ---
clang-3.9.1 generates code that I expect:
f(char*): # @f(char*)
movl$131073, (%rdi) # imm = 0x20001
movq%rdi, %rax
retq
++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
When the following code is compiled with gcc-7 and earlier versions with flags
--std=c++14 -O3 -pthread:
#include
#include
struct A
{
std
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code:
enum X { A };
unsigned foo(bool b) { return b ? A : 2u;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64085
--- Comment #1 from Maxim Yegorushkin ---
It compiles fine if I replace the line in question with:
return [&captive = static_cast(arg)](auto&& a) {
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
$ cat test.cc
#include
#include
template
auto make_monad(T&& arg) {
return [captive = std::forward(arg)](
FIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Passing wrong number of arguments into std::vector<>::emplace_back() causes an
internal compiler error:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56394
--- Comment #6 from Maxim Yegorushkin
2013-02-19 14:31:10 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > Also reproduces with optimization but with -fno-inl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56394
--- Comment #4 from Maxim Yegorushkin
2013-02-19 14:21:52 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > Also reproduces with optimization but with -fno-inline. The issue must be
> > with the exact division:
> >
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56394
Maxim Yegorushkin changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resoluti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56394
Bug #: 56394
Summary: pointer arithmetic breaks with __attribute__((packed))
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: ma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53941
--- Comment #2 from Maxim Yegorushkin
2012-07-12 14:36:52 UTC ---
Fair enough.
I wasn't sure whether std::pair<> should work as a range, so I went to
http://gcc.gnu.org/gcc-4.7/cxx0x_status.html which refers to
http://www.open-std.org/JTC1/SC22
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53941
Bug #: 53941
Summary: "Range-based for" feature is not implemented for
std::pair<>.
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53126
--- Comment #1 from Maxim Yegorushkin
2012-04-26 08:24:43 UTC ---
Created attachment 27245
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27245
The Makefile I use to download gcc and libs, build and install it.
Usage:
make download
mak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53126
Bug #: 53126
Summary: gcc-4.7.0 error "gcc-ar: Cannot find plugin"
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: critical
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47589
--- Comment #1 from Maxim Yegorushkin
2011-02-02 15:43:45 UTC ---
Created attachment 23215
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23215
Archived preprocessed source
Could not attach the preprocessed source as plain text because of t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47589
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig.
78 matches
Mail list logo
