Re: [PATCH v4] Add strict aliasing warning when inlining function.

2014-08-20 Thread lin zuojian
Hi Richard,
Do you think this version is good enough to commit to trunk? I have
asked Andrew to commit for me. If it is not good enough, I may ask
him not to do this.

---
Lin Zuojian


Fix tree-optimization/62091

2014-08-20 Thread Jan Hubicka
Hi,
this should be hopefully last fix to tree-optimization/62091.  The testcase 
triggers
another unnecesary paranoia in get_dynamic_type: if location is of type A to 
start with
and then it is re-initialized to type A, it should not count as dynamic type 
change.

While looking into it, I added some debug info that I think is useful enough to 
be kept
and I also noticed that we do not handle multiple inheritance very well. Fixed 
thus.

Bootstrapped/regtested x86_64-linux, will commit it after bit of additional 
testing.
With this change I can now build libreoffice, so I think I can drop the old 
ipa-prop
intraprocedural code and remove the sanity check.

Honza

PR tree-optimization/62091
* g++.dg/ipa/devirt-37.C: Update template.
* g++.dg/ipa/devirt-40.C: New testcase.
* ipa-devirt.c (ipa_polymorphic_call_context::restrict_to_inner_type):
handle correctly arrays.
(extr_type_from_vtbl_ptr_store): Add debug output; handle multiple
inheritance binfos.
(record_known_type): Walk into inner type.
(ipa_polymorphic_call_context::get_dynamic_type): Likewise; strenghten
condition on no type changes.
Index: testsuite/g++.dg/ipa/devirt-37.C
===
--- testsuite/g++.dg/ipa/devirt-37.C(revision 214255)
+++ testsuite/g++.dg/ipa/devirt-37.C(working copy)
@@ -30,7 +30,7 @@ t()
 /* After inlining the call within constructor needs to be checked to not go 
into a basetype.
We should see the vtbl store and we should notice extcall as possibly 
clobbering the
type but ignore it because b is in static storage.  */
-/* { dg-final { scan-tree-dump "Determined dynamic type."  "fre2"  } } */
+/* { dg-final { scan-tree-dump "No dynamic type change found."  "fre2"  } } */
 /* { dg-final { scan-tree-dump "Checking vtbl store:"  "fre2"  } } */
 /* { dg-final { scan-tree-dump "Function call may change dynamic type:extcall" 
 "fre2"  } } */
 /* { dg-final { scan-tree-dump "converting indirect call to function virtual 
void"  "fre2"  } } */
Index: testsuite/g++.dg/ipa/devirt-40.C
===
--- testsuite/g++.dg/ipa/devirt-40.C(revision 0)
+++ testsuite/g++.dg/ipa/devirt-40.C(revision 0)
@@ -0,0 +1,23 @@
+/* { dg-options "-O2 -fdump-tree-fre2-details"  } */
+typedef enum
+{
+} UErrorCode;
+class UnicodeString
+{
+public:
+  UnicodeString ();
+  virtual ~UnicodeString ();
+};
+class A
+{
+  UnicodeString &m_fn1 (UnicodeString &, int &p2, UErrorCode &) const;
+};
+UnicodeString::UnicodeString () {}
+UnicodeString &
+A::m_fn1 (UnicodeString &, int &p2, UErrorCode &) const
+{
+  UnicodeString a[2];
+}
+
+/* { dg-final { scan-tree-dump "converting indirect call to function virtual 
UnicodeString" "fre2"  } } */
+/* { dg-final { cleanup-tree-dump "fre2" } } */
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 214223)
+++ ipa-devirt.c(working copy)
@@ -2015,8 +2015,10 @@ ipa_polymorphic_call_context::restrict_t
  tree subtype = TYPE_MAIN_VARIANT (TREE_TYPE (type));
 
  /* Give up if we don't know array size.  */
- if (!tree_fits_shwi_p (TYPE_SIZE (subtype))
- || !tree_to_shwi (TYPE_SIZE (subtype)) <= 0)
+ if (!TYPE_SIZE (subtype)
+ || !tree_fits_shwi_p (TYPE_SIZE (subtype))
+ || tree_to_shwi (TYPE_SIZE (subtype)) <= 0
+ || !contains_polymorphic_type_p (subtype))
goto give_up;
  cur_offset = cur_offset % tree_to_shwi (TYPE_SIZE (subtype));
  type = subtype;
@@ -2630,7 +2632,7 @@ extr_type_from_vtbl_ptr_store (gimple st
   HOST_WIDE_INT *type_offset)
 {
   HOST_WIDE_INT offset, size, max_size;
-  tree lhs, rhs, base, binfo;
+  tree lhs, rhs, base;
 
   if (!gimple_assign_single_p (stmt))
 return NULL_TREE;
@@ -2639,7 +2641,11 @@ extr_type_from_vtbl_ptr_store (gimple st
   rhs = gimple_assign_rhs1 (stmt);
   if (TREE_CODE (lhs) != COMPONENT_REF
   || !DECL_VIRTUAL_P (TREE_OPERAND (lhs, 1)))
-return NULL_TREE;
+ {
+   if (dump_file)
+ fprintf (dump_file, "  LHS is not virtual table.\n");
+   return NULL_TREE;
+ }
 
   if (tci->vtbl_ptr_ref && operand_equal_p (lhs, tci->vtbl_ptr_ref, 0))
 ;
@@ -2649,33 +2655,80 @@ extr_type_from_vtbl_ptr_store (gimple st
   if (offset != tci->offset
  || size != POINTER_SIZE
  || max_size != POINTER_SIZE)
-   return NULL_TREE;
+   {
+ if (dump_file)
+   fprintf (dump_file, "wrong offset %i!=%i or size %i\n",
+(int)offset, (int)tci->offset, (int)size);
+ return NULL_TREE;
+   }
   if (DECL_P (tci->instance))
{
  if (base != tci->instance)
-   return NULL_TREE;
+   {
+ if (dump_file)
+   {
+ fprin

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

2014-08-20 Thread Tony Wang
Step 3: Test cases to verify the code size reduction.

gcc/gcc/testsuite/ChangeLog:
2014-08-21  Tony Wang  

* gcc.target/arm/size-optimization-ieee-1.c: New test case
* gcc.target/arm/size-optimization-ieee-2.c: New test case
* lib/gcc-dg.exp: Add new function scan-symbol-common, scan-symbol-yes, 
scan-symbol-no to scan a user defined symbol in final elf file

BR,
Tony

diff --git a/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c
b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c
new file mode 100644
index 000..46e9cdf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-1.c
@@ -0,0 +1,30 @@
+/* { dg-do link { target { arm_thumb2_ok } } } */
+/* { dg-options "-Wl,--gc-sections" } */
+int
+foo ()
+{
+  volatile float a;
+  volatile float b;
+  volatile float c = a * b;
+  return 0;
+}
+
+int
+bar ()
+{
+  volatile double a;
+  volatile double b;
+  volatile double c = a * b;
+  return 0;
+}
+
+int
+main ()
+{
+  foo ();
+  bar ();
+  return 0;
+}
+/* { dg-final { scan-symbol-no "__aeabi_fdiv" } } */
+/* { dg-final { scan-symbol-no "__aeabi_ddiv" } } */
+
diff --git a/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c
b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c
new file mode 100644
index 000..5007d62
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/size-optimization-ieee-2.c
@@ -0,0 +1,30 @@
+/* { dg-do link { target { arm_thumb2_ok } } } */
+/* { dg-options "-Wl,--gc-sections" } */
+int
+foo ()
+{
+  volatile float a;
+  volatile float b;
+  volatile float c = a / b;
+  return 0;
+}
+
+int
+bar ()
+{
+  volatile double a;
+  volatile double b;
+  volatile double c = a / b;
+  return 0;
+}
+
+int
+main ()
+{
+  foo ();
+  bar ();
+  return 0;
+}
+/* { dg-final { scan-symbol-yes "__aeabi_fmul" } } */
+/* { dg-final { scan-symbol-yes "__aeabi_dmul" } } */
+
diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 3390caa..0d52e95 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -880,5 +880,57 @@ proc gdb-exists { args } {
 return 0;
 }
 
+# Scan the OUTPUT_FILE for a symbol. Return 1 if it present, or
+# return 0 if it doesn't present
+
+proc scan-symbol-common { args } {
+global nm
+global base_dir
+
+set testcase [testname-for-summary]
+set output_file "[file rootname [file tail $testcase]].exe"
+
+# Find nm like we find g++ in g++.exp.
+if ![info exists nm]  {
+set nm [findfile $base_dir/../../../binutils/nm \
+$base_dir/../../../binutils/nm \
+[findfile $base_dir/../../nm $base_dir/../../nm \
+  [findfile $base_dir/nm $base_dir/nm \
+   [transform nm
+verbose -log "nm is $nm"
+}
+
+if { $output_file == "" } {
+fail "scan-symbol-not $args: dump file does not exist"
+return
+}
+
+set fd [open "| $nm $output_file" r]
+set text [read $fd]
+close $fd
+
+if [regexp -- [lindex $args 0] $text] {
+return 1
+} else {
+return 0
+}
+}
+
+proc scan-symbol-yes { args } {
+if { [scan-symbol-common $args] == 1 } {
+   pass "scan-symbol-yes $args exists"
+} else {
+   fail "scan-symbol-yes $args does not exist"
+}
+}
+
+proc scan-symbol-no { args } {
+if { [scan-symbol-common $args] != 1 } {
+pass "scan-symbol-no $args does not exist"
+} else {
+fail "scan-symbol-no $args exists"
+}
+}
+
 set additional_prunes ""
 set dg_runtest_extra_prunes ""

libgcc_mul_div_code_size_reduction_3.diff
Description: Binary data


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

2014-08-20 Thread Tony Wang
Step 2: Mark all the symbols around the fragment boundaries as function 
symbols, so as to generate veneer when
the two section is too far away from each other. Also, I have both manually and 
using some test cases to
verify that IP and PSR are not alive at such point.

gcc/libgcc/ChangeLog:
2014-8-21   Tony Wang 

* config/arm/ieee754-sf.S: Expose symbols around fragment boundaries as 
function symbols.
* config/arm/ieee754-df.S: Same with above

BR,
Tony

libgcc_mul_div_code_size_reduction_2.diff
Description: Binary data


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

2014-08-20 Thread Tony Wang
Hi there,

In libgcc the file ieee754-sf.S and ieee754-df.S have some function pairs which 
will be bundled into one .o
file and sharing the same .text section. For example, the fmul and fdiv, the 
libgcc makefile will build them
into one .o file and archived into libgcc.a. So when user only call single 
float point multiply functions, the
fdiv function will also be linked, and as fmul and fdiv share the same .text 
section, linker option
--gc-sections or -flot can't remove the dead code.
 
So this optimization just separates the function pair(fmul/fdiv and dmul/ddiv) 
into different sections,
following the naming pattern of -ffunction-sections(.text.__functionname), 
through which the unused sections
of fdiv/ddiv can be eliminated through option --gcc-sections when users only 
use fmul/dmul.The solution is to
add a conditional statement in the macro FUNC_START, which will conditional 
change the section of a function
from .text to .text.__\name. when compiling with the L_arm_muldivsf3 or 
L_arm_muldivdf3 macro.

GCC regression test has been done on QEMU for Cortex-M3. No new regressions 
when turn on this patch.

The code reduction for thumb2 on cortex-m3 is:
1. When user only use single float point multiply:
fmul+fdiv => fmul will have a code size reduction of 318 bytes.
 
2. When user only use double float point multiply:
dmul+ddiv => dmul will have a code size reduction of 474 bytes.

Ok for trunk?

BR,
Tony

Step 1: Provide another option: sp-scetion to control whether to split the 
section of a function pair into two
part.

gcc/libgcc/ChangeLog:
2014-08-21  Tony Wang  

* config/arm/lib1funcs.S (FUNC_START): Add conditional section
redefine for macro L_arm_muldivsf3 and L_arm_muldivdf3
(SYM_END, ARM_SYM_START): Add macros used to expose function 
Symbols

diff --git a/libgcc/config/arm/lib1funcs.S b/libgcc/config/arm/lib1funcs.S
index b617137..0f87111 100644
--- a/libgcc/config/arm/lib1funcs.S
+++ b/libgcc/config/arm/lib1funcs.S
@@ -418,8 +418,12 @@ SYM (\name):
 #define THUMB_SYNTAX
 #endif
 
-.macro FUNC_START name
+.macro FUNC_START name sp_section=
+  .ifc \sp_section, function_section
+   .section.text.__\name,"ax",%progbits
+  .else
.text
+  .endif
.globl SYM (__\name)
TYPE (__\name)
.align 0
@@ -429,14 +433,24 @@ SYM (\name):
 SYM (__\name):
 .endm
 
+.macro ARM_SYM_START name
+   TYPE (\name)
+   .align 0
+SYM (\name):
+.endm
+
+.macro SYM_END name
+   SIZE (\name)
+.endm
+
 /* Special function that will always be coded in ARM assembly, even if
in Thumb-only compilation.  */
 
 #if defined(__thumb2__)
 
 /* For Thumb-2 we build everything in thumb mode.  */
-.macro ARM_FUNC_START name
-   FUNC_START \name
+.macro ARM_FUNC_START name sp_section=
+   FUNC_START \name \sp_section
.syntax unified
 .endm
 #define EQUIV .thumb_set
@@ -467,8 +481,12 @@ _L__\name:
 #ifdef __ARM_ARCH_6M__
 #define EQUIV .thumb_set
 #else
-.macro ARM_FUNC_START name
+.macro ARM_FUNC_START name sp_section=
+  .ifc \sp_section, function_section
+   .section.text.__\name,"ax",%progbits
+  .else
.text
+  .endif
.globl SYM (__\name)
TYPE (__\name)
.align 0

libgcc_mul_div_code_size_reduction_1.diff
Description: Binary data


Fix testsuite failures I caused

2014-08-20 Thread Jan Hubicka
Hello,
I managed to mess up my testing today for the unreachable function change and 
profiling
update.  The following patch should fix the fallout.
First problem is testsuite expecting that extern inlines are not instrumented. 
While
this is not handled consistently for years (since ealry inlining was 
introduced) my
patch made it worse.
Second fix removes overactive sanity check - symtab_remove_unreachable_nodes 
can iterate
in rare cases and thus it is unsafe to use it for testing that it was run 
previously.

Bootstrap/regtest in progress, will commit once it passes.

Honza

* tree-profile.c (tree_profiling): Skip external functions
when doing coverage instrumentation.
* cgraphunit.c (compile): Do not assert that all nodes are reachable.

* gcc.dg/ipa/ctor-empty-1.c: Update template.
Index: tree-profile.c
===
--- tree-profile.c  (revision 214223)
+++ tree-profile.c  (working copy)
@@ -578,6 +578,13 @@ tree_profiling (void)
   if (DECL_SOURCE_LOCATION (node->decl) == BUILTINS_LOCATION)
continue;
 
+  /* Do not instrument extern inline functions when testing coverage.
+While this is not perfectly consistent (early inlined extern inlines
+will get acocunted), testsuite expects that.  */
+  if (DECL_EXTERNAL (node->decl)
+ && flag_test_coverage)
+   continue;
+
   push_cfun (DECL_STRUCT_FUNCTION (node->decl));
 
   /* Local pure-const may imply need to fixup the cfg.  */
Index: cgraphunit.c
===
--- cgraphunit.c(revision 214224)
+++ cgraphunit.c(working copy)
@@ -2209,11 +2209,6 @@ compile (void)
   cgraph_materialize_all_clones ();
   bitmap_obstack_initialize (NULL);
   execute_ipa_pass_list (g->get_passes ()->all_late_ipa_passes);
-#ifdef ENABLE_CHECKING
-  symtab_node::verify_symtab_nodes ();
-  /* Verify late IPA passes cleaned up after themselves.  */
-  gcc_assert (!symtab_remove_unreachable_nodes (false, dump_file));
-#endif
   bitmap_obstack_release (NULL);
   mark_functions_to_output ();
 
Index: testsuite/gcc.dg/ipa/ctor-empty-1.c
===
--- testsuite/gcc.dg/ipa/ctor-empty-1.c (revision 214239)
+++ testsuite/gcc.dg/ipa/ctor-empty-1.c (working copy)
@@ -1,8 +1,8 @@
 /* { dg-do compile } */
-/* { dg-options "-O3 -c -fdump-ipa-cgraph"  } */
+/* { dg-options "-O3 -c -fdump-ipa-free-inline-summary"  } */
 static __attribute__((constructor))
 void empty_constructor()
 {
 }
-/* { dg-final { scan-ipa-dump "Reclaiming functions: empty_constructor"  
"cgraph"  } } */
-/* { dg-final { cleanup-ipa-dump "cgraph" } } */
+/* { dg-final { scan-ipa-dump "Reclaiming functions: empty_constructor"  
"free-inline-summary"  } } */
+/* { dg-final { cleanup-ipa-dump "free-inline-summary" } } */
Index: testsuite/g++.dg/ipa/devirt-37.C
===
--- testsuite/g++.dg/ipa/devirt-37.C(revision 214240)
+++ testsuite/g++.dg/ipa/devirt-37.C(working copy)
@@ -30,7 +30,7 @@ t()
 /* After inlining the call within constructor needs to be checked to not go 
into a basetype.
We should see the vtbl store and we should notice extcall as possibly 
clobbering the
type but ignore it because b is in static storage.  */
-/* { dg-final { scan-tree-dump "Determined dynamic type."  "fre2"  } } */
+/* { dg-final { scan-tree-dump "No dynamic type change found."  "fre2"  } } */
 /* { dg-final { scan-tree-dump "Checking vtbl store:"  "fre2"  } } */
 /* { dg-final { scan-tree-dump "Function call may change dynamic type:extcall" 
 "fre2"  } } */
 /* { dg-final { scan-tree-dump "converting indirect call to function virtual 
void"  "fre2"  } } */
Index: testsuite/g++.dg/ipa/devirt-40.C
===
--- testsuite/g++.dg/ipa/devirt-40.C(revision 0)
+++ testsuite/g++.dg/ipa/devirt-40.C(revision 0)
@@ -0,0 +1,23 @@
+/* { dg-options "-O2 -fdump-tree-fre2-details"  } */
+typedef enum
+{
+} UErrorCode;
+class UnicodeString
+{
+public:
+  UnicodeString ();
+  virtual ~UnicodeString ();
+};
+class A
+{
+  UnicodeString &m_fn1 (UnicodeString &, int &p2, UErrorCode &) const;
+};
+UnicodeString::UnicodeString () {}
+UnicodeString &
+A::m_fn1 (UnicodeString &, int &p2, UErrorCode &) const
+{
+  UnicodeString a[2];
+}
+
+/* { dg-final { scan-tree-dump-not "converting indirect call to function 
virtual UnicodeString" "fre2"  } } */
+/* { dg-final { cleanup-tree-dump "fre2" } } */


Re: [GSoC] Elimination of CLooG library installation dependency

2014-08-20 Thread Bin.Cheng
I think it's a issue in isl library check for (Canadian)
cross_compiling.  Will send a patch soon.

Thanks,
bin

On Wed, Aug 20, 2014 at 1:47 PM, Bin.Cheng  wrote:
> On Wed, Aug 20, 2014 at 1:24 PM, Roman Gareev  wrote:
>> Which configure options do you use? Have you tried to bootstrap
>> r214105 with same configure options?
>> Have you tried to manually export the path to isl to LD_RUN_PATH?
>> (You've probably tried. I just want to make sure.)
>
> I can't access the build bot right now, so haven't tried other options
> yet.  The latest good I got build was against r213896.
>
> Thanks,
> bin
>>
>>
>> 2014-08-20 9:28 GMT+06:00 Bin.Cheng :
>>> I suspect this causes arm/aarch64 native bootstrap failure with below 
>>> messages.
>>>
>>> aarch64-none-linux-gnu-g++ -c   -g -O2 -DIN_GCC-fno-exceptions
>>> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
>>> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
>>> -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
>>> -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I.
>>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc
>>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/.
>>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../include
>>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libcpp/include
>>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include
>>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/workdir/aarch64-none-linux-gnu/sysroot//usr/include
>>>  
>>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber
>>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libdecnumber/dpd
>>> -I../libdecnumber
>>> -I/projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/../libbacktrace
>>>  -DCLOOG_INT_GMP   -o graphite.o -MT graphite.o -MMD -MP -MF
>>> ./.deps/graphite.TPo
>>> /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c
>>> /projects/pd/pdsw-infrastructure/production-builds/bld-root/channels/fsf-trunk/builds/502/src/gcc/gcc/graphite.c:38:21:
>>> fatal error: isl/set.h: No such file or directory
>>> compilation terminated.
>>> make[1]: *** [graphite.o] Error 1
>>> make[1]: Leaving directory
>>> `/arm/scratch/pdtltest/bld-temporary/builds/fsf-trunk/502/workdir/aarch64-none-linux-gnu/obj/build-gcc/gcc'
>>> make: *** [all-gcc] Error 2
>>>
>>> Thanks,
>>> bin
>>
>> --
>> Cheers, Roman Gareev.


RE: [PATCH, ARM] Fix incorrect alignment of small values in minipool

2014-08-20 Thread Thomas Preud'homme
> From: Richard Earnshaw
> Sent: Monday, August 18, 2014 6:34 PM
> >
> > The problem is that in the pattern for constable_4 we don't have the
> information
> > about the access mode for this entry. In the testcase along this patch the
> rtx
> > manipulated in the pattern is VOIDmode while the access mode is HImode.
> In
> > dump_minipool on the other hand the information can be found in mp-
> >mode.
> >
> 
> I think it would be better to make sure the mode field never contains
> VOIDmode.  That's not really useful information.

I'm a bit confused. In the chapter about modes (13.6) of the gcc internal 
documentation
VOIDmode is said to be the correct mode for constant. You want me to change 
this?

Best regards,

Thomas





Re: [PATCH v4] Add strict aliasing warning when inlining function.

2014-08-20 Thread lin zuojian
Hi Andrew,
What do you think of the current patch? If you thought it was find to
commit to trunk, please commit it for me.
--
Lin Zuojian


[PATCH v4] Add strict aliasing warning when inlining function.

2014-08-20 Thread lin zuojian
Hi,
This patch is to improve the output of strict_aliasing_warning. This
version will output the expression of rhs, type of that expression,
and the type of lhs. That make it easier to debug strict aliasing
bug.

* tree-inline.c (setup_one_parameter): Add strict aliasing check.
* c-family/c-common.c (strict_aliasing_warning): Move to alias.c.
* c-family/c-common.h (strict_aliasing_warning): Move to tree.h.
* alias.c (strict_aliasing_warning): New function moved from
c-family/c-common.c.
* tree.h (strict_aliasing_warning): New function declaration moved from
c-family/c-common.h.
* testsuite/g++.dg/warn/Wstrict-aliasing-inline-parameter.C: New test.
---
 gcc/ChangeLog  |  11 +++
 gcc/alias.c| 107 +
 gcc/c-family/c-common.c|  78 ---
 gcc/c-family/c-common.h|   1 -
 .../warn/Wstrict-aliasing-inline-parameter.C   |  40 
 gcc/tree-inline.c  |   4 +
 gcc/tree.h |   2 +
 7 files changed, 164 insertions(+), 79 deletions(-)
 create mode 100644 
gcc/testsuite/g++.dg/warn/Wstrict-aliasing-inline-parameter.C

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 1067203..bff6354 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,14 @@
+2014-08-21  Lin Zuojian  
+
+   * tree-inline.c (setup_one_parameter): Add strict aliasing check.
+   * c-family/c-common.c (strict_aliasing_warning): Move to alias.c.
+   * c-family/c-common.h (strict_aliasing_warning): Move to tree.h.
+   * alias.c (strict_aliasing_warning): New function moved from
+   c-family/c-common.c.
+   * tree.h (strict_aliasing_warning): New function declaration moved from
+   c-family/c-common.h.
+   * testsuite/g++.dg/warn/Wstrict-aliasing-inline-parameter.C: New test.
+
 2014-08-21  Manuel López-Ibáñez  
 
PR fortran/44054
diff --git a/gcc/alias.c b/gcc/alias.c
index 39df09b..ab11ae3 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -47,6 +47,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "is-a.h"
 #include "gimple.h"
 #include "gimple-ssa.h"
+#include "tree-pretty-print.h"
 
 /* The aliasing API provided here solves related but different problems:
 
@@ -3044,4 +3045,110 @@ end_alias_analysis (void)
   sbitmap_free (reg_known_equiv_p);
 }
 
+/* Helper of strict_aliasing_warning to format warning.  */
+static void
+strict_aliasing_warning_output (tree type, tree expr, const char *msg)
+{
+  pretty_printer pp;
+  pp_string (&pp, msg);
+  pp_dot (&pp);
+  pp_space (&pp);
+  pp_string (&pp, "With expression");
+  pp_colon (&pp);
+  pp_space (&pp);
+  dump_generic_node (&pp, expr, 0, 0, false);
+  pp_comma (&pp);
+  pp_space (&pp);
+  pp_string (&pp, "type of expresssion");
+  pp_colon (&pp);
+  pp_space (&pp);
+  dump_generic_node (&pp, TREE_TYPE (expr), 0, 0, false);
+  pp_comma (&pp);
+  pp_space (&pp);
+  pp_string (&pp, "type to cast");
+  pp_colon (&pp);
+  pp_space (&pp);
+  dump_generic_node (&pp, type, 0, 0, false);
+  pp_dot (&pp);
+  warning (OPT_Wstrict_aliasing, pp_formatted_text (&pp), NULL);
+}
+
+/* Print a warning about casts that might indicate violation
+   of strict aliasing rules if -Wstrict-aliasing is used and
+   strict aliasing mode is in effect. OTYPE is the original
+   TREE_TYPE of EXPR, and TYPE the type we're casting to. */
+
+bool
+strict_aliasing_warning (tree otype, tree type, tree expr)
+{
+  /* Strip pointer conversion chains and get to the correct original type.  */
+  STRIP_NOPS (expr);
+  otype = TREE_TYPE (expr);
+
+  if (!(flag_strict_aliasing
+   && POINTER_TYPE_P (type)
+   && POINTER_TYPE_P (otype)
+   && !VOID_TYPE_P (TREE_TYPE (type)))
+  /* If the type we are casting to is a ref-all pointer
+ dereferencing it is always valid.  */
+  || TYPE_REF_CAN_ALIAS_ALL (type))
+return false;
+
+  if ((warn_strict_aliasing > 1) && TREE_CODE (expr) == ADDR_EXPR
+  && (DECL_P (TREE_OPERAND (expr, 0))
+  || handled_component_p (TREE_OPERAND (expr, 0
+{
+  /* Casting the address of an object to non void pointer. Warn
+ if the cast breaks type based aliasing.  */
+  if (!COMPLETE_TYPE_P (TREE_TYPE (type)) && warn_strict_aliasing == 2)
+   {
+ strict_aliasing_warning_output (type, expr, "type-punning to 
incomplete type "
+  "might break strict-aliasing rules");
+ return true;
+   }
+  else
+{
+  /* warn_strict_aliasing >= 3.   This includes the default (3).
+ Only warn if the cast is dereferenced immediately.  */
+  alias_set_type set1 =
+   get_alias_set (TREE_TYPE (TREE_OPERAND (expr, 0)));
+  alias_set_type set2 = get_alias_set (TREE_TYPE (type));
+
+  if (set1 != set2 && set2 != 0
+ && (set1 == 0 || !ali

Re: [PATCH, rs6000] Enable and document some additional builtin overloads

2014-08-20 Thread David Edelsohn
On Wed, Aug 20, 2014 at 8:41 PM, Bill Schmidt
 wrote:
> Hi,
>
> The Power ISA 2.07 enables some additional forms of existing vector
> builtins, in particular allowing use of vector long long (signed and
> unsigned) and vector double forms.  This patch adds those builtins and
> provides documentation for them.  There are also cases where builtins
> from ISA 2.06 were not added for all possible vector types (for
> instance, sometimes defining vector signed long long but omitting vector
> unsigned long long).  This patch fixes those omissions as well.
>
> I've added a new compile-only test that verifies the new forms are
> accepted by the compiler.  I've bootstrapped and regtested this on
> powerpc64le-unknown-linux-gnu with no regressions, and this new test
> passes.  Is this ok for trunk?
>
> Thanks,
> Bill
>
>
> [gcc]
>
> 2014-08-20  Bill Schmidt  
>
> * config/rs6000/altivec.h (vec_cpsgn): New #define.
> (vec_mergee): Likewise.
> (vec_mergeo): Likewise.
> (vec_cntlz): Likewise.
> * config/rs600/rs6000-c.c (altivec_overloaded_builtins): Add new
> entries for VEC_AND, VEC_ANDC, VEC_MERGEH, VEC_MERGEL, VEC_NOR,
> VEC_OR, VEC_PACKSU, VEC_XOR, VEC_PERM, VEC_SEL, VEC_VCMPGT_P,
> VMRGEW, and VMRGOW.
> * doc/extend.texi: Document various forms of vec_cpsgn,
> vec_splats, vec_and, vec_andc, vec_mergeh, vec_mergel, vec_nor,
> vec_or, vec_perm, vec_sel, vec_sub, vec_xor, vec_all_eq,
> vec_all_ge, vec_all_gt, vec_all_le, vec_all_lt, vec_all_ne,
> vec_any_eq, vec_any_ge, vec_any_gt, vec_any_le, vec_any_lt,
> vec_any_ne, vec_mergee, vec_mergeo, vec_packsu, and vec_cntlz.
>
> [gcc/testsuite]
>
> 2014-08-20  Bill Schmidt  
>
> * testsuite/gcc.target/powerpc/builtins-1.c: New test.

Okay.

Thanks, David


Re: [PATCH 039/236] create_insn_rtx_from_pattern and create_copy_of_insn_rtx return rtx_insn

2014-08-20 Thread David Malcolm
On Wed, 2014-08-13 at 12:02 -0600, Jeff Law wrote:
> On 08/06/14 11:20, David Malcolm wrote:
> > gcc/
> > * sel-sched-ir.h (create_insn_rtx_from_pattern): Strengthen return
> > type from rtx to rtx_insn *.
> > * sel-sched-ir.h (create_copy_of_insn_rtx): Likewise.
> > * sel-sched-ir.c (create_insn_rtx_from_pattern): Likewise.
> > * sel-sched-ir.c (create_copy_of_insn_rtx): Likewise, also for
> > local "res".
> OK.
Thanks; committed to trunk as r214253.



Re: [PATCH 038/236] find_first_parameter_load returns an rtx_insn

2014-08-20 Thread David Malcolm
On Wed, 2014-08-13 at 12:01 -0600, Jeff Law wrote:
> On 08/06/14 11:20, David Malcolm wrote:
> > gcc/
> > * rtl.h (find_first_parameter_load): Strengthen return type from
> > rtx to rtx_insn *.
> > * rtlanal.c (find_first_parameter_load): Strengthen return type
> > from rtx to rtx_insn *.  Add checked cast for now, to postpone
> > strengthening the params.
> OK.

Thanks; committed to trunk as r214251, with trivial as_a_nullable ->
safe_as_a fixup.



[PATCH, rs6000] Enable and document some additional builtin overloads

2014-08-20 Thread Bill Schmidt
Hi,

The Power ISA 2.07 enables some additional forms of existing vector
builtins, in particular allowing use of vector long long (signed and
unsigned) and vector double forms.  This patch adds those builtins and
provides documentation for them.  There are also cases where builtins
from ISA 2.06 were not added for all possible vector types (for
instance, sometimes defining vector signed long long but omitting vector
unsigned long long).  This patch fixes those omissions as well.

I've added a new compile-only test that verifies the new forms are
accepted by the compiler.  I've bootstrapped and regtested this on
powerpc64le-unknown-linux-gnu with no regressions, and this new test
passes.  Is this ok for trunk?

Thanks,
Bill


[gcc]

2014-08-20  Bill Schmidt  

* config/rs6000/altivec.h (vec_cpsgn): New #define.
(vec_mergee): Likewise.
(vec_mergeo): Likewise.
(vec_cntlz): Likewise.
* config/rs600/rs6000-c.c (altivec_overloaded_builtins): Add new
entries for VEC_AND, VEC_ANDC, VEC_MERGEH, VEC_MERGEL, VEC_NOR,
VEC_OR, VEC_PACKSU, VEC_XOR, VEC_PERM, VEC_SEL, VEC_VCMPGT_P,
VMRGEW, and VMRGOW.
* doc/extend.texi: Document various forms of vec_cpsgn,
vec_splats, vec_and, vec_andc, vec_mergeh, vec_mergel, vec_nor,
vec_or, vec_perm, vec_sel, vec_sub, vec_xor, vec_all_eq,
vec_all_ge, vec_all_gt, vec_all_le, vec_all_lt, vec_all_ne,
vec_any_eq, vec_any_ge, vec_any_gt, vec_any_le, vec_any_lt,
vec_any_ne, vec_mergee, vec_mergeo, vec_packsu, and vec_cntlz.

[gcc/testsuite]

2014-08-20  Bill Schmidt  

* testsuite/gcc.target/powerpc/builtins-1.c: New test.


Index: gcc/config/rs6000/altivec.h
===
--- gcc/config/rs6000/altivec.h (revision 214242)
+++ gcc/config/rs6000/altivec.h (working copy)
@@ -124,6 +124,7 @@
 #define vec_vcfux __builtin_vec_vcfux
 #define vec_cts __builtin_vec_cts
 #define vec_ctu __builtin_vec_ctu
+#define vec_cpsgn __builtin_vec_copysign
 #define vec_expte __builtin_vec_expte
 #define vec_floor __builtin_vec_floor
 #define vec_loge __builtin_vec_loge
@@ -214,8 +215,10 @@
 #define vec_lvsl __builtin_vec_lvsl
 #define vec_lvsr __builtin_vec_lvsr
 #define vec_max __builtin_vec_max
+#define vec_mergee __builtin_vec_vmrgew
 #define vec_mergeh __builtin_vec_mergeh
 #define vec_mergel __builtin_vec_mergel
+#define vec_mergeo __builtin_vec_vmrgow
 #define vec_min __builtin_vec_min
 #define vec_mladd __builtin_vec_mladd
 #define vec_msum __builtin_vec_msum
@@ -336,6 +339,7 @@
 #define vec_vadduqm __builtin_vec_vadduqm
 #define vec_vbpermq __builtin_vec_vbpermq
 #define vec_vclz __builtin_vec_vclz
+#define vec_cntlz __builtin_vec_vclz
 #define vec_vclzb __builtin_vec_vclzb
 #define vec_vclzd __builtin_vec_vclzd
 #define vec_vclzh __builtin_vec_vclzh
Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 214242)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -884,6 +884,18 @@ const struct altivec_builtin_types altivec_overloa
   { ALTIVEC_BUILTIN_VEC_AND, ALTIVEC_BUILTIN_VAND,
 RS6000_BTI_V2DF, RS6000_BTI_bool_V2DI, RS6000_BTI_V2DF, 0 },
   { ALTIVEC_BUILTIN_VEC_AND, ALTIVEC_BUILTIN_VAND,
+RS6000_BTI_V2DI, RS6000_BTI_V2DI, RS6000_BTI_V2DI, 0 },
+  { ALTIVEC_BUILTIN_VEC_AND, ALTIVEC_BUILTIN_VAND,
+RS6000_BTI_V2DI, RS6000_BTI_V2DI, RS6000_BTI_bool_V2DI, 0 },
+  { ALTIVEC_BUILTIN_VEC_AND, ALTIVEC_BUILTIN_VAND,
+RS6000_BTI_V2DI, RS6000_BTI_bool_V2DI, RS6000_BTI_V2DI, 0 },
+  { ALTIVEC_BUILTIN_VEC_AND, ALTIVEC_BUILTIN_VAND,
+RS6000_BTI_unsigned_V2DI, RS6000_BTI_unsigned_V2DI, 
RS6000_BTI_unsigned_V2DI, 0 },
+  { ALTIVEC_BUILTIN_VEC_AND, ALTIVEC_BUILTIN_VAND,
+RS6000_BTI_unsigned_V2DI, RS6000_BTI_unsigned_V2DI, RS6000_BTI_bool_V2DI, 
0 },
+  { ALTIVEC_BUILTIN_VEC_AND, ALTIVEC_BUILTIN_VAND,
+RS6000_BTI_unsigned_V2DI, RS6000_BTI_bool_V2DI, RS6000_BTI_unsigned_V2DI, 
0 },
+  { ALTIVEC_BUILTIN_VEC_AND, ALTIVEC_BUILTIN_VAND,
 RS6000_BTI_bool_V4SI, RS6000_BTI_bool_V4SI, RS6000_BTI_bool_V4SI, 0 },
   { ALTIVEC_BUILTIN_VEC_AND, ALTIVEC_BUILTIN_VAND,
 RS6000_BTI_V4SI, RS6000_BTI_bool_V4SI, RS6000_BTI_V4SI, 0 },
@@ -938,6 +950,18 @@ const struct altivec_builtin_types altivec_overloa
   { ALTIVEC_BUILTIN_VEC_ANDC, ALTIVEC_BUILTIN_VANDC,
 RS6000_BTI_V2DF, RS6000_BTI_bool_V2DI, RS6000_BTI_V2DF, 0 },
   { ALTIVEC_BUILTIN_VEC_ANDC, ALTIVEC_BUILTIN_VANDC,
+RS6000_BTI_V2DI, RS6000_BTI_V2DI, RS6000_BTI_V2DI, 0 },
+  { ALTIVEC_BUILTIN_VEC_ANDC, ALTIVEC_BUILTIN_VANDC,
+RS6000_BTI_V2DI, RS6000_BTI_V2DI, RS6000_BTI_bool_V2DI, 0 },
+  { ALTIVEC_BUILTIN_VEC_ANDC, ALTIVEC_BUILTIN_VANDC,
+RS6000_BTI_V2DI, RS6000_BTI_bool_V2DI, RS6000_BTI_V2DI, 0 },
+  { ALTIVEC_BUILTIN_VEC_ANDC, ALTIVEC_BUILTIN_VANDC,
+RS6000_BTI_unsigned_V2DI, RS6000_BTI_unsigned_V2DI, 
RS6000_BTI_unsigned_V2DI, 0 },
+  { ALTIVEC_BUI

Re: [PATCH 037/236] sel_bb_{head|end} return rtx_insn

2014-08-20 Thread David Malcolm
On Wed, 2014-08-13 at 12:00 -0600, Jeff Law wrote:
> On 08/06/14 11:20, David Malcolm wrote:
> > gcc/
> > * sel-sched-ir.h (exit_insn): Strengthen from rtx to rtx_insn *.
> > (sel_bb_head): Strengthen return type insn_t (currently just an
> > rtx) to rtx_insn *.
> > (sel_bb_end): Likewise.
> >
> > * sel-sched-ir.c (exit_insn): Strengthen from rtx to rtx_insn *.
> > (sel_bb_head): Strengthen return type and local "head" from
> > insn_t (currently just an rtx) to rtx_insn *.
> > (sel_bb_end): Likewise for return type.
> > (free_nop_and_exit_insns): Replace use of NULL_RTX with NULL when
> > working with insn.
> OK.
Thanks; committed to trunk as r214247.



Re: [PATCH 036/236] get_last_bb_insn returns an rtx_insn

2014-08-20 Thread David Malcolm
On Wed, 2014-08-13 at 11:57 -0600, Jeff Law wrote:
> On 08/06/14 11:20, David Malcolm wrote:
> > gcc/
> > * basic-block.h (get_last_bb_insn): Strengthen return type from
> > rtx to rtx_insn *.
> > * cfgrtl.c (get_last_bb_insn): Likewise, and for locals "tmp" and
> > end".
> OK.
Thanks.  Committed to trunk as r214246 (having rerun bootstrap and
regrtest).



TAGs for variables created through common.opt

2014-08-20 Thread Aldy Hernandez
What are the rules for etags, is it fair game to generate them for 
variables defined in the build directory (as opposed to the source 
directory)?


For instance, my editor can't find flag_generate_lto because the TAGS 
rule in Makefile.in runs etags for source file *.h files (not those in 
the build directory).  Is it fair game to generate tags for "options.h" 
in the build directory, as this patch does?


The attached patch would point flag_generate_lto to the extern 
definition below.  Not ideal, but close enough:


#ifdef GENERATOR_FILE
extern int flag_generate_lto;
#else
  int x_flag_generate_lto;
#define flag_generate_lto global_options.x_flag_generate_lto

I suppose if we wanted to be pedantic, we should point it to the source 
in common.opt, but that would require:


a) hacking etags to support our .opt language.

b) hack one of the opt*.awk files to generate ad-hoc TAG entries directly.

c) Or perhaps even, add semicolons to the end of variable entries in the 
.opt files.  That way, we could more or less trick etags into thinking 
it's C.  Though things like HOST_WIDE_INT variables would not work.


Yes, I'm that lazy.  Why should I have to look around for something that 
can clearly be automated?


Aldy
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 1b3820b..549e7a3 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3792,6 +3792,7 @@ paranoia: paranoia.o real.o $(LIBIBERTY)
 
 # Update the tags table.
 TAGS: lang.tags
+   BUILD_DIR=`pwd`;\
(cd $(srcdir);  \
incs= ; \
list='$(SUBDIRS)'; for dir in $$list; do\
@@ -3799,7 +3800,8 @@ TAGS: lang.tags
incs="$$incs --include $$dir/TAGS.sub"; \
  fi;   \
done;   \
-   etags -o TAGS.sub c-family/*.h c-family/*.c *.h *.c *.cc; \
+   etags -o TAGS.sub c-family/*.h c-family/*.c *.h *.c *.cc \
+$$BUILD_DIR/options.h; \
etags --include TAGS.sub $$incs)
 
 # -


Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using

2014-08-20 Thread Chen Gang
On 08/21/2014 03:23 AM, Mike Stump wrote:
> On Aug 20, 2014, at 11:29 AM, Chen Gang  wrote:
>>
>> It sounds useful to me. At present, my PC is 4 core, so I guess, -j2
> 
> No, -j4….  should be around twice as fast as -j2 on your machine (assuming 
> you aren’t memory starved (4GB or more)).
> 
>> for 2 directories are enough. This time (without "--disable-multilibs),
>> I still use 1x, for I am not sure that it must be success.
> 
> Right, the -j won’t impact correctness, only speed of result.
> 

At present, normal "../gcc/configure && make" is OK for both original
directory and new directory. tonight, I shall run "make check" (I guess,
it shall be OK, too), then try to send related patch tomorrow morning.


Thanks.
-- 
Chen Gang

Open share and attitude like air water and life which God blessed


Re: [Patch] PR55189 enable -Wreturn-type by default

2014-08-20 Thread Joseph S. Myers
On Wed, 20 Aug 2014, Sylvestre Ledru wrote:

> On 20/08/2014 00:02, Joseph S. Myers wrote:
> > On Fri, 15 Aug 2014, Sylvestre Ledru wrote:
> >
> >> It is indeed useless. I removed it. Thanks
> >> http://sylvestre.ledru.info/0001-Enable-warning-Wreturn-type-by-default.patch
> > I don't think most of the testsuite changes in this patch should be 
> > needed, and we should be conservative about changing existing testcases 
> > because of the risk that it affects what they test.  Most of the changes 
> > seem like they would only have been relevant for the previous version that 
> > enabled -Wmissing-return warnings by default.
> >
> > The change to gcc.dg/c90-impl-int-1.c is simply wrong - the specific point 
> > of that testcase is to test various cases of implicit int, so you can't 
> > add explicit int return types to it.
> >
> > You need, obviously, the new tests for how -W(no-)missing-return and 
> > -W(no-)return-type work and what the defaults are.  Existing tests should 
> > only need to be changed if they do in fact fail with the compiler patch 
> > applied.
> >
> Thanks for the feedback.
> I updated the patch (including the gcc.dg/c90-impl-int-1.c change):
> http://sylvestre.ledru.info/0001-Enable-warning-Wreturn-type-by-default.patch
> 
> For information, the number of files modified by this commit dropped
> from 1298 to 818.

Are you sure that's the right patch?

* It seems to be missing the new testcases, which are a necessary part of 
the patch.

* The first few testcase changes I looked at in the patch still don't make 
sense to me.  They are changing int return types to void, or adding 
"return 0;", which should not be needed with the defaults as I understand 
them - the warnings for those should be the "control reaches end of 
non-void function" which I thought was being left off by default.  If 
those are getting warnings (for C) without the changes, there's something 
I still don't understand about what this patch is doing and why it's meant 
to be safe.

Could you clarify - in terms of source code constructs, not option names - 
which cases your patch would or would not cause to receive warnings by 
default for C?

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [Patch] PR55189 enable -Wreturn-type by default

2014-08-20 Thread Sylvestre Ledru
On 20/08/2014 00:02, Joseph S. Myers wrote:
> On Fri, 15 Aug 2014, Sylvestre Ledru wrote:
>
>> It is indeed useless. I removed it. Thanks
>> http://sylvestre.ledru.info/0001-Enable-warning-Wreturn-type-by-default.patch
> I don't think most of the testsuite changes in this patch should be 
> needed, and we should be conservative about changing existing testcases 
> because of the risk that it affects what they test.  Most of the changes 
> seem like they would only have been relevant for the previous version that 
> enabled -Wmissing-return warnings by default.
>
> The change to gcc.dg/c90-impl-int-1.c is simply wrong - the specific point 
> of that testcase is to test various cases of implicit int, so you can't 
> add explicit int return types to it.
>
> You need, obviously, the new tests for how -W(no-)missing-return and 
> -W(no-)return-type work and what the defaults are.  Existing tests should 
> only need to be changed if they do in fact fail with the compiler patch 
> applied.
>
Thanks for the feedback.
I updated the patch (including the gcc.dg/c90-impl-int-1.c change):
http://sylvestre.ledru.info/0001-Enable-warning-Wreturn-type-by-default.patch

For information, the number of files modified by this commit dropped
from 1298 to 818.

Thanks,
Sylvestre



[c++-concepts] template scoping error

2014-08-20 Thread Andrew Sutton
Fixes a regression in lookup rules involving declarations with
nested-name-specifiers. In particular, we don't actually want to
execute these rules if we absolutely don't have to.

2014-08-15  Andrew Sutton  

Fixing regression in scoping rules for templates.
* gcc/cp/semantics.c (fixup_tmeplate_type): Lift check to
finish_template_type.
(finish_template_type): Only do this when concepts are enabled,
and also when the class is actually a template. For non-dependent
types there are no actions to be taken.

Andrew Sutton
Index: gcc/cp/semantics.c
===
--- gcc/cp/semantics.c	(revision 214228)
+++ gcc/cp/semantics.c	(working copy)
@@ -3004,10 +3004,6 @@ finish_template_decl (tree parms)
 static tree
 fixup_template_type (tree type)
 {
-  // Don't try to fix non-class types.
-  if (!CLASS_TYPE_P (type))
-return type;
-
   // Find the template parameter list at the a depth appropriate to
   // the scope we're trying to enter. 
   tree parms = current_template_parms;
@@ -3055,8 +3051,12 @@ finish_template_type (tree name, tree ar
 NULL_TREE, NULL_TREE, entering_scope,
 tf_warning_or_error | tf_user);
 
-  // If entering a scope, correct the lookup to account for constraints.
-  if (entering_scope)
+  // If entering a scope of a template, correct the lookup to 
+  // account for constraints.
+  if (flag_concepts 
+  && entering_scope 
+  && CLASS_TYPE_P (type) 
+  && CLASSTYPE_IS_TEMPLATE (type))
 type = fixup_template_type (type);
 
   if (type == error_mark_node)


Re: [c++-concepts] variable concept fixes

2014-08-20 Thread Andrew Sutton
> On 08/20/2014 08:56 PM, Andrew Sutton wrote:
>>
>> +  return VAR_P (decl)
>> + && DECL_LANG_SPECIFIC (decl)
>> + && DECL_DECLARED_CONCEPT_P (decl);
>
> this is brittle from the formatting point of view. Please double check in
> detail what I'm going to say, but I think that in such cases you simply want
> to wrap the whole thing in round parentheses.

Sorry, did you just mean to wrap the entire conjunction in parens? I'm
trying to find the formatting guidelines to check, but not succeeding
at the moment.

Andrew


Re: [C++ PATCH] Fix -Wlogical-not-parentheses (PR c++/62199)

2014-08-20 Thread Jason Merrill

On 08/20/2014 04:02 PM, Marek Polacek wrote:

On Wed, Aug 20, 2014 at 02:36:21PM -0400, Jason Merrill wrote:

Could we set current.lhs_type to TRUTH_NOT_EXPR when we see a ! rather than
track nots in two separate local variables?


Good point.  So like the following?


I was thinking to do away with parenthesized_not_lhs_warn as well, so 
instead of



  bool parenthesized_not_lhs_warn
= cp_lexer_next_token_is (parser->lexer, CPP_NOT);

  /* Parse the first expression.  */
  current.lhs = cp_parser_cast_expression (parser, /*address_p=*/false,
   cast_p, decltype_p, pidk);
  current.lhs_type = ERROR_MARK;


we would set current.lhs_type to TRUTH_NOT_EXPR here if the first token 
is CPP_NOT, and



  /* Extract another operand.  It may be the RHS of this expression
 or the LHS of a new, higher priority expression.  */
  rhs = cp_parser_simple_cast_expression (parser);
  rhs_type = ERROR_MARK;


here we would do the same thing for rhs_type.


   cp_lexer_consume_token (parser->lexer);
+  if (cp_lexer_next_token_is (parser->lexer, CPP_NOT))
+   current.lhs_type = TRUTH_NOT_EXPR;

...

  current.lhs = rhs;
+ parenthesized_not_lhs_warn = current.lhs_type == TRUTH_NOT_EXPR;
  current.lhs_type = rhs_type;


and then you don't need any changes in these places.


   if (warn_logical_not_paren
  && parenthesized_not_lhs_warn)


And here you check current.lhs_type.

Jason



Re: [Patch] Switch elimination pass for PR 54742

2014-08-20 Thread Sebastian Pop
James Greenhalgh wrote:
> On Tue, Aug 19, 2014 at 09:39:56PM +0100, Steve Ellcey wrote:
> > Here is an official submission for the switch optimization described in
> > PR 54742.  I have addressed the formatting/comment issues that were raised
> > and also added a test case based on comment #27 from PR 54742 and I fixed a
> > bug I found while doing benchmarking with SPEC2006 (the perl benchmark was
> > generating an ICE in a routine with multiple switch statements).
> > 
> > I ran the benchmarking to see if I could find any more tests that are
> > helped like coremark is and while I found a number of benchmarks in
> > SPEC 2006 and EEMBC where the optimization is triggered, this optimization
> > generally didn't affect the performance of those benchmarks.  The biggest
> > impact I could find was on the perl benchmark in SPEC where I saw around
> > a 0.4% improvement on a MIPS 74k.  Not huge, but not nothing.
> 
> For what it is worth, I see a nice (~4%) improvement in Crafty from
> SPEC 2000. I haven't investigated too deeply, but at a first glance the
> number of branch mispredictions has dropped just over 1%, as you
> might hope from this optimisation.
> 
> I can also attest to there being a number of places the optimisation is
> triggered (with high enough parameters; I was running with
> --param max-switch-paths=1000 --param max-switch-insns=1), but like
> you I don't see much measurable change in execution time.

Without change to the default params, I see the switch shortcut having a
performance impact on both png and jpeg, compress and decompress mode.

I think that's enough to remove the "benchmarketing" label from the switch
shortcut transform.

Sebastian


Re: [PATCH] Add support for GNU/Hurd in gnat-4.9

2014-08-20 Thread Svante Signell
On Wed, 2014-05-21 at 10:48 +0200, Samuel Thibault wrote:
> Svante Signell, le Wed 21 May 2014 10:44:54 +0200, a écrit :
> > On Wed, 2014-05-21 at 10:33 +0200, Arnaud Charlet wrote:
> > > > > I think the majority of work has bee done, Now that patch will change
> > > > > slightly for every missing feature added to Hurd.
> > > > 
> > > > Then it's all good, it's a matter of what I said above.
> > > 
> > > Don't forget also the part where general changes are done in GNAT which
> > > require update to target specific files: these typically require someone
> > > to regularly test each port to detect any missing update, and report/fix
> > > them, even if GNU/Hurd hasn't changed itself.
> > 
> > With the help from the dabian-ada people, especially Ludovic Brenta,
> > gnat has been running on GNU/Hurd in Debian since gcc/gnat-4.6.3.
> 
> Then it's all good.  Just say that you wish to continue maintaining
> things like this, and upstream will be happy.

Attached is the updated ada-hurd.diff patch for GNU/Hurd. It builds fine
with gnat-4.9.1-1 and gcc-4.9.1-7. This patch now has the same amount of
files as the kFreeBSD patch. Hopefully it can be material for upstream,
but at least in Debian the Hurd port would be on par with kFreeBSD.
Regarding remaining code commented out or irrelevant comments in the new
file s-osinte-gnu.ads, please help me to iron out the left-overs.

Ludovic, can you consider using this file as ada-hurd.diff for next
upload of Debian gnat-4.9?

For clarity: I wish to continue to maintain the Ada port for Hurd, with
the help of the Debian Ada and Hurd people, with or without being
imported upstream.

Thanks!
Index: gnat-4.9-4.9.0/src/gcc/ada/s-osinte-gnu.ads
===
--- /dev/null
+++ gnat-4.9-4.9.0/src/gcc/ada/s-osinte-gnu.ads
@@ -0,0 +1,804 @@
+--
+--  --
+--GNU ADA RUN-TIME LIBRARY (GNARL) COMPONENTS   --
+--  --
+--   S Y S T E M . O S _ I N T E R F A C E  --
+--  --
+--  S p e c --
+--  --
+-- Copyright (C) 1991-1994, Florida State University--
+--  Copyright (C) 1995-2014, Free Software Foundation, Inc. --
+--  --
+-- GNAT is free software;  you can  redistribute it  and/or modify it under --
+-- terms of the  GNU General Public License as published  by the Free Soft- --
+-- ware  Foundation;  either version 3,  or (at your option) any later ver- --
+-- sion.  GNAT is distributed in the hope that it will be useful, but WITH- --
+-- OUT ANY WARRANTY;  without even the  implied warranty of MERCHANTABILITY --
+-- or FITNESS FOR A PARTICULAR PURPOSE. --
+--  --
+-- As a special exception under Section 7 of GPL version 3, you are granted --
+-- additional permissions described in the GCC Runtime Library Exception,   --
+-- version 3.1, as published by the Free Software Foundation.   --
+--  --
+-- You should have received a copy of the GNU General Public License and--
+-- a copy of the GCC Runtime Library Exception along with this program; --
+-- see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see--
+-- .  --
+--  --
+-- GNARL was developed by the GNARL team at Florida State University.   --
+-- Extensive contributions were provided by Ada Core Technologies, Inc. --
+--  --
+--
+
+--  This is the GNU/Hurd (POSIX Threads) version of this package
+
+--  This package encapsulates all direct interfaces to OS services
+--  that are needed by children of System.
+
+--  PLEASE DO NOT add any with-clauses to this package or remove the pragma
+--  Preelaborate. This package is designed to be a bottom-level (leaf) package
+
+with Interfaces.C;
+with Unchecked_Conversion;
+
+package System.OS_Interface is
+   pragma Preelaborate;
+
+   pragma Linker_Options ("-lpthread");
+   pragma Linker_Options ("-lrt");
+
+   subtype intis Interfaces.C.int;
+   subtype char   is Interfaces.C.char;
+   subtype short  is Interfaces.C.s

Re: [C++ PATCH] Fix -Wlogical-not-parentheses (PR c++/62199)

2014-08-20 Thread Marek Polacek
On Wed, Aug 20, 2014 at 02:36:21PM -0400, Jason Merrill wrote:
> Could we set current.lhs_type to TRUTH_NOT_EXPR when we see a ! rather than
> track nots in two separate local variables?

Good point.  So like the following?  I haven't had time to run the full
regtest/bootstrap cycle yet, but at least the -Wlogical-not-parentheses
testcases and dg.exp pass.

2014-08-20  Marek Polacek  

PR c++/62199
* parser.c (cp_parser_binary_expression): Check each LHS if it's
preceded with logical not.  Handle logical not of constants.

* c-c++-common/pr62199.c: New test.

diff --git gcc/cp/parser.c gcc/cp/parser.c
index 9053bfa..18705ee 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -8071,6 +8071,8 @@ cp_parser_binary_expression (cp_parser* parser, bool 
cast_p,
 
   /* We used the operator token.  */
   cp_lexer_consume_token (parser->lexer);
+  if (cp_lexer_next_token_is (parser->lexer, CPP_NOT))
+   current.lhs_type = TRUTH_NOT_EXPR;
 
   /* For "false && x" or "true || x", x will never be executed;
 disable warnings while evaluating it.  */
@@ -8098,6 +8100,7 @@ cp_parser_binary_expression (cp_parser* parser, bool 
cast_p,
  *sp = current;
  ++sp;
  current.lhs = rhs;
+ parenthesized_not_lhs_warn = current.lhs_type == TRUTH_NOT_EXPR;
  current.lhs_type = rhs_type;
  current.prec = new_prec;
  new_prec = lookahead_prec;
@@ -8126,8 +8129,17 @@ cp_parser_binary_expression (cp_parser* parser, bool 
cast_p,
 
   if (warn_logical_not_paren
  && parenthesized_not_lhs_warn)
-   warn_logical_not_parentheses (current.loc, current.tree_type,
- TREE_OPERAND (current.lhs, 0), rhs);
+   {
+ tree lhs;
+ /* If the LHS was !CST, we have true/false now.  Convert it
+to integer type, otherwise we wouldn't warn.  */
+ if (TREE_CODE (current.lhs) == INTEGER_CST)
+   lhs = convert (integer_type_node, current.lhs);
+ else
+   lhs = TREE_OPERAND (current.lhs, 0);
+ warn_logical_not_parentheses (current.loc, current.tree_type,
+   lhs, rhs);
+   }
 
   overload = NULL;
   /* ??? Currently we pass lhs_type == ERROR_MARK and rhs_type ==
diff --git gcc/testsuite/c-c++-common/pr62199.c 
gcc/testsuite/c-c++-common/pr62199.c
index e69de29..51078c8 100644
--- gcc/testsuite/c-c++-common/pr62199.c
+++ gcc/testsuite/c-c++-common/pr62199.c
@@ -0,0 +1,22 @@
+/* PR c++/62199 */
+/* { dg-do compile } */
+/* { dg-options "-Wlogical-not-parentheses" } */
+
+int r;
+void
+foo (int a)
+{
+  r = a > 0 || !a >= 2; /* { dg-warning "19:logical not is only applied to the 
left hand side of comparison" } */
+  r = !a || a == 10;
+  r = !a && !a < 4; /* { dg-warning "16:logical not is only applied to the 
left hand side of comparison" } */
+  r = !a > 0 && a < 6; /* { dg-warning "10:logical not is only applied to the 
left hand side of comparison" } */
+  r = a + (!a < 12); /* { dg-warning "15:logical not is only applied to the 
left hand side of comparison" } */
+  r = a == 7 || !a < 12; /* { dg-warning "20:logical not is only applied to 
the left hand side of comparison" } */
+  r = (a == 7 * a > 0) || !a < 2; /* { dg-warning "30:logical not is only 
applied to the left hand side of comparison" } */
+  r = (1 > !a) || (!42 > a); /* { dg-warning "24:logical not is only applied 
to the left hand side of comparison" } */
+  r = (!5 > a); /* { dg-warning "11:logical not is only applied to the left 
hand side of comparison" } */
+  r = (!0 > a); /* { dg-warning "11:logical not is only applied to the left 
hand side of comparison" } */
+  r = (!-5 > a); /* { dg-warning "12:logical not is only applied to the left 
hand side of comparison" } */
+  r = (!(5 + 3) > a); /* { dg-warning "17:logical not is only applied to the 
left hand side of comparison" } */
+  r = (!(5 - a) > a); /* { dg-warning "17:logical not is only applied to the 
left hand side of comparison" } */
+}

Marek


Re: [Patch AArch64] Fix for PR62040

2014-08-20 Thread Carrot Wei
Good suggestion. Add the testcase.

thanks
Guozhi Wei

2014-08-20  Guozhi Wei  

PR target/62040
* gcc.target/aarch64/pr62040.c: New test.

Index: pr62040.c
===
--- pr62040.c (revision 0)
+++ pr62040.c (revision 0)
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-g -Os" } */
+
+#include "arm_neon.h"
+
+extern bar(int32x4_t);
+
+void foo() {
+  int32x4x4_t rows;
+  uint64x2x2_t row01;
+
+  row01.val[0] = vreinterpretq_u64_s32(rows.val[0]);
+  row01.val[1] = vreinterpretq_u64_s32(rows.val[1]);
+  uint64x1_t row3l = vget_low_u64(row01.val[0]);
+  row01.val[0] = vcombine_u64(vget_low_u64(row01.val[1]), row3l);
+  int32x4_t xxx = vreinterpretq_s32_u64(row01.val[0]);
+  int32x4_t out = vtrn1q_s32 (xxx, xxx);
+  bar(out);
+}

On Wed, Aug 20, 2014 at 4:26 AM, Kyrill Tkachov  wrote:
> Hi Carrot,
>
> cc'ing the aarch64 maintainers...
>
>
> On 20/08/14 00:43, Carrot Wei wrote:
>>
>> Hi
>>
>> Current AArch64 backend can generate rtl expressions like
>> (vec_duplicate:DI (const_int 0 [0])), which causes ICE in
>> simplify_const_unary_operation because vec_duplicate should generate
>> vector mode only.
>>
>> As suggested by Andrew in the bug entry, I split the original insn
>> patterns to avoid scalar mode vec_duplicate expression.
>
>
> The documentation does say that vec_concat can work on scalars, so it seems
> ok to me at a glance (but I can't approve it myself).
>
> Would be nice to have an addition to the testsuite though...
>
> Kyrill
>
>
>> Passed regression tests on qemu without failure.
>> OK for trunk and 4.9 branch?
>>
>> thanks
>> Guozhi Wei
>>
>> 2014-08-19  Guozhi Wei  
>>
>>  PR target/62040
>>  * config/aarch64/iterators.md (VQ_NO2E, VQ_2E): New iterators.
>>  * config/aarch64/aarch64-simd.md (move_lo_quad_internal_):
>> Split
>>  it into two patterns.
>>  (move_lo_quad_internal_be_): Likewise.
>
>
>


Re: [c++-concepts] variable concept fixes

2014-08-20 Thread Paolo Carlini

Hi,

On 08/20/2014 08:56 PM, Andrew Sutton wrote:

+  return VAR_P (decl)
+ && DECL_LANG_SPECIFIC (decl)
+ && DECL_DECLARED_CONCEPT_P (decl);
this is brittle from the formatting point of view. Please double check 
in detail what I'm going to say, but I think that in such cases you 
simply want to wrap the whole thing in round parentheses.


Paolo.


Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using

2014-08-20 Thread Mike Stump
On Aug 20, 2014, at 11:29 AM, Chen Gang  wrote:
> 
> It sounds useful to me. At present, my PC is 4 core, so I guess, -j2

No, -j4….  should be around twice as fast as -j2 on your machine (assuming you 
aren’t memory starved (4GB or more)).

> for 2 directories are enough. This time (without "--disable-multilibs),
> I still use 1x, for I am not sure that it must be success.

Right, the -j won’t impact correctness, only speed of result.


[c++-concepts] variable concept fixes

2014-08-20 Thread Andrew Sutton
Add more diagnostics for variable concepts. Also fix a regression
where non-template concepts variables were causing ICEs because they
aren't being allocated via build_lang_decl.

2014-08-15  Andrew Sutton  

Additional declaration restrictions on variable concepts.
* gcc/cp/decl.c (is_concept_var): New.
(cp_finish_decl): Check for uninitialized variable
concepts.
(grokvardecl): Don't set the concept flag for non-template variables.
* g++.dg/concepts/decl-diagnose.C: Add tests.

Andrew Sutton
Index: gcc/cp/decl.c
===
--- gcc/cp/decl.c	(revision 214239)
+++ gcc/cp/decl.c	(working copy)
@@ -6259,6 +6259,16 @@ value_dependent_init_p (tree init)
   return false;
 }
 
+// Returns true if a DECL is VAR_DECL with the concept specifier. Note
+// that not all variables are decl-lang-specific.
+static inline bool
+is_concept_var (tree decl) 
+{
+  return VAR_P (decl) 
+ && DECL_LANG_SPECIFIC (decl)
+ && DECL_DECLARED_CONCEPT_P (decl);
+}
+
 /* Finish processing of a declaration;
install its line number and initial value.
If the length of an array type is not known before,
@@ -6435,6 +6445,8 @@ cp_finish_decl (tree decl, tree init, bo
 	init = NULL_TREE;
 	  release_tree_vector (cleanups);
 	}
+  else if (!init && is_concept_var (decl))
+error ("variable concept has no initializer");
   else if (!DECL_PRETTY_FUNCTION_P (decl))
 	{
 	  /* Deduce array size even if the initializer is dependent.  */
@@ -8264,9 +8276,17 @@ grokvardecl (tree type,
   else
 DECL_INTERFACE_KNOWN (decl) = 1;
 
-  // Mark the variable as a concept.
+  // Check that the variable can be safely declared as a concept.
   if (conceptp)
-DECL_DECLARED_CONCEPT_P (decl) = true;
+{
+  if (!processing_template_decl) 
+{
+  error ("a non-template variable cannot be %");
+  return NULL_TREE;
+}
+  else
+DECL_DECLARED_CONCEPT_P (decl) = true;
+}
 
   // Handle explicit specializations and instantiations of variable templates.
   if (orig_declarator)


Re: [C++ PATCH] Fix -Wlogical-not-parentheses (PR c++/62199)

2014-08-20 Thread Jason Merrill
Could we set current.lhs_type to TRUTH_NOT_EXPR when we see a ! rather 
than track nots in two separate local variables?


Jason


Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using

2014-08-20 Thread Chen Gang
On 08/21/2014 01:35 AM, Mike Stump wrote:
> On Aug 20, 2014, at 7:26 AM, Chen Gang  wrote:
>> - for each test, always contents "unexpected errors" for gcc, g++ ...
>>   but "make check" skip them and continue, at last still "echo $?" = 0.
> 
> I use make -k -j16.  It is roughly 16x faster.  I’d use -j where n is the 
> core count.  I think -k is useful to ensure all the tests always run.  If 
> make check returns 0, then the -k won’t make a difference.  When non-zero, 
> then it might.
> 

It sounds useful to me. At present, my PC is 4 core, so I guess, -j2
for 2 directories are enough. This time (without "--disable-multilibs),
I still use 1x, for I am not sure that it must be success.


Thanks.
-- 
Chen Gang

Open share and attitude like air water and life which God blessed


Re: [PATCH] gcc/c/c-aux-info.c: Resize 'buff' from 10 to 14 bytes

2014-08-20 Thread Chen Gang
On 08/21/2014 02:06 AM, Joseph S. Myers wrote:
> On Sun, 17 Aug 2014, Chen Gang wrote:
> 
>> 2014-08-17  Chen Gang  
>>
>>  * c/c-aux-info.c (gen_type): Resize 'buff' from 10 to 23 bytes.
> 
> This patch is OK, subject to testing, though the ChangeLog entry needs to 
> reflect the change to using HOST_WIDE_INT without truncation to int.
> 

OK, thanks, I shall notice about it when send patch v2.

I have finished testsuit with "--disable-multilibs", successfully, and
all 11 "*.sum" files are the 'same'. I am just running with normal
configuration (without "--disable-multilibs").

Hope I can send patch v2 tomorrow.

Thanks.
-- 
Chen Gang

Open share and attitude like air water and life which God blessed


Re: [PATCH] gcc/c/c-aux-info.c: Resize 'buff' from 10 to 14 bytes

2014-08-20 Thread Joseph S. Myers
On Sun, 17 Aug 2014, Chen Gang wrote:

> 2014-08-17  Chen Gang  
> 
>   * c/c-aux-info.c (gen_type): Resize 'buff' from 10 to 23 bytes.

This patch is OK, subject to testing, though the ChangeLog entry needs to 
reflect the change to using HOST_WIDE_INT without truncation to int.

-- 
Joseph S. Myers
jos...@codesourcery.com


[C++ PATCH] Fix -Wlogical-not-parentheses (PR c++/62199)

2014-08-20 Thread Marek Polacek
Today I was playing with my -Wlogical-not-parentheses warning and
unfortunately I discovered two bugs:
1) if we have an expression consisting of more binary subexpression,
   such as "n > 5 || !n < 10", we don't warn for the second subexpr,
   because the code looked for "!" only on the very first LHS.  Fixed
   by introducing a temporary flag that says whether an expression has
   "!" - and if this expr turns out to be a LHS, warn.
2) ICE with e.g. "!42 > n".  The result of the LHS is a constant, so we
   can't use TREE_OPERAND on it.

The C FE happens to be fine and doesn't need any tweaks.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2014-08-20  Marek Polacek  

PR c++/62199
* parser.c (cp_parser_binary_expression): Check each LHS if it's
preceded with logical not.  Handle logical not of constants.

* c-c++-common/pr62199.c: New test.

diff --git gcc/cp/parser.c gcc/cp/parser.c
index 9053bfa..3b02349 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -8034,6 +8034,7 @@ cp_parser_binary_expression (cp_parser* parser, bool 
cast_p,
 
   for (;;)
 {
+  bool not_expr_save;
   /* Get an operator token.  */
   token = cp_lexer_peek_token (parser->lexer);
 
@@ -8071,6 +8072,7 @@ cp_parser_binary_expression (cp_parser* parser, bool 
cast_p,
 
   /* We used the operator token.  */
   cp_lexer_consume_token (parser->lexer);
+  not_expr_save = cp_lexer_next_token_is (parser->lexer, CPP_NOT);
 
   /* For "false && x" or "true || x", x will never be executed;
 disable warnings while evaluating it.  */
@@ -8101,6 +8103,7 @@ cp_parser_binary_expression (cp_parser* parser, bool 
cast_p,
  current.lhs_type = rhs_type;
  current.prec = new_prec;
  new_prec = lookahead_prec;
+ parenthesized_not_lhs_warn = not_expr_save;
  goto get_rhs;
 
 pop:
@@ -8126,8 +8129,17 @@ cp_parser_binary_expression (cp_parser* parser, bool 
cast_p,
 
   if (warn_logical_not_paren
  && parenthesized_not_lhs_warn)
-   warn_logical_not_parentheses (current.loc, current.tree_type,
- TREE_OPERAND (current.lhs, 0), rhs);
+   {
+ tree lhs;
+ /* If the LHS was !CST, we have true/false now.  Convert it
+to integer type, otherwise we wouldn't warn.  */
+ if (TREE_CODE (current.lhs) == INTEGER_CST)
+   lhs = convert (integer_type_node, current.lhs);
+ else
+   lhs = TREE_OPERAND (current.lhs, 0);
+ warn_logical_not_parentheses (current.loc, current.tree_type,
+   lhs, rhs);
+   }
 
   overload = NULL;
   /* ??? Currently we pass lhs_type == ERROR_MARK and rhs_type ==
diff --git gcc/testsuite/c-c++-common/pr62199.c 
gcc/testsuite/c-c++-common/pr62199.c
index e69de29..3191151 100644
--- gcc/testsuite/c-c++-common/pr62199.c
+++ gcc/testsuite/c-c++-common/pr62199.c
@@ -0,0 +1,22 @@
+/* PR c++/62199 */
+/* { dg-do compile } */
+/* { dg-options "-Wlogical-not-parentheses" } */
+
+int r;
+void
+foo (int a)
+{
+  r = a > 0 || !a >= 2; /* { dg-warning "19:logical not is only applied to the 
left hand side of comparison" } */
+  r = !a || a == 10;
+  r = !a && !a < 4; /* { dg-warning "16:logical not is only applied to the 
left hand side of comparison" } */
+  r = !a > 0 && a < 6; /* { dg-warning "10:logical not is only applied to the 
left hand side of comparison" } */
+  r = a + (!a < 12); /* { dg-warning "15:logical not is only applied to the 
left hand side of comparison" } */
+  r = a == 7 || !a < 12; /* { dg-warning "20:logical not is only applied to 
the left hand side of comparison" } */
+  r = (a == 7 * a > 0) || !a < 2; /* { dg-warning "30:logical not is only 
applied to the left hand side of comparison" } */
+  r = (1 > !a) || (!42 > a); /* { dg-warning "24:logical not is only applied 
to the left hand side of comparison" } */
+  r = (!5 > a); /* { dg-warning "11:logical not is only applied to the left 
hand side of comparison" } */
+  r = (!0 > a); /* { dg-warning "11:logical not is only applied to the left 
hand side of comparison" } */
+  r = (!-5 > a); /* { dg-warning "12:logical not is only applied to the left 
hand side of comparison" } */
+  r = (!(5 + 3) > a); /* { dg-warning "17:logical not is only applied to the 
left hand side of comparison" } */
+  r = (!(5 - a) > a); /* { dg-warning "17:logical not is only applied to the 
left hand side of comparison" } */
+}

Marek


Re: PR62203 (was Re: [PATCH 035/236] Return types of unlink_insn_chain and duplicate_insn_chain)

2014-08-20 Thread David Malcolm
On Wed, 2014-08-20 at 12:09 -0400, David Malcolm wrote:
> On Wed, 2014-08-20 at 06:19 -0400, David Malcolm wrote:
> > On Wed, 2014-08-20 at 10:20 +0200, Andreas Schwab wrote:
> > > David Malcolm  writes:
> > > 
> > > > @@ -4083,7 +4083,7 @@ cfg_layout_can_duplicate_bb_p (const_basic_block 
> > > > bb)
> > > >return true;
> > > >  }
> > > >  
> > > > -rtx
> > > > +rtx_insn *
> > > >  duplicate_insn_chain (rtx from, rtx to)
> > > >  {
> > > >rtx insn, next, copy;
> > > > @@ -4169,7 +4169,7 @@ duplicate_insn_chain (rtx from, rtx to)
> > > >  }
> > > >insn = NEXT_INSN (last);
> > > >delete_insn (last);
> > > > -  return insn;
> > > > +  return as_a  (insn);
> > > 
> > > This is wrong, insn may be NULL.
> > 
> > Thanks; and indeed, this broke the bootstrap, as noted in:
> > https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01964.html
> > 
> > Fixed in r214207:
> > https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01971.html
> 
> ...and this has subsequently been filed as PR62203 (retitling
> accordingly).
> 
> > Sorry.  I'm trying to figure out why this didn't break during my
> > testing.  Patch #60 of the original series contained an equivalent as_a
> > -> as_a_nullable hunk:
> > https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00708.html
> > - albeit with a misleading ChangeLog entry (I'm assuming I messed that
> > up during a rebase) - but this hadn't been applied yet.
> 
> I just reran a bootstrap with patches 4-35 containing the unsafe as_a
> cast from #35, on top of r213973 (from 2014-08-14), and somehow it
> successfully bootstrapped and regression tested on
> x86_64-unknown-linux-gnu (Fedora 20).  r213973 has been the baseline
> I've been testing and patching against.
> 
> So presumably something changed *since* r213973 to make the bug in patch
> #35 show itself when applied on a more recent trunk (I was able to
> reproduce the bug on the same machine, with the same configure flags).
> 
> Bother.

I figured this out: my testing bootstrap had a stray
   --enable-checking=release
which meant that the as_a wasn't running the is_a_helper, and hence
gracefully handled a NULL insn.

Fixed now in my testing setup, and am rerunning bootstrap for the
followup patches.

Sorry again.

> I'll rebase against a more recent trunk and retest accordingly for the
> followup patches.  I'll also take another look at the patches that add
> as_a<> (as opposed to safe_as_a<>) [Does this make a case for adding the
> safety check to the is_a_helper functions, and dropping safe_as_a
> variant altogether?]
> 
> Sorry about this
> Dave




Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using

2014-08-20 Thread Mike Stump
On Aug 20, 2014, at 7:26 AM, Chen Gang  wrote:
> - for each test, always contents "unexpected errors" for gcc, g++ ...
>   but "make check" skip them and continue, at last still "echo $?" = 0.

I use make -k -j16.  It is roughly 16x faster.  I’d use -j where n is the 
core count.  I think -k is useful to ensure all the tests always run.  If make 
check returns 0, then the -k won’t make a difference.  When non-zero, then it 
might.

Re: [Patch] Switch elimination pass for PR 54742

2014-08-20 Thread James Greenhalgh
On Tue, Aug 19, 2014 at 09:39:56PM +0100, Steve Ellcey wrote:
> Here is an official submission for the switch optimization described in
> PR 54742.  I have addressed the formatting/comment issues that were raised
> and also added a test case based on comment #27 from PR 54742 and I fixed a
> bug I found while doing benchmarking with SPEC2006 (the perl benchmark was
> generating an ICE in a routine with multiple switch statements).
> 
> I ran the benchmarking to see if I could find any more tests that are
> helped like coremark is and while I found a number of benchmarks in
> SPEC 2006 and EEMBC where the optimization is triggered, this optimization
> generally didn't affect the performance of those benchmarks.  The biggest
> impact I could find was on the perl benchmark in SPEC where I saw around
> a 0.4% improvement on a MIPS 74k.  Not huge, but not nothing.

For what it is worth, I see a nice (~4%) improvement in Crafty from
SPEC 2000. I haven't investigated too deeply, but at a first glance the
number of branch mispredictions has dropped just over 1%, as you
might hope from this optimisation.

I can also attest to there being a number of places the optimisation is
triggered (with high enough parameters; I was running with
--param max-switch-paths=1000 --param max-switch-insns=1), but like
you I don't see much measurable change in execution time.

Thanks,
James

> 
> So, OK to checkin?
> 
> Steve Ellcey
> sell...@mips.com
> 
> 
> 2014-08-12  Steve Ellcey  
> 
>   PR tree-opt/54742
>   * Makefile.in (OBJS): Add tree-switch-shortcut.o.
>   * common.opt (ftree-switch-shortcut): New.
>   * opts.c (default_options_table): Add OPT_ftree_switch_shortcut.
>   * params.def (PARAM_MAX_SWITCH_INSNS): New.
>   (PARAM_MAX_SWITCH_PATHS): New.
>   * passes.def (pass_tree_switch_shortcut): New.
>   * timevar.def (TV_TREE_SWITCH_SHORTCUT): New.
>   * tree-pass.h (make_pass_tree_switch_shortcut): New.
>   * tree-switch-shortcut.c: New.
> 
> 
> 2014-08-12  Steve Ellcey  
> 
>   PR tree-opt/54742
>   * gcc.dg/pr54742.c: New test.

> diff --git a/gcc/testsuite/gcc.dg/pr54742.c b/gcc/testsuite/gcc.dg/pr54742.c
> new file mode 100644
> index 000..77aa8ba
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr54742.c
> @@ -0,0 +1,50 @@
> +/* PR tree-optimization/54742
> +   Verify that the tree-optimization-shortcut pass completely removes
> +   the switch statement.  */
> +
> +/* { dg-do compile } */
> +/* { dg-options "-O3" } */
> +
> +int sum0, sum1, sum2, sum3;
> +int foo(char * s, char** ret)
> +{
> +  int state=0;
> +  char c;
> +
> +  for (; *s && state != 4; s++)
> +{
> +  c = *s;
> +  if (c == '*')
> + {
> +   s++;
> +   break;
> + }
> +  switch (state) {
> + case 0:
> +   if (c == '+') state = 1;
> +   else if (c != '-') sum0+=c;
> +   break;
> + case 1:
> +   if (c == '+') state = 2;
> +   else if (c == '-') state = 0;
> +   else sum1+=c;
> +   break;
> + case 2:
> +   if (c == '+') state = 3;
> +   else if (c == '-') state = 1;
> +   else sum2+=c;
> +   break;
> + case 3:
> +   if (c == '-') state = 2;
> +   else if (c == 'x') state = 4;
> +   break;
> + default:
> +   break;
> +  }
> +}
> +  *ret = s;
> +  return state;
> +}
> +
> +/* { dg-final { scan-tree-dump-not "switch" "optimized" } } */
> +/* { dg-final { cleanup-tree-dump "optimized" } } */
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 31c1f4d..94e8ec4 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -1411,6 +1411,7 @@ OBJS = \
>   tree-scalar-evolution.o \
>   tree-sra.o \
>   tree-switch-conversion.o \
> + tree-switch-shortcut.o \
>   tree-ssa-address.o \
>   tree-ssa-alias.o \
>   tree-ssa-ccp.o \
> diff --git a/gcc/common.opt b/gcc/common.opt
> index 0c4f86b..fe0664a 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -2249,6 +2249,10 @@ ftree-sra
>  Common Report Var(flag_tree_sra) Optimization
>  Perform scalar replacement of aggregates
>  
> +ftree-switch-shortcut
> +Common Report Var(flag_tree_switch_shortcut) Init(0) Optimization
> +Convert jumps to switch statements into jumps to case statement.
> +
>  ftree-ter
>  Common Report Var(flag_tree_ter) Optimization
>  Replace temporary expressions in the SSA->normal pass
> diff --git a/gcc/opts.c b/gcc/opts.c
> index be1867c..f1ac2e5 100644
> --- a/gcc/opts.c
> +++ b/gcc/opts.c
> @@ -514,6 +514,7 @@ static const struct default_options 
> default_options_table[] =
>  { OPT_LEVELS_3_PLUS, OPT_fvect_cost_model_, NULL, 
> VECT_COST_MODEL_DYNAMIC },
>  { OPT_LEVELS_3_PLUS, OPT_fipa_cp_clone, NULL, 1 },
>  { OPT_LEVELS_3_PLUS, OPT_ftree_partial_pre, NULL, 1 },
> +{ OPT_LEVELS_3_PLUS, OPT_ftree_switch_shortcut, NULL, 1 },
>  
>  /* -Ofast adds optimizations to -O3.  */
>  { OPT_LEVELS_FAST, OPT_ffast_math, NULL, 1 },
> diff --git a/gcc/params.def b/gcc/params.def
> 

Re: [PATCH,rs6000] Add __VEC_ELEMENT_REG_ORDER__ builtin define for PowerPC

2014-08-20 Thread Bill Schmidt
On Wed, 2014-08-20 at 17:28 +0100, Alan Lawrence wrote:
> Completely as an aside: this makes me wonder, whether having and using a 
> similar 
> macro _inside_ gcc, i.e. for targets to specify the ordering of elements 
> within 
> a vector independently of BYTES_BIG_ENDIAN, might be a good thing?
> 

Yes, certainly...in fact, we have such a macro in the PowerPC backend
(VECTOR_ELT_ORDER_BIG) that we use in some cases where the target is
little endian but it is desirable to use big-endian element order (for
porting from BE PowerPC code that uses certain coding practices).
However, our macro is tied to a particular target-specific option.  If
other targets find the concept useful we'd certainly be open to a more
unified approach.

Thanks,
Bill

> --Alan
> 
> Bill Schmidt wrote:
> > Hi,
> > 
> > This adds a macro to indicate the order in which vector elements appear
> > in a register on PowerPC.  Elements may appear in right-to-left order
> > for little endian, or in left-to-right order for big endian and when
> > -maltivec=be is selected for little endian.  The same macro is being
> > implemented in the IBM XL compilers.
> > 
> > Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> > regressions.  Verified the new macro takes on the correct value in the
> > circumstances listed above.  Is this ok for trunk?  It would be
> > preferable to backport this to GCC 4.9 as well.
> > 
> > Thanks,
> > Bill
> > 
> > 
> > 2014-08-15  Bill Schmidt  
> > 
> > * conifg/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Provide
> > builtin define __VEC_ELEMENT_REG_ORDER__.
> > 
> > 
> > Index: gcc/config/rs6000/rs6000-c.c
> > ===
> > --- gcc/config/rs6000/rs6000-c.c(revision 214025)
> > +++ gcc/config/rs6000/rs6000-c.c(working copy)
> > @@ -497,6 +497,12 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfile)
> >break;
> >  }
> >  
> > +  /* Vector element order.  */
> > +  if (BYTES_BIG_ENDIAN || (rs6000_altivec_element_order == 2))
> > +builtin_define ("__VEC_ELEMENT_REG_ORDER__=__ORDER_BIG_ENDIAN__");
> > +  else
> > +builtin_define ("__VEC_ELEMENT_REG_ORDER__=__ORDER_LITTLE_ENDIAN__");
> > +
> >/* Let the compiled code know if 'f' class registers will not be 
> > available.  */
> >if (TARGET_SOFT_FLOAT || !TARGET_FPRS)
> >  builtin_define ("__NO_FPRS__");
> > 
> > 
> > 
> 
> 




Fix coverage.c skippping some functions

2014-08-20 Thread Jan Hubicka
Hi,
while debugging quite werid libgcov issue I noticed that we skip profiling 
DECL_EXTERNAL
functions.  THis is not quite correct: if the function gets inlined during the 
train run,
the counters are used and ought to be streamed.  With LTO the profile will get 
merged with
the offline copy from other unit, without LTO we can be pretty sure the 
function will be inlined
in -fprofile-use run, too (if it matters) and thus ought to be instrumented as 
well or we hit
problems with empty profile.

I also revisited coverage_compute_profile_id to be non-zero, since function IDs 
was nonzero before
and made it prettier with unique name symbols.

Bootstrapped/regtested x86_64-linux, comitted.

* coverage.c (coverage_compute_profile_id): Return non-0;
also handle symbols with unique name.
(coverage_end_function): Do not skip DECL_EXTERNAL functions.
Index: coverage.c
===
--- coverage.c  (revision 214223)
+++ coverage.c  (working copy)
@@ -579,7 +579,7 @@ coverage_compute_profile_id (struct cgra
   unsigned chksum;
 
   /* Externally visible symbols have unique name.  */
-  if (TREE_PUBLIC (n->decl) || DECL_EXTERNAL (n->decl))
+  if (TREE_PUBLIC (n->decl) || DECL_EXTERNAL (n->decl) || n->unique_name)
 {
   chksum = coverage_checksum_string
(0, IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (n->decl)));
@@ -601,8 +601,10 @@ coverage_compute_profile_id (struct cgra
(chksum, aux_base_name);
 }
 
-  /* Non-negative integers are hopefully small enough to fit in all targets.  
*/
-  return chksum & 0x7fff;
+  /* Non-negative integers are hopefully small enough to fit in all targets.
+ Gcov file formats wants non-zero function IDs.  */
+  chksum = chksum & 0x7fff;
+  return chksum + (!chksum);
 }
 
 /* Compute cfg checksum for the function FN given as argument.
@@ -692,30 +694,24 @@ coverage_end_function (unsigned lineno_c
 {
   struct coverage_data *item = 0;
 
-  /* If the function is extern (i.e. extern inline), then we won't
-be outputting it, so don't chain it onto the function
-list.  */
-  if (!DECL_EXTERNAL (current_function_decl))
-   {
- item = ggc_alloc ();
+  item = ggc_alloc ();
 
-  if (PARAM_VALUE (PARAM_PROFILE_FUNC_INTERNAL_ID))
-   item->ident = current_function_funcdef_no + 1;
-  else
-{
-  gcc_assert (coverage_node_map_initialized_p ());
-  item->ident = cgraph_node::get (cfun->decl)->profile_id;
-}
-
- item->lineno_checksum = lineno_checksum;
- item->cfg_checksum = cfg_checksum;
-
- item->fn_decl = current_function_decl;
- item->next = 0;
- *functions_tail = item;
- functions_tail = &item->next;
+  if (PARAM_VALUE (PARAM_PROFILE_FUNC_INTERNAL_ID))
+   item->ident = current_function_funcdef_no + 1;
+  else
+   {
+ gcc_assert (coverage_node_map_initialized_p ());
+ item->ident = cgraph_node::get (cfun->decl)->profile_id;
}
 
+  item->lineno_checksum = lineno_checksum;
+  item->cfg_checksum = cfg_checksum;
+
+  item->fn_decl = current_function_decl;
+  item->next = 0;
+  *functions_tail = item;
+  functions_tail = &item->next;
+
   for (i = 0; i != GCOV_COUNTERS; i++)
{
  tree var = fn_v_ctrs[i];


Re: [PATCH,rs6000] Add __VEC_ELEMENT_REG_ORDER__ builtin define for PowerPC

2014-08-20 Thread Alan Lawrence
Completely as an aside: this makes me wonder, whether having and using a similar 
macro _inside_ gcc, i.e. for targets to specify the ordering of elements within 
a vector independently of BYTES_BIG_ENDIAN, might be a good thing?


--Alan

Bill Schmidt wrote:

Hi,

This adds a macro to indicate the order in which vector elements appear
in a register on PowerPC.  Elements may appear in right-to-left order
for little endian, or in left-to-right order for big endian and when
-maltivec=be is selected for little endian.  The same macro is being
implemented in the IBM XL compilers.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions.  Verified the new macro takes on the correct value in the
circumstances listed above.  Is this ok for trunk?  It would be
preferable to backport this to GCC 4.9 as well.

Thanks,
Bill


2014-08-15  Bill Schmidt  

* conifg/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Provide
builtin define __VEC_ELEMENT_REG_ORDER__.


Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 214025)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -497,6 +497,12 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfile)
   break;
 }
 
+  /* Vector element order.  */

+  if (BYTES_BIG_ENDIAN || (rs6000_altivec_element_order == 2))
+builtin_define ("__VEC_ELEMENT_REG_ORDER__=__ORDER_BIG_ENDIAN__");
+  else
+builtin_define ("__VEC_ELEMENT_REG_ORDER__=__ORDER_LITTLE_ENDIAN__");
+
   /* Let the compiled code know if 'f' class registers will not be available.  
*/
   if (TARGET_SOFT_FLOAT || !TARGET_FPRS)
 builtin_define ("__NO_FPRS__");








[libgfortran/62188, committed] Fix indexing off end of array

2014-08-20 Thread Steve Kargl
I've committed this patch as obvious to trunk and the 4.8
4.9 branches.

2014-08-20  Steven G. Kargl  

PR libgfortran/62188
* m4/bessel.m4: Avoid indexing off the end of an array.
* generated/bessel_r10.c: Regenerated.
* generated/bessel_r16.c: Ditto.
* generated/bessel_r4.c: Ditto.
* generated/bessel_r8.c: Ditto.

-- 
Steve

Index: generated/bessel_r10.c
===
--- generated/bessel_r10.c  (revision 214227)
+++ generated/bessel_r10.c  (working copy)
@@ -162,7 +162,7 @@ bessel_yn_r10 (gfc_array_r10 * const res
 
   x2rev = GFC_REAL_10_LITERAL(2.)/x;
 
-  for (i = 2; i <= n1+n2; i++)
+  for (i = 2; i <= n2 - n1; i++)
 {
 #if defined(GFC_REAL_10_INFINITY)
   if (unlikely (last2 == -GFC_REAL_10_INFINITY))
Index: generated/bessel_r16.c
===
--- generated/bessel_r16.c  (revision 214227)
+++ generated/bessel_r16.c  (working copy)
@@ -166,7 +166,7 @@ bessel_yn_r16 (gfc_array_r16 * const res
 
   x2rev = GFC_REAL_16_LITERAL(2.)/x;
 
-  for (i = 2; i <= n1+n2; i++)
+  for (i = 2; i <= n2 - n1; i++)
 {
 #if defined(GFC_REAL_16_INFINITY)
   if (unlikely (last2 == -GFC_REAL_16_INFINITY))
Index: generated/bessel_r4.c
===
--- generated/bessel_r4.c   (revision 214227)
+++ generated/bessel_r4.c   (working copy)
@@ -162,7 +162,7 @@ bessel_yn_r4 (gfc_array_r4 * const restr
 
   x2rev = GFC_REAL_4_LITERAL(2.)/x;
 
-  for (i = 2; i <= n1+n2; i++)
+  for (i = 2; i <= n2 - n1; i++)
 {
 #if defined(GFC_REAL_4_INFINITY)
   if (unlikely (last2 == -GFC_REAL_4_INFINITY))
Index: generated/bessel_r8.c
===
--- generated/bessel_r8.c   (revision 214227)
+++ generated/bessel_r8.c   (working copy)
@@ -162,7 +162,7 @@ bessel_yn_r8 (gfc_array_r8 * const restr
 
   x2rev = GFC_REAL_8_LITERAL(2.)/x;
 
-  for (i = 2; i <= n1+n2; i++)
+  for (i = 2; i <= n2 - n1; i++)
 {
 #if defined(GFC_REAL_8_INFINITY)
   if (unlikely (last2 == -GFC_REAL_8_INFINITY))
Index: m4/bessel.m4
===
--- m4/bessel.m4(revision 214227)
+++ m4/bessel.m4(working copy)
@@ -163,7 +163,7 @@ bessel_yn_r'rtype_kind` ('rtype` * const
 
   x2rev = GFC_REAL_'rtype_kind`_LITERAL(2.)/x;
 
-  for (i = 2; i <= n1+n2; i++)
+  for (i = 2; i <= n2 - n1; i++)
 {
 #if defined('rtype_name`_INFINITY)
   if (unlikely (last2 == -'rtype_name`_INFINITY))


RE: [PATCH, AArch64] Fix typo

2014-08-20 Thread Evandro Menezes
All,

My apologies for being a pest. :-)

-- 
Evandro Menezes  Austin, TX

-Original Message-
From: Ramana Radhakrishnan [mailto:ramana@googlemail.com] 
Sent: Wednesday, August 20, 2014 11:08
To: Evandro Menezes
Cc: James Greenhalgh; gcc-patches; James Greenhalgh; Richard Earnshaw; Marcus 
Shawcroft; ram...@gcc.gnu.org
Subject: Re: [PATCH, AArch64] Fix typo

On Wed, Aug 20, 2014 at 4:45 PM, Evandro Menezes  wrote:
> This is a trivial patch.  However, without it, the addressing mode 
> cost is incorrectly calculated, since the cost intended for HI end up 
> being used for SI on A57.

Pinging patches every day isn't going to help :). Pinging weekly is the 
generally accepted norm in this community.
https://gcc.gnu.org/contribute.html#patches even says this is 2 weeks !  I 
cannot approve this patch even though it looks sane to me.

Folks who are listed as maintainers are real people and are allowed a life 
outside GCC, you know ... :)

regards
Ramana

>
> I'd appreciate your considering this patch fixing this issue.
>
> Thank you,
>
> --
> Evandro Menezes Austin, USA
> e.mene...@samsung.com   +1-512-425-3365
>
>
> -Original Message-
> From: Evandro Menezes [mailto:e.mene...@samsung.com]
> Sent: Tuesday, August 19, 2014 14:40
> To: 'James Greenhalgh'
> Cc: 'gcc-patches@gcc.gnu.org'; 'James Greenhalgh'; 
> 'richard.earns...@arm.com'; 'marcus.shawcr...@arm.com'
> Subject: RE: [PATCH, AArch64] Fix typo
>
> Ping, pretty please.
>
> --
> Evandro Menezes Austin, USA
> e.mene...@samsung.com   +1-512-425-3365
>
> -Original Message-
> From: Evandro Menezes [mailto:e.mene...@samsung.com]
> Sent: Monday, August 18, 2014 10:02
> To: 'James Greenhalgh'
> Cc: 'gcc-patches@gcc.gnu.org'; 'James Greenhalgh'; 
> 'richard.earns...@arm.com'; 'marcus.shawcr...@arm.com'
> Subject: RE: [PATCH, AArch64] Fix typo
>
> Ping.
>
> --
> Evandro Menezes Austin, USA
> e.mene...@samsung.com   +1-512-425-3365
> -Original Message-
> From: Evandro Menezes [mailto:e.mene...@samsung.com]
> Sent: Friday, August 15, 2014 14:55
> To: 'James Greenhalgh'
> Cc: 'gcc-patches@gcc.gnu.org'; 'James Greenhalgh'; 
> 'richard.earns...@arm.com'; 'marcus.shawcr...@arm.com'
> Subject: RE: [PATCH, AArch64] Fix typo
>
> Thanks for the review.
>
> --
> Evandro Menezes Austin, USA
> e.mene...@samsung.com   +1-512-425-3365
>
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org 
> [mailto:gcc-patches-ow...@gcc.gnu.org]
> On Behalf Of James Greenhalgh
> Sent: Friday, August 15, 2014 11:36
> To: Evandro Menezes
> Cc: gcc-patches@gcc.gnu.org; 'James Greenhalgh'; 
> richard.earns...@arm.com; marcus.shawcr...@arm.com
> Subject: Re: [PATCH, AArch64] Fix typo
>
> On Fri, Aug 15, 2014 at 05:24:58PM +0100, Evandro Menezes wrote:
>> I tripped at a typo that goes undetected because the macro 
>> NAMED_PARAM doesn't apply in the absence of designated initializers.
>>
>> Since struct scale_addr_mode_cost has the cost for DI, but not for 
>> QI, the instances of struct cpu_addrcost_table are not initialized as 
>> intended due to the different order of the structure members.
>
> Thanks for spotting and fixing this.
>
> The ChangeLog entry should be added to gcc/ChangeLog, and should look 
> like
> this:
>
> 2014-08-14  Evandro Menezes  
>
> * config/aarch64/aarch64.c (generic_addrcost_table): Initialize
> elements in the correct order.
> (cortexa57_addrcost_table): Likewise.
>
> My fixes were:
>   * Two spaces between your name and email address.
>   * Name the structure/function/thing changed.
>   * Set the path relative to the ChangeLog being modified.
>
> Otherwise, this patch looks correct to me. However, you will need 
> approval from an AArch64 port maintainer (For AArch64 this is Richard 
> Earnshaw or Marcus Shawcroft - both added to CC).
>
> Thanks,
> James



PR62203 (was Re: [PATCH 035/236] Return types of unlink_insn_chain and duplicate_insn_chain)

2014-08-20 Thread David Malcolm
On Wed, 2014-08-20 at 06:19 -0400, David Malcolm wrote:
> On Wed, 2014-08-20 at 10:20 +0200, Andreas Schwab wrote:
> > David Malcolm  writes:
> > 
> > > @@ -4083,7 +4083,7 @@ cfg_layout_can_duplicate_bb_p (const_basic_block bb)
> > >return true;
> > >  }
> > >  
> > > -rtx
> > > +rtx_insn *
> > >  duplicate_insn_chain (rtx from, rtx to)
> > >  {
> > >rtx insn, next, copy;
> > > @@ -4169,7 +4169,7 @@ duplicate_insn_chain (rtx from, rtx to)
> > >  }
> > >insn = NEXT_INSN (last);
> > >delete_insn (last);
> > > -  return insn;
> > > +  return as_a  (insn);
> > 
> > This is wrong, insn may be NULL.
> 
> Thanks; and indeed, this broke the bootstrap, as noted in:
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01964.html
> 
> Fixed in r214207:
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01971.html

...and this has subsequently been filed as PR62203 (retitling
accordingly).

> Sorry.  I'm trying to figure out why this didn't break during my
> testing.  Patch #60 of the original series contained an equivalent as_a
> -> as_a_nullable hunk:
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00708.html
> - albeit with a misleading ChangeLog entry (I'm assuming I messed that
> up during a rebase) - but this hadn't been applied yet.

I just reran a bootstrap with patches 4-35 containing the unsafe as_a
cast from #35, on top of r213973 (from 2014-08-14), and somehow it
successfully bootstrapped and regression tested on
x86_64-unknown-linux-gnu (Fedora 20).  r213973 has been the baseline
I've been testing and patching against.

So presumably something changed *since* r213973 to make the bug in patch
#35 show itself when applied on a more recent trunk (I was able to
reproduce the bug on the same machine, with the same configure flags).

Bother.

I'll rebase against a more recent trunk and retest accordingly for the
followup patches.  I'll also take another look at the patches that add
as_a<> (as opposed to safe_as_a<>) [Does this make a case for adding the
safety check to the is_a_helper functions, and dropping safe_as_a
variant altogether?]

Sorry about this
Dave



Re: [PATCH, AArch64] Fix typo

2014-08-20 Thread Ramana Radhakrishnan
On Wed, Aug 20, 2014 at 4:45 PM, Evandro Menezes  wrote:
> This is a trivial patch.  However, without it, the addressing mode cost is
> incorrectly calculated, since the cost intended for HI end up being used for
> SI on A57.

Pinging patches every day isn't going to help :). Pinging weekly is
the generally accepted norm in this community.
https://gcc.gnu.org/contribute.html#patches even says this is 2 weeks
!  I cannot approve this patch even though it looks sane to me.

Folks who are listed as maintainers are real people and are allowed a
life outside GCC, you know ... :)

regards
Ramana

>
> I'd appreciate your considering this patch fixing this issue.
>
> Thank you,
>
> --
> Evandro Menezes Austin, USA
> e.mene...@samsung.com   +1-512-425-3365
>
>
> -Original Message-
> From: Evandro Menezes [mailto:e.mene...@samsung.com]
> Sent: Tuesday, August 19, 2014 14:40
> To: 'James Greenhalgh'
> Cc: 'gcc-patches@gcc.gnu.org'; 'James Greenhalgh';
> 'richard.earns...@arm.com'; 'marcus.shawcr...@arm.com'
> Subject: RE: [PATCH, AArch64] Fix typo
>
> Ping, pretty please.
>
> --
> Evandro Menezes Austin, USA
> e.mene...@samsung.com   +1-512-425-3365
>
> -Original Message-
> From: Evandro Menezes [mailto:e.mene...@samsung.com]
> Sent: Monday, August 18, 2014 10:02
> To: 'James Greenhalgh'
> Cc: 'gcc-patches@gcc.gnu.org'; 'James Greenhalgh';
> 'richard.earns...@arm.com'; 'marcus.shawcr...@arm.com'
> Subject: RE: [PATCH, AArch64] Fix typo
>
> Ping.
>
> --
> Evandro Menezes Austin, USA
> e.mene...@samsung.com   +1-512-425-3365
> -Original Message-
> From: Evandro Menezes [mailto:e.mene...@samsung.com]
> Sent: Friday, August 15, 2014 14:55
> To: 'James Greenhalgh'
> Cc: 'gcc-patches@gcc.gnu.org'; 'James Greenhalgh';
> 'richard.earns...@arm.com'; 'marcus.shawcr...@arm.com'
> Subject: RE: [PATCH, AArch64] Fix typo
>
> Thanks for the review.
>
> --
> Evandro Menezes Austin, USA
> e.mene...@samsung.com   +1-512-425-3365
>
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
> On Behalf Of James Greenhalgh
> Sent: Friday, August 15, 2014 11:36
> To: Evandro Menezes
> Cc: gcc-patches@gcc.gnu.org; 'James Greenhalgh'; richard.earns...@arm.com;
> marcus.shawcr...@arm.com
> Subject: Re: [PATCH, AArch64] Fix typo
>
> On Fri, Aug 15, 2014 at 05:24:58PM +0100, Evandro Menezes wrote:
>> I tripped at a typo that goes undetected because the macro NAMED_PARAM
>> doesn't apply in the absence of designated initializers.
>>
>> Since struct scale_addr_mode_cost has the cost for DI, but not for QI,
>> the instances of struct cpu_addrcost_table are not initialized as
>> intended due to the different order of the structure members.
>
> Thanks for spotting and fixing this.
>
> The ChangeLog entry should be added to gcc/ChangeLog, and should look like
> this:
>
> 2014-08-14  Evandro Menezes  
>
> * config/aarch64/aarch64.c (generic_addrcost_table): Initialize
> elements in the correct order.
> (cortexa57_addrcost_table): Likewise.
>
> My fixes were:
>   * Two spaces between your name and email address.
>   * Name the structure/function/thing changed.
>   * Set the path relative to the ChangeLog being modified.
>
> Otherwise, this patch looks correct to me. However, you will need approval
> from an AArch64 port maintainer (For AArch64 this is Richard Earnshaw or
> Marcus Shawcroft - both added to CC).
>
> Thanks,
> James


RE: [PATCH, AArch64] Fix typo

2014-08-20 Thread Evandro Menezes
This is a trivial patch.  However, without it, the addressing mode cost is
incorrectly calculated, since the cost intended for HI end up being used for
SI on A57.

I'd appreciate your considering this patch fixing this issue.

Thank you,

-- 
Evandro Menezes Austin, USA
e.mene...@samsung.com   +1-512-425-3365


-Original Message-
From: Evandro Menezes [mailto:e.mene...@samsung.com] 
Sent: Tuesday, August 19, 2014 14:40
To: 'James Greenhalgh'
Cc: 'gcc-patches@gcc.gnu.org'; 'James Greenhalgh';
'richard.earns...@arm.com'; 'marcus.shawcr...@arm.com'
Subject: RE: [PATCH, AArch64] Fix typo

Ping, pretty please.

-- 
Evandro Menezes Austin, USA
e.mene...@samsung.com   +1-512-425-3365

-Original Message-
From: Evandro Menezes [mailto:e.mene...@samsung.com]
Sent: Monday, August 18, 2014 10:02
To: 'James Greenhalgh'
Cc: 'gcc-patches@gcc.gnu.org'; 'James Greenhalgh';
'richard.earns...@arm.com'; 'marcus.shawcr...@arm.com'
Subject: RE: [PATCH, AArch64] Fix typo

Ping.

-- 
Evandro Menezes Austin, USA
e.mene...@samsung.com   +1-512-425-3365
-Original Message-
From: Evandro Menezes [mailto:e.mene...@samsung.com]
Sent: Friday, August 15, 2014 14:55
To: 'James Greenhalgh'
Cc: 'gcc-patches@gcc.gnu.org'; 'James Greenhalgh';
'richard.earns...@arm.com'; 'marcus.shawcr...@arm.com'
Subject: RE: [PATCH, AArch64] Fix typo

Thanks for the review.

-- 
Evandro Menezes Austin, USA
e.mene...@samsung.com   +1-512-425-3365

-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On Behalf Of James Greenhalgh
Sent: Friday, August 15, 2014 11:36
To: Evandro Menezes
Cc: gcc-patches@gcc.gnu.org; 'James Greenhalgh'; richard.earns...@arm.com;
marcus.shawcr...@arm.com
Subject: Re: [PATCH, AArch64] Fix typo

On Fri, Aug 15, 2014 at 05:24:58PM +0100, Evandro Menezes wrote:
> I tripped at a typo that goes undetected because the macro NAMED_PARAM 
> doesn't apply in the absence of designated initializers.
> 
> Since struct scale_addr_mode_cost has the cost for DI, but not for QI, 
> the instances of struct cpu_addrcost_table are not initialized as 
> intended due to the different order of the structure members.

Thanks for spotting and fixing this.

The ChangeLog entry should be added to gcc/ChangeLog, and should look like
this:

2014-08-14  Evandro Menezes  

* config/aarch64/aarch64.c (generic_addrcost_table): Initialize
elements in the correct order.
(cortexa57_addrcost_table): Likewise.

My fixes were:
  * Two spaces between your name and email address.
  * Name the structure/function/thing changed.
  * Set the path relative to the ChangeLog being modified.

Otherwise, this patch looks correct to me. However, you will need approval
from an AArch64 port maintainer (For AArch64 this is Richard Earnshaw or
Marcus Shawcroft - both added to CC).

Thanks,
James


aarch64.diff
Description: Binary data


Re: [PATCH,rs6000] Add __VEC_ELEMENT_REG_ORDER__ builtin define for PowerPC

2014-08-20 Thread David Edelsohn
2014-08-15  Bill Schmidt  

* conifg/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Provide
builtin define __VEC_ELEMENT_REG_ORDER__.

Okay.

Thanks, David


Re: [PATCH] SPARC: add mcpu=leon3v7 target

2014-08-20 Thread Daniel Hellstrom

Hi Joel,

Yes an update is required. If/when I get positive comments on the mcpu=leon3v7 
patch I will suggest a new updated multilib patch and a RTEMS LEON3 BSP build 
configuration change.

I have tested the mcpu=leon3v7 patch with RTEMS leon3 BSP generating V7 instructions, and ngmp generating V8 instructions to check that I haven't broken anything. The instructions generated in the 
both cases are good, and the RTEMS single-core test-suite runs on both GR712RC and NGFP hardware successfully (apart from the already known two failures of course).


Regards,
Daniel Hellstrom

On 08/20/2014 05:05 PM, Joel Sherrill wrote:

Daniel,

Does this mean that Sebastian's patch to add a leon3 multilib for
sparc-rtems
needs to be augmented to handled leon3v7? Or does it need to map to a
regular v7 library?

It just seems like the multilibs should have been touched somehow.

--joel
On 8/20/2014 10:01 AM, Daniel Hellstrom wrote:

The LEON3/4 soft-core CPU has support for both SPARCv7 and SPARCv8 that
is configurable at design time. The majority of the LEON3 ASICs are v8
compatible, however when designing an as small LEON3 as possible, v7
without FPU is frequently used.

The current GCC leon3 support implies the SPARCv8 instruction set
which is not compatible with SPARCv7. Relying on the standard SPARCv7
(-mcpu=v7) target for a LEON3-V7 is not feasible since the atomic
instruction (CAS) can not be generated by standard v7 target. This
is also a problem for binaries aiming to be compatible with all LEON3/4
processors.

  * config.gcc (sparc*-*-*): Accept mcpu=leon3v7 processor
  * doc/invoke.texi (SPARC options): add mcpu=leon3v7 comment
  * config/sparc/leon.md (leon3_load, leon_store, leon_fp_*):
handle leon3v7 as leon3
  * config/sparc/sparc-opts.h (enum processor_type): Add PROCESSOR_LEON3V7
  * config/sparc/sparc.c (sparc_option_override): add leon3v7 support
  * config/sparc/sparc.h (TARGET_CPU_leon3v7): new define
  * config/sparc/sparc.md (cpu): add leon3v7
  * config/sparc/sparc.opt (enum processor_type): Add leon3v7
---
  gcc/config.gcc|5 -
  gcc/config/sparc/leon.md  |   14 +++---
  gcc/config/sparc/sparc-opts.h |1 +
  gcc/config/sparc/sparc.c  |3 +++
  gcc/config/sparc/sparc.h  |   38 +++---
  gcc/config/sparc/sparc.md |1 +
  gcc/config/sparc/sparc.opt|3 +++
  gcc/doc/invoke.texi   |   16 
  8 files changed, 50 insertions(+), 31 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 605efc0..199e387 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3065,6 +3065,9 @@ if test x$with_cpu = x ; then
*-leon[3-9]*)
  with_cpu=leon3
  ;;
+   *-leon[3-9]v7*)
+ with_cpu=leon3v7
+ ;;
*)
  with_cpu="`echo ${target} | sed 's/-.*$//'`"
  ;;
@@ -3749,7 +3752,7 @@ case "${target}" in
case ${val} in
"" | sparc | sparcv9 | sparc64 \
| v7 | cypress \
-   | v8 | supersparc | hypersparc | leon | leon3 \
+   | v8 | supersparc | hypersparc | leon | leon3 | leon3v7 
\
| sparclite | f930 | f934 | sparclite86x \
| sparclet | tsc701 \
| v9 | ultrasparc | ultrasparc3 | niagara | niagara2 \
diff --git a/gcc/config/sparc/leon.md b/gcc/config/sparc/leon.md
index b511397..e8050fa 100644
--- a/gcc/config/sparc/leon.md
+++ b/gcc/config/sparc/leon.md
@@ -29,11 +29,11 @@
  
  ;; Use a double reservation to work around the load pipeline hazard on UT699.

  (define_insn_reservation "leon3_load" 1
-  (and (eq_attr "cpu" "leon3") (eq_attr "type" "load,sload"))
+  (and (eq_attr "cpu" "leon3,leon3v7") (eq_attr "type" "load,sload"))
"leon_memory*2")
  
  (define_insn_reservation "leon_store" 2

-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "store"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "store"))
"leon_memory*2")
  
  ;; This describes Gaisler Research's FPU

@@ -44,21 +44,21 @@
  (define_cpu_unit "grfpu_ds" "grfpu")
  
  (define_insn_reservation "leon_fp_alu" 4

-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fp,fpcmp,fpmul"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fp,fpcmp,fpmul"))
"grfpu_alu, nothing*3")
  
  (define_insn_reservation "leon_fp_divs" 16

-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpdivs"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpdivs"))
"grfpu_ds*14, nothing*2")
  
  (define_insn_reservation "leon_fp_divd" 17

-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpdivd"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpdivd"))
"grfpu_ds*15, nothing*2")
  
  (define_insn_reservation "leon_fp_sqrts" 24

-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpsqrts"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr

Re: spar-rtems add leon3 multlib to 4.9

2014-08-20 Thread Daniel Hellstrom

Hello,

I would ideally like the mcpu=leon3v7 patch applied first (https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02035.html), so that we can change the multi lib patch to include the leon3v7 target. I believe 
it would be good for the RTEMS LEON3 BSP to include support for all LEON3/4 processors. If switching to mcpu=leon3 in RTEMS BSP, then we no longer support the LEON3 V7 processors.


Best Regards,

Daniel Hellstrom
Software Section Head
Aeroflex Gaisler AB
Aeroflex Microelectronic Solutions – HiRel
Kungsgatan 12
SE-411 19 Gothenburg, Sweden
Phone: +46 31 7758657
dan...@gaisler.com
www.Aeroflex.com/Gaisler

On 08/20/2014 03:51 PM, Joel Sherrill wrote:

I would like to add this patch to the 4.9 branch. It is RTEMS
specific and takes advantage of the leon3 multilib support from
Eric Botcazou.

OK to commit?

--joel

gcc/ChangeLog
2013-08-29  Sebastian Huber

* config/sparc/t-rtems: Add leon3 multilibs.
---
   gcc/config/sparc/t-rtems |4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/sparc/t-rtems b/gcc/config/sparc/t-rtems
index 63d0217..f1a3d84 100644
--- a/gcc/config/sparc/t-rtems
+++ b/gcc/config/sparc/t-rtems
@@ -17,6 +17,6 @@
   #.
   #

-MULTILIB_OPTIONS = msoft-float mcpu=v8
-MULTILIB_DIRNAMES = soft v8
+MULTILIB_OPTIONS = msoft-float mcpu=v8/mcpu=leon3
+MULTILIB_DIRNAMES = soft v8 leon3
   MULTILIB_MATCHES = msoft-float=mno-fpu





Re: [PATCH] SPARC: add mcpu=leon3v7 target

2014-08-20 Thread Joel Sherrill
Daniel,

Does this mean that Sebastian's patch to add a leon3 multilib for
sparc-rtems
needs to be augmented to handled leon3v7? Or does it need to map to a
regular v7 library?

It just seems like the multilibs should have been touched somehow.

--joel
On 8/20/2014 10:01 AM, Daniel Hellstrom wrote:
> The LEON3/4 soft-core CPU has support for both SPARCv7 and SPARCv8 that
> is configurable at design time. The majority of the LEON3 ASICs are v8
> compatible, however when designing an as small LEON3 as possible, v7
> without FPU is frequently used.
>
> The current GCC leon3 support implies the SPARCv8 instruction set
> which is not compatible with SPARCv7. Relying on the standard SPARCv7
> (-mcpu=v7) target for a LEON3-V7 is not feasible since the atomic
> instruction (CAS) can not be generated by standard v7 target. This
> is also a problem for binaries aiming to be compatible with all LEON3/4
> processors.
>
>  * config.gcc (sparc*-*-*): Accept mcpu=leon3v7 processor
>  * doc/invoke.texi (SPARC options): add mcpu=leon3v7 comment
>  * config/sparc/leon.md (leon3_load, leon_store, leon_fp_*):
>handle leon3v7 as leon3
>  * config/sparc/sparc-opts.h (enum processor_type): Add PROCESSOR_LEON3V7
>  * config/sparc/sparc.c (sparc_option_override): add leon3v7 support
>  * config/sparc/sparc.h (TARGET_CPU_leon3v7): new define
>  * config/sparc/sparc.md (cpu): add leon3v7
>  * config/sparc/sparc.opt (enum processor_type): Add leon3v7
> ---
>  gcc/config.gcc|5 -
>  gcc/config/sparc/leon.md  |   14 +++---
>  gcc/config/sparc/sparc-opts.h |1 +
>  gcc/config/sparc/sparc.c  |3 +++
>  gcc/config/sparc/sparc.h  |   38 +++---
>  gcc/config/sparc/sparc.md |1 +
>  gcc/config/sparc/sparc.opt|3 +++
>  gcc/doc/invoke.texi   |   16 
>  8 files changed, 50 insertions(+), 31 deletions(-)
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 605efc0..199e387 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -3065,6 +3065,9 @@ if test x$with_cpu = x ; then
>   *-leon[3-9]*)
> with_cpu=leon3
> ;;
> + *-leon[3-9]v7*)
> +   with_cpu=leon3v7
> +   ;;
>   *)
> with_cpu="`echo ${target} | sed 's/-.*$//'`"
> ;;
> @@ -3749,7 +3752,7 @@ case "${target}" in
>   case ${val} in
>   "" | sparc | sparcv9 | sparc64 \
>   | v7 | cypress \
> - | v8 | supersparc | hypersparc | leon | leon3 \
> + | v8 | supersparc | hypersparc | leon | leon3 | leon3v7 
> \
>   | sparclite | f930 | f934 | sparclite86x \
>   | sparclet | tsc701 \
>   | v9 | ultrasparc | ultrasparc3 | niagara | niagara2 \
> diff --git a/gcc/config/sparc/leon.md b/gcc/config/sparc/leon.md
> index b511397..e8050fa 100644
> --- a/gcc/config/sparc/leon.md
> +++ b/gcc/config/sparc/leon.md
> @@ -29,11 +29,11 @@
>  
>  ;; Use a double reservation to work around the load pipeline hazard on UT699.
>  (define_insn_reservation "leon3_load" 1
> -  (and (eq_attr "cpu" "leon3") (eq_attr "type" "load,sload"))
> +  (and (eq_attr "cpu" "leon3,leon3v7") (eq_attr "type" "load,sload"))
>"leon_memory*2")
>  
>  (define_insn_reservation "leon_store" 2
> -  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "store"))
> +  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "store"))
>"leon_memory*2")
>  
>  ;; This describes Gaisler Research's FPU
> @@ -44,21 +44,21 @@
>  (define_cpu_unit "grfpu_ds" "grfpu")
>  
>  (define_insn_reservation "leon_fp_alu" 4
> -  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fp,fpcmp,fpmul"))
> +  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" 
> "fp,fpcmp,fpmul"))
>"grfpu_alu, nothing*3")
>  
>  (define_insn_reservation "leon_fp_divs" 16
> -  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpdivs"))
> +  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpdivs"))
>"grfpu_ds*14, nothing*2")
>  
>  (define_insn_reservation "leon_fp_divd" 17
> -  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpdivd"))
> +  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpdivd"))
>"grfpu_ds*15, nothing*2")
>  
>  (define_insn_reservation "leon_fp_sqrts" 24
> -  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpsqrts"))
> +  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpsqrts"))
>"grfpu_ds*22, nothing*2")
>  
>  (define_insn_reservation "leon_fp_sqrtd" 25
> -  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpsqrtd"))
> +  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpsqrtd"))
>"grfpu_ds*23, nothing*2")
> diff --git a/gcc/config/sparc/sparc-opts.h b/gcc/config/sparc/sparc-opts.h
> index b5e9761..c35bee4 100644
> --- a/gcc/config/sparc/sparc-opts.h
> +++ b/gcc/config/sparc/sparc-opts.h
> @@ -31,6 +31,7 @@ enum processor_type {
>PROCESSOR_HYPER

Re: DSE calls to builtins (memset, etc)

2014-08-20 Thread Marc Glisse

On Wed, 20 Aug 2014, Richard Biener wrote:


On Wed, Aug 20, 2014 at 4:18 PM, Marc Glisse  wrote:

On Wed, 20 Aug 2014, Richard Biener wrote:


-  if (stmt != use_stmt
- && ref_maybe_used_by_stmt_p (use_stmt, gimple_assign_lhs
(stmt)))
-   return;
-




I don't see how you can remove this code?




dse_possible_dead_store_p already tests ref_maybe_used_by_stmt_p and
thus cannot return true with such a use_stmt, as far as I can see. As I
said, bootstrap+testsuite with an assert instead of 'return' didn't turn
up anything. I could keep it as a gcc_checking_assert (with a slight
update to the comment) if you like. Or did I miss a path in
dse_possible_dead_store_p?



Yes, the one that early returns from the operand_equal_p check.

You might want to do some svn blaming to see what testcases
were added with the above code (and the code surrounding it).

I'm not sure either... so if it passes bootstrap & regtest it must be
dead code... (well...)



The early return operand_equal_p has use_stmt == stmt, so it doesn't even
reach the call to ref_maybe_used_by_stmt_p I am removing.

svn blame leads me to r132899 (gcc.c-torture/execute/pr35472.c)
and before that to r131101 (gcc.c-torture/execute/20071219-1.c)


Maybe add some noclone attributes as well?


Ok, both testcases now have noinline,noclone instead of just noinline in 
my tree.


* gcc.c-torture/execute/pr35472.c: Add noclone attribute.
* gcc.c-torture/execute/20071219-1.c: Likewise.


And try -fno-tree-fre/pre?


No problem.
(it makes it harder to find a killing stmt)


But pr35472.c clearly shows what it was trying to fix:

 *p = a;
 *p = b;

with p == &b.  The *p = b; store does _not_ make *p = a dead because
*p = b; is a no-op.  So a modified testcase would be

 *p = a;
 *p = *p;

where without your patch the first DSE pass removes *p = *p (but
not first *p = a).

Maybe if that still works after your patch you can add this as a new testcase,
also verifying that *p = *p store indeed is removed.


DSE goes backwards, so it first removes *p=*p (already tested by 
gcc.dg/tree-ssa/pr57361.c) and when we look at *p=*a; there is no second 
statement left, so it wouldn't really test what you want.


--
Marc Glisse


[PATCH] SPARC: add mcpu=leon3v7 target

2014-08-20 Thread Daniel Hellstrom
The LEON3/4 soft-core CPU has support for both SPARCv7 and SPARCv8 that
is configurable at design time. The majority of the LEON3 ASICs are v8
compatible, however when designing an as small LEON3 as possible, v7
without FPU is frequently used.

The current GCC leon3 support implies the SPARCv8 instruction set
which is not compatible with SPARCv7. Relying on the standard SPARCv7
(-mcpu=v7) target for a LEON3-V7 is not feasible since the atomic
instruction (CAS) can not be generated by standard v7 target. This
is also a problem for binaries aiming to be compatible with all LEON3/4
processors.

 * config.gcc (sparc*-*-*): Accept mcpu=leon3v7 processor
 * doc/invoke.texi (SPARC options): add mcpu=leon3v7 comment
 * config/sparc/leon.md (leon3_load, leon_store, leon_fp_*):
   handle leon3v7 as leon3
 * config/sparc/sparc-opts.h (enum processor_type): Add PROCESSOR_LEON3V7
 * config/sparc/sparc.c (sparc_option_override): add leon3v7 support
 * config/sparc/sparc.h (TARGET_CPU_leon3v7): new define
 * config/sparc/sparc.md (cpu): add leon3v7
 * config/sparc/sparc.opt (enum processor_type): Add leon3v7
---
 gcc/config.gcc|5 -
 gcc/config/sparc/leon.md  |   14 +++---
 gcc/config/sparc/sparc-opts.h |1 +
 gcc/config/sparc/sparc.c  |3 +++
 gcc/config/sparc/sparc.h  |   38 +++---
 gcc/config/sparc/sparc.md |1 +
 gcc/config/sparc/sparc.opt|3 +++
 gcc/doc/invoke.texi   |   16 
 8 files changed, 50 insertions(+), 31 deletions(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 605efc0..199e387 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3065,6 +3065,9 @@ if test x$with_cpu = x ; then
*-leon[3-9]*)
  with_cpu=leon3
  ;;
+   *-leon[3-9]v7*)
+ with_cpu=leon3v7
+ ;;
*)
  with_cpu="`echo ${target} | sed 's/-.*$//'`"
  ;;
@@ -3749,7 +3752,7 @@ case "${target}" in
case ${val} in
"" | sparc | sparcv9 | sparc64 \
| v7 | cypress \
-   | v8 | supersparc | hypersparc | leon | leon3 \
+   | v8 | supersparc | hypersparc | leon | leon3 | leon3v7 
\
| sparclite | f930 | f934 | sparclite86x \
| sparclet | tsc701 \
| v9 | ultrasparc | ultrasparc3 | niagara | niagara2 \
diff --git a/gcc/config/sparc/leon.md b/gcc/config/sparc/leon.md
index b511397..e8050fa 100644
--- a/gcc/config/sparc/leon.md
+++ b/gcc/config/sparc/leon.md
@@ -29,11 +29,11 @@
 
 ;; Use a double reservation to work around the load pipeline hazard on UT699.
 (define_insn_reservation "leon3_load" 1
-  (and (eq_attr "cpu" "leon3") (eq_attr "type" "load,sload"))
+  (and (eq_attr "cpu" "leon3,leon3v7") (eq_attr "type" "load,sload"))
   "leon_memory*2")
 
 (define_insn_reservation "leon_store" 2
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "store"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "store"))
   "leon_memory*2")
 
 ;; This describes Gaisler Research's FPU
@@ -44,21 +44,21 @@
 (define_cpu_unit "grfpu_ds" "grfpu")
 
 (define_insn_reservation "leon_fp_alu" 4
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fp,fpcmp,fpmul"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fp,fpcmp,fpmul"))
   "grfpu_alu, nothing*3")
 
 (define_insn_reservation "leon_fp_divs" 16
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpdivs"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpdivs"))
   "grfpu_ds*14, nothing*2")
 
 (define_insn_reservation "leon_fp_divd" 17
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpdivd"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpdivd"))
   "grfpu_ds*15, nothing*2")
 
 (define_insn_reservation "leon_fp_sqrts" 24
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpsqrts"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpsqrts"))
   "grfpu_ds*22, nothing*2")
 
 (define_insn_reservation "leon_fp_sqrtd" 25
-  (and (eq_attr "cpu" "leon,leon3") (eq_attr "type" "fpsqrtd"))
+  (and (eq_attr "cpu" "leon,leon3,leon3v7") (eq_attr "type" "fpsqrtd"))
   "grfpu_ds*23, nothing*2")
diff --git a/gcc/config/sparc/sparc-opts.h b/gcc/config/sparc/sparc-opts.h
index b5e9761..c35bee4 100644
--- a/gcc/config/sparc/sparc-opts.h
+++ b/gcc/config/sparc/sparc-opts.h
@@ -31,6 +31,7 @@ enum processor_type {
   PROCESSOR_HYPERSPARC,
   PROCESSOR_LEON,
   PROCESSOR_LEON3,
+  PROCESSOR_LEON3V7,
   PROCESSOR_SPARCLITE,
   PROCESSOR_F930,
   PROCESSOR_F934,
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index e9b2bcf..7f3c43e 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -1125,6 +1125,7 @@ sparc_option_override (void)
 { TARGET_CPU_hypersparc, PROCESSOR_HYPERSPARC },
 { TARGET_CPU_leon, PROCESSOR_LEON },
 { TARGET_CPU_leon3, PROCESSOR_LEON3 },
+ 

Re: DSE calls to builtins (memset, etc)

2014-08-20 Thread Richard Biener
On Wed, Aug 20, 2014 at 4:31 PM, Marc Glisse  wrote:
> On Wed, 20 Aug 2014, Richard Biener wrote:
>
>> On Wed, Aug 20, 2014 at 9:14 AM, Marc Glisse  wrote:
>>>
>>> Hello,
>>>
>>> here is a new version of the patch which passed bootstrap+testsuite. I am
>>> still removing the ref_maybe_used_by_stmt_p test, see the previous
>>> message
>>> for a discussion.
>>
>>
>> Looks good to me.  I'm still nervous about removing that check (though
>> the description looks odd - if the stmt kills the lhs and it also uses
>> it then if this is not an exact overlap it's undefined
>
>
> I hadn't realized that. Note that this looks true if the reference is the
> lhs of an assignment, but it can be wrong if the reference was computed from
> a call:
>
> memset(p,x,5);
> memmove(p+2,p,42);
>
> memmove would kill memset, except that...
>
>
>> and if it is then the stmt is still dead...).
>
>
> use_stmt would be dead in that case, not stmt.

Yeah, but we don't handle call self-assignments.

Richard.

> stmt:   a = 42;
> use_stmt:   a = a;
>
>> So - ok if it bootstraps/tests ok.
>
>
> --
> Marc Glisse


[patch, avr] Remove avr devices that are not released

2014-08-20 Thread Sivanupandi, Pitchumani
Attached patch removes avr devices that are not released 
(may not be released in near future also).

If OK, could someone commit please?

Regards,
Pitchumani

gcc/ChangeLog

2014-08-20  Pitchumani Sivanupandi 

* config/avr/avr-mcus.def: Remove atmega26hvg, atmega64rfa2,
atmega48hvf, atxmega32x1, atmxt224, atmxt224e, atmxt336s,
atmxt540s and atmxt540sreva devices.
* config/avr/avr-tables.opt: Regenerate.
* config/avr/t-multilib: Regenerate.
* doc/avr-mmcu.texi: Regenerate.



avr-remove-unsupported-devices.patch
Description: avr-remove-unsupported-devices.patch


Re: [PING][PATCH] Make web_entry subclassable

2014-08-20 Thread Richard Biener
On Wed, Aug 20, 2014 at 4:30 PM, Bill Schmidt
 wrote:
> Ping -- the patch that depends on this one has been approved, but I am
> still waiting for approval on these target-independent bits.

Ok.

Thanks,
Richard.

> Thanks,
> Bill
>
> On Wed, 2014-08-13 at 18:01 -0500, Bill Schmidt wrote:
>> Hi,
>>
>> I want to reuse some of the infrastructure in web.c (and df.h) for a
>> target-specific RTL pass, particularly the union-find stuff.  I could
>> just copy it, I suppose, but it seems better to make the struct
>> web_entry into a class so that I can inherit what I need.  That's what
>> this patch does.
>>
>> When I talked about this with some other folks, they mentioned that
>> there has been talk of eliminating the web pass altogether, so that
>> might be an argument in favor of just copying the logic.  I am happy to
>> do that if that's deemed preferable.
>>
>> I've taken the original struct and made it a base class that only
>> retains the pred field from the original class, along with the
>> union-find code.  The reg field is something I don't need, so I've moved
>> that into a subclass that the web code now uses.  I've removed the
>> extra_info field, which is not used and no longer makes sense with
>> inheritance available.  The rest of the changes are just adjusting to
>> these modifications.
>>
>> I didn't overly "C++ify" anything, to keep the changes as non-invasive
>> as possible.
>>
>> I'll post the PowerPC patch that makes use of the subclassing shortly.
>>
>> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
>> regressions.  Is this ok for trunk?
>>
>> Thanks,
>> Bill
>>
>>
>> 2014-08-13  Bill Schmidt  
>>
>>   * df.h (web_entry_base): Replace existing struct web_entry with a
>>   new class web_entry_base with only the predecessor member.
>>   (unionfind_root): Remove declaration and move to class member.
>>   (unionfind_union): Remove declaration and move to friend
>>   function.
>>   (union_defs): Remove declaration.
>>   * web.c (web_entry_base::unionfind_root): Modify to be member
>>   function and adjust accessors.
>>   (unionfind_union): Modify to be friend function and adjust
>>   accessors.
>>   (web_entry): New subclass of web_entry_base containing the reg
>>   member.
>>   (union_match_dups): Modify for struct -> class changes.
>>   (union_defs): Likewise.
>>   (entry_register): Likewise.
>>   (pass_web::execute): Likewise.
>>
>>
>> Index: gcc/df.h
>> ===
>> --- gcc/df.h  (revision 213923)
>> +++ gcc/df.h  (working copy)
>> @@ -1184,20 +1184,22 @@ df_single_use (const df_insn_info *info)
>>
>>  /* web */
>>
>> -/* This entry is allocated for each reference in the insn stream.  */
>> -struct web_entry
>> +class web_entry_base
>>  {
>> -  /* Pointer to the parent in the union/find tree.  */
>> -  struct web_entry *pred;
>> -  /* Newly assigned register to the entry.  Set only for roots.  */
>> -  rtx reg;
>> -  void* extra_info;
>> + private:
>> +  /* Reference to the parent in the union/find tree.  */
>> +  web_entry_base *pred_pvt;
>> +
>> + public:
>> +  /* Accessors.  */
>> +  web_entry_base *pred () { return pred_pvt; }
>> +  void set_pred (web_entry_base *p) { pred_pvt = p; }
>> +
>> +  /* Find representative in union-find tree.  */
>> +  web_entry_base *unionfind_root ();
>> +
>> +  /* Union with another set, returning TRUE if they are already unioned.  */
>> +  friend bool unionfind_union (web_entry_base *first, web_entry_base 
>> *second);
>>  };
>>
>> -extern struct web_entry *unionfind_root (struct web_entry *);
>> -extern bool unionfind_union (struct web_entry *, struct web_entry *);
>> -extern void union_defs (df_ref, struct web_entry *,
>> - unsigned int *used, struct web_entry *,
>> - bool (*fun) (struct web_entry *, struct web_entry *));
>> -
>>  #endif /* GCC_DF_H */
>> Index: gcc/web.c
>> ===
>> --- gcc/web.c (revision 213923)
>> +++ gcc/web.c (working copy)
>> @@ -53,17 +53,17 @@ along with GCC; see the file COPYING3.  If not see
>>
>>  /* Find the root of unionfind tree (the representative of set).  */
>>
>> -struct web_entry *
>> -unionfind_root (struct web_entry *element)
>> +web_entry_base *
>> +web_entry_base::unionfind_root ()
>>  {
>> -  struct web_entry *element1 = element, *element2;
>> +  web_entry_base *element = this, *element1 = this, *element2;
>>
>> -  while (element->pred)
>> -element = element->pred;
>> -  while (element1->pred)
>> +  while (element->pred ())
>> +element = element->pred ();
>> +  while (element1->pred ())
>>  {
>> -  element2 = element1->pred;
>> -  element1->pred = element;
>> +  element2 = element1->pred ();
>> +  element1->set_pred (element);
>>element1 = element2;
>>  }
>>return element;
>> @@ -74,23 +74,32 @@ along with GCC; see the file COPYING3.

Re: DSE calls to builtins (memset, etc)

2014-08-20 Thread Marc Glisse

On Wed, 20 Aug 2014, Marc Glisse wrote:


On Wed, 20 Aug 2014, Richard Biener wrote:


On Wed, Aug 20, 2014 at 9:14 AM, Marc Glisse  wrote:

Hello,

here is a new version of the patch which passed bootstrap+testsuite. I am
still removing the ref_maybe_used_by_stmt_p test, see the previous message
for a discussion.


Looks good to me.  I'm still nervous about removing that check (though
the description looks odd - if the stmt kills the lhs and it also uses
it then if this is not an exact overlap it's undefined


I hadn't realized that. Note that this looks true if the reference is the lhs 
of an assignment, but it can be wrong if the reference was computed from a 
call:


memset(p,x,5);
memmove(p+2,p,42);


Obviously I swapped p and p+2...


memmove would kill memset, except that...


and if it is then the stmt is still dead...).


use_stmt would be dead in that case, not stmt.

stmt:   a = 42;
use_stmt:   a = a;


So - ok if it bootstraps/tests ok.


--
Marc Glisse


Re: DSE calls to builtins (memset, etc)

2014-08-20 Thread Marc Glisse

On Wed, 20 Aug 2014, Richard Biener wrote:


On Wed, Aug 20, 2014 at 9:14 AM, Marc Glisse  wrote:

Hello,

here is a new version of the patch which passed bootstrap+testsuite. I am
still removing the ref_maybe_used_by_stmt_p test, see the previous message
for a discussion.


Looks good to me.  I'm still nervous about removing that check (though
the description looks odd - if the stmt kills the lhs and it also uses
it then if this is not an exact overlap it's undefined


I hadn't realized that. Note that this looks true if the reference is the 
lhs of an assignment, but it can be wrong if the reference was computed 
from a call:


memset(p,x,5);
memmove(p+2,p,42);

memmove would kill memset, except that...


and if it is then the stmt is still dead...).


use_stmt would be dead in that case, not stmt.

stmt:   a = 42;
use_stmt:   a = a;


So - ok if it bootstraps/tests ok.


--
Marc Glisse


[PING][PATCH] Make web_entry subclassable

2014-08-20 Thread Bill Schmidt
Ping -- the patch that depends on this one has been approved, but I am
still waiting for approval on these target-independent bits.

Thanks,
Bill

On Wed, 2014-08-13 at 18:01 -0500, Bill Schmidt wrote:
> Hi,
> 
> I want to reuse some of the infrastructure in web.c (and df.h) for a
> target-specific RTL pass, particularly the union-find stuff.  I could
> just copy it, I suppose, but it seems better to make the struct
> web_entry into a class so that I can inherit what I need.  That's what
> this patch does.
> 
> When I talked about this with some other folks, they mentioned that
> there has been talk of eliminating the web pass altogether, so that
> might be an argument in favor of just copying the logic.  I am happy to
> do that if that's deemed preferable.
> 
> I've taken the original struct and made it a base class that only
> retains the pred field from the original class, along with the
> union-find code.  The reg field is something I don't need, so I've moved
> that into a subclass that the web code now uses.  I've removed the
> extra_info field, which is not used and no longer makes sense with
> inheritance available.  The rest of the changes are just adjusting to
> these modifications.
> 
> I didn't overly "C++ify" anything, to keep the changes as non-invasive
> as possible.
> 
> I'll post the PowerPC patch that makes use of the subclassing shortly.
> 
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> regressions.  Is this ok for trunk?
> 
> Thanks,
> Bill
> 
> 
> 2014-08-13  Bill Schmidt  
> 
>   * df.h (web_entry_base): Replace existing struct web_entry with a
>   new class web_entry_base with only the predecessor member.
>   (unionfind_root): Remove declaration and move to class member.
>   (unionfind_union): Remove declaration and move to friend
>   function.
>   (union_defs): Remove declaration.
>   * web.c (web_entry_base::unionfind_root): Modify to be member
>   function and adjust accessors.
>   (unionfind_union): Modify to be friend function and adjust
>   accessors.
>   (web_entry): New subclass of web_entry_base containing the reg
>   member.
>   (union_match_dups): Modify for struct -> class changes.
>   (union_defs): Likewise.
>   (entry_register): Likewise.
>   (pass_web::execute): Likewise.
> 
> 
> Index: gcc/df.h
> ===
> --- gcc/df.h  (revision 213923)
> +++ gcc/df.h  (working copy)
> @@ -1184,20 +1184,22 @@ df_single_use (const df_insn_info *info)
> 
>  /* web */
> 
> -/* This entry is allocated for each reference in the insn stream.  */
> -struct web_entry
> +class web_entry_base
>  {
> -  /* Pointer to the parent in the union/find tree.  */
> -  struct web_entry *pred;
> -  /* Newly assigned register to the entry.  Set only for roots.  */
> -  rtx reg;
> -  void* extra_info;
> + private:
> +  /* Reference to the parent in the union/find tree.  */
> +  web_entry_base *pred_pvt;
> +
> + public:
> +  /* Accessors.  */
> +  web_entry_base *pred () { return pred_pvt; }
> +  void set_pred (web_entry_base *p) { pred_pvt = p; }
> +
> +  /* Find representative in union-find tree.  */
> +  web_entry_base *unionfind_root ();
> +
> +  /* Union with another set, returning TRUE if they are already unioned.  */
> +  friend bool unionfind_union (web_entry_base *first, web_entry_base 
> *second);
>  };
> 
> -extern struct web_entry *unionfind_root (struct web_entry *);
> -extern bool unionfind_union (struct web_entry *, struct web_entry *);
> -extern void union_defs (df_ref, struct web_entry *,
> - unsigned int *used, struct web_entry *,
> - bool (*fun) (struct web_entry *, struct web_entry *));
> -
>  #endif /* GCC_DF_H */
> Index: gcc/web.c
> ===
> --- gcc/web.c (revision 213923)
> +++ gcc/web.c (working copy)
> @@ -53,17 +53,17 @@ along with GCC; see the file COPYING3.  If not see
> 
>  /* Find the root of unionfind tree (the representative of set).  */
> 
> -struct web_entry *
> -unionfind_root (struct web_entry *element)
> +web_entry_base *
> +web_entry_base::unionfind_root ()
>  {
> -  struct web_entry *element1 = element, *element2;
> +  web_entry_base *element = this, *element1 = this, *element2;
> 
> -  while (element->pred)
> -element = element->pred;
> -  while (element1->pred)
> +  while (element->pred ())
> +element = element->pred ();
> +  while (element1->pred ())
>  {
> -  element2 = element1->pred;
> -  element1->pred = element;
> +  element2 = element1->pred ();
> +  element1->set_pred (element);
>element1 = element2;
>  }
>return element;
> @@ -74,23 +74,32 @@ along with GCC; see the file COPYING3.  If not see
> nothing is done.  Otherwise, return false.  */
> 
>  bool
> -unionfind_union (struct web_entry *first, struct web_entry *second)
> +unionfind_union (web_entry_base *first, web_

Re: DSE calls to builtins (memset, etc)

2014-08-20 Thread Richard Biener
On Wed, Aug 20, 2014 at 4:18 PM, Marc Glisse  wrote:
> On Wed, 20 Aug 2014, Richard Biener wrote:
>
> -  if (stmt != use_stmt
> - && ref_maybe_used_by_stmt_p (use_stmt, gimple_assign_lhs
> (stmt)))
> -   return;
> -



 I don't see how you can remove this code?
>>>
>>>
>>>
>>> dse_possible_dead_store_p already tests ref_maybe_used_by_stmt_p and
>>> thus cannot return true with such a use_stmt, as far as I can see. As I
>>> said, bootstrap+testsuite with an assert instead of 'return' didn't turn
>>> up anything. I could keep it as a gcc_checking_assert (with a slight
>>> update to the comment) if you like. Or did I miss a path in
>>> dse_possible_dead_store_p?
>>
>>
>> Yes, the one that early returns from the operand_equal_p check.
>>
>> You might want to do some svn blaming to see what testcases
>> were added with the above code (and the code surrounding it).
>>
>> I'm not sure either... so if it passes bootstrap & regtest it must be
>> dead code... (well...)
>
>
> The early return operand_equal_p has use_stmt == stmt, so it doesn't even
> reach the call to ref_maybe_used_by_stmt_p I am removing.
>
> svn blame leads me to r132899 (gcc.c-torture/execute/pr35472.c)
> and before that to r131101 (gcc.c-torture/execute/20071219-1.c)

Maybe add some noclone attributes as well?  And try -fno-tree-fre/pre?

But pr35472.c clearly shows what it was trying to fix:

  *p = a;
  *p = b;

with p == &b.  The *p = b; store does _not_ make *p = a dead because
*p = b; is a no-op.  So a modified testcase would be

  *p = a;
  *p = *p;

where without your patch the first DSE pass removes *p = *p (but
not first *p = a).

Maybe if that still works after your patch you can add this as a new testcase,
also verifying that *p = *p store indeed is removed.

> Both testcases are still in the testsuite and passed. The rest of the code
> has changed quite a bit since then, it isn't that surprising if some test
> becomes redundant. But if it makes you nervous, we could keep it as a
> checking_assert, the cost should be negligible...

Nah, I wouldn't do a gcc_checking_assert here.

Richard.

> --
> Marc Glisse


Re: [PATCH] gcc/gcc.c: XNEWVEC enough space for 'saved_suffix' using

2014-08-20 Thread Chen Gang
On 08/18/2014 06:17 PM, Chen Gang wrote:
> Then you didn't do a test suite run.  make check will create .sum files.  Try 
> cd gcc && make check.  Then in testsuite/gcc/gcc.sum there will be a file.
>>>

After get a new PC, I guess, I have passed "make check" with
"--disable-multilibs" (only spent less 10 hours!):

 - "make check" finish return succeed: "echo $?" is 0. And generate 11
   "*.sum" files.

 - 10 of 11 are the same, the different one is about "gcc.sum", after
   check the details contents, it is about my configuration issue, I am
   trying run "cd gcc && make check" again, after re-configuration.

 - for each test, always contents "unexpected errors" for gcc, g++ ...
   but "make check" skip them and continue, at last still "echo $?" = 0.

If what I guess is incorrect, please let me know, thanks.

After finished install gcc*.i686, next, I shall try normal configuration
("enable-multilibs") for "make check". Welcome any ideas, suggestions,
or completions.


Thanks.
-- 
Chen Gang

Open share and attitude like air water and life which God blessed


Re: [PATCH, PR61776] verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate

2014-08-20 Thread Richard Biener
On Tue, Aug 19, 2014 at 8:46 PM, Wei Mi  wrote:
> Sorry for the late reply. I took some time to make myself more
> familiar with NORETURN and related code, and finally I understood what
> you mean and saw why only GF_CALL_CTRL_ALTERING was enough and
> GF_CALL_NORETURN was unneeded. With your suggestion, the change looks
> much briefer! Please check if the new patch attached is ok.

Indeed - much nicer than I originally thought.  Thanks for bearing
with me.

> bootstrap and regression tests pass on x86_64-linux-gnu.

Ok!

Thanks,
Richard.

> Thanks,
> Wei.
>
>> +static void
>> +update_no_abnormal_goto_attr (basic_block bb)
>> +{
>> +  gimple_stmt_iterator gsi;
>> +  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
>> +{
>>
>> it should be enough to check these on last stmts of a basic block, no?
>
> Yes, that is better.
>
>>
>> That you call update_no_abnormal_goto_attr from two places
>> before cleanup_tree_cfg_bb suggests you may want to perform
>> this change in cleanup_control_flow_bb which already looks
>> at the last stmt only?
>
> Changed.
>
>>
>> Btw, I originally had this whole idea of moving flags to the gimple
>> stmt level because of the "interesting" way we handle the noreturn
>> attribute (calls to noreturn functions also end basic-blocks).
>>
>> Thus would it be possible to turn all these into a single flag,
>> GF_CALL_CTRL_ALTERING?  That is, cover everything
>> that is_ctrl_altering_stmt covers?  I suggest we initialize it at
>> CFG build time and only ever clear it later.
>
> Good idea!


Re: DSE calls to builtins (memset, etc)

2014-08-20 Thread Marc Glisse

On Wed, 20 Aug 2014, Richard Biener wrote:


-  if (stmt != use_stmt
- && ref_maybe_used_by_stmt_p (use_stmt, gimple_assign_lhs
(stmt)))
-   return;
-



I don't see how you can remove this code?



dse_possible_dead_store_p already tests ref_maybe_used_by_stmt_p and
thus cannot return true with such a use_stmt, as far as I can see. As I
said, bootstrap+testsuite with an assert instead of 'return' didn't turn
up anything. I could keep it as a gcc_checking_assert (with a slight
update to the comment) if you like. Or did I miss a path in
dse_possible_dead_store_p?


Yes, the one that early returns from the operand_equal_p check.

You might want to do some svn blaming to see what testcases
were added with the above code (and the code surrounding it).

I'm not sure either... so if it passes bootstrap & regtest it must be
dead code... (well...)


The early return operand_equal_p has use_stmt == stmt, so it doesn't even 
reach the call to ref_maybe_used_by_stmt_p I am removing.


svn blame leads me to r132899 (gcc.c-torture/execute/pr35472.c)
and before that to r131101 (gcc.c-torture/execute/20071219-1.c)

Both testcases are still in the testsuite and passed. The rest of the code 
has changed quite a bit since then, it isn't that surprising if some test 
becomes redundant. But if it makes you nervous, we could keep it as a 
checking_assert, the cost should be negligible...


--
Marc Glisse


Revisit placement of symtab_remove_unreachable_nodes

2014-08-20 Thread Jan Hubicka
Hi,
this patch sanifies placement of symtab_remove_unreachable_nodes.  First is a
confussion about early local passes.  THe superpass TODO contains
symtab_remove_unreachable_nodes that is intended to run after local passes but
PM executes it before (because subpasses are run after TODOs). This is supposed
to be handled in cgraphunit.c but these days it is too late, because we do have
small IPA passes run after local cleanups (profiling, pass_ipa_tm etc.). This
makes these passes to process about 200K extra functions on firefox.

symtab_remove_unreachable_nodes takes parameter whether it is run before or
after inlining.  This parameter is wrong at couple times, so I fixed it too.
Incrementally I plan to make this part of cgraph_state as theparameter is
clearly confusing and hard to maintain.

Bootstrapped/regtested x86_64-linux.

* cgraphunit.c (ipa_passes, compile): Reshedule
symtab_remove_unreachable_nodes passes; update comments.
* ipa-inline.c (pass_data_ipa_inline): Do not schedule
TODO_remove_functions before the pass; the functions ought to be
already removed.
* ipa.c (pass_data_ipa_free_inline_summary): Enable dump; schedule
TODO_remove_functions.
* passes.c (pass_data_early_local_passes): Do not schedule function
removal.
(execute_one_pass): Fix call of symtab_remove_unreachable_nodes.

* lto.c (read_cgraph_and_symbols): Fix symtab_remove_unreachable_nodes
call.
(do_whole_program_analysis): Only sanity check that IPA passes cleans 
up.

* testsuite/g++.dg/ipa/devirt-17.C: Update template.
* testsuite/g++.dg/ipa/devirt-16.C: Update template.
Index: cgraphunit.c
===
--- cgraphunit.c(revision 214193)
+++ cgraphunit.c(working copy)
@@ -2047,10 +2047,6 @@ ipa_passes (void)
return;
 }
 
-  /* We never run removal of unreachable nodes after early passes.  This is
- because TODO is run before the subpasses.  It is important to remove
- the unreachable functions to save works at IPA level and to get LTO
- symbol tables right.  */
   symtab_remove_unreachable_nodes (true, cgraph_dump_file);
 
   /* If pass_all_early_optimizations was not scheduled, the state of
@@ -2184,7 +2180,8 @@ compile (void)
 }
 
   /* This pass remove bodies of extern inline functions we never inlined.
- Do this later so other IPA passes see what is really going on.  */
+ Do this later so other IPA passes see what is really going on.
+ FIXME: THis should be run just after inlining by pasmanager.  */
   symtab_remove_unreachable_nodes (false, dump_file);
   cgraph_global_info_ready = true;
   if (cgraph_dump_file)
@@ -2210,9 +2207,10 @@ compile (void)
   cgraph_materialize_all_clones ();
   bitmap_obstack_initialize (NULL);
   execute_ipa_pass_list (g->get_passes ()->all_late_ipa_passes);
-  symtab_remove_unreachable_nodes (true, dump_file);
 #ifdef ENABLE_CHECKING
   symtab_node::verify_symtab_nodes ();
+  /* Verify late IPA passes cleaned up after themselves.  */
+  gcc_assert (!symtab_remove_unreachable_nodes (false, dump_file));
 #endif
   bitmap_obstack_release (NULL);
   mark_functions_to_output ();
Index: testsuite/g++.dg/ipa/devirt-16.C
===
--- testsuite/g++.dg/ipa/devirt-16.C(revision 214193)
+++ testsuite/g++.dg/ipa/devirt-16.C(working copy)
@@ -32,7 +32,6 @@ main()
   return b->foo();
 }
 
-/* { dg-final { scan-ipa-dump "devirtualizing" "whole-program"} } */
 /* { dg-final { scan-ipa-dump "builtin_unreachable" "whole-program"} } */
 /* { dg-final { scan-ipa-dump-not "A::foo" "whole-program"} } */
 /* { dg-final { scan-ipa-dump-not "A::foo" "whole-program"} } */
Index: testsuite/g++.dg/ipa/devirt-17.C
===
--- testsuite/g++.dg/ipa/devirt-17.C(revision 214193)
+++ testsuite/g++.dg/ipa/devirt-17.C(working copy)
@@ -37,7 +37,6 @@ main()
   return b->foo();
 }
 
-/* { dg-final { scan-ipa-dump "devirtualizing" "whole-program"} } */
 /* { dg-final { scan-ipa-dump-not "builtin_unreachable" "whole-program"} } */
 /* { dg-final { scan-ipa-dump "B::foo" "whole-program"} } */
 /* { dg-final { scan-ipa-dump-not "A::foo" "whole-program"} } */
Index: ipa-inline.c
===
--- ipa-inline.c(revision 214193)
+++ ipa-inline.c(working copy)
@@ -2519,7 +2519,7 @@ const pass_data pass_data_ipa_inline =
   0, /* properties_required */
   0, /* properties_provided */
   0, /* properties_destroyed */
-  TODO_remove_functions, /* todo_flags_start */
+  0, /* todo_flags_start */
   ( TODO_dump_symtab ), /* todo_flags_finish */
 };
 
Index: ipa.c
===
--- ipa.c   (revision 214193)
+++ ipa.c   (working copy)
@@ -727,14 +727,17 @@ name

Re: DSE calls to builtins (memset, etc)

2014-08-20 Thread Richard Biener
On Wed, Aug 20, 2014 at 9:14 AM, Marc Glisse  wrote:
> Hello,
>
> here is a new version of the patch which passed bootstrap+testsuite. I am
> still removing the ref_maybe_used_by_stmt_p test, see the previous message
> for a discussion.

Looks good to me.  I'm still nervous about removing that check (though
the description looks odd - if the stmt kills the lhs and it also uses
it then if this is not an exact overlap it's undefined and if it is then
the stmt is still dead...).

So - ok if it bootstraps/tests ok.

Thanks,
Richard.

> 2014-08-20  Marc Glisse  
>
> PR tree-optimization/62112
> gcc/
> * gimple-iterator.c (gsi_replace): Return whether EH cleanup is
> needed.
> * gimple-iterator.h (gsi_replace): Return bool.
> * tree-ssa-alias.c (ref_may_alias_global_p_1): New helper, code
> moved from ref_may_alias_global_p.
>
> (ref_may_alias_global_p, refs_may_alias_p,
> ref_maybe_used_by_stmt_p):
> New overloads.
> (ref_maybe_used_by_call_p): Take ao_ref* instead of tree.
> (stmt_kills_ref_p_1): Rename...
> (stmt_kills_ref_p): ... to this.
> * tree-ssa-alias.h (ref_may_alias_global_p,
> ref_maybe_used_by_stmt_p,
> stmt_kills_ref_p): Declare.
> * tree-ssa-dse.c (dse_possible_dead_store_p): New argument, use it.
>
> Move the self-assignment case...
> (dse_optimize_stmt): ... here. Handle builtin calls. Remove dead
> code.
> gcc/testsuite/
> * gcc.dg/tree-ssa/pr62112-1.c: New file.
> * gcc.dg/tree-ssa/pr62112-2.c: Likewise.
>
> --
> Marc Glisse
> Index: gcc/gimple-iterator.c
> ===
> --- gcc/gimple-iterator.c   (revision 214210)
> +++ gcc/gimple-iterator.c   (working copy)
> @@ -422,51 +422,54 @@ gsi_split_seq_before (gimple_stmt_iterat
>/* Cut OLD_SEQ before I.  */
>gimple_seq_set_last (&old_seq, prev);
>if (prev->next)
>  prev->next = NULL;
>  }
>
>
>  /* Replace the statement pointed-to by GSI to STMT.  If UPDATE_EH_INFO
> is true, the exception handling information of the original
> statement is moved to the new statement.  Assignments must only be
> -   replaced with assignments to the same LHS.  */
> +   replaced with assignments to the same LHS.  Returns whether EH edge
> +   cleanup is required.  */
>
> -void
> +bool
>  gsi_replace (gimple_stmt_iterator *gsi, gimple stmt, bool update_eh_info)
>  {
>gimple orig_stmt = gsi_stmt (*gsi);
> +  bool require_eh_edge_purge = false;
>
>if (stmt == orig_stmt)
> -return;
> +return false;
>
>gcc_assert (!gimple_has_lhs (orig_stmt) || !gimple_has_lhs (stmt)
>   || gimple_get_lhs (orig_stmt) == gimple_get_lhs (stmt));
>
>gimple_set_location (stmt, gimple_location (orig_stmt));
>gimple_set_bb (stmt, gsi_bb (*gsi));
>
>/* Preserve EH region information from the original statement, if
>   requested by the caller.  */
>if (update_eh_info)
> -maybe_clean_or_replace_eh_stmt (orig_stmt, stmt);
> +require_eh_edge_purge = maybe_clean_or_replace_eh_stmt (orig_stmt,
> stmt);
>
>gimple_duplicate_stmt_histograms (cfun, stmt, cfun, orig_stmt);
>
>/* Free all the data flow information for ORIG_STMT.  */
>gimple_set_bb (orig_stmt, NULL);
>gimple_remove_stmt_histograms (cfun, orig_stmt);
>delink_stmt_imm_use (orig_stmt);
>
>gsi_set_stmt (gsi, stmt);
>gimple_set_modified (stmt, true);
>update_modified_stmt (stmt);
> +  return require_eh_edge_purge;
>  }
>
>
>  /* Replace the statement pointed-to by GSI with the sequence SEQ.
> If UPDATE_EH_INFO is true, the exception handling information of
> the original statement is moved to the last statement of the new
> sequence.  If the old statement is an assignment, then so must
> be the last statement of the new sequence, and they must have the
> same LHS.  */
>
> Index: gcc/gimple-iterator.h
> ===
> --- gcc/gimple-iterator.h   (revision 214210)
> +++ gcc/gimple-iterator.h   (working copy)
> @@ -51,21 +51,21 @@ extern void gsi_insert_seq_before_withou
>  extern void gsi_insert_seq_before (gimple_stmt_iterator *, gimple_seq,
>enum gsi_iterator_update);
>  extern void gsi_insert_seq_after_without_update (gimple_stmt_iterator *,
>  gimple_seq,
>  enum gsi_iterator_update);
>  extern void gsi_insert_seq_after (gimple_stmt_iterator *, gimple_seq,
>   enum gsi_iterator_update);
>  extern gimple_seq gsi_split_seq_after (gimple_stmt_iterator);
>  extern void gsi_set_stmt (gimple_stmt_iterator *, gimple);
>  extern void gsi_split_seq_before (gimple_stmt_iterator *, gimple_seq *);
> -extern void gsi_replace (gimple_stmt_iterator *, gimple, bool);
> +extern bool gsi_replace (gimple_stmt

Re: [PATCH][match-and-simplify] Fix comparison pattern

2014-08-20 Thread Richard Biener
On Wed, 20 Aug 2014, Marc Glisse wrote:

> On Wed, 20 Aug 2014, Richard Biener wrote:
> 
> > On Wed, 20 Aug 2014, Marc Glisse wrote:
> > 
> > > On Wed, 20 Aug 2014, Richard Biener wrote:
> > > 
> > > > Committed.
> > > > 
> > > > Also makes visible a desirable change I plan for if-exprs.  They
> > > > should behave like outer ifs and allow us to write that series
> > > > of pattern as
> > > > 
> > > > (for op in eq ne
> > > >  /* Simplify X * C1 CMP 0 to X CMP 0 if C1 is not zero.  */
> > > >  (simplify
> > > >(op (mult @0 INTEGER_CST@1) integer_zerop@2)
> > > >/* In fold-const.c we have this and the following patterns
> > > >   combined because there we can "compute" the operator
> > > >   to use by using swap_tree_comparison.  */
> > > >(if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0)))
> > > >  (if (tree_int_cst_sgn (@1) > 0)
> > > >  (op @0 @2))
> > > >  (if (tree_int_cst_sgn (@1) < 0 && op == EQ_EXPR)
> > > >  (ne @0 @2))
> > > >  (if (tree_int_cst_sgn (@1) < 0 && op == NE_EXPR)
> > > >  (eq @0 @2)
> > > > 
> > > > that is, inner ifs have two operands, one condition and one
> > > > "result" (which can be another if).  And the simplify
> > > > now has one mandatory match operand and at least one
> > > > result operand (if which all but the last have to be an
> > > > 'if').
> > > 
> > > Not related to how you do "if" and such, but this simplification doesn't
> > > make
> > > sense. swap_tree_comparison preserves eq and ne, you only care that @1 is
> > > non-zero. It is for comparisons like lt that the sign can change the
> > > operation.
> > 
> > Oops, true (the fold_comparison code doesn't restrict itself to
> > eq and ne).  So for ne and eq the sign of @1 doesn't matter.
> > So we can improve here and do
> > 
> > /* Simplify X * C1 CMP 0 to X CMP 0 if C1 is not zero.  */
> > (for op in lt le eq ne ge gt
> >  (simplify
> >(op (mult @0 INTEGER_CST@1) integer_zerop@2)
> >/* In fold-const.c we have this and the following pattern
> >   combined because there we can "compute" the operator
> >   to use by using swap_tree_comparison.  Here we manage
> >   to use only two patterns by swapping the operands instead
> >   of changing the comparison code.  */
> >(if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
> > && tree_int_cst_sgn (@1) > 0))
> >(op @0 @2))
> >  (simplify
> >(op (mult @0 INTEGER_CST@1) integer_zerop@2)
> >(if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
> > && tree_int_cst_sgn (@1) < 0))
> >(op @2 @0)))
> > 
> > right?
> 
> Yes, that looks fine.
> 
> (fold-const.c checks TREE_OVERFLOW(@1), I don't know about that)

Not sure why it does that.

> (we are obviously losing the warning)

Yes.  I have no idea how to preserve those - I'd have to invent
a similar API as fold() does to defer warnings.

Other than that adding some special syntax just for the overflow
warnings is of course possible.

Richard.


spar-rtems add leon3 multlib to 4.9

2014-08-20 Thread Joel Sherrill
I would like to add this patch to the 4.9 branch. It is RTEMS
specific and takes advantage of the leon3 multilib support from
Eric Botcazou. 

OK to commit?

--joel

gcc/ChangeLog
2013-08-29  Sebastian Huber

* config/sparc/t-rtems: Add leon3 multilibs.
---
  gcc/config/sparc/t-rtems |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/sparc/t-rtems b/gcc/config/sparc/t-rtems
index 63d0217..f1a3d84 100644
--- a/gcc/config/sparc/t-rtems
+++ b/gcc/config/sparc/t-rtems
@@ -17,6 +17,6 @@
  #.
  #

-MULTILIB_OPTIONS = msoft-float mcpu=v8
-MULTILIB_DIRNAMES = soft v8
+MULTILIB_OPTIONS = msoft-float mcpu=v8/mcpu=leon3
+MULTILIB_DIRNAMES = soft v8 leon3
  MULTILIB_MATCHES = msoft-float=mno-fpu

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985



Re: DSE calls to builtins (memset, etc)

2014-08-20 Thread Richard Biener
On Tue, Aug 19, 2014 at 4:16 PM, Marc Glisse  wrote:
> On Tue, 19 Aug 2014, Richard Biener wrote:
>
>>>  /* Return true whether REF may refer to global memory.  */
>>>
>>>  bool
>>> -ref_may_alias_global_p (tree ref)
>>> +ref_may_alias_global_p (ao_ref *ref)
>>>  {
>>> -  tree base = get_base_address (ref);
>>> +  tree base = ao_ref_base (ref);
>>>if (DECL_P (base))
>>>  return is_global_var (base);
>>>else if (TREE_CODE (base) == MEM_REF
>>>|| TREE_CODE (base) == TARGET_MEM_REF)
>>>  return ptr_deref_may_alias_global_p (TREE_OPERAND (base, 0));
>>>return true;
>>>  }
>>>
>>> +bool
>>> +ref_may_alias_global_p (tree ref)
>>> +{
>>> +  ao_ref r;
>>> +  ao_ref_init (&r, ref);
>>> +  return ref_may_alias_global_p (&r);
>>> +}
>>> +
>>
>>
>> I'd do two wrapers then since get_base_address is way cheaper
>> than doing ao_ref_base.  Thus, split out the code doing the
>> actual job into a static ref_may_alias_global_1?
>
>
> Ok, for this function the extra precision in ao_ref_base is indeed
> useless.
>
>
>>> +  /* We know we have virtual definitions.  We can handle assignments and
>>> + some builtin calls.  */
>>> +  if (is_gimple_call (stmt))
>>
>>
>>  if (gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
>>
>> which also does argument verification
>
>
> Good point, then I can remove the test 'nargs < 2' below.
>
>
>>> +{
>>> +  tree callee = gimple_call_fndecl (stmt);
>>> +  if (!callee || DECL_BUILT_IN_CLASS (callee) != BUILT_IN_NORMAL)
>>> +   return;
>>> +  switch (DECL_FUNCTION_CODE (callee))
>>> +   {
>>> + case BUILT_IN_MEMCPY:
>>> + case BUILT_IN_MEMMOVE:
>>> + case BUILT_IN_MEMSET:
>>> +   {
>>> + gimple use_stmt;
>>> + ao_ref ref;
>>> + tree size = NULL_TREE;
>>> + int nargs = gimple_call_num_args (stmt);
>>> + if (nargs < 2)
>>> +   return;
>>> + if (nargs == 3)
>>> +   size = gimple_call_arg (stmt, 2);
>>> + tree ptr = gimple_call_arg (stmt, 0);
>>> + ao_ref_init_from_ptr_and_size (&ref, ptr, size);
>>> + if (!dse_possible_dead_store_p (&ref, stmt, &use_stmt))
>>> +   return;
>>> +
>>> + if (dump_file && (dump_flags & TDF_DETAILS))
>>> +   {
>>> + fprintf (dump_file, "  Deleted dead store '");
>>
>>
>> dead call
>>
>>> + print_gimple_stmt (dump_file, gsi_stmt (*gsi),
>>> dump_flags,
>>> 0);
>>> + fprintf (dump_file, "'\n");
>>> +   }
>>> +
>>> + tree lhs = gimple_call_lhs (stmt);
>>> + if (lhs)
>>> +   {
>>> + gimple new_stmt = gimple_build_assign (lhs, ptr);
>>> + unlink_stmt_vdef (stmt);
>>> + gsi_replace (gsi, new_stmt, true);
>>
>>
>> You may need eh cleanup here as well.
>
>
> Cleanup is one of the most mysterious parts of gcc, I am never sure what
> to release/update/unlink/purge/etc :-(
>
>
>> Bonus points if you make gsi_replace return whether
>> maybe_clean_or_replace_eh_stmt returned true.
>
>
> Ok, that seems trivial.
>
>
>>> -  basic_block bb;
>>> -
>>> -  /* If use_stmt is or might be a nop assignment, e.g. for
>>> -  struct { ... } S a, b, *p; ...
>>> -  b = a; b = b;
>>> -or
>>> -  b = a; b = *p; where p might be &b,
>>> -or
>>> -   *p = a; *p = b; where p might be &b,
>>> -or
>>> -   *p = *u; *p = *v; where p might be v, then USE_STMT
>>> - acts as a use as well as definition, so store in STMT
>>> - is not dead.  */
>>> -  if (stmt != use_stmt
>>> - && ref_maybe_used_by_stmt_p (use_stmt, gimple_assign_lhs
>>> (stmt)))
>>> -   return;
>>> -
>>
>>
>> I don't see how you can remove this code?
>
>
> dse_possible_dead_store_p already tests ref_maybe_used_by_stmt_p and
> thus cannot return true with such a use_stmt, as far as I can see. As I
> said, bootstrap+testsuite with an assert instead of 'return' didn't turn
> up anything. I could keep it as a gcc_checking_assert (with a slight
> update to the comment) if you like. Or did I miss a path in
> dse_possible_dead_store_p?

Yes, the one that early returns from the operand_equal_p check.

You might want to do some svn blaming to see what testcases
were added with the above code (and the code surrounding it).

I'm not sure either... so if it passes bootstrap & regtest it must be
dead code... (well...)

Richard.

> Thanks,
>
> --
> Marc Glisse


[PATCH][match-and-simplify] Fix texinfo errors

2014-08-20 Thread Richard Biener

Committed.

Richard.

2014-08-20  Richard Biener  

* match-and-simplify.texi: Fix errors during pdf build.

Index: gcc/doc/match-and-simplify.texi
===
--- gcc/doc/match-and-simplify.texi (revision 214220)
+++ gcc/doc/match-and-simplify.texi (working copy)
@@ -34,24 +34,12 @@ APIs are introduced.
 @section GIMPLE API
 @cindex GIMPLE API
 
-The main GIMPLE API entry to the expression simplifications mimics
-that of the GENERIC fold_@{unary,binary,ternary@} API:
-
-@deftypefn
-tree gimple_simplify (enum tree_code, tree, tree,
-gimple_seq *, tree (*)(tree));
-@end deftypefn
-@deftypefn
-tree gimple_simplify (enum tree_code, tree, tree, tree,
-gimple_seq *, tree (*)(tree));
-@end deftypefn
-@deftypefn
-tree gimple_simplify (enum tree_code, tree, tree, tree, tree,
-gimple_seq *, tree (*)(tree));
-@end deftypefn
-@deftypefn
-tree gimple_simplify (enum built_in_function, tree, tree,
-gimple_seq *, tree (*)(tree));
+@deftypefn {GIMPLE function} tree gimple_simplify (enum tree_code, tree, tree, 
gimple_seq *, tree (*)(tree))
+@deftypefnx {GIMPLE function} tree gimple_simplify (enum tree_code, tree, 
tree, tree, gimple_seq *, tree (*)(tree))
+@deftypefnx {GIMPLE function} tree gimple_simplify (enum tree_code, tree, 
tree, tree, tree, gimple_seq *, tree (*)(tree))
+@deftypefnx {GIMPLE function} tree gimple_simplify (enum built_in_function, 
tree, tree, gimple_seq *, tree (*)(tree))
+The main GIMPLE API entry to the expression simplifications mimicing
+that of the GENERIC fold_@{unary,binary,ternary@} functions.
 @end deftypefn
 
 thus providing n-ary overloads for operation or function.  The
@@ -62,33 +50,17 @@ tie simplifications to a SSA lattice.
 
 In addition to those APIs a fold_stmt-like interface is provided with
 
-@deftypefn
-bool gimple_simplify (gimple_stmt_iterator *, tree (*)(tree));
+@deftypefn bool gimple_simplify (gimple_stmt_iterator *, tree (*)(tree));
 @end deftypefn
 
 which also has the additional valueization hook.
 
 Ontop of these a @code{fold_buildN}-like API for GIMPLE is introduced:
 
-@deftypefn
-tree gimple_build (gimple_seq *, location_t,
-   enum tree_code, tree, tree,
-   tree (*valueize) (tree) = NULL);
-@end deftypefn
-@deftypefn
-tree gimple_build (gimple_seq *, location_t,
-   enum tree_code, tree, tree, tree,
-   tree (*valueize) (tree) = NULL);
-@end deftypefn
-@deftypefn
-tree gimple_build (gimple_seq *, location_t,
-   enum tree_code, tree, tree, tree, tree,
-   tree (*valueize) (tree) = NULL);
-@end deftypefn
-@deftypefn
-tree gimple_build (gimple_seq *, location_t,
-   enum built_in_function, tree, tree,
-   tree (*valueize) (tree) = NULL);
+@deftypefn tree gimple_build (gimple_seq *, location_t, enum tree_code, tree, 
tree, tree (*valueize) (tree) = NULL);
+@deftypefnx tree gimple_build (gimple_seq *, location_t, enum tree_code, tree, 
tree, tree, tree (*valueize) (tree) = NULL);
+@deftypefnx tree gimple_build (gimple_seq *, location_t, enum tree_code, tree, 
tree, tree, tree, tree (*valueize) (tree) = NULL);
+@deftypefnx tree gimple_build (gimple_seq *, location_t, enum 
built_in_function, tree, tree, tree (*valueize) (tree) = NULL);
 @end deftypefn
 
 which is supposed to replace @code{force_gimple_operand (fold_buildN (...), 
...)}.


Re: [PATCH i386 AVX512] [20/n] AVX-512 integer shift pattern.

2014-08-20 Thread Uros Bizjak
On Wed, Aug 20, 2014 at 3:08 PM, Kirill Yukhin  wrote:
> Hello,
> On 15 Aug 20:35, Uros Bizjak wrote:
>> On Fri, Aug 15, 2014 at 1:56 PM, Kirill Yukhin  
>> wrote:
>> Again, please split insn pattern to avoid:
>>
>> +  "TARGET_SSE2
>> +   && 
>> +   && ((mode != V16HImode && mode != V8HImode)
>> +   || TARGET_AVX512BW
>> +   || !)"
>>
>> insn constraints. The insn constraint should use baseline TARGET_* and
>> mode iterator should use TARGET_* that results in "baseline TARGET_ &&
>> iterator TARGET_" for certain mode. If these are properly used, then
>> there is no need to use mode checks in the insn constraint.
> I've refactored the pattern. But it should be mentioned,
> that it still uses mode checkes implicitly.
> Problem is that masking allowed either for ZMM or (XMM|YMM)+TARGET_AVX512VL,
> supposing that TARGET_AVX512F is on for both cases.
> That is what "mask_mode512bit_condition" check:
>   (define_subst_attr "mask_mode512bit_condition" "mask" "1" "( == 
> 64 || TARGET_AVX512VL)")
>
> So, this pattern:
> (define_insn "3"
>   [(set (match_operand:VI2_AVX2_AVX512BW 0 "register_operand" "=x,v")
> (any_lshift:VI2_AVX2_AVX512BW
>   (match_operand:VI2_AVX2_AVX512BW 1 "register_operand" "0,v")
>   (match_operand:SI 2 "nonmemory_operand" "xN,vN")))]
>   "TARGET_SSE2 &&  && "
>
> is expanded to (16hi, mask, ashift):
> (define_insn ("ashlv16hi3_mask")
>  [
> (set (match_operand:V16HI 0 ("register_operand") ("=x,v"))
> (vec_merge:V16HI (ashift:V16HI (match_operand:V16HI 1 
> ("register_operand") ("0,v"))
> (match_operand:SI 2 ("nonmemory_operand") ("xN,vN")))
> (match_operand:V16HI 3 ("vector_move_operand") ("0C,0C"))
> (match_operand:HI 4 ("register_operand") ("Yk,Yk"
> ] ("(TARGET_AVX512F) && ((TARGET_SSE2 && (32 == 64 || TARGET_AVX512VL) && 
> TARGET_AVX512BW) && (TARGET_AVX2))")
>
> (TARGET_AVX512F) came from `mask' subst, (32 == 64 || TARGET_AVX512VL) is what
> I've described above, (TARGET_AVX512BW) came from coresponding subst attr and
> TARGET_AVX2 belongs to mode iterator.

This looks OK to me, enabling the insn using "&& "
is the established practice. As the general approach, the final insn
enable condition should be formed from baseline condition, conditional
mode and define-subst enables in the most logical way.

> Bootstrapped and avx512-regtested.
>
> gcc/
> * config/i386/sse.md
> (define_mode_iterator VI248_AVX2): Delete.
> (define_mode_iterator VI2_AVX2_AVX512BW): New.
> (define_mode_iterator VI48_AVX2): Ditto.
> (define_insn ""3"): Add masking.
> Split into two similar patterns, which use different mode
> iterators: VI2_AVX2_AVX512BW and VI48_AVX2.
> * config/i386/subst.md (define_subst_attr "mask_avx512bw_condition"):
> New.

OK for mainline.

Thanks,
Uros.


[PATCH][match-and-simplify] Nested inner ifs

2014-08-20 Thread Richard Biener

$subject.

Bootstrap ongoing on x86_64-unknown-linux-gnu.

Richard.

2014-08-20  Richard Biener  

* genmatch.c (copy_reverse): New function.
(parse_simplify): Support nested inner ifs.
* match-comparison.pd: Use nested inner ifs.

Index: match-and-simplify/gcc/genmatch.c
===
*** match-and-simplify.orig/gcc/genmatch.c  2014-08-20 14:41:39.517805937 
+0200
--- match-and-simplify/gcc/genmatch.c   2014-08-20 15:15:01.272668118 +0200
*** parse_op (cpp_reader *r)
*** 2223,2231 
return op;
  }
  
  /* Parse
!  (simplify ""
!  )  */
  
  static void
  parse_simplify (cpp_reader *r, source_location match_location,
--- 2223,2245 
return op;
  }
  
+ /* Return a reversed copy of V.  */
+ 
+ static vec
+ copy_reverse (vec v)
+ {
+   vec c = vNULL;
+   for (int i = v.length ()-1; i >= 0; --i)
+ c.safe_push (v[i]);
+   return c;
+ }
+ 
  /* Parse
!  'simplify' [  ]  
!with
!   =  | 
!   = '(' 'if' '('  ')'  ')'
!and fill SIMPLIFIERS with the results.  */
  
  static void
  parse_simplify (cpp_reader *r, source_location match_location,
*** parse_simplify (cpp_reader *r, source_lo
*** 2249,2290 
  
token = peek (r);
  
!   operand *result = NULL;
!   source_location result_loc;
!   while (!result
!&& token->type == CPP_OPEN_PAREN)
  {
!   eat_token (r, CPP_OPEN_PAREN);
!   if (peek_ident (r, "if"))
{
! vec ifexprs = vNULL;
! eat_ident (r, "if");
! ifexprs.safe_push (parse_c_expr (r, CPP_OPEN_PAREN));
! /* ???  Support nested (if ...) here.  */
! token = peek (r);
! simplifiers.safe_push
! (new simplify (id, match, match_location, parse_op (r),
!token->src_loc, ifexprs));
}
else
{
! result_loc = token->src_loc;
! result = parse_expr (r);
}
-   eat_token (r, CPP_CLOSE_PAREN);
token = peek (r);
  }
- 
-   if (!result
-   && token->type != CPP_CLOSE_PAREN)
- {
-   result_loc = token->src_loc;
-   result = parse_op (r);
- }
- 
-   if (result)
- simplifiers.safe_push
-   (new simplify (id, match, match_location, result, result_loc));
  }
  
  void parse_pattern (cpp_reader *, vec&);
--- 2263,2323 
  
token = peek (r);
  
!   auto_vec ifexprs;
!   while (1)
  {
!   if (token->type == CPP_OPEN_PAREN)
{
! eat_token (r, CPP_OPEN_PAREN);
! if (peek_ident (r, "if"))
!   {
! eat_ident (r, "if");
! ifexprs.safe_push (parse_c_expr (r, CPP_OPEN_PAREN));
!   }
! else
!   {
! simplifiers.safe_push
! (new simplify (id, match, match_location, parse_expr (r),
!token->src_loc, copy_reverse (ifexprs)));
! eat_token (r, CPP_CLOSE_PAREN);
! /* A "default" result closes the enclosing scope.  */
! if (ifexprs.length () > 0)
!   {
! eat_token (r, CPP_CLOSE_PAREN);
! ifexprs.pop ();
!   }
! else
!   return;
!   }
!   }
!   else if (token->type == CPP_CLOSE_PAREN)
!   {
! /* Close a scope if requested.  */
! if (ifexprs.length () > 0)
!   {
! eat_token (r, CPP_CLOSE_PAREN);
! ifexprs.pop ();
! token = peek (r);
!   }
! else
!   return;
}
else
{
! simplifiers.safe_push
! (new simplify (id, match, match_location, parse_op (r),
!token->src_loc, copy_reverse (ifexprs)));
! /* A "default" result closes the enclosing scope.  */
! if (ifexprs.length () > 0)
!   {
! eat_token (r, CPP_CLOSE_PAREN);
! ifexprs.pop ();
!   }
! else
!   return;
}
token = peek (r);
  }
  }
  
  void parse_pattern (cpp_reader *, vec&);
Index: match-and-simplify/gcc/match-comparison.pd
===
*** match-and-simplify.orig/gcc/match-comparison.pd 2014-08-20 
14:41:39.517805937 +0200
--- match-and-simplify/gcc/match-comparison.pd  2014-08-20 15:02:09.222721273 
+0200
***
*** 7,16 
 to use by using swap_tree_comparison.  Here we manage
 to use only two patterns by swapping the operands instead
 of changing the comparison code.  */
! (if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
!  && tree_int_cst_sgn (@1) > 0)
!  (op @0 @2))
! (if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
!  && tree_int_cst_sgn (@1) < 0)
!  (op @2 @0
  
--- 7,15 
 to use by using swap_tree_comparison.  Here we manage
 to use only two patterns by swapping t

Re: [PATCH i386 AVX512] [19/n] Extends AVX-512 broadcasts.

2014-08-20 Thread Uros Bizjak
On Wed, Aug 20, 2014 at 2:51 PM, Kirill Yukhin  wrote:
> Hello Uroš,
> On 15 Aug 20:29, Uros Bizjak wrote:
>> Can you avoid insn constraints like:
>>
>> > +  "TARGET_AVX512DQ && ( == 64 || TARGET_AVX512VL)"
>>
>> This should be split to two insn patterns, each with different
>> baseline insn constraint.
>
> I've splitted pattern into two similar w/ different mode iterators.
>
> Bootstrapped and avx512-regtested.
>
> Is it ok for trunk?
>
> gcc/
> * config/i386/sse.md
> (define_mode_iterator VI4F_BRCST32x2): New.
> (define_mode_attr 64x2mode): Ditto.
> (define_mode_attr 32x2mode): Ditto.
> (define_insn "avx512dq_broadcast"
> with VI4F_BRCST32x2 mode iterator): Ditto.
> (define_insn "avx512vl_broadcast_1"): 
> Ditto.
> (define_insn "avx512dq_broadcast_1"
> with V16FI mode iterator): Ditto.
> (define_insn "avx512dq_broadcast_1"
> with VI8F_512 mode iterator): Ditto.
> (define_insn "avx512dq_broadcast_1"
> with VI8F_256 mode iterator): Ditto.
> --
> Thanks, K
>
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 4632b3a..6a5faee 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -482,6 +482,7 @@
>  (define_mode_iterator VI8F_128 [V2DI V2DF])
>  (define_mode_iterator VI4F_256 [V8SI V8SF])
>  (define_mode_iterator VI8F_256 [V4DI V4DF])
> +(define_mode_iterator VI8F_512 [V8DI V8DF])
>  (define_mode_iterator VI8F_256_512
>[V4DI V4DF (V8DI "TARGET_AVX512F") (V8DF "TARGET_AVX512F")])
>  (define_mode_iterator VI48F_256_512
> @@ -14514,6 +14515,83 @@
> (set_attr "prefix" "vex")
> (set_attr "mode" "")])
>
> +;; For broadcast[i|f]32x2.  Yes there is no v4sf version, only v4si.
> +(define_mode_iterator VI4F_BRCST32x2
> +  [V16SI (V8SI "TARGET_AVX512VL") (V4SI "TARGET_AVX512VL")
> +   V16SF (V8SF "TARGET_AVX512VL")])
> +
> +(define_mode_attr 64x2mode
> +  [(V8DF "V2DF") (V8DI "V2DI") (V4DI "V2DI") (V4DF "V2DF")])
> +
> +(define_mode_attr 32x2mode
> +  [(V16SF "V2SF") (V16SI "V2SI") (V8SI "V2SI")
> +  (V8SF "V2SF") (V4SI "V2SI")])
> +
> +(define_insn "avx512dq_broadcast"
> +  [(set (match_operand:VI4F_BRCST32x2 0 "register_operand" "=v")
> +   (vec_duplicate:VI4F_BRCST32x2
> + (vec_select:<32x2mode>
> +   (match_operand: 1 "nonimmediate_operand" "vm")
> +   (parallel [(const_int 0) (const_int 1)]]
> +  "TARGET_AVX512DQ"
> +  "vbroadcast32x2\t{%1, %0|%0, 
> %1}"
> +  [(set_attr "type" "ssemov")
> +   (set_attr "prefix_extra" "1")
> +   (set_attr "prefix" "evex")
> +   (set_attr "mode" "")])
> +
> +(define_insn "avx512vl_broadcast_1"
> +  [(set (match_operand:VI4F_256 0 "register_operand" "=v,v")
> +(vec_duplicate:VI4F_256
> + (match_operand: 1 "nonimmediate_operand" "v,m")))]
> +  "TARGET_AVX512VL"
> +  "@
> +   vshuf32x4\t{$0x0, %t1, %t1, 
> %0|%0, %t1, %t1, 0x0}
> +   vbroadcast32x4\t{%1, %0|%0, 
> %1}"
> +  [(set_attr "type" "ssemov")
> +   (set_attr "prefix_extra" "1")
> +   (set_attr "prefix" "evex")
> +   (set_attr "mode" "")])
> +
> +(define_insn "avx512dq_broadcast_1"
> +  [(set (match_operand:V16FI 0 "register_operand" "=v,v")
> +   (vec_duplicate:V16FI
> + (match_operand: 1 "nonimmediate_operand" "v,m")))]
> +  "TARGET_AVX512DQ"
> +  "@
> +   vshuf32x4\t{$0x44, %g1, %g1, 
> %0|%0, %g1, %g1, 0x44}
> +   vbroadcast32x8\t{%1, %0|%0, 
> %1}"
> +  [(set_attr "type" "ssemov")
> +   (set_attr "prefix_extra" "1")
> +   (set_attr "prefix" "evex")
> +   (set_attr "mode" "")])
> +
> +(define_insn "avx512dq_broadcast_1"
> +  [(set (match_operand:VI8F_512 0 "register_operand" "=v,v")
> +   (vec_duplicate:VI8F_512
> + (match_operand:<64x2mode> 1 "nonimmediate_operand" "v,m")))]
> +  "TARGET_AVX512DQ"
> +  "@
> +   vshuf64x2\t{$0x0, %g1, %g1, 
> %0|%0, %g1, %g1, 0x0}
> +   vbroadcast64x2\t{%1, %0|%0, 
> %1}"
> +  [(set_attr "type" "ssemov")
> +   (set_attr "prefix_extra" "1")
> +   (set_attr "prefix" "evex")
> +   (set_attr "mode" "")])
> +
> +(define_insn "avx512dq_broadcast_1"
> +  [(set (match_operand:VI8F_256 0 "register_operand" "=v,v")
> +   (vec_duplicate:VI8F_256
> + (match_operand:<64x2mode> 1 "nonimmediate_operand" "v,m")))]
> +  "TARGET_AVX512DQ && TARGET_AVX512VL"
> +  "@
> +   vshuf64x2\t{$0x0, %t1, %t1, 
> %0|%0, %t1, %t1, 0x0}
> +   vbroadcast64x2\t{%1, %0|%0, 
> %1}"
> +  [(set_attr "type" "ssemov")
> +   (set_attr "prefix_extra" "1")
> +   (set_attr "prefix" "evex")
> +   (set_attr "mode" "")])

Please merge the above two patterns. Please introduce VI8F_BRCST64x2
in the same way as for broadcast32x2. Using TARGET_AVX512VL condition
in the mode constraint and TARGET_AVX512DQ as the baseline insn
constraint, you will also simplify insn constraint.

OK with this change.

Thanks,
Uros.


Re: [PATCH i386 AVX512] [20/n] AVX-512 integer shift pattern.

2014-08-20 Thread Kirill Yukhin
Hello,
On 15 Aug 20:35, Uros Bizjak wrote:
> On Fri, Aug 15, 2014 at 1:56 PM, Kirill Yukhin  
> wrote:
> Again, please split insn pattern to avoid:
> 
> +  "TARGET_SSE2
> +   && 
> +   && ((mode != V16HImode && mode != V8HImode)
> +   || TARGET_AVX512BW
> +   || !)"
> 
> insn constraints. The insn constraint should use baseline TARGET_* and
> mode iterator should use TARGET_* that results in "baseline TARGET_ &&
> iterator TARGET_" for certain mode. If these are properly used, then
> there is no need to use mode checks in the insn constraint.
I've refactored the pattern. But it should be mentioned,
that it still uses mode checkes implicitly.
Problem is that masking allowed either for ZMM or (XMM|YMM)+TARGET_AVX512VL,
supposing that TARGET_AVX512F is on for both cases.
That is what "mask_mode512bit_condition" check:
  (define_subst_attr "mask_mode512bit_condition" "mask" "1" "( == 64 
|| TARGET_AVX512VL)")

So, this pattern:
(define_insn "3"
  [(set (match_operand:VI2_AVX2_AVX512BW 0 "register_operand" "=x,v")
(any_lshift:VI2_AVX2_AVX512BW
  (match_operand:VI2_AVX2_AVX512BW 1 "register_operand" "0,v")
  (match_operand:SI 2 "nonmemory_operand" "xN,vN")))]
  "TARGET_SSE2 &&  && "

is expanded to (16hi, mask, ashift):
(define_insn ("ashlv16hi3_mask")
 [
(set (match_operand:V16HI 0 ("register_operand") ("=x,v"))
(vec_merge:V16HI (ashift:V16HI (match_operand:V16HI 1 
("register_operand") ("0,v"))
(match_operand:SI 2 ("nonmemory_operand") ("xN,vN")))
(match_operand:V16HI 3 ("vector_move_operand") ("0C,0C"))
(match_operand:HI 4 ("register_operand") ("Yk,Yk"
] ("(TARGET_AVX512F) && ((TARGET_SSE2 && (32 == 64 || TARGET_AVX512VL) && 
TARGET_AVX512BW) && (TARGET_AVX2))") 

(TARGET_AVX512F) came from `mask' subst, (32 == 64 || TARGET_AVX512VL) is what
I've described above, (TARGET_AVX512BW) came from coresponding subst attr and
TARGET_AVX2 belongs to mode iterator.

Bootstrapped and avx512-regtested.

gcc/
* config/i386/sse.md
(define_mode_iterator VI248_AVX2): Delete.
(define_mode_iterator VI2_AVX2_AVX512BW): New.
(define_mode_iterator VI48_AVX2): Ditto.
(define_insn ""3"): Add masking.
Split into two similar patterns, which use different mode
iterators: VI2_AVX2_AVX512BW and VI48_AVX2.
* config/i386/subst.md (define_subst_attr "mask_avx512bw_condition"):
New.

--
Thanks, K

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 6a5faee..5b1e5c1 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -347,9 +347,11 @@
(V16HI "TARGET_AVX2") V8HI
(V8SI "TARGET_AVX2") V4SI])
 
-(define_mode_iterator VI248_AVX2
-  [(V16HI "TARGET_AVX2") V8HI
-   (V8SI "TARGET_AVX2") V4SI
+(define_mode_iterator VI2_AVX2_AVX512BW
+  [(V32HI "TARGET_AVX512BW") (V16HI "TARGET_AVX2") V8HI])
+
+(define_mode_iterator VI48_AVX2
+  [(V8SI "TARGET_AVX2") V4SI
(V4DI "TARGET_AVX2") V2DI])
 
 (define_mode_iterator VI248_AVX2_8_AVX512F
@@ -8585,15 +8587,34 @@
(const_string "0")))
(set_attr "mode" "")])
 
-(define_insn "3"
-  [(set (match_operand:VI248_AVX2 0 "register_operand" "=x,x")
-   (any_lshift:VI248_AVX2
- (match_operand:VI248_AVX2 1 "register_operand" "0,x")
- (match_operand:SI 2 "nonmemory_operand" "xN,xN")))]
-  "TARGET_SSE2"
+(define_insn "3"
+  [(set (match_operand:VI2_AVX2_AVX512BW 0 "register_operand" "=x,v")
+   (any_lshift:VI2_AVX2_AVX512BW
+ (match_operand:VI2_AVX2_AVX512BW 1 "register_operand" "0,v")
+ (match_operand:SI 2 "nonmemory_operand" "xN,vN")))]
+  "TARGET_SSE2 &&  && "
+  "@
+   p\t{%2, %0|%0, %2}
+   vp\t{%2, %1, %0|%0, 
%1, %2}"
+  [(set_attr "isa" "noavx,avx")
+   (set_attr "type" "sseishft")
+   (set (attr "length_immediate")
+ (if_then_else (match_operand 2 "const_int_operand")
+   (const_string "1")
+   (const_string "0")))
+   (set_attr "prefix_data16" "1,*")
+   (set_attr "prefix" "orig,vex")
+   (set_attr "mode" "")])
+
+(define_insn "3"
+  [(set (match_operand:VI48_AVX2 0 "register_operand" "=x,v")
+   (any_lshift:VI48_AVX2
+ (match_operand:VI48_AVX2 1 "register_operand" "0,v")
+ (match_operand:SI 2 "nonmemory_operand" "xN,vN")))]
+  "TARGET_SSE2 && "
   "@
p\t{%2, %0|%0, %2}
-   vp\t{%2, %1, %0|%0, %1, %2}"
+   vp\t{%2, %1, %0|%0, 
%1, %2}"
   [(set_attr "isa" "noavx,avx")
(set_attr "type" "sseishft")
(set (attr "length_immediate")
diff --git a/gcc/config/i386/subst.md b/gcc/config/i386/subst.md
index edb0965..b05cb17 100644
--- a/gcc/config/i386/subst.md
+++ b/gcc/config/i386/subst.md
@@ -56,6 +56,7 @@
 (define_subst_attr "mask_operand_arg34" "mask" "" ", operands[3], operands[4]")
 (define_subst_attr "mask_mode512bit_condition" "mask" "1" "( == 64 
|| TARGET_AVX512VL)")
 (define_subst_attr "mask_avx512vl_condition" "mask" "1" "TARGET_AVX512VL")
+(define_subst_attr "mask_avx512bw_condition" "mask" "1

Re: [PATCH i386 AVX512] [19/n] Extends AVX-512 broadcasts.

2014-08-20 Thread Kirill Yukhin
Hello Uroš,
On 15 Aug 20:29, Uros Bizjak wrote:
> Can you avoid insn constraints like:
> 
> > +  "TARGET_AVX512DQ && ( == 64 || TARGET_AVX512VL)"
> 
> This should be split to two insn patterns, each with different
> baseline insn constraint.

I've splitted pattern into two similar w/ different mode iterators.

Bootstrapped and avx512-regtested.

Is it ok for trunk?

gcc/
* config/i386/sse.md
(define_mode_iterator VI4F_BRCST32x2): New.
(define_mode_attr 64x2mode): Ditto.
(define_mode_attr 32x2mode): Ditto.
(define_insn "avx512dq_broadcast"
with VI4F_BRCST32x2 mode iterator): Ditto.
(define_insn "avx512vl_broadcast_1"): 
Ditto.
(define_insn "avx512dq_broadcast_1"
with V16FI mode iterator): Ditto.
(define_insn "avx512dq_broadcast_1"
with VI8F_512 mode iterator): Ditto.
(define_insn "avx512dq_broadcast_1"
with VI8F_256 mode iterator): Ditto.
--
Thanks, K

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 4632b3a..6a5faee 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -482,6 +482,7 @@
 (define_mode_iterator VI8F_128 [V2DI V2DF])
 (define_mode_iterator VI4F_256 [V8SI V8SF])
 (define_mode_iterator VI8F_256 [V4DI V4DF])
+(define_mode_iterator VI8F_512 [V8DI V8DF])
 (define_mode_iterator VI8F_256_512
   [V4DI V4DF (V8DI "TARGET_AVX512F") (V8DF "TARGET_AVX512F")])
 (define_mode_iterator VI48F_256_512
@@ -14514,6 +14515,83 @@
(set_attr "prefix" "vex")
(set_attr "mode" "")])
 
+;; For broadcast[i|f]32x2.  Yes there is no v4sf version, only v4si.
+(define_mode_iterator VI4F_BRCST32x2
+  [V16SI (V8SI "TARGET_AVX512VL") (V4SI "TARGET_AVX512VL")
+   V16SF (V8SF "TARGET_AVX512VL")])
+
+(define_mode_attr 64x2mode
+  [(V8DF "V2DF") (V8DI "V2DI") (V4DI "V2DI") (V4DF "V2DF")])
+
+(define_mode_attr 32x2mode
+  [(V16SF "V2SF") (V16SI "V2SI") (V8SI "V2SI")
+  (V8SF "V2SF") (V4SI "V2SI")])
+
+(define_insn "avx512dq_broadcast"
+  [(set (match_operand:VI4F_BRCST32x2 0 "register_operand" "=v")
+   (vec_duplicate:VI4F_BRCST32x2
+ (vec_select:<32x2mode>
+   (match_operand: 1 "nonimmediate_operand" "vm")
+   (parallel [(const_int 0) (const_int 1)]]
+  "TARGET_AVX512DQ"
+  "vbroadcast32x2\t{%1, %0|%0, %1}"
+  [(set_attr "type" "ssemov")
+   (set_attr "prefix_extra" "1")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "")])
+
+(define_insn "avx512vl_broadcast_1"
+  [(set (match_operand:VI4F_256 0 "register_operand" "=v,v")
+(vec_duplicate:VI4F_256
+ (match_operand: 1 "nonimmediate_operand" "v,m")))]
+  "TARGET_AVX512VL"
+  "@
+   vshuf32x4\t{$0x0, %t1, %t1, 
%0|%0, %t1, %t1, 0x0}
+   vbroadcast32x4\t{%1, %0|%0, %1}"
+  [(set_attr "type" "ssemov")
+   (set_attr "prefix_extra" "1")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "")])
+
+(define_insn "avx512dq_broadcast_1"
+  [(set (match_operand:V16FI 0 "register_operand" "=v,v")
+   (vec_duplicate:V16FI
+ (match_operand: 1 "nonimmediate_operand" "v,m")))]
+  "TARGET_AVX512DQ"
+  "@
+   vshuf32x4\t{$0x44, %g1, %g1, 
%0|%0, %g1, %g1, 0x44}
+   vbroadcast32x8\t{%1, %0|%0, %1}"
+  [(set_attr "type" "ssemov")
+   (set_attr "prefix_extra" "1")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "")])
+
+(define_insn "avx512dq_broadcast_1"
+  [(set (match_operand:VI8F_512 0 "register_operand" "=v,v")
+   (vec_duplicate:VI8F_512
+ (match_operand:<64x2mode> 1 "nonimmediate_operand" "v,m")))]
+  "TARGET_AVX512DQ"
+  "@
+   vshuf64x2\t{$0x0, %g1, %g1, 
%0|%0, %g1, %g1, 0x0}
+   vbroadcast64x2\t{%1, %0|%0, %1}"
+  [(set_attr "type" "ssemov")
+   (set_attr "prefix_extra" "1")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "")])
+
+(define_insn "avx512dq_broadcast_1"
+  [(set (match_operand:VI8F_256 0 "register_operand" "=v,v")
+   (vec_duplicate:VI8F_256
+ (match_operand:<64x2mode> 1 "nonimmediate_operand" "v,m")))]
+  "TARGET_AVX512DQ && TARGET_AVX512VL"
+  "@
+   vshuf64x2\t{$0x0, %t1, %t1, 
%0|%0, %t1, %t1, 0x0}
+   vbroadcast64x2\t{%1, %0|%0, %1}"
+  [(set_attr "type" "ssemov")
+   (set_attr "prefix_extra" "1")
+   (set_attr "prefix" "evex")
+   (set_attr "mode" "")])
+
 (define_insn "avx512cd_maskb_vec_dup"
   [(set (match_operand:VI8_AVX512VL 0 "register_operand" "=v")
(vec_duplicate:VI8_AVX512VL


Re: [ping*2] fix build failure of x86_64-mingw32, missing crtbegin/crtend.o

2014-08-20 Thread Olivier Hainque
Hello,

Ping #2 for https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00237.html

Thanks in advance for your feedback,

With Kind Regards,

Olivier


On Jul 3, 2014, at 16:57 , Olivier Hainque  wrote:
> From gcc/i386/config/mingw32.h, STARTFILE_SPEC and ENDFILE_SPEC include
> crtbegin.o and crtend.o unconditionally.
> 
> libgcc/config.host includes crtbegin.o and crtend.o in extra_parts for
> i[34567]86-*-mingw* but not for x86_64-*-mingw*.
> 
> Building a toolchain for x86_64-pc-mingw32 then rapidly fails with complaints
> about crtbegin.o and crtend.o missing.
> 
> This patch is a proposal to fix this by adding the objects to extra_parts,
> as well as i386/t-cygming to tmake_file so rules are available to build the
> objects.
> 
> Tested by verifying that a build with --target=x86_64-pc-mingw32
> proceeds to completion after the change.
> 
> OK to commit ?
> 
> Thanks in advance for your feedback,
> 
> With Kind Regards,
> 
> Olivier
> 
> 2014-07-02  Olivier Hainque  
> 
> libgcc/
>   * config.host (x86_64-*-mingw*): Add i386/t-cygming to tmake_file
>   and crtbegin.o + crtend.o to extra_parts.
> 
> 




[PATCH][match-and-simplify] Change inner if-parsing

2014-08-20 Thread Richard Biener

This changes inner ifs to have a result operand and to allow
a simplify pattern to have multiple such ifs, thus:

(simplify
   (match-expression...)
   (if (cond1)
   result1)
   (if (cond2)
   result2)
   ...
   resultdefault)

I'm not sure a default makes sense when a previous if failed
(the first taken result always wins), but maybe it's useful
to catch special-cases that simplify differently.

What's not yet implemented is nesting those ifs to factor
out common checks (useful for the sofar single pattern in
match-comparison.pd).  I'll get to that now.

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

Richard.

2014-08-20  Richard Biener  

* genmatch.c (parse_simplify): Change inner if parsing, allow
multiple ifs.
(parse_pattern): Adjust.
* match.pd: Adjust inner ifs.
* match-builtin.pd: Likewise.
* match-comparison.pd: Likewise.
* match-constant-folding.pd: Likewise.
* match-plusminus.pd: Likewise.
* match-rotate.pd: Likewise.

Index: match-and-simplify/gcc/genmatch.c
===
*** match-and-simplify.orig/gcc/genmatch.c  2014-08-20 14:32:10.826845091 
+0200
--- match-and-simplify/gcc/genmatch.c   2014-08-20 14:32:19.236844512 +0200
*** parse_op (cpp_reader *r)
*** 2227,2234 
   (simplify ""
   )  */
  
! static simplify *
! parse_simplify (cpp_reader *r, source_location match_location)
  {
const cpp_token *token = peek (r);
const char *id;
--- 2227,2235 
   (simplify ""
   )  */
  
! static void
! parse_simplify (cpp_reader *r, source_location match_location,
!   vec& simplifiers)
  {
const cpp_token *token = peek (r);
const char *id;
*** parse_simplify (cpp_reader *r, source_lo
*** 2248,2278 
  
token = peek (r);
  
!   if (token->type != CPP_OPEN_PAREN)
! return new simplify (id, match, match_location, parse_op (r), 
token->src_loc);
! 
!   eat_token (r, CPP_OPEN_PAREN);
! 
!   token = peek (r);
!   source_location result_loc = token->src_loc;
! 
!   // ( expr )
!   if (peek_ident (r, "if") == 0)
  {
!   operand *result = parse_expr (r);
eat_token (r, CPP_CLOSE_PAREN);
!   return new simplify (id, match, match_location, result, result_loc); 
  }
  
!   // (if c-expr)
!   eat_ident (r, "if");
!   operand *ifexpr = parse_c_expr (r, CPP_OPEN_PAREN);
!   eat_token (r, CPP_CLOSE_PAREN);
  
!   result_loc = peek (r)->src_loc;
!   simplify *s = new simplify (id, match, match_location, parse_op (r), 
result_loc);
!   s->ifexpr_vec.safe_push (ifexpr);
!   return s;
  }
  
  void parse_pattern (cpp_reader *, vec&);
--- 2249,2290 
  
token = peek (r);
  
!   operand *result = NULL;
!   source_location result_loc;
!   while (!result
!&& token->type == CPP_OPEN_PAREN)
  {
!   eat_token (r, CPP_OPEN_PAREN);
!   if (peek_ident (r, "if"))
!   {
! vec ifexprs = vNULL;
! eat_ident (r, "if");
! ifexprs.safe_push (parse_c_expr (r, CPP_OPEN_PAREN));
! /* ???  Support nested (if ...) here.  */
! token = peek (r);
! simplifiers.safe_push
! (new simplify (id, match, match_location, parse_op (r),
!token->src_loc, ifexprs));
!   }
!   else
!   {
! result_loc = token->src_loc;
! result = parse_expr (r);
!   }
eat_token (r, CPP_CLOSE_PAREN);
!   token = peek (r);
  }
  
!   if (!result
!   && token->type != CPP_CLOSE_PAREN)
! {
!   result_loc = token->src_loc;
!   result = parse_op (r);
! }
  
!   if (result)
! simplifiers.safe_push
!   (new simplify (id, match, match_location, result, result_loc));
  }
  
  void parse_pattern (cpp_reader *, vec&);
*** parse_pattern (cpp_reader *r, vecsrc_loc));
else if (strcmp (id, "for") == 0)
  parse_for (r, token->src_loc, simplifiers); 
else if (strcmp (id, "if") == 0)
--- 2385,2391 
const cpp_token *token = peek (r);
const char *id = get_ident (r);
if (strcmp (id, "simplify") == 0)
! parse_simplify (r, token->src_loc, simplifiers);
else if (strcmp (id, "for") == 0)
  parse_for (r, token->src_loc, simplifiers); 
else if (strcmp (id, "if") == 0)
Index: match-and-simplify/gcc/match-builtin.pd
===
*** match-and-simplify.orig/gcc/match-builtin.pd2014-08-20 
14:32:10.826845091 +0200
--- match-and-simplify/gcc/match-builtin.pd 2014-08-20 14:32:19.236844512 
+0200
*** along with GCC; see the file COPYING3.
*** 39,44 
/* This needs to be conditionalized on flag_unsafe_math_optimizations,
   but we keep it for now to exercise function re-optimization.
   It makes gcc.dg/pr43419.c FAIL execution though.  */
!   (if (REAL_VALUES_EQUAL (TREE_REAL_CST (@1), dconsthalf)))
!   (BUILT_I

Re: [PATCH] Add guality [p]type test.

2014-08-20 Thread Richard Biener
On Wed, Aug 20, 2014 at 2:19 PM, Mark Wielaard  wrote:
> On Wed, 2014-08-20 at 10:49 +0200, Richard Biener wrote:
>> On Tue, Aug 19, 2014 at 7:52 PM, Mark Wielaard  wrote:
>> > Filed as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62190 "LTO DWARF
>> > produces __unknown__ type for unsigned int function argument type".
>> >
>> > I included a smaller testcase in the bug that can just be dropped into
>> > gcc/testsuite/gcc.dg/guality/ to show the issue. Shall I just commit the
>> > change to the restrict.c testcase, so at least that one always PASSes
>> > for now?
>>
>> No need - I have a fix in testing.
>
> Thanks, that fix works for me. But I still need to mark the variables as
> used in the restrict.c test case to turn them from UNSUPPORTED to PASS
> with LTO.
>
> 2014-08-20  Mark Wielaard  
>
> * gcc.dg/guality/restrict.c: Add `used' attribute to all variables.
>
> OK to push?

Ok.

Thanks,
Richard.

> Thanks,
>
> Mark
>
> diff --git a/gcc/testsuite/gcc.dg/guality/restrict.c 
> b/gcc/testsuite/gcc.dg/guality/restrict.c
> index e31224b..62d7832 100644
> --- a/gcc/testsuite/gcc.dg/guality/restrict.c
> +++ b/gcc/testsuite/gcc.dg/guality/restrict.c
> @@ -2,16 +2,16 @@
>  /* { dg-do run } */
>  /* { dg-options "-std=c99 -gdwarf-3" } */
>
> -int *ip;
> -const int *cip;
> -int * restrict irp;
> -int * const icp;
> -const int * restrict cirp;
> -int * const restrict icrp;
> -const int * const restrict cicrp;
> -
> -int * const volatile restrict cvirp;
> -const volatile int * restrict pcvir;
> +int *ip __attribute__((used));
> +const int *cip __attribute__((used));
> +int * restrict irp __attribute__((used));
> +int * const icp __attribute__((used));
> +const int * restrict cirp __attribute__((used));
> +int * const restrict icrp __attribute__((used));
> +const int * const restrict cicrp __attribute__((used));
> +
> +int * const volatile restrict cvirp __attribute__((used));
> +const volatile int * restrict pcvir __attribute__((used));
>
>  static __attribute__((noclone, noinline)) void *
>  cpy (void * restrict s1, const void * restrict s2, unsigned int n)
>


Re: [PATCH] Add guality [p]type test.

2014-08-20 Thread Mark Wielaard
On Wed, 2014-08-20 at 10:49 +0200, Richard Biener wrote:
> On Tue, Aug 19, 2014 at 7:52 PM, Mark Wielaard  wrote:
> > Filed as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62190 "LTO DWARF
> > produces __unknown__ type for unsigned int function argument type".
> >
> > I included a smaller testcase in the bug that can just be dropped into
> > gcc/testsuite/gcc.dg/guality/ to show the issue. Shall I just commit the
> > change to the restrict.c testcase, so at least that one always PASSes
> > for now?
> 
> No need - I have a fix in testing.

Thanks, that fix works for me. But I still need to mark the variables as
used in the restrict.c test case to turn them from UNSUPPORTED to PASS
with LTO.

2014-08-20  Mark Wielaard  

* gcc.dg/guality/restrict.c: Add `used' attribute to all variables.

OK to push?

Thanks,

Mark

diff --git a/gcc/testsuite/gcc.dg/guality/restrict.c 
b/gcc/testsuite/gcc.dg/guality/restrict.c
index e31224b..62d7832 100644
--- a/gcc/testsuite/gcc.dg/guality/restrict.c
+++ b/gcc/testsuite/gcc.dg/guality/restrict.c
@@ -2,16 +2,16 @@
 /* { dg-do run } */
 /* { dg-options "-std=c99 -gdwarf-3" } */
 
-int *ip;
-const int *cip;
-int * restrict irp;
-int * const icp;
-const int * restrict cirp;
-int * const restrict icrp;
-const int * const restrict cicrp;
-
-int * const volatile restrict cvirp;
-const volatile int * restrict pcvir;
+int *ip __attribute__((used));
+const int *cip __attribute__((used));
+int * restrict irp __attribute__((used));
+int * const icp __attribute__((used));
+const int * restrict cirp __attribute__((used));
+int * const restrict icrp __attribute__((used));
+const int * const restrict cicrp __attribute__((used));
+
+int * const volatile restrict cvirp __attribute__((used));
+const volatile int * restrict pcvir __attribute__((used));
 
 static __attribute__((noclone, noinline)) void *
 cpy (void * restrict s1, const void * restrict s2, unsigned int n)



Re: [Patch] Remove arm-specific formats from asm_fprintf

2014-08-20 Thread Joseph S. Myers
On Wed, 20 Aug 2014, David Wohlferd wrote:

> Or have I completely missed your point?

Suppose you build a copy of GCC, call it GCCA, and use it to compile a 
program P, with -Wformat enabled.  The following must hold:

* If P is not GCC, asm_fprintf formats are not accepted at all by GCCA 
when compiling P.

* If P is a copy of GCC (the same version as GCCA), say GCCB, configured 
for ARM target, then the formats that are used with asm_fprintf in such a 
copy of GCC must be accepted.  It is necessary that builds for all (host, 
target) combinations are clean, as long as the version of GCC used for the 
build is the same as the version of GCC being built, so that cross builds 
with --enable-werror-always can be used detect build problems that would 
show up in a native bootstrap.  If the build for some hosts is not clean, 
this breaks the use of --enable-werror-always for continuous integration.

* If P is a copy of GCC (the same version as GCCA), say GCCB, configured 
for some other target, then the formats that are used with asm_fprintf in 
such a copy of GCC must be accepted - but whether the ARM-GCC-specific 
formats are accepted doesn't matter *as long as that doesn't depend on how 
GCCA was configured*.  You can have GCC always accept them (as at 
present).  Or you can arrange things so that GCCA detects whether P is 
GCCB (ARM target) or GCCB (some other target) and so controls the set of 
supported asm_fprintf formats accordingly.  But having the accepted set 
depend on how GCCA was configured would adversely affect the usefulness of 
--enable-werror-always to detect build failures that would occur in a 
bootstrap without breaking in other cases.

What's not acceptable and represents a fundamental confusion of the 
different platforms inherently involved in a compiler is what the patch 
would introduce, which is the set of formats accepted depending on the 
target of GCCA (= host of GCCB); any such platform-dependence must be on 
the target of GCCB, not the host of GCCB.  That means this cannot be 
determined based on how GCCA is configured; instead, GCCA must obtain the 
information in some way at runtime from the source code of P, just as P 
can already communicate back to GCCA the argument types accepted by 
various of the GCC-specific formats.

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [Patch AArch64] Fix for PR62040

2014-08-20 Thread Kyrill Tkachov

Hi Carrot,

cc'ing the aarch64 maintainers...

On 20/08/14 00:43, Carrot Wei wrote:

Hi

Current AArch64 backend can generate rtl expressions like
(vec_duplicate:DI (const_int 0 [0])), which causes ICE in
simplify_const_unary_operation because vec_duplicate should generate
vector mode only.

As suggested by Andrew in the bug entry, I split the original insn
patterns to avoid scalar mode vec_duplicate expression.


The documentation does say that vec_concat can work on scalars, so it 
seems ok to me at a glance (but I can't approve it myself).


Would be nice to have an addition to the testsuite though...

Kyrill


Passed regression tests on qemu without failure.
OK for trunk and 4.9 branch?

thanks
Guozhi Wei

2014-08-19  Guozhi Wei  

 PR target/62040
 * config/aarch64/iterators.md (VQ_NO2E, VQ_2E): New iterators.
 * config/aarch64/aarch64-simd.md (move_lo_quad_internal_): Split
 it into two patterns.
 (move_lo_quad_internal_be_): Likewise.





[PATCH][match-and-simplify] Refactor GIMPLE code-gen

2014-08-20 Thread Richard Biener

This refactors GIMPLE code-gen to use switch ()es similar to
the GENERIC version.  This should provide all of the
backtracking avoidance we need (I think so at least).

Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu.

Richard.

2014-08-20  Richard Biener  

* genmatch.c (dt_node::get_expr_code, dt_node::is_gimple_expr,
dt_node::is_gimple_fn): Remove.
(dt_operand::kids_type, dt_operand::gtok_kids,
dt_operand::gen_generic_expr_expr, dt_operand::gen_generic_expr_fn):
Likewise.
(dt_operand::gen_gimple_expr_expr, dt_operand::gen_gimple_expr_fn):
Merge into ...
(dt_operand::gen_gimple_expr): ... this new function.
(is_a_helper): More specializations.
(expr::gen_transform): Add missing newline.
(dt_operand::gen_gimple_kids): Rewrite to use switch statements.
(dt_operand::gen_generic_expr): Adjust.
(dt_operand::gen_gimple): Likewise.

Index: gcc/genmatch.c
===
*** gcc/genmatch.c.orig 2014-08-19 16:50:02.426224137 +0200
--- gcc/genmatch.c  2014-08-20 12:55:55.647242705 +0200
*** struct dt_node
*** 414,423 
  
virtual void gen_gimple (FILE *) {}
virtual void gen_generic (FILE *) {}
-   
-   bool get_expr_code (enum tree_code&);
-   bool is_gimple_expr ();
-   bool is_gimple_fn ();
  };
  
  struct dt_operand: public dt_node
--- 414,419 
*** struct dt_operand: public dt_node
*** 426,460 
dt_operand *match_dop;
dt_operand *parent;
unsigned pos;
- 
-   struct kids_type {
- vec gimple_exprs;
- vec fns;
- vec others;
- dt_node *true_operand;
-   
- kids_type (): gimple_exprs (vNULL), fns (vNULL), others (vNULL), 
true_operand (0) {}
-   };
   
dt_operand (enum dt_type type, operand *op_, dt_operand *match_dop_, 
dt_operand *parent_ = 0, unsigned pos_ = 0)
!   : dt_node (type), op (op_), match_dop (match_dop_), parent (parent_), 
pos (pos_) {} 
  
virtual void gen_gimple (FILE *);
virtual void gen_generic (FILE *);
unsigned gen_predicate (FILE *, const char *);
unsigned gen_match_op (FILE *, const char *);
  
!   unsigned gen_gimple_expr_expr (FILE *); 
!   unsigned gen_gimple_expr_fn (FILE *);
! 
!   unsigned gen_generic_expr (FILE *, const char *, bool);
!   void gen_generic_expr_expr (FILE *, expr *, const char *, bool);
!   void gen_generic_expr_fn (FILE *, expr *, const char *, bool);
  
char *get_name (char *);
void gen_opname (char *, unsigned);
  
-   void grok_kids(kids_type&);
void gen_gimple_kids (FILE *);
void gen_generic_kids (FILE *);
  };
--- 422,442 
dt_operand *match_dop;
dt_operand *parent;
unsigned pos;
   
dt_operand (enum dt_type type, operand *op_, dt_operand *match_dop_, 
dt_operand *parent_ = 0, unsigned pos_ = 0)
!   : dt_node (type), op (op_), match_dop (match_dop_), parent (parent_), 
pos (pos_) {}
  
virtual void gen_gimple (FILE *);
virtual void gen_generic (FILE *);
unsigned gen_predicate (FILE *, const char *);
unsigned gen_match_op (FILE *, const char *);
  
!   unsigned gen_gimple_expr (FILE *);
!   unsigned gen_generic_expr (FILE *, const char *);
  
char *get_name (char *);
void gen_opname (char *, unsigned);
  
void gen_gimple_kids (FILE *);
void gen_generic_kids (FILE *);
  };
*** struct dt_simplify: public dt_node
*** 479,484 
--- 461,474 
virtual void gen_generic (FILE *f);
  };
  
+ template<>
+ template<>
+ inline bool
+ is_a_helper ::test (dt_node *n)
+ {
+   return n->type == dt_node::DT_OPERAND;
+ }
+ 
  struct decision_tree
  {
dt_node *root;
*** expr::gen_transform (FILE *f, const char
*** 913,919 
fprintf (f, ");\n");
  }
fprintf (f, "  %s = res;\n", dest);
!   fprintf (f, "}");
  }
  
  void
--- 903,909 
fprintf (f, ");\n");
  }
fprintf (f, "  %s = res;\n", dest);
!   fprintf (f, "}\n");
  }
  
  void
*** dt_operand::gen_match_op (FILE *f, const
*** 1292,1540 
  }
  
  unsigned
! dt_operand::gen_gimple_expr_fn (FILE *f) 
  {
expr *e = static_cast (op);
unsigned n_ops = e->ops.length ();
  
-   fn_id *op = static_cast  (e->operation->op);
-   fprintf (f, "if (gimple_call_builtin_p (def_stmt, %s))\n", op->id);
-   fprintf (f, "{\n");
- 
for (unsigned i = 0; i < n_ops; ++i)
  {
char child_opname[20];
gen_opname (child_opname, i); 
  
!   fprintf (f, "tree %s = gimple_call_arg (def_stmt, %u);\n", 
child_opname, i);
!   fprintf (f, "if ((%s = do_valueize (valueize, %s)) != 0)\n", 
child_opname, child_opname);
fprintf (f, "{\n");
! } 
  
!   return n_ops + 1;
  }
  
  unsigned
! dt_operand::gen_gimple_expr_expr (FILE *f)
  {
expr *e = static_cast (op);
-   unsigned n_ops = e->ops.length (); 
- 
-   operator_id *op_id = static_cast  (e->operation->op);
-   
-   if (op_id->code == NOP

[PATCH] Fix PR62190

2014-08-20 Thread Richard Biener

The C frontend commonizes uint{16,32,64}_type_node with existing
integer type nodes and thus gets proper "names" for them.  The
LTO frontend (and tree.c common code) keeps them separate
and thus debugs as __unknown__.  The following patch arranges
the common code in build_common_tree_nodes to use
make_or_reuse_type for those.

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

Richard.

2014-08-20  Richard Biener  

PR lto/62190
* tree.c (build_common_tree_nodes): Use make_or_reuse_type
to build uint{16,32,64}_type_node.

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 214212)
+++ gcc/tree.c  (working copy)
@@ -9698,9 +9698,9 @@ build_common_tree_nodes (bool signed_cha
   integer_ptr_type_node = build_pointer_type (integer_type_node);
 
   /* Fixed size integer types.  */
-  uint16_type_node = build_nonstandard_integer_type (16, true);
-  uint32_type_node = build_nonstandard_integer_type (32, true);
-  uint64_type_node = build_nonstandard_integer_type (64, true);
+  uint16_type_node = make_or_reuse_type (16, 1);
+  uint32_type_node = make_or_reuse_type (32, 1);
+  uint64_type_node = make_or_reuse_type (64, 1);
 
   /* Decimal float types. */
   dfloat32_type_node = make_node (REAL_TYPE);


Re: [PATCH v3] Add strict aliasing warning when inlining function.

2014-08-20 Thread lin zuojian
Hi,
And I have run test like this:
 make check-g++ RUNTESTFLAGS="dg.exp"
And turned out there are 3 more unexpected failures like
g++.dg/opt/pmf1.C
/home/linzj/src/build-gcc/gcc-trunk/gcc/testsuite/g++.dg/opt/pmf1.C: In 
function ‘int main()’:
/home/linzj/src/build-gcc/gcc-trunk/gcc/testsuite/g++.dg/opt/pmf1.C:72:42: 
warning: dereferencing type-punned pointer will break strict-aliasing rules 
[-Wstrict-aliasing]
 t.forward(itemfunptr, &Item::fred, 1);
  ^
/home/linzj/src/build-gcc/gcc-trunk/gcc/testsuite/g++.dg/opt/pmf1.C:72:42: 
warning: during inlining function void WorldObject::forward(memfunT, 
arg1T, arg2T) [with memfunT = void (Container::*)(void (Item::*)(int), int); 
arg1T = void (Item::*)(int); arg2T = int; Derived = Container] into function 
int main() [-Wstrict-aliasing]
FAIL: g++.dg/opt/pmf1.C  -std=gnu++98 (test for excess errors)
PASS: g++.dg/opt/pmf1.C  -std=gnu++98 execution test
FAIL: g++.dg/opt/pmf1.C  -std=gnu++11 (test for excess errors)
PASS: g++.dg/opt/pmf1.C  -std=gnu++11 execution test
FAIL: g++.dg/opt/pmf1.C  -std=gnu++1y (test for excess errors) 

I think it's okay to fix this test. And commit my code.
---
Lin Zuojian



[PATCH, g++, testsuite] Skip thread_local6.C on target using wrapper

2014-08-20 Thread Tony Wang
Hi there,

It's a very simple test case modification to fix the test case failure on ARM 
bare metal target.
thread_local6.C is a test case to test the behavior of the deconstruct of a 
thread local variable, and it just
use _exit(0) to override the return 1(calling exit(1)). However, such a 
behavior can't be detected on embedded
target with dejagnu wrapper mechanism, because the wrapper will only output the 
return value in exit() instead
of _exit(). There're some similar test cases(g++.dg/init/ref15.C) already 
avoided to test on the target using
wrapper, so this patch just follow their pattern to avoid the test case on 
target using wrapper.

gcc/gcc/testsuite/ChangeLog:
2014-08-20  Tony Wang  

* g++.dg/tls/thread_local6.C: Skip this test case when
target uses dejagnu wrapper.

diff --git a/gcc/testsuite/g++.dg/tls/thread_local6.C 
b/gcc/testsuite/g++.dg/tls/thread_local6.C
index 
378cf3d58c7bcbebb224137b353301f75b420d5a..6cf820e0e9a181e403aa2c0ebaa822ab7b6f7aab
 100644
--- a/gcc/testsuite/g++.dg/tls/thread_local6.C
+++ b/gcc/testsuite/g++.dg/tls/thread_local6.C
@@ -1,6 +1,6 @@
 // Test for cleanups in the main thread without -pthread.
 
-// { dg-do run { target c++11 } }
+// { dg-do run { target { c++11 && unwrapped } } }
 // { dg-add-options tls }
 // { dg-require-effective-target tls_runtime }




Re: [PATCH 035/236] Return types of unlink_insn_chain and duplicate_insn_chain

2014-08-20 Thread David Malcolm
On Wed, 2014-08-20 at 10:20 +0200, Andreas Schwab wrote:
> David Malcolm  writes:
> 
> > @@ -4083,7 +4083,7 @@ cfg_layout_can_duplicate_bb_p (const_basic_block bb)
> >return true;
> >  }
> >  
> > -rtx
> > +rtx_insn *
> >  duplicate_insn_chain (rtx from, rtx to)
> >  {
> >rtx insn, next, copy;
> > @@ -4169,7 +4169,7 @@ duplicate_insn_chain (rtx from, rtx to)
> >  }
> >insn = NEXT_INSN (last);
> >delete_insn (last);
> > -  return insn;
> > +  return as_a  (insn);
> 
> This is wrong, insn may be NULL.

Thanks; and indeed, this broke the bootstrap, as noted in:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01964.html

Fixed in r214207:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01971.html


Sorry.  I'm trying to figure out why this didn't break during my
testing.  Patch #60 of the original series contained an equivalent as_a
-> as_a_nullable hunk:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00708.html
- albeit with a misleading ChangeLog entry (I'm assuming I messed that
up during a rebase) - but this hadn't been applied yet.


Dave



Re: [PATCH] Relax check against commuting XOR and ASHIFTRT in combine.c

2014-08-20 Thread Alan Lawrence

Thanks to Arnaud for confirming that Adacore does not have interest in the
Ada/Alpha combination 
(https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01832.html).

As per below, I've tested check-ada on x86_64-none-linux-gnu without problems.
Can I say, "ping"?  :)

Cheers, Alan



Alan Lawrence wrote:
Ok, the attached tests are passing on x86_64-none-linux-gnu, aarch64-none-elf, 
arm-none-eabi, and a bunch of smaller platforms for which I've only built a 
stage 1 compiler (i.e. as far as necessary to assemble). That's with either 
change to simplify_shift_const_1.


As to the addition of "result_mode != shift_mode", or removing the whole check 
against XOR - I've now tested the latter:


bootstrapped on x86_64-none-linux-gnu, check-gcc and check-ada;
bootstrapped on arm-none-linux-gnueabihf;
bootstrapped on aarch64-none-linux-gnu;
cross-tested check-gcc on aarch64-none-elf;
cross-tested on arm-none-eabi;
(and Uros has bootstrapped on alpha and done a suite of tests, as per 
https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg01236.html).


 From a perspective of paranoia, I'd lean towards adding "result_mode != 
shift_mode", but for neatness removing the whole check against XOR is nicer. So 
I'd defer to the maintainers as to whether one might be preferable to the 
other...(but my unproven suspicion is that the two are equivalent, and no case 
where result_mode != shift_mode is possible!)


--Alan

Alan Lawrence wrote:
Thanks for the suggestions! I think I've got a reasonably platform-independent 
testcase that scans the rtl dump, just trying it on a few more platforms now...


As to running on Alpha: bootstrap succeeds, and the regression testsuite doesn't 
raise any issues (https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg01236.html) 
- and that's with a more aggressive patch that completely rolls back the 
original r76965:


Index: combine.c
===
--- combine.c   (revision 212523)
+++ combine.c   (working copy)
@@ -10218,9 +10218,6 @@
 if (CONST_INT_P (XEXP (varop, 1))
 /* We can't do this if we have (ashiftrt (xor))  and the
constant has its sign bit set in shift_mode.  */
- && !(code == ASHIFTRT && GET_CODE (varop) == XOR
-  && 0 > trunc_int_for_mode (INTVAL (XEXP (varop, 1)),
- shift_mode))
 && (new_rtx = simplify_const_binary_operation
 (code, result_mode,
  gen_int_mode (INTVAL (XEXP (varop, 1)), result_mode),
@@ -10237,10 +10234,7 @@
logical expression, make a new logical expression, and apply
the inverse distributive law.  This also can't be done
for some (ashiftrt (xor)).  */
- if (CONST_INT_P (XEXP (varop, 1))
-&& !(code == ASHIFTRT && GET_CODE (varop) == XOR
- && 0 > trunc_int_for_mode (INTVAL (XEXP (varop, 1)),
-shift_mode)))
+ if (CONST_INT_P (XEXP (varop, 1)))
   {
 rtx lhs = simplify_shift_const (NULL_RTX, code, shift_mode,
 XEXP (varop, 0), count);

I'm testing this version more widely but initial indications are good.

However, I've not succeeded in checking Ada on Alpha, as GCC's Ada frontend 
requires an Ada compiler to bootstrap. So I have to ask: does anyone actually 
use Ada on Alpha? (And if so, would they please be able to test the above patch?)


Moreover, I don't really see we have much reason to believe the check against 
commuting is required even for Ada/Alpha. GCC's internals have changed 
substantially in the interim, with the Ada frontend no longer generating RTL 
directly, as we now have intervening GENERIC/GIMPLE tree stages. Unless there is 
a logical/bitwise explanation for why the commuting of ashiftrc and xor is 
unsafe, is the best explanation that the Ada frontend was generating RTL that 
may have looked OK at the time but we would now consider dubious, malformed, bad?


(E.g., these days I don't see how to produce an ashiftrt of one mode containing
an XOR of another without an intervening sign_extend, zero_extend or subreg.)

--Alan

Jeff Law wrote:

On 06/30/14 13:05, Alan Lawrence wrote:

combine.c includes a check which prevents

(ashiftrt (xor A C2) C1)

from being commuted to

(xor (ashiftrt A C1) (ashiftrt C2 C1))

for constants C1, C2 if C2 has its sign bit set.

Specifically, this prevents (ashiftrt (not A) C1) from being commuted to

(not (ashiftrt A C1))

because the former is rewritten to (ashiftrt (xor A -1) C1) above, with
a comment /* Make this fit the case below.  */ - which it no longer does.

If result_mode == shift_mode, I can see no reason to prevent this
normalisation (indeed, I'm not sure I can see any reason to prevent it
even if result_mode != shift_mode - but I've not managed to produce such
a case in m

Re: [PATCH/PR c/59304] #pragma diagnostic pop after warning fails for options unspecified in the command-line and disabled by default

2014-08-20 Thread Dodji Seketeli
Hello Manuel,

Manuel López-Ibáñez  writes:

> The idea is that when we see a change of classification, and the
> option was originally unspecified, we record the command-line status.
> This way, when doing pop later, we already check if the option was
> reclassified so we get the command-line status. This also works with
> -Wall, since all dependent options go through set_option and call
> diagnostic_classify_diagnostic. But we have to call it before changing
> the option status.
>
> Bootstrapped and regression tested on x86_64-linux-gnu.
>
> OK?

Yes, this looks OK to me.

>
> gcc/ChangeLog:
>
> 2014-08-19  Manuel López-Ibáñez  
>
> PR c/59304
> * opts-common.c (set_option): Call diagnostic_classify_diagnostic
> before setting the option.
> * diagnostic.c (diagnostic_classify_diagnostic): Record
> command-line status.
>
> gcc/testsuite/ChangeLog:
>
> 2014-08-19  Manuel López-Ibáñez  
>
> PR c/59304
> * gcc.dg/pr59304.c: New test.

Thank you!


-- 
Dodji


Re: [PATCH][match-and-simplify] Fix comparison pattern

2014-08-20 Thread Marc Glisse

On Wed, 20 Aug 2014, Richard Biener wrote:


On Wed, 20 Aug 2014, Marc Glisse wrote:


On Wed, 20 Aug 2014, Richard Biener wrote:


Committed.

Also makes visible a desirable change I plan for if-exprs.  They
should behave like outer ifs and allow us to write that series
of pattern as

(for op in eq ne
 /* Simplify X * C1 CMP 0 to X CMP 0 if C1 is not zero.  */
 (simplify
   (op (mult @0 INTEGER_CST@1) integer_zerop@2)
   /* In fold-const.c we have this and the following patterns
  combined because there we can "compute" the operator
  to use by using swap_tree_comparison.  */
   (if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0)))
 (if (tree_int_cst_sgn (@1) > 0)
 (op @0 @2))
 (if (tree_int_cst_sgn (@1) < 0 && op == EQ_EXPR)
 (ne @0 @2))
 (if (tree_int_cst_sgn (@1) < 0 && op == NE_EXPR)
 (eq @0 @2)

that is, inner ifs have two operands, one condition and one
"result" (which can be another if).  And the simplify
now has one mandatory match operand and at least one
result operand (if which all but the last have to be an
'if').


Not related to how you do "if" and such, but this simplification doesn't make
sense. swap_tree_comparison preserves eq and ne, you only care that @1 is
non-zero. It is for comparisons like lt that the sign can change the
operation.


Oops, true (the fold_comparison code doesn't restrict itself to
eq and ne).  So for ne and eq the sign of @1 doesn't matter.
So we can improve here and do

/* Simplify X * C1 CMP 0 to X CMP 0 if C1 is not zero.  */
(for op in lt le eq ne ge gt
 (simplify
   (op (mult @0 INTEGER_CST@1) integer_zerop@2)
   /* In fold-const.c we have this and the following pattern
  combined because there we can "compute" the operator
  to use by using swap_tree_comparison.  Here we manage
  to use only two patterns by swapping the operands instead
  of changing the comparison code.  */
   (if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
&& tree_int_cst_sgn (@1) > 0))
   (op @0 @2))
 (simplify
   (op (mult @0 INTEGER_CST@1) integer_zerop@2)
   (if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
&& tree_int_cst_sgn (@1) < 0))
   (op @2 @0)))

right?


Yes, that looks fine.

(fold-const.c checks TREE_OVERFLOW(@1), I don't know about that)
(we are obviously losing the warning)

--
Marc Glisse


[PATCH][AArch64] Tidy: remove unused qualifier_const_pointer

2014-08-20 Thread Alan Lawrence

The only reference is in a comment.

gcc/ChangeLog:

* config/aarch64/aarch64-builtins.c (enum aarch64_type_qualifiers):
Remove qualifier_const_pointer, update comment.diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index 5217f4a5f39224dbf8029542ad33790ef2c191be..1683c59166ee3c9994511e2d6cd42d6baa09c74e 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -82,8 +82,6 @@ enum aarch64_type_qualifiers
   qualifier_const = 0x2, /* 1 << 1  */
   /* T *foo.  */
   qualifier_pointer = 0x4, /* 1 << 2  */
-  /* const T *foo.  */
-  qualifier_const_pointer = 0x6, /* qualifier_const | qualifier_pointer  */
   /* Used when expanding arguments if an operand could
  be an immediate.  */
   qualifier_immediate = 0x8, /* 1 << 3  */
@@ -98,7 +96,7 @@ enum aarch64_type_qualifiers
   qualifier_map_mode = 0x80, /* 1 << 7  */
   /* qualifier_pointer | qualifier_map_mode  */
   qualifier_pointer_map_mode = 0x84,
-  /* qualifier_const_pointer | qualifier_map_mode  */
+  /* qualifier_const | qualifier_pointer | qualifier_map_mode  */
   qualifier_const_pointer_map_mode = 0x86,
   /* Polynomial types.  */
   qualifier_poly = 0x100

[PATCH][AArch64] One-liner: fix type of an add in SIMD registers

2014-08-20 Thread Alan Lawrence
The SIMD-register variant is miscategorized as "alu_reg" despite not using any 
ALU registers, and should be "neon_add" for e.g. scheduling.


Tested with check-gcc and check-g++ on aarch64-none-elf and aarch64_be-none-elf.

gcc/ChangeLog:

* config/aarch64/aarch64.md (adddi3_aarch64): set type to neon_add.diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 3eb783c3681b16e1a5f780ec656bd261b9cb4954..f8eb305140e7b0aed006b33f1724a90939e48316 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -1198,7 +1198,7 @@
   add\\t%x0, %x1, %x2
   sub\\t%x0, %x1, #%n2
   add\\t%d0, %d1, %d2"
-  [(set_attr "type" "alu_imm,alu_reg,alu_imm,alu_reg")
+  [(set_attr "type" "alu_imm,alu_reg,alu_imm,neon_add")
(set_attr "simd" "*,*,*,yes")]
 )
 

Re: [Patch 1/2] Control SRA and IPA-SRA by a param rather than MOVE_RATIO

2014-08-20 Thread Richard Biener
On Wed, Aug 20, 2014 at 11:09 AM, James Greenhalgh
 wrote:
>
> Hi,
>
> Presently the decision as to whether to completely scalarize an aggregate
> or not is made based on MOVE_RATIO. This is an undocumented, and unexpected,
> overloading of the target macro.
>
> In this patch we fix this.
>
> First, we we add a new target hook
> TARGET_DEFAULT_MAX_TOTAL_SCALARIZATION_SIZE, which returns MOVE_RATIO
> by default.
>
> Then we add two new parameters:
>
>   sra-max-total-scalarization-size-Ospeed - The maximum size of aggregate
>   to consider when compiling for speed
>   sra-max-total-scalarization-size-Osize - The maximum size of aggregate
>   to consider when compiling for size.
>
> Set to default to 0.
>
> Finally we wire up SRA to prefer using the parameters, and if it doesn't
> find values for them, fallback to the target hook.
>
> Bootstrapped and regression tested for x86, arm and aarch64 with no
> issues, I've also thrown a smoke-test of popular small benchmarks at
> each platform without seeing meaningful differences (as you would expect).
>
> OK?

I think this is overly complicated and instead SRA should only
use the parameters.  Targets can adjust their default (like they
do for other parameters).

The default should be MOVE_RATIO which should be applied
where the common code adjusts parameters (see existing
examples for not overriding user specified ones).

Thanks,
Richard.

> Thanks,
> James
>
> ---
> gcc/
>
> 2014-08-20  James Greenhalgh  
>
> * doc/invoke.texi (sra-max-total-scalarization-size-Ospeed): Document.
> (sra-max-total-scalarization-size-Osize): Likewise.
> * doc/tm.texi.in
> (TARGET_DEFAULT_MAX_TOTAL_SCALARIZATION_SIZE): Add hook.
> * doc/tm.texi: Regenerate.
> * params.def (sra-max-total-scalarization-size-Ospeed): New.
> (sra-max-total-scalarization-size-Osize): Likewise.
> * target.def (default_max_total_scalarization_size): New.
> * targhooks.c (default_max_total_scalarization_size): New.
> * targhooks.h (default_max_total_scalarization_size): New.
> * tree-sra.c (get_max_total_scalarization_size): New.
> (analyze_all_variable_accesses): Use it.


[PATCH][AArch64] Remove varargs from aarch64_simd_expand_args

2014-08-20 Thread Alan Lawrence
This patch just replaces the varargs with a builtin_simd_arg*. The use of 
varargs seems to make stepping into, and breakpointing, aarch64_simd_expand_args 
difficult, and this adds typesafety and (I argue!) reduces complexity.


Tested check-gcc on aarch64-none-elf.

gcc/ChangeLog:

* config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args): Replace
varargs with pointer parameter.
(aarch64_simd_expand_builtin): pass pointer into previous.diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index fee17ecf637436c8704f565be2eb9ef23891209a..1af17900785685e4e005710d3bb1743d88a11c16 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -904,9 +904,8 @@ typedef enum
 
 static rtx
 aarch64_simd_expand_args (rtx target, int icode, int have_retval,
-			  tree exp, ...)
+			  tree exp, builtin_simd_arg *args)
 {
-  va_list ap;
   rtx pat;
   tree arg[SIMD_MAX_BUILTIN_ARGS];
   rtx op[SIMD_MAX_BUILTIN_ARGS];
@@ -920,11 +919,9 @@ aarch64_simd_expand_args (rtx target, int icode, int have_retval,
 	  || !(*insn_data[icode].operand[0].predicate) (target, tmode)))
 target = gen_reg_rtx (tmode);
 
-  va_start (ap, exp);
-
   for (;;)
 {
-  builtin_simd_arg thisarg = (builtin_simd_arg) va_arg (ap, int);
+  builtin_simd_arg thisarg = args[argc];
 
   if (thisarg == SIMD_ARG_STOP)
 	break;
@@ -960,8 +957,6 @@ aarch64_simd_expand_args (rtx target, int icode, int have_retval,
 	}
 }
 
-  va_end (ap);
-
   if (have_retval)
 switch (argc)
   {
@@ -1075,12 +1070,7 @@ aarch64_simd_expand_builtin (int fcode, tree exp, rtx target)
   /* The interface to aarch64_simd_expand_args expects a 0 if
  the function is void, and a 1 if it is not.  */
   return aarch64_simd_expand_args
-	  (target, icode, !is_void, exp,
-	   args[1],
-	   args[2],
-	   args[3],
-	   args[4],
-	   SIMD_ARG_STOP);
+	  (target, icode, !is_void, exp, &args[1]);
 }
 
 rtx

[Patch AArch64 2/2] Wire up TARGET_DEFAULT_MAX_SCALARIZATION_SIZE

2014-08-20 Thread James Greenhalgh

Hi,

This patch wires up our new target hook for AArch64. This means we can
bring back the two failing SRA tests (churn :( ). For now, I've just used
the old values we had for MOVE_RATIO. We should refactor that, as we use it
in two places (more churn :( ).

Bootstrapped on AArch64 with no issues and benchmarked with no discernible
impact.

OK for trunk?

Thanks,
James

---
gcc/

2014-08-20  James Greenhalgh  

* config/aarch64/aarch64.c
(aarch64_expand_movmem): Refactor old move costs.
(aarch64_default_max_total_scalarization_size): New.
(TARGET_DEFAULT_MAX_TOTAL_SCALARIZATION_SIZE): Likewise.
* config/aarch64/aarch64.h (AARCH64_MOVE_RATIO): New.
(MOVE_RATIO): Use it.

gcc/testsuite/

2014-08-20  James Greenhalgh  

* gcc.dg/tree-ssa/pr42585.c: Bring back for AArch64.
* gcc.dg/tree-ssa/sra-12.c: Likewise.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index c3c871e..d608717 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -9725,7 +9725,7 @@ aarch64_expand_movmem (rtx *operands)
 
   /* When optimizing for size, give a better estimate of the length of a
  memcpy call, but use the default otherwise.  */
-  unsigned int max_instructions = (speed_p ? 15 : AARCH64_CALL_RATIO) / 2;
+  unsigned int max_instructions = AARCH64_MOVE_RATIO (speed_p);
 
   /* We can't do anything smart if the amount to copy is not constant.  */
   if (!CONST_INT_P (operands[2]))
@@ -9826,6 +9826,14 @@ aarch64_expand_movmem (rtx *operands)
   return true;
 }
 
+/* Implement TARGET_DEFAULT_MAX_TOTAL_SCALARIZATION_SIZE.  */
+
+static unsigned int
+aarch64_default_max_total_scalarization_size (bool size_p)
+{
+  return AARCH64_MOVE_RATIO (!size_p);
+}
+
 #undef TARGET_ADDRESS_COST
 #define TARGET_ADDRESS_COST aarch64_address_cost
 
@@ -9949,6 +9957,10 @@ aarch64_expand_movmem (rtx *operands)
 #undef TARGET_MANGLE_TYPE
 #define TARGET_MANGLE_TYPE aarch64_mangle_type
 
+#undef TARGET_DEFAULT_MAX_TOTAL_SCALARIZATION_SIZE
+#define TARGET_DEFAULT_MAX_TOTAL_SCALARIZATION_SIZE \
+  aarch64_default_max_total_scalarization_size
+
 #undef TARGET_MEMORY_MOVE_COST
 #define TARGET_MEMORY_MOVE_COST aarch64_memory_move_cost
 
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index db950da..5401061 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -681,6 +681,8 @@ do {	 \
 /* The base cost overhead of a memcpy call, for MOVE_RATIO and friends.  */
 #define AARCH64_CALL_RATIO 8
 
+#define AARCH64_MOVE_RATIO(speed) (((speed) ? 15 : AARCH64_CALL_RATIO) / 2)
+
 /* MOVE_RATIO dictates when we will use the move_by_pieces infrastructure.
move_by_pieces will continually copy the largest safe chunks.  So a
7-byte copy is a 4-byte + 2-byte + byte copy.  This proves inefficient
@@ -688,7 +690,7 @@ do {	 \
standard name to implement the copy.  This logic does not apply when
targeting -mstrict-align, so keep a sensible default in that case.  */
 #define MOVE_RATIO(speed) \
-  (!STRICT_ALIGNMENT ? 2 : (((speed) ? 15 : AARCH64_CALL_RATIO) / 2))
+  (!STRICT_ALIGNMENT ? 2 : AARCH64_MOVE_RATIO (speed))
 
 /* For CLEAR_RATIO, when optimizing for size, give a better estimate
of the length of a memset call, but use the default otherwise.  */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c b/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c
index 07f575d..a970c85 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c
@@ -35,6 +35,6 @@ Cyc_string_ungetc (int ignore, struct _fat_ptr *sptr)
 /* Whether the structs are totally scalarized or not depends on the
MOVE_RATIO macro definition in the back end.  The scalarization will
not take place when using small values for MOVE_RATIO.  */
-/* { dg-final { scan-tree-dump-times "struct _fat_ptr _ans" 0 "optimized" { target { ! "aarch64*-*-* arm*-*-* avr-*-* nds32*-*-* powerpc*-*-* s390*-*-* sh*-*-*" } } } } */
-/* { dg-final { scan-tree-dump-times "struct _fat_ptr _T2" 0 "optimized" { target { ! "aarch64*-*-* arm*-*-* avr-*-* nds32*-*-* powerpc*-*-* s390*-*-* sh*-*-*" } } } } */
+/* { dg-final { scan-tree-dump-times "struct _fat_ptr _ans" 0 "optimized" { target { ! "arm*-*-* avr-*-* nds32*-*-* powerpc*-*-* s390*-*-* sh*-*-*" } } } } */
+/* { dg-final { scan-tree-dump-times "struct _fat_ptr _T2" 0 "optimized" { target { ! "arm*-*-* avr-*-* nds32*-*-* powerpc*-*-* s390*-*-* sh*-*-*" } } } } */
 /* { dg-final { cleanup-tree-dump "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/sra-12.c b/gcc/testsuite/gcc.dg/tree-ssa/sra-12.c
index 45aa963..59e5e6a 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/sra-12.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/sra-12.c
@@ -21,5 +21,5 @@ int foo (struct S *p)
   *p = l;
 }
 
-/* { dg-final { scan-tree-dump-times "l;" 0 "release_ssa" { target { ! "aarch64*-*-* avr*-*-* nds32*-*-*" } } } } */
+/* { dg-final { scan-tree-dump-times "l;" 0 "

[Patch 1/2] Control SRA and IPA-SRA by a param rather than MOVE_RATIO

2014-08-20 Thread James Greenhalgh

Hi,

Presently the decision as to whether to completely scalarize an aggregate
or not is made based on MOVE_RATIO. This is an undocumented, and unexpected,
overloading of the target macro.

In this patch we fix this.

First, we we add a new target hook
TARGET_DEFAULT_MAX_TOTAL_SCALARIZATION_SIZE, which returns MOVE_RATIO
by default.

Then we add two new parameters:

  sra-max-total-scalarization-size-Ospeed - The maximum size of aggregate
  to consider when compiling for speed
  sra-max-total-scalarization-size-Osize - The maximum size of aggregate
  to consider when compiling for size.

Set to default to 0.

Finally we wire up SRA to prefer using the parameters, and if it doesn't
find values for them, fallback to the target hook.

Bootstrapped and regression tested for x86, arm and aarch64 with no
issues, I've also thrown a smoke-test of popular small benchmarks at
each platform without seeing meaningful differences (as you would expect).

OK?

Thanks,
James

---
gcc/

2014-08-20  James Greenhalgh  

* doc/invoke.texi (sra-max-total-scalarization-size-Ospeed): Document.
(sra-max-total-scalarization-size-Osize): Likewise.
* doc/tm.texi.in
(TARGET_DEFAULT_MAX_TOTAL_SCALARIZATION_SIZE): Add hook.
* doc/tm.texi: Regenerate.
* params.def (sra-max-total-scalarization-size-Ospeed): New.
(sra-max-total-scalarization-size-Osize): Likewise.
* target.def (default_max_total_scalarization_size): New.
* targhooks.c (default_max_total_scalarization_size): New.
* targhooks.h (default_max_total_scalarization_size): New.
* tree-sra.c (get_max_total_scalarization_size): New.
(analyze_all_variable_accesses): Use it.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 6374261..2b6593d 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10232,6 +10232,15 @@ parameters only when their cumulative size is less or equal to
 @option{ipa-sra-ptr-growth-factor} times the size of the original
 pointer parameter.
 
+@item sra-max-total-scalarization-size-Ospeed
+@item sra-max-total-scalarization-size-Osize
+The two Scalar Reduction of Aggregates passes (SRA and IPA-SRA) aim to
+replace scalar parts of aggregates with uses of independent scalar
+variables. These parameters control the maximum size of aggregate
+which will be considered for replacement when compiling for speed
+(@option{sra-max-total-scalarization-size-Ospeed}) or size
+(@option{sra-max-total-scalarization-size-Osize}) respectively.
+
 @item tm-max-aggregate-size
 When making copies of thread-local variables in a transaction, this
 parameter specifies the size in bytes after which variables are
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 9dd8d68..42ef37f 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -6118,6 +6118,16 @@ value to the result of that function.  The arguments to that function
 are the same as to this target hook.
 @end deftypefn
 
+@deftypefn {Target Hook} {unsigned int} TARGET_DEFAULT_MAX_TOTAL_SCALARIZATION_SIZE (bool @var{size_p})
+This target hook is used by the Scalar Replacement of Aggregates pass
+  to determine the maximum size, in words, of aggregate to consider for
+  replacement.  @code{size_p} is used to indicate whether we are compiling
+  for size or speed.  By default, the maximum total scalarization size
+  is determined by MOVE_RATIO and can be further controlled using the
+  parameters @code{sra-max-total-scalarization-size-Ospeed} and
+  @code{sra-max-total-scalarization-size-Osize}.
+@end deftypefn
+
 @defmac BRANCH_COST (@var{speed_p}, @var{predictable_p})
 A C expression for the cost of a branch instruction.  A value of 1 is
 the default; other values are interpreted relative to that. Parameter
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index dd72b98..d560521 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -4607,6 +4607,8 @@ These macros are obsolete, new ports should use the target hook
 
 @hook TARGET_MEMORY_MOVE_COST
 
+@hook TARGET_DEFAULT_MAX_TOTAL_SCALARIZATION_SIZE
+
 @defmac BRANCH_COST (@var{speed_p}, @var{predictable_p})
 A C expression for the cost of a branch instruction.  A value of 1 is
 the default; other values are interpreted relative to that. Parameter
diff --git a/gcc/params.def b/gcc/params.def
index aefdd07..dea6fb3 100644
--- a/gcc/params.def
+++ b/gcc/params.def
@@ -942,6 +942,18 @@ DEFPARAM (PARAM_TM_MAX_AGGREGATE_SIZE,
 	  "pairs",
 	  9, 0, 0)
 
+DEFPARAM (PARAM_SRA_TOTAL_SCALARIZATION_SIZE_SPEED,
+	  "sra-max-total-scalarization-size-Ospeed",
+	  "Maximum size, in words, of an aggregate which should be "
+	  "considered for scalarization when compiling for speed",
+	  0, 0, 0)
+
+DEFPARAM (PARAM_SRA_TOTAL_SCALARIZATION_SIZE_SIZE,
+	  "sra-max-total-scalarization-size-Osize",
+	  "Maximum size, in words, of an aggregate which should be "
+	  "considered for scalarization when compiling for size",
+	  0, 0, 0)
+
 DEFPARAM (PARAM_IPA_CP_VALUE_LIST_SIZE,
 	  "ip

Re: [PATCH v3] Add strict aliasing warning when inlining function.

2014-08-20 Thread lin zuojian
Hi,
This version make sure that the added test case pass the test.


* tree-inline.c (setup_one_parameter): Add strict aliasing check.
* c-family/c-common.c (strict_aliasing_warning): Move to alias.c.
* c-family/c-common.h (strict_aliasing_warning): Move to tree.h.
* alias.c (strict_aliasing_warning): New function moved from
c-family/c-common.c.
* tree.h (strict_aliasing_warning): New function declaration moved from
c-family/c-common.h.
* testsuite/g++.dg/warn/Wstrict-aliasing-inline-parameter.C: New test.
---
 gcc/ChangeLog  | 11 +++
 gcc/alias.c| 78 ++
 gcc/c-family/c-common.c| 78 --
 gcc/c-family/c-common.h|  1 -
 .../warn/Wstrict-aliasing-inline-parameter.C   | 40 +++
 gcc/tree-inline.c  |  4 ++
 gcc/tree.h |  2 +
 7 files changed, 135 insertions(+), 79 deletions(-)
 create mode 100644 
gcc/testsuite/g++.dg/warn/Wstrict-aliasing-inline-parameter.C

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index e1b655f..4338e2b 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,14 @@
+2014-08-21  Lin Zuojian  
+
+   * tree-inline.c (setup_one_parameter): Add strict aliasing check.
+   * c-family/c-common.c (strict_aliasing_warning): Move to alias.c.
+   * c-family/c-common.h (strict_aliasing_warning): Move to tree.h.
+   * alias.c (strict_aliasing_warning): New function moved from
+   c-family/c-common.c.
+   * tree.h (strict_aliasing_warning): New function declaration moved from
+   c-family/c-common.h.
+   * testsuite/g++.dg/warn/Wstrict-aliasing-inline-parameter.C: New test.
+
 2014-08-20  David Malcolm  
 
* cfgrtl.c (duplicate_insn_chain): Convert the checked cast on
diff --git a/gcc/alias.c b/gcc/alias.c
index 39df09b..8496435 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -3044,4 +3044,82 @@ end_alias_analysis (void)
   sbitmap_free (reg_known_equiv_p);
 }
 
+/* Print a warning about casts that might indicate violation
+   of strict aliasing rules if -Wstrict-aliasing is used and
+   strict aliasing mode is in effect. OTYPE is the original
+   TREE_TYPE of EXPR, and TYPE the type we're casting to. */
+
+bool
+strict_aliasing_warning (tree otype, tree type, tree expr)
+{
+  /* Strip pointer conversion chains and get to the correct original type.  */
+  STRIP_NOPS (expr);
+  otype = TREE_TYPE (expr);
+
+  if (!(flag_strict_aliasing
+   && POINTER_TYPE_P (type)
+   && POINTER_TYPE_P (otype)
+   && !VOID_TYPE_P (TREE_TYPE (type)))
+  /* If the type we are casting to is a ref-all pointer
+ dereferencing it is always valid.  */
+  || TYPE_REF_CAN_ALIAS_ALL (type))
+return false;
+
+  if ((warn_strict_aliasing > 1) && TREE_CODE (expr) == ADDR_EXPR
+  && (DECL_P (TREE_OPERAND (expr, 0))
+  || handled_component_p (TREE_OPERAND (expr, 0
+{
+  /* Casting the address of an object to non void pointer. Warn
+ if the cast breaks type based aliasing.  */
+  if (!COMPLETE_TYPE_P (TREE_TYPE (type)) && warn_strict_aliasing == 2)
+   {
+ warning (OPT_Wstrict_aliasing, "type-punning to incomplete type "
+  "might break strict-aliasing rules");
+ return true;
+   }
+  else
+{
+  /* warn_strict_aliasing >= 3.   This includes the default (3).
+ Only warn if the cast is dereferenced immediately.  */
+  alias_set_type set1 =
+   get_alias_set (TREE_TYPE (TREE_OPERAND (expr, 0)));
+  alias_set_type set2 = get_alias_set (TREE_TYPE (type));
+
+  if (set1 != set2 && set2 != 0
+ && (set1 == 0 || !alias_sets_conflict_p (set1, set2)))
+   {
+ warning (OPT_Wstrict_aliasing, "dereferencing type-punned "
+  "pointer will break strict-aliasing rules");
+ return true;
+   }
+  else if (warn_strict_aliasing == 2
+  && !alias_sets_must_conflict_p (set1, set2))
+   {
+ warning (OPT_Wstrict_aliasing, "dereferencing type-punned "
+  "pointer might break strict-aliasing rules");
+ return true;
+   }
+}
+}
+  else
+if ((warn_strict_aliasing == 1) && !VOID_TYPE_P (TREE_TYPE (otype)))
+  {
+/* At this level, warn for any conversions, even if an address is
+   not taken in the same statement.  This will likely produce many
+   false positives, but could be useful to pinpoint problems that
+   are not revealed at higher levels.  */
+alias_set_type set1 = get_alias_set (TREE_TYPE (otype));
+alias_set_type set2 = get_alias_set (TREE_TYPE (type));
+if (!COMPLETE_TYPE_P (type)
+|| !alias_sets_must_conflict_p (set1, set

[PATCH][match-and-simplify] Use gsi_replace_with_seq_vops

2014-08-20 Thread Richard Biener

Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.

Richard.

2014-08-20  Richard Biener  

* gimple-fold.c (fold_stmt_1): Use gsi_replace_with_seq_vops
helper to insert gimple_simplify result.

Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c   (revision 214101)
+++ gcc/gimple-fold.c   (working copy)
@@ -2732,6 +2732,7 @@ fold_stmt_1 (gimple_stmt_iterator *gsi,
  && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (ops[2])))
return changed;
   gimple_assign_set_rhs_with_ops_1 (gsi, rcode, ops[0], ops[1], ops[2]);
+  gsi_insert_seq_before (gsi, seq, GSI_SAME_STMT);
 }
   else
 {
@@ -2739,22 +2740,15 @@ fold_stmt_1 (gimple_stmt_iterator *gsi,
return changed;
   if (gimple_has_lhs (stmt))
{
- gimple_seq tail = NULL;
  tree lhs = gimple_get_lhs (stmt);
  maybe_push_res_to_seq (rcode, TREE_TYPE (lhs),
-ops, &tail, lhs);
- gcc_assert (gimple_seq_singleton_p (tail));
- gimple with = gimple_seq_first_stmt (tail);
- gimple_set_vdef (with, gimple_vdef (stmt));
- gimple_set_vuse (with, gimple_vuse (stmt));
- gsi_replace (gsi, with, false);
+ops, &seq, lhs);
+ gsi_replace_with_seq_vops (gsi, seq);
}
   else
gcc_unreachable ();
 }
 
-  if (!inplace)
-gsi_insert_seq_before (gsi, seq, GSI_SAME_STMT);
   return true;
 }
 


Re: [PATCH][match-and-simplify] Fix comparison pattern

2014-08-20 Thread Richard Biener
On Wed, 20 Aug 2014, Marc Glisse wrote:

> On Wed, 20 Aug 2014, Richard Biener wrote:
> 
> > Committed.
> > 
> > Also makes visible a desirable change I plan for if-exprs.  They
> > should behave like outer ifs and allow us to write that series
> > of pattern as
> > 
> > (for op in eq ne
> >  /* Simplify X * C1 CMP 0 to X CMP 0 if C1 is not zero.  */
> >  (simplify
> >(op (mult @0 INTEGER_CST@1) integer_zerop@2)
> >/* In fold-const.c we have this and the following patterns
> >   combined because there we can "compute" the operator
> >   to use by using swap_tree_comparison.  */
> >(if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0)))
> >  (if (tree_int_cst_sgn (@1) > 0)
> >  (op @0 @2))
> >  (if (tree_int_cst_sgn (@1) < 0 && op == EQ_EXPR)
> >  (ne @0 @2))
> >  (if (tree_int_cst_sgn (@1) < 0 && op == NE_EXPR)
> >  (eq @0 @2)
> > 
> > that is, inner ifs have two operands, one condition and one
> > "result" (which can be another if).  And the simplify
> > now has one mandatory match operand and at least one
> > result operand (if which all but the last have to be an
> > 'if').
> 
> Not related to how you do "if" and such, but this simplification doesn't make
> sense. swap_tree_comparison preserves eq and ne, you only care that @1 is
> non-zero. It is for comparisons like lt that the sign can change the
> operation.

Oops, true (the fold_comparison code doesn't restrict itself to
eq and ne).  So for ne and eq the sign of @1 doesn't matter.
So we can improve here and do

/* Simplify X * C1 CMP 0 to X CMP 0 if C1 is not zero.  */
(for op in lt le eq ne ge gt
  (simplify
(op (mult @0 INTEGER_CST@1) integer_zerop@2)
/* In fold-const.c we have this and the following pattern
   combined because there we can "compute" the operator
   to use by using swap_tree_comparison.  Here we manage
   to use only two patterns by swapping the operands instead
   of changing the comparison code.  */
(if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
 && tree_int_cst_sgn (@1) > 0))
(op @0 @2))
  (simplify
(op (mult @0 INTEGER_CST@1) integer_zerop@2)
(if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
 && tree_int_cst_sgn (@1) < 0))
(op @2 @0)))

right?

Thanks,
Richard.


Re: [PATCH] Add guality [p]type test.

2014-08-20 Thread Richard Biener
On Tue, Aug 19, 2014 at 7:52 PM, Mark Wielaard  wrote:
> On Tue, 2014-08-19 at 14:16 +0200, Richard Biener wrote:
>> On Tue, Aug 19, 2014 at 2:10 PM, Mark Wielaard  wrote:
>> > gcc/testsuite/ChangeLog
>> > 2014-08-19  Mark Wielaard  
>> >
>> > * gcc.dg/guality/restrict.c: Add `used' attribute to all variables.
>> > (cpy): Change type of last argument to int.
>> >
>> > That last change is necessary to succeed with LTO. Otherwise the type of
>> > the function:
>> >
>> > static __attribute__((noclone, noinline)) void *
>> > cpy (void * restrict s1, const void * restrict s2, unsigned int n)
>> >
>> > comes out as:
>> >
>> > void *(void * restrict, const void * restrict, __unknown__)
>> >
>> > That seems a genuine bug. Should I commit the cpy function type change
>> > to make the test PASS with LTO? Or leave it as is so it FAILs and
>> > someone else can look into it?
>>
>> Yeah, that's a genuine bug.  Not sure why it happens.  If you file a bug
>> I can have a look later.
>
> Filed as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62190 "LTO DWARF
> produces __unknown__ type for unsigned int function argument type".
>
> I included a smaller testcase in the bug that can just be dropped into
> gcc/testsuite/gcc.dg/guality/ to show the issue. Shall I just commit the
> change to the restrict.c testcase, so at least that one always PASSes
> for now?

No need - I have a fix in testing.

Richard.

> Cheers,
>
> Mark


[PATCH][AArch64] Fix wrong ".cfi_def_cfa_offset" in epilogue

2014-08-20 Thread Jiong Wang

for *a function with frame size >= 512 and there is outgoing area*,
aarch64 gcc is generate wrong .cfi_def_cfa_offset for the last
stack adjustment instruction in epiloue.

given a simple testcase

test.c
===
int
main (int argc, char **argv)
{
  char a[600];
  int b = 0x10;
  printf ("%d, %d, %d, %d, %d, %d, %d, %d\n", argc + 0, argc + 1, argc + 2,
  argc + 3, argc + 4, argc + 5, argc + 6, argc + 7);
  return 0;
}


gcc -O0 -g test.c

gdb ./a.out
(gdb) b main
(gdb) r
(gdb) b *0x00400744
(break point at the end of the "main"
   0x0040073c <+204>: ldp x29, x30, [sp],#16
   0x00400740 <+208>: add sp, sp, #0x280
   0x00400744 <+212>: ret  <--- *set a break point here*
)

(gdb) c
Breakpoint 2, 0x00400744 in main (argc=-1693278018, argv=0x0) at 
hello.c:9
(gdb) p/x b
* $1 = 0 while $1 should be 0x10 *
(gdb)

all local variable access are wrong, because gcc generated wrong cfa adjustment

add sp, sp, 640  <--- A
.cfi_def_cfa_offset 624  <--- B
ret

after A, the cfa offset should be zero, so B should be

   .cfi_def_cfa_offset 0


no regression on aarch64-none-elf bare-metal full test.

ok for trunk?

thanks.

gcc/
  * config/aarch64/aarch64.c (aarch64_expand_epilogue): Remove redundant cfa 
offset update.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 2ea55e8..53d3fa1 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -2551,11 +2551,6 @@ aarch64_expand_epilogue (bool for_sibcall)
 	  RTX_FRAME_RELATED_P (insn) = 1;
 	}
 	}
-
-  aarch64_set_frame_expr (gen_rtx_SET (Pmode, stack_pointer_rtx,
-	   plus_constant (Pmode,
-			  stack_pointer_rtx,
-			  offset)));
 }

   emit_use (gen_rtx_REG (DImode, LR_REGNUM));

RE: [PATCH] Fix confusion between target, host and symbolic number byte sizes

2014-08-20 Thread Thomas Preud'homme
Ping?

> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> > Sent: Thursday, August 07, 2014 1:57 PM
> > To: gcc-patches@gcc.gnu.org
> > Subject: RE: [PATCH] Fix confusion between target, host and symbolic
> > number byte sizes
> >
> > I suppose people were busy when I posted this patch and it got forgotten
> > since so here is a little ping.
> >
> > Best regards,
> >
> > Thomas
> >
> > > -Original Message-
> > > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > > ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> > > Sent: Friday, July 04, 2014 12:53 PM
> > > To: gcc-patches@gcc.gnu.org
> > > Subject: [PATCH] Fix confusion between target, host and symbolic
> number
> > > byte sizes
> > >
> > > The bswap pass deals with 3 possibly different byte size: host, target and
> > the
> > > size a byte marker occupied in the symbolic_number structure [1].
> > However,
> > > as of now the code mixes the three size. This works in practice as the 
> > > pass
> > is
> > > only enabled for target with BITS_PER_UNIT == 8 and nobody runs GCC
> on
> > a
> > > host with CHAR_BIT != 8. As prompted by Jakub Jelinek, this patch fixes
> this
> > > mess. Byte marker are 8-bit quantities (they could be made 4-bit
> quantities
> > > but I prefered to keep the code working the same as before) for which a
> > > new macro is introduced (BITS_PER_MARKERS), anything related to
> storing
> > > the value or a byte marker in a variable should check for the host byte
> size
> > or
> > > wide integer size and anything aimed at manipulating the target value
> > should
> > > check for BITS_PER_UNIT.
> > >
> > >
> > > [1] Although the comment for this structure implies that a byte marker as
> > the
> > > same size as the host byte, the way it is used in the code (even before
> any
> > of
> > > my patch) shows that it uses a fixed size of 8 [2].
> > > [2] Note that since the pass is only active for targets with BITS_PER_UNIT
> > ==
> > > 8, it might be using the target byte size.
> > >
> > > gcc/ChangeLog:
> > >
> > > 2014-07-04  Thomas Preud'homme  
> > >
> > >   * tree-ssa-math-opts.c (struct symbolic_number): Clarify comment
> > > about
> > >   the size of byte markers.
> > >   (do_shift_rotate): Fix confusion between host, target and marker
> > > byte
> > >   size.
> > >   (verify_symbolic_number_p): Likewise.
> > >   (find_bswap_or_nop_1): Likewise.
> > >   (find_bswap_or_nop): Likewise.
> > >
> > >
> > > diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
> > > index ca2b30d..55c5df7 100644
> > > --- a/gcc/tree-ssa-math-opts.c
> > > +++ b/gcc/tree-ssa-math-opts.c
> > > @@ -1602,11 +1602,10 @@ make_pass_cse_sincos (gcc::context *ctxt)
> > >
> > >  /* A symbolic number is used to detect byte permutation and selection
> > > patterns.  Therefore the field N contains an artificial number
> > > -   consisting of byte size markers:
> > > +   consisting of octet sized markers:
> > >
> > > -   0- byte has the value 0
> > > -   1..size - byte contains the content of the byte
> > > -   number indexed with that value minus one.
> > > +   0- target byte has the value 0
> > > +   1..size - marker value is the target byte index minus one.
> > >
> > > To detect permutations on memory sources (arrays and structures), a
> > > symbolic
> > > number is also associated a base address (the array or structure the
> load
> > is
> > > @@ -1631,6 +1630,8 @@ struct symbolic_number {
> > >unsigned HOST_WIDE_INT range;
> > >  };
> > >
> > > +#define BITS_PER_MARKER 8
> > > +
> > >  /* The number which the find_bswap_or_nop_1 result should match in
> > > order to have a nop.  The number is masked according to the size of
> > > the symbolic number before using it.  */
> > > @@ -1652,15 +1653,16 @@ do_shift_rotate (enum tree_code code,
> > >struct symbolic_number *n,
> > >int count)
> > >  {
> > > -  int bitsize = TYPE_PRECISION (n->type);
> > > +  int size = TYPE_PRECISION (n->type) / BITS_PER_UNIT;
> > >
> > > -  if (count % 8 != 0)
> > > +  if (count % BITS_PER_UNIT != 0)
> > >  return false;
> > > +  count = (count / BITS_PER_UNIT) * BITS_PER_MARKER;
> > >
> > >/* Zero out the extra bits of N in order to avoid them being shifted
> > >   into the significant bits.  */
> > > -  if (bitsize < 8 * (int)sizeof (int64_t))
> > > -n->n &= ((uint64_t)1 << bitsize) - 1;
> > > +  if (size < 64 / BITS_PER_MARKER)
> > > +n->n &= ((uint64_t) 1 << (size * BITS_PER_MARKER)) - 1;
> > >
> > >switch (code)
> > >  {
> > > @@ -1670,22 +1672,22 @@ do_shift_rotate (enum tree_code code,
> > >  case RSHIFT_EXPR:
> > >/* Arithmetic shift of signed type: result is dependent on the 
> > > value.
> */
> > >if (!TYPE_UNSIGNED (n->type)
> > > -   && (n->n & ((uint64_t) 0xff << (bitsize - 8
> > > +   && (n->n & ((uint64_t) 0xff << ((size - 1) * BITS_PER_MARKER)))

Re: [PATCH 035/236] Return types of unlink_insn_chain and duplicate_insn_chain

2014-08-20 Thread Andreas Schwab
David Malcolm  writes:

> @@ -4083,7 +4083,7 @@ cfg_layout_can_duplicate_bb_p (const_basic_block bb)
>return true;
>  }
>  
> -rtx
> +rtx_insn *
>  duplicate_insn_chain (rtx from, rtx to)
>  {
>rtx insn, next, copy;
> @@ -4169,7 +4169,7 @@ duplicate_insn_chain (rtx from, rtx to)
>  }
>insn = NEXT_INSN (last);
>delete_insn (last);
> -  return insn;
> +  return as_a  (insn);

This is wrong, insn may be NULL.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."


  1   2   >