Re: Converting to LRA (calling all maintainers)
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 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). It was actually one of the next targets on the list after SH. What's with all that hurry to kill the old reload? Unless LRA can be brought "up to speed" for all other targets and vice versa, ripping out old reload and all the dependent targets would be a set back for GCC, IMHO. It would lose a bunch of targets. Cheers, Oleg
Re: Converting to LRA (calling all maintainers)
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). It was actually one of the next targets on the list after SH. > > What's with all that hurry to kill the old reload? Unless LRA can be > brought "up to speed" for all other targets and vice versa, ripping out > old reload and all the dependent targets would be a set back for GCC, > IMHO. It would lose a bunch of targets. 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. There are enough half conversions in GCC already, and the maintenance cost is non-zero. Segher
Re: Converting to LRA (calling all maintainers)
> 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 time for a given port. Do we have a Wiki page for the cc0 conversion? If no, I can start one based on my fresh experience with the Visium port. -- Eric Botcazou
sprintf warning on overlapping output
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)
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 priority is IMO the cc0 thing and you cannot > really do both at the same time for a given port. You can delete one port for two reasons at the same time though ;-) > Do we have a Wiki page for > the cc0 conversion? If no, I can start one based on my fresh experience with > the Visium port. There is none so far as far as I know. Thanks for volunteering, Segher
Successful bootstrap and install of gcc (GCC) 6.2.0 on powerpc64-unknown-linux-gnu
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-wrapper Target: powerpc-unknown-linux-gnu Configured with: ../gcc-6.2.0/configure --with-cpu-32=G4 --with-cpu-64=G5 --enable-targets=powerpc64-unknown-linux-gnu --disable-nls --prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++ --host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu --target=powerpc-unknown-linux-gnu --with-system-zlib --with-sysroot=/ Thread model: posix gcc version 6.2.0 (GCC) -- Build environment -- host: g5-xserve-m distro: los.git rootfs=f700f9 native=f700f9 kernel: Linux 4.8.0-rc6-g5-los_f989d71 binutils: GNU binutils 2.27 make: GNU Make 4.1 libc: GNU C Library (GNU libc) stable release version 2.24 zlib: 1.2.8 mpfr: 3.1.3 gmp: 6 -- Time consumed -- configure: real0m 8.84s user0m 6.72s sys 0m 4.10s bootstrap: real5h 9m 10s user9h 18m 44s sys 25m 4.96s install:real0m 36.88s user0m 28.17s sys 0m 29.76s -- Hardware details --- MemTotal: 8070684 kB processor : 0 cpu : PPC970FX, altivec supported clock : 2300.00MHz revision: 3.0 (pvr 003c 0300) processor : 1 cpu : PPC970FX, altivec supported clock : 2300.00MHz revision: 3.0 (pvr 003c 0300) timebase: platform: PowerMac model : RackMac3,1 machine : RackMac3,1 motherboard : RackMac3,1 MacRISC4 Power Macintosh detected as : 339 (XServe G5) pmac flags : L2 cache: 512K unified pmac-generation : NewWorld A.
Re: sprintf warning on overlapping output
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 overlaps an input buffer? > > > > Thanks > Bernd. > I was testing Prathamesh's -Wrestrict patch, and it caught a few cases like that: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00027.html Eric
Re: Converting to LRA (calling all maintainers)
> 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 IMO the cc0 thing and you cannot > really do both at the same time for a given port. Do we have a Wiki page for > the cc0 conversion? If no, I can start one based on my fresh experience with > the Visium port. That would be great. I've been trying to understand the process, and while I have a few notes from assorted emails over the years, it certainly isn't clear in my mind. paul
gcc-7-20160925 is now available
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 240479 You'll find: gcc-7-20160925.tar.bz2 Complete GCC MD5=b7ac3a7a6bd7e91b3ecebf58c9511e7f SHA1=8db364b3bc60d2ac1b8d40a664c296c690fd9f29 Diffs from 7-20160918 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
