Re: Converting to LRA (calling all maintainers)

2016-09-25 Thread Oleg Endo
On Fri, 2016-09-16 at 16:25 -0500, Segher Boessenkool wrote: > On Fri, Sep 16, 2016 at 02:53:16PM -0600, Jeff Law wrote: > > > > Under traps for the unwary -- LRA requires the target to not use > > the old  > > cc0 condition code handling... > I added this now, thanks Jeff. > > > > > ANd yes, I

Re: Converting to LRA (calling all maintainers)

2016-09-25 Thread Segher Boessenkool
On Sun, Sep 25, 2016 at 04:28:04PM +0900, Oleg Endo wrote: > > > ANd yes, I see this as a way to deprecating those cc0 targets like > > > the  > > > m68k :-) > > Would be a shame to see m68k go.  There still is time... > > Indeed.  68K is a perfect candidate for addressing mode optimization > (AMS

Re: Converting to LRA (calling all maintainers)

2016-09-25 Thread Eric Botcazou
> There is no hurry to kill old reload. As you say, many targets will > not be converted soon. But one day it will be removed. Not in GCC 7, > not in GCC 8 almost certainly. But one day. Certainly not in GCC 8, the top priority is IMO the cc0 thing and you cannot really do both at the same ti

sprintf warning on overlapping output

2016-09-25 Thread Bernd Edlinger
Hi Martin, in the past I have seen (and fixed) code like sprintf(buf, "%s %d", buf, x); that may possibly work by chance, but usually produces undefined results. Do you see a way to enhance the warning for cases where the output buffer overlaps an input buffer? Thanks Bernd.

Re: Converting to LRA (calling all maintainers)

2016-09-25 Thread Segher Boessenkool
On Sun, Sep 25, 2016 at 10:46:55AM +0200, Eric Botcazou wrote: > > There is no hurry to kill old reload. As you say, many targets will > > not be converted soon. But one day it will be removed. Not in GCC 7, > > not in GCC 8 almost certainly. But one day. > > Certainly not in GCC 8, the top pr

Successful bootstrap and install of gcc (GCC) 6.2.0 on powerpc64-unknown-linux-gnu

2016-09-25 Thread Aaro Koskinen
Hi, Here's a report of a successful build and install of GCC: $ gcc-6.2.0/config.guess powerpc64-unknown-linux-gnu $ newcompiler/bin/gcc -v Using built-in specs. COLLECT_GCC=newcompiler/bin/gcc COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/powerpc-unknown-linux-gnu/6.2.0/lto-wra

Re: sprintf warning on overlapping output

2016-09-25 Thread Eric Gallager
On 9/25/16, Bernd Edlinger wrote: > Hi Martin, > > in the past I have seen (and fixed) code like > > sprintf(buf, "%s %d", buf, x); > > that may possibly work by chance, but usually > produces undefined results. > > Do you see a way to enhance the warning for cases > where the output buffer overla

Re: Converting to LRA (calling all maintainers)

2016-09-25 Thread Paul.Koning
> On Sep 25, 2016, at 4:46 AM, Eric Botcazou wrote: > >> There is no hurry to kill old reload. As you say, many targets will >> not be converted soon. But one day it will be removed. Not in GCC 7, >> not in GCC 8 almost certainly. But one day. > > Certainly not in GCC 8, the top priority is

gcc-7-20160925 is now available

2016-09-25 Thread gccadmin
Snapshot gcc-7-20160925 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20160925/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision