ICEs in print_operand() of the rs6000 backend with invalid input assembly
Hi, 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). For example, when feeding gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c to the powerpc-targeted compiler: % powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118 -c gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c during RTL pass: final gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c: In function 'foo': gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c:10:1: internal compiler error: in print_operand, at config/rs6000/rs6000.c:20992 10 | } | ^ 0x6da7e3 print_operand(_IO_FILE*, rtx_def*, int) <…>/gcc-9-20181118/gcc/config/rs6000/rs6000.c:20992 0x9eb84f output_operand(rtx_def*, int) <…>/gcc-9-20181118/gcc/final.c:4042 0x9ec4d6 output_asm_insn(char const*, rtx_def**) <…>/gcc-9-20181118/gcc/final.c:3935 0x9ee6a6 final_scan_insn_1 <…>/gcc-9-20181118/gcc/final.c:2712 0x9ee998 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) <…>/gcc-9-20181118/gcc/final.c:3149 0x9eecae final_1 <…>/gcc-9-20181118/gcc/final.c:2019 0x9ef838 rest_of_handle_final <…>/gcc-9-20181118/gcc/final.c:4649 0x9ef838 execute <…>/gcc-9-20181118/gcc/final.c:4723 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? Thanks.
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.
> For example, when feeding
> gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c to the
> powerpc-targeted compiler:
>
> % powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118 -c
> gcc/testsuite/gcc.target/i386/indirect-thunk-register-4.c
(This is a V output modifier, which expects a trap code, which you cannot
give in inline asm at all).
> 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! 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.
Thanks,
Segher
p.s. Patch for the %V thing:
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index ac0e210..9b29f0b 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -20971,7 +20971,7 @@ print_operand (FILE *file, rtx x, int code)
fputs ("lge", file); /* 5 */
break;
default:
- gcc_unreachable ();
+ output_operand_lossage ("invalid %%V value");
}
break;
Re: Bug 84762 - GCC for PowerPC32 violates the SysV ABI spec for small struct returns
Hi Sirl, As you mention in Bugzilla (comment 13), aix_return( return in memory) svr4_return(in registers) what is the semantics of *svr4gnu* w.r.t return . On Mon, Nov 19, 2018 at 11:33 PM Franz Sirl < franz.sirl-ker...@lauterbach.com> 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
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 < franz.sirl-ker...@lauterbach.com> 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
question about attribute aligned for functions
GCC currently accepts the declaration of f0 below but ignores the attribute. On aarch64 (and I presume on other targets with a default function alignment greater than 1), GCC rejects f1 with an error, even though it accepts -falign-functions=1 without as much as a warning. Clang, on the other hand, rejects f0 with a hard error because the alignment is not a power of two, but accepts f1 and appears to honor the attribute. It also accepts -falign-functions=1. I think diagnosing f0 with a warning is helpful because an explicit zero alignment is most likely a mistake (especially when it comes from a macro or some computation). But I don't see a good reason to reject a program that specifies a smaller alignment for a function when the default (or minimum) alignment is greater. A smaller alignment is trivially satisfied by a greater alignment so either accepting it or dropping it seems preferable to failing with an error (either could be with or without a warning). __attribute__ ((aligned (0))) void f0 (void); // accepted, ignored __attribute__ ((aligned (1))) void f1 (void); // aarch64 error __attribute__ ((aligned (4))) void f4 (void); // okay Does anyone know why GCC rejects the program, or can anyone think of a reason why GCC should not behave as suggested above? Thanks Martin
gcc-8-20181123 is now available
Snapshot gcc-8-20181123 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20181123/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 266422 You'll find: gcc-8-20181123.tar.xzComplete GCC SHA256=e35fe8aae95021b470c25c75aecbc53bcd585c2b70796fc6cef48537d079d115 SHA1=91cf4803f1b58c4e4a114bd2394e15d62291 Diffs from 8-20181116 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 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.
