[Bug c++/22260] New: -fPIC -fno-delayed-branch miscompiles MI this_adjusting thunks
/../../../../sparc-sun-solaris2.8/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/pkg/gcc-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.0.0/../../../../include/c++/4.0.0
/usr/local/pkg/gcc-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.0.0/../../../../include/c++/4.0.0/sparc-sun-solaris2.8
/usr/local/pkg/gcc-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.0.0/../../../../include/c++/4.0.0/backward
/usr/local/pkg/gcc-4.0.0/include
/usr/local/pkg/gcc-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.0.0/include
/usr/include
End of search list.
GNU C++ version 4.0.0 (sparc-sun-solaris2.8)
compiled by GNU C version 4.0.0.
GGC heuristics: --param ggc-min-expand=82 --param ggc-min-heapsize=98304
/usr/local/pkg/binutils-2.16/bin/as -V -Qy -s -K PIC -xarch=v8 -o
/var/tmp//ccwjroiT.o /var/tmp//ccaIczQW.s
GNU assembler version 2.16 (sparc-sun-solaris2.8) using BFD version 2.16
/usr/local/pkg/gcc-4.0.0/libexec/gcc/sparc-sun-solaris2.8/4.0.0/collect2 -V -R.
-Y P,/usr/ccs/lib:/usr/lib -rpath-link /usr/lib -Qy -o bug
/usr/local/pkg/gcc-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.0.0/crt1.o
/usr/local/pkg/gcc-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.0.0/crti.o
/usr/ccs/lib/values-Xa.o
/usr/local/pkg/gcc-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.0.0/crtbegin.o -L.
-L/usr/local/pkg/gcc-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.0.0 -L/usr/ccs/bin
-L/usr/ccs/lib
-L/usr/local/pkg/gcc-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.0.0/../../..
/var/tmp//ccwjroiT.o -lbug -lsupc++ -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -lc
-R/usr/local/pkg/gcc-4.0.0/lib
/usr/local/pkg/gcc-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.0.0/crtend.o
/usr/local/pkg/gcc-4.0.0/lib/gcc/sparc-sun-solaris2.8/4.0.0/crtn.o
GNU ld version 2.16
Supported emulations:
elf32_sparc
elf64_sparc
% ./bug || echo bad
bad
As shown by the execution of the program above, the apparent address of global
variable 'i' has changed after the destructor is invoked via the thunk. In
non-trivial use, a segv or other nasty is more likely to occur when the wrong
GOT is indexed.
The problem is easily worked around by specifying -fdelayed-branch (or using an
optimization level which does so implicitly) in which case the normal sibcall
instruction sequence is generated.
The problem appears to be that in sparc_output_mi_thunk(), the following code
sequence for a no delayed branch pic thunk protects %o7 (which is clobbered by
the call to the pic helper), but fails to protect the pic register %l7 itself
which is obviously altered by the pic helper. Since the register window has not
been saved at this point, %l7 will be left altered upon the eventual return to
the caller of the thunk. Looks like the code should protect (and restore before
the jump) both %o7 and %l7.
/* The hoops we have to jump through in order to generate a sibcall
without using delay slots... */
rtx spill_reg, seq, scratch = gen_rtx_REG (Pmode, 1);
if (flag_pic)
{
spill_reg = gen_rtx_REG (word_mode, 15); /* %o7 */
start_sequence ();
/* Delay emitting the PIC helper function because it needs to
change the section and we are emitting assembly code. */
load_pic_register (true); /* clobbers %o7 */
scratch = legitimize_pic_address (funexp, Pmode, scratch);
seq = get_insns ();
end_sequence ();
emit_and_preserve (seq, spill_reg);
}
--
Summary: -fPIC -fno-delayed-branch miscompiles MI this_adjusting
thunks
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scp at predict dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: 4.0.0
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22260
[Bug c++/20746] Incorrect return value for covariant return function returning null ptr
--- Additional Comments From scp at predict dot com 2005-06-30 21:00 --- This fix has not made it to the gcc_4_0 branch, and the problem still exists in gcc4.0.0. It is trivially recreated using the same test code: gcc -v -o cv cv.cpp -lstdc++ Reading specs from /usr/local/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.0/specs Target: sparc-sun-solaris2.8 Configured with: ../sources/gcc-4.0.0/configure --prefix=/opt/csw/gcc4 --with-local-prefix=/opt/csw --without-gnu-as --with-as=/usr/ccs/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --enable-shared --enable-multilib --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --enable-java-awt=xlib --with-system-zlib --enable-languages=c,c++,f95,java,objc,ada Thread model: posix gcc version 4.0.0 /usr/local/csw/gcc4/bin/../libexec/gcc/sparc-sun-solaris2.8/4.0.0/cc1plus -quiet -v -iprefix /usr/local/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.0/ cv.cpp -quiet -dumpbase cv.cpp -mcpu=v7 -auxbase cv -version -o /var/tmp//cc6dpjVx.s ignoring nonexistent directory "/usr/local/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.0/../../../../sparc-sun-solaris2.8/include" ignoring duplicate directory "/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.0/../../../../include/c++/4.0.0" ignoring duplicate directory "/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.0/../../../../include/c++/4.0.0/sparc-sun-solaris2.8" ignoring duplicate directory "/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.0/../../../../include/c++/4.0.0/backward" ignoring duplicate directory "/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.0/include" ignoring nonexistent directory "/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.0/../../../../sparc-sun-solaris2.8/include" #include "..." search starts here: #include <...> search starts here: /usr/local/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.0/../../../../include/c++/4.0.0 /usr/local/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.0/../../../../include/c++/4.0.0/sparc-sun-solaris2.8 /usr/local/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.0/../../../../include/c++/4.0.0/backward /usr/local/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.0/include /opt/csw/include /opt/csw/gcc4/include /usr/include End of search list. GNU C++ version 4.0.0 (sparc-sun-solaris2.8) compiled by GNU C version 4.0.0. GGC heuristics: --param ggc-min-expand=82 --param ggc-min-heapsize=98304 /usr/ccs/bin/as -V -Qy -s -xarch=v8 -o /var/tmp//ccwNutZ8.o /var/tmp//cc6dpjVx.s /usr/ccs/bin/as: Sun WorkShop 6 2003/12/18 Compiler Common 6.0 Patch 114802-02 /usr/local/csw/gcc4/bin/../libexec/gcc/sparc-sun-solaris2.8/4.0.0/collect2 -V -R /opt/csw/gcc4/lib -Y P,/opt/csw/gcc4/lib:/usr/ccs/lib:/usr/lib -Qy -o cv /usr/local/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.0/crt1.o /usr/local/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.0/crti.o /usr/ccs/lib/values-Xa.o /usr/local/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.0/crtbegin.o -L/usr/local/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.0 -L/usr/local/csw/gcc4/bin/../lib/gcc -L/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.0 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.0/../../.. -L/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.0/../../.. /var/tmp//ccwNutZ8.o -lstdc++ -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -lc /usr/local/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.0/crtend.o /usr/local/csw/gcc4/bin/../lib/gcc/sparc-sun-solaris2.8/4.0.0/crtn.o ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.293 % ./cv in C* C::l cp=8 Applying the patch to the gcc-4.0.0 release version fixes the problem: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/method.c.diff?cvsroot=gcc&r1=1.324&r2=1.325 How do I request that this fix be folded into the gcc_4_0 branch? -- What|Removed |Added -------------------- CC||scp at predict dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20746
[Bug c++/20746] Incorrect return value for covariant return function returning null ptr
--- Additional Comments From scp at predict dot com 2005-07-06 21:47 --- (In reply to comment #9) > the bug is not a regression, so it has not gone into 4.0. As there seems to > be > a need for it, and the patch is small, we could probably do it. Right now 4.0 > is frozen for 4.0.1 though Nathan, 4.0.2 is certainly fine by me. I've already applied the patch locally to 4.0.0, and will continue to do so until it is folded in to 4.0.X. I just wanted to clarify that there is a need for it for any code which has a function returning a pointer to derived class instance which is then assigned to a pointer to a virtual base class of that class type. I have plenty of non-trivial code which does this which is why I discovered the problem and your 3.4.X fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20746
