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
> 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
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
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
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
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.
> 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
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
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
