[Bug c/99317] Missed warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99317 --- Comment #2 from Piotr --- @(In reply to Andrew Pinski from comment #1) > I dont think this is exactly a bug. The warning is a pedantic warning and > with void*, things are implicitly converted by standard c rules. With not `void *` it is exactly the same. https://godbolt.org/z/zM8Eqs No -pedantic option too.
[Bug c/99317] New: Missed warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99317
Bug ID: 99317
Summary: Missed warning
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pj at hugeone dot co.uk
Target Milestone: ---
The code:
int *foo(void *v, void *w, int x) {
float * f = v;
int * i = w;
return (x ? f : i);
}
int *foo1(void *v, void *w, int x) {
float * f = v;
int * i = w;
return (1 ? f : (void *)i);
}
int *bar(void *v, void *w, int x) {
float * f = v;
int * i = w;
return (x ? f : (void *)i);
}
Function foo correctly emits the warning:
source>: In function 'foo':
:7:19: warning: pointer type mismatch in conditional expression
7 | return (x ? f : i);
| ^
Casting removes that warming even in the trivial foo1 example.
https://godbolt.org/z/ozsPPY
[Bug c/99011] Potentially missed optimization. Arrays are created without need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99011 Piotr changed: What|Removed |Added Version|10.2.1 |10.2.0 --- Comment #1 from Piotr --- https://godbolt.org/z/E18djs
[Bug c/99011] New: Potentially missed optimization. Arrays are created without need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99011
Bug ID: 99011
Summary: Potentially missed optimization. Arrays are created
without need
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pj at hugeone dot co.uk
Target Milestone: ---
Consider the code:
```
int bar(int N)
{
return N > 10 ? 14 : 8;
}
int foo(int N)
{
return (const int[]){8, 14}[N > 10];
}
int zoo(int N)
{
int a[] = {8,14};
return a[N > 10];
}
int boo(int N)
{
const static int a[] = {8,14};
return a[N > 10];
}
```
IMO in all cases the generated code should be the same as generated for
function bar. IMO arrays can be optimized out.
Compiled with -O3
foo:
mov rax, QWORD PTR .LC0[rip]
mov QWORD PTR [rsp-8], rax
xor eax, eax
cmp edi, 10
setgal
mov eax, DWORD PTR [rsp-8+rax*4]
ret
bar:
cmp edi, 10
mov edx, 8
mov eax, 14
cmovle eax, edx
ret
zoo:
mov rax, QWORD PTR .LC0[rip]
mov QWORD PTR [rsp-8], rax
xor eax, eax
cmp edi, 10
setgal
mov eax, DWORD PTR [rsp-8+rax*4]
ret
boo:
xor eax, eax
cmp edi, 10
setgal
mov eax, DWORD PTR a.0[0+rax*4]
ret
a.0:
.long 8
.long 14
.LC0:
.long 8
.long 14
gcc -O3 --verbose:
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-10.2.0/bin/gcc
Target: x86_64-linux-gnu
Configured with: ../gcc-10.2.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,go,d --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (Compiler-Explorer-Build)
COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' './output.s'
'-masm=intel' '-S' '-v' '-O3' '-mtune=generic' '-march=x86-64'
/opt/compiler-explorer/gcc-10.2.0/bin/../libexec/gcc/x86_64-linux-gnu/10.2.0/cc1
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/
-quiet -dumpbase example.c -masm=intel -mtune=generic -march=x86-64
-auxbase-strip ./output.s -g -O3 -version -fdiagnostics-color=always -o
./output.s
GNU C17 (Compiler-Explorer-Build) version 10.2.0 (x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/../../../../x86_64-linux-gnu/include"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/10.2.0/include"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring duplicate directory
"/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/10.2.0/include-fixed"
ignoring nonexistent directory
"/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/10.2.0/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/include
/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/include-fixed
/usr/local/include
/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/../../include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C17 (Compiler-Explorer-Build) version 10.2.0 (x86_64-linux-gnu)
compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 870fa0f1a93c5f0ff6fd5ef23d839e5a
COMPILER_PATH=/opt/compiler-explorer/gcc-10.2.0/bin/../libexec/gcc/x86_64-linux-gnu/10.2.0/:/opt/compiler-explorer/gcc-10.2.0/bin/../libexec/gcc/x86_64-linux-gnu/:/opt/compiler-explorer/gcc-10.2.0/bin/../libexec/gcc/:/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/../../../../x86_64-linux-gnu/bin/
LIBRARY_PATH=/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/:/o
[Bug c/92620] New: Ignored -fno-builtin -fno-builtin-memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92620
Bug ID: 92620
Summary: Ignored -fno-builtin -fno-builtin-memcpy
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pj at hugeone dot co.uk
Target Milestone: ---
int main()
{
printf("%s", (char[]){'H','e','l','l','o',' ','H','e','l','l','o','
','H','e','l','l','o',' ','H','e','l','l','o',' ','H','e','l','l','o','
','H','e','l','l','o',' ','H','e','l','l','o',' ','H','e','l','l','o','
','H','e','l','l','o',' ','H','e','l','l','o',' ','H','e','l','l','o','
','H','e','l','l','o',' ',0});
}
-Os -fno-builtin -fno-builtin-memcpy
ARM gcc 8.2
main:
str lr, [sp, #-4]!
sub sp, sp, #84
mov r2, #73
ldr r1, .L3
add r0, sp, #4
bl memcpy
add r1, sp, #4
ldr r0, .L3+4
bl printf
mov r0, #0
add sp, sp, #84
ldr pc, [sp], #4
.L3:
.word .LANCHOR0
.word .LC1
.LC1:
.ascii "%s\000"
[Bug c/86073] New: -O3 arm generates calls to memset even for known at the compile time very small sizes (<=3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86073
Bug ID: 86073
Summary: -O3 arm generates calls to memset even for known at
the compile time very small sizes (<=3)
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pj at hugeone dot co.uk
Target Milestone: ---
The test code:
void *my_memset1(void *ptr, const int v, size_t size)
{
size_t rem = size & 3;
size_t pro = (4 - ((uint32_t)ptr & 3)) & 3;
uint32_t v32 = *(uint32_t *)ptr = (((unsigned)v) << 24) | (((unsigned)v) <<
16) | (((unsigned)v) << 8) | v;
void *retval = ptr;
pro = pro >= size ? pro : size;
size -= pro;
while(pro--)
{
*(uint8_t *)ptr++ = v;
}
size >>= 2;
while(size--)
{
*(uint32_t *)ptr = v32;
ptr+=4;
}
while(rem--)
{
*(uint8_t *)ptr++ = v;
}
return retval;
}
rem is always <= 3
pro is always <= 3
both generate call to the buikt in memset function
my_memset1:
push {r3, r4, r5, r6, r7, r8, r9, lr}
lsls r5, r1, #16
negs r3, r0
and r3, r3, #3
orr r5, r5, r1, lsl #24
orrs r5, r5, r1
cmp r3, r2
orr r5, r5, r1, lsl #8
it cc
movcc r3, r2
mov r7, r1
mov r8, r0
str r5, [r0]
subs r6, r2, r3
and r9, r2, #3
cbz r3, .L13
mov r2, r3
uxtb r1, r1
mov r4, r3
bl memset <<--- here
lsrs r0, r6, #2
add r3, r8, r4
beq .L14
.L20:
add r0, r3, r0, lsl #2
.L11:
str r5, [r3], #4
cmp r3, r0
bne .L11
.L10:
cmp r9, #0
beq .L12
mov r2, r9
uxtb r1, r7
bl memset<< here
.L12:
mov r0, r8
pop {r3, r4, r5, r6, r7, r8, r9, pc}
.L13:
mov r3, r0
lsrs r0, r6, #2
bne .L20
.L14:
mov r0, r3
b .L10
[Bug c/81774] Volatile - order of reads in generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81774
--- Comment #3 from Piotr ---
And what about if volatile variable changes during the multiplications. Mybe
not in this example but if y was declared global - it can be interrupted
between multiplications.
volatile int y;
int x3(int x)
{
return y * y * y * y;
}
[Bug c/81774] Volatile - order of reads in generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81774 Piotr changed: What|Removed |Added CC||pj at hugeone dot co.uk Version|new-ra |unknown --- Comment #1 from Piotr --- versions from 4.47 to 7.1.0
[Bug c/81774] New: Volatile - order of reads in generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81774
Bug ID: 81774
Summary: Volatile - order of reads in generated code
Product: gcc
Version: new-ra
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pj at hugeone dot co.uk
Target Milestone: ---
I do not know if it and bug but it look strange to me.
Lets consider a trivial example:
int x3(int x)
{
volatile int y = x;
return y * y * y * y;
}
the code generated for x86-64 (7.1.0 - tested on many versions since 4.4.7)
(tested on ARM gcc up to 6.3 & AVR as well)
mov DWORD PTR [rsp-4], edi
mov eax, DWORD PTR [rsp-4]
mov esi, DWORD PTR [rsp-4]
mov ecx, DWORD PTR [rsp-4]
mov edx, DWORD PTR [rsp-4]
imuleax, esi
imuleax, ecx
imuleax, edx
IMO it reading the variable should be between the muls:
mov DWORD PTR [rsp-4], edi
mov eax, DWORD PTR [rsp-4]
mov esi, DWORD PTR [rsp-4]
imuleax, esi
mov ecx, DWORD PTR [rsp-4]
imuleax, ecx
mov edx, DWORD PTR [rsp-4]
imuleax, edx
as the stored value can change during the multiplications
[Bug middle-end/78824] multiple add should in my opinion be optimized to multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78824 --- Comment #4 from Piotr --- Freddie it is about avr-gcc not arm-gcc.
[Bug middle-end/78824] multiple add should in my opinion be optimized to multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78824 --- Comment #2 from Piotr --- avr-gcc actually
[Bug c/78824] New: multiple add should in my opinion be optimized to multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78824
Bug ID: 78824
Summary: multiple add should in my opinion be optimized to
multiplication
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pj at hugeone dot co.uk
Target Milestone: ---
Hi
Example (-O3)
volatile uint16_t y;
uint8_t nvx8;
int main(void) {
y = nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8
+ nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8;
}
translated to:
y = nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8
+ nvx8 + nvx8 + nvx8 + nvx8 + nvx8 + nvx8;
94: 80 91 00 01 lds r24, 0x0100
98: 28 2f mov r18, r24
9a: 30 e0 ldi r19, 0x00 ; 0
9c: c9 01 movwr24, r18
9e: 88 0f add r24, r24
a0: 99 1f adc r25, r25
a2: 88 0f add r24, r24
a4: 99 1f adc r25, r25
a6: 82 0f add r24, r18
a8: 93 1f adc r25, r19
aa: 82 0f add r24, r18
ac: 93 1f adc r25, r19
ae: 82 0f add r24, r18
b0: 93 1f adc r25, r19
b2: 82 0f add r24, r18
b4: 93 1f adc r25, r19
b6: 82 0f add r24, r18
b8: 93 1f adc r25, r19
ba: 82 0f add r24, r18
bc: 93 1f adc r25, r19
be: 82 0f add r24, r18
c0: 93 1f adc r25, r19
c2: 82 0f add r24, r18
c4: 93 1f adc r25, r19
c6: 82 0f add r24, r18
c8: 93 1f adc r25, r19
ca: 82 0f add r24, r18
cc: 93 1f adc r25, r19
ce: 82 0f add r24, r18
d0: 93 1f adc r25, r19
d2: 82 0f add r24, r18
d4: 93 1f adc r25, r19
d6: 90 93 02 01 sts 0x0102, r25
da: 80 93 01 01 sts 0x0101, r24
It should be optimized to multiplication I think.
