https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117000
--- Comment #6 from Paweł Bylica ---
Thanks for fixing this. Is there a way to get similar effect in GCC 14?
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
I was investigating why in GCC 13.3 the functions test1 and test2 produce
different x86 assembly. They only differ by the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
--- Comment #7 from Paweł Bylica ---
(In reply to Martin Jambor from comment #6)
> (In reply to Paweł Bylica from comment #5)
> > (In reply to Martin Jambor from comment #4)
> > > In this testcase all (well, both) functions referenced from the a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
--- Comment #5 from Paweł Bylica ---
(In reply to Martin Jambor from comment #4)
> In this testcase all (well, both) functions referenced from the array
> are semantically equivalent which is recognized by ICF but making it
> be able to pass thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
--- Comment #2 from Paweł Bylica ---
I don't think this is related to lambdas. The following is also not optimized:
using F = int (*)(int) noexcept;
inline int impl(int x) noexcept { return x; }
void test(int z[2]) noexcept {
static cons
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
In the following example there is a compile-time table of pointers to simple
functions. When the table is used in
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
When lzcnt instructions is enabled (-mlzcnt) the compiler generates lzcnt for
__builtin_clz() in the context where the bsr instruction is sufficient and
better.
unsigned bsr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #15 from Paweł Bylica ---
For what it's worth, clang's __builtin_addc is implemented in frontend only as
a pair of __builtin_add_overflow. The commit from 11 year ago does not explain
why they were added.
https://github.com/llvm/llvm-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110020
--- Comment #2 from Paweł Bylica ---
Yes, you are right. Sorry for taking your time.
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
This is a test case reduced from a C implementation of SHA256.
void test(unsigned h[8]) {
for (unsigned i = 0; i < 2; i++) {
unsigned w
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
When we have an addition and an overflow check and the overflow flag is
combined with some other condition the codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49054
Paweł Bylica changed:
What|Removed |Added
CC||chfast at gmail dot com
--- Comment #7
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
The code
void err(void);
void merge_bb(int y) {
if (y)
return err();
}
is
merge_bb:
testedi, edi
jne .L4
ret
.L4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105354
Paweł Bylica changed:
What|Removed |Added
CC||chfast at gmail dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104151
Paweł Bylica changed:
What|Removed |Added
CC||chfast at gmail dot com
--- Comment #18
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
I have an example of vectorization of 4x64-bit struct (representation of
256-bit integer). The implementation just uses for loop of count 4.
This is vectorized in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92140
--- Comment #32 from Paweł Bylica ---
For what it's worth, the original code is compiled the same as in Clang since
GCC 10. https://godbolt.org/z/vxorYW815
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
Reduced reproducer:
struct i256 {
long v[4];
};
void assign(struct i256 *v, long z) {
struct i256 r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106786
--- Comment #4 from Paweł Bylica ---
Any update on this? I've identified some other similar cases where this hurting
the performance.
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
I have a simple struct with array uint64_t[4]. When using memcpy() load it from
a storage of bytes and then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
--- Comment #6 from Paweł Bylica ---
The workaround is
MyObj obj = {};
which at least suggests some inconsistency in the compiler internals.
For me this warning should be disabled in C++ when designated initializers are
used and all other fie
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
If a struct S has a field c of type C having user constructor the
"missing-field-initializers" is reported for this field e
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
I noticed a regression when using the builtin for sbb instruction
(__builtin_ia32_sbb_u64).
typedef unsigned long long u64;
struct R {
u64 value;
bool carry;
};
inline R subc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
Paweł Bylica changed:
What|Removed |Added
CC||chfast at gmail dot com
--- Comment #25
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
I get
intx_reduced.cpp: In substitution of ‘template
uint f(const T&) [with unsigned int N = N; T = uint;
= ]’:
intx_reduced.cpp:18:31: required from
MED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
When building for 32-bit x86 but with SSE2 floating-point enabled:
-m32 -msse2 -mfpmath=sse
the conversion f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99620
--- Comment #4 from Paweł Bylica ---
Can you give me introduction where and how to fix it? I have a longer list of
similar issues, so maybe it's good time to learn how to fix them myself.
FYI, clang is unifying both cases by changing `k = l > a.
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
Hi.
For the 128-bit precision subtraction: SUB + SBB the optimization depends on
the how the carry bit condition is specified in the code. In the first case
below
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97145
Paweł Bylica changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51839
Paweł Bylica changed:
What|Removed |Added
CC||chfast at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97659
--- Comment #4 from Paweł Bylica ---
I'd like to explain some things here (to my best knowledge):
1. The "pointer-subtract" checks is ASan extension, not enabled by default.
When running with this check enabled in my application I have not detec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97659
--- Comment #2 from Paweł Bylica ---
Created attachment 49482
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49482&action=edit
Minimal test case source code
It turned out the problem is related to vector's internal instrumentation
_GLIBCXX
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
When vector::insert(iterator pos, InputIt first, InputIt last) is used
the AddressSanitizer additional
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
When my application is instrumented with -fsanitize=address,pointer-compare
and running under
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
Having a constexpr function that subtracts two pointers does not work in
constexpr context when building with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #16 from Paweł Bylica ---
I have checked the glibc implementation of floorf().
Source here:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/flt-32/s_floorf.c;h=da6c6dfa8ae86129e74d2e4391fac3a3c2ec;hb=HEAD
- It ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #15 from Paweł Bylica ---
(In reply to Marc Glisse from comment #14)
> (In reply to Marc Glisse from comment #13)
> > if (HONOR_SIGNED_ZEROS (mode))
> > x2 = copysign (x2, x);
>
> Hmm, I misread the comment, sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #8 from Paweł Bylica ---
Did you consider fixing the __builtin_floor() implementation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804
--- Comment #3 from Paweł Bylica ---
Yes, you are right, that is not violation of IEEE 754 (I assumed wrongly
previously, sorry).
However, it still maybe undesired to get different binary results depending on
optimization enabled/disabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96804
--- Comment #1 from Paweł Bylica ---
Created attachment 49133
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49133&action=edit
Assembly output
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
Created attachment 49132
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49132&action=edit
C source code
In the following function, when compiling without optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #4 from Paweł Bylica ---
I missed some information:
This affects both double and float variants: __builtin_floor() and
__builtin_floorf().
This affects also usage of floor() C standard library function as the function
call usually r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #3 from Paweł Bylica ---
Created attachment 49128
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49128&action=edit
Compiler invocation log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #1 from Paweł Bylica ---
Created attachment 49126
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49126&action=edit
Test source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96793
--- Comment #2 from Paweł Bylica ---
Created attachment 49127
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49127&action=edit
Assembly output
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
Created attachment 49125
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49125&action=edit
Preprocessed test code
47 matches
Mail list logo