I thought I was pretty clear about a gcc.godbolt.org link so I can verify it. I guess the style of "programming" you do fits perfectly: Googling for others' work. I don't even know the GCC version used -- or the settings used -- how can it be verified? It could be a hand-written asm file for all you know.

Also, you forgot 3)

3) [esp+0] aligned to 32 bytes

Deal with it.

Why should I bother about producing code for you.

My code or not, it's a legit ASSEMBLY LISTING emitted by C.

system error wrote:

Why should I bother about producing code for you.

You made the claim, burden of proof is on you. So prove it. If you don't want to bother, don't make claims, and shut up? Easy enough. In fact, you typed way more and "bothered" way more with nonsensical bullshit than it would take you to write a simple C code to prove your point. But you can't. All you can type is 1) bullshit 2) pseudo code 3) google searches.

system error wrote:

My code or not, it's a legit ASSEMBLY LISTING emitted by C.

^ see above. Prove it. I see a copy-paste from a *book* (your link).

I will say it one last time: prove it, or shut it. If you won't, then we have nothing further to discuss.

And no, unless it's exactly the requirements I put up for a proof (verified on gcc.godbolt.org, and you can try with GCC 6.3.0 because that's what I used, but you must say which version if you do otherwise and exact command line options -- but use a recent GCC version, not an ancient one I don't have available -- either way, if it is proper in older versions of GCC that's a good thing, it means it was a "regression" so it has more potential to be accepted when I submit the patch), I will not bother to look at it unless you qualify ALL those criteria.

I've spent enough time on your tirade, so I'm done here. (I love how ignorant you are about others, when 2 other people already told you to get lost)

gcc.godbolt.org

How do you fit a 32-byte vector plus a 4-byte int into 32 bytes again? What I literally said it won't fit in 32 bytes. Since it's 32+4 = 36 bytes minimum.

And no, unless it's exactly the requirements I put up for a proof (verified on gcc.godbolt.org, and you can try with GCC 6.3.0 because that's what I used, but you must say which version if you do otherwise and exact command line options -- but use a recent GCC version, not an ancient one I don't have available -- either way, if it is proper in older versions of GCC that's a good thing, it means it was a "regression" so it has more potential to be accepted when I submit the patch), I will not bother to look at it unless you qualify ALL those criteria.

Furs wrote:

And no, unless it's exactly the requirements I put up for a proof (verified on gcc.godbolt.org, and you can try with GCC 6.3.0 because that's what I used, but you must say which version if you do otherwise and exact command line options -- but use a recent GCC version, not an ancient one I don't have available -- either way, if it is proper in older versions of GCC that's a good thing, it means it was a "regression" so it has more potential to be accepted when I submit the patch), I will not bother to look at it unless you qualify ALL those criteria.

Your tester1 fails the requirements, since it's not a C++ code that GCC can compile on godbolt. Suck it up.

So, where's the patch? Sent it yet? xD

First I need to make a patch to justify it by reducing the frame size, obviously, (i.e. from 64 to 36 in this example), otherwise it won't get accepted since it's useless. Though it does work currently in my plugin which I verify first with.

system error wrote:

So, where's the patch? Sent it yet? xD

I believe I've answered this already:

Furs wrote:

First I need to make a patch to justify it by reducing the frame size, obviously, (i.e. from 64 to 36 in this example), otherwise it won't get accepted since it's useless. Though it does work currently in my plugin which I verify first with.

You deserve no proper answer since you can't seem to read properly.

It looks kind of complicated to fix the sub esp, 64 unfortunately. It's deeply rooted into LRA/reload. The swap is easy to fix, but without that fix, the swap is useless (makes no difference). Problem is that even if I don't round up the stack, GCC will use [esp+32] for vector (which is invalid if I only have 36 bytes of space), because it rounds it up on every elimination iteration in reload.

So my problem right now is how to fix it from "sub esp, 64" and make it "sub esp, 36" before I fix the swap. (and before you ask, no, this is pure C code for RTL generation, there's zero assembly involved please spare me your asm "examples"). The entire prolog/epilog in GCC is in RTL not assembly. (LISP-like structures/language)

@system error: Alright, since you're so "competent" (you love the other word), then please go send a patch to make GCC use sub esp, 36 (i.e. not round it up).

What burden of proof?

It's simple: Don't call others incompetent when you can't do what they can do, because that makes you even more incompetent. And I'll work on the patch but it seems pretty troublesome (the LRA/reload alignment part), sigh.