Re: ICE's with -fgimple

2016-12-20 Thread Richard Biener
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

2016-12-20 Thread Ulrich Weigand
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

2016-12-20 Thread Szabolcs Nagy
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

2016-12-20 Thread gccadmin
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.