[Bug c/65331] New: C99 format macros doesn't accept bit fields for 64-bit integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65331 Bug ID: 65331 Summary: C99 format macros doesn't accept bit fields for 64-bit integer types Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dmitry.petroff at gmail dot com Created attachment 34976 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34976&action=edit compile with gcc -Werror=format Hi. I'm compiling my project with -Werror=format and compilation failt when I use bit fields of (u)int64_t type. I expected that bit fields wider than 32 bits will be compatible with PRIu64/PRIi64/PRIx64. This bug also appears in 4.8 branch (don't know about earlier versions).
[Bug c/65331] C99 format macros doesn't accept bit fields for 64-bit integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65331
--- Comment #1 from Dmitry Petrov ---
UPD: it appears that bug doesn't related to PRI* format specifiers:
-m64:
printf("%lu\n", value); // usigned long value:31 => error (ok)
printf("%lu\n", value); // usigned long value:33 => error (not ok IMHO)
-m32
printf("%lu\n", value); // usigned long long value:31 => compiles (ok)
printf("%llu\n", value); // usigned long long value:33 => error (not ok IMHO)
It seems that bit fields wider than 32 bits are'n treated as 64 bit integers
and need an explicit cast while fields of 32 bits width and less are propagated
to 32-bit integer type (int/unsigned int) and work just fine.
[Bug c++/62282] New: Undefined reference with __inline __attribute(__gnu_inline__) with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62282
Bug ID: 62282
Summary: Undefined reference with __inline
__attribute(__gnu_inline__) with -O0
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dmitry.petroff at gmail dot com
The following code produces "undefined reference to `test(int)'" message when
compiled with g++ -O0 test.cpp:
// == cut ==
__inline
__attribute__ ((__gnu_inline__))
int test(int v)
{
return v;
}
int main(int argc, char **argv)
{
return test(argc);
}
// == cut ==
It links successfully in C mode.
This bug breaks for me usage of gperf's C output in C++ code with simple
"include" directive.
[Bug c++/62282] Undefined reference with __inline __attribute(__gnu_inline__) with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62282 --- Comment #3 from Dmitry Petrov --- Created attachment 33408 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33408&action=edit g++ + gperf bug in action Guys, I'm software developer myself and I can understand your attitute to "declare bug as a feature". But please note, that this bug is breaking normal development with gperf which is also a GNU tool. In the attached archive try make => failure in compiling bug++ make CFLAGS=-O => success, inlining happens make CXX=clang++ => success You're saying "we've designed this extension and it works as it should". But why gcc links this successfully, but g++ don't? It looks like either C or C++ compiler bug. P. S. I'm using gperf to generate code for both C server-side and C++ tools/testcases and such g++ behaviour is really unpleasing when making debug builds.
[Bug c++/62282] [4.8/4.9/5 Regression] Undefined reference with __inline __attribute(__gnu_inline__) with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62282 Dmitry Petrov changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #9 from Dmitry Petrov --- Jakub, so you telling that different behaviour of gcc and g++ is ok in this case? With gcc inline + gnu_inline does not yields undefined references. And before you advice me to not use such constructions in my code, please note that problem appears in gperf output. So people have to use ugly #undef workarounds or even more ugly sed tricks or just don't use gperf's C output with g++ when debugging. And I'm sorry to be that insistent but >G++ 4.3 was the first release to support gnu_inline attribute in C++ is not true: g++-4.1 supported gnu_inline at some point: http://www.redhat.com/archives/fedora-extras-commits/2007-September/msg00089.html
[Bug c++/62282] [4.8/4.9/5 Regression] Undefined reference with __inline __attribute(__gnu_inline__) with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62282
--- Comment #11 from Dmitry Petrov ---
>Which of the above mentioned semantics you want for your inlines?
Semantics that would allow me get code that links even with -O0 without need to
dublicate function body.
I can understand how this code can produce an undefined reference:
// === cut ===
__inline
__attribute__ ((__gnu_inline__))
int test(int v)
{
return v;
}
int main(int argc, char **argv)
{
return test(argc);
}
// === cut ===
With -O0 gcc is not inlining, then __inline + gnu_inline comes into play by
prohibiting generation test's body. So there's main function that has "call
U(_Z4testi)" instruction but there's no way to actually get test address. That
is logical, but insane.
Is there an easy way to get debugger-friendly (-O0) compiler output other than
provide an exact function copy but without __inline
__attribute__((__gnu_inline__))?
>From what I see, I have to pipe gperf's output to sed -e
's/__gnu__inline__/\0,__always_inline__/', but this seems so ugly that GNU
tools cannot cooperate with each other.
