(gcc-3.1/gcc/cp/method.c:428) DefaultPrintfPort.cxx:20: generic thunk code fails for method `virtual void DefaultPrintfPort::p(char*, ...)' which uses `...' Release: 3.1 Environment: Reading specs from /home/baallan/gcj/311_nothreads/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs Configured with: ../../gcj/gcc-3.1/configure --prefix=/home/baallan/gcj/311_nothreads --enable-threads=single Thread model: single gcc version 3.1 redhat linux 7.3 mandrake linux 8.0 i686 no LD_LIBRARY_PATH set /home/baallan/bin:/home/baallan/mpich124-311_nothreads/bin:/home/baallan/gcj/311_nothreads/bin:/usr/kerberos/bin:/usr/local/java/j2sdk1.4.0_01/bin:/usr/local/gcc/3.1/bin:/usr/local/bin:/bin:/usr/bin:/home/baallan/bin:/usr/X11R6/bin How-To-Repeat: g++ snip.i # run the file attachment through g++ w/no arguments
Fix: unknown. if production is illegal (no ellipsis in c++ virt funcs?) change error message to compliance warning/error.
State-Changed-From-To: open->analyzed State-Changed-Why: known bug with thunk code
State-Changed-From-To: analyzed->closed State-Changed-Why: Reduced snippet: ------------------------------------------------- struct A { virtual void func(...) = 0; }; struct B : virtual A { virtual void func(...); }; void B::func(...) {} ------------------------------------------------- pr7618.cpp:12: generic thunk code fails for method `virtual void B::func(...)' which uses `...' Fixed in 3.3 CVS 20030421 and 3.4 CVS 20030430. It might have been fixed in 3.2.3 as well.
State-Changed-From-To: closed->analyzed State-Changed-Why: The bug is still present on mips-sgi-irix6.5 (3.3 branch, mainline).
*** Bug 11982 has been marked as a duplicate of this bug. ***
I can reproduce this in 3.3.2 (20030815) on powerpc-apple-darwin6.6. It might also happen on other targets, it is target dependent because where it fails is after calling targetm.asm_out.can_output_mi_thunk.
The change which fixed this on the mainline is for PPC is: 2003-01-08 David Edelsohn * config/rs6000/rs6000.h (FUNCTION_MODE): Always use SImode. * config/rs6000/rs6000.c (TARGET_ASM_CAN_OUTPUT_MI_THUNK): Redefine as hook_bool_tree_hwi_hwi_tree_true. (rs6000_emit_allocate_stack): Use TARGET_32BIT. (rs6000_emit_epilogue): Same. (rs6000_output_mi_thunk): Re-implement as RTL. * config/rs6000/xcoff.h (ASM_DECLARE_FUNCTION_NAME): Call xcoffout_declare_function if any debugging enabled. So it looks like every target needs to do something like this which means it is most likely will not be fixed for 3.3.
2.95.3 accepted this, note this is only 3.3 regression for powerpc-*-*, mips has not been fixed on the mainline yet, there might be other targets which do not accept this. Here are a listof targets (or I think will not accept this by looking at the config files) which does not accept this: arc avr c4x d30x dsp16xx fr30 h8300 i370 i860 i960 ip2k iq2000 m32r m68hc11 m88k mcore mips mmix mn10300 ns32k pdp11 v850 xtensa
The only major target in this is MIPS.
Eric says he will deal with this for MIPS at least.
I posted a sample patch for the MIPS backend here: http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01199.html This needs to be checked by someone with access to real hardware.
Subject: Bug 7618 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: rsandifo@gcc.gnu.org 2004-01-18 09:44:59 Modified files: gcc : ChangeLog gcc/config/mips: mips.c Log message: PR target/7618 * config/mips/mips.c: Include cfglayout.h. (TARGET_ASM_OUTPUT_MI_THUNK, TARGET_ASM_CAN_OUTPUT_MI_THUNK): Define. (mips_unspec_offset_high): Add temporary register argument. (mips_load_call_address): New function, split out from... (mips_expand_call): ...here. (mips_output_cplocal): New function. (mips_output_function_prologue, mips_output_function_epilogue): Use it. (mips_emit_loadgp): New function, split out from... (mips_expand_prologue): ...here. (mips_output_mi_thunk): New function. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.16&r2=2.2326.2.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/mips/mips.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.362&r2=1.362.4.1
Patch for MIPS committed. Given Andrew's comment: The only major target in this is MIPS. and given that this PR is specifically against the MIPS port, I'll go ahead and close it.
Subject: Re: [3.3/3.4/3.5 Regression] GCC 3.x vararg disallowed in virtual function "rsandifo at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | Patch for MIPS committed. Given Andrew's comment: | | The only major target in this is MIPS. | | and given that this PR is specifically against the MIPS port, I'll go | ahead and close it. Do you intend to have it fixed on gcc-3_3-branch too? -- Gaby
Richard, from the commit message, it looks like this went in in the gcc-3_4- branch only. But this is a 3.3/3.4/3.5 regression, so you should port your fix at least to mainline too. Also, as Gaby have just asked, is it possible/feasable to backport this to the 3.3 branch as well?
Subject: Re: [3.3/3.4/3.5 Regression] GCC 3.x vararg disallowed in virtual function "giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes: > Richard, from the commit message, it looks like this went in in the gcc-3_4- > branch only. But this is a 3.3/3.4/3.5 regression, so you should port your fix > at least to mainline too. It went into both, I just forgot to add the PR marker when making the initial mainline commit. FWIW, I did add it afterwards, but that didn't seem to trigger the automatic message. > Also, as Gaby have just asked, is it possible/feasable to backport > this to the 3.3 branch as well? Not really. The port has changed too much in the meantime. Richard
Subject: Re: [3.3/3.4/3.5 Regression] GCC 3.x vararg disallowed in virtual function "rsandifo at redhat dot com" <gcc-bugzilla@gcc.gnu.org> writes: | > Also, as Gaby have just asked, is it possible/feasable to backport | > this to the 3.3 branch as well? | | Not really. The port has changed too much in the meantime. OK. Thanks! -- Gaby