Re: [Mingw-w64-public] Frame pointer and Win32 API functions

2014-07-27 Thread John E. / TDM
On 7/27/2014 9:44 AM, Ruben Van Boxem wrote: > Hi guys, > > I stumbled upon a strange question on Stackoverflow.com: > http://stackoverflow.com/q/24962205/256138 > > Is he right to think the generated code is suboptimal? Or is this an > ABI requirement? Can GCC be improved in this regard? Unless

Re: [Mingw-w64-public] Frame pointer and Win32 API functions

2014-07-27 Thread JonY
On 7/27/2014 23:44, Ruben Van Boxem wrote: > Hi guys, > > I stumbled upon a strange question on Stackoverflow.com: > http://stackoverflow.com/q/24962205/256138 > > Is he right to think the generated code is suboptimal? Or is this an ABI > requirement? Can GCC be improved in this regard? > > I ca

Re: [Mingw-w64-public] [PATCH] softmath: Add more double functions

2014-07-27 Thread JonY
On 7/27/2014 23:50, André Hentschel wrote: > Am 26.07.2014 um 01:54 schrieb JonY: >> On 7/26/2014 06:20, André Hentschel wrote: >>> +double log2(double x) +{ +return softmath_log(x) / softmath_log(2); +} > >> Any reason not to expand softmath_log(2) into a constant? Otherwise, it >> looks OK.

Re: [Mingw-w64-public] [PATCH] softmath: Add more double functions

2014-07-27 Thread André Hentschel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 26.07.2014 um 01:54 schrieb JonY: > On 7/26/2014 06:20, André Hentschel wrote: >> +double log2(double x) +{ +return softmath_log(x) / softmath_log(2); +} > > Any reason not to expand softmath_log(2) into a constant? Otherwise, it looks > OK. >

[Mingw-w64-public] Frame pointer and Win32 API functions

2014-07-27 Thread Ruben Van Boxem
Hi guys, I stumbled upon a strange question on Stackoverflow.com: http://stackoverflow.com/q/24962205/256138 Is he right to think the generated code is suboptimal? Or is this an ABI requirement? Can GCC be improved in this regard? I can point him to this mailing list and ask him to supply reprod

Re: [Mingw-w64-public] _lrotl and _lrotr

2014-07-27 Thread dw
And while I think it would be a good idea to add this function to intrin-impl.h so that this "intrinsic" function would be, well, intrinsic (instead of imported), that seems like a discussion for another day. Hey, it's another day... I originally thought it would make sense to do this incre