Bug 12007 - Multiple inheritance float pass by value fails
Summary: Multiple inheritance float pass by value fails
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.3
: P2 normal
Target Milestone: 4.0.0
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2003-08-21 12:30 UTC by Bill Wade
Modified: 2004-02-20 23:24 UTC (History)
2 users (show)

See Also:
Host: hppa1.1-hp-hpux10.20
Target: hppa1.1-hp-hpux10.20
Build: hppa1.1-hp-hpux10.20
Known to work:
Known to fail:
Last reconfirmed: 2004-01-18 01:34:24


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bill Wade 2003-08-21 12:30:17 UTC
When
  1) Passing a float by value to a virtual member function
  2) The actual object uses multiple inheritance with two base classes
and
  3) The member function in (1) is from the second base class
the wrong value is received in the member function.

Workarounds include changing the argument (function declaration) from float to 
double, or make the function's base class be the first base class.

The expected output of the following program is "3.14159".  I am 
seeing "0.00000"

// Reproduce putval bug with a small program

#include <stdio.h>

class gvImpl
{
public:
  virtual void PutVal(float value){}
};

class foo { public: virtual void Bar(){} };

class myGv: public foo, public gvImpl
{
  void PutVal(float value){ printf("%f\n", value); }
};

myGv x;
gvImpl* object = &x;

int main()
{
  object->PutVal(3.14159f);
  return 0;
}

Script started on Thu Aug 21 07:22:21 2003
Thu Aug 21 07:22:22 CDT 2003
sulu v940: g++ -v -save-temps mi.cpp
Reading specs from /usr/local/gcc-3.3/lib/gcc-lib/hppa1.1-hp-hpux10.20/3.3/s
pecs
Configured with: ../gcc-3.3/configure --prefix=/usr/local/gcc-3.3 --with-gnu-
as 
--with-as=/usr/local/bin/as
Thread model: single
gcc version 3.3
 /usr/local/gcc-3.3/lib/gcc-lib/hppa1.1-hp-hpux10.20/3.3/cc1plus -E -
D__GNUG__=3
 -quiet -v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 mi.cpp mi.ii

ignoring nonexistent directory "/usr/local/gcc-3.3/hppa1.1-hp-
hpux10.20/include"

#include "..." search starts here:
#include <...> search starts here:
 /usr/local/gcc-3.3/include/c++/3.3
 /usr/local/gcc-3.3/include/c++/3.3/hppa1.1-hp-hpux10.20
 /usr/local/gcc-3.3/include/c++/3.3/backward
 /usr/local/include
 /usr/local/gcc-3.3/include
 /usr/local/gcc-3.3/lib/gcc-lib/hppa1.1-hp-hpux10.20/3.3/include
 /usr/include
End of search list.
 /usr/local/gcc-3.3/lib/gcc-lib/hppa1.1-hp-hpux10.20/3.3/cc1plus -
fpreprocessed 
mi.ii -quiet -dumpbase mi.cpp -auxbase mi -version -o mi.s
GNU C++ version 3.3 (hppa1.1-hp-hpux10.20)
        compiled by GNU C version 3.3.
GGC heuristics: --param ggc-min-expand=42 --param ggc-min-heapsize=22528
 /usr/local/bin/as --traditional-format -o mi.o mi.s
 /usr/local/gcc-3.3/lib/gcc-lib/hppa1.1-hp-hpux10.20/3.3/collect2 -
L/lib/pa1.1 -
L/usr/lib/pa1.1 -z -u main /usr/ccs/lib/crt0.o -L/usr/local/gcc-3.3/lib/gcc-
lib/
hppa1.1-hp-hpux10.20/3.3 -L/usr/ccs/bin -L/usr/ccs/lib -L/opt/langtools/lib -
L/u
sr/local/gcc-3.3/lib mi.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
sulu v940: ./a.out
0.000000
sulu v940: gzip mi.ii
sulu v940: uuencode mi.ii.gz mi.ii.gz
begin 664 mi.ii.gz
M'XL("-FZ1#\``VUI+FEI`-5:66_C-A!^]Z\@$K2PLXD3'W&<=;L/+7HLL`]]
M*@JX@2!+E*-:5T7)3AKXOW=XZ20IIY`7:+`;.YQO[N%P*/L23=!%Z(^=)+D8
M7-(_OMOD?I#=^-$GN>#$86A'+@K\",M%R3+@?][F)+T-8L<.;K>.<S,;SVX#
M?\/>T]?G)+$GX\G-<P+_\I?)W7AZ=TM!?N0$N8MO2>;Z\?CY`F3-T)S*G/<H
M5(CL1:*=;JMVSF=]2J4RL]<$N]A#EL42X4?6WK8"GV2PLHUR1_ZYHB[=]QBE
M*5//?LI@%:A70I'D-215]Z=]YEX:T$^JP&`:RKJY?62K*KA>656(Y4=92_^B
M$UFM`.?93A$0EQ8D6R[F$?&W$78Y-6^2R7.<9I1ILE!R<7K>`L`"_3^;*KDH
M-2_(32;/)IF130+HCP0%<;3EOP"PF"OY2TQ>@&I"Q"I]#>V7F@Q)RDO:)7I\
M5_RE=4F6ZLW+2P`4PMWTOR38"C!$:,G=TR=:"1,YL#R#!)D'%:@H&"Z=5X5"
M1EDX:F#5#JV0FB$Z"4R\J#2#""6L:D6WB"I*755<BZP\%<!3T&O%IQ91AY1"
MH(86]^^I(;DM$10A]P7:7!^'9[7-58Z&`:(_E4@PY2[><]7SOELW58SD3\MI
M/XJ+]`U:$%IA*(Q=+#%J1`2#S:X*:7KG)3&IU$G#&)E)BI))?#C'0=/66UA7
MMZT5)H]L@IT397HGBGJ44.G)8]^UI/"D9:?:'8F*/:_M2"L=@"JV5"]SDJXJ
M%>9UIL/S@U/3P:&%*[/%5W"E9:DY(5W%)9VI5];D_N$K9N64PDI\5]DI)#TX
M="&V'?2\@YZ5='5I,Q0A_C]87V.LJ5D6\;..QF=93E3IC@T8&V\R/\3B4)F>
M8Q,I#V?I'AW8S[9S6[7N@(I=(Q:MT._P*X=4)=1G),O*V9M5#20%6)9KNRZ;
M%RM4-N-=03X4M)*3'*"*-=DJ>%$APW1@:^JP"$9.L!-'+M'%HP"F@1\:NG'1
MR"A.[OSIXQFG!*6%%6?+@/$-@BK[1)54/GY;]&5ER'INB:2K(&SBI".<FLPO
M$A9],?!KV84!!OW<AXV?+8T2`#!9U!%%/0!M-FW7+&D)Y;)(6U;1O82H1C)X
M;:.BQFM4L6>0:N\470Q5NEG#!W9#0\GS*U$(J.<AJ6^?N@-"CKTU50Q/)_W=
MLD5VWO(H4@6;)+;#%:BH21IG30^*'N;R@5C5[6%+-V62+,T=Z"P\,"EZ*WU,
MUY.G%3JB*T%;J?C^SFT7F)C#>SM83QD+76TU/W`J5Q]9O&`<0:Z3N)[`WN``
M;'IK'HS%P;P)K#19*=>);GT]>7C2D`AUOB"Y<;X),*=XZ_F3L/(H[6KDF/=R
M-[1"3`A42J7-MO:"S?OP)9HMSW3028UL<H%>)_3-9V>;ZUOW$]<*;;)C6N=?
MX38AB@;4$DQK1J91&@*OQ((>1-;#X7!Z-U^./L`;.G/$WE!@1N@*+4>CF\EH
M=*NAC<H*.0IES,7EW1FG6OR2X31"%S]>@&.7Z+Z7Q^0Z94>J8?KX=89T-B3L
MK/+RI)TD=E;E1-=+J@W\*F%\GK,:5QPCTBBS>!;BI]*-GA[%-!^0-ZI@MNSY
MLY+V9GJK]DEVXF9E?ZR/&3#%P@EBH&YL@A5D.3Q[@;W5<0/5#_`7,_E71CZB
MGS]_^4EYW/W_G-'HSCT<N8D!$>&#QD"A@H0@9+U$'Z97[%PKJWH?^RX5D4<P
M-XCC_(@L&M0_^#.5:?]55Z9*G+E@0/7CKEZ>+C9TBLU$'8.`^/%F_;22<1`T
M6B8I#N,]'L*EB&0BOJ.5"A;981UVC4Q,?#4+$^`;%I"F6`\NIP0/F9%*NA?`
M_*^FLTS"Z029%H!KI%4$N'T;>$UIU^)>KE*?I/1CGI*KYOYX/%;Q$,>.-"QJ
M#J'D!"07?0I0RE1D2L>B$'X*G[?%F:/.$.>C`#*L!5R?[R0'8=T8TK!3"]8;
M)ZD@84A+26E[Q715XKJ-I1"J`=ZKJ:2Y]9J8/&(^U-744'P5MAIMK"I?9)J2
MF!1UR9^NJP-,ZE!NH(:!@[PXP9&Y.RB84MS!5O$8NN3C63ISW7&\*]R6'Y.R
MFFTX(&G(RW`0&/I3B@]^Y!H`3H#M%*>IH0?2&=U`3=-8P\T4)!S0R`9,<`]]
M?LFB,OT*Y;RI(DBR[0[YJ2L[;?E:-[O%>TC]3!XZG2+Z>OYFJA`Z^1!ZCM0&
M#L/^9]-.>?`P,V>+/JY2.C-YBAUX'_JNX>2%7A'%ZKH1V]-ENY/M@%;US);]
M?$&H53VJ42F*,SDN658YS=4<CI/,3K=M/V$=-H!R'3:F<AW^K<J)L7Y<`$U$
MA&D5@5D_J=M=,RDP<J;5I,"U^JZ/S[U,)0M&'_3M`TZ@0]<19IC1^&+RONXO
M1D,L9D,36U\/=$P!VJOFK\:7TA1AV9N'PVY^XXS6YH=0W)^S;W";%#/@"9$P
MC+RG!$)H/2T.K4;&RA/N<_1C+JPY:LN[1`>P,K*6R--GURK3:0.JN)@TS3KU
MAJ+7J1TE2WB'/W0::MMU^EC4$>K*?-2!K(X2)?2TF4(U430#]BY)#.Q1?C9N
M&S!<BQY5'L,G5"]MXR?`:#_7)1@Z2"_?>E$_:-`\QLEL]N#A$BUZ_4XMU4V?
MX\Z+KVRCZ6#@!#8A:+O_'";!X&V0P`#A.Q_!R+V?9KD=\,3\EF>_V\$0<FAG
M]..='(_>CH/C2O)[<8S>D&"NL_X`5SD`HQ(<OOZR_RC`E/-:OB^L0'JM\NI_
M\8WW9W1Q+997B%M#1:.7U8!+ND+QYB_L9.A[]"TL#FBV0]N/AB.F@Q-O/@DU
;L_%D/KE_]%B)I#C+(4-W*PC9O]:P1"<9+P``
`
end
sulu v940: exit
sulu v940: 
script done on Thu Aug 21 07:23:14 2003
Comment 1 Dara Hazeghi 2004-01-17 23:48:27 UTC
This works for me with gcc 3.3.1 on x86-linux. Would it be possible for you to test with gcc 3.3.2 
or a recent snapshot, to see if this is still a problem? Dave have you seen anything like this? 
Thanks.
Comment 2 dave 2004-01-18 00:22:54 UTC
Subject: Re:  Multiple inheritance float pass by value fails

> This works for me with gcc 3.3.1 on x86-linux. Would it be possible for you
> to test with gcc 3.3.2 
> or a recent snapshot, to see if this is still a problem? Dave have you seen
> anything like this? 

I tried the putval test program.  It generates 0.000000 with 3.3.1
on hpux 10.20 and 11.11.  It generates 2.153332 with 3.3.2 under hpux 11.00.
With a 64-bit version of 3.5 experimental, it generates 3.141590.  So,
the problem might be fixed in 3.4.

I don't have a 32-bit build of 3.4 or 3.3.3 available to try at the
moment.

Dave
Comment 3 Dara Hazeghi 2004-01-18 01:34:23 UTC
Thanks. If/when you get a chance to try 3.4 on HP-UX 32bit, that'd be great. Otherwise, I suppose 
we should suspend this as fixed on 3.5?
Comment 4 dave 2004-01-19 16:42:11 UTC
Subject: Re:  Multiple inheritance float pass by value fails

> Thanks. If/when you get a chance to try 3.4 on HP-UX 32bit, that'd be great.
> Otherwise, I suppose 
> we should suspend this as fixed on 3.5?

The testcase fails on 3.4 hpux 10.20 and 3.5 hpux 11.11, 32-bit SOM
port.  On the hppa-linux port, it returns 3.141590 -O0 and -O1, but
0.000000 at -O2.

I would leave this PR open.

Dave
Comment 5 dave 2004-01-19 18:58:06 UTC
Subject: Re:  Multiple inheritance float pass by value fails

> On the hppa-linux port, it returns 3.141590 -O0 and -O1, but
> 0.000000 at -O2.

This appears to be a problem with the call usage information.  The
problem seems similar PR optimization/12372.

When an argument doesn't have a prototype, floats are supposed to
be passed in both general and floating point registers.  However,
the call usage information only contains a USE for the floating
point register (%fr7):

(call_insn/j 20 19 21 0 0x402495d0 (parallel [
            (set (reg:SI 28 %r28)
		(call (mem:SI (symbol_ref/v:SI ("@printf")) [0 S4 A32])
		    (const_int 16 [0x10])))
	    (clobber (reg:SI 1 %r1))
	    (use (reg:SI 2 %r2))
	    (use (const_int 0 [0x0]))
	]) -1 (nil)
    (expr_list:REG_EH_REGION (const_int 0 [0x0])
	(nil))
    (expr_list (use (reg:DF 38 %fr7))
	(expr_list (use (reg:SI 26 %r26))
	    (nil))))

There should be use a DFmode use for %r23 (or equivalent) to get the
argument loads to %r23 and %r24 from being deleted.

I believe that this optimization is only applied in sibling calls.
A work-around may be to use "-fno-optimize-sibling-calls".

Dave
Comment 6 dave 2004-01-19 20:36:03 UTC
Subject: Re:  Multiple inheritance float pass by value f

> The testcase fails on 3.4 hpux 10.20 and 3.5 hpux 11.11, 32-bit SOM
> port.

Ok, the problem is understood.  An indirect call is used to transfer
to the thunk.  Under the HP-UX 32-bit runtime, the first arguments
are passed in general registers.  However, myGv::PutVal(float)
expects its second argument in %fr5.  The linker is supposed to
provide a stub to copy the argument.  However, the .PARAM statement
for the thunk doesn't provide argument location information.  As
a result, the float argument doesn't get copied from %r25 to %fr5.
We also don't provide a .CALL for the transfer from the thunk to
the function.  This is also another potential place where argument
relocation might occur.  The linker doesn't relocate arguments
for this branch as it assumes the arguments are in their default
locations.

The .PARAM statement is generated by ASM_DECLARE_FUNCTION_NAME.
It would appear that the declaration for the thunk doesn't contain
any argument information.  The proper fix is to provide appropriate
argument for the thunk (DECL_ARGUMENTS) as the thunk has no way
of knowing whether it is being called directly or not.  This will
allow the linker to appropriately relocate arguments for both direct
and indirect calls to the thunk.

The hppa-linux ABI is slightly different.  The linker doesn't relocate
arguments.  To compensate, we put floating arguments in both general
and floating point registers for indirect calls.  This avoids the
above problem.  However, the sibcall issue needs fixing.

Dave
Comment 7 dave 2004-01-19 20:56:29 UTC
Subject: Re:  Multiple inheritance float pass by value f

> The .PARAM statement is generated by ASM_DECLARE_FUNCTION_NAME.
> It would appear that the declaration for the thunk doesn't contain
> any argument information.  The proper fix is to provide appropriate
> argument for the thunk (DECL_ARGUMENTS) as the thunk has no way
> of knowing whether it is being called directly or not.

The PR should be changed from "target" to "c++".  This stuff is
done in cp/method.c.

Dave
Comment 8 CVS Commits 2004-02-20 23:03:51 UTC
Subject: Bug 12007

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	danglin@gcc.gnu.org	2004-02-20 23:03:42

Modified files:
	gcc            : ChangeLog dbxout.c 
	gcc/cp         : ChangeLog method.c 

Log message:
	PR c++/12007
	* dbxout.c (dbxout_parms): Check that DECL_RTL and DECL_INCOMING_RTL
	are set for parameters before outputing debugging information.
	* cp/method.c (use_thunk): Always clone function argument tree.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.2874&r2=2.2875
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dbxout.c.diff?cvsroot=gcc&r1=1.177&r2=1.178
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.3964&r2=1.3965
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/method.c.diff?cvsroot=gcc&r1=1.277&r2=1.278

Comment 9 CVS Commits 2004-02-20 23:10:40 UTC
Subject: Bug 12007

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	danglin@gcc.gnu.org	2004-02-20 23:10:33

Modified files:
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/other: vthunk1.C 

Log message:
	PR c++/12007
	* g++.dg/other/vthunk1.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.3525&r2=1.3526
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/vthunk1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1

Comment 10 John David Anglin 2004-02-20 23:16:30 UTC
Fixed.