[Bug c/90219] New: Wrong source location for "cannot convert to a pointer type" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90219
Bug ID: 90219
Summary: Wrong source location for "cannot convert to a pointer
type" warning
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tbaeder at redhat dot com
Target Milestone: ---
Using gcc 8.3.1 and the following sample code:
static int use_float(float *f) {
return (int)*f;
}
// Type your code here, or load an example.
int square(int num) {
float f = 1.0f;
return use_float((float*)f);
}
it prints the following error:
: In function 'square':
:8:5: error: cannot convert to a pointer type
return use_float((float*)f);
^~
which is highlighting the wrong part of that line. The error message itself
could be improved as well (I forgot to take the address of f of course!) but I
think the cast should be highlighted.
If use_float() is instead called stand-alone and not as part of the return
statment:
int square(int num) {
float f = 1.0f;
use_float((float*)f);
return 1;
}
The source location is slightly better:
: In function 'square':
:8:5: error: cannot convert to a pointer type
use_float((float*)f);
^
[Bug c/90219] Wrong source location for "cannot convert to a pointer type" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90219 --- Comment #2 from Timm Bäder --- (In reply to Jonathan Wakely from comment #1) > Well if you took the address you wouldn't need to cast it to (float*) Sure, this was just a dumbed-down version of the original code.
[Bug other/98733] New: libiberty (v)asprintf checks do not work if asprintf() is a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98733
Bug ID: 98733
Summary: libiberty (v)asprintf checks do not work if asprintf()
is a macro
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: tbaeder at redhat dot com
Target Milestone: ---
The include/libiberty.h file has a check before declaring asprintf:
#if defined(HAVE_DECL_ASPRINTF) && !HAVE_DECL_ASPRINTF
extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2;
#endif
via a ac_fn_c_check_decl call in libiberty's configure script,
HAVE_DECL_ASPRINTF is defined when the following code sample compiles without
errors:
#include
/* ... tons of includes and constant definitions ... */
int
main()
{
(void) asprintf;
return 0;
}
This compiles if asprintf is defined as a function but fails if it is a macro,
which can be tested in this godbolt.org test: https://godbolt.org/z/T5n17c
This is the case for asprintf when stdio.h includes bits/stdio2.h and the
compiler does not support va_arg_pack().
The former happens via stdio.h when the _FORTIFY_SOURCE level is > 0 and
__fortify_function is defined:
https://sourceware.org/git/?p=glibc.git;a=blob;f=libio/stdio.h;h=144137cf67aadac3e86844e37f0fe47c45072fd3;hb=HEAD#l866
and the latter causes the definition of asprintf() as a
macro:https://sourceware.org/git/?p=glibc.git;a=blob;f=libio/bits/stdio2.h;h=3f0cab1254b02c4348dcd961e38b9805c7cbe834;hb=HEAD#l206
Given this combination, HAVE_DECL_ASPRINTF is 0, which means libiberty will in
the end declare its own asprintf, via include/libiberty.h:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=include/libiberty.h;h=f4c0fe11d6fe3fe0e1cc44c7c6f6266c97c263e4;hb=HEAD#l655
... which will then fail:
../../libiberty/../include/libiberty.h:627:12: error: expected parameter
declarator
extern int asprintf (char **, const char *, ...) ATTRIBUTE_PRINTF_2;
^
/usr/include/bits/stdio2.h:207:24: note: expanded from macro 'asprintf'
__asprintf_chk (ptr, __USE_FORTIFY_LEVEL - 1, __VA_ARGS__)
Clang does not support va_arg_pack(), so this failure occurs when using clang.
[Bug c/90219] Wrong source location for "cannot convert to a pointer type" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90219 Timm Bäder changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Timm Bäder --- This seems to be fixed in recent versions of GCC: https://godbolt.org/z/53zdv5KMe
[Bug other/98733] libiberty (v)asprintf checks do not work if asprintf() is a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98733 --- Comment #1 from Timm Bäder --- I looked into this problem again and I think a potential fix could be as easy as... commit b95eed1938403874be927d4c25b8bbf88ed686ce (HEAD -> master) Author: Timm Bäder Date: Mon May 10 09:33:26 2021 +0200 libiberty: Check for asprintf/snprintf macros asprintf and snprintf might be defined as a macro, in which case the declarations in libiberty.h should be omitted. This is in particular true for compilers that do not support __va_arg_pack(). diff --git a/include/libiberty.h b/include/libiberty.h index f4c0fe11d6f..51a5bf91219 100644 --- a/include/libiberty.h +++ b/include/libiberty.h @@ -648,7 +648,7 @@ extern void *bsearch_r (const void *, const void *, int (*)(const void *, const void *, void *), void *); -#if defined(HAVE_DECL_ASPRINTF) && !HAVE_DECL_ASPRINTF +#if defined(HAVE_DECL_ASPRINTF) && !HAVE_DECL_ASPRINTF && !defined(asprintf) /* Like sprintf but provides a pointer to malloc'd storage, which must be freed by the caller. */ @@ -672,7 +672,7 @@ extern int vasprintf (char **, const char *, va_list) ATTRIBUTE_PRINTF(2,0); extern char *xvasprintf (const char *, va_list) ATTRIBUTE_MALLOC ATTRIBUTE_PRINTF(1,0); -#if defined(HAVE_DECL_SNPRINTF) && !HAVE_DECL_SNPRINTF +#if defined(HAVE_DECL_SNPRINTF) && !HAVE_DECL_SNPRINTF && !defined(snprintf) /* Like sprintf but prints at most N characters. */ extern int snprintf (char *, size_t, const char *, ...) ATTRIBUTE_PRINTF_3; #endif Does that seem like a sensible thing to do on the GCC side?
[Bug c++/117727] New: __builtin_bit_cast with target type nullptr_t unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117727 Bug ID: 117727 Summary: __builtin_bit_cast with target type nullptr_t unimplemented Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tbaeder at redhat dot com Target Milestone: --- See this example code: typedef __UINTPTR_TYPE__ uintptr_t; constexpr uintptr_t A = __builtin_bit_cast(uintptr_t, nullptr); static_assert(A == 0); typedef decltype(nullptr) nullptr_t; constexpr decltype(nullptr) N = __builtin_bit_cast(nullptr_t, (uintptr_t)12); static_assert(N == nullptr); The first bitcast works, but the second one doesn't: array.cpp:30:52: sorry, unimplemented: ‘__builtin_bit_cast’ cannot be constant evaluated because the argument cannot be interpreted 30 | constexpr decltype(nullptr) N = __builtin_bit_cast(nullptr_t, (uintptr_t)12); |^ I think this should work similarly. I checked that using std::nullptr_t from has the same problem.
[Bug c++/117727] __builtin_bit_cast with target type nullptr_t unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117727 --- Comment #4 from Timm Bäder --- (In reply to Jakub Jelinek from comment #2) > I thought all the bits of the type are padding bits (given that reads of > std::nullptr_t typed objects just don't read any of the bits and simply > result in nullptr). Is this (all bits if a nullptr_t being padding bits) in the spec or are you referring to gcc's implementation? (In reply to Andrew Pinski from comment #3) > So in summary all 3 compilers have different behavior. FWIW I opened https://github.com/llvm/llvm-project/issues/117166 on the clang side.
[Bug c++/119567] New: "unknown operator" in pointer subtraction diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119567 Bug ID: 119567 Summary: "unknown operator" in pointer subtraction diagnostic Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tbaeder at redhat dot com Target Milestone: --- See: https://godbolt.org/z/fnPn844oY constexpr int (*p1)[0] = 0, (*p2)[0] = 0; constexpr int k2 = p2 - p1; prints: :4:23: error: arithmetic on pointer to an empty aggregate 4 | constexpr int k2 = p2 - p1; |~~~^~~~ :4:23: error: '(0 0)' is not a constant expression Not sure if the two 0s are correct either, but the "unknown operator" for a subtraction seems very wrong.
