Re: [0/6] v10: stack branch merge to trunk

[Andreas Tobler <andreast-list at fgznet dot ch>]

Hi HJ,

H.J. Lu wrote:

> Here is the version 10 of patches to merge stack branch to trunk.
> The difference from the last version is the updated DWARF
> patch. Here are 7 patches:
>
> [1/7] v10: New fields in rtl_data.  Richard OKed the last one. Unchanged
> from the last one.
> [2/7] v10:: Handle frame pointer for stack alignment. New. Need middle-end
> review.
> [3/7] v10: Collect alignment info.  Need middle-end review.
> [4/7] v10: Update DWARF2.  Approved by Jason.
> [5/7] v10: Update x86 backend.  Need x86 backend reviewe.
> [6/7] v10: Update document.  Richard OKed the last one. Unchanged from
> the last one.
> [7/7] v10: New testscases. Janis has OKed the previous one.  Unchanged
> from the last one.

I'm a bit afraid about the merging politics here.

Concrete, you broke darwin i686 bootstrap at least with 3/7.

What I do not understand is the process. For example, the tuples branch, 
a bit more invasive than yours, called for testers for primary and 
secondary targets they were not able to test them self.
You did not, but this branch affects all x86 targets, maybe a bit more. 
There is not only linux, we have a few more OS's, and we try to keep the 
freedom of a working target.

So, I'd have expected a call from you for testing your branch on 
different OS's which have the base x86 cpu as default before merging to 
trunk. I'm willing, and I DO testing on all of my machine park cpu's if 
I'm asked.

The blame is not only against you, but also to the reviewers.

I'd like to propose a merging criteria, merging from a branch to trunk 
is only allowed if a set of primary and secondary targets passed 
bootstrap and testing. If not, the branch has to stay branch until this 
criteria is fulfilled.

I know I sound a bit harsh, but situations like this are causing me 
uneeded cycles.

Btw, the failing part is due to the fact that darwin x86 has a 
STACK_BOUNDARY of 128 per default.

Regards,
Andreas