gcc-9-20201211 is now available

2020-12-11 Thread GCC Administrator via Gcc
Snapshot gcc-9-20201211 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20201211/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

Re: gcc/DATESTAMP not updated any longer

2020-12-11 Thread Jakub Jelinek via Gcc
On Fri, Dec 11, 2020 at 07:04:28PM +0100, Martin Liška wrote: > On 12/11/20 2:17 PM, Rainer Orth wrote: > > Rainer Orth writes: > > > > > I noticed that gcc/DATESTAMP isn't updated any longer after this > > > Friday. I doubt this is intentional... > > > > This has happened again tonight... > >

RFC v4: Re: cacheflush.2

2020-12-11 Thread Alejandro Colomar (man-pages) via Gcc
I forgot to add a junk to the text. v4: NOTES Unless you need the finer grained control that this system call provides, you probably want to use the GCC built-in function __builtin___clear_cache(), which provides a portable interface across platforms supported

RFC v3: Re: cacheflush.2

2020-12-11 Thread Alejandro Colomar (man-pages) via Gcc
Hi all, Please review this text: [ NOTES Unless you need the finer grained control that this system call provides, you probably want to use the GCC built-in function __builtin___clear_cache(), which provides a more portable interface: void __bui

Re: cacheflush.2

2020-12-11 Thread Alejandro Colomar (man-pages) via Gcc
It looks like GCC recently moved from 'char *' to 'void *'. This SO question[1] (4 years ago) quotes the GCC docs and they had 'char *'. Maybe Clang hasn't noticed the change. I'll report a bug. [1]: https://stackoverflow.com/q/35741814/6872717 On 12/9/20 8:15 PM, Alejandro Colomar (man-pages) wr

Re: gcc/DATESTAMP not updated any longer

2020-12-11 Thread Martin Liška
On 12/11/20 2:17 PM, Rainer Orth wrote: Rainer Orth writes: I noticed that gcc/DATESTAMP isn't updated any longer after this Friday. I doubt this is intentional... This has happened again tonight... Rainer Thanks for heads up. I'm aware of it and I don't see reason why (running

Re: RFC v2: Re: cacheflush.2

2020-12-11 Thread Alejandro Colomar (man-pages) via Gcc
Hi Michael, On 12/11/20 9:15 AM, Michael Kerrisk (man-pages) wrote: > i Alex, > > On 12/10/20 9:56 PM, Alejandro Colomar (man-pages) wrote: >> Hi all, >> >> v2: >> >> [ >> NOTES >>Unless you need the finer grained control that this system >>call provides, you probably want to

Re: The conditions when convert from double to float is permitted?

2020-12-11 Thread Segher Boessenkool
On Fri, Dec 11, 2020 at 05:38:30PM +0800, Xionghu Luo wrote: > On 2020/12/11 15:47, Richard Biener wrote: > >> Note that the add/sub sequence is different for (3) and (4) since > >> -funsafe-math-optimizations is implicitly true. "fp-contract=fast" in > >> (1) and (2) could avoid Inf as fmads coul

Re: The conditions when convert from double to float is permitted?

2020-12-11 Thread Segher Boessenkool
On Fri, Dec 11, 2020 at 03:54:44PM +0800, Xionghu Luo wrote: > +cc. > > > On 2020/12/11 14:25, Xionghu Luo via Gcc wrote: > >Thanks, > > > >On 2020/12/10 17:12, Richard Biener wrote: > >>>2) From PR90070: > >>> > >>>double temp1 = (double)r->red; > >>>double temp2 = (double)aggregate.red;

Re: gcc/DATESTAMP not updated any longer

2020-12-11 Thread Rainer Orth
Rainer Orth writes: > I noticed that gcc/DATESTAMP isn't updated any longer after this > Friday. I doubt this is intentional... This has happened again tonight... Rainer -- - Rainer Orth, Center for Biotechno

Re: Integer division on x86 -m32

2020-12-11 Thread Alexander Monakov via Gcc
On Fri, 11 Dec 2020, Andrew Haley via Gcc wrote: > On 11/12/2020 07:12, Marc Glisse wrote: > > On Thu, 10 Dec 2020, Lucas de Almeida via Gcc wrote: > > > >> when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to > >> __divdi3 is always output, even though it seems the use of

Re: The conditions when convert from double to float is permitted?

2020-12-11 Thread Richard Biener via Gcc
On Fri, Dec 11, 2020 at 10:44 AM Xionghu Luo wrote: > > > On 2020/12/11 15:47, Richard Biener wrote: > >> Note that the add/sub sequence is different for (3) and (4) since > >> -funsafe-math-optimizations is implicitly true. "fp-contract=fast" in > >> (1) and (2) could avoid Inf as fmads could ha

Re: The conditions when convert from double to float is permitted?

2020-12-11 Thread Xionghu Luo via Gcc
On 2020/12/11 15:47, Richard Biener wrote: >> Note that the add/sub sequence is different for (3) and (4) since >> -funsafe-math-optimizations is implicitly true. "fp-contract=fast" in >> (1) and (2) could avoid Inf as fmads could handle float overflow (verified >> it on Power, not sure other t

Re: The conditions when convert from double to float is permitted?

2020-12-11 Thread Xionghu Luo via Gcc
On 2020/12/11 15:47, Richard Biener wrote: >> Note that the add/sub sequence is different for (3) and (4) since >> -funsafe-math-optimizations is implicitly true. "fp-contract=fast" in >> (1) and (2) could avoid Inf as fmads could handle float overflow (verified >> it on Power, not sure other ta

Re: Integer division on x86 -m32

2020-12-11 Thread Andrew Haley via Gcc
On 11/12/2020 07:12, Marc Glisse wrote: > On Thu, 10 Dec 2020, Lucas de Almeida via Gcc wrote: > >> when performing (int64_t) foo / (int32_t) bar in gcc under x86, a call to >> __divdi3 is always output, even though it seems the use of the idiv >> instruction could be faster. > > IIRC, idiv requi

Re: RFC v2: Re: cacheflush.2

2020-12-11 Thread Michael Kerrisk (man-pages) via Gcc
i Alex, On 12/10/20 9:56 PM, Alejandro Colomar (man-pages) wrote: > Hi all, > > v2: > > [ > NOTES >Unless you need the finer grained control that this system >call provides, you probably want to use the GCC built-in >function __builtin___clear_cache(), which pr