Re: [PATCH] Reenable CSE of non-volatile inline asm (PR rtl-optimization/63637)

2015-01-15 Thread Jakub Jelinek
On Thu, Jan 15, 2015 at 07:46:18AM +0100, Richard Biener wrote:
> >> That last line means the compiler is free to delete a non-volatile
> >> asm with a memory clobber if that asm is not needed for dataflow.  Or
> >> that is how I read it; it is trying to indicate that if you want to
> >> prevent the memory clobber from being deleted (together with the rest
> >> of the asm), you need to make the asm volatile.
> >>
> >> So as far as I can see the compiler can CSE two identical
> >non-volatile
> >> asms with memory clobber just fine.  Older GCC (I tried 4.7.2) does
> >do
> >> this; current mainline doesn't.  I think it should.
> >No, it should not CSE those two cases.  That's simply wrong and if an 
> >older version did that optimization, that's a bug.
> 
> I think segher has a point here.  If the asm with memory clobber would store 
> to random memory and the point would be to preserve that then the whole 
> distinction with volatile doesn't make much sense (after all without volatile 
> we happily DCE such asm if the regular outputs are not needed).
> 
> This doesn't mean 'memory' is a well-designed thing, of course. Just its
> effects are effectively limited to reads without volatile(?)

Segher's mails talk about "memory" being a write but not read.
If we even can't agree on what non-volatile "memory" means, I think
we should treat it more conservatively, because every user (and there are
lots of people using non-volatile asm with "memory" in the wild) treats it
differently.  Just trying to grep for a few:
glibc:
./sysdeps/alpha/bits/atomic.h:# define atomic_full_barrier()__asm ("mb" : : 
: "memory");
./sysdeps/alpha/bits/atomic.h:# define atomic_read_barrier()__asm ("mb" : : 
: "memory");
./sysdeps/alpha/bits/atomic.h:# define atomic_write_barrier()   __asm ("wmb" : 
: : "memory");
./sysdeps/sparc/sparc32/bits/atomic.h:# define atomic_full_barrier() __asm ("" 
::: "memory")
./sysdeps/powerpc/powerpc32/bits/atomic.h:# define atomic_read_barrier()
__asm ("lwsync" ::: "memory")
./sysdeps/powerpc/powerpc32/bits/atomic.h:# define atomic_read_barrier()
__asm ("sync" ::: "memory")
./sysdeps/powerpc/powerpc64/bits/atomic.h:#define atomic_read_barrier() __asm 
("lwsync" ::: "memory")
./sysdeps/powerpc/bits/atomic.h:#define atomic_full_barrier()   __asm ("sync" 
::: "memory")
./sysdeps/powerpc/bits/atomic.h:#define atomic_write_barrier()  __asm ("eieio" 
::: "memory")
./sysdeps/generic/malloc-machine.h:# define atomic_full_barrier() __asm ("" ::: 
"memory")
./elf/tst-tlsmod3.c:  asm ("" ::: "memory");
./elf/tst-tlsmod4.c:  asm ("" ::: "memory");
./elf/tst-tlsmod1.c:  asm ("" ::: "memory");
./elf/tst-tlsmod2.c:  asm ("" ::: "memory");
./include/atomic.h:# define atomic_full_barrier() __asm ("" ::: "memory")
linux kernel:
./arch/arm/mach-omap2/pm24xx.c: asm("mcr p15, 0, %0, c7, c0, 4" : : "r" (zero) 
: "memory", "cc");
./arch/arm/include/asm/irqflags.h:#define local_fiq_enable()  __asm__("cpsie f  
@ __stf" : : : "memory", "cc")
./arch/arm/include/asm/irqflags.h:#define local_fiq_disable() __asm__("cpsid f  
@ __clf" : : : "memory", "cc")
./arch/x86/include/asm/uaccess_64.h:asm("":::"memory");
./arch/x86/include/asm/uaccess_64.h:asm("":::"memory");
./arch/x86/include/asm/segment.h:   asm("mov %%" #seg ",%0":"=r" (value) : 
: "memory")
./arch/x86/include/asm/stackprotector.h:asm("mov %0, %%gs" : : "r" 
(__KERNEL_STACK_CANARY) : "memory");
./arch/arm64/include/asm/irqflags.h:#define local_fiq_enable()  asm("msr
daifclr, #1" : : : "memory")
./arch/arm64/include/asm/irqflags.h:#define local_fiq_disable() asm("msr
daifset, #1" : : : "memory")
./arch/arm64/include/asm/irqflags.h:#define local_async_enable()
asm("msrdaifclr, #4" : : : "memory")
./arch/arm64/include/asm/irqflags.h:#define local_async_disable()   
asm("msrdaifset, #4" : : : "memory")
./arch/tile/lib/memcpy_64.c:__asm__ ("" : : : 
"memory");
./arch/tile/lib/memcpy_64.c:__asm__ ("" : : : 
"memory");
./arch/tile/include/hv/netio_intf.h:  __asm__("" : : : "memory");
./drivers/net/ethernet/sgi/ioc3-eth.c:  __asm__("sync" ::: "memory")
./lib/sha1.c:  #define setW(x, val) do { W(x) = (val); __asm__("":::"memory"); 
} while (0)

The glibc barriers are supposedly something that can be CSEd (one barrier 
instead of
two consecutive barriers is enough), but certainly not moved across any 
loads/stores
in between.  In the kernel case, the enable/disable probably wouldn't allow 
even CSE.

So I'm with Jeff that we should treat "memory" at least as unspecified read and 
write,
and whether we can CSE them if there are no memory loads/stores in between them 
can
be discussed (most likely the kernel would be safe even in that case, because 
those
usually don't nest and appear in pairs, or act as barriers (like the glibc 
case),
or read from segment registers (guess again ok to be CSEd with no intervening 
loads/stores).

Re: [PATCH] Reenable CSE of non-volatile inline asm (PR rtl-optimization/63637)

2015-01-15 Thread Richard Biener
On Thu, 15 Jan 2015, Jakub Jelinek wrote:

> On Thu, Jan 15, 2015 at 07:46:18AM +0100, Richard Biener wrote:
> > >> That last line means the compiler is free to delete a non-volatile
> > >> asm with a memory clobber if that asm is not needed for dataflow.  Or
> > >> that is how I read it; it is trying to indicate that if you want to
> > >> prevent the memory clobber from being deleted (together with the rest
> > >> of the asm), you need to make the asm volatile.
> > >>
> > >> So as far as I can see the compiler can CSE two identical
> > >non-volatile
> > >> asms with memory clobber just fine.  Older GCC (I tried 4.7.2) does
> > >do
> > >> this; current mainline doesn't.  I think it should.
> > >No, it should not CSE those two cases.  That's simply wrong and if an 
> > >older version did that optimization, that's a bug.
> > 
> > I think segher has a point here.  If the asm with memory clobber would 
> > store to random memory and the point would be to preserve that then the 
> > whole distinction with volatile doesn't make much sense (after all without 
> > volatile we happily DCE such asm if the regular outputs are not needed).
> > 
> > This doesn't mean 'memory' is a well-designed thing, of course. Just its
> > effects are effectively limited to reads without volatile(?)
> 
> Segher's mails talk about "memory" being a write but not read.
> If we even can't agree on what non-volatile "memory" means, I think
> we should treat it more conservatively, because every user (and there are
> lots of people using non-volatile asm with "memory" in the wild) treats it
> differently.  Just trying to grep for a few:
> glibc:
> ./sysdeps/alpha/bits/atomic.h:# define atomic_full_barrier()  __asm ("mb" : : 
> : "memory");
> ./sysdeps/alpha/bits/atomic.h:# define atomic_read_barrier()  __asm ("mb" : : 
> : "memory");
> ./sysdeps/alpha/bits/atomic.h:# define atomic_write_barrier() __asm ("wmb" : 
> : : "memory");
> ./sysdeps/sparc/sparc32/bits/atomic.h:# define atomic_full_barrier() __asm 
> ("" ::: "memory")
> ./sysdeps/powerpc/powerpc32/bits/atomic.h:# define atomic_read_barrier()  
> __asm ("lwsync" ::: "memory")
> ./sysdeps/powerpc/powerpc32/bits/atomic.h:# define atomic_read_barrier()  
> __asm ("sync" ::: "memory")
> ./sysdeps/powerpc/powerpc64/bits/atomic.h:#define atomic_read_barrier()   
> __asm ("lwsync" ::: "memory")
> ./sysdeps/powerpc/bits/atomic.h:#define atomic_full_barrier() __asm ("sync" 
> ::: "memory")
> ./sysdeps/powerpc/bits/atomic.h:#define atomic_write_barrier()__asm 
> ("eieio" ::: "memory")
> ./sysdeps/generic/malloc-machine.h:# define atomic_full_barrier() __asm ("" 
> ::: "memory")
> ./elf/tst-tlsmod3.c:  asm ("" ::: "memory");
> ./elf/tst-tlsmod4.c:  asm ("" ::: "memory");
> ./elf/tst-tlsmod1.c:  asm ("" ::: "memory");
> ./elf/tst-tlsmod2.c:  asm ("" ::: "memory");
> ./include/atomic.h:# define atomic_full_barrier() __asm ("" ::: "memory")
> linux kernel:
> ./arch/arm/mach-omap2/pm24xx.c:   asm("mcr p15, 0, %0, c7, c0, 4" : : "r" 
> (zero) : "memory", "cc");
> ./arch/arm/include/asm/irqflags.h:#define local_fiq_enable()  __asm__("cpsie 
> f@ __stf" : : : "memory", "cc")
> ./arch/arm/include/asm/irqflags.h:#define local_fiq_disable() __asm__("cpsid 
> f@ __clf" : : : "memory", "cc")
> ./arch/x86/include/asm/uaccess_64.h:  asm("":::"memory");
> ./arch/x86/include/asm/uaccess_64.h:  asm("":::"memory");
> ./arch/x86/include/asm/segment.h: asm("mov %%" #seg ",%0":"=r" (value) : 
> : "memory")
> ./arch/x86/include/asm/stackprotector.h:  asm("mov %0, %%gs" : : "r" 
> (__KERNEL_STACK_CANARY) : "memory");
> ./arch/arm64/include/asm/irqflags.h:#define local_fiq_enable()
> asm("msrdaifclr, #1" : : : "memory")
> ./arch/arm64/include/asm/irqflags.h:#define local_fiq_disable()   
> asm("msrdaifset, #1" : : : "memory")
> ./arch/arm64/include/asm/irqflags.h:#define local_async_enable()  
> asm("msrdaifclr, #4" : : : "memory")
> ./arch/arm64/include/asm/irqflags.h:#define local_async_disable() 
> asm("msrdaifset, #4" : : : "memory")
> ./arch/tile/lib/memcpy_64.c:  __asm__ ("" : : : 
> "memory");
> ./arch/tile/lib/memcpy_64.c:  __asm__ ("" : : : 
> "memory");
> ./arch/tile/include/hv/netio_intf.h:  __asm__("" : : : "memory");
> ./drivers/net/ethernet/sgi/ioc3-eth.c:__asm__("sync" ::: "memory")
> ./lib/sha1.c:  #define setW(x, val) do { W(x) = (val); 
> __asm__("":::"memory"); } while (0)
> 
> The glibc barriers are supposedly something that can be CSEd (one barrier 
> instead of
> two consecutive barriers is enough), but certainly not moved across any 
> loads/stores
> in between.  In the kernel case, the enable/disable probably wouldn't allow 
> even CSE.
> 
> So I'm with Jeff that we should treat "memory" at least as unspecified read 
> and write,
> and whether we can CSE them if there are no memory loads/stores in between 
> them can
> be dis

Re: [PATCH] Fix PR64365

2015-01-15 Thread Richard Biener
On Wed, 14 Jan 2015, Richard Biener wrote:

> 
> This fixes an issue in dependence analysis and how we make pointer
> dereferences visible to it.  Basically dependence analysis works
> on indices (assuming we deal with arrays) and thus never needs
> sth like an access size (because indices are non-sparse and
> different index means a different memory area).  Dereferences
> breaks this because we present dependence analysis with a
> sparse index space.  Thus to rule out partially overlapping
> accesses we have to make sure to separate bases (only equal
> bases get treated this way).
> 
> The following ensures this by making the indices multiples of
> the access size (and shifting the byte offset modulo the access
> size to the base object).
> 
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.

I have applied the following variant which also handles NULL
TYPE_SIZE_UNIT and treats those cases less conservative by
simply forcing the index to be always zero.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
sofar.

Richard.

2015-01-15  Richard Biener  

PR middle-end/64365
* tree-data-ref.c (dr_analyze_indices): Make sure that accesses
for MEM_REF access functions with the same base can never partially
overlap.

* gcc.dg/torture/pr64365.c: New testcase.

Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c (revision 219603)
+++ gcc/tree-data-ref.c (working copy)
@@ -992,6 +994,22 @@ dr_analyze_indices (struct data_referenc
fold_convert (ssizetype, memoff));
  memoff = build_int_cst (TREE_TYPE (memoff), 0);
}
+ /* Adjust the offset so it is a multiple of the access type
+size and thus we separate bases that can possibly be used
+to produce partial overlaps (which the access_fn machinery
+cannot handle).  */
+ wide_int rem;
+ if (TYPE_SIZE_UNIT (TREE_TYPE (ref))
+ && TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (ref))) == INTEGER_CST
+ && !integer_zerop (TYPE_SIZE_UNIT (TREE_TYPE (ref
+   rem = wi::mod_trunc (off, TYPE_SIZE_UNIT (TREE_TYPE (ref)), SIGNED);
+ else
+   /* If we can't compute the remainder simply force the initial
+  condition to zero.  */
+   rem = off;
+ off = wide_int_to_tree (ssizetype, wi::sub (off, rem));
+ memoff = wide_int_to_tree (TREE_TYPE (memoff), rem);
+ /* And finally replace the initial condition.  */
  access_fn = chrec_replace_initial_condition
  (access_fn, fold_convert (orig_type, off));
  /* ???  This is still not a suitable base object for

Index: gcc/testsuite/gcc.dg/torture/pr64365.c
===
--- gcc/testsuite/gcc.dg/torture/pr64365.c  (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr64365.c  (working copy)
@@ -0,0 +1,37 @@
+/* { dg-do run } */
+/* { dg-require-effective-target int32plus } */
+
+extern void abort (void);
+extern int memcmp (const void * , const void *, __SIZE_TYPE__);
+
+void __attribute__((noinline,noclone))
+foo(int *in)
+{
+  int i;
+  for (i = 62; i >= 10; i--)
+{
+  in[i - 8] -= in[i];
+  in[i - 5] += in[i] * 2;
+  in[i - 4] += in[i];
+}
+}
+
+int main()
+{
+  int x[64];
+  int y[64] = { 0, 1, -2380134, -1065336, -1026376, 3264240, 3113534, 2328130, 
3632054, 3839634, 2380136, 1065339, 1026380, 1496037, 1397286, 789976, 386408, 
450984, 597112, 497464, 262008, 149184, 194768, 231519, 173984, 87753, 60712, 
82042, 87502, 60014, 30050, 25550, 33570, 32386, 20464, 10675, 10868, 13329, 
11794, 6892, 3988, 4564, 5148, 4228, 2284, 1568, 1848, 1943, 1472, 741, 628, 
702, 714, 474, 230, 234, 238, 242, 120, 59, 60, 61, 62, 63 };
+  int i;
+
+  for (i = 0; i < 64; ++i)
+{
+  x[i] = i;
+  __asm__ volatile ("");
+}
+
+  foo (x);
+
+  if (memcmp (x, y, sizeof (x)) != 0)
+abort ();
+
+  return 0;
+}


Re: [patch] update function comments for lto_symtab_encoder_encode_*

2015-01-15 Thread Richard Biener
On Wed, Jan 14, 2015 at 5:58 PM, Aldy Hernandez  wrote:
> On 01/14/2015 01:06 AM, Richard Biener wrote:
>
>>> Whenever I get to the LTO part of this project, I promise to start
>>> documenting things better.  This whole thing is a mystery.
>>
>>
>> Well - mostly to me as well ;)  I'll let Honza answer this...
>
>
> Ha, you're being too modest!  I get the feeling that no one wants to own up
> to LTO :).
>
> So...
>
> Would anyone mind if I removed all references of "WHOPR" in the
> documentation (doc/lto.texi) and in *most* of the comments in the source?
> AFAICT, WHOPR has been the default LTO mode since Richard's linker plugin
> patch here:
>
> https://gcc.gnu.org/ml/gcc-patches/2014-03/msg00157.html
>
> From what I can see, WHOPR is the default unless no partitions were found,
> but otherwise there is no way to disable it.  It's just confusing to have
> this nomenclature that is mostly not applicable.

You can disable WHOPR with -flto-partition=none, otherwise partitions
are always "found" (thus even if we identify only a single partition
we use a separate ltrans process).

> I obviously wouldn't change actual code, since we're past stage1, but
> comments/documentation are fair game.  Eventually, I'd like to change the
> code to something like "LTO partitioning mode" or something (at the next
> stage1).
>
> Would this be acceptable?

I'm not sure what you propose to change?  The references to "WHOPR"
may be historical (refering to the design document), and re-wording
the user-level and internals documentation to make it the default behavior
and maybe cite non-whopr mode as optimization in case of a single
partition is ok.

Note that we still have the issue that we want to exercise both
WHOPR and non-WHOPR in the testsuite but all testcases are so
small that we'd automagically would use non-WHOPR mode (if
such automatism was implemented...).

Richard.

> Aldy


Re: [PATCH] Reenable CSE of non-volatile inline asm (PR rtl-optimization/63637)

2015-01-15 Thread Jakub Jelinek
On Thu, Jan 15, 2015 at 09:13:30AM +0100, Jakub Jelinek wrote:
> differently.  Just trying to grep for a few:
> glibc:
> ./sysdeps/alpha/bits/atomic.h:# define atomic_full_barrier()  __asm ("mb" : : 
> : "memory");
> ./sysdeps/alpha/bits/atomic.h:# define atomic_read_barrier()  __asm ("mb" : : 
> : "memory");
> ./sysdeps/alpha/bits/atomic.h:# define atomic_write_barrier() __asm ("wmb" : 
> : : "memory");
> ./sysdeps/sparc/sparc32/bits/atomic.h:# define atomic_full_barrier() __asm 
> ("" ::: "memory")
> ./sysdeps/powerpc/powerpc32/bits/atomic.h:# define atomic_read_barrier()  
> __asm ("lwsync" ::: "memory")
> ./sysdeps/powerpc/powerpc32/bits/atomic.h:# define atomic_read_barrier()  
> __asm ("sync" ::: "memory")
> ./sysdeps/powerpc/powerpc64/bits/atomic.h:#define atomic_read_barrier()   
> __asm ("lwsync" ::: "memory")
> ./sysdeps/powerpc/bits/atomic.h:#define atomic_full_barrier() __asm ("sync" 
> ::: "memory")
> ./sysdeps/powerpc/bits/atomic.h:#define atomic_write_barrier()__asm 
> ("eieio" ::: "memory")
> ./sysdeps/generic/malloc-machine.h:# define atomic_full_barrier() __asm ("" 
> ::: "memory")
> ./elf/tst-tlsmod3.c:  asm ("" ::: "memory");
> ./elf/tst-tlsmod4.c:  asm ("" ::: "memory");
> ./elf/tst-tlsmod1.c:  asm ("" ::: "memory");
> ./elf/tst-tlsmod2.c:  asm ("" ::: "memory");
> ./include/atomic.h:# define atomic_full_barrier() __asm ("" ::: "memory")
> linux kernel:
> ./arch/arm/mach-omap2/pm24xx.c:   asm("mcr p15, 0, %0, c7, c0, 4" : : "r" 
> (zero) : "memory", "cc");
> ./arch/arm/include/asm/irqflags.h:#define local_fiq_enable()  __asm__("cpsie 
> f@ __stf" : : : "memory", "cc")
> ./arch/arm/include/asm/irqflags.h:#define local_fiq_disable() __asm__("cpsid 
> f@ __clf" : : : "memory", "cc")
> ./arch/x86/include/asm/uaccess_64.h:  asm("":::"memory");
> ./arch/x86/include/asm/uaccess_64.h:  asm("":::"memory");
> ./arch/x86/include/asm/segment.h: asm("mov %%" #seg ",%0":"=r" (value) : 
> : "memory")
> ./arch/x86/include/asm/stackprotector.h:  asm("mov %0, %%gs" : : "r" 
> (__KERNEL_STACK_CANARY) : "memory");
> ./arch/arm64/include/asm/irqflags.h:#define local_fiq_enable()
> asm("msrdaifclr, #1" : : : "memory")
> ./arch/arm64/include/asm/irqflags.h:#define local_fiq_disable()   
> asm("msrdaifset, #1" : : : "memory")
> ./arch/arm64/include/asm/irqflags.h:#define local_async_enable()  
> asm("msrdaifclr, #4" : : : "memory")
> ./arch/arm64/include/asm/irqflags.h:#define local_async_disable() 
> asm("msrdaifset, #4" : : : "memory")
> ./arch/tile/lib/memcpy_64.c:  __asm__ ("" : : : 
> "memory");
> ./arch/tile/lib/memcpy_64.c:  __asm__ ("" : : : 
> "memory");
> ./arch/tile/include/hv/netio_intf.h:  __asm__("" : : : "memory");
> ./drivers/net/ethernet/sgi/ioc3-eth.c:__asm__("sync" ::: "memory")
> ./lib/sha1.c:  #define setW(x, val) do { W(x) = (val); 
> __asm__("":::"memory"); } while (0)

Oops, bad grep, only the 
./arch/x86/include/asm/segment.h: asm("mov %%" #seg ",%0":"=r" (value) : : 
"memory")
is what we are talking about actually, asm without outputs is implicitly
volatile.

Jakub


Re: [Patch] Missing plugin header files

2015-01-15 Thread Richard Biener
On Wed, Jan 14, 2015 at 10:43 PM, Steve Ellcey  wrote:
> I tried compiling an empty plugin that just included gcc-plugin.h and
> plugin-version.h and found that these header files were included from
> gcc-plugin.h but not in the list of header files to be copied to the
> plugin include directory.
>
> OK to checkin?

Ok.

Thanks,
Richard.

> Steve Ellcey
> sell...@imgtec.com
>
> 2015-01-14  Steve Ellcey  
>
> * Makefile.in (PLUGIN_HEADERS): Add dominance.h, cfg.h, cfgrtl.h,
> cfganal.h, cfgbuild.h, cfgcleanup.h, lcm.h, builtins.def,
> chkp-builtins.def, and pass-instances.def
>
>
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 44a4214..abe2d0d 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -3228,7 +3228,8 @@ PLUGIN_HEADERS = $(TREE_H) $(CONFIG_H) $(SYSTEM_H) 
> coretypes.h $(TM_H) \
>tree-ssa-loop.h tree-ssa-loop-ivopts.h tree-ssa-loop-manip.h \
>tree-ssa-loop-niter.h tree-ssa-ter.h tree-ssa-threadedge.h \
>tree-ssa-threadupdate.h inchash.h wide-int.h signop.h hash-map.h \
> -  hash-set.h pass-instances.def
> +  hash-set.h dominance.h cfg.h cfgrtl.h cfganal.h cfgbuild.h cfgcleanup.h \
> +  lcm.h builtins.def chkp-builtins.def pass-instances.def
>
>  # generate the 'build fragment' b-header-vars
>  s-header-vars: Makefile


Re: [PATCH PR64434]

2015-01-15 Thread Yuri Rumyantsev
Hi All,

I did a change proposed by Richard - unconditionally allocate from the heap.

Bootstrap and regression testing did not show any new failures.

Is it OK for trunk?

ChangeLog

2015-01-15  Yuri Rumyantsev  

PR tree-optimization/64434
* cfgexpand.c (reorder_operands): New function.
(expand_gimple_basic_block): Insert call of reorder_operands if
optimized is true.

gcc/testsuite/ChangeLog
* gcc.dg/torture/pr64434.c: New test.

2015-01-14 17:07 GMT+03:00 Yuri Rumyantsev :
> Jakub,
>
> I did all changes requested by you.
>
> Here is updated patch.
>
> BTW I thought that gcc performs splitting of blocks with huge  size.
>
>
> 2015-01-14 16:33 GMT+03:00 Jakub Jelinek :
>> On Wed, Jan 14, 2015 at 04:28:42PM +0300, Yuri Rumyantsev wrote:
>>> Hi All,
>>>
>>> I did all changes proposed by Richard and delete check on def in the
>>> same block as Jakub proposed.
>>> I also moved check  on optimization to call site..
>>>
>>> I also checked that bootstrap and regression testing did not show any
>>> new failures.
>>>
>>> Is it OK for trunk?
>>
>> The  | SSA_OP_VUSE is still in there, the testcase is still executable,
>> still doesn't end with newline, and I really think you should replace
>>   lattice = XALLOCAVEC (unsigned int, n);
>> with something like:
>>   if (n >= 10)
>> lattice = XNEWVEC (unsigned int, n);
>>   else
>> lattice = XALLOCAVEC (unsigned int, n);
>> ...
>>   if (n >= 10)
>> XDELETE (lattice);
>> or similar.
>>
>> Jakub


patch2
Description: Binary data


[AArch64] Add a new scheduling description for the ARM Cortex-A57 processor

2015-01-15 Thread James Greenhalgh

Hi,

This patch implements a new scheduler model for the ARM Cortex-A57
processor.

This model results in better code generation for the Cortex-A57 with a
more mixed blend of instruction types, particularly when scheduling for
the new instructions introduced in ARMv8-A.

I haven't yet wired it up for the ARM back end, though it is likely
to also be appropriate there. As is convention for these shared
models I've added the .md file to config/arm/cortex-a57.md

I've bootstrapped and tested the patch on an aarch64-none-linux-gnu
target with no regressions.

Is this patch OK for trunk?

Thanks,
James

---
2015-01-15  James Greenhalgh  

* config/arm/cortex-a57.md: New.
* config/aarch64/aarch64.md: Include it.
* config/aarch64/aarch64-cores.def (cortex-a57): Tune for it.
* config/aarch64/aarch64-tune.md: Regenerate.
diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index 18f5c48..e30beb0 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -35,7 +35,7 @@
 /* V8 Architecture Processors.  */
 
 AARCH64_CORE("cortex-a53",  cortexa53, cortexa53, 8,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa53)
-AARCH64_CORE("cortex-a57",  cortexa15, cortexa15, 8,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa57)
+AARCH64_CORE("cortex-a57",  cortexa57, cortexa57, 8,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa57)
 AARCH64_CORE("thunderx",thunderx,  thunderx, 8,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx)
 
 /* V8 big.LITTLE implementations.  */
diff --git a/gcc/config/aarch64/aarch64-tune.md b/gcc/config/aarch64/aarch64-tune.md
index c717ea848bcd4a4d9bce8b338b3643438ec7474e..f8455006e194c6b3261fc86a71ca8a88bd177f2a 100644
--- a/gcc/config/aarch64/aarch64-tune.md
+++ b/gcc/config/aarch64/aarch64-tune.md
@@ -1,5 +1,5 @@
 ;; -*- buffer-read-only: t -*-
 ;; Generated automatically by gentune.sh from aarch64-cores.def
 (define_attr "tune"
-	"cortexa53,cortexa15,thunderx,cortexa57cortexa53"
+	"cortexa53,cortexa57,thunderx,cortexa57cortexa53"
 	(const (symbol_ref "((enum attr_tune) aarch64_tune)")))
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index fc729515910718a6e4792de92b543d4e2524d568..6c9d76760dfa86e8649789776a21b771848d727c 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -188,7 +188,7 @@ (define_attr "enabled" "no,yes"
 
 ;; Scheduling
 (include "../arm/cortex-a53.md")
-(include "../arm/cortex-a15.md")
+(include "../arm/cortex-a57.md")
 (include "thunderx.md")
 
 ;; ---
diff --git a/gcc/config/arm/cortex-a57.md b/gcc/config/arm/cortex-a57.md
index ...c9782f20e9534f97bdb5e9f180f7f61010f930f0 100644
--- a/gcc/config/arm/cortex-a57.md
+++ b/gcc/config/arm/cortex-a57.md
@@ -0,0 +1,797 @@
+;; ARM Cortex-A57 pipeline description
+;; Copyright (C) 2014-2015 Free Software Foundation, Inc.
+;;
+;; This file is part of GCC.
+;;
+;; GCC is free software; you can redistribute it and/or modify it
+;; under the terms of the GNU General Public License as published by
+;; the Free Software Foundation; either version 3, or (at your option)
+;; any later version.
+;;
+;; GCC is distributed in the hope that it will be useful, but
+;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+;; General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public License
+;; along with GCC; see the file COPYING3.  If not see
+;; .
+
+(define_automaton "cortex_a57")
+
+(define_attr "cortex_a57_neon_type"
+  "neon_abd, neon_abd_q, neon_arith_acc, neon_arith_acc_q,
+   neon_arith_basic, neon_arith_complex,
+   neon_reduc_add_acc, neon_multiply, neon_multiply_q,
+   neon_multiply_long, neon_mla, neon_mla_q, neon_mla_long,
+   neon_sat_mla_long, neon_shift_acc, neon_shift_imm_basic,
+   neon_shift_imm_complex,
+   neon_shift_reg_basic, neon_shift_reg_basic_q, neon_shift_reg_complex,
+   neon_shift_reg_complex_q, neon_fp_negabs, neon_fp_arith,
+   neon_fp_arith_q, neon_fp_reductions_q, neon_fp_cvt_int,
+   neon_fp_cvt_int_q, neon_fp_cvt16, neon_fp_minmax, neon_fp_mul,
+   neon_fp_mul_q, neon_fp_mla, neon_fp_mla_q, neon_fp_recpe_rsqrte,
+   neon_fp_recpe_rsqrte_q, neon_fp_recps_rsqrts, neon_fp_recps_rsqrts_q,
+   neon_bitops, neon_bitops_q, neon_from_gp,
+   neon_from_gp_q, neon_move, neon_tbl3_tbl4, neon_zip_q, neon_to_gp,
+   neon_load_a, neon_load_b, neon_load_c, neon_load_d, neon_load_e,
+   neon_load_f, neon_store_a, neon_store_b, neon_store_complex,
+   unknown"
+  (cond [
+	  (eq_attr "type" "neon_abd, neon_abd_long")
+	(const_string "neon_abd")
+	  (eq_attr "type" "neon_abd_q")
+	(const_string "neon_abd_q")
+	  (eq_attr "type" "neon_arith_acc, neon_reduc_add_acc,\
+			   neon_reduc_add_acc_q")
+	(const_string "neon_arith_acc")

[Ping] [C++ Patch] PR 58614

2015-01-15 Thread Paolo Carlini

Hi,

pinging this patchlet...

https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01926.html

On 12/29/2014 03:54 PM, Paolo Carlini wrote:

Hi,

in this ICE on invalid, we crash during error recovery when 
maybe_adjust_types_for_deduction gets an elt which has TREE_TYPE (elt) 
== error_mark_node. I think we can simply check for that and return 
unify_invalid. Tested x86_64-linux.

Thanks!
Paolo.



RE: [PATCH, RFC] LRA subreg handling

2015-01-15 Thread Robert Suchanek
> Robert, can you look at reload.c::reload_inner_reg_of_subreg and verify
> that the comment just before its return statement is effectively the
> situation you're in.
> 
> There are certainly cases where a SUBREG needs to be treated as an
> in-out operand.  We walked through them eons ago when we were poking at
> SSA for RTL.  But the details have long since faded from memory.

The comment pretty much applies to my situation.  The only difference I can
see is that reload would have had hard registers at this point.  In the 
testcase,
LRA does not have hard registers assigned to the concerned pseudo(s), thus, 
it can't rely on the information in hard_regno_nregs to check if the number of
registers in INNER is different to the number of words in INNER.

Robert


Re: [PATCH PR64434]

2015-01-15 Thread Richard Biener
On Thu, Jan 15, 2015 at 10:39 AM, Yuri Rumyantsev  wrote:
> Hi All,
>
> I did a change proposed by Richard - unconditionally allocate from the heap.
>
> Bootstrap and regression testing did not show any new failures.
>
> Is it OK for trunk?

+  if (!is_gimple_assign (stmt)
+ || gimple_has_volatile_ops (stmt))
+   continue;
+  code = gimple_assign_rhs_code (stmt);
+  if (!commutative_tree_code (code))
+   continue;
+  gcc_assert (gimple_num_ops (stmt) == 3);
+  op0 = gimple_op (stmt, 1);
+  op1 = gimple_op (stmt, 2);
+  if (op0 == NULL_TREE || op1 == NULL_TREE
+ || TREE_CODE (op0) != SSA_NAME
+ || TREE_CODE (op1) != SSA_NAME)
+   continue;

you can simplify this to

 if (!is_gimple_assign (stmt)
|| !commutative_tree_code (gimple_assign_rhs_code (stmt)))
   continue;
 op0 = gimple_assign_rhs1 (stmt);
 op1 = gimple_assign_rhs2 (Stmt);
 if (TREE_CODE (op0) != SSA_NAME
 || TREE_CODE (op1) != SSA_NAME)
   continue;

Please output the computed costs for both operands in

+ if (dump_file && (dump_flags & TDF_DETAILS))
+   {
+ fprintf (dump_file, "Swap operands in stmt:\n");
+ print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM);
+   }

as that will help debugging if odd things happen.

Ok with that changes.  I belive this may fix some duplicate bugs
as well.

Thanks,
Richard.


> ChangeLog
>
> 2015-01-15  Yuri Rumyantsev  
>
> PR tree-optimization/64434
> * cfgexpand.c (reorder_operands): New function.
> (expand_gimple_basic_block): Insert call of reorder_operands if
> optimized is true.
>
> gcc/testsuite/ChangeLog
> * gcc.dg/torture/pr64434.c: New test.
>
> 2015-01-14 17:07 GMT+03:00 Yuri Rumyantsev :
>> Jakub,
>>
>> I did all changes requested by you.
>>
>> Here is updated patch.
>>
>> BTW I thought that gcc performs splitting of blocks with huge  size.
>>
>>
>> 2015-01-14 16:33 GMT+03:00 Jakub Jelinek :
>>> On Wed, Jan 14, 2015 at 04:28:42PM +0300, Yuri Rumyantsev wrote:
 Hi All,

 I did all changes proposed by Richard and delete check on def in the
 same block as Jakub proposed.
 I also moved check  on optimization to call site..

 I also checked that bootstrap and regression testing did not show any
 new failures.

 Is it OK for trunk?
>>>
>>> The  | SSA_OP_VUSE is still in there, the testcase is still executable,
>>> still doesn't end with newline, and I really think you should replace
>>>   lattice = XALLOCAVEC (unsigned int, n);
>>> with something like:
>>>   if (n >= 10)
>>> lattice = XNEWVEC (unsigned int, n);
>>>   else
>>> lattice = XALLOCAVEC (unsigned int, n);
>>> ...
>>>   if (n >= 10)
>>> XDELETE (lattice);
>>> or similar.
>>>
>>> Jakub


Re: [Patch, Fortran, F03] PR 58023: ICE on invalid with bad PPC declaration

2015-01-15 Thread Dominique Dhumieres
Hi Janus,

Your patch at https://gcc.gnu.org/ml/fortran/2015-01/txtThsA1zTNFd.txt
looks very similar to the Mikael's one for pr58023 at
https://gcc.gnu.org/bugzilla/attachment.cgi?id=30633
with retval replaved with success.

Was it intended?

Cheers,

Dominique


[PATCH] Workaround -Wmaybe-uninitialized false positives during profiledbootstrap

2015-01-15 Thread Jakub Jelinek
Hi!

I ran into -Werror=maybe-uninitialized errors during profiledbootstrap
(../configure --enable-languages=c,c++ --enable-checking=release;
make -j16 profiledboostrap) before I hit a miscompilation I'm going to file.

Is this ok for trunk, or do we want to work around them differently?

2015-01-14  Jakub Jelinek  

* gengtype.c (create_user_defined_type): Workaround
-Wmaybe-uninitialized false positives.
* cse.c (fold_rtx): Likewise.
* loop-invariant.c (gain_for_invariant): Likewise.

--- gcc/gengtype.c.jj   2015-01-14 17:46:50.0 +0100
+++ gcc/gengtype.c  2015-01-14 18:15:19.285494736 +0100
@@ -611,7 +611,7 @@ create_user_defined_type (const char *ty
 comma-separated list of strings, implicitly assumed to
 be type names, potentially with "*" characters.  */
   char *arg = open_bracket + 1;
-  char *next;
+  char *next = NULL;
   char *type_id = strtoken (arg, ",>", &next);
   pair_p fields = 0;
   while (type_id)
--- gcc/cse.c.jj2015-01-14 17:49:01.0 +0100
+++ gcc/cse.c   2015-01-14 19:02:40.638325329 +0100
@@ -3093,8 +3093,8 @@ fold_rtx (rtx x, rtx_insn *insn)
   int changed = 0;
 
   /* Operands of X.  */
-  rtx folded_arg0;
-  rtx folded_arg1;
+  rtx folded_arg0 = NULL_RTX;
+  rtx folded_arg1 = NULL_RTX;
 
   /* Constant equivalents of first three operands of X;
  0 when no such equivalent is known.  */
--- gcc/loop-invariant.c.jj 2015-01-14 17:50:10.0 +0100
+++ gcc/loop-invariant.c2015-01-14 21:13:23.780857707 +0100
@@ -1268,7 +1268,7 @@ gain_for_invariant (struct invariant *in
bool speed, bool call_p)
 {
   int comp_cost, size_cost;
-  enum reg_class cl;
+  enum reg_class cl = NO_REGS;
   int ret;
 
   actual_stamp++;

Jakub


Re: [PATCH] Workaround -Wmaybe-uninitialized false positives during profiledbootstrap

2015-01-15 Thread Richard Biener
On Thu, Jan 15, 2015 at 12:10 PM, Jakub Jelinek  wrote:
> Hi!
>
> I ran into -Werror=maybe-uninitialized errors during profiledbootstrap
> (../configure --enable-languages=c,c++ --enable-checking=release;
> make -j16 profiledboostrap) before I hit a miscompilation I'm going to file.
>
> Is this ok for trunk, or do we want to work around them differently?

I wonder if we can arrange profiledbootstrap to use --disable-werror
unless --enable-werror is specified explicitely...  Similarly useful
if we could do a similar thing from non-standard build-configs...

I also wonder if we shouldn't simply fix the uninit pass ...

Richard.

> 2015-01-14  Jakub Jelinek  
>
> * gengtype.c (create_user_defined_type): Workaround
> -Wmaybe-uninitialized false positives.
> * cse.c (fold_rtx): Likewise.
> * loop-invariant.c (gain_for_invariant): Likewise.
>
> --- gcc/gengtype.c.jj   2015-01-14 17:46:50.0 +0100
> +++ gcc/gengtype.c  2015-01-14 18:15:19.285494736 +0100
> @@ -611,7 +611,7 @@ create_user_defined_type (const char *ty
>  comma-separated list of strings, implicitly assumed to
>  be type names, potentially with "*" characters.  */
>char *arg = open_bracket + 1;
> -  char *next;
> +  char *next = NULL;
>char *type_id = strtoken (arg, ",>", &next);
>pair_p fields = 0;
>while (type_id)
> --- gcc/cse.c.jj2015-01-14 17:49:01.0 +0100
> +++ gcc/cse.c   2015-01-14 19:02:40.638325329 +0100
> @@ -3093,8 +3093,8 @@ fold_rtx (rtx x, rtx_insn *insn)
>int changed = 0;
>
>/* Operands of X.  */
> -  rtx folded_arg0;
> -  rtx folded_arg1;
> +  rtx folded_arg0 = NULL_RTX;
> +  rtx folded_arg1 = NULL_RTX;
>
>/* Constant equivalents of first three operands of X;
>   0 when no such equivalent is known.  */
> --- gcc/loop-invariant.c.jj 2015-01-14 17:50:10.0 +0100
> +++ gcc/loop-invariant.c2015-01-14 21:13:23.780857707 +0100
> @@ -1268,7 +1268,7 @@ gain_for_invariant (struct invariant *in
> bool speed, bool call_p)
>  {
>int comp_cost, size_cost;
> -  enum reg_class cl;
> +  enum reg_class cl = NO_REGS;
>int ret;
>
>actual_stamp++;
>
> Jakub


[PATCH] Avoid -Werror=format-security errors in libcpp

2015-01-15 Thread Jakub Jelinek
Hi!

With the addition of build libcpp, my build failed because of distro default
flags of -Werror=format-security.

The first hunk is I think no big deal, making it const makes the warning
go away.

The second hunk is more controversial, as even making message const doesn't
help with the warning.  There is another option of using "%s" and
_( instead of N_ in message, or just keep it as is and I can keep the second
hunk as local hack.

Thoughts on this?

2015-01-15  Jakub Jelinek  

* macro.c (create_iso_definition): Make paste_op_error_msg var
const.
* expr.c (cpp_classify_number): Avoid -Wformat-security warning.

--- libcpp/macro.c.jj   2015-01-14 11:01:34.0 +0100
+++ libcpp/macro.c  2015-01-14 14:22:19.286949884 +0100
@@ -2947,7 +2947,7 @@ create_iso_definition (cpp_reader *pfile
   cpp_token *token;
   const cpp_token *ctoken;
   bool following_paste_op = false;
-  const char *paste_op_error_msg =
+  const char *const paste_op_error_msg =
 N_("'##' cannot appear at either end of a macro expansion");
   unsigned int num_extra_tokens = 0;
 
--- libcpp/expr.c.jj2015-01-14 11:01:34.0 +0100
+++ libcpp/expr.c   2015-01-14 14:35:52.851002344 +0100
@@ -672,16 +672,17 @@ cpp_classify_number (cpp_reader *pfile,
   if ((result & CPP_N_WIDTH) == CPP_N_LARGE
  && CPP_OPTION (pfile, cpp_warn_long_long))
 {
-  const char *message = CPP_OPTION (pfile, cplusplus) 
-   ? N_("use of C++11 long long integer constant")
-   : N_("use of C99 long long integer constant");
-
  if (CPP_OPTION (pfile, c99))
 cpp_warning_with_line (pfile, CPP_W_LONG_LONG, virtual_location,
-  0, message);
+  0, CPP_OPTION (pfile, cplusplus)
+ ? "use of C++11 long long integer 
constant"
+ : "use of C99 long long integer 
constant");
   else
 cpp_pedwarning_with_line (pfile, CPP_W_LONG_LONG,
- virtual_location, 0, message);
+ virtual_location, 0,
+ CPP_OPTION (pfile, cplusplus)
+ ? "use of C++11 long long integer 
constant"
+ : "use of C99 long long integer 
constant");
 }
 
   result |= CPP_N_INTEGER;


Jakub


RE: [PATCH] Allow MIPS call-saved-{4-6}.c tests to correctly run for micromips

2015-01-15 Thread Matthew Fortune
 
> I have tested this for both mips and micromips, and the tests now pass
> successfully.
> The ChangeLog and patch are below.
> 
> Ok to commit?

Since you had not got to committing this yet. I have added the micromips
variants of the tests and committed your patch for you. Thanks for
finding the failures.

Thanks,
Matthew

gcc/testsuite/

* gcc.target/mips/call-saved-4.c (foo): Add NOCOMPRESSION.
* gcc.target/mips/call-saved-5.c (foo): Likewise.
* gcc.target/mips/call-saved-6.c (foo): Likewise.
* gcc.target/mips/call-saved-7.c: New file.
* gcc.target/mips/call-saved-8.c: New file.
* gcc.target/mips/call-saved-9.c: New file.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219640 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/testsuite/ChangeLog  | 10 ++
 gcc/testsuite/gcc.target/mips/call-saved-4.c |  2 +-
 gcc/testsuite/gcc.target/mips/call-saved-5.c |  2 +-
 gcc/testsuite/gcc.target/mips/call-saved-6.c |  2 +-
 gcc/testsuite/gcc.target/mips/call-saved-7.c | 25 +
 gcc/testsuite/gcc.target/mips/call-saved-8.c | 25 +
 gcc/testsuite/gcc.target/mips/call-saved-9.c | 25 +
 7 files changed, 88 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/mips/call-saved-7.c
 create mode 100644 gcc/testsuite/gcc.target/mips/call-saved-8.c
 create mode 100644 gcc/testsuite/gcc.target/mips/call-saved-9.c

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 6b73d31..1285633 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,13 @@
+2015-01-15  Andrew Bennett  
+   Matthew Fortune  
+
+   * gcc.target/mips/call-saved-4.c (foo): Add NOCOMPRESSION.
+   * gcc.target/mips/call-saved-5.c (foo): Likewise.
+   * gcc.target/mips/call-saved-6.c (foo): Likewise.
+   * gcc.target/mips/call-saved-7.c: New file.
+   * gcc.target/mips/call-saved-8.c: New file.
+   * gcc.target/mips/call-saved-9.c: New file.
+
 2015-01-14  Matthew Fortune  
 
* gcc.target/mips/lsa.c: New file.
diff --git a/gcc/testsuite/gcc.target/mips/call-saved-4.c 
b/gcc/testsuite/gcc.target/mips/call-saved-4.c
index 846ea32..92881c4 100644
--- a/gcc/testsuite/gcc.target/mips/call-saved-4.c
+++ b/gcc/testsuite/gcc.target/mips/call-saved-4.c
@@ -3,7 +3,7 @@
 
 void bar (void);
 
-void
+NOCOMPRESSION void
 foo (int x)
 {
   __builtin_unwind_init ();
diff --git a/gcc/testsuite/gcc.target/mips/call-saved-5.c 
b/gcc/testsuite/gcc.target/mips/call-saved-5.c
index 2937b31..152b28f 100644
--- a/gcc/testsuite/gcc.target/mips/call-saved-5.c
+++ b/gcc/testsuite/gcc.target/mips/call-saved-5.c
@@ -3,7 +3,7 @@
 
 void bar (void);
 
-void
+NOCOMPRESSION void
 foo (int x)
 {
   __builtin_unwind_init ();
diff --git a/gcc/testsuite/gcc.target/mips/call-saved-6.c 
b/gcc/testsuite/gcc.target/mips/call-saved-6.c
index 0d1a4c8..a384d4a 100644
--- a/gcc/testsuite/gcc.target/mips/call-saved-6.c
+++ b/gcc/testsuite/gcc.target/mips/call-saved-6.c
@@ -3,7 +3,7 @@
 
 void bar (void);
 
-void
+NOCOMPRESSION void
 foo (int x)
 {
   __builtin_unwind_init ();
diff --git a/gcc/testsuite/gcc.target/mips/call-saved-7.c 
b/gcc/testsuite/gcc.target/mips/call-saved-7.c
new file mode 100644
index 000..2ebc2f1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/call-saved-7.c
@@ -0,0 +1,25 @@
+/* Check that we save the correct call-saved GPRs and FPRs.  */
+/* { dg-options "(HAS_LDC) -mmicromips -mabi=32 -mfp32" } */
+
+void bar (void);
+
+void
+foo (int x)
+{
+  __builtin_unwind_init ();
+  __builtin_eh_return (x, bar);
+}
+/* { dg-final { scan-assembler "\\\$16-\\\$23" } } */
+/* { dg-final { scan-assembler "\\\$(30|fp)" } } */
+/* { dg-final { scan-assembler "\\\$f20" } } */
+/* { dg-final { scan-assembler "\\\$f22" } } */
+/* { dg-final { scan-assembler "\\\$f24" } } */
+/* { dg-final { scan-assembler "\\\$f26" } } */
+/* { dg-final { scan-assembler "\\\$f28" } } */
+/* { dg-final { scan-assembler "\\\$f30" } } */
+/* { dg-final { scan-assembler-not "\\\$f21" } } */
+/* { dg-final { scan-assembler-not "\\\$f23" } } */
+/* { dg-final { scan-assembler-not "\\\$f25" } } */
+/* { dg-final { scan-assembler-not "\\\$f27" } } */
+/* { dg-final { scan-assembler-not "\\\$f29" } } */
+/* { dg-final { scan-assembler-not "\\\$f31" } } */
diff --git a/gcc/testsuite/gcc.target/mips/call-saved-8.c 
b/gcc/testsuite/gcc.target/mips/call-saved-8.c
new file mode 100644
index 000..4e8f8d7
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/call-saved-8.c
@@ -0,0 +1,25 @@
+/* Check that we save the correct call-saved GPRs and FPRs.  */
+/* { dg-options "-mmicromips -mabi=32 -mfpxx" } */
+
+void bar (void);
+
+void
+foo (int x)
+{
+  __builtin_unwind_init ();
+  __builtin_eh_return (x, bar);
+}
+/* { dg-final { scan-assembler "\\\$16-\\\$23" } } */
+/* { dg-final { scan-assembler "\\\$(30|fp)" } } */
+/* { dg-final { scan-assembler "\\\$f20" } } */
+/* { dg-final { scan-a

[PATCH,committed] Ensure options incompatible with micromips imply -mno-micromips

2015-01-15 Thread Matthew Fortune
A bit of housekeeping in mips.exp. Several test options are incompatible
with micromips so this patch enforces no-micromips as required.

The number of failures in mips.exp for -mmicromips is now much lower and
primarily related to branch distance differences vs MIPS.

Thanks,
Matthew

gcc/testsuite/

* gcc.target/mips/mips.exp (mips-dg-options): -mips3d requires
-mno-micromips.  MIPS32R1 and below require -mno-micromips.
-march=loongson* and -march=octeon* require -mno-micromips.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219641 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/testsuite/ChangeLog| 6 ++
 gcc/testsuite/gcc.target/mips/mips.exp | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 1285633..842ebf4 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2015-01-15  Matthew Fortune  
+
+   * gcc.target/mips/mips.exp (mips-dg-options): -mips3d requires
+   -mno-micromips.  MIPS32R1 and below require -mno-micromips.
+   -march=loongson* and -march=octeon* require -mno-micromips.
+
 2015-01-15  Andrew Bennett  
Matthew Fortune  
 
diff --git a/gcc/testsuite/gcc.target/mips/mips.exp 
b/gcc/testsuite/gcc.target/mips/mips.exp
index 3d6da81..b81d344 100644
--- a/gcc/testsuite/gcc.target/mips/mips.exp
+++ b/gcc/testsuite/gcc.target/mips/mips.exp
@@ -955,6 +955,7 @@ proc mips-dg-options { args } {
 mips_option_dependency options "-mips16" "-mno-micromips"
 mips_option_dependency options "-mmicromips" "-mno-mips16"
 mips_option_dependency options "-mips3d" "-mpaired-single"
+mips_option_dependency options "-mips3d" "-mno-micromips"
 mips_option_dependency options "-mpaired-single" "-mfp64"
 mips_option_dependency options "-mfp64" "-mhard-float"
 mips_option_dependency options "-mfp32" "-mhard-float"
@@ -1298,6 +1299,7 @@ proc mips-dg-options { args } {
}
mips_make_test_option options "-mno-dsp"
mips_make_test_option options "-mno-synci"
+   mips_make_test_option options "-mno-micromips"
}
 if { $isa_rev > 5 } {
mips_make_test_option options "-mno-dsp"
@@ -1310,6 +1312,10 @@ proc mips-dg-options { args } {
mips_make_test_option options "-mnan=2008"
mips_make_test_option options "-mabs=2008"
}
+   if { [regexp {^-march=(octeon|loongson)} $arch] } {
+   mips_make_test_option options "-mno-micromips"
+   }
+
unset arch
unset isa
unset isa_rev
-- 
2.2.1



Re: [PATCH] Workaround -Wmaybe-uninitialized false positives during profiledbootstrap

2015-01-15 Thread Jakub Jelinek
On Thu, Jan 15, 2015 at 12:17:44PM +0100, Richard Biener wrote:
> On Thu, Jan 15, 2015 at 12:10 PM, Jakub Jelinek  wrote:
> > Hi!
> >
> > I ran into -Werror=maybe-uninitialized errors during profiledbootstrap
> > (../configure --enable-languages=c,c++ --enable-checking=release;
> > make -j16 profiledboostrap) before I hit a miscompilation I'm going to file.
> >
> > Is this ok for trunk, or do we want to work around them differently?
> 
> I wonder if we can arrange profiledbootstrap to use --disable-werror
> unless --enable-werror is specified explicitely...  Similarly useful
> if we could do a similar thing from non-standard build-configs...

For non-standard ones I'm ok, but I've always hoped that profiledbootstrap
is considered standard.  It certainly worked fine with -Werror at least
for us in gcc 4.[4-9].

> I also wonder if we shouldn't simply fix the uninit pass ...

If it is possible, sure, but it isn't always the case.

We could also just use type var = var; if that is the way to avoid
the warnings and not generate extra code.

Jakub


Re: [PATCH] Workaround -Wmaybe-uninitialized false positives during profiledbootstrap

2015-01-15 Thread Richard Biener
On Thu, Jan 15, 2015 at 12:29 PM, Jakub Jelinek  wrote:
> On Thu, Jan 15, 2015 at 12:17:44PM +0100, Richard Biener wrote:
>> On Thu, Jan 15, 2015 at 12:10 PM, Jakub Jelinek  wrote:
>> > Hi!
>> >
>> > I ran into -Werror=maybe-uninitialized errors during profiledbootstrap
>> > (../configure --enable-languages=c,c++ --enable-checking=release;
>> > make -j16 profiledboostrap) before I hit a miscompilation I'm going to 
>> > file.
>> >
>> > Is this ok for trunk, or do we want to work around them differently?
>>
>> I wonder if we can arrange profiledbootstrap to use --disable-werror
>> unless --enable-werror is specified explicitely...  Similarly useful
>> if we could do a similar thing from non-standard build-configs...
>
> For non-standard ones I'm ok, but I've always hoped that profiledbootstrap
> is considered standard.  It certainly worked fine with -Werror at least
> for us in gcc 4.[4-9].

Indeed it did (with release checking at least).

>> I also wonder if we shouldn't simply fix the uninit pass ...
>
> If it is possible, sure, but it isn't always the case.
>
> We could also just use type var = var; if that is the way to avoid
> the warnings and not generate extra code.

Is that portable though?  (legal C, not subject to other compilers
that it might be "hineous"...)

Anyway, I guess the patch is ok if you add a comment after the inits
/* initialize to avoid warnings with profiledbootstrap */
or similar.  Otherwise people might be tempted to remove the
init again (or wonder why it is there) as it works in regular bootstrap.

Thanks,
Richard.


> Jakub


Re: [Patch, Fortran, F03] PR 58023: ICE on invalid with bad PPC declaration

2015-01-15 Thread Janus Weil
> Your patch at https://gcc.gnu.org/ml/fortran/2015-01/txtThsA1zTNFd.txt
> looks very similar to the Mikael's one for pr58023 at
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=30633
> with retval replaved with success.
>
> Was it intended?

Nope. I wasn't even aware of that patch. To which PR is it attached
(not 58023 apparently)?

Cheers,
Janus


[PATCH] Fix darwin FAIL of gcc.dg/lto/pr64415_0.c

2015-01-15 Thread Richard Biener

Committed.

Richard.

2015-01-15  Richard Biener  

PR lto/64415
* gcc.dg/lto/pr64415_0.c: Skip on darwin.

Index: gcc/testsuite/gcc.dg/lto/pr64415_0.c
===
--- gcc/testsuite/gcc.dg/lto/pr64415_0.c(revision 219635)
+++ gcc/testsuite/gcc.dg/lto/pr64415_0.c(working copy)
@@ -1,4 +1,5 @@
 /* { dg-lto-do link } */
+/* { dg-skip-if "undefined symbols" { *-*-darwin* } } */
 /* { dg-require-effective-target fpic } */
 /* { dg-lto-options { { -O -flto -fpic } } } */
 /* { dg-extra-ld-options { -shared } } */


[PATCH, CHKP, PR64363] Don't instrument functions we cannot copy

2015-01-15 Thread Ilya Enkovich
Hi,

This patch is to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64363.  Patch 
disables instrumentation for functions we cannot clone correctly due to labels.

Bootstrapped and checked on x86_64-unknown-linux-gnu.  OK for trunk?

Thanks,
Ilya
--
gcc/

2015-01-14  Ilya Enkovich  

PR target/64363
* ipa-chkp.h (chkp_instrumentable_p): New.
* ipa-chkp.c: Include tree-inline.h.
(chkp_instrumentable_p): New.
(chkp_maybe_create_clone): Use chkp_instrumentable_p.
Fix processing of not instrumentable functions.
(chkp_versioning): Use chkp_instrumentable_p. Warn about
not instrumentable functions.
* tree-chkp.c (chkp_add_bounds_to_call_stmt): Use
chkp_instrumentable_p.
* tree-inline.h (copy_forbidden): New.
* tree-inline.c (copy_forbidden): Not static anymore.

gcc/testsuite/

2015-01-14  Ilya Enkovich  

PR target/64363
* gcc.target/i386/chkp-label-address.c: New.


diff --git a/gcc/ipa-chkp.c b/gcc/ipa-chkp.c
index 30d511d..4fb60f0 100644
--- a/gcc/ipa-chkp.c
+++ b/gcc/ipa-chkp.c
@@ -50,6 +50,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "lto-streamer.h"
 #include "cgraph.h"
 #include "tree-chkp.h"
+#include "tree-inline.h"
 #include "ipa-chkp.h"
 
 /*  Pointer Bounds Checker has two IPA passes to support code instrumentation.
@@ -401,6 +402,18 @@ chkp_maybe_clone_builtin_fndecl (tree fndecl)
   return clone;
 }
 
+/* Return 1 if function FNDECL should be instrumented.  */
+
+bool
+chkp_instrumentable_p (tree fndecl)
+{
+  struct function *fn = DECL_STRUCT_FUNCTION (fndecl);
+  return (!lookup_attribute ("bnd_legacy", DECL_ATTRIBUTES (fndecl))
+ && (!flag_chkp_instrument_marked_only
+ || lookup_attribute ("bnd_instrument", DECL_ATTRIBUTES (fndecl)))
+ && (!fn || !copy_forbidden (fn, fndecl)));
+}
+
 /* Return clone created for instrumentation of NODE or NULL.  */
 
 cgraph_node *
@@ -483,10 +496,10 @@ chkp_maybe_create_clone (tree fndecl)
{
  /* If function will not be instrumented, then it's instrumented
 version is a thunk for the original.  */
- if (lookup_attribute ("bnd_legacy", DECL_ATTRIBUTES (fndecl))
- || (flag_chkp_instrument_marked_only
- && !lookup_attribute ("bnd_instrument", DECL_ATTRIBUTES 
(fndecl
+ if (!chkp_instrumentable_p (fndecl))
{
+ clone->remove_callees ();
+ clone->remove_all_references ();
  clone->thunk.thunk_p = true;
  clone->thunk.add_pointer_bounds_args = true;
  clone->create_edge (node, NULL, 0, CGRAPH_FREQ_BASE);
@@ -532,7 +545,8 @@ chkp_maybe_create_clone (tree fndecl)
 
   /* Clone all thunks.  */
   for (e = node->callers; e; e = e->next_caller)
-   if (e->caller->thunk.thunk_p)
+   if (e->caller->thunk.thunk_p
+   && !e->caller->thunk.add_pointer_bounds_args)
  {
struct cgraph_node *thunk
  = chkp_maybe_create_clone (e->caller->decl);
@@ -578,6 +592,7 @@ static unsigned int
 chkp_versioning (void)
 {
   struct cgraph_node *node;
+  const char *reason;
 
   bitmap_obstack_initialize (NULL);
 
@@ -587,14 +602,20 @@ chkp_versioning (void)
  && !node->instrumented_version
  && !node->alias
  && !node->thunk.thunk_p
- && !lookup_attribute ("bnd_legacy", DECL_ATTRIBUTES (node->decl))
- && (!flag_chkp_instrument_marked_only
- || lookup_attribute ("bnd_instrument",
-  DECL_ATTRIBUTES (node->decl)))
  && (!DECL_BUILT_IN (node->decl)
  || (DECL_BUILT_IN_CLASS (node->decl) == BUILT_IN_NORMAL
  && DECL_FUNCTION_CODE (node->decl) < BEGIN_CHKP_BUILTINS)))
-   chkp_maybe_create_clone (node->decl);
+   {
+ if (chkp_instrumentable_p (node->decl))
+   chkp_maybe_create_clone (node->decl);
+ else if ((reason = copy_forbidden (DECL_STRUCT_FUNCTION (node->decl),
+node->decl)))
+   {
+ std::string msg = "function cannot be instrumented: ";
+ msg += reason;
+ warning (OPT_Wchkp, msg.c_str (), node->decl);
+   }
+   }
 }
 
   /* Mark all aliases and thunks of functions with no instrumented
diff --git a/gcc/ipa-chkp.h b/gcc/ipa-chkp.h
index b087227..6708fe9 100644
--- a/gcc/ipa-chkp.h
+++ b/gcc/ipa-chkp.h
@@ -23,5 +23,6 @@ along with GCC; see the file COPYING3.  If not see
 extern tree chkp_copy_function_type_adding_bounds (tree orig_type);
 extern tree chkp_maybe_clone_builtin_fndecl (tree fndecl);
 extern cgraph_node *chkp_maybe_create_clone (tree fndecl);
+extern bool chkp_instrumentable_p (tree fndecl);
 
 #endif /* GCC_IPA_CHKP_H */
diff --git a/gcc/testsuite/gcc.target/i386/chkp-label-address.c 
b/gcc/testsuite/gcc.target/i386/chkp-label-address.c
new file mode 100644
index 0

[PATCH] Fix PR61743

2015-01-15 Thread Richard Biener

I am testing the following hack^Wpatch which makes us preserve
range information in some very special case in PRE.  This is
important to get number of iteration analysis results in a way
to enable unrolling of loops in some EEMBC testcase (I don't
have access to that benchmark unless it is part of coremark).

I'm not 100% happy about that special-casing (and in future
we might consider moving core range operation from VRP to
somewhere publically accessible to compute the cast of the
range properly also for truncations and negative ranges).

Bootstrap and regtest in progress on x86_64-unknown-linux-gnu.

Tell me if you think this is too much of a hack and exporting
extract_range_from_unary_expr_1 from tree-vrp.c and using that
would be less of that (I'd rather move things elsewhere to
make sure the exported routines are isolated well enough from
VRP internals).

Thanks,
Richard.

2015-01-15  Richard Biener  

PR tree-optimization/61743
* tree-ssa-pre.c (insert_into_preds_of_block): Preserve range
information on PHIs for some simple cases.

* gcc.dg/tree-ssa/pr61743-1.c: New testcase.
* gcc.dg/tree-ssa/pr61743-2.c: Likewise.

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 219646)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -3173,6 +3172,33 @@ insert_into_preds_of_block (basic_block
   bitmap_insert_into_set (NEW_SETS (block),
  newphi);
 
+  /* If we insert a PHI node for a conversion of another PHI node
+ in the same basic-block try to preserve range information.
+ This is important so that followup loop passes receive optimal
+ number of iteration analysis results.  See PR61743.  */
+  if (expr->kind == NARY
+  && CONVERT_EXPR_CODE_P (expr->u.nary->opcode)
+  && TREE_CODE (expr->u.nary->op[0]) == SSA_NAME
+  && gimple_bb (SSA_NAME_DEF_STMT (expr->u.nary->op[0])) == block
+  && INTEGRAL_TYPE_P (type)
+  && INTEGRAL_TYPE_P (TREE_TYPE (expr->u.nary->op[0]))
+  && (TYPE_PRECISION (type)
+ >= TYPE_PRECISION (TREE_TYPE (expr->u.nary->op[0])))
+  && SSA_NAME_RANGE_INFO (expr->u.nary->op[0]))
+{
+  wide_int min, max;
+  if (get_range_info (expr->u.nary->op[0], &min, &max) == VR_RANGE
+ && !wi::neg_p (min, SIGNED)
+ && !wi::neg_p (max, SIGNED))
+   /* Just handle extension and sign-changes of all-positive ranges.  */
+   set_range_info (temp,
+   SSA_NAME_RANGE_TYPE (expr->u.nary->op[0]),
+   wide_int_storage::from (min, TYPE_PRECISION (type),
+   TYPE_SIGN (type)),
+   wide_int_storage::from (max, TYPE_PRECISION (type),
+   TYPE_SIGN (type)));
+}
+
   if (dump_file && (dump_flags & TDF_DETAILS))
 {
   fprintf (dump_file, "Created phi ");
Index: gcc/testsuite/gcc.dg/tree-ssa/pr61743-2.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr61743-2.c   (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr61743-2.c   (working copy)
@@ -0,0 +1,53 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -funroll-loops -fdump-tree-cunroll-details" } */
+
+#define N 8
+#define M 14
+typedef unsigned char e_u8;
+e_u8 x[256];
+#define MAX(a,b) ((a)>=(b)?(a):(b))
+#define btype e_u8
+
+static inline void bar1(e_u8 a[4][N], e_u8 b[4][N], btype n)
+{
+  int i, j;
+
+  for(i = 0; i < 4; i++)
+for(j = 0; j < n; j++)
+  a[i][j] ^= b[i][j];
+}
+
+static inline void bar2(e_u8 a[4][N], e_u8 b[256], btype n)
+{
+  int i, j;
+
+  for(i = 0; i < 4; i++)
+for(j = 0; j < n; j++)
+  a[i][j] = b[a[i][j]] ;
+}
+
+int foo1 (e_u8 a[4][N], int b1, int b2, e_u8 b[M+1][4][N])
+{
+  btype n;
+  int r, m;
+
+  switch (b2) {
+case 128: n = 4; break;
+case 192: n = 6; break;
+case 256: n = 8; break;
+default : return (-2);
+  }
+  switch (MAX(b1,b2)) {
+case 128: m = 10; break;
+case 192: m = 12; break;
+case 256: m = 14; break;
+default : return (-3);
+  }
+  bar1(a,b[m],n);
+  bar2(a,x,n);
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-times "loop with 4 iterations completely 
unrolled" 2 "cunroll" } } */
+/* { dg-final { scan-tree-dump-times "loop with 8 iterations completely 
unrolled" 2 "cunroll" } } */
+/* { dg-final { cleanup-tree-dump "cunroll" } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/pr61743-1.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr61743-1.c   (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr61743-1.c   (working copy)
@@ -0,0 +1,53 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -funroll-loops -fdump-tree-cunroll-details" } */
+
+#define N 8
+#define M 14
+typedef unsigned char e_u8;
+e_u8 x[256];
+#define MAX(a,b) ((a)>=(b)?(a):(b))
+#define btype int
+
+static inline void bar1(e_u8 a[4][N], e_u8 b[

[PATCH, ARM, testsuite] Improve scd42-1.c for UAL

2015-01-15 Thread Tony Liu
Hi,

This is the patch to improve the test case gcc.target/arm/scd42-1.c for both
UAL and non-UAL. It now checks UAL format assembly code for Thumb1 and
Thumb2 while non-UAL format assembly code for ARM mode.

With this patch, the test passes for both cases.

Thanks,
Tony 

2015-01-15  Tony Liu  

   * gcc.target/arm/scd42-1.c: Improve the check for UAL and non-UAL
cases.diff --git a/gcc/testsuite/gcc.target/arm/scd42-1.c 
b/gcc/testsuite/gcc.target/arm/scd42-1.c
index f2bd629..420f7c4 100644
--- a/gcc/testsuite/gcc.target/arm/scd42-1.c
+++ b/gcc/testsuite/gcc.target/arm/scd42-1.c
@@ -13,4 +13,5 @@ unsigned load1(void)
 return 17;
 }
 
-/* { dg-final { scan-assembler "movs\[ ].*17" } } */
+/* { dg-final { scan-assembler "mov\[  ].*17" { target { arm_nothumb } } } } */
+/* { dg-final { scan-assembler "movs\[ ].*17" { target { ! arm_nothumb 
} } } } */


Re: [PATCH] Fix darwin FAIL of gcc.dg/lto/pr64415_0.c

2015-01-15 Thread Richard Biener
On Thu, 15 Jan 2015, Richard Biener wrote:

> 
> Committed.

Turns out we can do better.

Committed.

Richard.

2015-01-15  Richard Biener  

PR lto/64415
* gcc.dg/lto/pr64415_0.c: Re-enable for darwin with
-Wl,-undefined,dynamic_lookup.

Index: gcc/testsuite/gcc.dg/lto/pr64415_0.c
===
--- gcc/testsuite/gcc.dg/lto/pr64415_0.c(revision 219647)
+++ gcc/testsuite/gcc.dg/lto/pr64415_0.c(working copy)
@@ -1,8 +1,8 @@
 /* { dg-lto-do link } */
-/* { dg-skip-if "undefined symbols" { *-*-darwin* } } */
 /* { dg-require-effective-target fpic } */
 /* { dg-lto-options { { -O -flto -fpic } } } */
 /* { dg-extra-ld-options { -shared } } */
+/* { dg-extra-ld-options "-Wl,-undefined,dynamic_lookup" { target *-*-darwin* 
} } */
 
 extern void bar(char *, int);
 


PATCH: PR libitm/64360: libitm.c/stackundo.c fails with -fpic

2015-01-15 Thread H.J. Lu
Hi,

libitm.c/stackundo.c fails with -fpic since test1 and test2 may be
preempted with -fpic.  This patch makes those 2 functions static.
Tested on Linux/x86.  OK for trunk?

Thanks.


H.J.

diff --git a/libitm/ChangeLog b/libitm/ChangeLog
index 74e2940..e46819c 100644
--- a/libitm/ChangeLog
+++ b/libitm/ChangeLog
@@ -1,3 +1,9 @@
+2015-01-15  H.J. Lu  
+
+   PR libitm/64360
+   * libitm.c/stackundo.c (test2): Make it static.
+   (test1): Likewise.
+
 2015-01-05  Jakub Jelinek  
 
Update copyright years.
diff --git a/libitm/testsuite/libitm.c/stackundo.c 
b/libitm/testsuite/libitm.c/stackundo.c
index 02759d7..c7d585e 100644
--- a/libitm/testsuite/libitm.c/stackundo.c
+++ b/libitm/testsuite/libitm.c/stackundo.c
@@ -1,10 +1,10 @@
-int __attribute__((noinline)) test2(int x[1000])
+static int __attribute__((noinline)) test2(int x[1000])
 {
   int i;
   return x[12];
 }
 
-int __attribute__((noinline)) test1()
+static int __attribute__((noinline)) test1()
 {
   int x[1000], i;
 


Re: [Patch, Fortran, F03] PR 58023: ICE on invalid with bad PPC declaration

2015-01-15 Thread Dominique d'Humières

> Le 15 janv. 2015 à 12:37, Janus Weil  a écrit :
> 
>> Your patch at https://gcc.gnu.org/ml/fortran/2015-01/txtThsA1zTNFd.txt
>> looks very similar to the Mikael's one for pr58023 at
>> https://gcc.gnu.org/bugzilla/attachment.cgi?id=30633
>> with retval replaved with success.
>> 
>> Was it intended?
> 
> Nope. I wasn't even aware of that patch. To which PR is it attached
> (not 58023 apparently)?

Sorry, copy&paste from the wrong window. It is pr44978.

Dominique

> Cheers,
> Janus



Re: [testsuite] PATCH: Add -fno-pie to gcc.target/i386/pr54445-2.c

2015-01-15 Thread Uros Bizjak
On Mon, Jan 12, 2015 at 1:34 AM, H.J. Lu  wrote:
> Since PIE is also PIC, we need to add -fno-pie to avoid PIC.  OK for trunk?
>
> Thanks.
>
> H.J.
> ---
>  gcc/testsuite/gcc.target/i386/pr54445-2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> 2015-01-11  H.J. Lu  
>
> * gcc.target/i386/pr54445-2.c: Add -fno-pie.
>
> diff --git a/gcc/testsuite/gcc.target/i386/pr54445-2.c 
> b/gcc/testsuite/gcc.target/i386/pr54445-2.c
> index 5151c13..4d49816 100644
> --- a/gcc/testsuite/gcc.target/i386/pr54445-2.c
> +++ b/gcc/testsuite/gcc.target/i386/pr54445-2.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile { target { *-*-linux* && { ! { ia32 } } } } } */
> -/* { dg-options "-O2 -fno-pic" } */
> +/* { dg-options "-O2 -fno-pic -fno-pie" } */
>
>  __thread unsigned char tls_array[64];

No. PI *executable* has nothing to do with the access to data.

Can you rather investigate why -fpie is generating:

movzbl%fs:-1+tls_array@tpoff(%rdi), %eax

instead of (expected)

movzbl%fs:tls_array@tpoff-1(%rdi), %eax

Uros.


Re: libgo patch committed: Update to Go 1.4

2015-01-15 Thread Richard Biener
On Thu, Jan 15, 2015 at 1:28 AM, Ian Lance Taylor  wrote:
> I've committed a patch to libgo to update it to the Go 1.4 release,
> except for the runtime package.  Much of the runtime package was
> rewritten in Go, and it does not really affect users of the library,
> so I've postponed that complex merge.  All the other packages are
> updated.  A few minor compiler changes were required, as well as a few
> changes to the runtime packages required for other changes.  The
> testsuite script was changed to add support for the new TestMain
> function, which is used by one or two of the standard packages.
>
> As usual with libgo updates the entire patch is too large to attach
> here.  I've attached the changes to configuration/build files and the
> runtime package.
>
> Note that the type descriptor format has changed very very slightly to
> include an additional flag.  This means that all existing Go files
> must be recompiled in order to work with this updated libgo.  I will
> bump the libgo version number shortly.
>
> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
> Committed to mainline.

Looks like this broke s390x:

[ 5286s] libtool: compile:  /home/abuild/rpmbuild/BUILD/gcc-5.0.0-r219634/obj-s3
90x-suse-linux/./gcc/gccgo -B/home/abuild/rpmbuild/BUILD/gcc-5.0.0-r219634/obj-s
390x-suse-linux/./gcc/ -B/usr/s390x-suse-linux/bin/ -B/usr/s390x-suse-linux/lib/
 -isystem /usr/s390x-suse-linux/include -isystem /usr/s390x-suse-linux/sys-inclu
de -O2 -g -I . -c -fgo-pkgpath=reflect ../../../libgo/go/reflect/deepequal.go ..
/../../libgo/go/reflect/makefunc.go ../../../libgo/go/reflect/makefunc_ffi.go ..
/../../libgo/go/reflect/makefuncgo_s390x.go ../../../libgo/go/reflect/makefuncgo
_s390.go ../../../libgo/go/reflect/type.go ../../../libgo/go/reflect/value.go  -
fPIC -o .libs/reflect-go.o
[ 5286s] ../../../libgo/go/reflect/makefuncgo_s390x.go:323:5: error: expected ';
' or '}' or newline
[ 5286s]} else {
[ 5286s]  ^
[ 5286s] ../../../libgo/go/reflect/makefuncgo_s390x.go:336:2: error: expected '}
'
[ 5286s]   case s390x_mem_ptr:
[ 5286s]   ^
[ 5286s] ../../../libgo/go/reflect/makefuncgo_s390x.go:357:2: error: expected de
claration
[ 5286s]   return
[ 5286s]   ^

and more errors.

Richard.

> Ian
>
> gotools/ChangeLog:
>
> 2015-01-14  Ian Lance Taylor  
>
> * Makefile.am (go_cmd_go_files): Sort entries.  Add generate.go.
> * Makefile.in: Rebuild.


Re: [testsuite] PATCH: Add -fno-pie to gcc.target/i386/pr54445-2.c

2015-01-15 Thread H.J. Lu
On Thu, Jan 15, 2015 at 4:44 AM, Uros Bizjak  wrote:
> On Mon, Jan 12, 2015 at 1:34 AM, H.J. Lu  wrote:
>> Since PIE is also PIC, we need to add -fno-pie to avoid PIC.  OK for trunk?
>>
>> Thanks.
>>
>> H.J.
>> ---
>>  gcc/testsuite/gcc.target/i386/pr54445-2.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> 2015-01-11  H.J. Lu  
>>
>> * gcc.target/i386/pr54445-2.c: Add -fno-pie.
>>
>> diff --git a/gcc/testsuite/gcc.target/i386/pr54445-2.c 
>> b/gcc/testsuite/gcc.target/i386/pr54445-2.c
>> index 5151c13..4d49816 100644
>> --- a/gcc/testsuite/gcc.target/i386/pr54445-2.c
>> +++ b/gcc/testsuite/gcc.target/i386/pr54445-2.c
>> @@ -1,5 +1,5 @@
>>  /* { dg-do compile { target { *-*-linux* && { ! { ia32 } } } } } */
>> -/* { dg-options "-O2 -fno-pic" } */
>> +/* { dg-options "-O2 -fno-pic -fno-pie" } */
>>
>>  __thread unsigned char tls_array[64];
>
> No. PI *executable* has nothing to do with the access to data.
>
> Can you rather investigate why -fpie is generating:
>
> movzbl%fs:-1+tls_array@tpoff(%rdi), %eax
>
> instead of (expected)
>
> movzbl%fs:tls_array@tpoff-1(%rdi), %eax
>
> Uros.

They have the same encoding.  The differences are in the order of address
in the first operand due to different output orders of PLUS between
output_addr_const and output_pic_addr_const.

-- 
H.J.


Re: [testsuite] PATCH: Add -fno-pie to gcc.target/i386/pr54445-2.c

2015-01-15 Thread Uros Bizjak
On Thu, Jan 15, 2015 at 2:00 PM, H.J. Lu  wrote:

>>>  gcc/testsuite/gcc.target/i386/pr54445-2.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> 2015-01-11  H.J. Lu  
>>>
>>> * gcc.target/i386/pr54445-2.c: Add -fno-pie.
>>>
>>> diff --git a/gcc/testsuite/gcc.target/i386/pr54445-2.c 
>>> b/gcc/testsuite/gcc.target/i386/pr54445-2.c
>>> index 5151c13..4d49816 100644
>>> --- a/gcc/testsuite/gcc.target/i386/pr54445-2.c
>>> +++ b/gcc/testsuite/gcc.target/i386/pr54445-2.c
>>> @@ -1,5 +1,5 @@
>>>  /* { dg-do compile { target { *-*-linux* && { ! { ia32 } } } } } */
>>> -/* { dg-options "-O2 -fno-pic" } */
>>> +/* { dg-options "-O2 -fno-pic -fno-pie" } */
>>>
>>>  __thread unsigned char tls_array[64];
>>
>> No. PI *executable* has nothing to do with the access to data.
>>
>> Can you rather investigate why -fpie is generating:
>>
>> movzbl%fs:-1+tls_array@tpoff(%rdi), %eax
>>
>> instead of (expected)
>>
>> movzbl%fs:tls_array@tpoff-1(%rdi), %eax
>>
>> Uros.
>
> They have the same encoding.  The differences are in the order of address
> in the first operand due to different output orders of PLUS between
> output_addr_const and output_pic_addr_const.

Then we should improve scan string to accept both expressions.

Uros.


Re: [PATCH, CHKP, PR64363] Don't instrument functions we cannot copy

2015-01-15 Thread Richard Biener
On Thu, Jan 15, 2015 at 12:46 PM, Ilya Enkovich  wrote:
> Hi,
>
> This patch is to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64363.  
> Patch disables instrumentation for functions we cannot clone correctly due to 
> labels.
>
> Bootstrapped and checked on x86_64-unknown-linux-gnu.  OK for trunk?

  {
+ clone->remove_callees ();
+ clone->remove_all_references ();

this looks like a spurious change?

+ std::string msg = "function cannot be instrumented: ";
+ msg += reason;
+ warning (OPT_Wchkp, msg.c_str (), node->decl);

ick - please don't use std::string.  SImply do

 warning (OPT_Wchkp, "function cannot be instrumented: %s", node->decl, reason);

Otherwise ok.

Thanks,
Richard.

> Thanks,
> Ilya
> --
> gcc/
>
> 2015-01-14  Ilya Enkovich  
>
> PR target/64363
> * ipa-chkp.h (chkp_instrumentable_p): New.
> * ipa-chkp.c: Include tree-inline.h.
> (chkp_instrumentable_p): New.
> (chkp_maybe_create_clone): Use chkp_instrumentable_p.
> Fix processing of not instrumentable functions.
> (chkp_versioning): Use chkp_instrumentable_p. Warn about
> not instrumentable functions.
> * tree-chkp.c (chkp_add_bounds_to_call_stmt): Use
> chkp_instrumentable_p.
> * tree-inline.h (copy_forbidden): New.
> * tree-inline.c (copy_forbidden): Not static anymore.
>
> gcc/testsuite/
>
> 2015-01-14  Ilya Enkovich  
>
> PR target/64363
> * gcc.target/i386/chkp-label-address.c: New.
>
>
> diff --git a/gcc/ipa-chkp.c b/gcc/ipa-chkp.c
> index 30d511d..4fb60f0 100644
> --- a/gcc/ipa-chkp.c
> +++ b/gcc/ipa-chkp.c
> @@ -50,6 +50,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "lto-streamer.h"
>  #include "cgraph.h"
>  #include "tree-chkp.h"
> +#include "tree-inline.h"
>  #include "ipa-chkp.h"
>
>  /*  Pointer Bounds Checker has two IPA passes to support code 
> instrumentation.
> @@ -401,6 +402,18 @@ chkp_maybe_clone_builtin_fndecl (tree fndecl)
>return clone;
>  }
>
> +/* Return 1 if function FNDECL should be instrumented.  */
> +
> +bool
> +chkp_instrumentable_p (tree fndecl)
> +{
> +  struct function *fn = DECL_STRUCT_FUNCTION (fndecl);
> +  return (!lookup_attribute ("bnd_legacy", DECL_ATTRIBUTES (fndecl))
> + && (!flag_chkp_instrument_marked_only
> + || lookup_attribute ("bnd_instrument", DECL_ATTRIBUTES 
> (fndecl)))
> + && (!fn || !copy_forbidden (fn, fndecl)));
> +}
> +
>  /* Return clone created for instrumentation of NODE or NULL.  */
>
>  cgraph_node *
> @@ -483,10 +496,10 @@ chkp_maybe_create_clone (tree fndecl)
> {
>   /* If function will not be instrumented, then it's instrumented
>  version is a thunk for the original.  */
> - if (lookup_attribute ("bnd_legacy", DECL_ATTRIBUTES (fndecl))
> - || (flag_chkp_instrument_marked_only
> - && !lookup_attribute ("bnd_instrument", DECL_ATTRIBUTES 
> (fndecl
> + if (!chkp_instrumentable_p (fndecl))
> {
> + clone->remove_callees ();
> + clone->remove_all_references ();
>   clone->thunk.thunk_p = true;
>   clone->thunk.add_pointer_bounds_args = true;
>   clone->create_edge (node, NULL, 0, CGRAPH_FREQ_BASE);
> @@ -532,7 +545,8 @@ chkp_maybe_create_clone (tree fndecl)
>
>/* Clone all thunks.  */
>for (e = node->callers; e; e = e->next_caller)
> -   if (e->caller->thunk.thunk_p)
> +   if (e->caller->thunk.thunk_p
> +   && !e->caller->thunk.add_pointer_bounds_args)
>   {
> struct cgraph_node *thunk
>   = chkp_maybe_create_clone (e->caller->decl);
> @@ -578,6 +592,7 @@ static unsigned int
>  chkp_versioning (void)
>  {
>struct cgraph_node *node;
> +  const char *reason;
>
>bitmap_obstack_initialize (NULL);
>
> @@ -587,14 +602,20 @@ chkp_versioning (void)
>   && !node->instrumented_version
>   && !node->alias
>   && !node->thunk.thunk_p
> - && !lookup_attribute ("bnd_legacy", DECL_ATTRIBUTES (node->decl))
> - && (!flag_chkp_instrument_marked_only
> - || lookup_attribute ("bnd_instrument",
> -  DECL_ATTRIBUTES (node->decl)))
>   && (!DECL_BUILT_IN (node->decl)
>   || (DECL_BUILT_IN_CLASS (node->decl) == BUILT_IN_NORMAL
>   && DECL_FUNCTION_CODE (node->decl) < BEGIN_CHKP_BUILTINS)))
> -   chkp_maybe_create_clone (node->decl);
> +   {
> + if (chkp_instrumentable_p (node->decl))
> +   chkp_maybe_create_clone (node->decl);
> + else if ((reason = copy_forbidden (DECL_STRUCT_FUNCTION 
> (node->decl),
> +node->decl)))
> +   {
> + std::string msg = "function cannot be instrumented: ";
> + msg += reason;
> + warning (O

Re: [testsuite] PATCH: Add -fno-pie to gcc.target/i386/pr54445-2.c

2015-01-15 Thread H.J. Lu
On Thu, Jan 15, 2015 at 02:02:51PM +0100, Uros Bizjak wrote:
> On Thu, Jan 15, 2015 at 2:00 PM, H.J. Lu  wrote:
> 
> >>>  gcc/testsuite/gcc.target/i386/pr54445-2.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> 2015-01-11  H.J. Lu  
> >>>
> >>> * gcc.target/i386/pr54445-2.c: Add -fno-pie.
> >>>
> >>> diff --git a/gcc/testsuite/gcc.target/i386/pr54445-2.c 
> >>> b/gcc/testsuite/gcc.target/i386/pr54445-2.c
> >>> index 5151c13..4d49816 100644
> >>> --- a/gcc/testsuite/gcc.target/i386/pr54445-2.c
> >>> +++ b/gcc/testsuite/gcc.target/i386/pr54445-2.c
> >>> @@ -1,5 +1,5 @@
> >>>  /* { dg-do compile { target { *-*-linux* && { ! { ia32 } } } } } */
> >>> -/* { dg-options "-O2 -fno-pic" } */
> >>> +/* { dg-options "-O2 -fno-pic -fno-pie" } */
> >>>
> >>>  __thread unsigned char tls_array[64];
> >>
> >> No. PI *executable* has nothing to do with the access to data.
> >>
> >> Can you rather investigate why -fpie is generating:
> >>
> >> movzbl%fs:-1+tls_array@tpoff(%rdi), %eax
> >>
> >> instead of (expected)
> >>
> >> movzbl%fs:tls_array@tpoff-1(%rdi), %eax
> >>
> >> Uros.
> >
> > They have the same encoding.  The differences are in the order of address
> > in the first operand due to different output orders of PLUS between
> > output_addr_const and output_pic_addr_const.
> 
> Then we should improve scan string to accept both expressions.
> 

The order of address in the first operand is different due to different
output orders of PLUS between output_addr_const and output_pic_addr_const.
This patch adjusts scan string for PIE in gcc.target/i386/pr54445-2.c.
Tested on Linux/x86-64.  OK to install?

Thanks.


H.J.
---
* gcc.target/i386/pr54445-2.c: Adjust scan string for PIE.
---
 gcc/testsuite/gcc.target/i386/pr54445-2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/i386/pr54445-2.c 
b/gcc/testsuite/gcc.target/i386/pr54445-2.c
index 5151c13..f0ca9dc 100644
--- a/gcc/testsuite/gcc.target/i386/pr54445-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr54445-2.c
@@ -8,4 +8,4 @@ tls_array_lookup_with_negative_constant(long long int position) 
{
   return tls_array[position - 1];
 }
 
-/* { dg-final { scan-assembler "mov(b|zbl)\[ \t\](%fs:)?tls_array@tpoff-1\\(%" 
} } */
+/* { dg-final { scan-assembler "mov(b|zbl)\[ 
\t\](%fs:)?(-1\\+)?tls_array@tpoff(-1)?\\(%" } } */
-- 
1.9.3



Re: [testsuite] PATCH: Add -fno-pie to gcc.target/i386/pr54445-2.c

2015-01-15 Thread Uros Bizjak
On Thu, Jan 15, 2015 at 2:15 PM, H.J. Lu  wrote:

>> >>>  gcc/testsuite/gcc.target/i386/pr54445-2.c | 2 +-
>> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>>
>> >>> 2015-01-11  H.J. Lu  
>> >>>
>> >>> * gcc.target/i386/pr54445-2.c: Add -fno-pie.
>> >>>
>> >>> diff --git a/gcc/testsuite/gcc.target/i386/pr54445-2.c 
>> >>> b/gcc/testsuite/gcc.target/i386/pr54445-2.c
>> >>> index 5151c13..4d49816 100644
>> >>> --- a/gcc/testsuite/gcc.target/i386/pr54445-2.c
>> >>> +++ b/gcc/testsuite/gcc.target/i386/pr54445-2.c
>> >>> @@ -1,5 +1,5 @@
>> >>>  /* { dg-do compile { target { *-*-linux* && { ! { ia32 } } } } } */
>> >>> -/* { dg-options "-O2 -fno-pic" } */
>> >>> +/* { dg-options "-O2 -fno-pic -fno-pie" } */
>> >>>
>> >>>  __thread unsigned char tls_array[64];
>> >>
>> >> No. PI *executable* has nothing to do with the access to data.
>> >>
>> >> Can you rather investigate why -fpie is generating:
>> >>
>> >> movzbl%fs:-1+tls_array@tpoff(%rdi), %eax
>> >>
>> >> instead of (expected)
>> >>
>> >> movzbl%fs:tls_array@tpoff-1(%rdi), %eax
>> >>
>> >> Uros.
>> >
>> > They have the same encoding.  The differences are in the order of address
>> > in the first operand due to different output orders of PLUS between
>> > output_addr_const and output_pic_addr_const.
>>
>> Then we should improve scan string to accept both expressions.
>>
>
> The order of address in the first operand is different due to different
> output orders of PLUS between output_addr_const and output_pic_addr_const.
> This patch adjusts scan string for PIE in gcc.target/i386/pr54445-2.c.
> Tested on Linux/x86-64.  OK to install?
>
> Thanks.
>
>
> H.J.
> ---
> * gcc.target/i386/pr54445-2.c: Adjust scan string for PIE.

OK.

Thanks,
Uros.


Re: [Patch, Fortran, F03] PR 58023: ICE on invalid with bad PPC declaration

2015-01-15 Thread Mikael Morin
Le 14/01/2015 19:30, Janus Weil a écrit :
> Hi Mikael,
> 
>>> the attached patch fixes an ICE-on-invalid problem with
>>> procedure-pointer components by making sure that we continue resolving
>>> all components of a derived type, even after an error is thrown.
>>>
>> Does the fonction return false as before, whenever an error has been
>> issued?  I have the feeling it doesn't any more with the patch.
> 
> yeah, you're right. The attached new version fixes that. Better?
> 
Yes, OK. Thanks.

Mikael


Re: [Patch, Fortran, F03] PR 58023: ICE on invalid with bad PPC declaration

2015-01-15 Thread Mikael Morin
Le 15/01/2015 12:37, Janus Weil a écrit :
>> Your patch at https://gcc.gnu.org/ml/fortran/2015-01/txtThsA1zTNFd.txt
>> looks very similar to the Mikael's one for pr58023 at
>> https://gcc.gnu.org/bugzilla/attachment.cgi?id=30633
>> with retval replaved with success.
>>
>> Was it intended?
> 
> Nope. I wasn't even aware of that patch. To which PR is it attached
> (not 58023 apparently)?
> 

maybe that one:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44978


Re: [Patch, Fortran, F03] PR 58023: ICE on invalid with bad PPC declaration

2015-01-15 Thread Mikael Morin
Le 15/01/2015 14:25, Mikael Morin a écrit :
> Le 15/01/2015 12:37, Janus Weil a écrit :
>>> Your patch at https://gcc.gnu.org/ml/fortran/2015-01/txtThsA1zTNFd.txt
>>> looks very similar to the Mikael's one for pr58023 at
>>> https://gcc.gnu.org/bugzilla/attachment.cgi?id=30633
>>> with retval replaved with success.
>>>
>>> Was it intended?
>>
>> Nope. I wasn't even aware of that patch. To which PR is it attached
>> (not 58023 apparently)?
>>
> 
> maybe that one:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44978
> 
Sorry, I hadn't seen Dominique's answer.


Re: flatten expr.h (version 2)

2015-01-15 Thread Prathamesh Kulkarni
On 14 January 2015 at 12:14, Richard Biener  wrote:
> On Wed, 14 Jan 2015, Prathamesh Kulkarni wrote:
>
>> On 14 January 2015 at 17:31, Richard Biener  wrote:
>> > On Wed, 14 Jan 2015, Prathamesh Kulkarni wrote:
>> >
>> >> On 14 January 2015 at 11:16, Prathamesh Kulkarni
>> >>  wrote:
>> >> > On 14 January 2015 at 16:40, Prathamesh Kulkarni
>> >> >  wrote:
>> >> >> On 14 January 2015 at 14:34, Richard Biener  wrote:
>> >> >>> On Wed, 14 Jan 2015, Prathamesh Kulkarni wrote:
>> >> >>>
>> >>  On 13 January 2015 at 22:02, Prathamesh Kulkarni
>> >>   wrote:
>> >>  > On 13 January 2015 at 16:06, Prathamesh Kulkarni
>> >>  >  wrote:
>> >>  >> On 13 January 2015 at 15:34, Richard Biener  
>> >>  >> wrote:
>> >>  >>> On Sun, 11 Jan 2015, Prathamesh Kulkarni wrote:
>> >>  >>>
>> >>   Hi,
>> >>   This is a revamped expr.h flattening flattening patch rebased on
>> >>   tree.h and tree-core.h flattening patch (r219402).
>> >>   It depends upon the following patch to get committed.
>> >>   https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00565.html
>> >>  
>> >>   Changes:
>> >>   * Removed all includes except tree-core.h. Put includes 
>> >>   required by
>> >>   expr.h in a comment.
>> >>   * Moved stmt.c, expmed.c prototypes to stmt.h, expmed.h 
>> >>   respectively.
>> >>   * Adjusted generator programs: genemit.c, gengtype.c, 
>> >>   genopinit.c, genoutput.c.
>> >>   * Did not put includes in gcc-plugin.h since expr.h cannot be 
>> >>   included
>> >>   by plugins
>> >>   (putting them broke building a file in c-family/ since expr.h 
>> >>   is not
>> >>   allowed in front-ends)
>> >>   * Affects java front-end (expr.h is allowed in java front-end).
>> >>  
>> >>   Bootstrapped and tested on x86_64-unknown-linux-gnu with 
>> >>   languages:
>> >>   all,go,ada,jit
>> >>   Built on all targets in config-list.mk with languages: all, go.
>> >>   OK to commit ?
>> >>  >>>
>> >>  >>> diff --git a/gcc/expr.c b/gcc/expr.c
>> >>  >>> index fc22862..824541e 100644
>> >>  >>> --- a/gcc/expr.c
>> >>  >>> +++ b/gcc/expr.c
>> >>  >>> @@ -41,11 +41,17 @@ along with GCC; see the file COPYING3.  If 
>> >>  >>> not see
>> >>  >>>  #include "regs.h"
>> >>  >>>  #include "hard-reg-set.h"
>> >>  >>>  #include "except.h"
>> >>  >>> -#include "input.h"
>> >>  >>>  #include "function.h"
>> >>  >>>  #include "insn-config.h"
>> >>  >>>  #include "insn-attr.h"
>> >>  >>>  /* Include expr.h after insn-config.h so we get 
>> >>  >>> HAVE_conditional_move.
>> >>  >>> */
>> >>  >>> +#include "hashtab.h"
>> >>  >>> +#include "emit-rtl.h"
>> >>  >>> +#include "expmed.h"
>> >>  >>> +#include "stmt.h"
>> >>  >>> +#include "statistics.h"
>> >>  >>> +#include "real.h"
>> >>  >>> +#include "fixed-value.h"
>> >>  >>>  #include "expr.h"
>> >>  >>>
>> >>  >>> Please move the comment to the proper place
>> >>  >> ah, my flattening tool doesn't look at comments. I will move the
>> >>  >> comment before expr.h include, thanks.
>> >>  >>>
>> >>  >>> diff --git a/gcc/expr.h b/gcc/expr.h
>> >>  >>> index a7638b8..f1be8dc 100644
>> >>  >>> --- a/gcc/expr.h
>> >>  >>> +++ b/gcc/expr.h
>> >>  >>> @@ -20,7 +20,8 @@ along with GCC; see the file COPYING3.  If not 
>> >>  >>> see
>> >>  >>>  #ifndef GCC_EXPR_H
>> >>  >>>  #define GCC_EXPR_H
>> >>  >>>
>> >>  >>> -/* For inhibit_defer_pop */
>> >>  >>> +/* expr.h required includes */
>> >>  >>> +#if 0
>> >>  >>>  #include "hashtab.h"
>> >>  >>>  #include "hash-set.h"
>> >>  >>>  #include "vec.h"
>> >>  >>> @@ -29,15 +30,17 @@ along with GCC; see the file COPYING3.  If 
>> >>  >>> not see
>> >>  >>>  #include "hard-reg-set.h"
>> >>  >>>  #include "input.h"
>> >>  >>>  #include "function.h"
>> >>  >>> -/* For XEXP, GEN_INT, rtx_code */
>> >>  >>>  #include "rtl.h"
>> >>  >>> -/* For optimize_size */
>> >>  >>>  #include "flags.h"
>> >>  >>> -/* For tree_fits_[su]hwi_p, tree_to_[su]hwi, fold_convert, 
>> >>  >>> size_binop,
>> >>  >>> -   ssize_int, TREE_CODE, TYPE_SIZE, int_size_in_bytes,*/
>> >>  >>>  #include "tree-core.h"
>> >>  >>> -/* For GET_MODE_BITSIZE, word_mode */
>> >>  >>>  #include "insn-config.h"
>> >>  >>> +#include "alias.h"
>> >>  >>> +#include "emit-rtl.h"
>> >>  >>> +#include "expmed.h"
>> >>  >>> +#include "stmt.h"
>> >>  >>> +#endif
>> >>  >>>
>> >>  >>> Err, please remove the #if 0 section
>> >>  >> I kept it because if something breaks later (hopefully not!), it 
>> >>  >> will
>> >>  >> be easier to fix.
>> >>  >> I will remove it.
>> >>  >>>
>> >>  >>> +
>> >> 

Re: [PATCH, CHKP, PR64363] Don't instrument functions we cannot copy

2015-01-15 Thread Ilya Enkovich
2015-01-15 16:07 GMT+03:00 Richard Biener :
> On Thu, Jan 15, 2015 at 12:46 PM, Ilya Enkovich  
> wrote:
>> Hi,
>>
>> This patch is to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64363.  
>> Patch disables instrumentation for functions we cannot clone correctly due 
>> to labels.
>>
>> Bootstrapped and checked on x86_64-unknown-linux-gnu.  OK for trunk?
>
>   {
> + clone->remove_callees ();
> + clone->remove_all_references ();
>
> this looks like a spurious change?

Seems bogus thunk creation here wasn't triggered before but this test
revealed it in addition to labels issue.

>
> + std::string msg = "function cannot be instrumented: ";
> + msg += reason;
> + warning (OPT_Wchkp, msg.c_str (), node->decl);
>
> ick - please don't use std::string.  SImply do
>
>  warning (OPT_Wchkp, "function cannot be instrumented: %s", node->decl, 
> reason);

reason string has "%q+F" inside and therefore string concatenation is required.

Thanks,
Ilya

>
> Otherwise ok.
>
> Thanks,
> Richard.
>
>> Thanks,
>> Ilya
>> --
>> gcc/
>>
>> 2015-01-14  Ilya Enkovich  
>>
>> PR target/64363
>> * ipa-chkp.h (chkp_instrumentable_p): New.
>> * ipa-chkp.c: Include tree-inline.h.
>> (chkp_instrumentable_p): New.
>> (chkp_maybe_create_clone): Use chkp_instrumentable_p.
>> Fix processing of not instrumentable functions.
>> (chkp_versioning): Use chkp_instrumentable_p. Warn about
>> not instrumentable functions.
>> * tree-chkp.c (chkp_add_bounds_to_call_stmt): Use
>> chkp_instrumentable_p.
>> * tree-inline.h (copy_forbidden): New.
>> * tree-inline.c (copy_forbidden): Not static anymore.
>>
>> gcc/testsuite/
>>
>> 2015-01-14  Ilya Enkovich  
>>
>> PR target/64363
>> * gcc.target/i386/chkp-label-address.c: New.
>>
>>
>> diff --git a/gcc/ipa-chkp.c b/gcc/ipa-chkp.c
>> index 30d511d..4fb60f0 100644
>> --- a/gcc/ipa-chkp.c
>> +++ b/gcc/ipa-chkp.c
>> @@ -50,6 +50,7 @@ along with GCC; see the file COPYING3.  If not see
>>  #include "lto-streamer.h"
>>  #include "cgraph.h"
>>  #include "tree-chkp.h"
>> +#include "tree-inline.h"
>>  #include "ipa-chkp.h"
>>
>>  /*  Pointer Bounds Checker has two IPA passes to support code 
>> instrumentation.
>> @@ -401,6 +402,18 @@ chkp_maybe_clone_builtin_fndecl (tree fndecl)
>>return clone;
>>  }
>>
>> +/* Return 1 if function FNDECL should be instrumented.  */
>> +
>> +bool
>> +chkp_instrumentable_p (tree fndecl)
>> +{
>> +  struct function *fn = DECL_STRUCT_FUNCTION (fndecl);
>> +  return (!lookup_attribute ("bnd_legacy", DECL_ATTRIBUTES (fndecl))
>> + && (!flag_chkp_instrument_marked_only
>> + || lookup_attribute ("bnd_instrument", DECL_ATTRIBUTES 
>> (fndecl)))
>> + && (!fn || !copy_forbidden (fn, fndecl)));
>> +}
>> +
>>  /* Return clone created for instrumentation of NODE or NULL.  */
>>
>>  cgraph_node *
>> @@ -483,10 +496,10 @@ chkp_maybe_create_clone (tree fndecl)
>> {
>>   /* If function will not be instrumented, then it's instrumented
>>  version is a thunk for the original.  */
>> - if (lookup_attribute ("bnd_legacy", DECL_ATTRIBUTES (fndecl))
>> - || (flag_chkp_instrument_marked_only
>> - && !lookup_attribute ("bnd_instrument", DECL_ATTRIBUTES 
>> (fndecl
>> + if (!chkp_instrumentable_p (fndecl))
>> {
>> + clone->remove_callees ();
>> + clone->remove_all_references ();
>>   clone->thunk.thunk_p = true;
>>   clone->thunk.add_pointer_bounds_args = true;
>>   clone->create_edge (node, NULL, 0, CGRAPH_FREQ_BASE);
>> @@ -532,7 +545,8 @@ chkp_maybe_create_clone (tree fndecl)
>>
>>/* Clone all thunks.  */
>>for (e = node->callers; e; e = e->next_caller)
>> -   if (e->caller->thunk.thunk_p)
>> +   if (e->caller->thunk.thunk_p
>> +   && !e->caller->thunk.add_pointer_bounds_args)
>>   {
>> struct cgraph_node *thunk
>>   = chkp_maybe_create_clone (e->caller->decl);
>> @@ -578,6 +592,7 @@ static unsigned int
>>  chkp_versioning (void)
>>  {
>>struct cgraph_node *node;
>> +  const char *reason;
>>
>>bitmap_obstack_initialize (NULL);
>>
>> @@ -587,14 +602,20 @@ chkp_versioning (void)
>>   && !node->instrumented_version
>>   && !node->alias
>>   && !node->thunk.thunk_p
>> - && !lookup_attribute ("bnd_legacy", DECL_ATTRIBUTES (node->decl))
>> - && (!flag_chkp_instrument_marked_only
>> - || lookup_attribute ("bnd_instrument",
>> -  DECL_ATTRIBUTES (node->decl)))
>>   && (!DECL_BUILT_IN (node->decl)
>>   || (DECL_BUILT_IN_CLASS (node->decl) == BUILT_IN_NORMAL
>>   && DECL_FUNCTION_CODE (node->decl) < BEGIN_CHKP_BUILTINS)))
>> -   chkp_maybe_create_clone (node->decl);

Re: [PATCH, CHKP, PR64363] Don't instrument functions we cannot copy

2015-01-15 Thread Richard Biener
On Thu, Jan 15, 2015 at 2:51 PM, Ilya Enkovich  wrote:
> 2015-01-15 16:07 GMT+03:00 Richard Biener :
>> On Thu, Jan 15, 2015 at 12:46 PM, Ilya Enkovich  
>> wrote:
>>> Hi,
>>>
>>> This patch is to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64363.  
>>> Patch disables instrumentation for functions we cannot clone correctly due 
>>> to labels.
>>>
>>> Bootstrapped and checked on x86_64-unknown-linux-gnu.  OK for trunk?
>>
>>   {
>> + clone->remove_callees ();
>> + clone->remove_all_references ();
>>
>> this looks like a spurious change?
>
> Seems bogus thunk creation here wasn't triggered before but this test
> revealed it in addition to labels issue.
>
>>
>> + std::string msg = "function cannot be instrumented: ";
>> + msg += reason;
>> + warning (OPT_Wchkp, msg.c_str (), node->decl);
>>
>> ick - please don't use std::string.  SImply do
>>
>>  warning (OPT_Wchkp, "function cannot be instrumented: %s", node->decl, 
>> reason);
>
> reason string has "%q+F" inside and therefore string concatenation is 
> required.

Then use

if (warning (OPT_Wchkp, "function cannot be instrumented"))
  inform (reason);

Richard.

> Thanks,
> Ilya
>
>>
>> Otherwise ok.
>>
>> Thanks,
>> Richard.
>>
>>> Thanks,
>>> Ilya
>>> --
>>> gcc/
>>>
>>> 2015-01-14  Ilya Enkovich  
>>>
>>> PR target/64363
>>> * ipa-chkp.h (chkp_instrumentable_p): New.
>>> * ipa-chkp.c: Include tree-inline.h.
>>> (chkp_instrumentable_p): New.
>>> (chkp_maybe_create_clone): Use chkp_instrumentable_p.
>>> Fix processing of not instrumentable functions.
>>> (chkp_versioning): Use chkp_instrumentable_p. Warn about
>>> not instrumentable functions.
>>> * tree-chkp.c (chkp_add_bounds_to_call_stmt): Use
>>> chkp_instrumentable_p.
>>> * tree-inline.h (copy_forbidden): New.
>>> * tree-inline.c (copy_forbidden): Not static anymore.
>>>
>>> gcc/testsuite/
>>>
>>> 2015-01-14  Ilya Enkovich  
>>>
>>> PR target/64363
>>> * gcc.target/i386/chkp-label-address.c: New.
>>>
>>>
>>> diff --git a/gcc/ipa-chkp.c b/gcc/ipa-chkp.c
>>> index 30d511d..4fb60f0 100644
>>> --- a/gcc/ipa-chkp.c
>>> +++ b/gcc/ipa-chkp.c
>>> @@ -50,6 +50,7 @@ along with GCC; see the file COPYING3.  If not see
>>>  #include "lto-streamer.h"
>>>  #include "cgraph.h"
>>>  #include "tree-chkp.h"
>>> +#include "tree-inline.h"
>>>  #include "ipa-chkp.h"
>>>
>>>  /*  Pointer Bounds Checker has two IPA passes to support code 
>>> instrumentation.
>>> @@ -401,6 +402,18 @@ chkp_maybe_clone_builtin_fndecl (tree fndecl)
>>>return clone;
>>>  }
>>>
>>> +/* Return 1 if function FNDECL should be instrumented.  */
>>> +
>>> +bool
>>> +chkp_instrumentable_p (tree fndecl)
>>> +{
>>> +  struct function *fn = DECL_STRUCT_FUNCTION (fndecl);
>>> +  return (!lookup_attribute ("bnd_legacy", DECL_ATTRIBUTES (fndecl))
>>> + && (!flag_chkp_instrument_marked_only
>>> + || lookup_attribute ("bnd_instrument", DECL_ATTRIBUTES 
>>> (fndecl)))
>>> + && (!fn || !copy_forbidden (fn, fndecl)));
>>> +}
>>> +
>>>  /* Return clone created for instrumentation of NODE or NULL.  */
>>>
>>>  cgraph_node *
>>> @@ -483,10 +496,10 @@ chkp_maybe_create_clone (tree fndecl)
>>> {
>>>   /* If function will not be instrumented, then it's instrumented
>>>  version is a thunk for the original.  */
>>> - if (lookup_attribute ("bnd_legacy", DECL_ATTRIBUTES (fndecl))
>>> - || (flag_chkp_instrument_marked_only
>>> - && !lookup_attribute ("bnd_instrument", DECL_ATTRIBUTES 
>>> (fndecl
>>> + if (!chkp_instrumentable_p (fndecl))
>>> {
>>> + clone->remove_callees ();
>>> + clone->remove_all_references ();
>>>   clone->thunk.thunk_p = true;
>>>   clone->thunk.add_pointer_bounds_args = true;
>>>   clone->create_edge (node, NULL, 0, CGRAPH_FREQ_BASE);
>>> @@ -532,7 +545,8 @@ chkp_maybe_create_clone (tree fndecl)
>>>
>>>/* Clone all thunks.  */
>>>for (e = node->callers; e; e = e->next_caller)
>>> -   if (e->caller->thunk.thunk_p)
>>> +   if (e->caller->thunk.thunk_p
>>> +   && !e->caller->thunk.add_pointer_bounds_args)
>>>   {
>>> struct cgraph_node *thunk
>>>   = chkp_maybe_create_clone (e->caller->decl);
>>> @@ -578,6 +592,7 @@ static unsigned int
>>>  chkp_versioning (void)
>>>  {
>>>struct cgraph_node *node;
>>> +  const char *reason;
>>>
>>>bitmap_obstack_initialize (NULL);
>>>
>>> @@ -587,14 +602,20 @@ chkp_versioning (void)
>>>   && !node->instrumented_version
>>>   && !node->alias
>>>   && !node->thunk.thunk_p
>>> - && !lookup_attribute ("bnd_legacy", DECL_ATTRIBUTES (node->decl))
>>> - && (!flag_chkp_instrument_marked_only
>>> - || lookup_attribute ("bnd_instrument",
>>> 

[PATCH][AARCH64]Fix syntax error in target selector "-O2" for volatileloadpair-1.c & volatileloadpair-2.c

2015-01-15 Thread Renlin Li

Hi all,

This is a simple fix to correct two typos (I believe) in the newly 
introduced volatileloadpair-1.c & volatileloadpair-2.c test case.


After the change, the test cases compiles and runs correctly.
Okay to commit?

Regards,
Renlin Li

gcc/testsuite/ChangeLog:

2015-01-15 Renlin Li 

* gcc.target/aarch64/volatileloadpair-1.c: Correct dg-options.
* gcc.target/aarch64/volatileloadpair-2.c: Likewise.


diff --git a/gcc/testsuite/gcc.target/aarch64/volatileloadpair-1.c b/gcc/testsuite/gcc.target/aarch64/volatileloadpair-1.c
index 76162a5..57a0535 100644
--- a/gcc/testsuite/gcc.target/aarch64/volatileloadpair-1.c
+++ b/gcc/testsuite/gcc.target/aarch64/volatileloadpair-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-do options "-O2" } */
+/* { dg-options "-O2" } */
 /* volatile references should not produce load pair. */
 /* { dg-final { scan-assembler-not "ldp\t" } } */
 
diff --git a/gcc/testsuite/gcc.target/aarch64/volatileloadpair-2.c b/gcc/testsuite/gcc.target/aarch64/volatileloadpair-2.c
index 133bda2..0a0616d 100644
--- a/gcc/testsuite/gcc.target/aarch64/volatileloadpair-2.c
+++ b/gcc/testsuite/gcc.target/aarch64/volatileloadpair-2.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-do options "-O2" } */
+/* { dg-options "-O2" } */
 /* volatile references should not produce load pair. */
 /* { dg-final { scan-assembler-not "ldp\t" } } */
 

Re: [PATCH][AARCH64]Fix syntax error in target selector "-O2" for volatileloadpair-1.c & volatileloadpair-2.c

2015-01-15 Thread Richard Earnshaw
On 15/01/15 14:10, Renlin Li wrote:
> Hi all,
> 
> This is a simple fix to correct two typos (I believe) in the newly 
> introduced volatileloadpair-1.c & volatileloadpair-2.c test case.
> 
> After the change, the test cases compiles and runs correctly.
> Okay to commit?
> 
> Regards,
> Renlin Li
> 
> gcc/testsuite/ChangeLog:
> 
>  2015-01-15 Renlin Li 
> 
>  * gcc.target/aarch64/volatileloadpair-1.c: Correct dg-options.
>  * gcc.target/aarch64/volatileloadpair-2.c: Likewise.
> 

OK.

R.
> 
> new(1).diff
> 
> 
> diff --git a/gcc/testsuite/gcc.target/aarch64/volatileloadpair-1.c 
> b/gcc/testsuite/gcc.target/aarch64/volatileloadpair-1.c
> index 76162a5..57a0535 100644
> --- a/gcc/testsuite/gcc.target/aarch64/volatileloadpair-1.c
> +++ b/gcc/testsuite/gcc.target/aarch64/volatileloadpair-1.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-do options "-O2" } */
> +/* { dg-options "-O2" } */
>  /* volatile references should not produce load pair. */
>  /* { dg-final { scan-assembler-not "ldp\t" } } */
>  
> diff --git a/gcc/testsuite/gcc.target/aarch64/volatileloadpair-2.c 
> b/gcc/testsuite/gcc.target/aarch64/volatileloadpair-2.c
> index 133bda2..0a0616d 100644
> --- a/gcc/testsuite/gcc.target/aarch64/volatileloadpair-2.c
> +++ b/gcc/testsuite/gcc.target/aarch64/volatileloadpair-2.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */
> -/* { dg-do options "-O2" } */
> +/* { dg-options "-O2" } */
>  /* volatile references should not produce load pair. */
>  /* { dg-final { scan-assembler-not "ldp\t" } } */
>  
> 




[PATCH][x86] Update s{r,l}li intrinsics.

2015-01-15 Thread Ilya Tocar
Hi,
Looks like new ISA doc [1] renamed srli,slli intrinsics to bsrli,bslli.
This patch adds b* versions, while keeping old srli for backward
compatibility.
OK for trunk?

1:https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf

ChangeLog:
gcc/
* config/i386/avx2intrin.h (_mm256_bslli_si256,
_mm256_bsrli_si256): New.
* config/i386/emmintrin.h (_mm_bsrli_si128, _mm_bslli_si128):
Ditto.

testsuite/
* gcc.target/i386/sse-14.c: Test new intrinsic.
* gcc.target/i386/sse-22.c: Diito.
---
 gcc/config/i386/avx2intrin.h   | 18 ++
 gcc/config/i386/emmintrin.h| 16 
 gcc/testsuite/gcc.target/i386/sse-14.c |  2 ++
 gcc/testsuite/gcc.target/i386/sse-22.c |  4 
 4 files changed, 40 insertions(+)

diff --git a/gcc/config/i386/avx2intrin.h b/gcc/config/i386/avx2intrin.h
index 669f1dc..8a30c5b 100644
--- a/gcc/config/i386/avx2intrin.h
+++ b/gcc/config/i386/avx2intrin.h
@@ -645,11 +645,20 @@ _mm256_sign_epi32 (__m256i __X, __m256i __Y)
 #ifdef __OPTIMIZE__
 extern __inline __m256i
 __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
+_mm256_bslli_si256 (__m256i __A, const int __N)
+{
+  return (__m256i)__builtin_ia32_pslldqi256 (__A, __N * 8);
+}
+
+extern __inline __m256i
+__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
 _mm256_slli_si256 (__m256i __A, const int __N)
 {
   return (__m256i)__builtin_ia32_pslldqi256 (__A, __N * 8);
 }
 #else
+#define _mm256_bslli_si256(A, N) \
+  ((__m256i)__builtin_ia32_pslldqi256 ((__m256i)(A), (int)(N) * 8))
 #define _mm256_slli_si256(A, N) \
   ((__m256i)__builtin_ia32_pslldqi256 ((__m256i)(A), (int)(N) * 8))
 #endif
@@ -727,11 +736,20 @@ _mm256_sra_epi32 (__m256i __A, __m128i __B)
 #ifdef __OPTIMIZE__
 extern __inline __m256i
 __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
+_mm256_bsrli_si256 (__m256i __A, const int __N)
+{
+  return (__m256i)__builtin_ia32_psrldqi256 (__A, __N * 8);
+}
+
+extern __inline __m256i
+__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
 _mm256_srli_si256 (__m256i __A, const int __N)
 {
   return (__m256i)__builtin_ia32_psrldqi256 (__A, __N * 8);
 }
 #else
+#define _mm256_bsrli_si256(A, N) \
+  ((__m256i)__builtin_ia32_psrldqi256 ((__m256i)(A), (int)(N) * 8))
 #define _mm256_srli_si256(A, N) \
   ((__m256i)__builtin_ia32_psrldqi256 ((__m256i)(A), (int)(N) * 8))
 #endif
diff --git a/gcc/config/i386/emmintrin.h b/gcc/config/i386/emmintrin.h
index ad37fac..b19f05a 100644
--- a/gcc/config/i386/emmintrin.h
+++ b/gcc/config/i386/emmintrin.h
@@ -1165,6 +1165,18 @@ _mm_srai_epi32 (__m128i __A, int __B)
 
 #ifdef __OPTIMIZE__
 extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
+_mm_bsrli_si128 (__m128i __A, const int __N)
+{
+  return (__m128i)__builtin_ia32_psrldqi128 (__A, __N * 8);
+}
+
+extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
+_mm_bslli_si128 (__m128i __A, const int __N)
+{
+  return (__m128i)__builtin_ia32_pslldqi128 (__A, __N * 8);
+}
+
+extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
 _mm_srli_si128 (__m128i __A, const int __N)
 {
   return (__m128i)__builtin_ia32_psrldqi128 (__A, __N * 8);
@@ -1176,6 +1188,10 @@ _mm_slli_si128 (__m128i __A, const int __N)
   return (__m128i)__builtin_ia32_pslldqi128 (__A, __N * 8);
 }
 #else
+#define _mm_bsrli_si128(A, N) \
+  ((__m128i)__builtin_ia32_psrldqi128 ((__m128i)(A), (int)(N) * 8))
+#define _mm_bslli_si128(A, N) \
+  ((__m128i)__builtin_ia32_pslldqi128 ((__m128i)(A), (int)(N) * 8))
 #define _mm_srli_si128(A, N) \
   ((__m128i)__builtin_ia32_psrldqi128 ((__m128i)(A), (int)(N) * 8))
 #define _mm_slli_si128(A, N) \
diff --git a/gcc/testsuite/gcc.target/i386/sse-14.c 
b/gcc/testsuite/gcc.target/i386/sse-14.c
index f3f6c5c..e8791e3 100644
--- a/gcc/testsuite/gcc.target/i386/sse-14.c
+++ b/gcc/testsuite/gcc.target/i386/sse-14.c
@@ -601,6 +601,8 @@ test_2 (_mm_alignr_pi8, __m64, __m64, __m64, 1)
 
 /* emmintrin.h */
 test_2 (_mm_shuffle_pd, __m128d, __m128d, __m128d, 1)
+test_1 (_mm_bsrli_si128, __m128i, __m128i, 1)
+test_1 (_mm_bslli_si128, __m128i, __m128i, 1)
 test_1 (_mm_srli_si128, __m128i, __m128i, 1)
 test_1 (_mm_slli_si128, __m128i, __m128i, 1)
 test_1 (_mm_extract_epi16, int, __m128i, 1)
diff --git a/gcc/testsuite/gcc.target/i386/sse-22.c 
b/gcc/testsuite/gcc.target/i386/sse-22.c
index 0d7bd16..5735514 100644
--- a/gcc/testsuite/gcc.target/i386/sse-22.c
+++ b/gcc/testsuite/gcc.target/i386/sse-22.c
@@ -138,6 +138,8 @@ test_1 (_mm_prefetch, void, void *, _MM_HINT_NTA)
 #endif
 #include 
 test_2 (_mm_shuffle_pd, __m128d, __m128d, __m128d, 1)
+test_1 (_mm_bsrli_si128, __m128i, __m128i, 1)
+test_1 (_mm_bslli_si128, __m128i, __m128i, 1)
 test_1 (_mm_srli_si128, __m128i, __m128i, 1)
 test_1 (_mm_slli_si128, __m128i, __m128i, 1)
 test_1 (_mm_extract_epi16, int, __m128i, 1)
@@ -269,6 +271,8 @@ t

Re: [PATCH][x86] Update s{r,l}li intrinsics.

2015-01-15 Thread Uros Bizjak
On Thu, Jan 15, 2015 at 3:17 PM, Ilya Tocar  wrote:
> Hi,
> Looks like new ISA doc [1] renamed srli,slli intrinsics to bsrli,bslli.
> This patch adds b* versions, while keeping old srli for backward
> compatibility.
> OK for trunk?
>
> 1:https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf
>
> ChangeLog:
> gcc/
> * config/i386/avx2intrin.h (_mm256_bslli_si256,
> _mm256_bsrli_si256): New.
> * config/i386/emmintrin.h (_mm_bsrli_si128, _mm_bslli_si128):
> Ditto.
>
> testsuite/
> * gcc.target/i386/sse-14.c: Test new intrinsic.
> * gcc.target/i386/sse-22.c: Diito.

OK.

Thanks,
Uros.


Re: [PATCH, AARCH64] Fix ICE in CCMP (PR64015)

2015-01-15 Thread Jiong Wang

On 15/12/14 08:41, Zhenqiang Chen wrote:




-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Saturday, December 13, 2014 3:26 AM
To: Zhenqiang Chen
Cc: Marcus Shawcroft; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, AARCH64] Fix ICE in CCMP (PR64015)


- tree lhs = gimple_assign_lhs (g);
  enum machine_mode mode = TYPE_MODE (TREE_TYPE (lhs));
  rtx target = gen_reg_rtx (mode);
+
+ start_sequence ();
  tmp = emit_cstore (target, icode, NE, cc_mode, cc_mode,
 0, tmp, const0_rtx, 1, mode);
  if (tmp)
-   return tmp;
+   {
+ rtx seq = get_insns ();
+ end_sequence ();
+ emit_insn (prep_seq);
+ emit_insn (gen_seq);
+ emit_insn (seq);
+ return tmp;
+   }
+ end_sequence ();

Given that you're already doing delete_insns_since (last) at the end of this
function, I don't think you need a new sequence around the emit_cstore.
Just

emit_insn (prep_seq);
emit_insn (gen_seq);
tmp = emit_cstore (...);
if (tmp)
  return tmp;

Updated.
  

+  int unsignedp = code == LTU || code == LEU || code == GTU || code
+ == GEU;

You don't need to examine the code, you can look at the argument:

   TYPE_UNSIGNED (TREE_TYPE (treeop0))
  
Updated.
  

+  op0 = prepare_operand (icode, op0, 2, op_mode, cmp_mode,
+ unsignedp);
+  op1 = prepare_operand (icode, op1, 3, op_mode, cmp_mode,
+ unsignedp);  if (!op0 || !op1)
+{
+  end_sequence ();
+  return NULL_RTX;
+}
+  *prep_seq = get_insns ();
+  end_sequence ();
+
+  cmp = gen_rtx_fmt_ee ((enum rtx_code) code, cmp_mode, op0, op1);
+ target = gen_rtx_REG (CCmode, CC_REGNUM);
+
+  create_output_operand (&ops[0], target, CCmode);
+ create_fixed_operand (&ops[1], cmp);  create_fixed_operand (&ops[2],
+ op0);  create_fixed_operand (&ops[3], op1);

Hmm.  With so many fixed operands, I think you may be better off not
creating the cmp expander in the first place.  Just inline the
SELECT_CC_MODE and everything right here.

In the patch, I use prepare_operand (icode, op0, 2, ...) to do the operand MODE 
conversion (from HI/QI to SI), which needs a cmp expander. Without it, I 
have to add additional codes to do the conversion (as it in previous patch, which 
leads to PR64015).


Ping~,

verified this patch will pass speck2k6 build without ICE anymore.



Thanks!
-Zhenqiang





[PATCH]Enable gcc/testsuite/gcc.dg/builtin-apply2.c for aarch64

2015-01-15 Thread Renlin Li

Hi all,

This test is applicable to aarch64 target. This patch will remove 
aarch64 from skip target list.



Verified that it passes for aarch64-none-elf and aarch64-none-linux-gnu 
target.

Okay for trunk?

gcc/testsuite/ChangeLog:

2015-01-15 Renlin Li 

* gcc.dg/builtin-apply2.c: Remove aarch64 target from skip list.

diff --git a/gcc/testsuite/gcc.dg/builtin-apply2.c b/gcc/testsuite/gcc.dg/builtin-apply2.c
index d666fcc..b6cbe39 100644
--- a/gcc/testsuite/gcc.dg/builtin-apply2.c
+++ b/gcc/testsuite/gcc.dg/builtin-apply2.c
@@ -1,6 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target untyped_assembly } */
-/* { dg-skip-if "Variadic funcs have all args on stack. Normal funcs have args in registers." { "aarch64*-*-* avr-*-* nds32*-*-*" } { "*" } { "" } } */
+/* { dg-skip-if "Variadic funcs have all args on stack. Normal funcs have args in registers." { "avr-*-* nds32*-*-*" } { "*" } { "" } } */
 /* { dg-skip-if "Variadic funcs use Base AAPCS.  Normal funcs use VFP variant." { arm*-*-* && arm_hf_eabi } { "*" } { "" } } */
 
 /* PR target/12503 */


[testsuite] Fix plugin test for bareboard ports

2015-01-15 Thread Eric Botcazou
Hi,

if you run a test for a bareboard port, e.g. arm-eabi or visium-elf, you'll 
see in gcc.log:

Running /home/eric/svn/gcc/gcc/testsuite/gcc.dg/dg.exp ...
Executing on host: /home/eric/build/gcc/arm-eabi/gcc/xgcc -
B/home/eric/build/gcc/arm-eabi/gcc/ linker_plugin14260.c  -fno-diagnostics-
show-caret -fdiagnostics-color=never  -flto -fuse-linker-plugin  -lm-o 
linker_plugin14260.exe(timeout = 300)
spawn /home/eric/build/gcc/arm-eabi/gcc/xgcc -B/home/eric/build/gcc/arm-
eabi/gcc/ linker_plugin14260.c -fno-diagnostics-show-caret -fdiagnostics-
color=never -flto -fuse-linker-plugin -lm -o linker_plugin14260.exe
/home/eric/install/gcc/arm-eabi/bin/ld: cannot find crt0.o: No such file or 
directory
collect2: error: ld returned 1 exit status
compiler exited with status 1

Failure of the plugin test will in turn cause gcc.c-torture/compile/pr61848.c 
to fail in LTO mode:

FAIL: gcc.c-torture/compile/pr61848.c   -O2 -flto   scan-assembler mysection
FAIL: gcc.c-torture/compile/pr61848.c   -O2 -flto -flto-partition=none   scan-
assembler mysection

because of the fat/thin LTO object mismatch.

The attached patch fixes it by ensuring that LTO_TORTURE_OPTIONS is computed 
after set_ld_library_path_env_vars is invoked (this procedure invokes in turn 
set_gcc_exec_prefix_env_var), both in c-torture.exp and in gcc-dg.exp.

Tested on x86_64-suse-linux and visium-elf, OK for the mainline?


2015-01-15  Eric Botcazou  

* lib/c-torture.exp: Compute LTO_TORTURE_OPTIONS after the environment
is set up.
* lib/gcc-dg.exp: Likewise.


-- 
Eric BotcazouIndex: lib/gcc-dg.exp
===
--- lib/gcc-dg.exp	(revision 219578)
+++ lib/gcc-dg.exp	(working copy)
@@ -72,7 +72,14 @@ if [info exists ADDITIONAL_TORTURE_OPTIO
 	[concat $DG_TORTURE_OPTIONS $ADDITIONAL_TORTURE_OPTIONS]
 }
 
-set LTO_TORTURE_OPTIONS ""
+global orig_environment_saved
+
+# This file may be sourced, so don't override environment settings
+# that have been previously setup.
+if { $orig_environment_saved == 0 } {
+append ld_library_path [gcc-set-multilib-library-path $GCC_UNDER_TEST]
+set_ld_library_path_env_vars
+}
 
 # Some torture-options cause intermediate code output, unusable for
 # testing using e.g. scan-assembler.  In this variable are the options
@@ -80,6 +87,7 @@ set LTO_TORTURE_OPTIONS ""
 global gcc_force_conventional_output
 set gcc_force_conventional_output ""
 
+set LTO_TORTURE_OPTIONS ""
 if [check_effective_target_lto] {
 # When having plugin test both slim and fat LTO and plugin/nonplugin
 # path.
@@ -97,15 +105,6 @@ if [check_effective_target_lto] {
 }
 }
 
-global orig_environment_saved
-
-# This file may be sourced, so don't override environment settings
-# that have been previously setup.
-if { $orig_environment_saved == 0 } {
-append ld_library_path [gcc-set-multilib-library-path $GCC_UNDER_TEST]
-set_ld_library_path_env_vars
-}
-
 # Define gcc callbacks for dg.exp.
 
 proc gcc-dg-test-1 { target_compile prog do_what extra_tool_flags } {
Index: lib/c-torture.exp
===
--- lib/c-torture.exp	(revision 219578)
+++ lib/c-torture.exp	(working copy)
@@ -51,6 +51,20 @@ if [info exists ADDITIONAL_TORTURE_OPTIO
 	[concat $C_TORTURE_OPTIONS $ADDITIONAL_TORTURE_OPTIONS]
 }
 
+global GCC_UNDER_TEST
+if ![info exists GCC_UNDER_TEST] {
+set GCC_UNDER_TEST "[find_gcc]"
+}
+
+global orig_environment_saved
+
+# This file may be sourced, so don't override environment settings
+# that have been previously setup.
+if { $orig_environment_saved == 0 } {
+append ld_library_path [gcc-set-multilib-library-path $GCC_UNDER_TEST]
+set_ld_library_path_env_vars
+}
+
 set LTO_TORTURE_OPTIONS ""
 if [check_effective_target_lto] {
 # When having plugin test both slim and fat LTO and plugin/nonplugin
@@ -68,20 +82,6 @@ if [check_effective_target_lto] {
 }
 }
 
-global GCC_UNDER_TEST
-if ![info exists GCC_UNDER_TEST] {
-set GCC_UNDER_TEST "[find_gcc]"
-}
-
-global orig_environment_saved
-
-# This file may be sourced, so don't override environment settings
-# that have been previously setup.
-if { $orig_environment_saved == 0 } {
-append ld_library_path [gcc-set-multilib-library-path $GCC_UNDER_TEST]
-set_ld_library_path_env_vars
-}
-
 #
 # c-torture-compile -- runs the Tege C-torture test
 #

Re: [RFC] POWER8 default for PPC64LE

2015-01-15 Thread Peter Bergner
On Wed, 2015-01-14 at 13:36 -0700, Jeff Law wrote:
> On 01/14/15 13:32, David Edelsohn wrote:
> > The PPC64LE ABI specifies POWER8 ISA as the minimum hardware
> > requierment.  Currently, Linux distributions are building the
> > toolchain using --with-cpu=power7 or power8, as they wish.  GCC
> > defaults to essentially the POWER4 ISA.
> >
> > The appended patch changes the default for PPC64LE to POWER8 (ISA
> > 2.7).  32-bit PPC SVR4 is not really defined, but it is left unchanged
> > with no minimum ISA.
> >
> > The default ISA can be overridden using --with-cpu= and we presume
> > that Linux distributions and users will continue to configure as they
> > require for their deployment.
> >
> > * config/rs6000/default64.h (TARGET_DEFAULT) [LITTLE_ENDIAN]: Use ISA
> > 2.7 (POWER8).
> Given you've got a new ABI in play here, seems like the perfect time to 
> bump the default ISA to something reasonable.

Agreed.  Given the new ABI requires POWER8 as the minimum, I think this
patch is a no brainer.

Peter





[PATCH 4.8/4.9] Backport of PR lto/63704

2015-01-15 Thread Martin Liška

Hello.

Following patch is a backport of PR lto/63704 for GCC 4.8 and 4.9 branches.
Richi preapproved me the patch and I've run regtests on x86_64-linux-pc.

I'm going to install the patch.

Thanks,
Martin
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 779fef7..ab916b8 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2015-01-15  Richard Biener  
+	Martin Liska  
+
+	PR middle-end/63704
+	* alias.c (mems_in_disjoint_alias_sets_p): Remove assert
+	and instead return false when !fstrict-aliasing.
+
 2014-10-21  Jakub Jelinek  
 
 	PR tree-optimization/63563
diff --git a/gcc/alias.c b/gcc/alias.c
index 434ae7a..79a3560 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -383,17 +383,9 @@ get_alias_set_entry (alias_set_type alias_set)
 static inline int
 mems_in_disjoint_alias_sets_p (const_rtx mem1, const_rtx mem2)
 {
-/* Perform a basic sanity check.  Namely, that there are no alias sets
-   if we're not using strict aliasing.  This helps to catch bugs
-   whereby someone uses PUT_CODE, but doesn't clear MEM_ALIAS_SET, or
-   where a MEM is allocated in some way other than by the use of
-   gen_rtx_MEM, and the MEM_ALIAS_SET is not cleared.  If we begin to
-   use alias sets to indicate that spilled registers cannot alias each
-   other, we might need to remove this check.  */
-  gcc_assert (flag_strict_aliasing
-	  || (!MEM_ALIAS_SET (mem1) && !MEM_ALIAS_SET (mem2)));
-
-  return ! alias_sets_conflict_p (MEM_ALIAS_SET (mem1), MEM_ALIAS_SET (mem2));
+  return (flag_strict_aliasing
+	  && ! alias_sets_conflict_p (MEM_ALIAS_SET (mem1),
+  MEM_ALIAS_SET (mem2)));
 }
 
 /* Insert the NODE into the splay tree given by DATA.  Used by


Re: [Ping] Port of VTV for Cygwin and MinGW

2015-01-15 Thread Ian Lance Taylor
On Wed, Jan 14, 2015 at 11:54 PM, Patrick Wollgast
 wrote:
> Is there something I'm still supposed to do, since I don't have write
> access and this was the last part missing an "OK"?

Somebody with write access will need to commit the patch for you.  You
should send a new clean patch including all the changes, along with
updated ChangeLog entries.

Ian


Re: [PATCH 5/5] rs6000: Do not allow TImode with -m32 -mpowerpc64

2015-01-15 Thread David Edelsohn
On Wed, Jan 14, 2015 at 8:14 PM, Segher Boessenkool
 wrote:
> This fixes 141 FAILs.
>
> -mpowerpc64 does not change the ABI, but default_scalar_mode_supported_p
> does not know that, and allows TImode for -m32 -mpowerpc64.
>
> This fixes it.  Okay for mainline?
>
>
> 2015-01-14  Segher Boessenkool  
>
> gcc/
> * config/rs6000/rs6000.c (rs6000_scalar_mode_supported_p): Disallow
> TImode for TARGET_32BIT.

Okay.

Would you please add a comment that efficient TImode arithmetic
requires carry to explain the TARGET_32BIT relationship?

We can think about providing TImode logical operations in 32 bit, in
the long run.

Thanks, David


Re: [PATCH, RFC] LRA subreg handling

2015-01-15 Thread Vladimir Makarov
On 14/01/15 02:20 PM, Robert Suchanek wrote:
> Hi Vladimir,
>
> An issue has been identified with LRA when running CPU2006 h264ref benchmark.
>
> I'll try to describe what the issue is and a fix applied as it is very
> difficult to reproduce it and it is next to impossible to create a narrowed
> testcase on top of the source code restrictions.
>
> The concerned LRA code in lra-constraints.c is the following:
>
> if (GET_CODE (*loc) == SUBREG)
>   {
> reg = SUBREG_REG (*loc);
> byte = SUBREG_BYTE (*loc);
> if (REG_P (reg)
> /* Strict_low_part requires reload the register not
>the sub-register.  */
> && (curr_static_id->operand[i].strict_low
> || (GET_MODE_SIZE (mode)
> <= GET_MODE_SIZE (GET_MODE (reg))
> && (hard_regno
> = get_try_hard_regno (REGNO (reg))) >= 0
> && (simplify_subreg_regno
> (hard_regno,
>  GET_MODE (reg), byte, mode) < 0)
> && (goal_alt[i] == NO_REGS
> || (simplify_subreg_regno
> (ira_class_hard_regs[goal_alt[i]][0],
>  GET_MODE (reg), byte, mode) >= 0
>   {
> loc = &SUBREG_REG (*loc);
> mode = GET_MODE (*loc);
>   }
>   }
>
> The above works just fine when we deal with strict_low_part or a subreg
> smaller than a word.
>
> However, multi-word operations that were emitted as a sequence of operations
> on word sized parts of the DImode register appears to expose a problem with
> LRA e.g. '(set (subreg: SI (reg: DI)) ...)'.
> LRA does not realize that it actually uses the other halve of the DI-mode
> register leading to a situation where it modifies one halve of the result and
> spills the whole register with the other halve undefined.
>
> In the dump I can see the following:
>
>   Creating newreg=1552 from oldreg=521, assigning class GR_REGS to r1552
>  1487: r1552:DI#4=r1404:SI+r1509:SI
>   REG_DEAD r1509:SI
>   REG_DEAD r1404:SI
> Inserting insn reload after:
>  1735: r521:DI=r1552:DI
>
> There is nothing in the dump that sets r1552:DI#0 nor a reload is inserted
> to load the value before modifying it but it is spilled.
>
> As it is a multi-word register, the split pass emits an additional instruction
> to load the whole 64-bit value but since one halve was modified, only
> register $20 appears in the live-in set. In contrast to $20, $21 is being used
> but not added to the live-in set.
>
> ...
> ;; live  in  4 [$4] 6 [$6] 7 [$7] 10 [$10] 11 [$11] 12 [$12] 13 [$13]
> [$14] 15 [$15] 16 [$16] 17 [$17] 20 [$20] 22 [$22] 23 [$23] 24 [$24] 25 [$25]
> 29 [$sp] 30 [$fp] 31 [$31] 52 [$f20] 79 [$fakec]
> ...
> (insn 1788 1077 1789 80 (set (reg:SI 20 $20 [orig:521 distortion ] [521])
> (mem/c:SI (plus:SI (reg/f:SI 29 $sp)
>   (const_int 40 [0x28])) [16 %sfp+40 S4 A64])) rdopt.c:257 288
> {*movsi_internal}
>  (nil))
> (insn 1789 1788 1743 80 (set (reg:SI 21 $21 [ distortion+4 ])
> (mem/c:SI (plus:SI (reg/f:SI 29 $sp)
>   (const_int 44 [0x2c])) [16 %sfp+44 S4 A32])) rdopt.c:257 288
> {*movsi_internal}
>  (nil))
> ...
>
> The potential fix for this is to promote the type of a subreg OP_OUT to 
> OP_INOUT
> to treat the pseudo register (r1552 in this case) as input and LRA will be 
> forced
> to insert a reload before modifying its contents. 
>
> Handling of strict_low_part case is fine as the operand is described in the 
> MD pattern
> as IN_OUT through modifiers.
>
> With the above change in place, we get a reload before assignment:
>
>   Creating newreg=1552 from oldreg=521, assigning class GR_REGS to r1552
>  1487: r1552:DI#4=r1404:SI+r1509:SI
>   REG_DEAD r1509:SI
>   REG_DEAD r1404:SI
> Inserting insn reload before:
>  1735: r1552:DI=r521:DI
> Inserting insn reload after:
>  1736: r521:DI=r1552:DI
>
> and the benchmark happily passes the runtime check.
>
> The question is whether changing the type to OP_INOUT is the correct and
> valid fix?
>
> Regards,
> Robert
>
> 2015-01-14  Robert Suchanek  
>
> gcc/
> * lra-constraints.c (curr_insn_transform): Change the type of a reload
> pseudo to OP_INOUT.
> ---
>  gcc/lra-constraints.c |1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
> index ec28b7f..018968b 100644
> --- a/gcc/lra-constraints.c
> +++ b/gcc/lra-constraints.c
> @@ -3798,6 +3798,7 @@ curr_insn_transform (void)
>   (ira_class_hard_regs[goal_alt[i]][0],
>GET_MODE (reg), byte, mode) >= 0)
> {
> + type = OP_INOUT;
>   loc = &SUBREG_REG (*loc);
>   mode = GET_MODE (*loc);
> }
>
Robert, thanks for working on the issue.  Your approach is in the right
direction.  But I believe the change should be

if (type == OP_OUT)
  type = OP_INO

[PATCH] Fix PR testsuite/64605

2015-01-15 Thread Ilya Verbin
Hi!

This patch fixes 'make check-target-libatomic'.

The problem is that gcc-dg.exp calls check_effective_target_lto, which calls
libatomic_target_compile.  Therefore gcc-dg.exp should be loaded only after the
definition of libatomic_target_compile.

However, a similar exp file in other tree (libitm/testsuite/lib/libitm.exp)
doesn't contain any explicit 'load_gcc_lib gcc-dg.exp' at all, but it loads
gcc-dg.exp implicitly.  So I'm not sure whether this patch is correct.

Could someone familiar with DejaGnu please review it?


diff --git a/libatomic/testsuite/lib/libatomic.exp 
b/libatomic/testsuite/lib/libatomic.exp
index 28cbaa8..b95032a 100644
--- a/libatomic/testsuite/lib/libatomic.exp
+++ b/libatomic/testsuite/lib/libatomic.exp
@@ -23,6 +23,11 @@ proc load_gcc_lib { filename } {
 }
 
 load_lib dg.exp
+
+# Required to use gcc-dg.exp - however, the latter should NOT be
+# loaded until ${tool}_target_compile is defined since it uses that
+# to determine default LTO options.
+
 load_gcc_lib file-format.exp
 load_gcc_lib target-supports.exp
 load_gcc_lib target-utils.exp
@@ -40,7 +45,6 @@ load_gcc_lib torture-options.exp
 load_gcc_lib timeout.exp
 load_gcc_lib timeout-dg.exp
 load_gcc_lib fortran-modules.exp
-load_gcc_lib gcc-dg.exp
 
 set dg-do-what-default run
 
@@ -219,3 +223,5 @@ proc libatomic_option_proc { option } {
return 0
 }
 }
+
+load_gcc_lib gcc-dg.exp


Thanks,
  -- Ilya


Re: [Patch, AArch64, testsuite] PR63971: Revert test_frame_* patch.

2015-01-15 Thread Mike Stump
On Jan 14, 2015, at 3:50 AM, Tejas Belagod  wrote:
> As agreed here (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971), please 
> can I reverse Andrew's patch 
> out(https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02916.html)?

Ok.

Unless someone objects to a reversion like this, when the author of a patch 
says it should be reverted…  that’s all the approval it needs, though, people 
can always ask for a review for any reason they want.

Re: [PATCH] IPA ICF: add comparison for target and optimization nodes

2015-01-15 Thread Rainer Orth
Martin Liška  writes:

> On 01/07/2015 12:38 PM, Martin Liška wrote:
>> Hello.
>>
>> Following patch adds support for target and optimization nodes
>> comparison, which is
>> based on Honza's newly added infrastructure.
>>
>> Apart from that, there's a small hunk that corrects formatting and
>> removes unnecessary
>> call to a comparison function.
>>
>> Hope it can be applied as one patch.
>>
>> Tested on x86_64-linux-pc without any new regression introduction.
>>
>> Ready for trunk?
>>
>> Thank you,
>> Martin
>
> Hello.
>
> Apart from the previous patch, I would like to install following patch
> which introduces
> new dump functions related to target and optimization nodes. These
> functions dump just
> different flags.
>
> Patch has been tested on x86_64-linux-pc.

Unfortunately, this patch breaks Solaris/SPARC bootstrap:

options-save.c:3267:34: error: unused parameter 'indent' 
[-Werror=unused-parameter]
  int indent,
  ^
options-save.c:3268:55: error: unused parameter 'ptr1' 
[-Werror=unused-parameter]
  struct cl_target_option *ptr1,
   ^
options-save.c:3269:55: error: unused parameter 'ptr2' 
[-Werror=unused-parameter]
  struct cl_target_option *ptr2)
   ^

The following patch fixes this and allow the bootstrap to continue.

2015-01-15  Rainer Orth  

* optc-save-gen.awk (cl_target_option_print_diff): Mark indent,
ptr1, ptr2 unused.

diff --git a/gcc/optc-save-gen.awk b/gcc/optc-save-gen.awk
--- a/gcc/optc-save-gen.awk
+++ b/gcc/optc-save-gen.awk
@@ -505,9 +505,9 @@ print "";
 print "/* Print different target option variables from structures provided as arguments.  */";
 print "void";
 print "cl_target_option_print_diff (FILE *file,";
-print " int indent,";
-print " struct cl_target_option *ptr1,";
-print " struct cl_target_option *ptr2)";
+print " int indent ATTRIBUTE_UNUSED,";
+print " struct cl_target_option *ptr1 ATTRIBUTE_UNUSED,";
+print " struct cl_target_option *ptr2 ATTRIBUTE_UNUSED)";
 print "{";
 
 print "  fputs (\"\\n\", file);";

Ok for mainline?

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [PATCH] IPA ICF: add comparison for target and optimization nodes

2015-01-15 Thread Martin Liška

On 01/15/2015 05:20 PM, Rainer Orth wrote:

Martin Liška  writes:


On 01/07/2015 12:38 PM, Martin Liška wrote:

Hello.

Following patch adds support for target and optimization nodes
comparison, which is
based on Honza's newly added infrastructure.

Apart from that, there's a small hunk that corrects formatting and
removes unnecessary
call to a comparison function.

Hope it can be applied as one patch.

Tested on x86_64-linux-pc without any new regression introduction.

Ready for trunk?

Thank you,
Martin


Hello.

Apart from the previous patch, I would like to install following patch
which introduces
new dump functions related to target and optimization nodes. These
functions dump just
different flags.

Patch has been tested on x86_64-linux-pc.


Unfortunately, this patch breaks Solaris/SPARC bootstrap:

options-save.c:3267:34: error: unused parameter 'indent' 
[-Werror=unused-parameter]
   int indent,
   ^
options-save.c:3268:55: error: unused parameter 'ptr1' 
[-Werror=unused-parameter]
   struct cl_target_option *ptr1,
^
options-save.c:3269:55: error: unused parameter 'ptr2' 
[-Werror=unused-parameter]
   struct cl_target_option *ptr2)
^

The following patch fixes this and allow the bootstrap to continue.

2015-01-15  Rainer Orth  

* optc-save-gen.awk (cl_target_option_print_diff): Mark indent,
ptr1, ptr2 unused.




Ok for mainline?

Rainer



Hello Rainer.

Thank you for the patch.

Martin


Re: [testsuite] PATCH: Ignore additional messages on Linux/x86 with PIE

2015-01-15 Thread Mike Stump
So, I was hoping that someone would step forward and review this.  I’d like for 
a reviewer to consider, is this the type of error messages we want to vend to 
the poor user?  It strikes me as, well, icky.  Should -fPIE imply -fPIC?

Exclusive of that issue, the patch is fine.

On Jan 11, 2015, at 4:23 PM, H.J. Lu  wrote:
> g++.dg/other/anon5.C is expected to fail to link.  On Linux/x86 with PIE,
> there are additional messages linker:
> 
> [hjl@gnu-tools-1 gcc]$ g++  -fPIE -pie
> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/other/anon5.C
> /tmp/ccwg53fj.o: In function `f()': anon5.C:(.text+0x7): undefined reference 
> to `(anonymous namespace)::c::t'
> /usr/local/bin/ld: /tmp/ccwg53fj.o: relocation R_X86_64_PC32 against 
> undefined symbol `_ZN12_GLOBAL__N_11c1tE' can not be used when making a 
> shared object; recompile with -fPIC
> /usr/local/bin/ld: final link failed: Bad value
> collect2: error: ld returned 1 exit status
> [hjl@gnu-tools-1 gcc]$ 
> 
> This patch ignores additional messages on Linux/x86 with PIE.  OK for
> trunk?
> 
> Thanks.
> 
> H.J.
> ---
> gcc/testsuite/g++.dg/other/anon5.C | 2 ++
> 1 file changed, 2 insertions(+)
> 
> 2015-01-11  H.J. Lu  
> 
>   * g++.dg/other/anon5.C: Ignore additional messages on Linux/x86
>   with PIE.
> 
> diff --git a/gcc/testsuite/g++.dg/other/anon5.C 
> b/gcc/testsuite/g++.dg/other/anon5.C
> index 81e9def..4e4cc44 100644
> --- a/gcc/testsuite/g++.dg/other/anon5.C
> +++ b/gcc/testsuite/g++.dg/other/anon5.C
> @@ -3,6 +3,8 @@
> // { dg-options "-g" }
> // Ignore additional message on powerpc-ibm-aix
> // { dg-prune-output "obtain more information" } */
> +// Ignore additional messages on Linux/x86 with PIE
> +// { dg-prune-output "Bad value" } */
> 
> namespace {
>   struct c


Re: [PATCH/expand] PR64011 Adjust bitsize when partial overflow happen for big-endian

2015-01-15 Thread Jiong Wang


On 15/01/15 03:51, Jeff Law wrote:

On 01/14/15 15:31, Jiong Wang wrote:

agree, and I think the truncation is needed otherwise there may have ICE
on some target.

and I found current gcc LOCATION info is very good !
have done an experimental hack on at "expand_assignment": 4931 where the
tree is expanded,
gcc could give quite useful & accurate warning based on tree LOCATION info.

./cc1 -O2 -mbig-endian pr48335-2.c

pr48335-2.c: In function ‘f5’:
pr48335-2.c:19:29: warning: overflow here !
 ((U *)((char *) &s.d + 1))[3] = x;
   ^

while we need to add warning at store_bit_field_using_insv where
there is no accurate LOCATION info. but looks like it's acceptable?

pr48335-2.c:19:33: warning: overflow here !
 ((U *)((char *) &s.d + 1))[3] = x;
   ^

Yes, I think we're on the right track now -- warn and truncate the the
insertion.

I just scanned our set of warning flags to see if this would fit nicely
under any of the existing flags, and it doesn't.  I guess putting it
under -Wextra is probably best for now.

I think the warning text should indicate that the statement will write
outside the bounds of the destination object or something along those lines.


thanks for suggestions. patch updated

the warning message is as the following:

./cc1 -O2 pr48335-2.c -Wextra

pr48335-2.c: In function ‘f5’:
pr48335-2.c:19:33: warning: write of 16bit data outside the bound of 
destination object, data truncated into 8bit [-Wextra]
   ((U *)((char *) &s.d + 1))[3] = x;
 ^
x86-64 bootstrap & regress ok.

ok for trunk?

one other thing is I found using of "insv" maybe sub-optimal in some situation.
for example, even before my patch, modify type of U to char so there is no 
overflow.

use BFI will cost one more fmov (cc1 -O2 test.c), maybe this is caused by bfi 
only
support integer type, which may cause extra reg copy when there are both float 
& int type.

// comment out the "if (maybe_expand_insn" in store_bit_field_using_insv
// to fall back to other code path
f5:
uxtbw0, w0
stp x29, x30, [sp, -16]!
fmovs0, wzr
fmovs1, w0
add x29, sp, 0
bl  bar
ldp x29, x30, [sp], 16
ret

// BFI version
f5:
fmovs0, wzr
stp x29, x30, [sp, -16]!
add x29, sp, 0
fmovw1, s0
bfi w1, w0, 0, 8
fmovs1, w1
bl  bar
ldp x29, x30, [sp], 16
ret


Thanks.

gcc/
PR64011
* expmed.c (store_bit_field_using_insv): Warn and truncate bitsize when 
there is
partial overflow.
diff --git a/gcc/expmed.c b/gcc/expmed.c
index 0304e46..176c317 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -535,6 +535,21 @@ store_bit_field_using_insv (const extraction_insn *insv, rtx op0,
   copy_back = true;
 }
 
+  /* There are similar overflow check at the start of store_bit_field_1,
+ but that only check the situation where the field lies completely
+ outside the register, while there do have situation where the field
+ lies partialy in the register, we need to adjust bitsize for this
+ partial overflow situation.  Without this fix, pr48335-2.c on big-endian
+ will broken on those arch support bit insert instruction, like arm, aarch64
+ etc.  */
+  if (bitsize + bitnum > unit && bitnum < unit)
+{
+  warning (OPT_Wextra, "write of "HOST_WIDE_INT_PRINT_UNSIGNED"bit data "
+	   "outside the bound of destination object, data truncated into "
+	   HOST_WIDE_INT_PRINT_UNSIGNED"bit", bitsize, unit - bitnum);
+  bitsize = unit - bitnum;
+}
+
   /* If BITS_BIG_ENDIAN is zero on a BYTES_BIG_ENDIAN machine, we count
  "backwards" from the size of the unit we are inserting into.
  Otherwise, we count bits from the most significant on a

Re: libgo patch committed: Update to Go 1.4

2015-01-15 Thread Rainer Orth
Ian Lance Taylor  writes:

> I've committed a patch to libgo to update it to the Go 1.4 release,
> except for the runtime package.  Much of the runtime package was
> rewritten in Go, and it does not really affect users of the library,
> so I've postponed that complex merge.  All the other packages are
> updated.  A few minor compiler changes were required, as well as a few
> changes to the runtime packages required for other changes.  The
> testsuite script was changed to add support for the new TestMain
> function, which is used by one or two of the standard packages.
>
> As usual with libgo updates the entire patch is too large to attach
> here.  I've attached the changes to configuration/build files and the
> runtime package.
>
> Note that the type descriptor format has changed very very slightly to
> include an additional flag.  This means that all existing Go files
> must be recompiled in order to work with this updated libgo.  I will
> bump the libgo version number shortly.
>
> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
> Committed to mainline.

This (and perhaps the previous gotools) patch broke Solaris bootstrap:

/vol/gcc/src/hg/trunk/local/libgo/go/net/tcpsockopt_unix.go:23:73: error: 
reference to undefined identifier 'syscall.TCP_KEEPINTVL'
  if err := syscall.SetsockoptInt(fd.sysfd, syscall.IPPROTO_TCP, 
syscall.TCP_KEEPINTVL, secs); err != nil {
/vol/gcc/src/hg/trunk/local/libgo/go/net/tcpsockopt_unix.go:26:103: error: 
reference to undefined identifier 'syscall.TCP_KEEPIDLE'
  return os.NewSyscallError("setsockopt", syscall.SetsockoptInt(fd.sysfd, 
syscall.IPPROTO_TCP, syscall.TCP_KEEPIDLE, secs))
make[4]: *** [net.lo] Error 1

The following patch fixes this:

diff --git a/libgo/mksysinfo.sh b/libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh
+++ b/libgo/mksysinfo.sh
@@ -340,7 +340,7 @@ grep '^const _SHUT_' gen-sysinfo.go |
   sed -e 's/^\(const \)_\(SHUT[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
 
 # The net package requires some const definitions.
-for m in IP_PKTINFO IPV6_V6ONLY IPPROTO_IPV6 IPV6_JOIN_GROUP IPV6_LEAVE_GROUP IPV6_TCLASS SO_REUSEPORT; do
+for m in IP_PKTINFO IPV6_V6ONLY IPPROTO_IPV6 IPV6_JOIN_GROUP IPV6_LEAVE_GROUP IPV6_TCLASS SO_REUSEPORT TCP_KEEPINTVL TCP_KEEPIDLE; do
   if ! grep "^const $m " ${OUT} >/dev/null 2>&1; then
 echo "const $m = 0" >> ${OUT}
   fi

Apart from that, bootstrap fails in gotools: due to the use of
-static-libgo, all commands there fail to link since the socket
functions are missing.  It seems like $LIBS from libgo needs to be added
somewhere, but I'm unsure how best to handle this.  To make any progress
at all, I've just manually added -lsocket -lnsl to gotools/Makefile
(AM_LDFLAGS).

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [testsuite] PATCH: Ignore additional messages on Linux/x86 with PIE

2015-01-15 Thread H.J. Lu
On Thu, Jan 15, 2015 at 8:24 AM, Mike Stump  wrote:
> So, I was hoping that someone would step forward and review this.  I’d like 
> for a reviewer to consider, is this the type of error messages we want to 
> vend to the poor user?  It strikes me as, well, icky.  Should -fPIE imply 
> -fPIC?

It is an optimization:

https://gcc.gnu.org/ml/gcc-cvs/2014-12/msg00206.html

If linker supports copy reloc in PIE, we turn off PIC for the data access.
Since the symbol is undefined in this case, linker complains.

> Exclusive of that issue, the patch is fine.

I will check it in.

Thanks.

> On Jan 11, 2015, at 4:23 PM, H.J. Lu  wrote:
>> g++.dg/other/anon5.C is expected to fail to link.  On Linux/x86 with PIE,
>> there are additional messages linker:
>>
>> [hjl@gnu-tools-1 gcc]$ g++  -fPIE -pie
>> /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/other/anon5.C
>> /tmp/ccwg53fj.o: In function `f()': anon5.C:(.text+0x7): undefined reference 
>> to `(anonymous namespace)::c::t'
>> /usr/local/bin/ld: /tmp/ccwg53fj.o: relocation R_X86_64_PC32 against 
>> undefined symbol `_ZN12_GLOBAL__N_11c1tE' can not be used when making a 
>> shared object; recompile with -fPIC
>> /usr/local/bin/ld: final link failed: Bad value
>> collect2: error: ld returned 1 exit status
>> [hjl@gnu-tools-1 gcc]$
>>
>> This patch ignores additional messages on Linux/x86 with PIE.  OK for
>> trunk?
>>
>> Thanks.
>>
>> H.J.
>> ---
>> gcc/testsuite/g++.dg/other/anon5.C | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> 2015-01-11  H.J. Lu  
>>
>>   * g++.dg/other/anon5.C: Ignore additional messages on Linux/x86
>>   with PIE.
>>
>> diff --git a/gcc/testsuite/g++.dg/other/anon5.C 
>> b/gcc/testsuite/g++.dg/other/anon5.C
>> index 81e9def..4e4cc44 100644
>> --- a/gcc/testsuite/g++.dg/other/anon5.C
>> +++ b/gcc/testsuite/g++.dg/other/anon5.C
>> @@ -3,6 +3,8 @@
>> // { dg-options "-g" }
>> // Ignore additional message on powerpc-ibm-aix
>> // { dg-prune-output "obtain more information" } */
>> +// Ignore additional messages on Linux/x86 with PIE
>> +// { dg-prune-output "Bad value" } */
>>
>> namespace {
>>   struct c



-- 
H.J.


Re: [PATCH 3/3, ARM, libgcc, ping6] Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc

2015-01-15 Thread Mike Stump
On Jan 14, 2015, at 6:52 AM, Richard Earnshaw  wrote:
> On 14/01/15 11:57, Thomas Preud'homme wrote:
>> Ping?
> 
> I'm OK with this, but I think you also need a generic testsuite
> maintainer to go over the target independent parts.

Ok.


RE: [PATCH] Fix for PR64081 in RTL loop unroller

2015-01-15 Thread Zamyatin, Igor
> 
> On 01/13/15 11:01, Zamyatin, Igor wrote:
> >>
> >> Is it really sufficient here to verify that all the defs are on latch
> >> predecessors, what about the case where there is a predecessor
> >> without a def.  How do you guarantee domination in that case?
> >>
> >> ISTM that given the structure for the code you're writing that you'd
> >> want to verify that in the event of multiple definitions that all of
> >> them appear on immediate predecessors of the latch *and* that each
> >> immediate predecessor has a definition.
> >
> > Yes, do you think it's better to check exactly immediate predecessors?
> I'd use the same structure that you have in iv_get_reaching_def.  If there
> was a reasonable way to factor that test into a single function and call it 
> from
> both places that would be even better.

Not sure it's possible to merge DF_REG_DEF_CHAIN walk and DF_REF_CHAIN walk...

Thanks,
Igor

> 
> Jeff


Re: [PATCH] Fix for PR64081 in RTL loop unroller

2015-01-15 Thread Jeff Law

On 01/15/15 09:36, Zamyatin, Igor wrote:


On 01/13/15 11:01, Zamyatin, Igor wrote:


Is it really sufficient here to verify that all the defs are on latch
predecessors, what about the case where there is a predecessor
without a def.  How do you guarantee domination in that case?

ISTM that given the structure for the code you're writing that you'd
want to verify that in the event of multiple definitions that all of
them appear on immediate predecessors of the latch *and* that each
immediate predecessor has a definition.


Yes, do you think it's better to check exactly immediate predecessors?

I'd use the same structure that you have in iv_get_reaching_def.  If there
was a reasonable way to factor that test into a single function and call it from
both places that would be even better.


Not sure it's possible to merge DF_REG_DEF_CHAIN walk and DF_REF_CHAIN walk...
OK.  Just use the same overall structure if we can't pull the test out 
into a single function that could be called from both places.


jeff



Re: [COMMITTED] Merge libffi with upstream

2015-01-15 Thread Rainer Orth
Richard Henderson  writes:

> Upstream libffi has added support for Go closures (using the static chain),
> and support for complex numbers.  Perhaps less relevant is new support for
> arc, microblaze, moxie, nios, and or1k targets.
>
> Without additional changes for Go, this merge has little effect.  Within the
> gcc tree libffi is primarily used by libjava.
>
> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
>
> Due to upstream breakage, and difficulty debugging on Darwin,
> {i686,x86_64}-darwin retains copies of the existing sources and thus remains
> 100% unchanged.  Since libgo doesn't support darwin, this should cause no
> immediate problems.

The patch introduced massive problems on Solaris, both SPARC and x86:

* on Solaris/SPARC, /bin/as requires

  .type fn,#function

  instead of @function.  I've simply commented the affected lines in
  src/sparc/v[89].S to make progress.

* /bin/as doesn't support .macro/.endm.  I'm using preprocessor macros
  instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
  unix64}.S.

* Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
  uses in src/x86/{sysv, unix64}.S, as on Darwin.

* Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
  the moment.

* Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
  generated .eh_frame sections match, otherwise libffi.so fails to link:

ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file 
src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and 
cannot be merged into a single output section

* Yet unfixed for Solaris/SPARC /bin/as:

as: "v8.s", line 128: error: invalid digit in radix 10

  as seems to only understand single-digit labels

as: "v8.s", line 140: error: statement syntax
as: "v8.s", line 157: error: unknown opcode ".rept"
as: "v8.s", line 157: error: statement syntax
as: "v8.s", line 163: error: unknown opcode ".endr"
as: "v8.s", line 163: error: statement syntax

  and knows nothing about .rept/.endr

Here are the hacks I've used to make some progress:

diff --git a/libffi/src/sparc/v8.S b/libffi/src/sparc/v8.S
--- a/libffi/src/sparc/v8.S
+++ b/libffi/src/sparc/v8.S
@@ -48,7 +48,9 @@
 #ifndef __GNUC__
 .align 8
 	.globl	C(ffi_flush_icache)
+#if !(defined(__sun__) && defined(__svr4__))
 	.type	C(ffi_flush_icache),@function
+#endif
 	FFI_HIDDEN(C(ffi_flush_icache))
 
 C(ffi_flush_icache):
@@ -66,14 +68,17 @@ 1:	iflush %o0
 	.size	C(ffi_flush_icache), . - C(ffi_flush_icache)
 #endif
 
-.macro E index
-	.align	16
-	.org	2b + \index * 16
-.endm
+#if defined(__sun__) && defined(__svr4__)
+# define E(INDEX)	.align 16
+#else
+# define E(INDEX)	.align 16; .org 2b + INDEX * 16
+#endif
 
 .align 8
 	.globl	C(ffi_call_v8)
+#if !(defined(__sun__) && defined(__svr4__))
 	.type	C(ffi_call_v8),@function
+#endif
 	FFI_HIDDEN(C(ffi_call_v8))
 
 C(ffi_call_v8):
@@ -114,71 +119,71 @@ 1:	add	%o7, %l0, %o7	! o7 = 0b + ret_typ
 	! Note that each entry is 4 insns, enforced by the E macro.
 	.align	16
 2:
-E SPARC_RET_VOID
+E(SPARC_RET_VOID)
 	ret
 	 restore
-E SPARC_RET_STRUCT
+E(SPARC_RET_STRUCT)
 	unimp
-E SPARC_RET_UINT8
+E(SPARC_RET_UINT8)
 	and	%o0, 0xff, %o0
 	st	%o0, [%i2]
 	ret
 	 restore
-E SPARC_RET_SINT8
+E(SPARC_RET_SINT8)
 	sll	%o0, 24, %o0
 	b	7f
 	 sra	%o0, 24, %o0
-E SPARC_RET_UINT16
+E(SPARC_RET_UINT16)
 	sll	%o0, 16, %o0
 	b	7f
 	 srl	%o0, 16, %o0
-E SPARC_RET_SINT16
+E(SPARC_RET_SINT16)
 	sll	%o0, 16, %o0
 	b	7f
 	 sra	%o0, 16, %o0
-E SPARC_RET_UINT32
+E(SPARC_RET_UINT32)
 7:	st	%o0, [%i2]
 	ret
 	 restore
-E SP_V8_RET_CPLX16
+E(SP_V8_RET_CPLX16)
 	sth	%o0, [%i2+2]
 	b	9f
 	 srl	%o0, 16, %o0
-E SPARC_RET_INT64
+E(SPARC_RET_INT64)
 	st	%o0, [%i2]
 	st	%o1, [%i2+4]
 	ret
 	 restore
-E SPARC_RET_INT128
+E(SPARC_RET_INT128)
 	std	%o0, [%i2]
 	std	%o2, [%i2+8]
 	ret
 	 restore
-E SPARC_RET_F_8
+E(SPARC_RET_F_8)
 	st	%f7, [%i2+7*4]
 	nop
 	st	%f6, [%i2+6*4]
 	nop
-E SPARC_RET_F_6
+E(SPARC_RET_F_6)
 	st	%f5, [%i2+5*4]
 	nop
 	st	%f4, [%i2+4*4]
 	nop
-E SPARC_RET_F_4
+E(SPARC_RET_F_4)
 	st	%f3, [%i2+3*4]
 	nop
 	st	%f2, [%i2+2*4]
 	nop
-E SPARC_RET_F_2
+E(SPARC_RET_F_2)
 	st	%f1, [%i2+4]
 	st	%f0, [%i2]
 	ret
 	 restore
-E SP_V8_RET_CPLX8
+E(SP_V8_RET_CPLX8)
 	stb	%o0, [%i2+1]
 	b	10f
 	 srl	%o0, 8, %o0
-E SPARC_RET_F_1
+E(SPARC_RET_F_1)
 	st	%f0, [%i2]
 	ret
 	 restore
@@ -231,7 +236,9 @@ 2:
 
 	.align 8
 	.globl	C(ffi_go_closure_v8)
+#if !(defined(__sun__) && defined(__svr4__))
 	.type	C(ffi_go_closure_v8),@function
+#endif
 	FFI_HIDDEN(C(ffi_go_closure_v8))
 
 C(ffi_go_closure_v8):
@@ -249,7 +256,9 @@ C(ffi_go_closure_v8):
 
 	.align 8
 	.globl	C(ffi_closure_v8)
+#if !(defined(__sun__) && defined(__svr4__))
 	.type	C(ffi_closure_v8),@function
+#endif
 	FFI_HIDDEN(C(ffi_closure_v8))
 
 C(ffi_closure_v8):
@@ -285,70 +294,70 @@ 1:	sll	%o0, 4, %o0	! o0 = o0 * 16
 	! Note that each entry is 4 insns, enforced by the E macro.
 	.align	16
 2:
-E SPARC_RET_VOID
+E(SPARC_RET_VOID)
 	ret
 	 restor

Re: [COMMITTED] Merge libffi with upstream

2015-01-15 Thread H.J. Lu
On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
 wrote:
> Richard Henderson  writes:
>
>> Upstream libffi has added support for Go closures (using the static chain),
>> and support for complex numbers.  Perhaps less relevant is new support for
>> arc, microblaze, moxie, nios, and or1k targets.
>>
>> Without additional changes for Go, this merge has little effect.  Within the
>> gcc tree libffi is primarily used by libjava.
>>
>> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
>>
>> Due to upstream breakage, and difficulty debugging on Darwin,
>> {i686,x86_64}-darwin retains copies of the existing sources and thus remains
>> 100% unchanged.  Since libgo doesn't support darwin, this should cause no
>> immediate problems.
>
> The patch introduced massive problems on Solaris, both SPARC and x86:
>
> * on Solaris/SPARC, /bin/as requires
>
>   .type fn,#function
>
>   instead of @function.  I've simply commented the affected lines in
>   src/sparc/v[89].S to make progress.
>
> * /bin/as doesn't support .macro/.endm.  I'm using preprocessor macros
>   instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
>   unix64}.S.
>
> * Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
>   uses in src/x86/{sysv, unix64}.S, as on Darwin.
>
> * Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
>   the moment.
>
> * Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
>   generated .eh_frame sections match, otherwise libffi.so fails to link:
>
> ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file 
> src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and 
> cannot be merged into a single output section
>
> * Yet unfixed for Solaris/SPARC /bin/as:
>
> as: "v8.s", line 128: error: invalid digit in radix 10
>
>   as seems to only understand single-digit labels
>
> as: "v8.s", line 140: error: statement syntax
> as: "v8.s", line 157: error: unknown opcode ".rept"
> as: "v8.s", line 157: error: statement syntax
> as: "v8.s", line 163: error: unknown opcode ".endr"
> as: "v8.s", line 163: error: statement syntax
>
>   and knows nothing about .rept/.endr
>
> Here are the hacks I've used to make some progress:
>

I think we should

1.  Revert the libffi merge patch.
2.  Create a GCC integration branch from the merge commit
in libffi git repo
3.  Apply all GCC customization changes to the GCC integration
branch.
4. Copy the the GCC integration branch to gcc/libffi,  NOT the
unmodified libffi commit.


-- 
H.J.


Re: [PATCH] -fsanitize=vptr instrumentation (take 3)

2015-01-15 Thread Jason Merrill

OK, sorry for the delay.

Jason


Re: [testsuite] PATCH: Ignore additional messages on Linux/x86 with PIE

2015-01-15 Thread H.J. Lu
On Thu, Jan 15, 2015 at 8:30 AM, H.J. Lu  wrote:
> On Thu, Jan 15, 2015 at 8:24 AM, Mike Stump  wrote:
>> So, I was hoping that someone would step forward and review this.  I’d like 
>> for a reviewer to consider, is this the type of error messages we want to 
>> vend to the poor user?  It strikes me as, well, icky.  Should -fPIE imply 
>> -fPIC?
>
> It is an optimization:
>
> https://gcc.gnu.org/ml/gcc-cvs/2014-12/msg00206.html
>
> If linker supports copy reloc in PIE, we turn off PIC for the data access.
> Since the symbol is undefined in this case, linker complains.
>

FYI, I opened a linker bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=17847

I will suppress the second linker message.

-- 
H.J.


Re: [COMMITTED] Merge libffi with upstream

2015-01-15 Thread Richard Henderson
On 01/15/2015 08:40 AM, Rainer Orth wrote:
> The patch introduced massive problems on Solaris, both SPARC and x86:
> 
> * on Solaris/SPARC, /bin/as requires
> 
>   .type fn,#function
> 
>   instead of @function.  I've simply commented the affected lines in
>   src/sparc/v[89].S to make progress.
> 
> * /bin/as doesn't support .macro/.endm.  I'm using preprocessor macros
>   instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
>   unix64}.S.
> 
> * Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
>   uses in src/x86/{sysv, unix64}.S, as on Darwin.
> 
> * Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
>   the moment.

I hate old assemblers...

> * Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
>   generated .eh_frame sections match, otherwise libffi.so fails to link:

Fair enough, that's a simple error.

> as: "v8.s", line 128: error: invalid digit in radix 10
> 
>   as seems to only understand single-digit labels

Easy enough to work around, I guess.

> as: "v8.s", line 140: error: statement syntax
> as: "v8.s", line 157: error: unknown opcode ".rept"
> as: "v8.s", line 157: error: statement syntax
> as: "v8.s", line 163: error: unknown opcode ".endr"
> as: "v8.s", line 163: error: statement syntax
> 
>   and knows nothing about .rept/.endr

Ug.  More preprocessor magic, I guess.


r~



[PATCH] Fix PR64068 and PR64559

2015-01-15 Thread Martin Liška

Hello.

This is Honsa's patch that I've just tested on x86_64-linux-pc. The patch is 
preapproved by Honza
and is going to be installed.

Thanks,
Martin
>From 84b6878f168802516febfbd00252f56f965b9666 Mon Sep 17 00:00:00 2001
From: mliska 
Date: Thu, 15 Jan 2015 17:20:00 +0100
Subject: [PATCH] Fix for PR64068 and PR64559.

gcc/testsuite/ChangeLog:

2015-01-15  Martin Liska  

	* g++.dg/ipa/pr64068.C: New test.
	* gcc.dg/ipa/PR64559.c: New test.

gcc/ChangeLog:

2015-01-15  Jan Hubicka  

	PR ipa/64068
	PR ipa/64559
	* ipa.c (symbol_table::remove_unreachable_nodes):
	Do not put abstract origins into boundary.
---
 gcc/ipa.c  |  1 -
 gcc/testsuite/g++.dg/ipa/pr64068.C | 49 ++
 gcc/testsuite/gcc.dg/ipa/PR64559.c | 39 ++
 3 files changed, 88 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/ipa/pr64068.C
 create mode 100644 gcc/testsuite/gcc.dg/ipa/PR64559.c

diff --git a/gcc/ipa.c b/gcc/ipa.c
index df96515..3626417 100644
--- a/gcc/ipa.c
+++ b/gcc/ipa.c
@@ -400,7 +400,6 @@ symbol_table::remove_unreachable_nodes (FILE *file)
 		   n = n->next_sibling_clone)
 		if (n->decl == DECL_ABSTRACT_ORIGIN (node->decl))
 		  n->used_as_abstract_origin = true;
-	  enqueue_node (origin_node, &first, &reachable);
 		}
 	}
 	  /* If any symbol in a comdat group is reachable, force
diff --git a/gcc/testsuite/g++.dg/ipa/pr64068.C b/gcc/testsuite/g++.dg/ipa/pr64068.C
new file mode 100644
index 000..9528883
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr64068.C
@@ -0,0 +1,49 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+typedef int PROV_ENUMALGS_EX, PCCRYPT_OID_INFO;
+class A {
+  int m_fn2();
+  virtual bool m_fn1(PCCRYPT_OID_INFO);
+};
+int fn1();
+void fn2();
+int A::m_fn2() { m_fn1(0); }
+
+bool fn3() {
+  for (;;) {
+if (fn1()) {
+  if (fn1() != 259)
+fn2();
+  break;
+}
+return 1;
+  }
+  return 0;
+}
+
+class B {
+public:
+  B() { fn3(); }
+};
+class C : A {
+  bool m_fn1(PCCRYPT_OID_INFO) { m_fn3(); }
+  int isSupportedByProvider_algId;
+  PROV_ENUMALGS_EX isSupportedByProvider_outEnumAlgs;
+  PROV_ENUMALGS_EX isSupportedByProvider_enumAlgs;
+  bool m_fn3() {
+while (1) {
+  if (fn1()) {
+if (fn1() != 259)
+  fn2();
+break;
+  }
+  if (isSupportedByProvider_algId)
+isSupportedByProvider_outEnumAlgs = isSupportedByProvider_enumAlgs;
+  return 1;
+}
+return 0;
+  }
+};
+
+void fn4() { B(); }
diff --git a/gcc/testsuite/gcc.dg/ipa/PR64559.c b/gcc/testsuite/gcc.dg/ipa/PR64559.c
new file mode 100644
index 000..463afdc
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/PR64559.c
@@ -0,0 +1,39 @@
+/* { dg-do compile } */
+/* { dg-options "-Os"  } */
+
+int a, b, c, d;
+
+struct S
+{
+  int f0;
+};
+
+static int
+fn1 (int p)
+{
+  return p == 0 || a;
+}
+
+static int
+fn2 ()
+{
+  d = fn1 (c);
+  return 0;
+}
+
+static int
+fn3 (struct S p)
+{
+  p.f0 || fn2 ();
+  if (fn1 (1))
+b = 0;
+  return 0;
+}
+
+int
+main ()
+{
+  struct S e = { 1 };
+  fn3 (e);
+  return 0;
+}
-- 
2.1.2



Re: [PATCH, RFC] LRA subreg handling

2015-01-15 Thread Jeff Law

On 01/15/15 03:13, Robert Suchanek wrote:

Robert, can you look at reload.c::reload_inner_reg_of_subreg and verify
that the comment just before its return statement is effectively the
situation you're in.

There are certainly cases where a SUBREG needs to be treated as an
in-out operand.  We walked through them eons ago when we were poking at
SSA for RTL.  But the details have long since faded from memory.


The comment pretty much applies to my situation.  The only difference I can
see is that reload would have had hard registers at this point.  In the 
testcase,
LRA does not have hard registers assigned to the concerned pseudo(s), thus,
it can't rely on the information in hard_regno_nregs to check if the number of
registers in INNER is different to the number of words in INNER.
The differences (hard vs pseudo regs) are primarily an implementation 
detail.  I was really looking to see if there was existing code which 
would turn an output reload into an in-out reload for these subregs.


The in-out nature of certain subregs is something I've personally 
stumbled over in various contexts (for example, this also came up during 
RTL-SSA investigations years ago).


Jeff


Re: [PATCH] Avoid -Werror=format-security errors in libcpp

2015-01-15 Thread Jeff Law

On 01/15/15 04:19, Jakub Jelinek wrote:

Hi!

With the addition of build libcpp, my build failed because of distro default
flags of -Werror=format-security.

The first hunk is I think no big deal, making it const makes the warning
go away.

The second hunk is more controversial, as even making message const doesn't
help with the warning.  There is another option of using "%s" and
_( instead of N_ in message, or just keep it as is and I can keep the second
hunk as local hack.

Thoughts on this?

2015-01-15  Jakub Jelinek  

* macro.c (create_iso_definition): Make paste_op_error_msg var
const.
* expr.c (cpp_classify_number): Avoid -Wformat-security warning.

I'd go with the patch as-is.  Approved.

jeff


--- libcpp/macro.c.jj   2015-01-14 11:01:34.0 +0100
+++ libcpp/macro.c  2015-01-14 14:22:19.286949884 +0100
@@ -2947,7 +2947,7 @@ create_iso_definition (cpp_reader *pfile
cpp_token *token;
const cpp_token *ctoken;
bool following_paste_op = false;
-  const char *paste_op_error_msg =
+  const char *const paste_op_error_msg =
  N_("'##' cannot appear at either end of a macro expansion");
unsigned int num_extra_tokens = 0;

--- libcpp/expr.c.jj2015-01-14 11:01:34.0 +0100
+++ libcpp/expr.c   2015-01-14 14:35:52.851002344 +0100
@@ -672,16 +672,17 @@ cpp_classify_number (cpp_reader *pfile,
if ((result & CPP_N_WIDTH) == CPP_N_LARGE
  && CPP_OPTION (pfile, cpp_warn_long_long))
  {
-  const char *message = CPP_OPTION (pfile, cplusplus)
-   ? N_("use of C++11 long long integer constant")
-   : N_("use of C99 long long integer constant");
-
  if (CPP_OPTION (pfile, c99))
  cpp_warning_with_line (pfile, CPP_W_LONG_LONG, virtual_location,
-  0, message);
+  0, CPP_OPTION (pfile, cplusplus)
+ ? "use of C++11 long long integer 
constant"
+ : "use of C99 long long integer 
constant");
else
  cpp_pedwarning_with_line (pfile, CPP_W_LONG_LONG,
- virtual_location, 0, message);
+ virtual_location, 0,
+ CPP_OPTION (pfile, cplusplus)
+ ? "use of C++11 long long integer 
constant"
+ : "use of C99 long long integer 
constant");
  }

result |= CPP_N_INTEGER;


Jakub





Re: [testsuite] Fix plugin test for bareboard ports

2015-01-15 Thread Mike Stump
On Jan 15, 2015, at 7:28 AM, Eric Botcazou  wrote:
> The attached patch fixes it by ensuring that LTO_TORTURE_OPTIONS is computed 
> after set_ld_library_path_env_vars is invoked (this procedure invokes in turn 
> set_gcc_exec_prefix_env_var), both in c-torture.exp and in gcc-dg.exp.

> OK for the mainline?

Ok.  Watch for fallout and/or comments from lto people.

Re: [PATCH] Fix PR testsuite/64605

2015-01-15 Thread Mike Stump
On Jan 15, 2015, at 8:14 AM, Ilya Verbin  wrote:
> The problem is that gcc-dg.exp calls check_effective_target_lto, which calls
> libatomic_target_compile.  Therefore gcc-dg.exp should be loaded only after 
> the
> definition of libatomic_target_compile.

> However, a similar exp file in other tree (libitm/testsuite/lib/libitm.exp)
> doesn't contain any explicit 'load_gcc_lib gcc-dg.exp' at all, but it loads
> gcc-dg.exp implicitly.  So I'm not sure whether this patch is correct.

So, can you try the itm version of this?  If that works, Ok.

Re: [COMMITTED] Merge libffi with upstream

2015-01-15 Thread Richard Henderson
On 01/15/2015 08:54 AM, H.J. Lu wrote:
> On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
>  wrote:
>> Richard Henderson  writes:
>>
>>> Upstream libffi has added support for Go closures (using the static chain),
>>> and support for complex numbers.  Perhaps less relevant is new support for
>>> arc, microblaze, moxie, nios, and or1k targets.
>>>
>>> Without additional changes for Go, this merge has little effect.  Within the
>>> gcc tree libffi is primarily used by libjava.
>>>
>>> Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
>>>
>>> Due to upstream breakage, and difficulty debugging on Darwin,
>>> {i686,x86_64}-darwin retains copies of the existing sources and thus remains
>>> 100% unchanged.  Since libgo doesn't support darwin, this should cause no
>>> immediate problems.
>>
>> The patch introduced massive problems on Solaris, both SPARC and x86:
>>
>> * on Solaris/SPARC, /bin/as requires
>>
>>   .type fn,#function
>>
>>   instead of @function.  I've simply commented the affected lines in
>>   src/sparc/v[89].S to make progress.
>>
>> * /bin/as doesn't support .macro/.endm.  I'm using preprocessor macros
>>   instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
>>   unix64}.S.
>>
>> * Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
>>   uses in src/x86/{sysv, unix64}.S, as on Darwin.
>>
>> * Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
>>   the moment.
>>
>> * Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
>>   generated .eh_frame sections match, otherwise libffi.so fails to link:
>>
>> ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file 
>> src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and 
>> cannot be merged into a single output section
>>
>> * Yet unfixed for Solaris/SPARC /bin/as:
>>
>> as: "v8.s", line 128: error: invalid digit in radix 10
>>
>>   as seems to only understand single-digit labels
>>
>> as: "v8.s", line 140: error: statement syntax
>> as: "v8.s", line 157: error: unknown opcode ".rept"
>> as: "v8.s", line 157: error: statement syntax
>> as: "v8.s", line 163: error: unknown opcode ".endr"
>> as: "v8.s", line 163: error: statement syntax
>>
>>   and knows nothing about .rept/.endr
>>
>> Here are the hacks I've used to make some progress:
>>
> 
> I think we should
> 
> 1.  Revert the libffi merge patch.
> 2.  Create a GCC integration branch from the merge commit
> in libffi git repo

How's that going to help?  The build infrastructure is totally different.
That and the fact that extremely few people test upstream libffi.

> 4. Copy the the GCC integration branch to gcc/libffi,  NOT the
> unmodified libffi commit.

I beg your pardon?


r~



Re: libgo patch committed: Update to Go 1.4

2015-01-15 Thread Jakub Jelinek
On Thu, Jan 15, 2015 at 01:58:43PM +0100, Richard Biener wrote:
> [ 5286s] ../../../libgo/go/reflect/makefuncgo_s390x.go:323:5: error: expected 
> ';
> ' or '}' or newline
> [ 5286s]} else {
> [ 5286s]  ^

Bet that
} else {
line should have been replaced with
default:

Jakub


Re: [PATCH] Fix PR testsuite/64605

2015-01-15 Thread Ilya Verbin
On 15 Jan 09:40, Mike Stump wrote:
> On Jan 15, 2015, at 8:14 AM, Ilya Verbin  wrote:
> > The problem is that gcc-dg.exp calls check_effective_target_lto, which calls
> > libatomic_target_compile.  Therefore gcc-dg.exp should be loaded only after 
> > the
> > definition of libatomic_target_compile.
> 
> > However, a similar exp file in other tree (libitm/testsuite/lib/libitm.exp)
> > doesn't contain any explicit 'load_gcc_lib gcc-dg.exp' at all, but it loads
> > gcc-dg.exp implicitly.  So I'm not sure whether this patch is correct.
> 
> So, can you try the itm version of this?  If that works, Ok.

If I just remove 'load_gcc_lib gcc-dg.exp' from libatomic.exp, like this is done
in libitm.exp, it will not work:

$ make check-target-libatomic
...
ERROR: (DejaGnu) proc "gcc-dg-test-1 libatomic_target_compile 
../../../../gcc/libatomic/testsuite/libatomic.c/atomic-compare-exchange-1.c run 
{ -g}" does not exist.

Note that gcc-dg-test-1 is defined in gcc-dg.exp, so it's somehow automatically
loaded for libitm and other libs, but non loaded for libatomic.

  -- Ilya


Re: [COMMITTED] Merge libffi with upstream

2015-01-15 Thread H.J. Lu
On Thu, Jan 15, 2015 at 9:19 AM, Richard Henderson  wrote:
> On 01/15/2015 08:54 AM, H.J. Lu wrote:
>> On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
>>  wrote:
>>> Richard Henderson  writes:
>>>
 Upstream libffi has added support for Go closures (using the static chain),
 and support for complex numbers.  Perhaps less relevant is new support for
 arc, microblaze, moxie, nios, and or1k targets.

 Without additional changes for Go, this merge has little effect.  Within 
 the
 gcc tree libffi is primarily used by libjava.

 Tested with no regressions on 
 {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.

 Due to upstream breakage, and difficulty debugging on Darwin,
 {i686,x86_64}-darwin retains copies of the existing sources and thus 
 remains
 100% unchanged.  Since libgo doesn't support darwin, this should cause no
 immediate problems.
>>>
>>> The patch introduced massive problems on Solaris, both SPARC and x86:
>>>
>>> * on Solaris/SPARC, /bin/as requires
>>>
>>>   .type fn,#function
>>>
>>>   instead of @function.  I've simply commented the affected lines in
>>>   src/sparc/v[89].S to make progress.
>>>
>>> * /bin/as doesn't support .macro/.endm.  I'm using preprocessor macros
>>>   instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
>>>   unix64}.S.
>>>
>>> * Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
>>>   uses in src/x86/{sysv, unix64}.S, as on Darwin.
>>>
>>> * Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
>>>   the moment.
>>>
>>> * Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
>>>   generated .eh_frame sections match, otherwise libffi.so fails to link:
>>>
>>> ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file 
>>> src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes 
>>> and cannot be merged into a single output section
>>>
>>> * Yet unfixed for Solaris/SPARC /bin/as:
>>>
>>> as: "v8.s", line 128: error: invalid digit in radix 10
>>>
>>>   as seems to only understand single-digit labels
>>>
>>> as: "v8.s", line 140: error: statement syntax
>>> as: "v8.s", line 157: error: unknown opcode ".rept"
>>> as: "v8.s", line 157: error: statement syntax
>>> as: "v8.s", line 163: error: unknown opcode ".endr"
>>> as: "v8.s", line 163: error: statement syntax
>>>
>>>   and knows nothing about .rept/.endr
>>>
>>> Here are the hacks I've used to make some progress:
>>>
>>
>> I think we should
>>
>> 1.  Revert the libffi merge patch.
>> 2.  Create a GCC integration branch from the merge commit
>> in libffi git repo
>
> How's that going to help?  The build infrastructure is totally different.
> That and the fact that extremely few people test upstream libffi.

It is to make sure that all GCC customization changes don't
get lost when merging with upstream.  I am willing to work on
this and create a GCC patch to combine steps 1-4.

>> 4. Copy the the GCC integration branch to gcc/libffi,  NOT the
>> unmodified libffi commit.
>
> I beg your pardon?
>
>
> r~
>



-- 
H.J.


Re: PATCH: PR libitm/64360: libitm.c/stackundo.c fails with -fpic

2015-01-15 Thread Jeff Law

On 01/15/15 05:23, H.J. Lu wrote:

Hi,

libitm.c/stackundo.c fails with -fpic since test1 and test2 may be
preempted with -fpic.  This patch makes those 2 functions static.
Tested on Linux/x86.  OK for trunk?

Thanks.


H.J.

diff --git a/libitm/ChangeLog b/libitm/ChangeLog
index 74e2940..e46819c 100644
--- a/libitm/ChangeLog
+++ b/libitm/ChangeLog
@@ -1,3 +1,9 @@
+2015-01-15  H.J. Lu  
+
+   PR libitm/64360
+   * libitm.c/stackundo.c (test2): Make it static.
+   (test1): Likewise.

OK.
Jeff



Re: [PATCH] Reenable CSE of non-volatile inline asm (PR rtl-optimization/63637)

2015-01-15 Thread Jeff Law

On 01/15/15 01:13, Jakub Jelinek wrote:


The glibc barriers are supposedly something that can be CSEd (one barrier 
instead of
two consecutive barriers is enough), but certainly not moved across any 
loads/stores
in between.  In the kernel case, the enable/disable probably wouldn't allow 
even CSE.

So I'm with Jeff that we should treat "memory" at least as unspecified read and 
write,
and whether we can CSE them if there are no memory loads/stores in between them 
can
be discussed (most likely the kernel would be safe even in that case, because 
those
usually don't nest and appear in pairs, or act as barriers (like the glibc 
case),
or read from segment registers (guess again ok to be CSEd with no intervening 
loads/stores).

In 4.9 backport I'd prefer not to CSE them at all though, stay conservative.
My vote would be to go conservative.  For gcc6 consider allowing a 
"memory" tag in the inputs and outputs to specify a read of any memory 
location and write of any memory location respectively.  A "memory" tag 
in the clobbers would maintain the conservative behaviour.


jeff


Re: [PATCH] IPA ICF: add comparison for target and optimization nodes

2015-01-15 Thread Jeff Law

On 01/15/15 09:20, Rainer Orth wrote:

Martin Liška  writes:


On 01/07/2015 12:38 PM, Martin Liška wrote:

Hello.

Following patch adds support for target and optimization nodes
comparison, which is
based on Honza's newly added infrastructure.

Apart from that, there's a small hunk that corrects formatting and
removes unnecessary
call to a comparison function.

Hope it can be applied as one patch.

Tested on x86_64-linux-pc without any new regression introduction.

Ready for trunk?

Thank you,
Martin


Hello.

Apart from the previous patch, I would like to install following patch
which introduces
new dump functions related to target and optimization nodes. These
functions dump just
different flags.

Patch has been tested on x86_64-linux-pc.


Unfortunately, this patch breaks Solaris/SPARC bootstrap:

options-save.c:3267:34: error: unused parameter 'indent' 
[-Werror=unused-parameter]
   int indent,
   ^
options-save.c:3268:55: error: unused parameter 'ptr1' 
[-Werror=unused-parameter]
   struct cl_target_option *ptr1,
^
options-save.c:3269:55: error: unused parameter 'ptr2' 
[-Werror=unused-parameter]
   struct cl_target_option *ptr2)
^

The following patch fixes this and allow the bootstrap to continue.

2015-01-15  Rainer Orth  

* optc-save-gen.awk (cl_target_option_print_diff): Mark indent,
ptr1, ptr2 unused.




Ok for mainline?

OK.
jeff



Re: [PATCH, AARCH64] Fix ICE in CCMP (PR64015)

2015-01-15 Thread Richard Henderson
On 12/15/2014 12:41 AM, Zhenqiang Chen wrote:
> +(define_expand "cmp"
> +  [(set (match_operand 0 "cc_register" "")
> +(match_operator:CC 1 "aarch64_comparison_operator"
> + [(match_operand:GPI 2 "register_operand" "")
> +  (match_operand:GPI 3 "aarch64_plus_operand" "")]))]
> +  ""
> +  "
> +  operands[1] = gen_rtx_fmt_ee (COMPARE, SELECT_CC_MODE (GET_CODE 
> (operands[1]),
> +  operands[2],
> +  operands[3]),
> +  operands[2], operands[3]);
> +  "
> +)

Use { } not "" for the C portion.

Otherwise ok.


r~


Re: [Patch] Missing plugin header files

2015-01-15 Thread Prathamesh Kulkarni
On 15 January 2015 at 14:14, Richard Biener  wrote:
> On Wed, Jan 14, 2015 at 10:43 PM, Steve Ellcey  wrote:
>> I tried compiling an empty plugin that just included gcc-plugin.h and
>> plugin-version.h and found that these header files were included from
>> gcc-plugin.h but not in the list of header files to be copied to the
>> plugin include directory.
>>
>> OK to checkin?
>
> Ok.
>
> Thanks,
> Richard.
>
>> Steve Ellcey
>> sell...@imgtec.com
>>
>> 2015-01-14  Steve Ellcey  
>>
>> * Makefile.in (PLUGIN_HEADERS): Add dominance.h, cfg.h, cfgrtl.h,
>> cfganal.h, cfgbuild.h, cfgcleanup.h, lcm.h, builtins.def,
>> chkp-builtins.def, and pass-instances.def
>>
Should pass-instances.def be removed from ChangeLog since it was
already present in PLUGIN_HEADERS ?

Thanks,
Prathamesh
>>
>> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
>> index 44a4214..abe2d0d 100644
>> --- a/gcc/Makefile.in
>> +++ b/gcc/Makefile.in
>> @@ -3228,7 +3228,8 @@ PLUGIN_HEADERS = $(TREE_H) $(CONFIG_H) $(SYSTEM_H) 
>> coretypes.h $(TM_H) \
>>tree-ssa-loop.h tree-ssa-loop-ivopts.h tree-ssa-loop-manip.h \
>>tree-ssa-loop-niter.h tree-ssa-ter.h tree-ssa-threadedge.h \
>>tree-ssa-threadupdate.h inchash.h wide-int.h signop.h hash-map.h \
>> -  hash-set.h pass-instances.def
>> +  hash-set.h dominance.h cfg.h cfgrtl.h cfganal.h cfgbuild.h cfgcleanup.h \
>> +  lcm.h builtins.def chkp-builtins.def pass-instances.def
>>
>>  # generate the 'build fragment' b-header-vars
>>  s-header-vars: Makefile


Re: C++ PATCH for c++/64356 and libstdc++/58777 (constexpr pointer arithmetic)

2015-01-15 Thread Jason Merrill

Oops, got a bit excessive with the copy/paste.

commit 4203eda52ae9eefc618d3819a3c468841bf2910b
Author: Jason Merrill 
Date:   Wed Jan 14 23:58:50 2015 -0500

	PR c++/64356
	* constexpr.c (cxx_eval_binary_expression): Fix pasto.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index e27a892..943ecbf 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1624,7 +1624,7 @@ cxx_eval_binary_expression (const constexpr_ctx *ctx, tree t,
   rhs = cxx_eval_constant_expression (ctx, orig_rhs, /*lval*/false,
   non_constant_p, overflow_p);
   if (!ptr)
-VERIFY_CONSTANT (lhs);
+VERIFY_CONSTANT (rhs);
 
   location_t loc = EXPR_LOCATION (t);
   enum tree_code code = TREE_CODE (t);
@@ -1640,7 +1640,7 @@ cxx_eval_binary_expression (const constexpr_ctx *ctx, tree t,
   else if (cxx_eval_check_shift_p (loc, ctx, code, type, lhs, rhs))
 *non_constant_p = true;
   if (!ptr)
-VERIFY_CONSTANT (lhs);
+VERIFY_CONSTANT (r);
   return r;
 }
 


Re: [PATCH/expand] PR64011 Adjust bitsize when partial overflow happen for big-endian

2015-01-15 Thread Jeff Law

On 01/15/15 09:27, Jiong Wang wrote:


On 15/01/15 03:51, Jeff Law wrote:

On 01/14/15 15:31, Jiong Wang wrote:

agree, and I think the truncation is needed otherwise there may have ICE
on some target.

and I found current gcc LOCATION info is very good !
have done an experimental hack on at "expand_assignment": 4931 where the
tree is expanded,
gcc could give quite useful & accurate warning based on tree LOCATION
info.

./cc1 -O2 -mbig-endian pr48335-2.c

pr48335-2.c: In function ‘f5’:
pr48335-2.c:19:29: warning: overflow here !
 ((U *)((char *) &s.d + 1))[3] = x;
   ^

while we need to add warning at store_bit_field_using_insv where
there is no accurate LOCATION info. but looks like it's acceptable?

pr48335-2.c:19:33: warning: overflow here !
 ((U *)((char *) &s.d + 1))[3] = x;
   ^

Yes, I think we're on the right track now -- warn and truncate the the
insertion.

I just scanned our set of warning flags to see if this would fit nicely
under any of the existing flags, and it doesn't.  I guess putting it
under -Wextra is probably best for now.

I think the warning text should indicate that the statement will write
outside the bounds of the destination object or something along those
lines.


thanks for suggestions. patch updated

the warning message is as the following:

./cc1 -O2 pr48335-2.c -Wextra

pr48335-2.c: In function ‘f5’:
pr48335-2.c:19:33: warning: write of 16bit data outside the bound of
destination object, data truncated into 8bit [-Wextra]
((U *)((char *) &s.d + 1))[3] = x;
  ^
x86-64 bootstrap & regress ok.

ok for trunk?

one other thing is I found using of "insv" maybe sub-optimal in some
situation.
for example, even before my patch, modify type of U to char so there is
no overflow.

use BFI will cost one more fmov (cc1 -O2 test.c), maybe this is caused
by bfi only
support integer type, which may cause extra reg copy when there are both
float & int type.

// comment out the "if (maybe_expand_insn" in store_bit_field_using_insv
// to fall back to other code path
f5:
 uxtbw0, w0
 stp x29, x30, [sp, -16]!
 fmovs0, wzr
 fmovs1, w0
 add x29, sp, 0
 bl  bar
 ldp x29, x30, [sp], 16
 ret

// BFI version
f5:
 fmovs0, wzr
 stp x29, x30, [sp, -16]!
 add x29, sp, 0
 fmovw1, s0
 bfi w1, w0, 0, 8
 fmovs1, w1
 bl  bar
 ldp x29, x30, [sp], 16
 ret


Thanks.

gcc/
 PR64011
 * expmed.c (store_bit_field_using_insv): Warn and truncate bitsize
when there is partial overflow.

OK for the trunk.   Please install.

Thanks,
Jeff



Rename unroll_[1-5].c

2015-01-15 Thread Mike Stump
So, I wanted to add some unrolling test cases and found that we had unroll-1.c 
and unroll_[1-5].c.  :-(  - is the standard, and picking numbers sequential 
from 1, with a - before the number is standard.  No reason to deviate in this 
case.  I’ve fixed this by renaming the test cases like so:

* gcc.dg/unroll_1.c: Rename gcc.dg/unroll_[1-5].c to unroll-[2-6].
* gcc.dg/unroll_2.c: Likewise.
* gcc.dg/unroll_3.c: Likewise.
* gcc.dg/unroll_4.c: Likewise.
* gcc.dg/unroll_5.c: Likewise.


Re: [Patch] Missing plugin header files

2015-01-15 Thread Steve Ellcey

> >>
> >> 2015-01-14  Steve Ellcey  
> >>
> >> * Makefile.in (PLUGIN_HEADERS): Add dominance.h, cfg.h, cfgrtl.h,
> >> cfganal.h, cfgbuild.h, cfgcleanup.h, lcm.h, builtins.def,
> >> chkp-builtins.def, and pass-instances.def
> >>
> Should pass-instances.def be removed from ChangeLog since it was
> already present in PLUGIN_HEADERS ?
> 
> Thanks,
> Prathamesh

Looks like a cut-n-paste error on my part when I copied the file names
from Makefile.in to ChangeLog.  I will fix the ChangeLog entry.

Steve Ellcey



Re: [Patch, Fortran, F03] PR 58023: ICE on invalid with bad PPC declaration

2015-01-15 Thread Janus Weil
2015-01-15 14:22 GMT+01:00 Mikael Morin :
 the attached patch fixes an ICE-on-invalid problem with
 procedure-pointer components by making sure that we continue resolving
 all components of a derived type, even after an error is thrown.

>>> Does the fonction return false as before, whenever an error has been
>>> issued?  I have the feeling it doesn't any more with the patch.
>>
>> yeah, you're right. The attached new version fixes that. Better?
>>
> Yes, OK. Thanks.

Committed as r219676. Thanks for reviewing!

Cheers,
Janus


Re: [PATCH] Disable -fuse-caller-save when -pg is active

2015-01-15 Thread Jeff Law

On 01/05/15 21:01, Hans-Peter Nilsson wrote:

On Fri, 14 Nov 2014, Radovan Obradovic wrote:

index eb37bfe..ddaf8e0 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c



@@ -1605,6 +1612,11 @@ process_options (void)
/* Save the current optimization options.  */
optimization_default_node = build_optimization_node (&global_options);
optimization_current_node = optimization_default_node;
+
+  /* Disable use caller save optimization if profiler is active or port
+ does not emit prologue and epilogue as RTL.  */
+  if (profile_flag || !HAVE_prologue || !HAVE_epilogue)
+flag_use_caller_save = 0;
  }


This seems wrong.  Why disable caller-save regardless of
profile_flag; is there some long-standing bug in caller-save for
"old" targets?
It's actually -fipa-ra, use-caller-save was the initial name for the 
option and everyone agreed it was poorly named.


The problem is that with -fipa-ra we analyze the generated RTL to 
determine register usage.  We later use that information to optimize 
register allocation in callers.


That works fine and good except for cases where we're emitting code 
textually rather than via RTL.  That happens with profiling, textual 
prologue or textual epilogue.  Thus the test is correct.


Jeff


Re: Another ptx offloading patch

2015-01-15 Thread Jeff Law

On 11/20/14 05:33, Bernd Schmidt wrote:

Now that I've managed to put together and test all the submitted OpenACC
patches I found there was one piece missing. The problem is that omp-low
on the host likes to generate function names like "_main._omp_fn". On
ptx, the dot is not allowed in identifiers, so we have to rewrite this
to use a dollar sign.

The patch below does this at the lto-read stage. Bootstrapped on
x86_64-linux, ok if testing is successful?
Was expecting Richi or Honza to review this...  They certainly know the 
LTO bits far better than I.  Or have you ultimately addressed this issue 
some other way?


jeff



Rename gcc.dg/inline_[1-4].c

2015-01-15 Thread Mike Stump
Similar to the unroll_1.c change.

* gcc.dg/inline_1.c: Rename gcc.dg/inline_[1-4].c to inline-3[6-9].c.
* gcc.dg/inline_2.c: Likewise.
* gcc.dg/inline_3.c: Likewise.
* gcc.dg/inline_4.c: Likewise.



Fix ARM bootstrap - xgene tune params

2015-01-15 Thread Richard Earnshaw
The recent xgene tuning parameters merge broke the ARM bootstrap, since
the tables have been extended by an additional parameter giving:

gcc/config/arm/arm.c:1932:1: error: missing initializer for member
'tune_params::fuseable_ops' [-Werror=missing-field-initializers]
 };
 ^


Fixed as below.  I've no idea if this is the optimial behaviour for
Xgene parts, but it preserves the previous behaviour of the compiler
before this pass was added.  I'll let those who really know decide
whether a more comprehensive change is needed.

R.

2015-01-15  Richard Earnshaw  

* arm.c (arm_xgene_tune): Add default initializer for instruction
fusion.diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index a2cce8e..c106843 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -1928,7 +1928,8 @@ const struct tune_params arm_xgene1_tune =
   false,   /* Prefer Neon for 64-bits 
bitops.  */
   true, true,  /* Prefer 32-bit encodings.  */
   false,  /* Prefer Neon for stringops.  */
-  32  /* Maximum insns to inline 
memset.  */
+  32, /* Maximum insns to inline 
memset.  */
+  ARM_FUSE_NOTHING /* Fuseable pairs of 
instructions.  */
 };
 
 /* Branches can be dual-issued on Cortex-A5, so conditional execution is

Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

2015-01-15 Thread Ilya Verbin
On 22 Dec 13:35, Jakub Jelinek wrote:
> On Mon, Dec 22, 2014 at 12:48:08PM +0100, Thomas Schwinge wrote:
> > In my understanding, we'd like to support the modes that either all
> > compilers are installed (which is what a user will be using), or all are
> > tested from their build trees.  Or, do we also have to support the mode
> > that only the offloading compilers are installed, but the target
> > (offloading host) compiler is not?  (Doesn't make much sense to me.)
> 
> All 3 of these, yes.
> The nothing is installed yet mode supposedly doesn't work properly on the
> trunk yet (and is what I'd like to use e.g. in distro rpm builds), the 
> offloading
> compilers installed, host is not is useful that you actually test the host 
> compiler
> before installing, and that supposedly works on the trunk, the all installed 
> testing
> I've never used myself, but some people are using it.

This patch enables 'make check-target-libgomp' with noninstalled offloading
compilers.  It creates gcc/accel// directory in the build tree of the
offloading compiler, this allows lto-wrapper to find corresponding mkoffload in
case if there is more than one offloading compiler.  Is this approach ok?
I don't like changes in config.gcc and t-intelmic, probably there is a better
way to create a link?


diff --git a/gcc/config.gcc b/gcc/config.gcc
index 0dfc08f..76eef6f 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4369,7 +4369,7 @@ fi
 case ${target} in
 i[34567]86-*-* | x86_64-*-*)
if test x$enable_as_accelerator = xyes; then
-   extra_programs="mkoffload\$(exeext)"
+   extra_programs="mkoffload\$(exeext) 
accel/${target_noncanonical}/mkoffload$(exeext)"
fi
;;
 esac
diff --git a/gcc/config/i386/intelmic-mkoffload.c 
b/gcc/config/i386/intelmic-mkoffload.c
index 8e490ff..41807cf 100644
--- a/gcc/config/i386/intelmic-mkoffload.c
+++ b/gcc/config/i386/intelmic-mkoffload.c
@@ -45,6 +45,11 @@ const char *temp_files[MAX_NUM_TEMPS];
 /* Shows if we should compile binaries for i386 instead of x86-64.  */
 bool target_ilp32 = false;
 
+/* An optional prefix for the target compiler, which is required when target
+   compiler is not installed.  */
+char *optional_target_path = NULL;
+
+
 /* Delete tempfiles and exit function.  */
 void
 tool_cleanup (bool from_signal ATTRIBUTE_UNUSED)
@@ -151,14 +156,18 @@ access_check (const char *name, int mode)
   return access (name, mode);
 }
 
-/* Find target compiler using a path from COLLECT_GCC or COMPILER_PATH.  */
+/* Find target compiler using a path from COLLECT_GCC, COMPILER_PATH, or a path
+   relative to ARGV0.  */
 static char *
-find_target_compiler (const char *name)
+find_target_compiler (const char *argv0)
 {
   bool found = false;
   char **paths = NULL;
   unsigned n_paths, i;
+  const char *current_path;
   const char *collect_path = dirname (ASTRDUP (getenv ("COLLECT_GCC")));
+  const char *name
+= DEFAULT_REAL_TARGET_MACHINE "-accel-" DEFAULT_TARGET_MACHINE "-gcc";
   size_t len = strlen (collect_path) + 1 + strlen (name) + 1;
   char *target_compiler = XNEWVEC (char, len);
   sprintf (target_compiler, "%s/%s", collect_path, name);
@@ -177,13 +186,28 @@ find_target_compiler (const char *name)
   if (access_check (target_compiler, X_OK) == 0)
{
  found = true;
- break;
+ goto out;
}
 }
 
+  /* If installed compiler wasn't found, try to find a non-installed compiler,
+ using a path relative to mkoffload.  */
+  current_path = dirname (ASTRDUP (argv0));
+  len = strlen (current_path) + sizeof ("/../../") - 1;
+  target_compiler = XRESIZEVEC (char, target_compiler, len + sizeof ("xgcc"));
+  sprintf (target_compiler, "%s/../../xgcc", current_path);
+  if (access_check (target_compiler, X_OK) == 0)
+{
+  optional_target_path = XNEWVEC (char, len + sizeof ("-B"));
+  sprintf (optional_target_path, "-B%s/../../", current_path);
+  found = true;
+}
+
 out:
   free_array_of_ptrs ((void **) paths, n_paths);
-  return found ? target_compiler : NULL;
+  if (!found)
+fatal_error ("offload compiler %s not found", name);
+  return target_compiler;
 }
 
 static void
@@ -193,6 +217,10 @@ compile_for_target (struct obstack *argv_obstack)
 obstack_ptr_grow (argv_obstack, "-m32");
   else
 obstack_ptr_grow (argv_obstack, "-m64");
+
+  if (optional_target_path)
+obstack_ptr_grow (argv_obstack, optional_target_path);
+
   obstack_ptr_grow (argv_obstack, NULL);
   char **argv = XOBFINISH (argv_obstack, char **);
 
@@ -492,11 +520,7 @@ main (int argc, char **argv)
   if (!host_compiler)
 fatal_error ("COLLECT_GCC must be set");
 
-  const char *target_driver_name
-= DEFAULT_REAL_TARGET_MACHINE "-accel-" DEFAULT_TARGET_MACHINE "-gcc";
-  char *target_compiler = find_target_compiler (target_driver_name);
-  if (target_compiler == NULL)
-fatal_error ("offload compiler %s not found", target_driver_name);
+  char *target_compiler = find_target_compiler (a

Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing

2015-01-15 Thread Jakub Jelinek
On Thu, Jan 15, 2015 at 09:55:40PM +0300, Ilya Verbin wrote:
> This patch enables 'make check-target-libgomp' with noninstalled offloading
> compilers.  It creates gcc/accel// directory in the build tree of the
> offloading compiler, this allows lto-wrapper to find corresponding mkoffload 
> in
> case if there is more than one offloading compiler.  Is this approach ok?
> I don't like changes in config.gcc and t-intelmic, probably there is a better
> way to create a link?

Let's wait until Thomas hopefully checks in the OpenACC merge in order not
to make him work even harder.
I'll look at your patch afterwards.

Jakub


Re: [Patch] Missing plugin header files

2015-01-15 Thread Prathamesh Kulkarni
On 16 January 2015 at 00:00, Steve Ellcey  wrote:
>
>> >>
>> >> 2015-01-14  Steve Ellcey  
>> >>
>> >> * Makefile.in (PLUGIN_HEADERS): Add dominance.h, cfg.h, cfgrtl.h,
>> >> cfganal.h, cfgbuild.h, cfgcleanup.h, lcm.h, builtins.def,
>> >> chkp-builtins.def, and pass-instances.def
>> >>
>> Should pass-instances.def be removed from ChangeLog since it was
>> already present in PLUGIN_HEADERS ?
>>
>> Thanks,
>> Prathamesh
>
> Looks like a cut-n-paste error on my part when I copied the file names
> from Makefile.in to ChangeLog.  I will fix the ChangeLog entry.
Thanks for the patch, I missed to put headers in PLUGIN_HEADERS
after putting includes in gcc-plugin.h. -:(

Regards,
Prathamesh
>
> Steve Ellcey
>


Re: [PATCH] Fix PR testsuite/64605

2015-01-15 Thread Mike Stump
On Jan 15, 2015, at 9:53 AM, Ilya Verbin  wrote:
> If I just remove 'load_gcc_lib gcc-dg.exp' from libatomic.exp, like this is 
> done
> in libitm.exp, it will not work:

Ok, original patch is fine.

Re: Fix ARM bootstrap - xgene tune params

2015-01-15 Thread Dr. Philipp Tomsich
Richard,

Thanks for catching this.
Your change is optimal for X-Gene 1.

—Phil.

> On 15 Jan 2015, at 19:51, Richard Earnshaw  wrote:
> 
> The recent xgene tuning parameters merge broke the ARM bootstrap, since
> the tables have been extended by an additional parameter giving:
> 
> gcc/config/arm/arm.c:1932:1: error: missing initializer for member
> 'tune_params::fuseable_ops' [-Werror=missing-field-initializers]
> };
> ^
> 
> 
> Fixed as below.  I've no idea if this is the optimial behaviour for
> Xgene parts, but it preserves the previous behaviour of the compiler
> before this pass was added.  I'll let those who really know decide
> whether a more comprehensive change is needed.
> 
> R.
> 
> 2015-01-15  Richard Earnshaw  
> 
>   * arm.c (arm_xgene_tune): Add default initializer for instruction
>   fusion.



[PATCH, committed] remove duplicate contents explow.h, dojump.h

2015-01-15 Thread Prathamesh Kulkarni
r219655 added two files explow.h, dojump.h with duplicated contents,
silly mistake from my side. The attached patch removes duplicate
contents. Committed (r219680) as obvious.

Thanks,
Prathamesh
2015-01-15  Prathamesh Kulkarni  

* explow.h: Remove duplicate contents.
* dojump.h: Likewise.
Index: gcc/dojump.h
===
--- gcc/dojump.h	(revision 219679)
+++ gcc/dojump.h	(working copy)
@@ -76,159 +76,3 @@
 			  enum rtx_code *, enum rtx_code *);
 
 #endif /* GCC_DOJUMP_H */
-/* Export function prototypes from dojump.c.
-   Copyright (C) 2015-2016 Free Software Foundation, Inc.
-
-This file is part of GCC.
-
-GCC is free software; you can redistribute it and/or modify it under
-the terms of the GNU General Public License as published by the Free
-Software Foundation; either version 3, or (at your option) any later
-version.
-
-GCC is distributed in the hope that it will be useful, but WITHOUT ANY
-WARRANTY; without even the implied warranty of MERCHANTABILITY or
-FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
-for more details.
-
-You should have received a copy of the GNU General Public License
-along with GCC; see the file COPYING3.  If not see
-.  */
-
-#ifndef GCC_DOJUMP_H
-#define GCC_DOJUMP_H
-
-/* At the start of a function, record that we have no previously-pushed
-   arguments waiting to be popped.  */
-extern void init_pending_stack_adjust (void);
-
-/* Discard any pending stack adjustment.  */
-extern void discard_pending_stack_adjust (void);
-
-/* When exiting from function, if safe, clear out any pending stack adjust
-   so the adjustment won't get done.  */
-extern void clear_pending_stack_adjust (void);
-
-/* Pop any previously-pushed arguments that have not been popped yet.  */
-extern void do_pending_stack_adjust (void);
-
-/* Struct for saving/restoring of pending_stack_adjust/stack_pointer_delta
-   values.  */
-
-struct saved_pending_stack_adjust
-{
-  /* Saved value of pending_stack_adjust.  */
-  int x_pending_stack_adjust;
-
-  /* Saved value of stack_pointer_delta.  */
-  int x_stack_pointer_delta;
-};
-
-/* Remember pending_stack_adjust/stack_pointer_delta.
-   To be used around code that may call do_pending_stack_adjust (),
-   but the generated code could be discarded e.g. using delete_insns_since.  */
-
-extern void save_pending_stack_adjust (saved_pending_stack_adjust *);
-
-/* Restore the saved pending_stack_adjust/stack_pointer_delta.  */
-
-extern void restore_pending_stack_adjust (saved_pending_stack_adjust *);
-
-/* Generate code to evaluate EXP and jump to LABEL if the value is zero.  */
-extern void jumpifnot (tree, rtx, int);
-extern void jumpifnot_1 (enum tree_code, tree, tree, rtx, int);
-
-/* Generate code to evaluate EXP and jump to LABEL if the value is nonzero.  */
-extern void jumpif (tree, rtx, int);
-extern void jumpif_1 (enum tree_code, tree, tree, rtx, int);
-
-/* Generate code to evaluate EXP and jump to IF_FALSE_LABEL if
-   the result is zero, or IF_TRUE_LABEL if the result is one.  */
-extern void do_jump (tree, rtx, rtx, int);
-extern void do_jump_1 (enum tree_code, tree, tree, rtx, rtx, int);
-
-extern void do_compare_rtx_and_jump (rtx, rtx, enum rtx_code, int,
- machine_mode, rtx, rtx, rtx, int);
-
-extern bool split_comparison (enum rtx_code, machine_mode,
-			  enum rtx_code *, enum rtx_code *);
-
-#endif /* GCC_DOJUMP_H */
-/* Export function prototypes from dojump.c.
-   Copyright (C) 2015-2016 Free Software Foundation, Inc.
-
-This file is part of GCC.
-
-GCC is free software; you can redistribute it and/or modify it under
-the terms of the GNU General Public License as published by the Free
-Software Foundation; either version 3, or (at your option) any later
-version.
-
-GCC is distributed in the hope that it will be useful, but WITHOUT ANY
-WARRANTY; without even the implied warranty of MERCHANTABILITY or
-FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
-for more details.
-
-You should have received a copy of the GNU General Public License
-along with GCC; see the file COPYING3.  If not see
-.  */
-
-#ifndef GCC_DOJUMP_H
-#define GCC_DOJUMP_H
-
-/* At the start of a function, record that we have no previously-pushed
-   arguments waiting to be popped.  */
-extern void init_pending_stack_adjust (void);
-
-/* Discard any pending stack adjustment.  */
-extern void discard_pending_stack_adjust (void);
-
-/* When exiting from function, if safe, clear out any pending stack adjust
-   so the adjustment won't get done.  */
-extern void clear_pending_stack_adjust (void);
-
-/* Pop any previously-pushed arguments that have not been popped yet.  */
-extern void do_pending_stack_adjust (void);
-
-/* Struct for saving/restoring of pending_stack_adjust/stack_pointer_delta
-   values.  */
-
-struct saved_pending_stack_adjust
-{
-  /* Saved value of pending_stack_adjust

[PATCH, committed] jit: prevent ICE with type mismatch in gcc_jit_block_add_assignment_op

2015-01-15 Thread David Malcolm
gcc_jit_block_add_assignment_op was missing type-checking on the params,
which could lead to an ICE deep inside gimplification in fold-const.c:
10339   gcc_assert (TYPE_PRECISION (atype) == TYPE_PRECISION (type));

Takes jit.sum's # of expected passes from 7494 to 7514.

Committed to trunk as r219681.

(FWIW I generated the test case using
gcc_jit_context_dump_reproducer_to_file and minimized it by hand)

gcc/jit/ChangeLog:
* libgccjit.c (gcc_jit_block_add_assignment_op): Check that the
lvalue and the rvalue are of compatible type.

gcc/testsuite/ChangeLog:
* jit.dg/test-error-mismatching-types-in-assignment-op.c: New
test case.
---
 gcc/jit/libgccjit.c| 10 
 ...test-error-mismatching-types-in-assignment-op.c | 64 ++
 2 files changed, 74 insertions(+)
 create mode 100644 
gcc/testsuite/jit.dg/test-error-mismatching-types-in-assignment-op.c

diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
index a78b3e7..0faf0f9 100644
--- a/gcc/jit/libgccjit.c
+++ b/gcc/jit/libgccjit.c
@@ -1900,6 +1900,16 @@ gcc_jit_block_add_assignment_op (gcc_jit_block *block,
 "unrecognized value for enum gcc_jit_binary_op: %i",
 op);
   RETURN_IF_FAIL (rvalue, ctxt, loc, "NULL rvalue");
+  RETURN_IF_FAIL_PRINTF4 (
+compatible_types (lvalue->get_type (),
+ rvalue->get_type ()),
+ctxt, loc,
+"mismatching types:"
+" assignment to %s (type: %s) involving %s (type: %s)",
+lvalue->get_debug_string (),
+lvalue->get_type ()->get_debug_string (),
+rvalue->get_debug_string (),
+rvalue->get_type ()->get_debug_string ());
 
   gcc::jit::recording::statement *stmt = block->add_assignment_op (loc, 
lvalue, op, rvalue);
 
diff --git 
a/gcc/testsuite/jit.dg/test-error-mismatching-types-in-assignment-op.c 
b/gcc/testsuite/jit.dg/test-error-mismatching-types-in-assignment-op.c
new file mode 100644
index 000..c86d334
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-error-mismatching-types-in-assignment-op.c
@@ -0,0 +1,64 @@
+#include 
+#include "harness.h"
+
+void
+create_code (gcc_jit_context *ctxt, void *user_data)
+{
+  /* Try to inject the equivalent of:
+static int idx;
+void test_func (void)
+   {
+ idx += (unsigned char)1; // mismatching type
+   }
+ and verify that we don't get an ICE inside gimplification
+ due to the type mismatch.  */
+  gcc_jit_type *void_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_VOID);
+  gcc_jit_type *int_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT);
+  gcc_jit_type *unsigned_char_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_UNSIGNED_CHAR);
+  gcc_jit_function *test_func =
+gcc_jit_context_new_function (ctxt, /* gcc_jit_context *ctxt */
+  NULL, /* gcc_jit_location *loc */
+  GCC_JIT_FUNCTION_EXPORTED, /* enum 
gcc_jit_function_kind kind */
+  void_type, /* gcc_jit_type *return_type */
+  "test_func", /* const char *name */
+  0, /* int num_params */
+  NULL, /* gcc_jit_param **params */
+  0); /* int is_variadic */
+  gcc_jit_block *block =
+gcc_jit_function_new_block (test_func, "initial");
+
+  gcc_jit_rvalue *unsigned_char_1 =
+gcc_jit_context_new_rvalue_from_int (ctxt, /* gcc_jit_context *ctxt */
+ unsigned_char_type, /* gcc_jit_type 
*numeric_type */
+ 1); /* int value */
+  gcc_jit_lvalue *idx =
+gcc_jit_context_new_global (ctxt, /* gcc_jit_context *ctxt */
+NULL, /* gcc_jit_location *loc */
+GCC_JIT_GLOBAL_INTERNAL, /* enum 
gcc_jit_global_kind kind */
+int_type, /* gcc_jit_type *type */
+"idx"); /* const char *name */
+
+  gcc_jit_block_add_assignment_op (block, /*gcc_jit_block *block */
+   NULL, /* gcc_jit_location *loc */
+   idx, /* gcc_jit_lvalue *lvalue */
+   GCC_JIT_BINARY_OP_PLUS, /* enum 
gcc_jit_binary_op op */
+   unsigned_char_1); /* gcc_jit_rvalue *rvalue 
*/
+  gcc_jit_block_end_with_void_return (block, /*gcc_jit_block *block */
+ NULL);
+}
+
+void
+verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
+{
+  CHECK_VALUE (result, NULL);
+
+  /* Verify that the correct error message was emitted.  */
+  CHECK_STRING_VALUE (gcc_jit_context_get_first_error (ctxt),
+ "gcc_jit_block_add_assignment_op:"
+ " mismatching types:"
+ " assignment to idx (type: int)"
+ " involving (unsigned char

Re: [PATCH] Fix PR testsuite/64605

2015-01-15 Thread Ilya Verbin
On 15 Jan 11:20, Mike Stump wrote:
> On Jan 15, 2015, at 9:53 AM, Ilya Verbin  wrote:
> > If I just remove 'load_gcc_lib gcc-dg.exp' from libatomic.exp, like this is 
> > done
> > in libitm.exp, it will not work:
> 
> Ok, original patch is fine.

Oh, I see, it's loaded by libitm/testsuite/libitm.c/c.exp, so I changed the
patch for consistency.  Here is the final version, OK to commit?


PR testsuite/64605
* testsuite/lib/libatomic.exp: Do not load gcc-dg.exp.
* testsuite/libatomic.c/c.exp: Load gcc-dg.exp.


diff --git a/libatomic/testsuite/lib/libatomic.exp 
b/libatomic/testsuite/lib/libatomic.exp
index 28cbaa8..0491c18 100644
--- a/libatomic/testsuite/lib/libatomic.exp
+++ b/libatomic/testsuite/lib/libatomic.exp
@@ -23,6 +23,11 @@ proc load_gcc_lib { filename } {
 }
 
 load_lib dg.exp
+
+# Required to use gcc-dg.exp - however, the latter should NOT be
+# loaded until ${tool}_target_compile is defined since it uses that
+# to determine default LTO options.
+
 load_gcc_lib file-format.exp
 load_gcc_lib target-supports.exp
 load_gcc_lib target-utils.exp
@@ -40,7 +45,6 @@ load_gcc_lib torture-options.exp
 load_gcc_lib timeout.exp
 load_gcc_lib timeout-dg.exp
 load_gcc_lib fortran-modules.exp
-load_gcc_lib gcc-dg.exp
 
 set dg-do-what-default run
 
diff --git a/libatomic/testsuite/libatomic.c/c.exp 
b/libatomic/testsuite/libatomic.c/c.exp
index 1da3cb1..dbdb5eb 100644
--- a/libatomic/testsuite/libatomic.c/c.exp
+++ b/libatomic/testsuite/libatomic.c/c.exp
@@ -21,6 +21,7 @@ if [info exists lang_test_file] then {
 }
 
 load_lib libatomic-dg.exp
+load_gcc_lib gcc-dg.exp
 
 # If a testcase doesn't have special options, use these.
 if ![info exists DEFAULT_CFLAGS] then {


  -- Ilya


Stage 3 RFC: using "jit" for ahead-of-time compilation

2015-01-15 Thread David Malcolm
Release managers: given that this only touches the jit, and that the jit
is off by default, any objections if I go ahead and commit this?
It's a late-breaking feature, but the jit as a whole is new, and
I think the following is a big win, so I'd like to proceed with this in
stage 3 (i.e. in the next 24 hours).  There are docs and testcases.

New jit API entrypoint: gcc_jit_context_compile_to_file

This patch adds a way to use libgccjit for ahead-of-time compilation.
I noticed that given the postprocessing steps the jit has to take to
turn the .s file into in-memory code (invoke driver to convert to
a .so and then dlopen), that it's not much of a leap to support
compiling the .s file into objects, dynamic libraries, and executables.

Doing so seems like a big win from a feature standpoint: people with
pre-existing frontend code who want a backend can then plug in libgccjit
and have a compiler, without needing to write it as a GCC frontend, or
use LLVM.

"jit" becomes something of a misnomer for this use-case.

As an experiment, I used this technique to add a compiler for the
language I'll refer to as "brainf" (ahem), and wrote this up for the
libgccjit tutorial (it's all in the patch); prebuilt HTML can be seen
at:
https://dmalcolm.fedorapeople.org/gcc/libgccjit-api-docs-wip/intro/tutorial05.html

The main things that are missing are:
  * specifying libraries to link against (Uli had some ideas about this)
  * cross-compilation support (needs some deeper work, especially the
test suite, so deferrable to gcc 6, I guess)
but the feature is useful with the patch as-is.

The new test cases take jit.sum's # of expected passes
from 7514 to 7571.

gcc/jit/ChangeLog:
* docs/cp/topics/results.rst: Rename to...
* docs/cp/topics/compilation.rst: ...this, and add section on
ahead-of-time compilation.
* docs/cp/topics/index.rst: Update for renaming of results.rst
to compilation.rst.
* docs/examples/emit-alphabet.bf: New file, a sample "brainf"
script.
* docs/examples/tut05-bf.c: New file, implementing a compiler
for "brainf".
* docs/internals/test-hello-world.exe.log.txt: Update to reflect
changes to logger output.
* docs/intro/index.rst: Add tutorial05.rst
* docs/intro/tutorial05.rst: New file.
* docs/topics/results.rst: Rename to...
* docs/topics/compilation.rst: ...this, and add section on
ahead-of-time compilation.
* docs/topics/index.rst: Update for renaming of results.rst to
compilation.rst.
* jit-playback.c (gcc::jit::playback::context::compile): Convert
return type from result * to void.  Move the code to convert to
dso and dlopen the result to a new pure virtual "postprocess"
method.
(gcc::jit::playback::compile_to_memory::compile_to_memory): New
function.
(gcc::jit::playback::compile_to_memory::postprocess): New
function, based on playback::context::compile.
(gcc::jit::playback::compile_to_file::compile_to_file): New
function.
(gcc::jit::playback::compile_to_file::postprocess): New function.
(gcc::jit::playback::compile_to_file::copy_file): New function.
(gcc::jit::playback::context::convert_to_dso): Move internals
to...
(gcc::jit::playback::context::invoke_driver): New method.  Add
"-shared" and "-c" options to driver's argv as needed.
* jit-playback.h: Include "timevar.h".
(gcc::jit::playback::context::compile): Convert return type from
result * to void.
(gcc::jit::playback::context::postprocess): New pure virtual
function, making this an abstract base class.
(gcc::jit::playback::context::get_tempdir): New accessor.
(gcc::jit::playback::context::invoke_driver): New function.
(class gcc::jit::playback::compile_to_memory): New subclass of
playback::context.
(class gcc::jit::playback::compile_to_file): Likewise.
* jit-recording.c (gcc::jit::recording::context::compile): Use a
playback::compile_to_memory, and extract its result.
(gcc::jit::recording::context::compile_to_file): New function.
* jit-recording.h (gcc::jit::recording::context::compile_to_file):
New function.
* libgccjit++.h (gccjit::context::compile_to_file): New method.
* libgccjit.c (gcc_jit_context_compile): Update log message to
clarify that this is an in-memory compile.
(gcc_jit_context_compile_to_file): New function.
* libgccjit.h (gcc_jit_context): Clarify that you can compile
a context more than once, and that you can compile to a file
as well as to memory.
(gcc_jit_result): Clarify that this is the result of an
in-memory compilation.
(gcc_jit_context_compile): Clarify that you can compile, and that
this is an in-memory compilation.
(enum gcc_jit_output_kind):

  1   2   >