Closed michalsc closed 3 months ago
it seems that the register information for variables gets lost in c++.
Workaround: use extern "C" wrappers:
extern "C" {
inline void _Printf(char const * f, ...) {
VPrintf(f, 1 + &f);
}
}
Yes, that would be one option, another is to use clib and linked libraries with stubs. The question remains if it is somehow fixable for gcc-6.5 or if we are stuck with what we have now. Please note on gcc-13.1 from your amiga13 branch everything seems to work as expected.
Yes, that would be one option, another is to use clib and linked libraries with stubs. The question remains if it is somehow fixable for gcc-6.5 or if we are stuck with what we have now. Please note on gcc-13.1 from your amiga13 branch everything seems to work as expected.
I noted that. Just buy me time...
Seems to happen only in templates. Minimal: http://franke.ms/cex/z/77Wsah
please test
Sorry for late reply - I've just tested it with doubly nested case - template based allocator used within template class - everything is working as expected.
As always many thanks for great work!
When compiling c++ code, the marcos/inlines from proto/ SDK directory are wrongly resolved causing catastrophic results, where library base is not loaded to
A6
register or putting function arguments to wrong registers.I have uploaded example code to your compiler explorer: http://franke.ms/cex/z/d1xP8G
Noticable snippets from the code above:
Call to VPrintf (this is how the Printf is resolved) shall put string pointer to D1, pointer to ARG list into D2 and DOSBase into A6, but instead it loads ARG list into A0 and DOSBase into D0, then references never touched A6:
Call to AllocMem shall put byte size to D0, requirements into D1 and SysBase into A6, instead byte size is loaded into D1, SysBase into D0 and requirements into A1:
Subsequent calls from deallocate() method lead to different but still wrong results.
Please note that using clib headers which do a standard C calls to external library result in corrent function invocations but add an additional overhead.
Affected is gcc from 6.5 series. I made additional test with gcc-13.1 from your amiga13 branch and it generates correct assembly for the calls (see attached file) stl.s-13.zip