Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
While working with legacy code, I encountered the following problem.
The code:
struct Struct;
int fn(Struct *);
Struct *Struct;
int fn(Struct
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
typedef __SIZE_TYPE__ size_t;
void baz(char *);
void foo( char *__restrict buff, const char*__restrict input)
{
size_t max = __builtin_strlen
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
On today's trunk, compiled with g++
---
typedef struct s{
char *key, *value;
}s;
s
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
The two following functions should produce the same assembly with optimizations
enabled.
This lead
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiled with -O1, on x86-64, f1 and f2 should produce the same code than f3
and f4, but f1 and f2 use two
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiled with -Os, the following functions use MMX instructions for simple
shift.
--
void foo(int *i
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiled with -std=c++20, who has only missing includes, the following code
prints way too much lines of error.
Adding
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiled with -O2 on x86, gcc trunk produces 3 mov instructions for each of the
following functions:
int foo(bool b, int i, int j) {
return b ? i - j
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiled with -O2, the following functions produce different assembly although
they compute the same things:
unsigned rot13_1(unsigned c
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiled with trunk and -O2, on x86-64, the testcase bellow shows, the calls to
memcmp are folded just when the size is a power of two. Other archs seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105338
--- Comment #13 from denis.campredon at gmail dot com ---
Thanks a lots.
I have a question though: foo and bar are similar, foo produces a branchless
code whereas bar uses a jump.
int foo(int i) {
return !i ? 0 : -2;
}
int bar(int i
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
int f(int i) {
return i ? 5 : 0;
}
int g(int i) {
return i ? -2 : 0;
}
int h(int b) {
return !!b * -2
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
bool foo(unsigned i) {
bool result = true;
while (i) {
i = i % 3;
i = i - (i==2 ? 2 : i ? 1 : 0);
result
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Was told to file a new PR for that case :
--
int foo(unsigned i) {
return i ? i % 2 : 0;
}
--
With trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104639
--- Comment #5 from denis.campredon at gmail dot com ---
That peace of code seems related but does not need a loop unlike the original
one.
--
int foo(unsigned i) {
return i ? i % 2 : 0;
}
--
With trunk 12
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
the following code compiled with -02
---
bool foo(int i) {
while (i == 4)
i += 2;
return i;
}
--
Trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97968
--- Comment #3 from denis.campredon at gmail dot com ---
This seems to be fixed for gcc12, unlike the code from pr-98303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104106
--- Comment #2 from denis.campredon at gmail dot com ---
The missed optimisations are also present if the arrays are allocated with
malloc or new.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
In the following snippet none of the loops are removed when compiled with -O2
or -O3.
In f and g the optimizers shoulds detect that tmp_a is only written and never
++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
g++ can remove new calls when the result is unused, but fails to di the same
with nothrow new calls. f() could be compiled to an empty function with
optimisations
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
On trunk and gcc 11, with -O2 the following functions are not optimized to
xor eax, eax
bool f() {
char a[] = {'a', 'c'};
char b[] = {'a', 'b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94802
denis.campredon at gmail dot com changed:
What|Removed |Added
CC||denis.campredon
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Created attachment 49761
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49761=edit
input file
The attached file, compiled with -O2 -fstrict-enums, o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98236
--- Comment #1 from denis.campredon at gmail dot com ---
Created attachment 49734
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49734=edit
assemble generated
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Created attachment 49733
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49733=edit
input file
Compiling test.c on x86 with -O2 leads to unoptimal c
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
For f1 code an unnecessary `comiss` instruction is used, the parity flag is
still set after the `jp` instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98169
--- Comment #2 from denis.campredon at gmail dot com ---
This also applies to vector types.
---
typedef float __attribute__((vector_size(8))) T;
T f(T a) {
return a != a;
}
---
Gcc could generate:
--
f:
xorps xmm1
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
The two following functions should produce the same assembly, at least on x86,
but for f1 gcc does not recognize the pattern for f1 and produce not optimal
code.
The problem
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
According to godbolt, f1 used to be optimised with gcc 7.
The same problem can be seen with signed types
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
In all the following functions gcc should recognize that j can't be greater
than 100, and link_error should not appear in assembly. Currently only f3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
The same problem applies with all comparison operators but '==' for 'int' and
'long' on x86-64.
(Returning a negative value instead of 0 makes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950
--- Comment #2 from denis.campredon at gmail dot com ---
Thanks for your fast patch. I've opened PR97961 for the __int128 problem
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
In #97950 Jackub told me to open a new bug for that.
The snippet bellow has the following problems
- f1 and f2
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
For the following code, the generation is unoptimal on x86-64.
For most of the functions with `short
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
For the following code
template struct s{}
auto f() {}
g++ produces a rather misleading error
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
gcc is not able to determine that the possible values of res are 0, 8, 16, 32
and so the following function is not optimized :
--
bool f(bool a, bool b, bool c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88280
--- Comment #2 from denis.campredon at gmail dot com ---
I don't know if I should create a separate bug report or not, since it looks
kind of related.
I've tried to replace the operator of the function e with other and it
generates a branch
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
The following functions should all produce the same code with optimisations on
(it is the same if `a' is replaced with a constant
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
--
int a;
static inline void f2 (...) {a++;}
void f1 (void) { f2 (0
++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiled with g++ the following code produces some rather confusing warnings:
---
int main(short s, void** t, int** u, int** v) {}
---
1 : :1:5: warning: first
++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
In the following snippet:
-
inline static constexpr short main() {
}
-
1 : :1:36: error: cannot declare '::main' to be inline
inline static constexpr
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Hello,
The fix for #pr83128 does not optimize the following testcase which should
produce the same result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83128
--- Comment #4 from denis.campredon at gmail dot com ---
Hi Richard,
Thanks for your quick response.
I don't know if I should open a new bug or not, but your patch does not seems
to handle casts. It fails to optimize the following snippet
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
It seems that GCC does not know that calloc initialize the memory to zero.
The the following functions could
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Currently gcc with -03 is able to optimize
--
char f() {
char * i = (char*)__builtin_malloc(100);
i[0
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Hello,
The following code produces
---
class C {
int f() = delete;
};
int f() {
return C().f
++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
The following code make the compiler emit an ICE with the latest snapshot
:3:13: internal compiler error: in write_unqualified_name, at
cp/mangle.c:1318
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80874
--- Comment #1 from denis.campredon at gmail dot com ---
Sorry, minmax3 should not produce the same asm, since minmax return a pair of
const reference.
But still the code is less than optimal.
One part it is because gcc might be because gcc
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Hello,
Considering the following code:
--
struct pair {
int min, max;
};
pair minmax1(int x, int y) {
if (x > y)
return {y, x};
e
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
With the following code:
-
void g(void (*)());
void f() {
int x;
g([x](){});
}
--
gcc produce this error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77846
--- Comment #1 from denis.campredon at gmail dot com ---
I'm pretty sure it is linked the following code, compiled with '-fpermissive'
only prints A instead of AB
--
enum E{ A, B };
class C {public:C(){};};
static inline
void f(E e
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiling the following code with -Wswitch
---
enum E {A, B};
class C {public: C();};
void f(E e) {
goto out
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Compiling the following code
void f(struct __builtin_va_list* ap);
Will result in an unfinished message
./Messages.h:1:15: error
++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
Created attachment 38956
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38956=edit
Reproducer to the bug
Compiling the attached file with `g++ ./bug.cpp' s
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
template
class A : T{};
template
using sp = A;
struct Base {};
template
const sp
rec()
{
return rec<T, num - 1>();
}
static void f(void) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71566
denis.campredon at gmail dot com changed:
What|Removed |Added
CC||denis.campredon
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
for the following code gcc should produce the same code for fun and fun2, but
fail for shorts and char with -01
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
For the following code
#include
struct s
{
int *i;
};
void f()
{
std::initializer_list initializer = {{false
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48050
Summary: [c++] ice with c++ code
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
59 matches
Mail list logo
