Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: no...@turm-lahnstein.de
Target Milestone: ---
Produced assembler (-O2) for
struct Vec3{
double x, y, z;
};
struct Vec3 create(void);
struct Vec3 use(){
return create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91398
--- Comment #3 from ead ---
Thank you for the expanations and your time!
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: no...@turm-lahnstein.de
Target Milestone: ---
For the following example:
struct Vec3{
double x, y, z;
};
struct Vec3 do_something(void);
void use
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: no...@turm-lahnstein.de
Target Milestone: ---
For the following example:
struct Vec3{
double x, y, z;
};
void vadd_v2(struct Vec3* a, struct Vec3* out);
struct Vec3 use_v1(struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90356
--- Comment #3 from ead ---
I guess -0.0+0.0=0.0 is the reason we have to add it once. I think there is no
need to add 0.0 twice.
Btw. compiled with -fno-signed-zeros, the code gets optimized to
doit:
ret
as expected.
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: no...@turm-lahnstein.de
Target Milestone: ---
For the following example:
float doit(float k){
float c[2]={0.0};
c[1]+=k;
return c[0]+c[1];
}
the resulting assembler (-O2) is (https://gcc.godbolt.org/z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87268
--- Comment #3 from ead ---
Sorry, I only saw that clang gives me what I expect... and overlooked the
warning.
call_doit should return void and not int.
Assignee: unassigned at gcc dot gnu.org
Reporter: no...@turm-lahnstein.de
Target Milestone: ---
For a simple code like this:
extern int shared;
void doit(int *);
int call_doit(){
doit(&shared);
}
when compiled with -O3 the resulting assembler is without tail
: unassigned at gcc dot gnu.org
Reporter: no...@turm-lahnstein.de
Target Milestone: ---
When compiling
bool is_nan1(double x){
return x!=x;
}
with g++-8.1 -O3 the resulting assembler (https://godbolt.org/g/BBFM3Q) is
_Z7is_nan1d:
ucomisd %xmm0, %xmm0
movl $1, %edx
setne %al
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: no...@turm-lahnstein.de
Target Milestone: ---
Please consider the following code:
#include
namespace timeit{
typedef std::function Fun;
//returns time needed for execution in seconds, calls setup once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84891
--- Comment #4 from ead ---
From my naive point of view:
- The c++ standard doesn't define how complex-number-multiplication should
work, it is implementation defined/gcc-specific (I'm not a standard-scholar, so
might be very wrong about it).
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: no...@turm-lahnstein.de
Target Milestone: ---
Please consider the following example
#include
#include
#include
std::complex mult
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80372
--- Comment #3 from ead ---
(In reply to Andrew Pinski from comment #2)
> What options are you using? -O2 or -O3 ? -mcpu=native ?
It is compiled with -O3, but it is the same for -O2 or -Os.
If compiled with -march=native, the result uses four
++
Assignee: unassigned at gcc dot gnu.org
Reporter: no...@turm-lahnstein.de
Target Milestone: ---
While copying a std::complex from a memory location to another, four
movsd operations are used. However it is possible to use two movups, which are
faster (at least on some
++
Assignee: unassigned at gcc dot gnu.org
Reporter: no...@turm-lahnstein.de
Target Milestone: ---
While copying a std::complex from a memory location to another, four
movsd operations are used. However it is possible to use two movups, which are
faster (at least on some
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: no...@turm-lahnstein.de
Target Milestone: ---
Compiling
static int data = 0; static int dummy = data; int main() { }
with g++ -Os leads to a less than perfect assembler code
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: no...@turm-lahnstein.de
Target Milestone: ---
Following stackoverflow discussion:
http://stackoverflow.com/questions/39081183/errors-with-g-5-and-6-when-using-address-sanitizer
17 matches
Mail list logo