On Wed, Oct 22, 2025 at 12:21 PM Paul Edwards <[email protected]> wrote:
> I am currently porting the x64 version of PDOS-generic,
> a mini Windows clone (available at pdos.org, start with
> makebios.leb in sourceforge), to EBCDIC.
This is going very well, but I had to drop from -O2 to -O1 in
one place for unknown reasons. I was trying to find out the
problem, but -O2 was rearranging my code too dramatically,
and I even have a demo available now - search for ucx64e
at pdos.org.
But an issue - perhaps the same issue - arose in a different
situation.
I am using gcc 15.2.0 (built myself) with the x64 mingw64 target,
and I have this innocuous 32-byte variable (in mcc.c in the PDOS
project - but I have added printfs):
typedef unsigned long long int u64;
struct $B17 {u64 a[4];};
static struct $B17 cc_decls_nextlx;
When compiling with -O2 (and I believe -O1 does the same thing),
I get this in one place where it is used:
movdqa cc_decls_nextlx(%rip), %xmm0
# movaps %xmm0, 32(%rsp)
# movdqa 16+cc_decls_nextlx(%rip), %xmm1
# movaps %xmm1, 48(%rsp)
(without the comments).
I'm not an assembler expert, but I believe that first line
requires the variable to be 16-byte aligned (it crashes
on that line anyway - I confirmed that by commenting
out the other lines - and also I confirmed the address
ended with an "8" instead of a "0" by printing it out).
The gcc-generated assembler code has this:
.lcomm cc_decls_nextlx,32
with no alignment statement - but an alignment statement
doesn't help anyway.
What does make it work is this:
.lcomm cc_decls_nextlx,32,16
ie that last parameter specifies 16-byte alignment, and that
actually works and resolves the issue.
I find it hard to believe that a major target like this could
have an issue, so perhaps I am doing something wrong.
Any guidance?
I'm going to freeze my environment for a while in case
it really is a bug and more information is required from me.
After that I'll put in some workaround and move on with
my "life". :-)
Thanks. Paul.
