BUG: djgpp should allow 16-byte alignment

[jwjag...@gmail.com]

Currently it seems that djgpp does not support 16-byte alignment. Since djgpp-compiled programs can potentially use SSE instructions (either explicitly or implicitly, when compiled with -march=pentium3), I do think this should be supported.

previous discussion:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79935

[Louis Santillan (lpsantil@gmail.com) [via djgpp@delorie.com]]

Are you unable to use `--mstackrealign`, `-mpreferred-stack-boundary=num`, `-mincoming-stack-boundary=num` [0]?  Looks like you'll also need to force those options if you compile with `-Os` as well.

[0] https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options  

[jwjag...@gmail.com]

I was already using -mpreferred-stack-boundary=4 (which implies -mincoming-stack-boundary=4) but that didn't seem to have the intended effect. Most notably in static constructors, the stack alignment is always 8 bytes off. From the disassembly I can tell gcc does its best to keep the stack aligned, so that part works correctly, at least.

Now yesterday I had a problem in a non-static function, where gcc inserted an SSE instruction with a memory operand [ebp-0x58], with (ebp % 0x10 == 0x0c). That doesn't make any sense at all! It's guaranteed to cause a GP fault and gcc should know this.

[Louis Santillan (lpsantil@gmail.com) [via djgpp@delorie.com]]

Have you tried using `-mstackrealign`?  That might correct the errors you are seeing.  Without seeing any code, it's hard to say what's going on.  Looking at BZ, I see the code there but no compiler flags.

[J.W. Jagersma (jwjagersma@gmail.com) [via djgpp@delorie.com]]

Okay thanks, I tried -mstackrealign and it seems to help in the last
case I mentioned. I don't really see how, though. It shouldn't be
necessary in the first place, since once the stack is aligned
correctly, it should stay aligned in every subsequent function call.

The GP fault I mentioned earlier occurs in the following instruction:
60987: 0f 29 45 a8 movaps XMMWORD PTR [ebp-0x58],xmm0

Here is the entry to this function, when compiled with -mstackrealign:
00060a74 <jw::thread::detail::scheduler::check_exception()>:
60a74: 8d 4c 24 04 lea ecx,[esp+0x4]
60a78: 83 e4 f0 and esp,0xfffffff0
60a7b: ff 71 fc push DWORD PTR [ecx-0x4]
60a7e: 55 push ebp
60a7f: 89 e5 mov ebp,esp

And here is the same function, without it:
00060918 <jw::thread::detail::scheduler::check_exception()>:
60918: 55 push ebp
60919: 89 e5 mov ebp,esp

In the first case, ebp ends up being 0x...8, while in the second, ebp
is 0x...c. In both cases however, esp at the point of the call is
correctly aligned to 0x10 bytes.

Either with or without -mstackrealign, the stack is always aligned to
16 bytes in main():
0005ee6c <main>:
5ee6c: 55 push ebp
5ee6d: 89 e5 mov ebp,esp
5ee6f: 57 push edi
5ee70: 56 push esi
5ee71: 53 push ebx
5ee72: 83 e4 f0 and esp,0xfffffff0
5ee75: 83 c4 80 add esp,0xffffff80

Here's the code I'm working with, if you want to try for yourself:
https://github.com/jwt27/jwdpmi_test

On 12 March 2017 at 06:15, Louis Santillan (lpsa...@gmail.com) [via

[RayeR]

DJGPP constant __BIGGEST_ALIGNMENT__ reports to be 16 but I don't know if it works and if it is related to this issue.

[jwjag...@gmail.com]

On Monday, 13 March 2017 03:55:49 UTC+1, RayeR wrote:
> DJGPP constant __BIGGEST_ALIGNMENT__ reports to be 16 but I don't know if it works and if it is related to this issue.

That's interesting since C++'s alignof(std::max_align_t) equals 8, even when compiling with -march-pentium3.