[Bug c++/77502] -Wzero-as-null-pointer-constant : misleading/imprecise messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77502
Rolf Eike Beer changed:
What|Removed |Added
CC||e...@sf-mail.de
--- Comment #4 from Rolf Eike Beer ---
Here is another case (all on a Gentoo system):
buildbot@castor ~ $ cat gnull.cpp
#include
#include
void foo(GObject *g)
{
g_object_set_data(g, "b", GINT_TO_POINTER(FALSE));
}
buildbot@castor ~ $ sparc-unknown-linux-gnu-gcc-8.3.0 $(pkg-config --cflags
glib-2.0) $(pkg-config --cflags gtk+-2.0) -c -Wzero-as-null-pointer-constant
gnull.cpp
In file included from /usr/include/glib-2.0/glib/gtypes.h:32,
from /usr/include/glib-2.0/glib/galloca.h:32,
from /usr/include/glib-2.0/glib.h:30,
from gnull.cpp:1:
gnull.cpp: In function 'void foo(GObject*)':
/usr/lib/glib-2.0/include/glibconfig.h:90:50: warning: zero as null pointer
constant [-Wzero-as-null-pointer-constant]
#define GINT_TO_POINTER(i) ((gpointer) (glong) (i))
^
gnull.cpp:6:31: note: in expansion of macro 'GINT_TO_POINTER'
g_object_set_data(g, "b", GINT_TO_POINTER(FALSE));
Now with gcc 9.2.
buildbot@castor ~ $ gcc $(pkg-config --cflags glib-2.0) $(pkg-config --cflags
gtk+-2.0) -c -Wzero-as-null-pointer-constant gnull.cpp
# no diagnostics, fine with me
# and now I change the macro to use "glong" instead of "gint" in glibconfig.h I
get different output (same for gcc 8 and 9):
buildbot@castor ~ $ gcc $(pkg-config --cflags glib-2.0) $(pkg-config --cflags
gtk+-2.0) -c -Wzero-as-null-pointer-constant gnull.cpp
gnull.cpp: In function 'void foo(GObject*)':
gnull.cpp:7:1: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
7 | }
| ^
# that was my sparc with 32 bit userland, now my amd64 (openSUSE):
gcc (SUSE Linux) 7.4.1 20190424 [gcc-7-branch revision 270538]
eike@daneel:~$ gcc $(pkg-config --cflags glib-2.0) $(pkg-config --cflags
gtk+-2.0) -c -Wzero-as-null-pointer-constant gnull.cpp
In file included from /usr/include/glib-2.0/glib/gtypes.h:32:0,
from /usr/include/glib-2.0/glib/galloca.h:32,
from /usr/include/glib-2.0/glib.h:30,
from gnull.cpp:1:
gnull.cpp: In function ‘void foo(GObject*)’:
/usr/lib64/glib-2.0/include/glibconfig.h:90:50: warning: zero as null pointer
constant [-Wzero-as-null-pointer-constant]
#define GINT_TO_POINTER(i) ((gpointer) (glong) (i))
^
gnull.cpp:6:31: note: in expansion of macro ‘GINT_TO_POINTER’
g_object_set_data(g, "b", GINT_TO_POINTER(FALSE));
^~~
When I have the relevant code in a greater function (
https://github.com/osm2go/osm2go/blob/6a7b955053ef9938f4be7b7ca8eacb99e4c426cf/src/platforms/gtk/osm_upload_dialog.cpp#L143
) this does _not_ warn on my PC, but it warns on the sparc.
[Bug driver/70936] Hard-coded C++ header paths and relocation problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936 --- Comment #14 from Rolf Eike Beer <e...@sf-mail.de> --- Still broken in 7.1.0.
[Bug driver/70936] Hard-coded C++ header paths and relocation problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936 --- Comment #13 from Rolf Eike Beer <e...@sf-mail.de> --- 6.2.0 also broken, 5.4.0 is fine.
[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936 --- Comment #11 from Rolf Eike Beer <e...@sf-mail.de> --- I configured with: ../gcc-host/configure --target=i686-unknown-linux-gnu --host=x86_64-pc-linux- gnu --build=x86_64-pc-linux-gnu --program-prefix=i686-unknown-linux-gnu- -- with-sysroot=/opt/emlix/test/sysroot --with-build-sysroot=/opt/emlix/test/ sysroot --with-gxx-include-dir=/opt/emlix/test/sysroot/usr/include/c++/6.2.0 --with-gnu-as --with-gnu-ld --enable-__cxa_atexit --enable-c99 --enable- clocale=gnu --with-system-zlib --enable-long-long --disable-multilib --enable- threads=posix --prefix=/opt/emlix/test --mandir=/opt/emlix/test/share/man -- infodir=/opt/emlix/test/share/info --enable-libssp --enable-libgomp --disable- gcj --disable-sjlj-exceptions --enable-languages=c,c++ --disable-interpreter --disable-libstdcxx-pch --with-gmp=/opt/emlix/test --with-mpfr=/opt/emlix/test --with-mpc=/opt/emlix/test --without-ppl --without-cloog --with-slibdir=/opt/ emlix/test/sysroot/lib --with-build-time-tools=/opt/emlix/test/i686-unknown- linux-gnu/bin '--with-pkgversion=emlix Linux Test-BSP' Please note that the --with-gxx-include-dir is not the culprit, the failure happens also without it.
[Bug driver/70936] Hard-coded C++ header paths and relocation problem on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70936 Rolf Eike Beer <e...@sf-mail.de> changed: What|Removed |Added CC| |e...@sf-mail.de --- Comment #10 from Rolf Eike Beer <e...@sf-mail.de> --- Just as a heads up: I have this problem also with a Linux/Linux cross toolchain. Details will follow, will do some additional tests first.
[Bug c++/43734] cerr related segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734 --- Comment #13 from Rolf Eike Beer e...@sf-mail.de --- Ok, it looks like this is no gcc problem. If I rebuild gcc with binutils 2.22 it works. If I compile gcc with binutils 2.23.[12] it fails. Having a gcc built with binutils 2.23.2 and building the program with binutils 2.22 it also fails. So the solution (for the moment) is to build gcc with binutils 2.22 and everything is fine.
[Bug c++/43734] cerr related segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734 --- Comment #11 from Rolf Eike Beer e...@sf-mail.de --- I don't have the least idea what's going on here, and cannot debug issues on Linux/SPARC since I don't have access to that platform. Sadly I can't give you direct access to my machine, but I'm willing to assist on any debugging needed. Meanwhile a second user was able to reproduce the issue on an independent system. We are hanging around in #gentoo-sparc on Freenode in case you want to join us.
[Bug c++/43734] cerr related segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734
Rolf Eike Beer e...@sf-mail.de changed:
What|Removed |Added
CC||e...@sf-mail.de
--- Comment #8 from Rolf Eike Beer e...@sf-mail.de ---
I get the same problem using gcc 4.5, 4.7, and 4.8 on a Sun Fire V240 running
Gentoo. Even if the compiler says Gentoo it is built with use flag vanilla,
i.e. without any Gentoo patches.
The test code is simply:
#include iostream
int main(void) {
std::cerr test;
return 0;
}
Which will output test and then segfault. I can reproduce this at will and
can give you further information (traces, asm, poking with gdb, whatever), just
ask. I have tried it with both binutils 2.23.1 and .2, the result is the same:
buildbot@alrakis ~ $ g++ -v -save-temps -g test.cpp -mcpu=native
Using built-in specs.
COLLECT_GCC=/usr/sparc-unknown-linux-gnu/gcc-bin/4.8.2/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc-unknown-linux-gnu/4.8.2/lto-wrapper
Target: sparc-unknown-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.8.2/work/gcc-4.8.2/configure
--prefix=/usr --bindir=/usr/sparc-unknown-linux-gnu/gcc-bin/4.8.2
--includedir=/usr/lib/gcc/sparc-unknown-linux-gnu/4.8.2/include
--datadir=/usr/share/gcc-data/sparc-unknown-linux-gnu/4.8.2
--mandir=/usr/share/gcc-data/sparc-unknown-linux-gnu/4.8.2/man
--infodir=/usr/share/gcc-data/sparc-unknown-linux-gnu/4.8.2/info
--with-gxx-include-dir=/usr/lib/gcc/sparc-unknown-linux-gnu/4.8.2/include/g++-v4
--host=sparc-unknown-linux-gnu --build=sparc-unknown-linux-gnu
--disable-altivec --disable-fixed-point --without-cloog --disable-lto
--disable-nls --with-system-zlib --enable-obsolete --disable-werror
--enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/sparc-unknown-linux-gnu/4.8.2/python
--enable-checking=release --disable-libgcj --enable-libstdcxx-time
--disable-libquadmath --enable-languages=c,c++ --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-targets=all --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.8.2'
Thread model: posix
gcc version 4.8.2 (Gentoo 4.8.2)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-g' '-o' 'cmtest48' '-shared-libgcc'
'-mcpu=ultrasparc3'
/usr/libexec/gcc/sparc-unknown-linux-gnu/4.8.2/cc1plus -E -quiet -v
-D_GNU_SOURCE -D__sparc_v9__ args.cpp -mcpu=ultrasparc3 -g -fworking-directory
-fpch-preprocess -o args.ii
ignoring nonexistent directory /usr/local/include
ignoring nonexistent directory
/usr/lib/gcc/sparc-unknown-linux-gnu/4.8.2/../../../../sparc-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/sparc-unknown-linux-gnu/4.8.2/include/g++-v4
/usr/lib/gcc/sparc-unknown-linux-gnu/4.8.2/include/g++-v4/sparc-unknown-linux-gnu
/usr/lib/gcc/sparc-unknown-linux-gnu/4.8.2/include/g++-v4/backward
/usr/lib/gcc/sparc-unknown-linux-gnu/4.8.2/include
/usr/lib/gcc/sparc-unknown-linux-gnu/4.8.2/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-g' '-o' 'cmtest48' '-shared-libgcc'
'-mcpu=ultrasparc3'
/usr/libexec/gcc/sparc-unknown-linux-gnu/4.8.2/cc1plus -fpreprocessed args.ii
-quiet -dumpbase args.cpp -mcpu=ultrasparc3 -auxbase args -g -version -o args.s
GNU C++ (Gentoo 4.8.2) version 4.8.2 (sparc-unknown-linux-gnu)
compiled by GNU C version 4.8.2, GMP version 5.0.2, MPFR version 3.1.1,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Gentoo 4.8.2) version 4.8.2 (sparc-unknown-linux-gnu)
compiled by GNU C version 4.8.2, GMP version 5.0.2, MPFR version 3.1.1,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8d0bbd26543db38471cca4be1a182624
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-g' '-o' 'cmtest48' '-shared-libgcc'
'-mcpu=ultrasparc3'
/usr/lib/gcc/sparc-unknown-linux-gnu/4.8.2/../../../../sparc-unknown-linux-gnu/bin/as
-v -s -Av9b -32 -relax -o args.o args.s
GNU assembler version 2.23.2 (sparc-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.23.2
COMPILER_PATH=/usr/libexec/gcc/sparc-unknown-linux-gnu/4.8.2/:/usr/libexec/gcc/sparc-unknown-linux-gnu/4.8.2/:/usr/libexec/gcc/sparc-unknown-linux-gnu/:/usr/lib/gcc/sparc-unknown-linux-gnu/4.8.2/:/usr/lib/gcc/sparc-unknown-linux-gnu/:/usr/lib/gcc/sparc-unknown-linux-gnu/4.8.2/../../../../sparc-unknown-linux-gnu/bin/
LIBRARY_PATH=/usr/lib/gcc/sparc-unknown-linux-gnu/4.8.2/:/usr/lib/gcc/sparc-unknown-linux-gnu/4.8.2/../../../../lib32/:/lib/../lib32/:/usr/lib/../lib32/:/usr/lib/gcc/sparc-unknown-linux-gnu/4.8.2/../../../../sparc-unknown-linux-gnu/lib/:/usr/lib/gcc/sparc-unknown-linux-gnu/4.8.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-g' '-o' 'cmtest48' '-shared-libgcc'
'-mcpu=ultrasparc3
[Bug c++/43734] cerr related segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734 --- Comment #9 from Rolf Eike Beer e...@sf-mail.de --- Created attachment 31314 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31314action=edit ii file of testcase
[Bug c++/50230] [4.5 regression] compiling CMake on PA-RISC fails due to unreachable symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50230 --- Comment #2 from Rolf Eike Beer e...@sf-mail.de 2011-09-05 15:48:10 UTC --- It is possible your tools are miscompiled. For example, some fixes to reorg were backported in May. These caused GCC to be miscompiled and produce incorrect code when optimizing at -O1 and above. Given that I can't duplicate the problem, further information is needed. Seems that trying to debug this issue now also destroyed the version I have on my system (or just the libstdc++, I don't know). What I did today is: rebuild binutils 2.21.1 using the gcc-4.5.3 I have installed rebuild binutils 2.21.1 using the gcc-4.5.3 I have installed once again rebuild gcc 4.5.3 rebuild binutils 2.21.1 again created new build directory cd this build directory /path/to/cmake-next/configure make This fails with: /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld: cmPropertyDefinitionMap.o(.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_[__gnu_cxx::new_allocatorstd::pairstd::basic_stringchar, std::char_traitschar, std::allocatorchar const, cmDocumentationSection* ::construct(std::pairstd::basic_stringchar, std::char_traitschar, std::allocatorchar const, cmDocumentationSection**, std::pairstd::basic_stringchar, std::char_traitschar, std::allocatorchar const, cmDocumentationSection* const)]+0x54): cannot reach 25c2__ZNSt4pairIKSsP22cmDocumentationSectionEC1ERKS3_+0, recompile with -ffunction-sections /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld: cmPropertyDefinitionMap.o(.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_[__gnu_cxx::new_allocatorstd::pairstd::basic_stringchar, std::char_traitschar, std::allocatorchar const, cmDocumentationSection* ::construct(std::pairstd::basic_stringchar, std::char_traitschar, std::allocatorchar const, cmDocumentationSection**, std::pairstd::basic_stringchar, std::char_traitschar, std::allocatorchar const, cmDocumentationSection* const)]+0x54): cannot handle R_PARISC_PCREL17F for std::pairstd::basic_stringchar, std::char_traitschar, std::allocatorchar const, cmDocumentationSection*::pair(std::pairstd::basic_stringchar, std::char_traitschar, std::allocatorchar const, cmDocumentationSection* const) /usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.3/../../../../hppa2.0-unknown-linux-gnu/bin/ld: final link failed: Bad value objdump shows this: objdump -x ./Bootstrap.cmk/cmPropertyDefinitionMap.o | grep _ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5 332 .text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_ 00a0 6008 2**2 ld .text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_ .text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_ wF .text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_ 00a0 _ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_ 09e0 R_PARISC_SEGREL32 .text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_ 09e4 R_PARISC_SEGREL32 .text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_+0x009c 0054 R_PARISC_PCREL17F _ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_ RELOCATION RECORDS FOR [.text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_]: 13b0 R_PARISC_PCREL32 .text._ZN9__gnu_cxx13new_allocatorISt4pairIKSsP22cmDocumentationSectionEE9constructEPS5_RKS5_+0x0008
[Bug target/46915] Wrong code is generated for conditional branch followed by zero length asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46915 --- Comment #12 from Rolf Eike Beer e...@sf-mail.de 2010-12-18 22:27:40 UTC --- Any chance this gets backported?
[Bug c/46936] New: turn __attribute__ ((nonnull (x))) into assert in debug mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46936
Summary: turn __attribute__ ((nonnull (x))) into assert in
debug mode
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: e...@sf-mail.de
I have this simple function to free a linked list:
void freeips(struct ips *p)
{
while (p) {
struct ips *thisip = p;
p = thisip-next;
free(thisip);
}
}
I accidentially annotated this as __attribute__ ((nonnull (1))) and called it
with a NULL argument. This still worked as long as I was building with -g. Once
I build this in release mode it crashed (correctly). I would like to have some
sort of automatic assert once I annotate a function this way. So when I build
this function annotated and pass NULL I get a meaningful crash and I can debug
this. If I need to explicitely switch this on by a command line switch it's
fine for me.
