Re: [Patch, Fortran] PR 85088: improve diagnostic for bad INTENT declaration

2018-06-10 Thread Janus Weil
Hi Thomas,

> I like what the patch does. However, I have one concern.
>
>>  * decl.c (match_attr_spec): Synchronize the DECL_* enum values with
>> the
>>  INTENT_* values from the enum 'sym_intent'.
>
>
> This part
>
> +  { GFC_DECL_BEGIN = 0, DECL_ALLOCATABLE = GFC_DECL_BEGIN,
> +DECL_IN = INTENT_IN, DECL_OUT = INTENT_OUT, DECL_INOUT = INTENT_INOUT,
> +DECL_DIMENSION, DECL_EXTERNAL,
> +DECL_INTRINSIC, DECL_OPTIONAL,
>
> brings a dependency of the values of sym_intent into this enum.
>
> I know that the order of sym_intent is not likely to change, but I would
> still prefer if you could add a comment to the sym_intent definition in
> gfortran.h noting that INTENT_IN cannot be zero, and add a
>
> gcc_assert (INTENT_IN > 0);
>
> somewhere (which will be optimized away) with an explanatory comment.

good point. I have added the assert and some comments. Updated patch attached.


> OK with that change.

Thanks. I'm doing another regtest now and will commit if that goes well ...

Cheers,
Janus
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 261358)
+++ gcc/fortran/decl.c	(working copy)
@@ -4716,9 +4716,10 @@ match_attr_spec (void)
 {
   /* Modifiers that can exist in a type statement.  */
   enum
-  { GFC_DECL_BEGIN = 0,
-DECL_ALLOCATABLE = GFC_DECL_BEGIN, DECL_DIMENSION, DECL_EXTERNAL,
-DECL_IN, DECL_OUT, DECL_INOUT, DECL_INTRINSIC, DECL_OPTIONAL,
+  { GFC_DECL_BEGIN = 0, DECL_ALLOCATABLE = GFC_DECL_BEGIN,
+DECL_IN = INTENT_IN, DECL_OUT = INTENT_OUT, DECL_INOUT = INTENT_INOUT,
+DECL_DIMENSION, DECL_EXTERNAL,
+DECL_INTRINSIC, DECL_OPTIONAL,
 DECL_PARAMETER, DECL_POINTER, DECL_PROTECTED, DECL_PRIVATE,
 DECL_STATIC, DECL_AUTOMATIC,
 DECL_PUBLIC, DECL_SAVE, DECL_TARGET, DECL_VALUE, DECL_VOLATILE,
@@ -4729,6 +4730,9 @@ match_attr_spec (void)
 /* GFC_DECL_END is the sentinel, index starts at 0.  */
 #define NUM_DECL GFC_DECL_END
 
+  /* Make sure that values from sym_intent are safe to be used here.  */
+  gcc_assert (INTENT_IN > 0);
+
   locus start, seen_at[NUM_DECL];
   int seen[NUM_DECL];
   unsigned int d;
@@ -4846,13 +4850,12 @@ match_attr_spec (void)
 		  if (match_string_p ("nt"))
 			{
 			  /* Matched "intent".  */
-			  /* TODO: Call match_intent_spec from here.  */
-			  if (gfc_match (" ( in out )") == MATCH_YES)
-			d = DECL_INOUT;
-			  else if (gfc_match (" ( in )") == MATCH_YES)
-			d = DECL_IN;
-			  else if (gfc_match (" ( out )") == MATCH_YES)
-			d = DECL_OUT;
+			  d = match_intent_spec ();
+			  if (d == INTENT_UNKNOWN)
+			{
+			  m = MATCH_ERROR;
+			  goto cleanup;
+			}
 			}
 		}
 		  else if (ch == 'r')
Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h	(revision 261358)
+++ gcc/fortran/gfortran.h	(working copy)
@@ -291,7 +291,8 @@ enum procedure_type
   PROC_INTRINSIC, PROC_ST_FUNCTION, PROC_EXTERNAL
 };
 
-/* Intent types.  */
+/* Intent types. Note that these values are also used in another enum in
+   decl.c (match_attr_spec).  */
 enum sym_intent
 { INTENT_UNKNOWN = 0, INTENT_IN, INTENT_OUT, INTENT_INOUT
 };


Re: [patch] dwarf2out don't discriminate on dwarf version for advertising Ada

2018-06-10 Thread Olivier Hainque
Hi Jakub,

> On 07 Jun 2018, at 10:36, Jakub Jelinek  wrote:

> The whole point of -gstrict-dwarf is that it doesn't allow any extensions,
> and DW_LANG_Ada83/DW_LANG_Ada95 only appeared in DWARF3.

Actually, according to

  http://wiki.dwarfstd.org/index.php?title=DWARF_Language_Support

DW_LANG_Ada83 is dwarf-2 and DW_LANG_Ada95 is dwarf-3.

So what about the attached variant instead ? I can add test if needed.

Thanks in advance,

With Kind Regards,

Olivier

2018-06-10  Olivier Hainque  

* dwarf2out.c (gen_compile_unit_die): fallout to DW_LANG_Ada83
for Ada with strict dwarf2.



dw2-ada83.diff
Description: Binary data


Re: [Patch, Fortran] PR 85088: improve diagnostic for bad INTENT declaration

2018-06-10 Thread Janus Weil
2018-06-10 9:02 GMT+02:00 Janus Weil :
> Hi Thomas,
>
>> I like what the patch does. However, I have one concern.
>>
>>>  * decl.c (match_attr_spec): Synchronize the DECL_* enum values with
>>> the
>>>  INTENT_* values from the enum 'sym_intent'.
>>
>>
>> This part
>>
>> +  { GFC_DECL_BEGIN = 0, DECL_ALLOCATABLE = GFC_DECL_BEGIN,
>> +DECL_IN = INTENT_IN, DECL_OUT = INTENT_OUT, DECL_INOUT = INTENT_INOUT,
>> +DECL_DIMENSION, DECL_EXTERNAL,
>> +DECL_INTRINSIC, DECL_OPTIONAL,
>>
>> brings a dependency of the values of sym_intent into this enum.
>>
>> I know that the order of sym_intent is not likely to change, but I would
>> still prefer if you could add a comment to the sym_intent definition in
>> gfortran.h noting that INTENT_IN cannot be zero, and add a
>>
>> gcc_assert (INTENT_IN > 0);
>>
>> somewhere (which will be optimized away) with an explanatory comment.
>
> good point. I have added the assert and some comments. Updated patch attached.
>
>
>> OK with that change.
>
> Thanks. I'm doing another regtest now and will commit if that goes well ...

No failures observed. Committed as r261386.

Cheers,
Janus


New French PO file for 'cpplib' (version 8.1-b20180128)

2018-06-10 Thread 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 French team of translators.  The file is available at:

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

(This file, 'cpplib-8.1-b20180128.fr.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.




Contents of PO file 'cpplib-8.1-b20180128.fr.po'

2018-06-10 Thread Translation Project Robot


cpplib-8.1-b20180128.fr.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.



[PATCH] PR79854 - diagnostics: gfc_conv_constant_to_tree should be gfc_internal_error

2018-06-10 Thread Dominique d'Humières
Is the following patch OK for the trunk?

TIA

Dominique

2018-06-10  Dominique d'Humieres  

PR fortran/79854
* trans-const.c: Remove include "diagnostic-core.h"
(gfc_conv_constant_to_tree): Replace fatal_error with gcc_unreachable.

--- ../_clean/gcc/fortran/trans-const.c 2018-02-23 15:17:14.0 +0100
+++ gcc/fortran/trans-const.c   2018-06-07 15:49:38.0 +0200
@@ -26,7 +26,6 @@ along with GCC; see the file COPYING3.  
 #include "tree.h"
 #include "gfortran.h"
 #include "trans.h"
-#include "diagnostic-core.h"   /* For fatal_error.  */
 #include "fold-const.h"
 #include "stor-layout.h"
 #include "realmpfr.h"
@@ -368,9 +367,7 @@ gfc_conv_constant_to_tree (gfc_expr * ex
 expr->representation.string);
 
 default:
-  fatal_error (input_location,
-  "gfc_conv_constant_to_tree(): invalid type: %s",
-  gfc_typename (&expr->ts));
+  gcc_unreachable ();
 }
 }
 


Re: [PATCH] PR79854 - diagnostics: gfc_conv_constant_to_tree should be gfc_internal_error

2018-06-10 Thread Thomas Koenig

Hi Dominique,


Is the following patch OK for the trunk?

TIA

Dominique

2018-06-10  Dominique d'Humieres  

 PR fortran/79854
 * trans-const.c: Remove include "diagnostic-core.h"
 (gfc_conv_constant_to_tree): Replace fatal_error with gcc_unreachable.


OK. Thanks!

Thomas


Re: Enforce F2008:C1282 and F2018:C1588

2018-06-10 Thread Thomas Koenig

Hi Steve,


The attached patch adresses part of an issue raised in
PR fortran/63514 by enforcing F2008:C1282 and F2018:C1588.
Regression tested on x86_64-*-freebsd.  OK to commit?


OK. Thanks!


PS: the actual underlying point of PR fortran/63514 is bogus,
and I recommend that it be closed with WONTFIX.


I concur.

Regards

Thomas


[patch, fortran] Remove bounds checking in DO loops for inline matmul

2018-06-10 Thread Thomas Koenig

Hello world,

the attached patch was motivated by the desire to reduce the runtime
of programs with -fcheck=bounds with (some) optimization, in order
to make debugging less time consuming.

This patch removes the run-time bounds checks with -fcheck=bounds
in the DO loops created by matmul inlining. The Necessary checks are
already performed outside the loop, so the inner tests are not needed.

OK for trunk?

Regards

Thomas

2018-06-10  Thomas Koenig  

* gfortran.h (gfc_expr): Add no_bounds_check field.
* frontend-passes.c (get_array_inq_function): Set no_bounds_check
on function and function argument.
(inline_matmul_assign): Set no_bounds_check on zero expression
and on lhs of zero expression.
Also handle A1B2 case if realloc on assigment is active.
* trans-array.c (gfc_conv_array_ref): Don't do range checking
if expr has no_bounds_check set.
(gfc_conv_expr_descriptor): Set no_bounds_check on ss if expr
has it set.
* trans-expr.c (gfc_trans_assignment_1): Set no_bounds_check
on lss and lss if the corresponding expressions have it set.

2018-06-10  Thomas Koenig  

* gfortran.dg/inline_matmul_23.f90: New test.
! { dg-do compile }
! { dg-options "-Og -fcheck=bounds -fdump-tree-optimized" }
! Check that bounds checking is done only before the matrix
! multiplication.

module y
contains
  subroutine x(a,b,c)
real, dimension(:,:) :: a, b, c
c = matmul(a,b)
  end subroutine x
end module y
! { dg-final { scan-tree-dump-times "_runtime_error" 3 "optimized" } }
Index: gfortran.h
===
--- gfortran.h	(Revision 261245)
+++ gfortran.h	(Arbeitskopie)
@@ -2144,6 +2144,10 @@ typedef struct gfc_expr
   /* Will require finalization after use.  */
   unsigned int must_finalize : 1;
 
+  /* Set this if no range check should be performed on this expression.  */
+
+  unsigned int no_bounds_check : 1;
+
   /* If an expression comes from a Hollerith constant or compile-time
  evaluation of a transfer statement, it may have a prescribed target-
  memory representation, and these cannot always be backformed from
Index: frontend-passes.c
===
--- frontend-passes.c	(Revision 261248)
+++ frontend-passes.c	(Arbeitskopie)
@@ -2938,9 +2938,14 @@ get_array_inq_function (gfc_isym_id id, gfc_expr *
 			   gfc_index_integer_kind);
 
   ec = gfc_copy_expr (e);
+
+  /* No bounds checking, this will be done before the loops if -fcheck=bounds
+ is in effect.  */
+  ec->no_bounds_check = 1;
   fcn = gfc_build_intrinsic_call (current_ns, id, name, e->where, 3,
   ec, dim_arg,  kind);
   gfc_simplify_expr (fcn, 0);
+  fcn->no_bounds_check = 1;
   return fcn;
 }
 
@@ -3645,6 +3650,9 @@ scalarized_expr (gfc_expr *e_in, gfc_expr **index,
 	}
 }
 
+  /* Bounds checking will be done before the loops if -fcheck=bounds
+ is in effect. */
+  e->no_bounds_check = 1;
   return e;
 }
 
@@ -3832,7 +3840,7 @@ inline_matmul_assign (gfc_code **c, int *walk_subt
 	m_case = A1B2;
 	}
 }
-
+
   if (m_case == none)
 return 0;
 
@@ -3911,10 +3919,13 @@ inline_matmul_assign (gfc_code **c, int *walk_subt
   next_code_point = &if_limit->block->next;
 }
 
+  zero_e->no_bounds_check = 1;
+
   assign_zero = XCNEW (gfc_code);
   assign_zero->op = EXEC_ASSIGN;
   assign_zero->loc = co->loc;
   assign_zero->expr1 = gfc_copy_expr (expr1);
+  assign_zero->expr1->no_bounds_check = 1;
   assign_zero->expr2 = zero_e;
 
   /* Handle the reallocation, if needed.  */
@@ -3926,20 +3937,33 @@ inline_matmul_assign (gfc_code **c, int *walk_subt
 	 bounds checking, the rest will be allocated.  Also check this
 	 for A2B1.   */
 
-  if ((gfc_option.rtcheck & GFC_RTCHECK_BOUNDS) && (m_case == A2B2 || m_case == A2B1))
+  if (gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
 	{
 	  gfc_code *test;
-	  gfc_expr *a2, *b1;
+	  if (m_case == A2B2 || m_case == A2B1)
+	{
+	  gfc_expr *a2, *b1;
 
-	  a2 = get_array_inq_function (GFC_ISYM_SIZE, matrix_a, 2);
-	  b1 = get_array_inq_function (GFC_ISYM_SIZE, matrix_b, 1);
-	  test = runtime_error_ne (b1, a2, "Dimension of array B incorrect "
-   "in MATMUL intrinsic: Is %ld, should be %ld");
-	  *next_code_point = test;
-	  next_code_point = &test->next;
+	  a2 = get_array_inq_function (GFC_ISYM_SIZE, matrix_a, 2);
+	  b1 = get_array_inq_function (GFC_ISYM_SIZE, matrix_b, 1);
+	  test = runtime_error_ne (b1, a2, "Dimension of array B incorrect "
+   "in MATMUL intrinsic: Is %ld, should be %ld");
+	  *next_code_point = test;
+	  next_code_point = &test->next;
+	}
+	  else if (m_case == A1B2)
+	{
+	  gfc_expr *a1, *b1;
+
+	  a1 = get_array_inq_function (GFC_ISYM_SIZE, matrix_a, 1);
+	  b1 = get_array_inq_function (GFC_ISYM_SIZE, matrix_b, 1);
+	  test = runtime_error_ne (b1, a1, "Dimension of array B i

Re: [PATCH] PR79854 - diagnostics: gfc_conv_constant_to_tree should be gfc_internal_error

2018-06-10 Thread Dominique d'Humières
Committed as r261387.

Thanks,

Dominique

> Le 10 juin 2018 à 14:25, Thomas Koenig  a écrit :
> 
> Hi Dominique,
> 
>> Is the following patch OK for the trunk?
>> TIA
>> Dominique
>> 2018-06-10  Dominique d'Humieres  
>> PR fortran/79854
>> * trans-const.c: Remove include "diagnostic-core.h"
>> (gfc_conv_constant_to_tree): Replace fatal_error with 
>> gcc_unreachable.
> 
> OK. Thanks!
> 
>   Thomas



[wwwdocs] More replacing by id= attributes

2018-06-10 Thread Gerald Pfeifer
This continues what I started last weekend, a primary step to
move our pages to HTML 5.

Applied.

Gerald

Index: svnwrite.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svnwrite.html,v
retrieving revision 1.38
diff -u -r1.38 svnwrite.html
--- svnwrite.html   6 Feb 2017 12:42:17 -   1.38
+++ svnwrite.html   2 Jun 2018 13:01:00 -
@@ -1,9 +1,5 @@
 
 
-
-
 Read-write SVN access
 
 
@@ -30,7 +26,7 @@
 
 
 
-Authenticated access
+Authenticated access
 
 We provide authenticated access via the SSH protocol.  This needs to
 be sponsored by an existing maintainer (someone with "write after approval"
@@ -59,7 +55,7 @@
 access policies below.
 
 
-Setting up your local SVN tree
+Setting up your local SVN tree
 
 Once your account has been set up, check out the GCC sources by 
 issuing the command:
@@ -90,7 +86,7 @@
 
 
 
-Write access policies
+Write access policies
 
 The GCC project grants developers various levels of write access to
 and review authority over the GCC master sources.  We have not put any
@@ -166,7 +162,7 @@
 
 
 
-Testing changes
+Testing changes
 
 All changes must be tested according to the 
 instructions for testing patches
@@ -195,7 +191,7 @@
 revocation of check-in privileges by the Steering Committee.
 
 
-Checking in a change
+Checking in a change
 
 The following is meant to provide a very quick overview of how to
 check in a change.  It is not meant to be a replacement for the SVN
@@ -250,7 +246,7 @@
 
 
 
-Example check-in session
+Example check-in session
 
 Here's an actual check-in session for a patch John Carr recently
 sent to the GCC list.  This was the ChangeLog for his change:
@@ -410,7 +406,7 @@
 like "Merge from mainline" or similar.
 
 
-Tips&Tricks around your account
+Tips&Tricks around your account
 
 Your gcc.gnu.org account also receives e-mail (and is what you
 use for Bugzilla).  If you ever need to change the address e-mail to
Index: releases.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/releases.html,v
retrieving revision 1.132
diff -u -r1.132 releases.html
--- releases.html   2 May 2018 10:21:15 -   1.132
+++ releases.html   2 Jun 2018 13:01:00 -
@@ -8,7 +8,7 @@
 
 GCC Releases
 
-Download
+Download
 
 Source code for GCC releases may be downloaded from our
 mirror sites.
@@ -24,7 +24,7 @@
 using SVN.
 
 
-GCC Timeline
+GCC Timeline
 
 The table is sorted by date.  Note that starting with version 3.3.4,
 we provide bug releases for older release branches for those users
Index: search.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/search.html,v
retrieving revision 1.192
diff -u -r1.192 search.html
--- search.html 10 Dec 2017 11:12:42 -  1.192
+++ search.html 2 Jun 2018 13:01:02 -
@@ -2226,11 +2226,11 @@
 
 
 
-
-
+
 In a boolean expression, the words searched for, or parts inside
 parentheses () are separated by the operator-words and,
 or and not.  Examples of correct expressions are:
+
 
 
 cat and dog
Index: lists.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v
retrieving revision 1.113
diff -u -r1.113 lists.html
--- lists.html  10 Mar 2018 16:32:33 -  1.113
+++ lists.html  2 Jun 2018 13:01:02 -
@@ -147,7 +147,7 @@
 
 To post a message, just send mail to 
listname@gcc.gnu.org.
 
-Policies
+Policies
 
 Our lists have a maximum message size of 100KB, only the gcc-prs list
 allows for a larger maximum message size of 2MB.  If your message exceeds
@@ -312,9 +312,8 @@
 
 
 
-This search will allow you to search the contents gcc.gnu.org.
+Search the contents gcc.gnu.org:
 
-
 
 
 
Index: develop.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.182
diff -u -r1.182 develop.html
--- develop.html20 May 2018 20:23:05 -  1.182
+++ develop.html2 Jun 2018 13:01:02 -
@@ -99,7 +99,7 @@
 
 Development on our main branch will proceed in three stages.
 
-Stage 1
+Stage 1
 
 During this period, changes of any nature may be made to the
 compiler.  In particular, major changes may be merged from branches.
@@ -115,19 +115,19 @@
 to attempt to order the inclusion of major features in an organized
 manner.
 
-Stage 2
+Stage 2
 
 Stage 2 has been abandoned in favor of an extended feature driven
 Stage 1 since the development of GCC 4.4.
 
-Stage 3
+Stage 3
 
 During this two-month period, the only (non-documentation) changes
 that may be made are changes that fix bugs or new ports which do not
 require changes to other parts of the compiler.
 New functionality may not be introduced during this period.
 
-Stage 4
+Stage 4
 
 During this period, the only (non-documentation) changes that may
 be made are changes that fix regressions.  Other changes may not be
@@

Re: [wwwdocs] Replace by id= attributes

2018-06-10 Thread Gerald Pfeifer
On Sat, 2 Jun 2018, Gerald Pfeifer wrote:
> Hmpf, I missed that id attributes have to start with a letter; 
> fixed thusly for the GCC8 pages.  I'll take care of the others
> later.

Done thusly.

Committed.

Gerald

Index: gcc-6/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.104
diff -u -r1.104 changes.html
--- gcc-6/changes.html  2 Jun 2018 21:16:17 -   1.104
+++ gcc-6/changes.html  10 Jun 2018 14:06:28 -
@@ -858,7 +858,7 @@
   
 
 
-GCC 6.2
+GCC 6.2
 
 This is the https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=6.2";>list
 of problem reports (PRs) from GCC's bug tracking system that are
@@ -876,7 +876,7 @@
 Support for the VIS 4.0 instruction set has been added.
   
 
-GCC 6.3
+GCC 6.3
 
 This is the https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=6.3";>list
 of problem reports (PRs) from GCC's bug tracking system that are
@@ -893,7 +893,7 @@
 pcommit instruction has been removed.
   
 
-GCC 6.4
+GCC 6.4
 
 This is the https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=6.4";>list
 of problem reports (PRs) from GCC's bug tracking system that are
@@ -910,7 +910,7 @@
 
 
 
-GCC 7.2
+GCC 7.2
 
 This is the https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=7.2";>list
 of problem reports (PRs) from GCC's bug tracking system that are
@@ -1312,7 +1312,7 @@

 
 
-GCC 7.3
+GCC 7.3
 
 This is the https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=7.3";>list
 of problem reports (PRs) from GCC's bug tracking system that are


Re: [wwwdocs] Replace by id= attributes

2018-06-10 Thread Gerald Pfeifer
...plus one I had missed.

Gerald

Index: gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.106
diff -u -r1.106 changes.html
--- gcc-7/changes.html  10 Jun 2018 14:12:46 -  1.106
+++ gcc-7/changes.html  10 Jun 2018 14:17:44 -
@@ -1262,7 +1262,7 @@
   
 
 
-GCC 7.1
+GCC 7.1
 
 This is the https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=7.0";>list
 of problem reports (PRs) from GCC's bug tracking system that are


Re: [wwwdocs] Replace by id= attributes

2018-06-10 Thread Gerald Pfeifer
On Sun, 10 Jun 2018, Gerald Pfeifer wrote:
>> Hmpf, I missed that id attributes have to start with a letter; 
>> fixed thusly for the GCC8 pages.  I'll take care of the others
>> later.
> Done thusly.

And in fact, not much point in having this for the table of contents
on the main release pages, so simplify those for current release series
as follows.

Applied as well.

Gerald

Index: gcc-6/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/index.html,v
retrieving revision 1.9
diff -u -r1.9 index.html
--- gcc-6/index.html2 Jun 2018 21:16:17 -   1.9
+++ gcc-6/index.html10 Jun 2018 14:13:40 -
@@ -22,25 +22,25 @@
 
 
 GCC 6.4
-July 4, 2017
+July 4, 2017
 (changes,
  http://gcc.gnu.org/onlinedocs/6.4.0/";>documentation)
 
 
 GCC 6.3
-December 21, 2016
+December 21, 2016
 (changes,
  http://gcc.gnu.org/onlinedocs/6.3.0/";>documentation)
 
 
 GCC 6.2
-August 22, 2016
+August 22, 2016
 (changes,
  http://gcc.gnu.org/onlinedocs/6.2.0/";>documentation)
 
 
 GCC 6.1
-April 27, 2016
+April 27, 2016
 (changes,
  http://gcc.gnu.org/onlinedocs/6.1.0/";>documentation)
 
Index: gcc-7/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/index.html,v
retrieving revision 1.7
diff -u -r1.7 index.html
--- gcc-7/index.html2 Jun 2018 21:16:18 -   1.7
+++ gcc-7/index.html10 Jun 2018 14:13:40 -
@@ -22,19 +22,19 @@
 
 
 GCC 7.3
-Jan 25, 2018
+Jan 25, 2018
 (changes,
  http://gcc.gnu.org/onlinedocs/7.3.0/";>documentation)
 
 
 GCC 7.2
-Aug 14, 2017
+Aug 14, 2017
 (changes,
  http://gcc.gnu.org/onlinedocs/7.2.0/";>documentation)
 
 
 GCC 7.1
-May 2, 2017
+May 2, 2017
 (changes,
  http://gcc.gnu.org/onlinedocs/7.1.0/";>documentation)
 
Index: gcc-8/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/index.html,v
retrieving revision 1.5
diff -u -r1.5 index.html
--- gcc-8/index.html2 Jun 2018 21:51:00 -   1.5
+++ gcc-8/index.html10 Jun 2018 14:13:40 -
@@ -22,7 +22,7 @@
 
 
 GCC 8.1
-May 2, 2018
+May 2, 2018
 (changes,
  http://gcc.gnu.org/onlinedocs/8.1.0/";>documentation)
 


Re: [patch, fortran] Remove bounds checking in DO loops for inline matmul

2018-06-10 Thread Steve Kargl
On Sun, Jun 10, 2018 at 02:50:56PM +0200, Thomas Koenig wrote:
> 
> the attached patch was motivated by the desire to reduce the runtime
> of programs with -fcheck=bounds with (some) optimization, in order
> to make debugging less time consuming.
> 
> This patch removes the run-time bounds checks with -fcheck=bounds
> in the DO loops created by matmul inlining. The Necessary checks are
> already performed outside the loop, so the inner tests are not needed.
> 
> OK for trunk?
> 

Yes.

-- 
Steve


Re: [patch, fortran] Remove bounds checking in DO loops for inline matmul

2018-06-10 Thread Thomas Koenig

Hi Steve,


On Sun, Jun 10, 2018 at 02:50:56PM +0200, Thomas Koenig wrote:



OK for trunk?



Yes.


Thanks, committed as rev 261388.

Regards

Thomas


Re: [PATCH][PR sanitizer/86090] Add checks for lstat and readlink to sanitizer configure.

2018-06-10 Thread Jakub Jelinek
On Fri, Jun 08, 2018 at 08:10:40PM +0300, Denis Khalikov wrote:
> From: Denis Khalikov 
> Date: Fri, 8 Jun 2018 19:53:01 +0300
> Subject: [PATCH] PR sanitizer/86090
> 
> * configure.ac: Check for lstat and readlink.
> * configure, config.h.in: Rebuild.

Ok for trunk.  Will somebody commit it for you or should I?

Jakub


Re: [patch] dwarf2out don't discriminate on dwarf version for advertising Ada

2018-06-10 Thread Jakub Jelinek
On Sun, Jun 10, 2018 at 09:26:51AM +0200, Olivier Hainque wrote:
> Hi Jakub,
> 
> > On 07 Jun 2018, at 10:36, Jakub Jelinek  wrote:
> 
> > The whole point of -gstrict-dwarf is that it doesn't allow any extensions,
> > and DW_LANG_Ada83/DW_LANG_Ada95 only appeared in DWARF3.
> 
> Actually, according to
> 
>   http://wiki.dwarfstd.org/index.php?title=DWARF_Language_Support

Well, you should better be looking at the pdfs of the standards, that is
more precise.  And there it says:
Names marked with † and their associated values are reserved,
but the languages they represent are not supported in DWARF Version 2.
...
DW_LANG_Ada83†  0x0003

so, using DW_LANG_Ada83 is fine for dwarf-2.

> 2018-06-10  Olivier Hainque  
> 
> * dwarf2out.c (gen_compile_unit_die): fallout to DW_LANG_Ada83
> for Ada with strict dwarf2.

Use uppercase Fallout.
Otherwise ok for trunk.

Jakub


[PATCH] PR fortran/68544 -- Issue error for derived type used as actual arg

2018-06-10 Thread Steve Kargl
The attach patch fixes an ICE that occurs when a user 
uses a derived type as an actual argument to subprogram.
Regression tested on x86_64-*-freebsd and i586-*-freebsd.
OK to commit?

2018-06-10  Steven G. Kargl  

PR fortran/68544
* resolve.c (is_dt_name): New function to compare symbol name against
list of derived types.
(resolve_actual_arglist): Use it to find wrong code.

2018-06-10  Steven G. Kargl  

PR fortran/68544
* gfortran.dg/pr68544.f90: New test.
* gfortran.dg/pr85687.f90: Modify test for new error message.
-- 
Steve
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(revision 261376)
+++ gcc/fortran/resolve.c	(working copy)
@@ -1862,7 +1862,19 @@ resolve_procedure_expression (gfc_expr* expr)
   return true;
 }
 
+/* Check that name is not a derived type.  */
 
+static bool
+is_dt_name (const char *name)
+{
+  gfc_dt_list *dt_list;
+
+  for (dt_list = gfc_derived_types; dt_list; dt_list = dt_list->next)
+if (strcmp(dt_list->derived->name, name) == 0)
+  return true;
+  return false;
+}
+
 /* Resolve an actual argument list.  Most of the time, this is just
resolving the expressions in the list.
The exception is that we sometimes have to decide whether arguments
@@ -1963,6 +1975,14 @@ resolve_actual_arglist (gfc_actual_arglist *arg, proce
 	  gfc_error ("ELEMENTAL non-INTRINSIC procedure %qs is not "
 			 "allowed as an actual argument at %L", sym->name,
 			 &e->where);
+	}
+
+	  /* Check to see if the argument is actually a derived type.  */
+	  if (is_dt_name (sym->name))
+	{
+	  gfc_error ("Derived type %qs is used as an actual "
+			 "argument at %L", sym->name, &e->where);
+	  goto cleanup;
 	}
 
 	  /* Check if a generic interface has a specific procedure
Index: gcc/testsuite/gfortran.dg/pr68544.f90
===
--- gcc/testsuite/gfortran.dg/pr68544.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr68544.f90	(working copy)
@@ -0,0 +1,13 @@
+! { dg-do compile }
+! PF fortran/68544
+program p
+   real x
+   type t
+   end type
+   x = f(t) ! { dg-error "used as an actual argument" }
+end
+subroutine b
+   type t
+   end type
+   print *, shape(t)! { dg-error "used as an actual argument" }
+end
Index: gcc/testsuite/gfortran.dg/pr85687.f90
===
--- gcc/testsuite/gfortran.dg/pr85687.f90	(revision 261376)
+++ gcc/testsuite/gfortran.dg/pr85687.f90	(working copy)
@@ -1,8 +1,9 @@
 ! { dg-do compile }
 ! PR fortran/85687
 ! Code original contributed by Gerhard Steinmetz gscfq at t-oline dot de
+! Originally, error message superceded by fix for PR fortran/68544.
 program p
type t
end type
-   print *, rank(t)  ! { dg-error "must be a data object" }
+   print *, rank(t)  ! { dg-error "used as an actual argument" }
 end


[PATCH] handle non-constant character assignments in strlen (PR 86083)

2018-06-10 Thread Martin Sebor

In the long resolved pr57230 I came across a discussion of
an enhancement to the strlen pass to also handle non-const char
assignments into the middle of known strings, in addition to
assignments where the stored value is known.  Storing non-nul
into the middle of a string of known length means that its
length can be assumed to stay the same, exposing more strlen
optimization opportunities.

The attached patch implements this idea.  (I looked for a simple
function that returns true/false based on whether a SSA_NAME is
or isn't definitely non-zero but couldn't find one so I created
one though it seems that extending one of the existing functions
might be a better approach?)

In a GCC build the patch discovers 40 non-nul stores out of 70
instances where range info is available (all in libstdc++), so
it gives some, albeit very small, improvement.

Martin

PR tree-optimization/86083 - handle non-constant assignments in strlen

gcc/ChangeLog:

	PR tree-optimization/86083
	* tree-ssa-strlen.c (value_is_nonzero): New static function.
	(handle_char_store): Call it.

gcc/testsuite/ChangeLog:

	PR tree-optimization/86083
	* gcc.dg/strlenopt-44.c: New test.


Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c	(revision 261284)
+++ gcc/tree-ssa-strlen.c	(working copy)
@@ -3126,6 +3126,27 @@ get_string_cst_length (tree rhs)
   return -1;
 }
 
+/* Return true iff EXP has a non-zero value, false otherwise.  */
+
+static bool
+value_is_nonzero (tree exp)
+{
+  if (TREE_CODE (exp) != SSA_NAME)
+return integer_nonzerop (exp);
+
+  wide_int min, max;
+  value_range_type rng = get_range_info (exp, &min, &max);
+
+  if (rng == VR_RANGE)
+return wi::gts_p (min, wi::zero (min.get_precision ()));
+
+  if (rng == VR_ANTI_RANGE)
+return (wi::les_p (min, wi::zero (min.get_precision ()))
+	&& wi::les_p (wi::zero (min.get_precision ()), max));
+
+  return false;
+}
+
 /* Handle a single character store.  */
 
 static bool
@@ -3165,9 +3186,7 @@ handle_char_store (gimple_stmt_iterator *gsi)
 }
 
   bool storing_zero_p = initializer_zerop (rhs);
-  bool storing_nonzero_p = (!storing_zero_p
-			&& TREE_CODE (rhs) == INTEGER_CST
-			&& integer_nonzerop (rhs));
+  bool storing_nonzero_p = !storing_zero_p && value_is_nonzero (rhs);
   /* Set to the length of the string being assigned if known.  */
   HOST_WIDE_INT rhslen;
 
Index: gcc/testsuite/gcc.dg/strlenopt-44.c
===
--- gcc/testsuite/gcc.dg/strlenopt-44.c	(nonexistent)
+++ gcc/testsuite/gcc.dg/strlenopt-44.c	(working copy)
@@ -0,0 +1,79 @@
+/* PR tree-optimization/86083 - handle non-constant assignments in strlen
+   { dg-do compile }
+   { dg-options "-O2 -Wall -fdump-tree-optimized" } */
+
+#include "range.h"
+#include "strlenopt.h"
+
+#define CAT(x, y) x ## y
+#define CONCAT(x, y) CAT (x, y)
+#define FAILNAME(name) CONCAT (call_ ## name ##_on_line_, __LINE__)
+
+#define FAIL(name) do {\
+extern void FAILNAME (name) (void);		\
+FAILNAME (name)();\
+  } while (0)
+
+/* Macro to emit a call to funcation named
+ call_in_true_branch_not_eliminated_on_line_NNN()
+   for each call that's expected to be eliminated.  The dg-final
+   scan-tree-dump-time directive at the bottom of the test verifies
+   that no such call appears in output.  */
+#define ASSERT_ELIM(expr)		\
+  if (!(expr)) FAIL (in_true_branch_not_eliminated); else (void)0
+
+/* Macro to emit a call to a function named
+ call_made_in_{true,false}_branch_on_line_NNN()
+   for each call that's expected to be retained.  The dg-final
+   scan-tree-dump-time directive at the bottom of the test verifies
+   that the expected number of both kinds of calls appears in output
+   (a pair for each line with the invocation of the KEEP() macro.  */
+#define ASSERT_KEEP(expr)			\
+  if (expr)	\
+FAIL (made_in_true_branch);			\
+  else		\
+FAIL (made_in_false_branch)
+
+
+#define ELIM(init, i, c, res)			\
+  do {		\
+char a[] = init;\
+a[i] = c;	\
+ASSERT_ELIM (strlen (a) == res);		\
+  } while (0)
+
+#define KEEP(init, i, c, res)			\
+  do {		\
+char a[] = init;\
+a[i] = c;	\
+ASSERT_KEEP (strlen (a) == res);		\
+  } while (0)
+
+void test_elim (void)
+{
+  ELIM ("1", 0, UR (1, 2), 1);
+  ELIM ("1", 0, UR (1, 127), 1);
+  ELIM ("1", 0, UR ('0', '9'), 1);
+
+  ELIM ("12", 0, UR (1, 127), 2);
+  ELIM ("12", 1, UR (1, 127), 2);
+
+  ELIM ("123", 0, UR (1, 9), 3);
+  ELIM ("123", 1, UR (10, 99), 3);
+  ELIM ("123", 2, UR (100, 127), 3);
+}
+
+#line 1000
+
+void test_keep (void)
+{
+  size_t uchar_max = (unsigned char)-1;
+
+  KEEP ("1", 0, UR (1, uchar_max + 1), 1);
+  KEEP ("1\0\3", 1, UR (1, 2), 1);
+}
+
+/* { dg-final { scan-tree-dump-times "call_in_true_branch_not_eliminated_" 0 "optimized" } }
+
+   { dg-final { scan-tree-dump-times "call_made_in_true_branch_on_line_1\[0-9\]\[0-9\]\[0-9

Re: [PATCH] wwwdocs: port from MetaHTML to a Python 3 script

2018-06-10 Thread Gerald Pfeifer
Hi David,

On Mon, 4 Jun 2018, David Malcolm wrote:
> Caveat/confession: I've never managed to successfully build MetaHTML,
> so I've never run it.

yes, it's become increasingly difficult to build given how it's
been abandoned unfortunately (which is something I had brought up
with RMS even twice or so).  Hence increasingly a bit of a burning
platform to move away from.

> Here's an attempt at porting the website from MetaHTML to a Python 3
> script.

This is great!  Thank you for doing this.

> I've tested it lightly so far by comparing it to reference pages from 
> the built site (index.html, c99status.html, and install/test.html so 
> far).

Can you also give something like gcc-8/*.html a try?  In between those
you pointed out and these I feel pretty comfortable about us having good
coverage.

> Does this look like the right idea?  (it's not quite perfect yet, but
> is pretty close for the pages I tested on).

It's more procedural, when in principle declarative is nicer, *but*
clearly something that works for everyone (who has Python) and is
maintainable is a big step forward.  And, heck, I may get to learn
a bit of Python on the way. ;-)

> Are there any other pages which have their own uses of MetaHTML that 
> I didn't spot yet?

I cannot think of any; not with some of my recent (and not so recent)
changes to push things to CSS and otherwise.

> For now, I've attempted to faithfully reproduce the strange whitespace that
> MetaHTML introduces, to make it easier to compare diffs.  A followup would
> be to remove that, to give more natural whitespace (thus keeping the
> whitespace changes separated from non-whitespace changes, as it were).

What do you think of simplifying this such that `diff -w -B` aka
`diff --ignore-all-space --ignore-blank-lines` doesn't flag anything?

That would be a way towards more natural whitespace as you refer to,
and from my parsing of the Python code would make things a bit easier?


Two small questions: given the main script is bin/preprocess, would 
it be okay to call the new one bin/preprocess-html-file instead of 
bin/process-html-file.py ?  And possibly omit the .py to "hide" this 
implementation detail?


Last weekend I started to think how to move nearly everything to HTML 5 
(and as you may have seen started to patch in that direction) and devise
a way to handle that in the framework with minimal effort.  

However, now that you have gone to the effort of creating this script,
I am wondering whether we should simply do a flag day and switch to your
script as quickly as possible, even before that transition is complete.

What do you think?

Gerald (on business travel last week and most of the next two, 
but trying to keep up by e-mail).


Re: [ARM/FDPIC 06/21] [ARM] FDPIC: Add support for c++ exceptions

2018-06-10 Thread Christophe Lyon
On 8 June 2018 at 12:51, Richard Earnshaw (lists)
 wrote:
> On 08/06/18 11:15, Kyrill Tkachov wrote:
>> Hi Christophe,
>>
>> On 25/05/18 09:03, Christophe Lyon wrote:
>>> When restoring a function address, we also have to restore the FDPIC
>>> register value (r9).
>>>
>>> 2018-XX-XX  Christophe Lyon  
>>> Mickaël Guêné 
>>>
>>> gcc/
>>> * ginclude/unwind-arm-common.h (unwinder_cache): Add reserved5
>>> field.
>>>
>>> libgcc/
>>> * config/arm/linux-atomic.c (__ARM_ARCH__): Define.
>>> (__kernel_cmpxchg): Add FDPIC support.
>>> (__kernel_dmb): Likewise.
>>> (__fdpic_cmpxchg): New function.
>>> (__fdpic_dmb): New function.
>>> * config/arm/unwind-arm.h (gnu_Unwind_Find_got): New function.
>>> (_Unwind_decode_typeinfo_ptr): Add FDPIC support.
>>> * unwindo-arm-common.inc (UCB_PR_GOT): New.
>>> (funcdesc_t): New struct.
>>> (get_eit_entry): Add FDPIC support.
>>> (unwind_phase2): Likewise.
>>> (unwind_phase2_forced): Likewise.
>>> (__gnu_Unwind_RaiseException): Likewise.
>>> (__gnu_Unwind_Resume): Likewise.
>>> (__gnu_Unwind_Backtrace): Likewise.
>>> * unwind-pe.h (read_encoded_value_with_base): Likewise.
>>>
>>> libstdc++/
>>> * libsupc++/eh_personality.cc (get_ttype_entry): Add FDPIC
>>> support.
>>>
>>> Change-Id: Ic0841eb3d7bfb0b3f6d187cd52a660b8fd394d85
>>>
>>> diff --git a/gcc/ginclude/unwind-arm-common.h
>>> b/gcc/ginclude/unwind-arm-common.h
>>> index 8a1a919..150bd0f 100644
>>> --- a/gcc/ginclude/unwind-arm-common.h
>>> +++ b/gcc/ginclude/unwind-arm-common.h
>>> @@ -91,7 +91,7 @@ extern "C" {
>>>_uw reserved2;  /* Personality routine address */
>>>_uw reserved3;  /* Saved callsite address */
>>>_uw reserved4;  /* Forced unwind stop arg */
>>> - _uw reserved5;
>>> + _uw reserved5;  /* Personality routine GOT value in FDPIC
>>> mode.  */
>>>  }
>>>unwinder_cache;
>>>/* Propagation barrier cache (valid after phase 1): */
>>> diff --git a/libgcc/config/arm/linux-atomic.c
>>> b/libgcc/config/arm/linux-atomic.c
>>> index d334c58..a20ad94 100644
>>> --- a/libgcc/config/arm/linux-atomic.c
>>> +++ b/libgcc/config/arm/linux-atomic.c
>>> @@ -23,13 +23,99 @@ a copy of the GCC Runtime Library Exception along
>>> with this program;
>>>  see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
>>>  . */
>>>
>>> +#if defined(__ARM_ARCH_2__)
>>> +# define __ARM_ARCH__ 2
>>> +#endif
>>> +
>>> +#if defined(__ARM_ARCH_3__)
>>> +# define __ARM_ARCH__ 3
>>> +#endif
>>> +
>>> +#if defined(__ARM_ARCH_3M__) || defined(__ARM_ARCH_4__) \
>>> +  || defined(__ARM_ARCH_4T__)
>>> +/* We use __ARM_ARCH__ set to 4 here, but in reality it's any
>>> processor with
>>> +   long multiply instructions.  That includes v3M.  */
>>> +# define __ARM_ARCH__ 4
>>> +#endif
>>> +
>>
>> Support for __ARM_ARCH_2__, __ARM_ARCH_3__, __ARM_ARCH_3M__ has been
>> removed in GCC 9
>> so this code is dead.
>
> Better still, use the ACLE pre-defines rather than the awkward GCC
> versions which need updating each time a new architecture variant is added.
>

Indeed, that's a better solution. I did notice discrepancies between
several copies of this code block in various GCC libs.


> R.
>
>>
>> I notice that in the removal I've missed out an occurrence of these in
>> config/arm/lib1funcs.S.
>> If you want to remove those occurrences as a separate patch that would
>> be preapproved.
>>
>> Thanks,
>> Kyrill
>>
>>> +#if defined(__ARM_ARCH_5__) || defined(__ARM_ARCH_5T__) \
>>> +  || defined(__ARM_ARCH_5E__) || defined(__ARM_ARCH_5TE__) \
>>> +  || defined(__ARM_ARCH_5TEJ__)
>>> +# define __ARM_ARCH__ 5
>>> +#endif
>>> +
>>> +#if defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_6J__) \
>>> +  || defined(__ARM_ARCH_6K__) || defined(__ARM_ARCH_6Z__) \
>>> +  || defined(__ARM_ARCH_6ZK__) || defined(__ARM_ARCH_6T2__) \
>>> +  || defined(__ARM_ARCH_6M__)
>>> +# define __ARM_ARCH__ 6
>>> +#endif
>>> +
>>> +#if defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__) \
>>> +  || defined(__ARM_ARCH_7R__) || defined(__ARM_ARCH_7M__) \
>>> +  || defined(__ARM_ARCH_7EM__)
>>> +# define __ARM_ARCH__ 7
>>> +#endif
>>> +
>>> +#ifndef __ARM_ARCH__
>>> +#error Unable to determine architecture.
>>> +#endif
>>> +
>>>  /* Kernel helper for compare-and-exchange.  */
>>>  typedef int (__kernel_cmpxchg_t) (int oldval, int newval, int *ptr);
>>> +#if __FDPIC__
>>> +#define __kernel_cmpxchg __fdpic_cmpxchg
>>> +#else
>>>  #define __kernel_cmpxchg (*(__kernel_cmpxchg_t *) 0x0fc0)
>>> +#endif
>>>
>>>  /* Kernel helper for memory barrier.  */
>>>  typedef void (__kernel_dmb_t) (void);
>>> +#if __FDPIC__
>>> +#define __kernel_dmb __fdpic_dmb
>>> +#else
>>>  #define __kernel_dmb (*(__kernel_dmb_t *) 0x0fa0)
>>> +#endif
>>> +
>>> +#if __FDPIC__
>>> +static int __fdpic_cmpxchg (int oldval,

Re: [ARM/FDPIC 04/21] [ARM] FDPIC: Add support for FDPIC for arm architecture

2018-06-10 Thread Christophe Lyon
On 8 June 2018 at 12:31, Kyrill  Tkachov  wrote:
> Hi Christophe,
>
>
> On 25/05/18 09:03, Christophe Lyon wrote:
>>
>> The FDPIC register is hard-coded to r9, as defined in the ABI.
>>
>> We have to disable tailcall optimizations if we don't know if the
>> target function is in the same module. If not, we have to set r9 to
>> the value associated with the target module.
>>
>> When generating a symbol address, we have to take into account whether
>> it is a pointer to data or to a function, because different
>> relocations are needed.
>>
>> 2018-XX-XX  Christophe Lyon  
>> Mickaël Guêné 
>>
>> * config/arm/arm-c.c (__FDPIC__): Define new pre-processor macro
>> in FDPIC mode.
>> * config/arm/arm-protos.h (arm_load_function_descriptor): Declare
>> new function.
>> * config/arm/arm.c (arm_option_override): Define pic register to
>> r9.
>> (arm_function_ok_for_sibcall) Disable sibcall optimization if we
>> have no decl or go through PLT.
>> (arm_load_pic_register): Handle TARGET_FDPIC.
>> (arm_is_segment_info_known): New function.
>> (arm_pic_static_addr): Add support for FDPIC.
>> (arm_load_function_descriptor): New function.
>> (arm_assemble_integer): Add support for FDPIC.
>> * config/arm/arm.h (PIC_OFFSET_TABLE_REG_CALL_CLOBBERED): Define.
>> * config/arm/arm.md (call): Add support for FDPIC.
>> (call_value): Likewise.
>> (*restore_pic_register_after_call): New pattern.
>> (untyped_call): Disable if FDPIC.
>> (untyped_return): Likewise.
>> * config/arm/unspecs.md (UNSPEC_PIC_RESTORE): New.
>>
>> Change-Id: Icee8484772f97ac6f3a9574df4aa4f25a8196786
>>
>> diff --git a/gcc/config/arm/arm-c.c b/gcc/config/arm/arm-c.c
>> index 4471f79..90733cc 100644
>> --- a/gcc/config/arm/arm-c.c
>> +++ b/gcc/config/arm/arm-c.c
>> @@ -202,6 +202,8 @@ arm_cpu_builtins (struct cpp_reader* pfile)
>>builtin_define ("__ARM_EABI__");
>>  }
>>
>> +  def_or_undef_macro (pfile, "__FDPIC__", TARGET_FDPIC);
>> +
>>def_or_undef_macro (pfile, "__ARM_ARCH_EXT_IDIV__", TARGET_IDIV);
>>def_or_undef_macro (pfile, "__ARM_FEATURE_IDIV", TARGET_IDIV);
>>
>> diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
>> index 8537262..edebeb7 100644
>> --- a/gcc/config/arm/arm-protos.h
>> +++ b/gcc/config/arm/arm-protos.h
>> @@ -134,6 +134,7 @@ extern int arm_max_const_double_inline_cost (void);
>>  extern int arm_const_double_inline_cost (rtx);
>>  extern bool arm_const_double_by_parts (rtx);
>>  extern bool arm_const_double_by_immediates (rtx);
>> +extern rtx arm_load_function_descriptor (rtx funcdesc);
>>  extern void arm_emit_call_insn (rtx, rtx, bool);
>>  bool detect_cmse_nonsecure_call (tree);
>>  extern const char *output_call (rtx *);
>> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
>> index 4a5da7e..56670e3 100644
>> --- a/gcc/config/arm/arm.c
>> +++ b/gcc/config/arm/arm.c
>> @@ -3475,6 +3475,12 @@ arm_option_override (void)
>>if (flag_pic && TARGET_VXWORKS_RTP)
>>  arm_pic_register = 9;
>>
>> +  /* If in FDPIC mode then force arm_pic_register to be r9.  */
>> +  if (TARGET_FDPIC)
>> +{
>> +  arm_pic_register = 9;
>> +}
>> +
>
>
> Leave out the braces.
> Also, I believe you'll want to add option checking for TARGET_FDPIC.
> Your cover letter says that this series supports Armv7. So you should add
> checks in arm_override to error out on unsupported configurations
> appropriately
> (pre-Armv7? TARGET_THUMB1? float-abi configurations?)
>

Indeed, it will be cleaner.

Thanks

> Thanks,
> Kyrill
>
>
>>if (arm_pic_register_string != NULL)
>>  {
>>int pic_register = decode_reg_name (arm_pic_register_string);
>> @@ -7256,6 +7262,21 @@ arm_function_ok_for_sibcall (tree decl, tree exp)
>>if (cfun->machine->sibcall_blocked)
>>  return false;
>>
>> +  if (TARGET_FDPIC)
>> +{
>> +  /* In FDPIC, never tailcall something for which we have no decl:
>> +the target function could be in a different module, requiring
>> +a different r9 value.  */
>> +  if (decl == NULL)
>> +   return false;
>> +
>> +  /* Don't tailcall if we go through the PLT since r9 is then
>> +corrupted and we don't restore it for static function
>> +call.  */
>> +  if (!targetm.binds_local_p (decl))
>> +   return false;
>> +}
>> +
>>/* Never tailcall something if we are generating code for Thumb-1.  */
>>if (TARGET_THUMB1)
>>  return false;
>> @@ -7634,7 +7655,9 @@ arm_load_pic_register (unsigned long saved_regs
>> ATTRIBUTE_UNUSED)
>>  {
>>rtx l1, labelno, pic_tmp, pic_rtx, pic_reg;
>>
>> -  if (crtl->uses_pic_offset_table == 0 || TARGET_SINGLE_PIC_BASE)
>> +  if (crtl->uses_pic_offset_table == 0
>> +  || TARGET_SINGLE_PIC_BASE
>> +  || TARGET_FDPIC)
>>  return;
>>
>>gcc_assert (flag_pic);
>> @@ -7702,28 +7725,167 @@ arm_load_pic_register 

Re: [ARM/FDPIC 09/21] [ARM] FDPIC: Add support for taking address of nested function

2018-06-10 Thread Christophe Lyon
On 8 June 2018 at 12:33, Kyrill  Tkachov  wrote:
> Hi Chrishophe,
>
> Could you please provide a description of what this patch does and how it
> achieves that?
>

OK, I'l try to do some archaeology and formulate a description.


>
> On 25/05/18 09:03, Christophe Lyon wrote:
>>
>> 2018-XX-XX  Christophe Lyon 
>> Mickaël Guêné 
>>
>> gcc/
>> * config/arm/arm.c (arm_asm_trampoline_template): Add FDPIC
>> support.
>> (arm_trampoline_init): Likewise.
>> (arm_trampoline_init): Likewise.
>> * config/arm/arm.h (TRAMPOLINE_SIZE): Likewise.
>>
>> Change-Id: I4b5127261a9aefa0f0318f110574ec07a856aeb1
>>
>> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
>> index 025485d..2434602 100644
>> --- a/gcc/config/arm/arm.c
>> +++ b/gcc/config/arm/arm.c
>> @@ -3967,7 +3967,27 @@ arm_asm_trampoline_template (FILE *f)
>>  {
>>fprintf (f, "\t.syntax unified\n");
>>
>> -  if (TARGET_ARM)
>> +  if (TARGET_FDPIC)
>> +{
>> +  /* The first two words are a function descriptor to jump into
>> +the trampoline code just below.  */
>> +  if (TARGET_ARM) fprintf (f, "\t.arm\n");
>> +  else if (TARGET_THUMB2) fprintf (f, "\t.thumb\n");
>> +  else fprintf (f, "\t.code\t16\n");
>> +
>
>
> Please format this in GNU style.

Sorry for missing that. I did visually inspect all the patches and ran
check_GNU_style (both .sh and .py, none complained).

>
>> +  assemble_aligned_integer (UNITS_PER_WORD, const0_rtx);
>> +  assemble_aligned_integer (UNITS_PER_WORD, const0_rtx);
>> +  /* Trampoline code which sets the static chain register but also
>> +PIC register before jumping into real code.  */
>> +  asm_fprintf (f, "\tldr\t%r, [%r, #%d]\n",
>> +  STATIC_CHAIN_REGNUM, PC_REGNUM, TARGET_THUMB2?8:4);
>> +  asm_fprintf (f, "\tldr\t%r, [%r, #%d]\n",
>> +  PIC_OFFSET_TABLE_REGNUM, PC_REGNUM, TARGET_THUMB2?8:4);
>> +  asm_fprintf (f, "\tldr\t%r, [%r, #%d]\n",
>> +  PC_REGNUM, PC_REGNUM, TARGET_THUMB2?8:4);
>
>
> Likewise.
> Also, this will use offset 4 for TARGET_THUMB1. Given that you handle
> TARGET_THUMB1
> in the if statement above you expect this code can be entered for
> TARGET_THUMB1?
>
I'll check that,

Thanks

> Thanks,
> Kyrill
>
>
>> +  assemble_aligned_integer (UNITS_PER_WORD, const0_rtx);
>> +}
>> +  else if (TARGET_ARM)
>>  {
>>fprintf (f, "\t.arm\n");
>>asm_fprintf (f, "\tldr\t%r, [%r, #0]\n", STATIC_CHAIN_REGNUM,
>> PC_REGNUM);
>> @@ -4008,12 +4028,37 @@ arm_trampoline_init (rtx m_tramp, tree fndecl, rtx
>> chain_value)
>>emit_block_move (m_tramp, assemble_trampoline_template (),
>> GEN_INT (TRAMPOLINE_SIZE), BLOCK_OP_NORMAL);
>>
>> -  mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 8 : 12);
>> -  emit_move_insn (mem, chain_value);
>> +  if (TARGET_FDPIC)
>> +{
>> +  rtx funcdesc = XEXP (DECL_RTL (fndecl), 0);
>> +  rtx fnaddr = gen_rtx_MEM (Pmode, funcdesc);
>> +  rtx gotaddr = gen_rtx_MEM (Pmode, plus_constant (Pmode, funcdesc,
>> 4));
>> +  rtx trampolineCodeStart
>> +   = plus_constant (Pmode, XEXP (m_tramp, 0), TARGET_THUMB2 ? 9 : 8);
>> +
>> +  /* Write initial funcdesc which will jump into trampoline.  */
>> +  mem = adjust_address (m_tramp, SImode, 0);
>> +  emit_move_insn (mem, trampolineCodeStart);
>> +  mem = adjust_address (m_tramp, SImode, 4);
>> +  emit_move_insn (mem, gen_rtx_REG (Pmode, PIC_OFFSET_TABLE_REGNUM));
>> +  /* Setup static chain.  */
>> +  mem = adjust_address (m_tramp, SImode, 20);
>> +  emit_move_insn (mem, chain_value);
>> +  /* GOT + real function entry point.  */
>> +  mem = adjust_address (m_tramp, SImode, 24);
>> +  emit_move_insn (mem, gotaddr);
>> +  mem = adjust_address (m_tramp, SImode, 28);
>> +  emit_move_insn (mem, fnaddr);
>> +}
>> +  else
>> +{
>> +  mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 8 : 12);
>> +  emit_move_insn (mem, chain_value);
>>
>> -  mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 12 : 16);
>> -  fnaddr = XEXP (DECL_RTL (fndecl), 0);
>> -  emit_move_insn (mem, fnaddr);
>> +  mem = adjust_address (m_tramp, SImode, TARGET_32BIT ? 12 : 16);
>> +  fnaddr = XEXP (DECL_RTL (fndecl), 0);
>> +  emit_move_insn (mem, fnaddr);
>> +}
>>
>>a_tramp = XEXP (m_tramp, 0);
>>emit_library_call (gen_rtx_SYMBOL_REF (Pmode, "__clear_cache"),
>> @@ -4027,7 +4072,9 @@ arm_trampoline_init (rtx m_tramp, tree fndecl, rtx
>> chain_value)
>>  static rtx
>>  arm_trampoline_adjust_address (rtx addr)
>>  {
>> -  if (TARGET_THUMB)
>> +  /* For FDPIC don't fix trampoline address since it's a function
>> + descriptor and not a function address.  */
>> +  if (TARGET_THUMB && !TARGET_FDPIC)
>>  addr = expand_simple_binop (Pmode, IOR, addr, const1_rtx,
>>  NULL, 0, OPTAB_LIB_WIDEN);
>>return addr;
>> diff --git a/

Re: [ARM/FDPIC 10/21] [ARM] FDPIC: Implement legitimize_tls_address_fdpic

2018-06-10 Thread Christophe Lyon
On 8 June 2018 at 12:41, Kyrill  Tkachov  wrote:
> Hi Christophe,
>
>
> On 25/05/18 09:03, Christophe Lyon wrote:
>>
>> Support additional relocations: TLS_GD32_FDPIC, TLS_LDM32_FDPIC, and
>> TLS_IE32_FDPIC.
>>
>> We do not support the GNU2 TLS dialect.
>>
>> 2018-XX-XX  Christophe Lyon  
>> Mickaël Guêné 
>>
>> gcc/
>> * config/arm/arm.c (tls_reloc): Add TLS_GD32_FDPIC,
>> TLS_LDM32_FDPIC and TLS_IE32_FDPIC.
>> (arm_call_tls_get_addr_fdpic): New.
>> (legitimize_tls_address_fdpic): New.
>> (legitimize_tls_address_not_fdpic): New.
>> (legitimize_tls_address): Add FDPIC support.
>> (arm_emit_tls_decoration): Likewise.
>>
>> Change-Id: I4ea5034ff654540c4658d0a79fb92f70550cdf4a
>>
>> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
>> index 2434602..20b8f66 100644
>> --- a/gcc/config/arm/arm.c
>> +++ b/gcc/config/arm/arm.c
>> @@ -2373,9 +2373,12 @@ char arm_arch_name[] = "__ARM_ARCH_PROFILE__";
>>
>>  enum tls_reloc {
>>TLS_GD32,
>> +  TLS_GD32_FDPIC,
>>TLS_LDM32,
>> +  TLS_LDM32_FDPIC,
>>TLS_LDO32,
>>TLS_IE32,
>> +  TLS_IE32_FDPIC,
>>TLS_LE32,
>>TLS_DESCSEQ  /* GNU scheme */
>>  };
>> @@ -8681,6 +8684,30 @@ load_tls_operand (rtx x, rtx reg)
>>  }
>>
>>  static rtx_insn *
>> +arm_call_tls_get_addr_fdpic (rtx x, rtx reg, rtx *valuep, int reloc)
>> +{
>
>
> Please add a function comment
>
>> +  rtx sum;
>> +
>> +  gcc_assert (reloc != TLS_DESCSEQ);
>> +  start_sequence ();
>> +
>> +  sum = gen_rtx_UNSPEC (Pmode,
>> +   gen_rtvec (2, x, GEN_INT (reloc)),
>> +   UNSPEC_TLS);
>> +  reg = load_tls_operand (sum, reg);
>> +  emit_insn (gen_addsi3 (reg, reg, gen_rtx_REG (Pmode, 9)));
>> +
>> +  *valuep = emit_library_call_value (get_tls_get_addr (), NULL_RTX,
>> +LCT_PURE, /* LCT_CONST?  */
>> +Pmode, reg, Pmode);
>
>
> I prefer to avoid comments with such question marks. Is there some ambiguity
> on which should be used?
>
>> +
>> +  rtx_insn *insns = get_insns ();
>> +  end_sequence ();
>> +
>> +  return insns;
>> +}
>> +
>> +static rtx_insn *
>>  arm_call_tls_get_addr (rtx x, rtx reg, rtx *valuep, int reloc)
>>  {
>>rtx label, labelno, sum;
>> @@ -8736,8 +8763,84 @@ arm_tls_descseq_addr (rtx x, rtx reg)
>>return reg;
>>  }
>>
>> -rtx
>> -legitimize_tls_address (rtx x, rtx reg)
>> +static rtx
>> +legitimize_tls_address_fdpic (rtx x, rtx reg)
>> +{
>
>
> Please add a function comment, even if it's just a simple one.
>
>> +rtx dest, ret, eqv, addend, sum, tp;
>> +rtx_insn *insns;
>> +unsigned int model = SYMBOL_REF_TLS_MODEL (x);
>> +
>> +switch (model)
>> +  {
>> +  case TLS_MODEL_GLOBAL_DYNAMIC:
>> +   if (TARGET_GNU2_TLS)
>> + {
>> +   abort ();
>> + }
>
>
> Use gcc_unreachable ().
>
>> +   else
>> + {
>> +   /* Original scheme.  */
>> +   insns = arm_call_tls_get_addr_fdpic (x, reg, &ret,
>> TLS_GD32_FDPIC);
>> +   dest = gen_reg_rtx (Pmode);
>> +   emit_libcall_block (insns, dest, ret, x);
>> + }
>> +   return dest;
>> +   break;
>> +
>> +  case TLS_MODEL_LOCAL_DYNAMIC:
>> +   if (TARGET_GNU2_TLS)
>> + {
>> +   abort ();
>> + }
>
>
> Likewise.
>
>> +   else
>> + {
>> +   insns = arm_call_tls_get_addr_fdpic (x, reg, &ret,
>> TLS_LDM32_FDPIC);
>> +   /* Attach a unique REG_EQUIV, to allow the RTL optimizers to
>> +  share the LDM result with other LD model accesses.  */
>> +   eqv = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, const1_rtx),
>> + UNSPEC_TLS);
>> +   dest = gen_reg_rtx (Pmode);
>> +   emit_libcall_block (insns, dest, ret, eqv);
>> +
>> +   /* Load the addend.  */
>> +   addend = gen_rtx_UNSPEC (Pmode,
>> +gen_rtvec (2, x, GEN_INT
>> (TLS_LDO32)),
>> +UNSPEC_TLS);
>> +   addend = force_reg (SImode, gen_rtx_CONST (SImode, addend));
>
>
> Nit I'm guessing, but I think this SImode should be Pmode.
>
>> +   dest = gen_rtx_PLUS (Pmode, dest, addend);
>> + }
>> +   return dest;
>> +   break;
>> +
>> +  case TLS_MODEL_INITIAL_EXEC:
>> +   sum = gen_rtx_UNSPEC (Pmode,
>> + gen_rtvec (2, x, GEN_INT (TLS_IE32_FDPIC)),
>> + UNSPEC_TLS);
>> +   reg = load_tls_operand (sum, reg);
>> +   /* FIXME: optimize below? */
>
>
> Not a fan of such FIXMEs. Let's either optimise it now or leave the comment
> out.
>
>> +   emit_insn (gen_addsi3 (reg, reg, gen_rtx_REG (Pmode, 9)));
>> +   emit_insn (gen_movsi (reg, gen_rtx_MEM (Pmode, reg)));
>
>
> You can use the shorter emit_move_insn (). I think there are other places in
> the series
> where you can do that as well.
>
>> +   tp 

Re: [ARM/FDPIC 13/21] [ARM] FDPIC: Support unwinding across thumb2 signal trampoline

2018-06-10 Thread Christophe Lyon
On 8 June 2018 at 13:01, Kyrill  Tkachov  wrote:
> Hi Christophe,
>
> Similar comments to patch 11/21
>
>
> On 25/05/18 09:03, Christophe Lyon wrote:
>>
>> 2018-XX-XX  Christophe Lyon 
>> Mickaël Guêné 
>>
>> libgcc/
>> * unwind-arm-common.inc (FDPIC_T2_LDR_R12_WITH_FUNCDESC)
>> (FDPIC_T2_LDR_R9_WITH_GOT, FDPIC_T2_LDR_PC_WITH_RESTORER): New.
>> (__gnu_personality_sigframe_fdpic): Support Thumb address.
>> (get_eit_entry): Support Thumb code.
>>
>> Change-Id: I2bb8994e733e48a89c6f4e0682921186c086f8bc
>>
>> diff --git a/libgcc/unwind-arm-common.inc b/libgcc/unwind-arm-common.inc
>> index 80d1e88..7de4033 100644
>> --- a/libgcc/unwind-arm-common.inc
>> +++ b/libgcc/unwind-arm-common.inc
>> @@ -38,6 +38,9 @@
>>  #define FDPIC_LDR_R12_WITH_FUNCDESC 0xe59fc004
>>  #define FDPIC_LDR_R9_WITH_GOT   0xe59c9004
>>  #define FDPIC_LDR_PC_WITH_RESTORER  0xe59cf000
>> +#define FDPIC_T2_LDR_R12_WITH_FUNCDESC  0xc008f8df
>> +#define FDPIC_T2_LDR_R9_WITH_GOT   0x9004f8dc
>> +#define FDPIC_T2_LDR_PC_WITH_RESTORER   0xf000f8dc
>>  #define FDPIC_FUNCDESC_OFFSET   12
>>  /* Signal frame offsets.  */
>>  #define ARM_NEW_RT_SIGFRAME_UCONTEXT0x80
>> @@ -228,7 +231,7 @@ __gnu_personality_sigframe_fdpic (_Unwind_State state,
>>  _Unwind_VRS_Get (context, _UVRSC_CORE, R_SP, _UVRSD_UINT32, &sp);
>>  _Unwind_VRS_Get (context, _UVRSC_CORE, R_PC, _UVRSD_UINT32, &pc);
>>
>> -funcdesc = *(unsigned int *)(pc + FDPIC_FUNCDESC_OFFSET);
>> +funcdesc = *(unsigned int *)((pc & ~1) + FDPIC_FUNCDESC_OFFSET);
>>  handler = *(unsigned int *)(funcdesc);
>>  first_handler_instruction = *(unsigned int *)(handler & ~1);
>>
>> @@ -277,10 +280,13 @@ get_eit_entry (_Unwind_Control_Block *ucbp, _uw
>> return_address)
>>/* If we are unwinding a signal handler then perhaps we have
>>   reached a trampoline.  Try to detect jump to restorer
>>   sequence.  */
>> - _uw *pc = (_uw *)((return_address+2) & ~3);
>> - if (pc[0] == FDPIC_LDR_R12_WITH_FUNCDESC
>> - && pc[1] == FDPIC_LDR_R9_WITH_GOT
>> - && pc[2] == FDPIC_LDR_PC_WITH_RESTORER)
>> + _uw *pc = (_uw *)((return_address+2) & ~1);
>> + if ((pc[0] == FDPIC_LDR_R12_WITH_FUNCDESC
>> +  && pc[1] == FDPIC_LDR_R9_WITH_GOT
>> +  && pc[2] == FDPIC_LDR_PC_WITH_RESTORER)
>> + || (pc[0] == FDPIC_T2_LDR_R12_WITH_FUNCDESC
>> + && pc[1] == FDPIC_T2_LDR_R9_WITH_GOT
>> + && pc[2] == FDPIC_T2_LDR_PC_WITH_RESTORER))
>>  {
>
>
> This largely overwrites and extends code added in patch 11/21. Can't we just
> merge the two
> patches into a final sane one?
>

Sure. It was developed in two steps, and I thought it was easier to
review in small pieces, but I can merge them.

> Thanks,
> Kyrill
>
>
>>struct funcdesc_t *funcdesc = (struct funcdesc_t *)
>>  &__gnu_personality_sigframe_fdpic;
>> @@ -309,13 +315,16 @@ get_eit_entry (_Unwind_Control_Block *ucbp, _uw
>> return_address)
>>/* If we are unwinding a signal handler then perhaps we have
>>   reached a trampoline.  Try to detect jump to restorer
>>   sequence.  */
>> -  _uw *pc = (_uw *)((return_address+2) & ~3);
>> -  if (pc[0] == FDPIC_LDR_R12_WITH_FUNCDESC
>> - && pc[1] == FDPIC_LDR_R9_WITH_GOT
>> - && pc[2] == FDPIC_LDR_PC_WITH_RESTORER)
>> +  _uw *pc = (_uw *)((return_address+2) & ~1);
>> +  if ((pc[0] == FDPIC_LDR_R12_WITH_FUNCDESC
>> +  && pc[1] == FDPIC_LDR_R9_WITH_GOT
>> +  && pc[2] == FDPIC_LDR_PC_WITH_RESTORER)
>> + || (pc[0] == FDPIC_T2_LDR_R12_WITH_FUNCDESC
>> + && pc[1] == FDPIC_T2_LDR_R9_WITH_GOT
>> + && pc[2] == FDPIC_T2_LDR_PC_WITH_RESTORER))
>>  {
>> - struct funcdesc_t *funcdesc = (struct funcdesc_t *)
>> -   &__gnu_personality_sigframe_fdpic;
>> + struct funcdesc_t *funcdesc
>> +   = (struct funcdesc_t *) &__gnu_personality_sigframe_fdpic;
>>
>>UCB_PR_ADDR (ucbp) = funcdesc->ptr;
>>UCB_PR_GOT (ucbp) = funcdesc->got;
>> @@ -335,13 +344,16 @@ get_eit_entry (_Unwind_Control_Block *ucbp, _uw
>> return_address)
>>/* If we are unwinding a signal handler then perhaps we have
>>   reached a trampoline.  Try to detect jump to restorer
>>   sequence.  */
>> -  _uw *pc = (_uw *)((return_address+2) & ~3);
>> -  if (pc[0] == FDPIC_LDR_R12_WITH_FUNCDESC
>> - && pc[1] == FDPIC_LDR_R9_WITH_GOT
>> - && pc[2] == FDPIC_LDR_PC_WITH_RESTORER)
>> +  _uw *pc = (_uw *)((return_address+2) & ~1);
>> +  if ((pc[0] == FDPIC_LDR_R12_WITH_FUNCDESC
>> +  && pc[1] == FDPIC_LDR_R9_WITH_GOT
>> +  && pc[2] == FDPIC_LDR_PC_WITH_RESTORER)
>> + || (pc[0] == FDPIC_T2_LDR_R12_WITH_FUNCDESC
>> + && pc[1] == FDPIC_T2_LDR_R9_WITH_GOT
>> +