[Bug c/53769] New: [C11]: Macros __STDC_NO_THREADS__ / __STDC_NO_ATOMIC__ missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769 Bug #: 53769 Summary: [C11]: Macros __STDC_NO_THREADS__ / __STDC_NO_ATOMIC__ missing. Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.peliss...@gmail.com When building a C program with -std=c11, GCC doesn't define __STDC_NO_THREADS__ & __STDC_NO_ATOMIC__ whereas it doesn't support theses features (yet) and still defines __STDC_VERSION__ to 201112L.
[Bug c/90962] New: Array bound over optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90962
Bug ID: 90962
Summary: Array bound over optimization
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.pelissier at gmail dot com
Target Milestone: ---
For the following program, GCC optimizes away the loop that affects the array:
#include
#include
struct node_s {
unsigned int size;
struct m_s *tab[1];
};
typedef struct m_s {
unsigned int type;
union {
struct node_s n;
} val[1];
} *m_t;
extern m_t node_c(uint8_t, unsigned int_t);
#define SET_AT(_x,_n,_y) ((_x)->val[0].n.tab[(_n)] = (_y))
m_t add_vc (unsigned int size, const m_t *tab)
{
if (size == 0)
return NULL;
m_t y = node_c (2, size);
for (unsigned int i = 0; i < size; i++) /* here */
SET_AT (y, i, tab[i]);
return y;
}
The following asm is generated for x86-64 when building it with gcc -O2 -S
t.c:
add_vc:
.LFB10:
.cfi_startproc
testl %edi, %edi
je .L3
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq%rsi, %rbx
movl%edi, %esi
movl$2, %edi
callnode_c
movq(%rbx), %rdx
movq%rdx, 16(%rax) // Only tab[0] is set
popq%rbx
.cfi_def_cfa_offset 8
ret
.p2align 4,,10
.p2align 3
.L3:
.cfi_restore 3
xorl%eax, %eax
ret
The loop is removed with GCC 7.3, GCC 8.2 and GCC 9.1: only tab[0] is set.
The loop is not removed and the program behaves as expected with GCC 4.9, GCC
6.3
[Bug c/19972] -Wreturn-local-addr misses return of local (nested) function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19972
--- Comment #3 from Patrick Pelissier ---
I have tested with GCC 7.1.0 the code of #0 (forget the function h, this was
only a reference) and the status is the same as described in #0.
For the following code,
int (*apply (int (*f) (const void *, const void *), void *a))(const void *)
{
int g(const void * b) { return f(a,b); };
return &g;
}
I get no warning for returning the nested function 'g'.
[Bug c/81741] New: Misoptimisation : replacing a constant field read access by a function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81741
Bug ID: 81741
Summary: Misoptimisation : replacing a constant field read
access by a function call
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.pelissier at gmail dot com
Target Milestone: ---
GCC 7.1.0 generates for the following code:
#include
typedef struct string_s {
unsigned long size, alloc;
char *ptr;
} string_t[1];
# define M_ASSUME(x)\
(! __builtin_constant_p (!!(x) || !(x)) || (x) ? \
(void) 0 : __builtin_unreachable())
int f(string_t s)
{
M_ASSUME(strlen(s->ptr) == s->size);
return s->size;
}
the following code on an x86-64 platform (gcc -std=c99 -O2 -S test.c):
f:
subq$8, %rsp
movq16(%rdi), %rdi
callstrlen
addq$8, %rsp
ret
Notice that the field access s->size is replaced by strlen(s->ptr), which is
way slower.
GCC 4.9 doesn't have this issue.
[Bug tree-optimization/81741] Misoptimisation : replacing a constant field read access by a function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81741 --- Comment #2 from Patrick Pelissier --- I can reproduce the behavior without __builtin_constant_p by removing it from the M_ASSUME macro : # define M_ASSUME(x)\ ( (x) ? \ (void) 0 : __builtin_unreachable()) It still generates the same instructions.
[Bug c++/60932] make stdatomic.h compatible with C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932 Patrick Pelissier changed: What|Removed |Added CC||patrick.pelissier at gmail dot com --- Comment #12 from Patrick Pelissier --- Is the status really "wontfix"? This makes any C library which uses stdatomic.h incompatible with g++ (and more and more C code uses stdatomic.h) which is rather bothersome. clang doesn't have this issue. What prevent stdatomic.h to detect if it is included in C++ mode and includes C++ instead?
[Bug c/64518] New: Warning about comparison between signed and unsigned can be useless in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64518
Bug ID: 64518
Summary: Warning about comparison between signed and unsigned
can be useless in some cases
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.pelissier at gmail dot com
For the following function:
int f(int x) { return ( x >= 0 && x < sizeof(int)); }
I get the following warning with gcc -Wsign-compare -c f.c :
f.c: In function 'f':
f.c:1:37: warning: comparison between signed and unsigned integer expressions
[-Wsign-compare]
int f(int x) { return ( x >= 0 && x < sizeof(int)); }
^
However, as x has been checked as positive due to the first comparison, I don't
see how the comparison between x (signed) and sizeof(int) (unsigned) can be
wrong.
The proposed enhancement is to improve the warning to handle this case properly
without adding a (useless) cast in the user code like this:
int f(int x) { return ( x >= 0 && (unsigned int) x < sizeof(int)); }
[Bug c/63597] New: Generate useless trampoline for some nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63597
Bug ID: 63597
Summary: Generate useless trampoline for some nested function
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.pelissier at gmail dot com
In some cases, GCC generate a trampoline for nested functions whereas it is not
needed.
For example, for the code:
extern void h(void (*)(int*), int*);
int f(int x, int y) {
int a;
void g(int *ptr_a) {
*ptr_a = ptr_a[&x-&a] + ptr_a[&y-&a];
}
h(g, &a);
return a;
}
It generates a trampoline for function g:
movl$-17599, %eax
movl$-17847, %edx
movl%edi, 8(%rsp)
movl%esi, (%rsp)
leaq12(%rsp), %rdi
leaq4(%rsp), %rsi
movw%ax, 12(%rsp)
movl$g.1623, %eax
movl%eax, 2(%rdi)
movq%rsp, 8(%rdi)
movw%dx, 6(%rdi)
movl$-1864106167, 16(%rdi)
callh
whereas function g doesn't use this access and so doesn't need the trampoline:
g.1623:
.LFB1:
.cfi_startproc
movl-4(%rdi), %eax
addl4(%rdi), %eax
movl%eax, (%rdi)
ret
(no use of %r10).
[Bug c/63597] Generate useless trampoline for some nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63597 Patrick Pelissier changed: What|Removed |Added Version|4.9.2 |4.9.1 --- Comment #1 from Patrick Pelissier --- -O option shall be used to compile the code.
[Bug preprocessor/69093] New: implement -fmacro-backtrace-limit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69093 Bug ID: 69093 Summary: implement -fmacro-backtrace-limit Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: patrick.pelissier at gmail dot com Target Milestone: --- Recent gcc performs full backtrace when error / warning appear within a macro but has not any option to limit its size. This makes gcc hard to use for debugging deferred recursive macros (See https://github.com/pfultz2/Cloak/wiki/C-Preprocessor-tricks,-tips,-and-idioms): in such cases, the backtrace is huge (more than 5000 lines of backtrace per instance) and useless. clang has the option -fmacro-backtrace-limit for this purpose.
[Bug middle-end/71789] New: atomic_int incompatibility warning between C and C++ [-Wlto-type-mismatch]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71789
Bug ID: 71789
Summary: atomic_int incompatibility warning between C and C++
[-Wlto-type-mismatch]
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.pelissier at gmail dot com
Target Milestone: ---
Trying to use a C library within a C++ program, I get some errors due to the
header of the C library including stdatomic.h
Following the advice of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932 I
tried to patch the header with:
#ifdef __cplusplus
#include
using namespace std;
#else
#include
#endif
However when I link the final application with LTO, I get some warning.
It can be shown by the following example:
c.c:
#include "c.h"
bool f(atomic_int b) {
return b == 0;
}
c.cpp:
#include "c.h"
int main(void) {
bool b = f(ATOMIC_VAR_INIT(0));
return b ? 0 : 1;
}
c.h:
#ifndef __C_H
#define __C_H
#include
#ifdef __cplusplus
#include
using namespace std;
#else
#include
#endif
#ifdef __cplusplus
extern "C" {
#endif
extern bool f(atomic_int n);
#ifdef __cplusplus
}
#endif
#endif
And the used compilation command:
$ gcc -c -flto -O2 -Wall -W -std=c11 c.c -o c1.o && g++ -c -flto -O2 -Wall -W
-std=c++11 c.cpp -o c2.o && g++ -flto -O2 -Wall c1.o c2.o
gives the following warning:
c.h:18:13: attention : type of ‘f’ does not match original declaration
[-Wlto-type-mismatch]
extern bool f(atomic_int n);
^
c.c:3:6: note : type mismatch in parameter 1
bool f(atomic_int b)
^
/opt/gcc/lib/gcc/x86_64-pc-linux-gnu/6.1.0/include/stdatomic.h:46:21: note :
type ‘atomic_int’ should match type ‘struct atomic_int’
typedef _Atomic int atomic_int;
^
/opt/gcc/include/c++/6.1.0/atomic:794:25: note : the incompatible type is
defined here
typedef atomic atomic_int;
^
c.c:3:6: note : ‘f’ was previously declared here
bool f(atomic_int b)
^
c.c:3:6: note : code may be misoptimized unless -fno-strict-aliasing is used
$ gcc --version
gcc (GCC) 6.1.0
[Bug c/71949] New: ATOMIC_FLAG_INIT definition in stdatomic.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71949
Bug ID: 71949
Summary: ATOMIC_FLAG_INIT definition in stdatomic.h
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.pelissier at gmail dot com
Target Milestone: ---
Compiling the following program, I get one error for one kind of affectation to
ATOMIC_FLAG_INIT :
#include
void f(void) {
atomic_flag f1 = ATOMIC_FLAG_INIT;
atomic_flag f2;
f2 = ATOMIC_FLAG_INIT;
}
$ /opt/gcc/bin/gcc -c flag.c
In file included from flag.c:1:0:
flag.c: In function 'f':
flag.c:6:9: error: expected expression before '{' token
f2 = ATOMIC_FLAG_INIT;
^
$ /opt/gcc/bin/gcc --version
gcc (GCC) 6.1.0
I expected both construction to be valid.
Proposed solution: fix definition of ATOMIC_FLAG_INIT in stdatomic.h into:
#define ATOMIC_FLAG_INIT ((atomic_flag) { 0 })
instead of
#define ATOMIC_FLAG_INIT{ 0 }
[Bug c/71949] ATOMIC_FLAG_INIT definition in stdatomic.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71949 --- Comment #2 from Patrick Pelissier --- I am not sure that DR#454 applies to this case as _Atomic types are allowed to have additional state needed by the implementation to carry for the atomic object (§7.17.2.2) whereas atomic_flag has only two states - set and clear - (§7.17.8) and no potential additional state is mentioned for the atomic flag. This would explain why the atomic_init generic function exists to initialize an atomic, but there is no equivalent function for atomic_flag.
[Bug c/53769] [C11]: Macros __STDC_NO_THREADS__ / __STDC_NO_ATOMIC__ missing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769 Patrick Pelissier changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #12 from Patrick Pelissier --- stdc-predef.h fixes the issue.
[Bug c/108201] New: Warning about conversion from unsigned int to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108201
Bug ID: 108201
Summary: Warning about conversion from unsigned int to unsigned
int
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.pelissier at gmail dot com
Target Milestone: ---
On a Linux x86_64 system, with GCC 12.2.0, when I build the following program
with -Wsign-conversion ,
typedef unsigned int m_string_unicode_t;
void decode(char c, m_string_unicode_t *unicode) {
*unicode = ((*unicode << 6)) | ((m_string_unicode_t) c);
}
void decode2(char c, unsigned int *unicode) {
*unicode = ((*unicode << 6)) | ((unsigned int) c);
}
I get the following wanning:
tst.c: In function 'decode':
tst.c:6:32: warning: conversion to 'm_string_unicode_t' {aka 'unsigned int'}
from 'unsigned int' may change the sign of the result [-Wsign-conversion]
There is a warning for the function decode, but not for the function decode2.
I don't understand the warning as there is no conversion from unsigned int to
unsigned int as both are the same type. I was expecting no warning for both
functions.
The warning only appears with GCC 12 (no issue with GCC 11).
[Bug c/109530] New: Warning "is used uninitialized" raised for an initialized variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109530
Bug ID: 109530
Summary: Warning "is used uninitialized" raised for an
initialized variable.
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.pelissier at gmail dot com
Target Milestone: ---
For the following program:
#include
#include
jmp_buf buf;
jmp_buf buf1;
typedef struct ry_s {
struct ry_s *next;
} ry_t[1];
struct ry_s *m_global;
static inline void
ry_init(ry_t state)
{
m_global = state;
}
static inline void
ry_clear(ry_t state)
{
m_global = state->next;
}
int func2(void)
{
for(_Bool b = 1 ; b ; b = 0)
for(ry_t test1 ; b ; ry_clear(test1), b = 0 )
if (ry_init(test1), setjmp (buf) == 0)
{
FILE *f = fopen("tmp","wt");
if ((setjmp (buf1) == 0) )
{
fprintf(f, "This is a text\n");
fclose(f);
}
}
return 0;
}
When running with "-O2 -Wall -Wextra", I get the following warning:
: In function 'func2':
:31:17: warning: 'f' is used uninitialized [-Wuninitialized]
31 | FILE *f = fopen("tmp","wt");
whereas f is obviously initialized in the statement.
I am confused by this warning.
