: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
I am trying to build gcc 4.8.2, and I got following compilation error:
make[3]: Entering directory `[path]/gcc/obj/gcc'
g++ -g -fkeep-inline-functions -DIN_GCC -fno-exceptions -fno
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
make[3]: Entering directory `[path]/gcc/obj/gcc'
build/gengtype \
-S ../../gcc-4.7.3/gcc -I gtyp-input.list -w
tmp-gtype.state
../../gcc-4.7.3/gcc/../include/splay-t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58828
--- Comment #2 from Daniel Fruzynski ---
Thanks for reply.
As I checked, this also happens when compiling using gcc 4.7.3, so looks that
this is more general problem.
File [path]/gcc/obj/gcc/config.status contains following entry:
configured by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58828
--- Comment #3 from Daniel Fruzynski ---
OK, I found it. I used script symlink-tree (distributed with binutils) to
create symlinks to binutils in gcc source dir. This script removed some gcc
source files and replaced them with symlinks to correspo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58840
--- Comment #2 from Daniel Fruzynski ---
OK, I found this. I used script symlink-tree to create symlinks to binutils in
gcc src dir. This script replaced some files with symlinks to their
counterparts in binutil dir, what caused this problem. gcc
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
I tried to pass -Werror=missing-include-dirs option to gcc in order to find all
non-existing include dirs and found that this option in broken. In gcc 4.5.2
this option is ignored - gcc does not print
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58988
--- Comment #1 from Daniel Fruzynski ---
gcc 4.8.2 is also affected by this bug - is works in the same way as gcc 4.7.3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88271
--- Comment #9 from Daniel Fruzynski ---
I have idea about alternate approach to this. gcc could try to look for
relations between loop control statement, and other statements which modify
variables used in that control statement. With such knowl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88271
--- Comment #10 from Daniel Fruzynski ---
Here is possible code transformation to equivalent form, where this
optimization can be simply applied. This change also has a bit surprising side
effect, second nested while loop is unrolled.
[code]
voi
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
I tried to write piece of code which used new AVX512 logic instructions which
works on kN registers. It turned out that gcc was moving
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88461
--- Comment #1 from Daniel Fruzynski ---
For comparison, this is code generated by icc 19.0.1:
[asm]
test(unsigned short*, int):
vmovdqu xmm0, XMMWORD PTR [rdi] #6.48
vptestnmw k0, xmm0, xmm0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81665
--- Comment #4 from Daniel Fruzynski ---
@Jonathan Wakely: constexpr requires C++11. When I reported this bug, we still
were at C++98 with most of out codebase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88461
--- Comment #3 from Daniel Fruzynski ---
Good catch, mask should be 16-bit. Here is fixed version:
[code]
#include
#include
int test(uint16_t* data, int a)
{
__m128i v = _mm_load_si128((const __m128i*)data);
__mmask16 m = _mm_testn_ep
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
When constant value is loaded into kN register, gcc puts it into eax first, and
then moved to kN register:
[code]
#include
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88465
--- Comment #2 from Daniel Fruzynski ---
I have logged issue for CompileExplorer to clarify this null instruction:
https://github.com/mattgodbolt/compiler-explorer/issues/1220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88465
--- Comment #3 from Daniel Fruzynski ---
This "null" ia an icc bug. Matt Godbolt from Compiler Explorer filed a bug with
Intel: ref 03997020
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
[code]
#include
void test(void* data, void* data2)
{
__m128i v = _mm_load_si128((__m128i const*)data
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
I was playing with Compiler Explorer to see how compilers can optimize various
pieces of code. I found next version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88473
--- Comment #2 from Daniel Fruzynski ---
I was playing with Compiler Explorer, to see how compilers optimize various
pieces of code. I found that next clang version (currently trunk) will be able
to analyze expressions which spans over vectors, m
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
When pointer to data is inside union, loops are not autovectorized. This also
happen when I removed "i" field from union, so it had only one field. Code
compiled with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88487
--- Comment #1 from Daniel Fruzynski ---
Update: when pointers to data are copied to local variables like below,
autovectorization starts working again.
[code]
void test3(S2* __restrict__ s1, S2* __restrict__ s2)
{
double* __restrict__ * __r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88487
--- Comment #2 from Daniel Fruzynski ---
I spotted that test3 in previous comment uses structure S2 which does not have
union inside. When I changes it to use S1, I got non-vectorized code. So this
workaround does not work.
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
Code below reads and writes data using different indices what is checked by
"if" above loop. This can be autovectorized, as both memory areas do n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88490
--- Comment #1 from Daniel Fruzynski ---
Ehh, small typo. This is correct version, also not vectorized:
[code]
struct S
{
double* __restrict__ * __restrict__ d;
};
void test(S* __restrict__ s, int n, int k)
{
if (n > k)
{
fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88490
--- Comment #3 from Daniel Fruzynski ---
In this case s->d is pointer to pointer to double, and both pointer levels have
restrict qualifier. I wonder if you could add some tag that s->d[n] and s->d[k]
points to separate memory areas. This tag cou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88487
--- Comment #4 from Daniel Fruzynski ---
OK, I see. Is there any workaround for this? I tried to assign pointer to local
variable directly and with intermediate casting via void*, but it did not help.
Casting S1* to S2* also does not work.
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
1st issue:
[code]
#define SIZE 2
void test(double* __restrict d1, double* __restrict d2, double* __restrict d3)
{
for (int n = 0; n < SIZE; ++n)
{
d
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
[code]
#include
bool test1(double d, double max)
{
return (d < max) && (d > -max);
}
bool test2(double d, double max)
{
return fabs(d) < max;
}
[/code]
Wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88542
--- Comment #2 from Daniel Fruzynski ---
No, code with -ffast-math is the same.
BTW, fabs(NaN) is NaN, so result is the same as before (false).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88540
--- Comment #3 from Daniel Fruzynski ---
Looks that AARCH64 is also affected. This is output from gcc 8.2 for SIZE=2:
[asm]
test(double*, double*, double*):
ldp d1, d0, [x0]
ldp d3, d2, [x1]
fcmpe d1, d3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88487
--- Comment #6 from Daniel Fruzynski ---
Not good. Fortunately I found workaround. This is probably the best what one
can get:
[code]
#include
#include
template
struct TypeHelper
{
constexpr unsigned offset();
operator Type&()
{
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
This example comes from code which could be compiled for various CPUs, and had
dedicated sections for AVX and SSE2. I left original ifdefs in comments. When
1st loop
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
[code]
void test1(int*__restrict n1, int*__restrict n2,
int*__restrict n3, int*__restrict n4)
{
for (int n = 0; n < 8; ++n)
{
if (n
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
This is a side effect of finding Bug 88570. I have noticed that when gcc has to
generate code for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88571
--- Comment #2 from Daniel Fruzynski ---
Yes. Issue still exists in g++ (GCC-Explorer-Build) 9.0.0 20181219
(experimental).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88570
--- Comment #2 from Daniel Fruzynski ---
In g++ (GCC-Explorer-Build) 9.0.0 20181219 (experimental) this still exists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88571
--- Comment #3 from Daniel Fruzynski ---
I have checked svn head version (20181221), issue is still there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88570
--- Comment #3 from Daniel Fruzynski ---
I have checked svn head version (20181221), issue is still there.
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
In test() gcc is not able to determine that for a==b it does not have to
evaluate 2nd comparison and can use value of a if 1st comparison is true. When
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88575
--- Comment #2 from Daniel Fruzynski ---
Code was compiled with -O3 -march=skylake.
I have tried to add -fno-signed-zeros and -fsigned-zeros, and got the same
output for both cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88575
--- Comment #3 from Daniel Fruzynski ---
I have tried to compile with -O3 -march=skylake -ffast-math and got this:
[asm]
test(double, double):
vminsd xmm2, xmm0, xmm1
vcmplesdxmm0, xmm0, xmm1
vxorpd xmm1, xmm1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782
Daniel Fruzynski changed:
What|Removed |Added
CC||bugzilla@poradnik-webmaster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782
--- Comment #4 from Daniel Fruzynski ---
I have found that I can use -ffixed-reg option for this. It allows to eliminate
one register, so I have to use it 16 times to eliminate all xmm16..31
registers. It would be handy to have another option whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782
--- Comment #5 from Daniel Fruzynski ---
I got following link:
https://stackoverflow.com/questions/53733624/is-xmm8-register-value-preserved-across-calls/53733767#53733767
Quote from it: "Any additional registers for newer instruction sets are
v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87729
--- Comment #2 from Daniel Fruzynski ---
Here you are:
[code]
class Foo
{
public:
virtual void f(int);
};
class Bar : public Foo
{
public:
virtual void f(short);
};
[/code]
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
SSE2 intrinsics are available by default when compiling code for 32-bit x86.
Code below compiles fine with options -m32 -O3. I had to add -mno-sse2 to get
an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88679
--- Comment #2 from Daniel Fruzynski ---
I used compiler at https://godbolt.org/. Here are outputs for both commands:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71659
Daniel Fruzynski changed:
What|Removed |Added
CC||bugzilla@poradnik-webmaster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71659
--- Comment #5 from Daniel Fruzynski ---
I meant pr85684
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
[code]
int test(int x)
{
return __builtin_ctz(x);
}
[/code]
gcc 4.9.1 with -O3 produces this:
[asm]
test(int):
rep bsf eax, edi
ret
[/asm]
And this with -O3 -mbmi:
[asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88959
--- Comment #1 from Daniel Fruzynski ---
I have found that this extra xor is not added when compiling with -O3
-march=sandybridge or -O3 -march=ivydybridge. However with -O3
-march=sandybridge/ivydybridge -mbmi it is added.
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
[code]
typedef int VInt __attribute__((vector_size(64)));
void test(VInt*__restrict a, VInt*__restrict b
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
[code]
void foo(char*);
inline void bar(int n)
{
if (__builtin_constant_p(n))
{
char a[(int)(n == 2 ? -1 : 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91235
--- Comment #1 from Daniel Fruzynski ---
I checked that trunk gcc also accepts this code, both with -std=c++11 and
-std=c++1z. Clang also compiles this without error. Could someone take a look
on this and add some comment here?
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
When code below is compiled, gcc prints warnings that null is passed to
function with nonnull attribute. However gcc does not point that error is
caused by inlining of my_strcpy at
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
When code below is compiled, gcc incorrectly complains that memcpy will read
data after end of buffer in line marked with star. Looks that gcc does not take
into account
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81914
--- Comment #9 from Daniel Fruzynski ---
In the meantime I found another case when gcc 7 inserts lots of jumps. I am not
sure if your extra test cases covers it too:
#include
int test(int data1[9][9], int data2[9][9])
{
uint64_t b1 = 0, b2 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83373
--- Comment #4 from Daniel Fruzynski ---
> Bug 83373 - False positive reported by -Wstringop-overflow, is
> another example of warning triggered by a missed optimization
> opportunity, this time in the strlen pass. The optimization
> is discusse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83373
--- Comment #6 from Daniel Fruzynski ---
My understanding is that after this patch will be applied, gcc will still emit
warning for last field in struct, e.g. like in code below. Is my understanding
correct or I missed something?
struct Msg
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83373
--- Comment #7 from Daniel Fruzynski ---
In my case structures like Msg above are generated from IDL files together with
code for serialization and deserialization. Because of this I cannot freely
move or add new fields there, this may break comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83373
--- Comment #9 from Daniel Fruzynski ---
Thanks for explanation. In addition to allocation on stack, my app also uses
custom allocator function like below. So in this case it also should work as
expected.
void* msg_alloc(int msg_id);
...
Msg* m
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
[code]
#include
struct S
{
char str1[10];
char str2[10];
char out[15];
};
void test(S* s) // line 10
{
snprintf(s->out, sizeof(s->out),
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
[code]
#include
struct S
{
char str[20];
char out[15];
};
void test(S* s)
{
snprintf(s->out, sizeof(s->str), "[%s]", s->str);
}
[/co
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
This looks like another missing optimization - -Wformat-truncation does not
take into account that there is "if" which checks that truncation will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521
Daniel Fruzynski changed:
What|Removed |Added
CC||bugzilla@poradnik-webmaster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83429
--- Comment #1 from Daniel Fruzynski ---
Another test case, this time "note:" with argument range also points to
incorrect line:
[code]
#include
struct S
{
unsigned char n;
char out[2];
};
void test(S* s) // line 9
{
snprintf(s->o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83429
--- Comment #2 from Daniel Fruzynski ---
Sometimes actual location is not reported at all:
[code]
#include
#include
struct S
{
char* str;
int n;
char out[10];
};
void test(S* s)
{
if (s->str)
snprintf(s->out, sizeof(s
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
Here is snipped of code which performs some calculations on matrix. It
repeatedly transforms some (N * N) matrix into (N-1 * N-1) one, and returns
final scalar value. gcc for some reason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83479
--- Comment #1 from Daniel Fruzynski ---
Here is clang 5.0 output, it is also shorted than gcc one (213 lines, gcc
produced 247).
test(double const (*) [8]): # @test(double const (*) [8])
vmovapd ymm3, ymmword ptr [rdi + 64]
vmovapd ymm4, ym
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83479
--- Comment #4 from Daniel Fruzynski ---
Rule No.1: never log bugs before morning coffee ;)
This does not produce warnings, compiled with "-O3 -march=haswell -mavx512f
-mavx512vl -mavx512bw -mavx512dq -mavx512cd -Wall -Werror".
[code]
#include "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83479
--- Comment #5 from Daniel Fruzynski ---
Here is also valid AVX version, it also spills a bit. Compiled with "-O3
-march=haswell -Wall -Werror".
[code]
#include "immintrin.h"
double test(const double data[5][4])
{
__m256d vLastRow, vLastCol,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83479
--- Comment #6 from Daniel Fruzynski ---
One correction: In c#4 line 17 has incorrect index, should be 8 instead of 9.
For some reason gcc did not complain here.
vLastRow = _mm512_load_pd (&data[8][0]);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81914
--- Comment #12 from Daniel Fruzynski ---
One more test case. Code compiled with TEST defined is branchless, without it
has branch.
[code]
#include
#define TEST
void test(uint64_t* a)
{
uint64_t n = *a / 8;
if (0 == n)
n = 1;
#ifdef T
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
[code]
void f1();
void f2();
void test(int a, int b, int c, int d, int n, int k)
{
int val = a & b;
if (__builtin_expect(!!(n == k), 0))
val &= c;
if (__builti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83610
--- Comment #1 from Daniel Fruzynski ---
Code was compiled with "-O3 -march=core2 -mtune=generic"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83610
--- Comment #3 from Daniel Fruzynski ---
Created attachment 42980
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42980&action=edit
Benchmark
Here is benchmark for this case. With unlikely() execution time decreases from
20.5sec to 20.3sec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81759
--- Comment #2 from Daniel Fruzynski ---
Looks that __builtin_ffs does not check if input value is nonzero at all.
Assembler code for following code also has unnecessary instructions:
[code]
unsigned int test(unsigned int n)
{
if (n == 0)
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
[code]
void test(unsigned int* ptr)
{
const int foo = Foo();
const int bar = Bar();
unsigned short n;
for (n = foo; n < 100; n += bar) {}
}
[/code]
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83634
--- Comment #1 from Daniel Fruzynski ---
A bit simpler test case which triggers this ICE:
[code]
void test()
{
const int foo = Foo();
short n;
for (n = foo; n < 100; ++n) {}
}
[/code]
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
Fix for bug 83373 does not work well with inlining:
[code]
#include
#include
char dest[20];
char src[10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82915
--- Comment #2 from Daniel Fruzynski ---
SIMD ISAa for other CPU types (e.g. ARM/AARCH64 NEON) also can benefit from
this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82915
--- Comment #4 from Daniel Fruzynski ---
For tracking purposes it probably would be better to have separate issues for
every CPU type which could benefit this. So this one could be for x86, and you
could open other requests for other CPUs which s
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
Functions like strcpy internally use memcpy to copy data. This may cause
problems when someone will try to use them to move string in buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83688
--- Comment #1 from Daniel Fruzynski ---
This also would allow to catch code which use sprintf to concatenate strings,
what is an undefined behavior (snippet from
https://linux.die.net/man/3/snprintf):
sprintf(buf, "%s some further text", buf);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83688
--- Comment #3 from Daniel Fruzynski ---
Looks that something is not working properly. I have pasted output from
compilation of function in 1st post, and -Wrestrict complained only about last
memcpy call. Please take a look on this.
BTW, string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83688
--- Comment #5 from Daniel Fruzynski ---
> There is nothing to indicate that the first call to memcpy() in comment #0
> overlaps so -Wrestrict doesn't warn for it.
I thought that fix for bug 83373 will somehow help here. gcc could guess that
mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83688
--- Comment #7 from Daniel Fruzynski ---
In general case yes, this can produce a lot of false positives. I wanted to use
this only for strings stored in fixed-size buffer. Existing string-related
warnings already uses this information, and this r
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
Warning for redefined macro does not have its own -Wsomething switch, please
add one. I also tried to use -fdiagnostics
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
gcc can detect if buffer size passed to function like strncpy is incorrect,
e.g. it is sizeof pointer
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
[code]
#define N 9
struct S1
{
int a1[N][N];
};
struct S2
{
int a2[N][N];
int a3[N][N];
};
void test1(S1* s1, S2* s2)
{
s2->a2[N-1][N-1] = s1->a1[N-
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
[code]
#define N 9
int a1[N][N];
int a2[N][N];
int b1[N*N];
int b2[N*N];
void test1()
{
for (int i = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84106
--- Comment #2 from Daniel Fruzynski ---
Test included in comment 0 is part of bigger test which I performed. In full
version code was also computing bitmask and stored in 3rd array. For test1 gcc
was able to vectorize inner loop to series of loa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84106
--- Comment #4 from Daniel Fruzynski ---
Here are results of small benchmark executed on Xeon E5-2683 v3. Code was
compiled using gcc 4.8.5. This gcc version also splits loops. Manually
vectorized code is 3.5 times faster:
[out]
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
Created attachment 43337
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43337&action=edit
Ful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84106
--- Comment #6 from Daniel Fruzynski ---
When you will be revisiting your cost-model for loops, please also take a look
on this code. test2 has one assignment moved to separate loops, and it is about
twice as fast as test1 function (for gcc 4.8.5
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
gcc produces ineffective code when std::copy is used to copy data. For test I
created my own version of std::copy and this version is optimized properly.
Compiles using g++ (GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317
--- Comment #2 from Daniel Fruzynski ---
Yes, I mean inefficient.
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
I have an idea of new function attribute: expect_return. It would allow to
specify value usually returned from function, so it could help with
optimization in similar way like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90293
--- Comment #1 from Daniel Fruzynski ---
One more case: sometimes it may be more handy to specify what will *not* be
usually returned, e.g. special invalid value. For such cases another attribute
would be needed:
__attribute__((expect_not_return
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
Created attachment 46353
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46353&action=edit
Preprocessed code
I got ICE Segmentation fault when trying t
1 - 100 of 187 matches
Mail list logo
