On 04/24/2013 09:14 PM, DJ Delorie wrote:
>> 24 bits stored as three bytes, or four? How does this affect vtable
>> layout? I would have expected the C++ frontend and libsupc++ to
>> currently be inconsistent with each other given such a setup.
> 
> In memory, four, I think.  The address registers really are three
> bytes though.  They're PSImode and gcc doesn't really have a good way
> of using any specified PSImode precision.

I took a look myself to find out the answer to the second part of my
question (I'll post a few patches to get m32c working on trunk later).
It turns out that as I expected, C++ support is somewhat broken on this
target. My vtables patch series fixes the following execution tests:

+PASS: g++.dg/abi/local1.C -std=c++98 execution test
+PASS: g++.dg/abi/local1.C -std=c++11 execution test
+PASS: g++.dg/ext/attr-alias-2.C -std=c++98 execution test
+PASS: g++.dg/ext/attr-alias-2.C -std=c++11 execution test
+PASS: g++.dg/lto/pr42987 cp_lto_pr42987_0.o-cp_lto_pr42987_1.o execute
 -flto -g
+PASS: g++.dg/lto/pr42987 cp_lto_pr42987_0.o-cp_lto_pr42987_1.o execute
 -flto -flto-partition=none -g
+PASS: g++.old-deja/g++.mike/thunk2.C -std=c++98 execution test
+PASS: g++.old-deja/g++.mike/thunk2.C -std=c++11 execution test
+PASS: g++.old-deja/g++.other/rtti3.C -std=gnu++98 execution test
+PASS: g++.old-deja/g++.other/rtti3.C -std=gnu++11 execution test
+PASS: g++.old-deja/g++.other/rtti4.C -std=gnu++98 execution test
+PASS: g++.old-deja/g++.other/rtti4.C -std=gnu++11 execution test

The downside is that it would be an ABI change for -mcpu=m32cm in terms
of generated code (to make it match what libsupc++ expects). Would you
consider that acceptable for this target, considering it is a bug fix
and the new layout is more space efficient?


Bernd

Reply via email to