Re: ICE's with -fgimple
On Sun, 18 Dec 2016, Prathamesh Kulkarni wrote: > Hi, > I observed a couple of similar ICE's with -fgimple for a function > having startwith. > > eg: > void __GIMPLE (startwith ("ccp1")) foo () > { > return; > } > > Compiling with -fgimple -O works fine however removing -O causes the > following ICE: > foo.c:7:1: internal compiler error: in expand, at cgraphunit.c:2054 > } > ^ > 0x7d4b5c cgraph_node::expand() > ../../gcc/gcc/cgraphunit.c:2054 > 0x7d5852 output_in_order > ../../gcc/gcc/cgraphunit.c:2244 > 0x7d5bfd symbol_table::compile() > ../../gcc/gcc/cgraphunit.c:2488 > 0x7d86e2 symbol_table::compile() > ../../gcc/gcc/cgraphunit.c:2558 > 0x7d86e2 symbol_table::finalize_compilation_unit() > > The following ICE is observed when startwith is set to some of the > later passes even with -O, > starting with fre3 like vrp1, pre, strlen (but few passes after fre3 > like thread1, dce2 don't cause ICE). > > foo.c: In function ‘foo’: > foo.c:7:1: internal compiler error: in expand, at cgraphunit.c:2054 > } > ^ > 0x7d4b5c cgraph_node::expand() > ../../gcc/gcc/cgraphunit.c:2054 > 0x7d6217 expand_all_functions > ../../gcc/gcc/cgraphunit.c:2137 > 0x7d6217 symbol_table::compile() > ../../gcc/gcc/cgraphunit.c:2494 > 0x7d86e2 symbol_table::compile() > ../../gcc/gcc/cgraphunit.c:2558 > 0x7d86e2 symbol_table::finalize_compilation_unit() > ../../gcc/gcc/cgraphunit.c:2584 That's an "imperfection" with the pass manager integration (you'll see similar ICEs when starswith picks a pass inside the loop pipeline for example). If you fix the expansion issue you'll still run into the fact that expand requires PROP_gimple_lvec for example and that the provider is not executed. "Fixing" that correctly requires some re-thinking of how we schedule passes in general, but for the moment the following patch works for me... (testing) Richard. 2016-12-20 Richard Biener * passes.c (execute_one_pass): Handle going out of SSA w/o hitting pass_startwith. Handle skipping property providers. * gcc.dg/gimplefe-19.c: New testcase. Index: gcc/passes.c === --- gcc/passes.c(revision 243738) +++ gcc/passes.c(working copy) @@ -2321,7 +2324,10 @@ execute_one_pass (opt_pass *pass) && (cfun->curr_properties & PROP_ssa)) { size_t namelen = strlen (pass->name); - if (! strncmp (pass->name, cfun->pass_startwith, namelen)) + /* We have to at least start when we leave SSA. */ + if (pass->properties_destroyed & PROP_ssa) + cfun->pass_startwith = NULL; + else if (! strncmp (pass->name, cfun->pass_startwith, namelen)) { /* The following supports starting with the Nth invocation of a pass (where N does not necessarily is equal to the @@ -2338,6 +2344,9 @@ execute_one_pass (opt_pass *pass) return true; } } + /* And also run any property provider. */ + else if (pass->properties_provided != 0) + ; else return true; } Index: gcc/testsuite/gcc.dg/gimplefe-19.c === --- gcc/testsuite/gcc.dg/gimplefe-19.c (revision 0) +++ gcc/testsuite/gcc.dg/gimplefe-19.c (working copy) @@ -0,0 +1,7 @@ +/* { dg-do compile } */ +/* { dg-options "-fgimple" } */ + +void __GIMPLE (startwith ("ccp1")) foo () +{ + return; +}
Re: GCC libatomic ABI specification draft
Torvald Riegel wrote: > On Fri, 2016-12-02 at 12:13 +0100, Gabriel Paubert wrote: > > On Thu, Dec 01, 2016 at 11:13:37AM -0800, Bin Fan at Work wrote: > > > Thanks for the comment. Yes, the ABI requires libatomic must query the > > > hardware. This is > > > necessary if we want the compiler to generate inlined code for 16-byte > > > atomics. Note that > > > this particular issue only affects x86. > > > > Why? Power (at least recent ones) has 128 bit atomic instructions > > (lqarx/stqcx.) and Z has 128 bit compare and swap. > > That's not the only factor affecting whether cmpxchg16b or such is used > for atomics. If the HW just offers a wide CAS but no wide atomic load, > then even an atomic load is not truly just a load, which breaks (1) > atomic loads on read-only mapped memory and (2) volatile atomic loads > (unless we claim that an idempotent store is like a load, which is quite > a stretch for volatile I think). I may have missed the context of the discussion, but just on the specific ISA question here: both Power and z not only have the 16-byte CAS (or load-and-reserve/store-conditional), but they also both have specific 16-byte atomic load and store instructions (lpq/stpq on z, lq/stq on Power). Those are available on any system supporting z/Architecture (z900 and up), and on any Power system supporting the V2.07 ISA (POWER8 and up). GCC does in fact use those instructions to implement atomic operations on 16-byte data types on those machines. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
Re: GCC libatomic ABI specification draft
On 20/12/16 13:26, Ulrich Weigand wrote: > Torvald Riegel wrote: >> On Fri, 2016-12-02 at 12:13 +0100, Gabriel Paubert wrote: >>> On Thu, Dec 01, 2016 at 11:13:37AM -0800, Bin Fan at Work wrote: Thanks for the comment. Yes, the ABI requires libatomic must query the hardware. This is necessary if we want the compiler to generate inlined code for 16-byte atomics. Note that this particular issue only affects x86. >>> >>> Why? Power (at least recent ones) has 128 bit atomic instructions >>> (lqarx/stqcx.) and Z has 128 bit compare and swap. >> >> That's not the only factor affecting whether cmpxchg16b or such is used >> for atomics. If the HW just offers a wide CAS but no wide atomic load, >> then even an atomic load is not truly just a load, which breaks (1) >> atomic loads on read-only mapped memory and (2) volatile atomic loads >> (unless we claim that an idempotent store is like a load, which is quite >> a stretch for volatile I think). > > I may have missed the context of the discussion, but just on the > specific ISA question here: both Power and z not only have the > 16-byte CAS (or load-and-reserve/store-conditional), but they also both > have specific 16-byte atomic load and store instructions (lpq/stpq > on z, lq/stq on Power). > > Those are available on any system supporting z/Architecture (z900 and up), > and on any Power system supporting the V2.07 ISA (POWER8 and up). GCC > does in fact use those instructions to implement atomic operations on > 16-byte data types on those machines. that's a bug. at least i don't see how gcc makes sure the libatomic calls can interoperate with inlined atomics.
gcc-5-20161220 is now available
Snapshot gcc-5-20161220 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20161220/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 243830 You'll find: gcc-5-20161220.tar.bz2 Complete GCC MD5=70bc47040743c2f19880594b79bd8fbe SHA1=f5a11e2d10027fcd37fa8cb070e66cf9d2a5924f Diffs from 5-20161213 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 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.