On Thu, 2022-06-09 at 17:23 +0200, Corinna Vinschen wrote: > On May 29 17:26, Ken Brown wrote: > > On 5/29/2022 9:39 AM, Jon Turney wrote: > > > On 26/05/2022 20:17, Ken Brown wrote: > > > > winsup/cygwin/autoload.cc | 136 --------------------- > > > > -- > > > > > > Looks good. > > > > > > I think that perhaps the stdcall decoration number n is unused on > > > x86_64, so can be removed also in a followup? > > > > Thanks, I missed that. > > > > Also, I guess most or all of the uses of __stdcall and __cdecl can be > > removed from the code. > > Yes, that's right, given there's only one calling convention on 64 bit. > > I have a minor objection in terms of this patch. > > When implementing support for AMD64, there were basically 2 problems to > solve. One of them was to support 64 bit systems, the other one was to > support AMD64. At that time, only IA-64 and AMD64 64 bit systems > existed, and since we never considered IA-64 to run Cygwin on, we > subsumed all 64 bit code paths under the __x86_64__ macro. > > But should we *ever* support ARM64, as unlikely as it is, we have to > make sure to find all the places where the code is specificially AMD64. > That goes, for instance, for all places calling assembler code, or > for exception handling accessing CPU registers, etc. > > I'm open to discussion, but I think the code being CPU-specific > should still be enclosed into #ifdef __x86_64__ brackets, with an > #else #error alternative. > > Right? Wrong? Useless complication?
Highly recommended. -- Yaakov
