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: ---
In the following snippet:
-
inline static constexpr short main() {
}
-
1 : :1:36: error: cannot declare '::main' to be inline
inline static
++
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
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
: 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 con
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 b
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
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
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 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71566
denis.campredon at gmail dot com changed:
What|Removed |Added
CC||denis.campredon at
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
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
-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
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 is
++
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
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: 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 be
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 sn
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
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
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 in
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
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();
}
static void f(void) {
rec
++
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&action=edit
Reproducer to the bug
Compiling the attached file with `g++ ./bug.cpp
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
: 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: 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
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
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 negativ
-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
: 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
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 is
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
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.
For
-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&action=edit
input file
Compiling test.c on x86 with -O2 l
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&action=edit
assemble generated
-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&action=edit
input file
The attached file, compiled with -O2 -fstric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94802
denis.campredon at gmail dot com changed:
What|Removed |Added
CC||denis.campredon at
-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=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
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
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
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
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
++
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 on
-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
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.
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
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'};
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) {
if
: 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
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 or
: 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
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
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
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
: 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
: 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, for
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;
}
59 matches
Mail list logo