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
