[Bug c/110425] New: Docbug: missing name for builtin function (__builtin_alloca_with_align_and_max?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110425 Bug ID: 110425 Summary: Docbug: missing name for builtin function (__builtin_alloca_with_align_and_max?) Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: hv at crypt dot org Target Milestone: --- In https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html and https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Other-Builtins.html the section after the entry for __builtin_alloca_with_align() starts: Built-in Function: void * (size_t size, size_t alignment, size_t max_size) Similar to __builtin_alloca_with_align but takes an extra argument specifying an upper bound for size ... The name of the function is missing. Judging by the corresponding page for v12.3.0, it should be "__builtin_alloca_with_align_and_max".
[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329 --- Comment #5 from Hugo van der Sanden --- (In reply to Martin Sebor from comment #4) > For functions like pthread_getspecific() and pthread_setspecific() that do > not access the object GCC provides attribute access none to suppress the > warning: > > extern __attribute__ ((access (none, 1))) void f1 (const void *pointer); Well that's not a solution for developers of perl, since these system headers are not under our control. I'm not sure it's a solution right now for developers of those system headers either, since adding the attribute yields a different warning under slightly earlier versions of gcc, eg with gcc-9.2.1: test.c:8:1: warning: 'access' attribute directive ignored [-Wattributes] 8 | extern int pthread_setspecific (unsigned int key, const void *pointer) __attribute__ ((access (none, 2))); | ^~ I think we still find the original sort of maybe-uninitialized warnings useful, so we'll probably just do the useless initialization, and the code will run a bit slower under gcc.
[Bug c/102381] New: unexpected -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102381
Bug ID: 102381
Summary: unexpected -Wmaybe-uninitialized
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hv at crypt dot org
Target Milestone: ---
This is reduced from perl source code. Reduction was a challenge, so there's a
risk the essence may have been lost.
The following code gives a -Wmaybe-uninitialized warning with each of "gcc-7
(Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0", "gcc-9 (Ubuntu 9.2.1-17ubuntu1~18.04.1)
9.2.1 20191102" and self-built "gcc (GCC) 11.2.0".
% cat test.c
extern void fail(void) __attribute__((__noreturn__));
int** f(void);
extern int *ip;
extern int i2, i3;
void test(int i1) {
int **ipp;
if (i1) {
ipp = f();
}
for (int i4 = 0; i4 < i2; i4++) {
if (((i3 & 1) != 1) && ((i3 & 3) != 3))
fail();
}
if (i1) {
ip = *ipp;
}
return;
}
% gcc -c -Wmaybe-uninitialized -O1 test.c
test.c: In function 'test':
test.c:18:14: warning: 'ipp' may be used uninitialized in this function
[-Wmaybe-uninitialized]
ip = *ipp;
^~~~
%
I think it should be clear that i1 does not change within this code, and the
'ip = *ipp' therefore cannot be reached without also previously having reached
'ipp = f()'. The sensitivity of the intervening code suggests this must be a
bug, eg replacing 'if (((i3 & 1) != 1) && ((i3 & 3) != 3))' with 'if ((i3 & 3)
!= 3)' makes the warning disappear.
[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329 --- Comment #2 from Hugo van der Sanden --- I guess this is justified by the second paragraph of the -Wmaybe-uninitialized docs: "In addition, passing a pointer (or in C++, a reference) to an uninitialized object to a const-qualified function argument is also diagnosed by this warning." Firstly, I'd request for this case that the wording of the diagnostic should clarify that it's the data pointed to that may be used uninitialized rather than the pointer itself. Secondly, I think there's a case to be made that 'const void *' should specifically be exempt from this warning: that a void* is not "a pointer to an object". (The specific call in the original code was to pthread_getspecific(); it seems reasonable that it should take a 'const void *' as its second argument.)
[Bug c/102329] New: pointer "maybe uninitialized" right after assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329
Bug ID: 102329
Summary: pointer "maybe uninitialized" right after assignment
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hv at crypt dot org
Target Milestone: ---
Reduced from perl source code:
% cat test.c
extern void *malloc (long unsigned int size);
extern void f1 (const void *pointer);
void perl_alloc(void) {
void *vp1 = malloc(1);
/* *(char*)vp1 = 0; */
f1((const void *)vp1);
}
% gcc-11.2.0 -c -Wmaybe-uninitialized -O2 test.c
test.c: In function 'perl_alloc':
test.c:7:5: warning: 'vp1' may be used uninitialized [-Wmaybe-uninitialized]
8 | f1((const void *)vp1);
| ^
test.c:2:13: note: by argument 1 of type 'const void *' to 'f1' declared here
3 | extern void f1 (const void *pointer);
| ^~
%
This build of gcc was configured as follows (including the error in prefix):
../gcc/configure --prefix=/opt/gcc-12 --disable-gcov --disable-multilib
--enable-languages=c --disable-nls --disable-decimal-float
No warning is seen under my system "gcc-9 (Ubuntu 9.2.1-17ubuntu1~18.04.1)
9.2.1 20191102", nor does 11.2.0 complain if the commented-out assignment is
uncommented, nor if 'malloc' is renamed to 'f2', nor if 'const' is removed from
the signature of f1 along with the corresponding cast.
Is the warning intended to imply that the memory pointed to by vp1 may be
uninitialized, rather than vp1 itself? If so, perhaps it is only that the
message is misleadingly worded, and making possibly inappropriate assumptions
about what f1() may do.
[Bug c/102291] New: dubious overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102291
Bug ID: 102291
Summary: dubious overflow warning
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hv at crypt dot org
Target Milestone: ---
The following code warns with gcc-11.2.0 (but not with 9.2.1-17ubuntu1~18.04.1)
in testera(), but not in testerb() which differs only by the removal of an
assert. I don't understand this, and cannot see what is overflowing.
This is reduced from a report against the UTF8_ACCUMULATE macro in perl source.
This build of gcc was configured as follows (including the error in prefix):
../gcc/configure --prefix=/opt/gcc-12 --disable-gcov --disable-multilib
--enable-languages=c --disable-nls --disable-decimal-float
% uname -a
Linux zen2 5.4.0-73-generic #82~18.04.1-Ubuntu SMP Fri Apr 16 15:10:02 UTC 2021
x86_64 x86_64 x86_64 GNU/Linux
% gcc --version | head -1
gcc (GCC) 11.2.0
% cat test.c
/* #include */
extern void __assert_fail (const char *__assertion, const char *__file,
unsigned int __line, const char *__function)
__attribute__ ((__nothrow__ , __leaf__))
__attribute__ ((__noreturn__));
#define assert(expr) \
((void) sizeof ((expr) ? 1 : 0), __extension__ ({ \
if (expr) \
; /* empty */ \
else \
__assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION); \
}))
#define __ASSERT_FUNCTION__extension__ __PRETTY_FUNCTION__
/* end assert.h */
typedef unsigned long ulong;
typedef unsigned char uchar;
#define FIT8(c) assert(((sizeof(c) == 1) || (((ulong) (c)) >> 8) == 0))
#define BE8a(c) (FIT8(c), ((uchar) (c)))
#define BE8b(c) ( ((uchar) (c)))
#define NUM(c) ((c) | 0)
#define TESTER(old, new) ulong)(old)) << 6) | (((uchar) NUM(new)) & 0x3f))
ulong testera(ulong ul) {
return TESTER(ul, BE8a(0x80));
}
ulong testerb(ulong ul) {
return TESTER(ul, BE8b(0x80));
}
% gcc -c test.c
test.c: In function 'testera':
test.c:24:49: warning: overflow in conversion from 'int' to 'long unsigned int'
changes value from 'void)4, (({...}))), 128)) & 63' to '0' [-Woverflow]
24 | #define TESTERa(old, new) ulong)(old)) << 6) | (((uchar) NUM(new))
& 0x3f))
| ^
test.c:27:12: note: in expansion of macro 'TESTERa'
27 | return TESTERa(ul, BE8a(0x80));
|^~~
%
