gcc-9-20181125 is now available
Snapshot gcc-9-20181125 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/9-20181125/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 266441 You'll find: gcc-9-20181125.tar.xzComplete GCC SHA256=87afbab2198c846d553e58aeab4f4813791e67c2f1e39723cd000b7c8a102f0e SHA1=211733607bc97d9646886edb0ac6368303935184 Diffs from 9-20181118 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 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.
Re: ICEs in print_operand() of the rs6000 backend with invalid input assembly
> Hi Arseny, > > On Fri, Nov 23, 2018 at 06:15:47PM +0700, Arseny Solokha wrote: >> I've found recently that rs6000 and powerpcspe backends can easily trip over >> various gcc_unreachable()'s and gcc_assert()'s in their respective copies of >> print_operand() when provided with some invalid assembly (i.e. assembly >> written >> for other architectures). > > Yup. They should use output_operand_lossage instead. Isn't it something that should be mentioned in the Internals manual? >> I have a hunch that this kind of invalid input should have been rejected way >> earlier, before getting to the printing out the resulting assembly, and that >> i386 backend actually does exactly that. Still, I'm not convinced that the >> current behavior is really unintended. Is it worthwhile at all to report >> ICEs of >> this kind? > > Please report them, yes! So I've filed PR88188 with three issues I've found so far. Though they might be of different nature. > Bonus points if you can find some way to test > this in the testsuite (preferably for all targets), testing many kinds > of input args (reg, imm, memory) and all output modifiers. For now I use a trivial script that simply tries to compile everything it finds, each file with a new set of -mcpu value, optimization options and --param options. Maybe enhancing the testsuite to facilitate some kind of fuzzing out of the box could be a proper task for the GSoC?
Re: Bug 84762 - GCC for PowerPC32 violates the SysV ABI spec for small struct returns
Hi Sirl, As you mentioned in Bugzilla (comment 13), aix_return ( return in memory) svr4_return (return in register) what is the semantics of svr4gnu w.r.t. return. Thanks Lokesh
Re: Bug 84762 - GCC for PowerPC32 violates the SysV ABI spec for small struct returns
Hi Sirl, As you mentioned in Bugzilla (comment 13), aix_return ( return in memory) svr4_return (return in register) what is the semantics of svr4gnu w.r.t. return. On Mon, Nov 19, 2018 at 11:33 PM Franz Sirl wrote: > > Am 2018-11-19 um 15:36 schrieb Lokesh Janghel: > > Hi Segher, > > > > I am building the GCC with the following configuration ( using gcc trunk ). > > ../gcc/configure --target=powerpc-linux > > --prefix=/opt/buckeye/powerpc-linux --disable-shared --disable-threads > > --enable-languages=c --with-newlib > > > > And my assembly code (without optimization) is: > > $ cc1 -msvr4-struct-return test.c > > .LFB0: > > stwu 1,-32(1) > > .LCFI0: > > stw 31,28(1) > > .LCFI1: > > mr 31,1 > > .LCFI2: > > lis 9,.LC0@ha > > la 9,.LC0@l(9) > > lhz 10,0(9) > > lbz 9,2(9) > > sth 10,11(31) > > stb 9,13(31) > > lhz 10,11(31) > > lbz 9,13(31) > > sth 10,8(31) > > stb 9,10(31) > > li 9,0 > > lbz 10,8(31) > > rlwinm 10,10,0,24,31 > > slwi 10,10,16 > > rlwinm 9,9,0,16,7 > > or 9,9,10 > > lbz 10,9(31) > > rlwinm 10,10,0,24,31 > > slwi 10,10,8 > > rlwinm 9,9,0,24,15 > > or 9,9,10 > > lbz 10,10(31) > > rlwinm 10,10,0,24,31 > > rlwinm 9,9,0,0,23 > > or 9,9,10 > > mr 3,9 > > addi 11,31,32 > > lwz 31,-4(11) > > .LCFI3: > > mr 1,11 > > .LCFI4: > > blr > > > > > > Assembly code (with optimization -O2) is: > > $ cc1 -msvr4-struct-return -O2 test.c > > .LFB0: > > stwu 1,-32(1) > > .LCFI0: > > lis 3,0x11 > > ori 3,3,0x2233 > > addi 1,1,32 > > .LCFI1: > > blr > > > > As you mentioned assembly code in the GCC Bugzilla, I am not able to > > reproduce the issue. > > Please let me know your options used to reproduce this issue. > > Hi, > > you already reproduced the issue, according to the ABI, the code should > look like: > > .LFB0: > stwu 1,-32(1) > .LCFI0: > lis 3,0x1122 > ori 3,3,0x3300 > addi 1,1,32 > .LCFI1: > blr > > So the value being passed around should be left-aligned in the register. > > > Sirl, > > If you got the patch for this issue or will look into the issue. > > I have an unfinished patch, it misses commandline handling, testcases > and some code comments. I've attached it. > > It's unlikely I can continue to work on it anytime soon :-(. > > Franz -- Thanks & Regards Lokesh Janghel +91-9752984749
