[Ada] Fix segfault on double record extension

[Eric Botcazou]

This is a regression present on the mainline and 5 branch, for a double record 
extension involving a size clause on the root type and a discriminant with 
variant part on the first extension...

Tested on x86_64-suse-linux, applied on the mainline and 5 branch.


2016-03-27  Eric Botcazou  

* gcc-interface/decl.c (components_to_record): Add special case for 
single field with representation clause at offset 0.


2016-03-27  Eric Botcazou  

* gnat.dg/specs/double_record_extension3.ads: New test.


-- 
Eric BotcazouIndex: gcc-interface/decl.c
===
--- gcc-interface/decl.c	(revision 234493)
+++ gcc-interface/decl.c	(working copy)
@@ -7606,6 +7606,23 @@ components_to_record (tree gnu_record_ty
   if (p_gnu_rep_list && gnu_rep_list)
 *p_gnu_rep_list = chainon (*p_gnu_rep_list, gnu_rep_list);
 
+  /* If only one field has a rep clause and it starts at 0, put back the field
+ at the head of the regular field list.  This will avoid creating a useless
+ REP part below and deal with the annoying case of an extension of a record
+ with variable size and rep clause, for which the _Parent field is forced
+ at offset 0 and has variable size, which we do not support below.  */
+  else if (gnu_rep_list
+	   && !DECL_CHAIN (gnu_rep_list)
+	   && !variants_have_rep
+	   && first_free_pos
+	   && integer_zerop (first_free_pos)
+	   && integer_zerop (bit_position (gnu_rep_list)))
+{
+  DECL_CHAIN (gnu_rep_list) = gnu_field_list;
+  gnu_field_list = gnu_rep_list;
+  gnu_rep_list = NULL_TREE;
+}
+
   /* Otherwise, sort the fields by bit position and put them into their own
  record, before the others, if we also have fields without rep clause.  */
   else if (gnu_rep_list)
-- { dg-do compile }

package Double_Record_Extension3 is

   type Rec1 is tagged record
  Id : Integer;
   end record;

   for Rec1 use record
  Id at 8 range 0 .. 31;
   end record;

   type Rec2 (Size : Integer) is new Rec1 with record
  Data : String (1 .. Size);
   end record;

   type Rec3 is new Rec2 (Size => 128) with record
  Valid : Boolean;
   end record;

end Double_Record_Extension3;

Re: [PATCH 3/4, libgomp] Resolve deadlock on plugin exit, HSA plugin parts

[Chung-Lin Tang]

On 2016/3/25 上午 02:40, Martin Jambor wrote:
> On the whole, I am fine with the patch but there are two issues:
> 
> First, and generally, when you change the return type of a function,
> you must document what return values mean in the comment of the
> function.  Most importantly, it must be immediately apparent whether a
> function returns true or false on failure from its comment.  So please
> fix that.

Thanks, I'll update on that.

>> >  /* Callback of dispatch queues to report errors.  */
>> > @@ -454,7 +471,7 @@ queue_callback (hsa_status_t status,
>> >hsa_queue_t *queue __attribute__ ((unused)),
>> >void *data __attribute__ ((unused)))
>> >  {
>> > -  hsa_fatal ("Asynchronous queue error", status);
>> > +  hsa_error ("Asynchronous queue error", status);
>> >  }
> ...I believe this hunk is wrong.  Errors reported in this way mean
> that something is very wrong and generally happen during execution of
> code on HSA GPU, i.e. within GOMP_OFFLOAD_run.  And since you left
> calls in create_single_kernel_dispatch, which is called as a part of
> GOMP_OFFLOAD_run, intact, I believe you actually want to leave
> hsa_fatel here too.

Yes, a fatal exit is okay within the 'run' hook, since we're not holding
the device lock there. I was only trying to audit the GOMP_OFFLOAD_init_device()
function, where the queues are created.

I'm not familiar with the HSA runtime API; will the callback only be triggered
during GPU kernel execution (inside the 'run' hook), and not for example,
within hsa_queue_create()? If so, then yes as you advised, the above change to
queue_callback() should be reverted.

Chung-Lin

Contents of PO file 'cpplib-6.1-b20160131.da.po'

[Translation Project Robot]

cpplib-6.1-b20160131.da.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New Danish PO file for 'cpplib' (version 6.1-b20160131)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Danish team of translators.  The file is available at:

http://translationproject.org/latest/cpplib/da.po

(This file, 'cpplib-6.1-b20160131.da.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[Patch, Fortran] STOP issue with coarrays

[Alessandro Fanfarillo]

Dear all,

the attached patch fixes the issue reported by Anton Shterenlikht
(https://gcc.gnu.org/ml/fortran/2016-03/msg00037.html). The compiler
delegates the external library to manage the STOP statement in case
-fcoarray=lib is used.

Built and regtested on x86_64-pc-linux-gnu.

Ok for trunk and gcc-5-branch?
gcc/fortran/ChangeLog
2016-03-27  Alessandro Fanfarillo  

* trans-decl.c (gfc_build_builtin_function_decls):
caf_stop_numeric and caf_stop_str definition.
* trans-stmt.c (gfc_trans_stop): invoke external functions
for stop and stop_str when coarrays are used.
* trans.h: extern for new functions.

libgfortran/ChangeLog
2016-03-27  Alessandro Fanfarillo  

* caf/libcaf.h: caf_stop_numeric and caf_stop_str prototype.
* caf/single.c: _gfortran_caf_stop_numeric and
_gfortran_caf_stop_str implementation.

commit bb407679e918dfb9cbc769594cf39a6bd09dd9d9
Author: Alessandro Fanfarillo 
Date:   Sun Mar 27 16:42:59 2016 +0200

Adding caf_stop_str and caf_stop_numeric

diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 4bd7dc4..309baf1 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -137,6 +137,8 @@ tree gfor_fndecl_caf_sendget;
 tree gfor_fndecl_caf_sync_all;
 tree gfor_fndecl_caf_sync_memory;
 tree gfor_fndecl_caf_sync_images;
+tree gfor_fndecl_caf_stop_str;
+tree gfor_fndecl_caf_stop_numeric;
 tree gfor_fndecl_caf_error_stop;
 tree gfor_fndecl_caf_error_stop_str;
 tree gfor_fndecl_caf_atomic_def;
@@ -3550,6 +3552,18 @@ gfc_build_builtin_function_decls (void)
   /* CAF's ERROR STOP doesn't return.  */
   TREE_THIS_VOLATILE (gfor_fndecl_caf_error_stop_str) = 1;
 
+  gfor_fndecl_caf_stop_numeric = gfc_build_library_function_decl_with_spec 
(
+get_identifier (PREFIX("caf_stop_numeric")), ".R.",
+void_type_node, 1, gfc_int4_type_node);
+  /* CAF's STOP doesn't return.  */
+  TREE_THIS_VOLATILE (gfor_fndecl_caf_stop_numeric) = 1;
+
+  gfor_fndecl_caf_stop_str = gfc_build_library_function_decl_with_spec (
+get_identifier (PREFIX("caf_stop_str")), ".R.",
+void_type_node, 2, pchar_type_node, gfc_int4_type_node);
+  /* CAF's STOP doesn't return.  */
+  TREE_THIS_VOLATILE (gfor_fndecl_caf_stop_str) = 1;
+
   gfor_fndecl_caf_atomic_def = gfc_build_library_function_decl_with_spec (
get_identifier (PREFIX("caf_atomic_define")), "R..RW",
void_type_node, 7, pvoid_type_node, size_type_node, integer_type_node,
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index cb54499..2fc43ed 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -635,7 +635,9 @@ gfc_trans_stop (gfc_code *code, bool error_stop)
 ? (flag_coarray == GFC_FCOARRAY_LIB
? gfor_fndecl_caf_error_stop_str
: gfor_fndecl_error_stop_string)
-: gfor_fndecl_stop_string,
+: (flag_coarray == GFC_FCOARRAY_LIB
+   ? gfor_fndecl_caf_stop_str
+   : gfor_fndecl_stop_string),
 2, build_int_cst (pchar_type_node, 0), tmp);
 }
   else if (code->expr1->ts.type == BT_INTEGER)
@@ -646,7 +648,9 @@ gfc_trans_stop (gfc_code *code, bool error_stop)
 ? (flag_coarray == GFC_FCOARRAY_LIB
? gfor_fndecl_caf_error_stop
: gfor_fndecl_error_stop_numeric)
-: gfor_fndecl_stop_numeric_f08, 1,
+: (flag_coarray == GFC_FCOARRAY_LIB
+   ? gfor_fndecl_caf_stop_numeric
+   : gfor_fndecl_stop_numeric_f08), 1,
 fold_convert (gfc_int4_type_node, se.expr));
 }
   else
@@ -657,7 +661,9 @@ gfc_trans_stop (gfc_code *code, bool error_stop)
 ? (flag_coarray == GFC_FCOARRAY_LIB
? gfor_fndecl_caf_error_stop_str
: gfor_fndecl_error_stop_string)
-: gfor_fndecl_stop_string,
+: (flag_coarray == GFC_FCOARRAY_LIB
+   ? gfor_fndecl_caf_stop_str
+   : gfor_fndecl_stop_string),
 2, se.expr, se.string_length);
 }
 
diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h
index 316ee9b..add0cea 100644
--- a/gcc/fortran/trans.h
+++ b/gcc/fortran/trans.h
@@ -762,6 +762,8 @@ extern GTY(()) tree gfor_fndecl_caf_sendget;
 extern GTY(()) tree gfor_fndecl_caf_sync_all;
 extern GTY(()) tree gfor_fndecl_caf_sync_memory;
 extern GTY(()) tree gfor_fndecl_caf_sync_images;
+extern GTY(()) tree gfor_fndecl_caf_stop_numeric;

[Patch, Fortran, pr70397, gcc-5, v1] [5/6 Regression] ice while allocating ultimate polymorphic

[Andre Vehreschild]

Hi all,

attached is a patch to fix an ICE on allocating an unlimited polymorphic entity
from a non-poly class or type without an length component. The routine
gfc_copy_class_to_class() assumed that both the source and destination object's
type is unlimited polymorphic, but in this case it is true for the destination
only, which made gfortran look for a non-existent _len component in the source
object and therefore ICE. This is fixed by the patch by adding a function to
return either the _len component, when it exists, or a constant zero node to
init the destination object's _len component with.

Bootstrapped and regtested ok on x86_64-linux-gnu/F23. (Might have some
line deltas, because my git is a bit older. Sorry, only have limited/slow
net-access currently.)

The same patch should be adaptable to trunk. To come...

Ok for 5-trunk?

Regards,
Andre
-- 
Andre Vehreschild * vehre at gcc dot gnu.org

pr70391_1.clog
Description: Binary data
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 1681d14..642ce26 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -173,6 +173,24 @@ gfc_class_len_get (tree decl)
 }
 
 
+/* Try to get the _len component of a class.  When the class is not unlimited
+   poly, i.e. no _len field exists, then return a zero node.  */
+
+tree
+gfc_class_len_or_zero_get (tree decl)
+{
+  tree len;
+  if (POINTER_TYPE_P (TREE_TYPE (decl)))
+decl = build_fold_indirect_ref_loc (input_location, decl);
+  len = gfc_advance_chain (TYPE_FIELDS (TREE_TYPE (decl)),
+			   CLASS_LEN_FIELD);
+  return len != NULL_TREE ? fold_build3_loc (input_location, COMPONENT_REF,
+	 TREE_TYPE (len), decl, len,
+	 NULL_TREE)
+			  : integer_zero_node;
+}
+
+
 /* Get the specified FIELD from the VPTR.  */
 
 static tree
@@ -250,6 +268,7 @@ gfc_vptr_size_get (tree vptr)
 
 #undef CLASS_DATA_FIELD
 #undef CLASS_VPTR_FIELD
+#undef CLASS_LEN_FIELD
 #undef VTABLE_HASH_FIELD
 #undef VTABLE_SIZE_FIELD
 #undef VTABLE_EXTENDS_FIELD
@@ -1070,7 +1089,7 @@ gfc_copy_class_to_class (tree from, tree to, tree nelems, bool unlimited)
   if (unlimited)
 {
   if (from_class_base != NULL_TREE)
-	from_len = gfc_class_len_get (from_class_base);
+	from_len = gfc_class_len_or_zero_get (from_class_base);
   else
 	from_len = integer_zero_node;
 }
diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h
index e6544f9..38cffa4 100644
--- a/gcc/fortran/trans.h
+++ b/gcc/fortran/trans.h
@@ -356,6 +356,7 @@ tree gfc_class_set_static_fields (tree, tree, tree);
 tree gfc_class_data_get (tree);
 tree gfc_class_vptr_get (tree);
 tree gfc_class_len_get (tree);
+tree gfc_class_len_get_try (tree);
 gfc_expr * gfc_find_and_cut_at_last_class_ref (gfc_expr *);
 /* Get an accessor to the class' vtab's * field, when a class handle is
available.  */
diff --git a/gcc/testsuite/gfortran.dg/unlimited_polymorphic_25.f90 b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_25.f90
new file mode 100644
index 000..d0b2a2e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_25.f90
@@ -0,0 +1,40 @@
+! { dg-do run }
+!
+! Test contributed by Valery Weber  
+
+module mod
+
+  TYPE, PUBLIC :: base_type
+  END TYPE base_type
+
+  TYPE, PUBLIC :: dict_entry_type
+ CLASS( * ), ALLOCATABLE :: key
+ CLASS( * ), ALLOCATABLE :: val
+  END TYPE dict_entry_type
+
+
+contains
+
+  SUBROUTINE dict_put ( this, key, val )
+CLASS(dict_entry_type), INTENT(INOUT) :: this
+CLASS(base_type), INTENT(IN) :: key, val
+INTEGER  :: istat
+ALLOCATE( this%key, SOURCE=key, STAT=istat )
+  end SUBROUTINE dict_put
+end module mod
+
+program test
+  use mod
+  type(dict_entry_type) :: t
+  type(base_type) :: a, b
+  call dict_put(t, a, b)
+
+  if (.NOT. allocated(t%key)) call abort()
+  select type (x => t%key)
+type is (base_type)
+class default
+  call abort()
+  end select
+  deallocate(t%key)
+end
+
diff --git a/gcc/testsuite/gfortran.dg/unlimited_polymorphic_26.f90 b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_26.f90
new file mode 100644
index 000..1300069
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_26.f90
@@ -0,0 +1,47 @@
+! { dg-do run }
+!
+! Test contributed by Valery Weber  
+
+module mod
+
+  TYPE, PUBLIC :: dict_entry_type
+ CLASS( * ), ALLOCATABLE :: key
+ CLASS( * ), ALLOCATABLE :: val
+  END TYPE dict_entry_type
+
+
+contains
+
+  SUBROUTINE dict_put ( this, key, val )
+CLASS(dict_entry_type), INTENT(INOUT) :: this
+CLASS(*), INTENT(IN) :: key, val
+INTEGER  :: istat
+ALLOCATE( this%key, SOURCE=key, STAT=istat )
+ALLOCATE( this%val, SOURCE=val, STAT=istat )
+  end SUBROUTINE dict_put
+end module mod
+
+program test
+  use mod
+  type(dict_entry_type) :: t
+  call dict_put(t, "foo", 42)
+
+  if (.NOT. allocated(t%key)) call abort()
+  select type (x => t%key)
+type is (CHARACTER(*))

Re: [Patch, Fortran, pr70397, gcc-5, v1] [5/6 Regression] ice while allocating ultimate polymorphic

[Andre Vehreschild]

Hi all,

and here is already the follow-up. In the initial patch a safe wasn't commenced
before pulling the patch, which lead to a refactoring of the new functions node
to be partial only. Sorry for the noise.

- Andre

Am Sun, 27 Mar 2016 18:49:18 +0200
schrieb Andre Vehreschild :

> Hi all,
> 
> attached is a patch to fix an ICE on allocating an unlimited polymorphic
> entity from a non-poly class or type without an length component. The routine
> gfc_copy_class_to_class() assumed that both the source and destination
> object's type is unlimited polymorphic, but in this case it is true for the
> destination only, which made gfortran look for a non-existent _len component
> in the source object and therefore ICE. This is fixed by the patch by adding
> a function to return either the _len component, when it exists, or a constant
> zero node to init the destination object's _len component with.
> 
> Bootstrapped and regtested ok on x86_64-linux-gnu/F23. (Might have some
> line deltas, because my git is a bit older. Sorry, only have limited/slow
> net-access currently.)
> 
> The same patch should be adaptable to trunk. To come...
> 
> Ok for 5-trunk?
> 
> Regards,
>   Andre



-- 
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Email: ve...@gmx.de * Tel: +49 241 9291018
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 1681d14..642ce26 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -173,6 +173,24 @@ gfc_class_len_get (tree decl)
 }
 
 
+/* Try to get the _len component of a class.  When the class is not unlimited
+   poly, i.e. no _len field exists, then return a zero node.  */
+
+tree
+gfc_class_len_or_zero_get (tree decl)
+{
+  tree len;
+  if (POINTER_TYPE_P (TREE_TYPE (decl)))
+decl = build_fold_indirect_ref_loc (input_location, decl);
+  len = gfc_advance_chain (TYPE_FIELDS (TREE_TYPE (decl)),
+			   CLASS_LEN_FIELD);
+  return len != NULL_TREE ? fold_build3_loc (input_location, COMPONENT_REF,
+	 TREE_TYPE (len), decl, len,
+	 NULL_TREE)
+			  : integer_zero_node;
+}
+
+
 /* Get the specified FIELD from the VPTR.  */
 
 static tree
@@ -250,6 +268,7 @@ gfc_vptr_size_get (tree vptr)
 
 #undef CLASS_DATA_FIELD
 #undef CLASS_VPTR_FIELD
+#undef CLASS_LEN_FIELD
 #undef VTABLE_HASH_FIELD
 #undef VTABLE_SIZE_FIELD
 #undef VTABLE_EXTENDS_FIELD
@@ -1070,7 +1089,7 @@ gfc_copy_class_to_class (tree from, tree to, tree nelems, bool unlimited)
   if (unlimited)
 {
   if (from_class_base != NULL_TREE)
-	from_len = gfc_class_len_get (from_class_base);
+	from_len = gfc_class_len_or_zero_get (from_class_base);
   else
 	from_len = integer_zero_node;
 }
diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h
index e6544f9..9a181be 100644
--- a/gcc/fortran/trans.h
+++ b/gcc/fortran/trans.h
@@ -356,6 +356,7 @@ tree gfc_class_set_static_fields (tree, tree, tree);
 tree gfc_class_data_get (tree);
 tree gfc_class_vptr_get (tree);
 tree gfc_class_len_get (tree);
+tree gfc_class_len_or_zero_get (tree);
 gfc_expr * gfc_find_and_cut_at_last_class_ref (gfc_expr *);
 /* Get an accessor to the class' vtab's * field, when a class handle is
available.  */
diff --git a/gcc/testsuite/gfortran.dg/unlimited_polymorphic_25.f90 b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_25.f90
new file mode 100644
index 000..d0b2a2e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_25.f90
@@ -0,0 +1,40 @@
+! { dg-do run }
+!
+! Test contributed by Valery Weber  
+
+module mod
+
+  TYPE, PUBLIC :: base_type
+  END TYPE base_type
+
+  TYPE, PUBLIC :: dict_entry_type
+ CLASS( * ), ALLOCATABLE :: key
+ CLASS( * ), ALLOCATABLE :: val
+  END TYPE dict_entry_type
+
+
+contains
+
+  SUBROUTINE dict_put ( this, key, val )
+CLASS(dict_entry_type), INTENT(INOUT) :: this
+CLASS(base_type), INTENT(IN) :: key, val
+INTEGER  :: istat
+ALLOCATE( this%key, SOURCE=key, STAT=istat )
+  end SUBROUTINE dict_put
+end module mod
+
+program test
+  use mod
+  type(dict_entry_type) :: t
+  type(base_type) :: a, b
+  call dict_put(t, a, b)
+
+  if (.NOT. allocated(t%key)) call abort()
+  select type (x => t%key)
+type is (base_type)
+class default
+  call abort()
+  end select
+  deallocate(t%key)
+end
+
diff --git a/gcc/testsuite/gfortran.dg/unlimited_polymorphic_26.f90 b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_26.f90
new file mode 100644
index 000..1300069
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_26.f90
@@ -0,0 +1,47 @@
+! { dg-do run }
+!
+! Test contributed by Valery Weber  
+
+module mod
+
+  TYPE, PUBLIC :: dict_entry_type
+ CLASS( * ), ALLOCATABLE :: key
+ CLASS( * ), ALLOCATABLE :: val
+  END TYPE dict_entry_type
+
+
+contains
+
+  SUBROUTINE dict_put ( this, key, val )
+CLASS(dict_entry_type), INTENT(INOUT) :: this
+CLASS(*), INTENT(IN) :: key, val
+INTEGER  :

Re: Patches to fix GCC's C++ exception_handling on NetBSD/VAX

[Mikael Pettersson]

Jake Hamby writes:
 > As an added bonus, I see that my patch set also included an old m68k patch
 > that had been sitting in my tree, which fixes a crash when -m68040 is 
 > defined.
 > I may have submitted it to port-m68k before. It hasn't been tested with the
 > new compiler either. Here's that patch separately. It only matter when
 > TARGET_68881 && TUNE_68040.

Do you have a test case or some recipe for reproducing the crash?
I'd be happy to test this patch on Linux/M68K.

/Mikael

 > 
 > -Jake
 > 
 > 
 > Index: external/gpl3/gcc/dist/gcc/config/m68k/m68k.md
 > 
 > RCS file: /cvsroot/src/external/gpl3/gcc/dist/gcc/config/m68k/m68k.md,v
 > retrieving revision 1.4
 > diff -u -u -r1.4 m68k.md
 > --- external/gpl3/gcc/dist/gcc/config/m68k/m68k.md   24 Jan 2016 09:43:33 
 > -  1.4
 > +++ external/gpl3/gcc/dist/gcc/config/m68k/m68k.md   26 Mar 2016 10:42:41 
 > -
 > @@ -2132,9 +2132,9 @@
 >  ;; into the kernel to emulate fintrz.  They should also be faster
 >  ;; than calling the subroutines fixsfsi or fixdfsi.
 > 
 > -(define_insn "fix_truncdfsi2"
 > +(define_insn "fix_truncsi2"
 >[(set (match_operand:SI 0 "nonimmediate_operand" "=dm")
 > -(fix:SI (fix:DF (match_operand:DF 1 "register_operand" "f"
 > +(fix:SI (match_operand:FP 1 "register_operand" "f")))
 > (clobber (match_scratch:SI 2 "=d"))
 > (clobber (match_scratch:SI 3 "=d"))]
 >"TARGET_68881 && TUNE_68040"
 > @@ -2143,9 +2143,9 @@
 >return "fmovem%.l %!,%2\;moveq #16,%3\;or%.l %2,%3\;and%.w 
 > #-33,%3\;fmovem%.l %3,%!\;fmove%.l %1,%0\;fmovem%.l %2,%!";
 >  })
 > 
 > -(define_insn "fix_truncdfhi2"
 > +(define_insn "fix_trunchi2"
 >[(set (match_operand:HI 0 "nonimmediate_operand" "=dm")
 > -(fix:HI (fix:DF (match_operand:DF 1 "register_operand" "f"
 > +(fix:HI (match_operand:FP 1 "register_operand" "f")))
 > (clobber (match_scratch:SI 2 "=d"))
 > (clobber (match_scratch:SI 3 "=d"))]
 >"TARGET_68881 && TUNE_68040"
 > @@ -2154,9 +2154,9 @@
 >return "fmovem%.l %!,%2\;moveq #16,%3\;or%.l %2,%3\;and%.w 
 > #-33,%3\;fmovem%.l %3,%!\;fmove%.w %1,%0\;fmovem%.l %2,%!";
 >  })
 > 
 > -(define_insn "fix_truncdfqi2"
 > +(define_insn "fix_truncqi2"
 >[(set (match_operand:QI 0 "nonimmediate_operand" "=dm")
 > -(fix:QI (fix:DF (match_operand:DF 1 "register_operand" "f"
 > +(fix:QI (match_operand:FP 1 "register_operand" "f")))
 > (clobber (match_scratch:SI 2 "=d"))
 > (clobber (match_scratch:SI 3 "=d"))]
 >"TARGET_68881 && TUNE_68040"

-- 

Re: [Patch, Fortran] STOP issue with coarrays

[Paul Richard Thomas]

Hi Alessandro,

The patch is fine for trunk and 5-branch - going on trivial, I would
say! Are you going to add the testcase?

Thanks a lot! I am impressed that you are doing these between
celebrating your doctorate and preparing for your move :-)

Paul

On 27 March 2016 at 17:10, Alessandro Fanfarillo
 wrote:
> Dear all,
>
> the attached patch fixes the issue reported by Anton Shterenlikht
> (https://gcc.gnu.org/ml/fortran/2016-03/msg00037.html). The compiler
> delegates the external library to manage the STOP statement in case
> -fcoarray=lib is used.
>
> Built and regtested on x86_64-pc-linux-gnu.
>
> Ok for trunk and gcc-5-branch?



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein

Re: [Patch, Fortran, pr70397, gcc-5, v1] [5/6 Regression] ice while allocating ultimate polymorphic

[Paul Richard Thomas]

Hi Andre,

The patch looks to be fine to me for both trunk and 5-branch.

Thanks for the patch.

Paul

On 27 March 2016 at 18:53, Andre Vehreschild  wrote:
> Hi all,
>
> and here is already the follow-up. In the initial patch a safe wasn't 
> commenced
> before pulling the patch, which lead to a refactoring of the new functions 
> node
> to be partial only. Sorry for the noise.
>
> - Andre
>
> Am Sun, 27 Mar 2016 18:49:18 +0200
> schrieb Andre Vehreschild :
>
>> Hi all,
>>
>> attached is a patch to fix an ICE on allocating an unlimited polymorphic
>> entity from a non-poly class or type without an length component. The routine
>> gfc_copy_class_to_class() assumed that both the source and destination
>> object's type is unlimited polymorphic, but in this case it is true for the
>> destination only, which made gfortran look for a non-existent _len component
>> in the source object and therefore ICE. This is fixed by the patch by adding
>> a function to return either the _len component, when it exists, or a constant
>> zero node to init the destination object's _len component with.
>>
>> Bootstrapped and regtested ok on x86_64-linux-gnu/F23. (Might have some
>> line deltas, because my git is a bit older. Sorry, only have limited/slow
>> net-access currently.)
>>
>> The same patch should be adaptable to trunk. To come...
>>
>> Ok for 5-trunk?
>>
>> Regards,
>>   Andre
>
>
>
> --
> Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
> Email: ve...@gmx.de * Tel: +49 241 9291018



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein

[PATCH] Fix PR tree-optimization/59124 (bogus -Warray-bounds warning)

[Patrick Palka]

In unrolling of the inner loop in the test case below we introduce
unreachable code that otherwise contains out-of-bounds array accesses.
This is because the estimation of the maximum number of iterations of
the inner loop is too conservative: we assume 6 iterations instead of
the actual 4.

Nonetheless, VRP should be able to tell that the code is unreachable so
that it doesn't warn about it.  The only thing holding VRP back is that
it doesn't look through conditionals of the form

   if (j_10 != CST1)where j_10 = j_9 + CST2

so that it could add the assertion

   j_9 != (CST1 - CST2)

This patch teaches VRP to detect such conditionals and to add such
assertions, so that it could remove instead of warn about the
unreachable code created during loop unrolling.

What this addition does with the test case below is something like this:

ASSERT_EXPR (i <= 5);
for (i = 1; i < 6; i++)
  {
j = i - 1;
if (j == 0)
  break;
// ASSERT_EXPR (i != 1)
bar[j] = baz[j];

j = i - 2
if (j == 0)
  break;
// ASSERT_EXPR (i != 2)
bar[j] = baz[j];

j = i - 3
if (j == 0)
  break;
// ASSERT_EXPR (i != 3)
bar[j] = baz[j];

j = i - 4
if (j == 0)
  break;
// ASSERT_EXPR (i != 4)
bar[j] = baz[j];

j = i - 5
if (j == 0)
  break;
// ASSERT_EXPR (i != 5)
bar[j] = baz[j];

j = i - 6
if (j == 0)
  break;
// ASSERT_EXPR (i != 6)
bar[j] = baz[j]; // unreachable because (i != 6 && i <= 5) is always false
  }

(I think the patch I sent a year ago that improved the
 register_edge_assert stuff would have fixed this too.  I'll try to
 post it again during next stage 1.
 https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00908.html)

Bootstrap + regtest in progress on x86_64-pc-linux-gnu, does this look
OK to commit after testing?

gcc/ChangeLog:

PR tree-optimization/59124
* tree-vrp.c (register_edge_assert_for): For NAME != CST1
where NAME = A + CST2 add the assertion A != (CST1 - CST2).

gcc/testsuite/ChangeLog:

PR tree-optimization/59124
* gcc.dg/Warray-bounds-19.c: New test.
---
 gcc/testsuite/gcc.dg/Warray-bounds-19.c | 17 +
 gcc/tree-vrp.c  | 22 ++
 2 files changed, 39 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/Warray-bounds-19.c

diff --git a/gcc/testsuite/gcc.dg/Warray-bounds-19.c 
b/gcc/testsuite/gcc.dg/Warray-bounds-19.c
new file mode 100644
index 000..e2f9661
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Warray-bounds-19.c
@@ -0,0 +1,17 @@
+/* PR tree-optimization/59124 */
+/* { dg-options "-O3 -Warray-bounds" } */
+
+unsigned baz[6];
+
+void foo(unsigned *bar, unsigned n)
+{
+  unsigned i, j;
+
+  if (n > 6)
+n = 6;
+
+  for (i = 1; i < n; i++)
+for (j = i - 1; j > 0; j--)
+  bar[j - 1] = baz[j - 1];
+}
+
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index b5654c5..31bd575 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -5820,6 +5820,28 @@ register_edge_assert_for (tree name, edge e, 
gimple_stmt_iterator si,
}
 }
 
+  /* In the case of NAME != CST1 where NAME = A + CST2 we can
+ assert that NAME != (CST1 - CST2).  */
+  if ((comp_code == EQ_EXPR || comp_code == NE_EXPR)
+  && TREE_CODE (val) == INTEGER_CST)
+{
+  gimple *def_stmt = SSA_NAME_DEF_STMT (name);
+
+  if (is_gimple_assign (def_stmt)
+ && gimple_assign_rhs_code (def_stmt) == PLUS_EXPR)
+   {
+ tree op0 = gimple_assign_rhs1 (def_stmt);
+ tree op1 = gimple_assign_rhs2 (def_stmt);
+ if (TREE_CODE (op0) == SSA_NAME
+ && TREE_CODE (op1) == INTEGER_CST)
+   {
+ op1 = int_const_binop (MINUS_EXPR, val, op1);
+ register_edge_assert_for_2 (op0, e, si, comp_code,
+ op0, op1, is_else_edge);
+   }
+   }
+}
+
   /* In the case of NAME == 0 or NAME != 1, for BIT_IOR_EXPR defining
  statement of NAME we can assert both operands of the BIT_IOR_EXPR
  have zero value.  */
-- 
2.8.0.rc3.27.gade0865

Re: [Patch, Fortran, pr70397, gcc-5, v1] [5/6 Regression] ice while allocating ultimate polymorphic

[Dominique d'Humières]

Andre,

In order to apply the patch on a recent trunk

@@ -1070,7 +1089,7 @@ gfc_copy_class_to_class (tree from, tree to, tree nelems, 
bool unlimited)
   if (unlimited)
 {
   if (from_class_base != NULL_TREE)
-   from_len = gfc_class_len_get (from_class_base);
+   from_len = gfc_class_len_or_zero_get (from_class_base);
   else
from_len = integer_zero_node;
 }
should be something such as

@@ -1120,7 +1142,7 @@ gfc_copy_class_to_class (tree from, tree
   if (unlimited)
 {
   if (from != NULL_TREE && unlimited)
-   from_len = gfc_class_len_get (from);
+   from_len = gfc_class_len_or_zero_get (from);
   else
from_len = integer_zero_node;
 }

With my patched tree I also see the regression

FAIL: gfortran.dg/coarray_allocate_4.f08  * (internal compiler error)

/opt/gcc/work/gcc/testsuite/gfortran.dg/coarray_allocate_4.f08:39:0:

allocate (z, source=x)
 
internal compiler error: tree check: expected record_type or union_type or 
qual_union_type, have void_type in gfc_class_len_or_zero_get, at 
fortran/trans-expr.c:186

Dominique

Re: [PATCH] Fix PR tree-optimization/59124 (bogus -Warray-bounds warning)

[Patrick Palka]

On Sun, 27 Mar 2016, Patrick Palka wrote:

> In unrolling of the inner loop in the test case below we introduce
> unreachable code that otherwise contains out-of-bounds array accesses.
> This is because the estimation of the maximum number of iterations of
> the inner loop is too conservative: we assume 6 iterations instead of
> the actual 4.
> 
> Nonetheless, VRP should be able to tell that the code is unreachable so
> that it doesn't warn about it.  The only thing holding VRP back is that
> it doesn't look through conditionals of the form
> 
>if (j_10 != CST1)where j_10 = j_9 + CST2
> 
> so that it could add the assertion
> 
>j_9 != (CST1 - CST2)
> 
> This patch teaches VRP to detect such conditionals and to add such
> assertions, so that it could remove instead of warn about the
> unreachable code created during loop unrolling.
> 
> What this addition does with the test case below is something like this:
> 
> ASSERT_EXPR (i <= 5);
> for (i = 1; i < 6; i++)
>   {
> j = i - 1;
> if (j == 0)
>   break;
> // ASSERT_EXPR (i != 1)
> bar[j] = baz[j];
> 
> j = i - 2
> if (j == 0)
>   break;
> // ASSERT_EXPR (i != 2)
> bar[j] = baz[j];
> 
> j = i - 3
> if (j == 0)
>   break;
> // ASSERT_EXPR (i != 3)
> bar[j] = baz[j];
> 
> j = i - 4
> if (j == 0)
>   break;
> // ASSERT_EXPR (i != 4)
> bar[j] = baz[j];
> 
> j = i - 5
> if (j == 0)
>   break;
> // ASSERT_EXPR (i != 5)
> bar[j] = baz[j];
> 
> j = i - 6
> if (j == 0)
>   break;
> // ASSERT_EXPR (i != 6)
> bar[j] = baz[j]; // unreachable because (i != 6 && i <= 5) is always false
>   }
> 
> (I think the patch I sent a year ago that improved the
>  register_edge_assert stuff would have fixed this too.  I'll try to
>  post it again during next stage 1.
>  https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00908.html)
> 
> Bootstrap + regtest in progress on x86_64-pc-linux-gnu, does this look
> OK to commit after testing?
> 
> gcc/ChangeLog:
> 
>   PR tree-optimization/59124
>   * tree-vrp.c (register_edge_assert_for): For NAME != CST1
>   where NAME = A + CST2 add the assertion A != (CST1 - CST2).
> 
> gcc/testsuite/ChangeLog:
> 
>   PR tree-optimization/59124
>   * gcc.dg/Warray-bounds-19.c: New test.
> ---
>  gcc/testsuite/gcc.dg/Warray-bounds-19.c | 17 +
>  gcc/tree-vrp.c  | 22 ++
>  2 files changed, 39 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.dg/Warray-bounds-19.c
> 
> diff --git a/gcc/testsuite/gcc.dg/Warray-bounds-19.c 
> b/gcc/testsuite/gcc.dg/Warray-bounds-19.c
> new file mode 100644
> index 000..e2f9661
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/Warray-bounds-19.c
> @@ -0,0 +1,17 @@
> +/* PR tree-optimization/59124 */
> +/* { dg-options "-O3 -Warray-bounds" } */
> +
> +unsigned baz[6];
> +
> +void foo(unsigned *bar, unsigned n)
> +{
> +  unsigned i, j;
> +
> +  if (n > 6)
> +n = 6;
> +
> +  for (i = 1; i < n; i++)
> +for (j = i - 1; j > 0; j--)
> +  bar[j - 1] = baz[j - 1];
> +}
> +
> diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
> index b5654c5..31bd575 100644
> --- a/gcc/tree-vrp.c
> +++ b/gcc/tree-vrp.c
> @@ -5820,6 +5820,28 @@ register_edge_assert_for (tree name, edge e, 
> gimple_stmt_iterator si,
>   }
>  }
>  
> +  /* In the case of NAME != CST1 where NAME = A + CST2 we can
> + assert that NAME != (CST1 - CST2).  */

This should say A != (...) not NAME != (...)

> +  if ((comp_code == EQ_EXPR || comp_code == NE_EXPR)
> +  && TREE_CODE (val) == INTEGER_CST)
> +{
> +  gimple *def_stmt = SSA_NAME_DEF_STMT (name);
> +
> +  if (is_gimple_assign (def_stmt)
> +   && gimple_assign_rhs_code (def_stmt) == PLUS_EXPR)
> + {
> +   tree op0 = gimple_assign_rhs1 (def_stmt);
> +   tree op1 = gimple_assign_rhs2 (def_stmt);
> +   if (TREE_CODE (op0) == SSA_NAME
> +   && TREE_CODE (op1) == INTEGER_CST)
> + {
> +   op1 = int_const_binop (MINUS_EXPR, val, op1);
> +   register_edge_assert_for_2 (op0, e, si, comp_code,
> +   op0, op1, is_else_edge);

The last argument to register_edge_assert_for_2() should be false not
is_else_edge since comp_code is already inverted.

Consider these two things fixed.  Also I moved down the new code so that
it's at the very bottom of register_edge_assert_for.  Here's an updated
patch that passes bootstrap + regtest.

-- 8< --

gcc/ChangeLog:

PR tree-optimization/59124
* tree-vrp.c (register_edge_assert_for): For NAME != CST1
where NAME = A + CST2 add the assertion A != (CST1 - CST2).

gcc/testsuite/ChangeLog:

PR tree-optimization/59124
* gcc.dg/Warray-bounds-19.c: New test.
---
 gcc/testsuite/gcc.dg/Warray-bounds-19.c | 17 +
 gcc/tree-vrp.c  | 22 ++
 2 files changed, 39 insertions(+)
 create mod

Re: [DOC Patch] Add sample for @cc constraint

[David Wohlferd]

Thanks for the feedback.  While I agree with some of this, there are 
parts that I want to defend.  If after explaining why I did what I did 
you still feel it should be changed, I'm prepared to do that.


On 3/24/2016 8:00 AM, Bernd Schmidt wrote:
> More problematic than a lack of documentation is that I haven't been 
able to find an executable testcase. If you could adapt your example for 
use in gcc.target/i386, that would be even more important.


It looks like Richard included some "scan-assembler" statements in the 
suites with the original checkin 
(https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=225122). Is that 
not sufficient?  If not, I'm certainly prepared to create a couple 
executable cases for the next rev of this patch.


>> +Do not clobber flags if they are being used as outputs.
>
> I don't think the manual should point out the obvious. I'd be 
surprised if this wasn't documented or at least strongly implied 
elsewhere for normal operands.


Well, *I* thought it was obvious, because it is both documented and 
implied elsewhere.


However, the compiler doesn't see it that way.  Normally, attempting to 
overlap 'clobbers' and 'outputs' generates compile errors, but not when 
outputting and clobbering flags.  I filed pr68095 about this (including 
a rough draft at a patch), but apparently not everyone sees this the way 
I do.


Outputting flags is new to v6, so changing the compiler to reject 
overlaps before the feature is ever released would be ideal.  If we try 
to patch this in v7, will it get rejected because it would break 
backward compatibility?


If we aren't going to change the code, then I decided it needed to be 
hammered home in the docs.  Because someday someone is going to want to 
do something more with flags, but they won't be able to because it will 
break backward compatibility with all the people who have written this 
the "obviously wrong" way.  Hopefully this text will serve as 
justification for that future someone to do it anyway.


That said, I'm ok with any of:

1) Leave this text in.
2) Remove the text and add the compiler check to v6.
3) Remove the text and add the compiler check to v7.
4) Leave the text in v6, then in v7: remove the text and add the 
compiler check.

5) (Reluctantly) remove the text and hope this never becomes a problem.

I'll update the patch with whichever option seems best.  If it were my 
choice to make, I'd go with #4 (followed by 3, 1, 5).  2 would actually 
be the best, but probably isn't realistic at this late date.


>> +For builds that don't support flag output operands,
>
> This feels strange, we should just be documenting the capabilities of 
this feature. Other parts of the docs already show what to do without it.


While I liked using the #define to contrast how this used to work (not 
sure where you think we show this?) with how the feature makes things 
better, I think I prefer the shorter example you are proposing.  I'll 
change this in the next rev of the patch.


>> +Note: On the x86 platform, flags are normally considered clobbered by
>> +extended asm whether the @code{"cc"} clobber is specified or not.
>
> Is it really necessary or helpful to mention that here? Not only is 
it not strictly correct (an output operand is not also considered 
clobbered), but to me it breaks the flow because you're left wondering 
how that sentence relates to the example (it doesn't).


The problem I am trying to fix here is that on x86, the "cc" is implicit 
for all extended asm statements, whether it is specified or not and 
whether there is a flags output or not.  However, that fact isn't 
documented anywhere.  So, where does that info go?  It could go right by 
the docs for "cc", but since this behavior only applies to x86, that 
would make the docs there messy.


Since the 'output flags' section already has an x86-specific section, 
that seemed like a plausible place to put it.  But no matter where I put 
it in that section, it always looks weird for exactly the reasons you state.


I'll try moving it up by the "cc" clobber in the next rev.  Let me know 
what you think.


>> +For platform-specific uses of flags, see also
>> +@ref{FlagOutputOperands,Flag Output Operands}.
>
> Is this likely to be helpful? Someone who's looking at how to use 
flag outputs probably isn't looking in the "Clobbers" section?


People reading about "cc" may be interested in knowing that you can do 
something with flags other than clobbering them.  And of course this 
lets us put the note about "x86 always clobbers flags" in that other 
section.


dw

Re: Patches to fix GCC's C++ exception_handling on NetBSD/VAX

[Jake Hamby]

Thank you for the offer. I already tested it on an Amiga 3000 w/ 68040 card 
when I made the fix. The bug manifested as the cross-compiler crashing with a 
failure to find a suitable insn, because it couldn’t find the correct FP 
instruction to expand to. I believe it manifested when running ./build.sh 
release with “-m68040” set in CPUFLAGS. I will test it myself and see if it’s 
still an issue without the patch. If you look at the .md file, there’s an 
entirely different code path to generate the same instructions when 
"TARGET_68881 && TUNE_68040" aren't defined.

At the time I made the change, I had already been testing the code on an Amiga 
3000 w/ 68040 card, so I know that the generated code is likely correct (also, 
the assembler accepted it). So I’m assuming that it’s a fairly safe thing. It 
was the difference between the build succeeding or failing, and not an issue 
with the generated code.

So the only thing I can suggest is that you can try a build with the patch and 
make sure it's stable. I was never able to produce a build without it, because 
"TARGET_68881 && TUNE_68040" was excluding the other choices when building, I 
believe, libm or libc or the kernel or something like that. I do have a test 
case for C++ exceptions on VAX, which I will send separately.

Thanks,
Jake


> On Mar 27, 2016, at 10:08, Mikael Pettersson  wrote:
> 
> Jake Hamby writes:
>> As an added bonus, I see that my patch set also included an old m68k patch
>> that had been sitting in my tree, which fixes a crash when -m68040 is 
>> defined.
>> I may have submitted it to port-m68k before. It hasn't been tested with the
>> new compiler either. Here's that patch separately. It only matter when
>> TARGET_68881 && TUNE_68040.
> 
> Do you have a test case or some recipe for reproducing the crash?
> I'd be happy to test this patch on Linux/M68K.
> 
> /Mikael
> 
>> 
>> -Jake
>> 
>> 
>> Index: external/gpl3/gcc/dist/gcc/config/m68k/m68k.md
>> 
>> RCS file: /cvsroot/src/external/gpl3/gcc/dist/gcc/config/m68k/m68k.md,v
>> retrieving revision 1.4
>> diff -u -u -r1.4 m68k.md
>> --- external/gpl3/gcc/dist/gcc/config/m68k/m68k.md   24 Jan 2016 09:43:33 
>> -  1.4
>> +++ external/gpl3/gcc/dist/gcc/config/m68k/m68k.md   26 Mar 2016 10:42:41 
>> -
>> @@ -2132,9 +2132,9 @@
>> ;; into the kernel to emulate fintrz.  They should also be faster
>> ;; than calling the subroutines fixsfsi or fixdfsi.
>> 
>> -(define_insn "fix_truncdfsi2"
>> +(define_insn "fix_truncsi2"
>>   [(set (match_operand:SI 0 "nonimmediate_operand" "=dm")
>> -(fix:SI (fix:DF (match_operand:DF 1 "register_operand" "f"
>> +(fix:SI (match_operand:FP 1 "register_operand" "f")))
>>(clobber (match_scratch:SI 2 "=d"))
>>(clobber (match_scratch:SI 3 "=d"))]
>>   "TARGET_68881 && TUNE_68040"
>> @@ -2143,9 +2143,9 @@
>>   return "fmovem%.l %!,%2\;moveq #16,%3\;or%.l %2,%3\;and%.w 
>> #-33,%3\;fmovem%.l %3,%!\;fmove%.l %1,%0\;fmovem%.l %2,%!";
>> })
>> 
>> -(define_insn "fix_truncdfhi2"
>> +(define_insn "fix_trunchi2"
>>   [(set (match_operand:HI 0 "nonimmediate_operand" "=dm")
>> -(fix:HI (fix:DF (match_operand:DF 1 "register_operand" "f"
>> +(fix:HI (match_operand:FP 1 "register_operand" "f")))
>>(clobber (match_scratch:SI 2 "=d"))
>>(clobber (match_scratch:SI 3 "=d"))]
>>   "TARGET_68881 && TUNE_68040"
>> @@ -2154,9 +2154,9 @@
>>   return "fmovem%.l %!,%2\;moveq #16,%3\;or%.l %2,%3\;and%.w 
>> #-33,%3\;fmovem%.l %3,%!\;fmove%.w %1,%0\;fmovem%.l %2,%!";
>> })
>> 
>> -(define_insn "fix_truncdfqi2"
>> +(define_insn "fix_truncqi2"
>>   [(set (match_operand:QI 0 "nonimmediate_operand" "=dm")
>> -(fix:QI (fix:DF (match_operand:DF 1 "register_operand" "f"
>> +(fix:QI (match_operand:FP 1 "register_operand" "f")))
>>(clobber (match_scratch:SI 2 "=d"))
>>(clobber (match_scratch:SI 3 "=d"))]
>>   "TARGET_68881 && TUNE_68040"
> 
> -- 

Re: Patches to fix GCC’s C++ exception handling on NetBSD/VAX

[Jake Hamby]

I'm very pleased to report that I was able to successfully build a NetBSD/vax 
system using the checked-in GCC 5.3, with the patches I've submitted, setting 
FIRST_PSEUDO_REGISTER to 17 and DWARF_FRAME_REGISTERS to 16. The kernel 
produced with GCC 5.3 crashes (on a real VS4000/90 and also SimH) in UVM, which 
may be a bug in the kernel that different optimization exposed, or a bug in 
GCC's generated code.

If you don't set DWARF_FRAME_REGISTERS to 16, then C++ exceptions break again, 
and GDB suddenly can't deal with the larger debug frames because of the data 
structure size mismatch between GCC and GDB. But with that additional define, 
you can raise FIRST_PSEUDO_REGISTER to include PSW (which is correct, since 
DWARF already uses that meaning), remove the "#ifdef notworking" around the 
asserts that Christos added in the NetBSD tree, and everything works as well as 
it did with #define FIRST_PSEUDO_REGISTER 16.

Here's the C++ test case I've been using to verify that the stack unwinding 
works and that different simple types can be thrown and caught. My ultimate 
goal is to be able to run GCC's testsuite because I'm far from certain that the 
OS, or even the majority of packages, really exercise all of the different 
paths in this very CISC architecture.

#include 
#include 

int recursive_throw(int i) {
  printf("enter recursive_throw(%d)\n", i);
  if (i > 0) {
printf("calling recursive_throw(%d)\n", i - 1);
recursive_throw(i - 1);
  } else {
printf("throwing exception\n");
throw 456;
  }
  printf("exit recursive_throw(%d)\n", i);
}

/* Test several kinds of throws. */
int throwtest(int test) {
  switch (test) {
case 0:
case 1:
  return test;

case 2:
  throw 123;

case 3:
  throw 123.45;

case 4:
  throw 678.9f;

case 5:
  recursive_throw(6);
  return 666;  // fail

default:
  return 999;  // not used in test
  }
}

int main() {
  for (int i = 0; i < 6; i++) {
try {
  int ret = throwtest(i);
  printf("throwtest(%d) returned %d\n", i, ret);
} catch (int e) {
  printf("Caught int exception: %d\n", e);
} catch (double d) {
  printf("Caught double exception: %f\n", d);
} catch (float f) {
  printf("Caught float exception: %f\n", (double)f);
}
  }
}

I'm pleased that I got it working, but the change I made to except.c to add:

RTX_FRAME_RELATED_P (insn) = 1;

below:

#ifdef EH_RETURN_HANDLER_RTX
  rtx insn = emit_move_insn (EH_RETURN_HANDLER_RTX, crtl->eh.ehr_handler);

isn't really correct, I don't think. It adds an additional .cfi directive that 
wasn't there before, and a GCC ./buildsh release fails building unwind-dw2.c 
(that's the place where the build either succeeds or fails or generates bad 
code) if you try to compile with assertions (and it doesn't without my change 
to except.c).

Unfortunately, I don't have a patch for the root cause for me having to add 
that line to except.c, which is that the required mov instruction to copy the 
__builtin_eh_return() return address into the old stack frame is being deleted 
for some reason, otherwise. Since I know the #ifdef EH_RETURN_HANDLER_RTX line 
*is* staying in the final code on other archs, I presume the problem is 
something VAX-related in the .md file.

If anyone knows about GCC's liveness detection, and specifically any potential 
problems that might cause this to be happening (removing a required 
"emit_move_insn (EH_RETURN_HANDLER_RTX, ...)" before a return call that was 
added in expand_eh_return () but then deleted if -O or higher is used), any 
advice would be appreciated as to where to look.

What I'm working on now is cleaning up and refactoring the .md insn 
definitions, but I'm not ready to share that code until it works and does 
something useful. I'm hoping to be able to optimize the removal of unneeded tst 
/ cmp instructions when the condition codes have been set to something useful 
by a previous insn. I don't think the code in vax_notice_update_cc () is 
necessarily correct, and it's very difficult to understand exactly how it's 
working, because it's trying to determine this based entirely on looking at the 
RTL of the insn (set, call, zero_extract, etc), which I think may have become 
out of sync with the types of instructions that are actually emitted in vax.md 
for those operations.

So I've just finished tagging the define_insn calls in vax.md with a "cc" 
attribute (like the avr backend) which my (hopefully more correct and more 
optimized) version of vax_notice_update_cc will use to know exactly what the 
flag status is after the insn, for Z, N, and C. Here's my definition of "cc". 
I'll share the rest after I'm sure that it works.

;; Condition code settings.  On VAX, the default value is "clobber".
;; The V flag is often set to zero, or else it has a special meaning,
;; usually related to testing for a signed integer range overflow.
;; "cmp_czn", "cmp_zn", and "cmp_z" are all assumed to modify V, and
;; no

Re: [PATCH] Fix PR tree-optimization/59124 (bogus -Warray-bounds warning)

[Patrick Palka]

On Sun, Mar 27, 2016 at 2:58 PM, Patrick Palka  wrote:
> In unrolling of the inner loop in the test case below we introduce
> unreachable code that otherwise contains out-of-bounds array accesses.
> This is because the estimation of the maximum number of iterations of
> the inner loop is too conservative: we assume 6 iterations instead of
> the actual 4.
>
> Nonetheless, VRP should be able to tell that the code is unreachable so
> that it doesn't warn about it.  The only thing holding VRP back is that
> it doesn't look through conditionals of the form
>
>if (j_10 != CST1)where j_10 = j_9 + CST2
>
> so that it could add the assertion
>
>j_9 != (CST1 - CST2)
>
> This patch teaches VRP to detect such conditionals and to add such
> assertions, so that it could remove instead of warn about the
> unreachable code created during loop unrolling.
>
> What this addition does with the test case below is something like this:
>
> ASSERT_EXPR (i <= 5);
> for (i = 1; i < 6; i++)
>   {
> j = i - 1;
> if (j == 0)
>   break;
> // ASSERT_EXPR (i != 1)
> bar[j] = baz[j];
>
> j = i - 2
> if (j == 0)
>   break;
> // ASSERT_EXPR (i != 2)
> bar[j] = baz[j];
>
> j = i - 3
> if (j == 0)
>   break;
> // ASSERT_EXPR (i != 3)
> bar[j] = baz[j];
>
> j = i - 4
> if (j == 0)
>   break;
> // ASSERT_EXPR (i != 4)
> bar[j] = baz[j];
>
> j = i - 5
> if (j == 0)
>   break;
> // ASSERT_EXPR (i != 5)
> bar[j] = baz[j];
>
> j = i - 6
> if (j == 0)
>   break;
> // ASSERT_EXPR (i != 6)
> bar[j] = baz[j]; // unreachable because (i != 6 && i <= 5) is always false
>   }

Er, sorry, this illustration is wrong.  First off, break; should say
continue;.  Second, we actually find that the second-to-last bar[j] =
baz[j]; assignment is unreachable, since VRP can use the ASSERT_EXPRs
to determine that i == 5 when evaluating the conditional immediately
preceding the second-to-last array access.  And because the
second-to-last assignment is unreachable then so is the last
assignment.  So we remove two unreachable array accesses (and their
enclosing basic blocks) and thus suppress the two -Warray-bounds
warnings.

Re: Patches to fix GCC’s C++ exception handling on NetBSD/VAX

[Jake Hamby]

The results you want to see for the test program are the following:

throwtest(0) returned 0
throwtest(1) returned 1
Caught int exception: 123
Caught double exception: 123.45
Caught float exception: 678.900024
enter recursive_throw(6)
calling recursive_throw(5)
enter recursive_throw(5)
calling recursive_throw(4)
enter recursive_throw(4)
calling recursive_throw(3)
enter recursive_throw(3)
calling recursive_throw(2)
enter recursive_throw(2)
calling recursive_throw(1)
enter recursive_throw(1)
calling recursive_throw(0)
enter recursive_throw(0)
throwing exception
Caught int exception: 456

Before I made the changes I've submitted, this worked on m68k and presumably 
everywhere else but VAX. On VAX, it crashed due to the pointer size 
discrepancies that I already talked about. I believe that it should be possible 
to improve GCC's backend by allowing %ap to be used as an additional general 
register (removing it from FIXED_REGISTERS, but leaving it in 
CALL_USED_REGISTERS, since it's modified on CALLS), without breaking the DWARF 
stack unwinding stuff, since the .cfi information it's emitting notes the 
correct %fp offset to find the frame, which it actually uses instead of the %ap 
in stack unwinding.

Gaining an additional general register to use within a function would be a nice 
win if it worked. But there are at two problems that must be solved before 
doing this (that I know of). The first is that certain combinations of VAX 
instructions and addressing modes seem to have problems when %ap, %fp, and/or 
%sp are used. I discovered this in the OpenVMS VAX Macro reference (which is 
essentially an updated version of the 1977 VAX architecture handbook), in Table 
8-5, General Register Addressing.

An additional source of info on which modes fail with address faults when AP or 
above is used, SimH's vax_cpu.c correctly handles this, and you can trace these 
macros to find the conditions:

#define CHECK_FOR_PCif (rn == nPC) \
RSVD_ADDR_FAULT
#define CHECK_FOR_SPif (rn >= nSP) \
RSVD_ADDR_FAULT
#define CHECK_FOR_APif (rn >= nAP) \
RSVD_ADDR_FAULT

So as long as the correct code is added to vax.md and vax.c to never emit move 
instructions under the wrong circumstances when %ap is involved, it could be 
used as a general register. I wonder if the use of %ap to find address 
arguments is a special case that happens to never emit anything that would fail 
(with a SIGILL, I believe).

But the other problem with making %ap available as a general (with a few 
special cases) register is that it would break one part of the patch I 
submitted at the beginning of the thread to fix C++ exceptions. One necessary 
part of that fix was to change "#define FRAME_POINTER_CFA_OFFSET(FNDECL) 0" to 
"#define ARG_POINTER_CFA_OFFSET(FNDECL) 0", which correctly generates the code 
to return the value for __builtin_dwarf_cfa () (as an offset of 0 from %ap).

When I was working on that fix, it seemed like it should be possible, since the 
DWARF / CFA code that's in there now is using an offset from %fp that it knows, 
that an improved fix would define FRAME_POINTER_CFA_OFFSET(FNDECL) as something 
that knows how to return the current CFA (canonical frame address) as an offset 
from %fp, since that's what it's using for all the .cfi_* directives. But I 
don't know what a correct definition of FRAME_POINTER_CFA_OFFSET should be in 
order for it to return that value, instead of 0, because I know that a 0 offset 
from %fp is definitely wrong, and it's not a fixed offset either (it depends on 
the number of registers saved in the procedure entry mask). Fortunately, %ap 
points directly to CFA, so that always works.

Just some thoughts on future areas for improval... I'm very happy to be able to 
run the NetBSD testsuite on VAX now. It gives me a lot of confidence as to what 
works and what doesn't. Most of the stuff I expected to fail (like libm tests, 
since it's not IEEE FP) failed, and most of the rest succeeded.

-Jake


> On Mar 27, 2016, at 15:34, Jake Hamby  wrote:
> 
> I'm very pleased to report that I was able to successfully build a NetBSD/vax 
> system using the checked-in GCC 5.3, with the patches I've submitted, setting 
> FIRST_PSEUDO_REGISTER to 17 and DWARF_FRAME_REGISTERS to 16. The kernel 
> produced with GCC 5.3 crashes (on a real VS4000/90 and also SimH) in UVM, 
> which may be a bug in the kernel that different optimization exposed, or a 
> bug in GCC's generated code.
> 
> If you don't set DWARF_FRAME_REGISTERS to 16, then C++ exceptions break 
> again, and GDB suddenly can't deal with the larger debug frames because of 
> the data structure size mismatch between GCC and GDB. But with that 
> additional define, you can raise FIRST_PSEUDO_REGISTER to include PSW (which 
> is correct, since DWARF already uses that meaning), remove the "#ifdef 
> notworking" around the asserts that Christos added in the NetBSD tree, and 
> 

Re: C++ PATCH for c++/70353 (core issue 1962)

[Segher Boessenkool]

On Fri, Mar 25, 2016 at 05:29:26PM -0400, Jason Merrill wrote:
> 70353 is a problem with the function-local static declaration of 
> __func__.  Normally constexpr functions can't have local statics, so 
> this is only an issue with __func__.  Meanwhile, core issue 1962 looks 
> like it's going to be resolved by changing __func__ et al to be prvalue 
> constants of type const char * rather than static local array variables, 
> so implementing that proposed resolution also resolves this issue, as 
> well as 62466 which complains about the strings not being merged between 
> translation units.  This patch proceeds from Martin's work last year.
> 
> Tested x86_64-pc-linux-gnu, applying to trunk.

This patch caused PR70422, a bootstrap comparison failure on aarch64,
ia64, and powerpc64.


Segher

Re: rs6000 stack_tie mishap again

[Segher Boessenkool]

On Wed, Mar 23, 2016 at 05:04:39PM +0100, Olivier Hainque wrote:
> The visible effect is a powerpc-eabispe compiler (no red-zone) producing an
> epilogue sequence like
> 
>addi %r11,%r1,184# temp pointer within frame

The normal -m32 compiler here generates code like

lwz 11,0(1)

and try as I might I cannot get it to fail.  Maybe because the GPR11
setup here involves a load?

>addi %r1,%r11,104# release frame
> 
>evldd %r21,16(%r11)  # restore registers
>...  # ...
>evldd %r31,96(%r11)  # ...
> 
>blr  # return

> We have observed this with a gcc 4.7 back-end and weren't able to reproduce
> with a more recent version.

This makes it not a regression and thus out of scope for GCC 6.  We're
supposed to stabilise things now ;-)

>   if (! writep)
> {
>   base = find_base_term (mem_addr);
>   if (base && (GET_CODE (base) == LABEL_REF
>  || (GET_CODE (base) == SYMBOL_REF
>  && CONSTANT_POOL_ADDRESS_P (base
>   return 0;
> }
> 
> 
> with
> 
> (gdb) pr mem_addr
> (plus:SI (reg:SI 11 11)
> (const_int 96 [0x60]))
>  
> and
>  
> (gdb) pr base
> (symbol_ref/u:SI ("*.LC0") [flags 0x82])
>  
> coming from insn 710, despite 894 in between. Ug.

Yeah that is just Wrong.

> The reason why 894 is not accounted in the base ref computation is because it
> is part of the epilogue sequence, and init_alias_analysis has:
> 
>   /* Walk the insns adding values to the new_reg_base_value array.  */
>   for (i = 0; i < rpo_cnt; i++)
>   { ...
> if (could_be_prologue_epilogue
> && prologue_epilogue_contains (insn))
>   continue;
> 
> The motivation for this is unclear to me.

Alan linked to the history.  It seems clear that just considering the
prologue is enough to fix the original problem (frame pointer setup),
and problems like yours cannot happen in the prologue.

Better would be not to have this hack at all.

> My rough understanding is that we probably really care about frame_related
> insns only here, at least on targets where the flag is supposed to be set
> accurately.

On targets with DWARF2 unwind info the flag should be set on those insns
that need unwind info.  This does not include all insns in the epilogue
that access the frame, so I don't think this will help you?

> This is the basis of the proposed patch, which essentially disconnects the
> shortcut above for !frame_related insns on targets which need precise alias
> analysis within epilogues, as indicated by a new target hook.

Eww.  Isn't that really all targets that schedule the epilogue at all?

> On the key insn at hand, the frame_related bit was cleared on purpose,
> per:
> 
> https://gcc.gnu.org/ml/gcc-patches/2011-11/msg00543.html
> 
>   "1) Marking an instruction setting up r11 for use by _save64gpr_* as
>frame-related results in r11 being set as the cfa for the rest of the
>function.  That's bad when r11 gets used for other things later.
>   "

And that is correct.

> So, aside from the dependency issue which needs to be fixed somehow, I
> think it would make sense to consider using a strong blockage mecanism in
> expand_epilogue.

It would be very nice if we could directly express "the set of GPR1 should
stay behind any frame accesses", yeah.


Segher

[PATCH] gcc/final.c: -fdebug-prefix-map support to remap sources with relative path

[Hongxu Jia]

PR other/70428
* final.c (remap_debug_filename): Use lrealpath to translate
relative path before remapping

Signed-off-by: Hongxu Jia 
---
 gcc/ChangeLog |  6 ++
 gcc/final.c   | 15 ---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index f02e3d8..8b7207c 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -26,6 +26,12 @@
in all constraint alternatives.
(movtd_64bit_nodm): Delete "j" constraint alternative.
 
+2016-03-24  Hongxu Jia  
+
+   PR other/70428
+   * final.c (remap_debug_filename): Use lrealpath to translate
+   relative path before remapping
+
 2016-03-24  Aldy Hernandez  
 
* tree-ssa-propagate.c: Enhance docs for
diff --git a/gcc/final.c b/gcc/final.c
index 55cf509..23293e5 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -1554,16 +1554,25 @@ remap_debug_filename (const char *filename)
   const char *name;
   size_t name_len;
 
+  /* Support to remap filename with relative path  */
+  char *realpath = lrealpath (filename);
+  if (realpath == NULL)
+return filename;
+
   for (map = debug_prefix_maps; map; map = map->next)
-if (filename_ncmp (filename, map->old_prefix, map->old_len) == 0)
+if (filename_ncmp (realpath, map->old_prefix, map->old_len) == 0)
   break;
   if (!map)
-return filename;
-  name = filename + map->old_len;
+{
+  free (realpath);
+  return filename;
+}
+  name = realpath + map->old_len;
   name_len = strlen (name) + 1;
   s = (char *) alloca (name_len + map->new_len);
   memcpy (s, map->new_prefix, map->new_len);
   memcpy (s + map->new_len, name, name_len);
+  free (realpath);
   return ggc_strdup (s);
 }
 
-- 
2.7.4

[PATCH 2/4] Don't cause ICEs when auto profile file is not found with checking

[Andi Kleen]

From: Andi Kleen 

Currently, on a checking enabled compiler when -fauto-profile does
not find the profile feedback file it errors out with assertation
failures. Add proper errors for this case.

gcc/:

2016-03-27  Andi Kleen  

* auto-profile.c (read_profile): Replace asserts with errors
when file does not exist.
* gcov-io.c (gcov_read_words): Dito.
---
 gcc/auto-profile.c | 32 +---
 gcc/gcov-io.c  |  4 +++-
 2 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/gcc/auto-profile.c b/gcc/auto-profile.c
index 5c0640a..5cb94a6 100644
--- a/gcc/auto-profile.c
+++ b/gcc/auto-profile.c
@@ -887,16 +887,25 @@ static void
 read_profile (void)
 {
   if (gcov_open (auto_profile_file, 1) == 0)
-error ("Cannot open profile file %s.", auto_profile_file);
+{
+  error ("Cannot open profile file %s.", auto_profile_file);
+  return;
+}
 
   if (gcov_read_unsigned () != GCOV_DATA_MAGIC)
-error ("AutoFDO profile magic number does not mathch.");
+{
+  error ("AutoFDO profile magic number does not mathch.");
+  return;
+}
 
   /* Skip the version number.  */
   unsigned version = gcov_read_unsigned ();
   if (version != AUTO_PROFILE_VERSION)
-error ("AutoFDO profile version %u does match %u.",
-   version, AUTO_PROFILE_VERSION);
+{
+  error ("AutoFDO profile version %u does match %u.",
+version, AUTO_PROFILE_VERSION);
+  return;
+}
 
   /* Skip the empty integer.  */
   gcov_read_unsigned ();
@@ -904,19 +913,28 @@ read_profile (void)
   /* string_table.  */
   afdo_string_table = new string_table ();
   if (!afdo_string_table->read())
-error ("Cannot read string table from %s.", auto_profile_file);
+{
+  error ("Cannot read string table from %s.", auto_profile_file);
+  return;
+}
 
   /* autofdo_source_profile.  */
   afdo_source_profile = autofdo_source_profile::create ();
   if (afdo_source_profile == NULL)
-error ("Cannot read function profile from %s.", auto_profile_file);
+{
+  error ("Cannot read function profile from %s.", auto_profile_file);
+  return;
+}
 
   /* autofdo_module_profile.  */
   fake_read_autofdo_module_profile ();
 
   /* Read in the working set.  */
   if (gcov_read_unsigned () != GCOV_TAG_AFDO_WORKING_SET)
-error ("Cannot read working set from %s.", auto_profile_file);
+{
+  error ("Cannot read working set from %s.", auto_profile_file);
+  return;
+}
 
   /* Skip the length of the section.  */
   gcov_read_unsigned ();
diff --git a/gcc/gcov-io.c b/gcc/gcov-io.c
index 17fcae0..95ead22 100644
--- a/gcc/gcov-io.c
+++ b/gcc/gcov-io.c
@@ -493,7 +493,9 @@ gcov_read_words (unsigned words)
   const gcov_unsigned_t *result;
   unsigned excess = gcov_var.length - gcov_var.offset;
 
-  gcov_nonruntime_assert (gcov_var.mode > 0);
+  if (gcov_var.mode <= 0)
+return NULL;
+
   if (excess < words)
 {
   gcov_var.start += gcov_var.offset;
-- 
2.7.3

[PATCH 1/4] Add gcc-auto-profile script

[Andi Kleen]

From: Andi Kleen 

Using autofdo is currently something difficult. It requires using the
model specific branches taken event, which differs on different CPUs.
The example shown in the manual requires a special patched version of
perf that is non standard, and also will likely not work everywhere.

This patch adds a new gcc-auto-profile script that figures out the
correct event and runs perf. The script is installed with on Linux systems.

Since maintaining the script would be somewhat tedious (needs changes
every time a new CPU comes out) I auto generated it from the online
Intel event database. The script to do that is in contrib and can be
rerun.

Right now there is no test if perf works in configure. This
would vary depending on the build and target system, and since
it currently doesn't work in virtualization and needs uptodate
kernel it may often fail in common distribution build setups.

So Linux just hardcodes installing the script, but it may fail at runtime.

This is needed to actually make use of autofdo in a generic way
in the build system and in the test suite.

So far the script is not installed.

gcc/:
2016-03-27  Andi Kleen  

* doc/invoke.texi: Document gcc-auto-profile
* gcc-auto-profile: Create.

contrib/:

2016-03-27  Andi Kleen  

* gen_autofdo_event.py: New file to regenerate
gcc-auto-profile.
---
 contrib/gen_autofdo_event.py | 155 +++
 gcc/doc/invoke.texi  |  31 +++--
 gcc/gcc-auto-profile |  70 +++
 3 files changed, 251 insertions(+), 5 deletions(-)
 create mode 100755 contrib/gen_autofdo_event.py
 create mode 100755 gcc/gcc-auto-profile

diff --git a/contrib/gen_autofdo_event.py b/contrib/gen_autofdo_event.py
new file mode 100755
index 000..db4db33
--- /dev/null
+++ b/contrib/gen_autofdo_event.py
@@ -0,0 +1,155 @@
+#!/usr/bin/python
+# generate Intel taken branches Linux perf event script for autofdo profiling
+
+# Copyright (C) 2016 Free Software Foundation, Inc.
+#
+# GCC is free software; you can redistribute it and/or modify it under
+# the terms of the GNU General Public License as published by the Free
+# Software Foundation; either version 3, or (at your option) any later
+# version.
+#
+# GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+# WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+# for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .  */
+
+# run it with perf record -b -e EVENT program ...
+# The Linux Kernel needs to support the PMU of the current CPU, and
+# it will likely not work in VMs.
+# add --all to print for all cpus, otherwise for current cpu
+# add --script to generate shell script to run correct event
+#
+# requires internet (https) access. this may require setting up a proxy
+# with export https_proxy=...
+#
+import urllib2
+import sys
+import json
+import argparse
+import collections
+
+baseurl = "https://download.01.org/perfmon";
+
+target_events = (u'BR_INST_RETIRED.NEAR_TAKEN',
+ u'BR_INST_EXEC.TAKEN',
+ u'BR_INST_RETIRED.TAKEN_JCC',
+ u'BR_INST_TYPE_RETIRED.COND_TAKEN')
+
+ap = argparse.ArgumentParser()
+ap.add_argument('--all', '-a', help='Print for all CPUs', action='store_true')
+ap.add_argument('--script', help='Generate shell script', action='store_true')
+args = ap.parse_args()
+
+eventmap = collections.defaultdict(list)
+
+def get_cpu_str():
+with open('/proc/cpuinfo', 'r') as c:
+vendor, fam, model = None, None, None
+for j in c:
+n = j.split()
+if n[0] == 'vendor_id':
+vendor = n[2]
+elif n[0] == 'model' and n[1] == ':':
+model = int(n[2])
+elif n[0] == 'cpu' and n[1] == 'family':
+fam = int(n[3])
+if vendor and fam and model:
+return "%s-%d-%X" % (vendor, fam, model), model
+return None, None
+
+def find_event(eventurl, model):
+print >>sys.stderr, "Downloading", eventurl
+u = urllib2.urlopen(eventurl)
+events = json.loads(u.read())
+u.close()
+
+found = 0
+for j in events:
+if j[u'EventName'] in target_events:
+event = "cpu/event=%s,umask=%s/" % (j[u'EventCode'], j[u'UMask'])
+if u'PEBS' in j and j[u'PEBS'] > 0:
+event += "p"
+if args.script:
+eventmap[event].append(model)
+else:
+print j[u'EventName'], "event for model", model, "is", event
+found += 1
+return found
+
+if not args.all:
+cpu, model = get_cpu_str()
+if not cpu:
+sys.exit("Unknown CPU type")
+
+url = baseurl + "/mapfile.csv"
+print >>sys.stderr, "Downloading", url
+u = urllib2.url

[PATCH 3/4] Run profile feedback tests with autofdo

[Andi Kleen]

From: Andi Kleen 

Extend the existing bprob and tree-prof tests to also run with autofdo.
The test runtimes are really a bit too short for autofdo, but it's
a reasonable sanity check.

This only works natively for now.

dejagnu doesn't seem to support a wrapper for unix tests, so I had
to open code running these tests.  That should be ok due to the
native run restrictions.

gcc/testsuite/:
2016-03-27  Andi Kleen  

* g++.dg/bprob/bprob.exp: Support autofdo.
* g++.dg/tree-prof/tree-prof.exp: dito.
* gcc.dg/tree-prof/tree-prof.exp: dito.
* gcc.misc-tests/bprob.exp: dito.
* gfortran.dg/prof/prof.exp: dito.
* lib/profopt.exp: dito.
* lib/target-supports.exp: Check for autofdo.
---
 gcc/testsuite/g++.dg/bprob/bprob.exp | 19 +
 gcc/testsuite/g++.dg/tree-prof/tree-prof.exp | 19 +
 gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp | 19 +
 gcc/testsuite/gcc.misc-tests/bprob.exp   | 23 +++
 gcc/testsuite/gfortran.dg/prof/prof.exp  | 18 +
 gcc/testsuite/lib/profopt.exp| 58 ++--
 gcc/testsuite/lib/target-supports.exp| 23 +++
 7 files changed, 176 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/g++.dg/bprob/bprob.exp 
b/gcc/testsuite/g++.dg/bprob/bprob.exp
index d07..92a1e94 100644
--- a/gcc/testsuite/g++.dg/bprob/bprob.exp
+++ b/gcc/testsuite/g++.dg/bprob/bprob.exp
@@ -53,6 +53,7 @@ if $tracelevel then {
 
 set profile_options "-fprofile-arcs"
 set feedback_options "-fbranch-probabilities"
+set profile_wrapper ""
 
 # Main loop.
 foreach profile_option $profile_options feedback_option $feedback_options {
@@ -65,4 +66,22 @@ foreach profile_option $profile_options feedback_option 
$feedback_options {
 }
 }
 
+set profile_wrapper [profopt-perf-wrapper]
+set profile_options "-g"
+set feedback_options "-fauto-profile"
+set run_autofdo 1
+
+foreach profile_option $profile_options feedback_option $feedback_options {
+foreach src [lsort [glob -nocomplain $srcdir/$subdir/bprob-*.c]] {
+if ![runtest_file_p $runtests $src] then {
+continue
+}
+   set base [file tail $srco
+profopt-execute $src
+}
+}
+
+set run_autofdo ""
+set profile_wrapper ""
+
 set PROFOPT_OPTIONS $bprob_save_profopt_options
diff --git a/gcc/testsuite/g++.dg/tree-prof/tree-prof.exp 
b/gcc/testsuite/g++.dg/tree-prof/tree-prof.exp
index 7a4b5cb..7220217 100644
--- a/gcc/testsuite/g++.dg/tree-prof/tree-prof.exp
+++ b/gcc/testsuite/g++.dg/tree-prof/tree-prof.exp
@@ -44,6 +44,7 @@ set PROFOPT_OPTIONS [list {}]
 # profile data.
 set profile_option "-fprofile-generate -D_PROFILE_GENERATE"
 set feedback_option "-fprofile-use -D_PROFILE_USE"
+set profile_wrapper ""
 
 foreach src [lsort [glob -nocomplain $srcdir/$subdir/*.C]] {
 # If we're only testing specific files and this isn't one of them, skip it.
@@ -53,4 +54,22 @@ foreach src [lsort [glob -nocomplain $srcdir/$subdir/*.C]] {
 profopt-execute $src
 }
 
+set profile_wrapper [profopt-perf-wrapper]
+set profile_options "-g"
+set feedback_options "-fauto-profile"
+set run_autofdo 1
+
+foreach profile_option $profile_options feedback_option $feedback_options {
+foreach src [lsort [glob -nocomplain $srcdir/$subdir/bprob-*.c]] {
+if ![runtest_file_p $runtests $src] then {
+continue
+}
+   set base [file tail $srco
+profopt-execute $src
+}
+}
+
+set run_autofdo ""
+set profile_wrapper ""
+
 set PROFOPT_OPTIONS $treeprof_save_profopt_options
diff --git a/gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp 
b/gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp
index 650ad8d..7fff52c 100644
--- a/gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp
+++ b/gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp
@@ -44,6 +44,7 @@ set PROFOPT_OPTIONS [list {}]
 # profile data.
 set profile_option "-fprofile-generate -D_PROFILE_GENERATE"
 set feedback_option "-fprofile-use -D_PROFILE_USE"
+set profile_wrapper ""
 
 foreach src [lsort [glob -nocomplain $srcdir/$subdir/*.c]] {
 # If we're only testing specific files and this isn't one of them, skip it.
@@ -53,4 +54,22 @@ foreach src [lsort [glob -nocomplain $srcdir/$subdir/*.c]] {
 profopt-execute $src
 }
 
+set profile_wrapper [profopt-perf-wrapper]
+set profile_options "-g"
+set feedback_options "-fauto-profile"
+set run_autofdo 1
+
+foreach profile_option $profile_options feedback_option $feedback_options {
+foreach src [lsort [glob -nocomplain $srcdir/$subdir/bprob-*.c]] {
+if ![runtest_file_p $runtests $src] then {
+continue
+}
+   set base [file tail $srco
+profopt-execute $src
+}
+}
+
+set run_autofdo ""
+set profile_wrapper ""
+
 set PROFOPT_OPTIONS $treeprof_save_profopt_options
diff --git a/gcc/testsuite/gcc.misc-tests/bprob.exp 
b/gcc/testsuite/gcc.misc-tests/bprob.exp
index 52dcb1f..cc12f1f 100644
--- a/gcc/testsuite/gcc.misc-tests/bprob.exp
+++ b/gcc/testsuite/gcc