ZDoom

Ah just seen, good fix :thumb:

I rewrote that part to use safe language constructs instead. If this broke once it may do so again in the future on a different system so better let's steer clear of such unsafe type punning exploits.

It's an alignment issue. Some recent change added an internal virtual method table pointer to this struct and with 32 bit alignment rules causes the part that mimics line_t to not align to 8 bytes anymore - but then fails with aligning the DVector2, creating an alignment gap, which is critical.

Lol oh yeah sorry, it was something I found ages ago, didn't realise it was in upstream. Maybe it needs to be removed?! On ARM it seems to cause exactly the same error as shown in the picture and only affects 32bit code. But maybe not related, sorry for the false alarm!

Edit: yeah seems to I have snuck in with the gles2 updates last year

If that's the case it could be a compiler error. If one simple line is enough to fix this, I will add it, but with the caveat that this does not change GZDoom's official status for supporting 32-bit. If anyone wants to do a 32-bit fork and this helps them, though - I have no issue with that. :)

EDIT: This already seems to be in GZDoom's master branch?

I know this is closed but for interest this is cause by some alignment issue between [b]HWLinePortal[/b] and [b]line_t[/b]

This is the fix for 32bit machines for me:
https://github.com/emileb/gzdoom/blob/1689ee600bb85cd55610af1b8324b507a6edecdd/src/rendering/hwrenderer/scene/hw_portal.h#L161

I can't see what exactly is causing it as the code looks like it should work fine. Thought I would mention it in case there is something fragile in the code and this appears later even on 64bit machines.

Most likely it's an old VS 2019 bug (or something changed in the compiler), same thing happened with mirrors and they worked when compiled with VS 2017. No longer relevant of course.

GZDoom 4.8.1 -  - SDL version
...
CPU Vendor ID: GenuineIntel
  Name: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
  Family 6, Model 140, Stepping 1
  Features: SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 AVX AVX2 AVX512 F16C FMA3 BMI1 BMI2 HyperThreading
Using video driver x11
GL_VENDOR: Intel
GL_RENDERER: Mesa Intel(R) Xe Graphics (TGL GT2)
GL_VERSION: 4.6 (Core Profile) Mesa 22.1.2 (Core profile)
GL_SHADING_LANGUAGE_VERSION: 4.60

Data point: Using an -m32 build on a x64 CPU,
[code]
GZDoom 4.8.1 - - SDL version
...
CPU Vendor ID: GenuineIntel
Name: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
Family 6, Model 140, Stepping 1
Features: SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 AVX AVX2 AVX512 F16C FMA3 BMI1 BMI2 HyperThreading
Using video driver x11
GL_VENDOR: Intel
GL_RENDERER: Mesa Intel(R) Xe Graphics (TGL GT2)
GL_VERSION: 4.6 (Core Profile) Mesa 22.1.2 (Core profile)
GL_SHADING_LANGUAGE_VERSION: 4.60
[/code]
The demo portal map shows no issue for me.

As a reminder if you guys want a change in the build process all you need to do is drop a message my way (or a pull request). I don't read every thread on this forum, but happened to browse this one today.

Yes, they should be stopped.

I think I just add a static_assert to make them fail for now.

[quote="Blue Shadow"]People are getting them from [url=https://devbuilds.drdteam.org/gzdoom/]here[/url] :p[/quote]

Hmm, I wonder if it's better to stop building them. I don't see the point, if the official stance on 32 bit is that it's no longer supported.

People are getting them from [url=https://devbuilds.drdteam.org/gzdoom/]here[/url] :p

Self-compiled, presumably..

But let's make this clear: 32 bit isn't being tested anymore and no guarantees are given, and any 32 bit specific bug report will be closed on sight.

Where are these 32 bit executables even being downloaded/distributed? The main site clearly only offers a 64 bit download...

In that case, case closed.
32 Bit is not supported anymore.