Re: Fortran vector math header

[Jakub Jelinek]

On Mon, Jan 21, 2019 at 08:47:42AM +0100, Martin Liška wrote:
> diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
> index 3314e176881..5c7c062574b 100644
> --- a/gcc/fortran/decl.c
> +++ b/gcc/fortran/decl.c
> @@ -11351,6 +11351,7 @@ match
>  gfc_match_gcc_builtin (void)
>  {
>char builtin[GFC_MAX_SYMBOL_LEN + 1];
> +  char target[GFC_MAX_SYMBOL_LEN + 1];
>  
>if (gfc_match (" ( %n ) attributes simd", builtin) != MATCH_YES)
>  return MATCH_ERROR;
> @@ -11361,6 +11362,24 @@ gfc_match_gcc_builtin (void)
>else if (gfc_match (" ( inbranch ) ") == MATCH_YES)
>  clause = SIMD_INBRANCH;
>  
> +  if (gfc_match (" if ( %n ) ", target) == MATCH_YES)
> +{
> +  unsigned HOST_WIDE_INT size_of_long
> + = tree_to_uhwi (TYPE_SIZE_UNIT (long_integer_type_node));
> +  if (strcmp (target, "lp64") == 0)
> + {
> +   if (size_of_long != 8)
> + return MATCH_YES;

__LP64__ macro is defined if:
  if (TYPE_PRECISION (long_integer_type_node) == 64
  && POINTER_SIZE == 64
  && TYPE_PRECISION (integer_type_node) == 32)
All of these are middle-end types or target macros, so you should be able to
test that in the Fortran FE too.

> + }
> +  else if (strcmp (target, "ilp32") == 0)
> + {
> +   if (size_of_long != 4)
> + return MATCH_YES;

For this obviously as well.

> + }
> +  else
> + return MATCH_ERROR;
> +}
> +
>if (gfc_vectorized_builtins == NULL)
>  gfc_vectorized_builtins = new hash_map ();

Jakub

Re: Fortran vector math header

[Martin Liška]

On 1/18/19 9:39 AM, Jakub Jelinek wrote:
> On Fri, Jan 18, 2019 at 09:18:33AM +0100, Martin Liška wrote:
>> What about something as simple as this:
>>
>> diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
>> index 3314e176881..2f2b965f97d 100644
>> --- a/gcc/fortran/decl.c
>> +++ b/gcc/fortran/decl.c
>> @@ -11361,6 +11361,11 @@ gfc_match_gcc_builtin (void)
>>else if (gfc_match (" ( inbranch ) ") == MATCH_YES)
>>  clause = SIMD_INBRANCH;
>>  
>> +  /* Filter builtins defined only for 64-bit compilation mode.  */
>> +  if (gfc_match (" ( 64bit ) ") == MATCH_YES
>> +  && tree_to_uhwi (TYPE_SIZE_UNIT (long_integer_type_node)) != 64)
>> +return MATCH_YES;
>> +
>>if (gfc_vectorized_builtins == NULL)
>>  gfc_vectorized_builtins = new hash_map ();
>>  
>> That would allow to write:
>> !GCC$ builtin (cos) attributes simd (notinbranch) (64bit)
> 
> That feels too hacky to me.
> We could have
> !GCC$ builtin (cos) attributes simd (notinbranch) if('x86_64-linux-gnu')
> or similar if we can agree and get somehow canonical names of the multilib
> targets based on options, or just if('lp64'), if('ilp32'), or whatever other
> identifiers.  The multiarch-style strings I'm afraid we have no way to
> propagate to f951 even on multiarch targets, if I understand it right, it is
> present there just in the form of substrings in the multi os directories.
> For some other strings, we'd need to come up with something that generates
> the strings for us, e.g. like config/*/*-d.c does for D have something
> similar for Fortran, and then we could use just x86_64, x32 and x86 or
> whatever else we choose (I guess the OS isn't that important, different OSes
> would have different headers).  Even x86_64 vs. x32 vs. x86 shows that it
> isn't possible to differentiate multilibs just based on sizes (kinds) of C
> types, and even querying those is complicated because one needs to use the
> use iso_c_binding, only: c_ptr etc. to get those into the scope, which isn't
> something we want in these headers.
> In any case, glibc would need to agree with gfortran on these identifiers.
> 
>   Jakub
> 

Hello.

I like the if('lp64'), if('ilp32') approach and I'm sending patch candidate for 
that.
Would it be accepted by glibc folks?

Thanks,
Martin
>From d21476c2223e6e5d12a949b4e2ba26417e37852b Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 21 Jan 2019 08:46:06 +0100
Subject: [PATCH] Support if statement in !GCC$ builtin directive.

---
 gcc/fortran/decl.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 3314e176881..5c7c062574b 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -11351,6 +11351,7 @@ match
 gfc_match_gcc_builtin (void)
 {
   char builtin[GFC_MAX_SYMBOL_LEN + 1];
+  char target[GFC_MAX_SYMBOL_LEN + 1];
 
   if (gfc_match (" ( %n ) attributes simd", builtin) != MATCH_YES)
 return MATCH_ERROR;
@@ -11361,6 +11362,24 @@ gfc_match_gcc_builtin (void)
   else if (gfc_match (" ( inbranch ) ") == MATCH_YES)
 clause = SIMD_INBRANCH;
 
+  if (gfc_match (" if ( %n ) ", target) == MATCH_YES)
+{
+  unsigned HOST_WIDE_INT size_of_long
+	= tree_to_uhwi (TYPE_SIZE_UNIT (long_integer_type_node));
+  if (strcmp (target, "lp64") == 0)
+	{
+	  if (size_of_long != 8)
+	return MATCH_YES;
+	}
+  else if (strcmp (target, "ilp32") == 0)
+	{
+	  if (size_of_long != 4)
+	return MATCH_YES;
+	}
+  else
+	return MATCH_ERROR;
+}
+
   if (gfc_vectorized_builtins == NULL)
 gfc_vectorized_builtins = new hash_map ();
 
-- 
2.20.1

Re: [PATCH] PR fortran/69101 -- IEEE_SELECTED_REAL_KIND part I

[Steve Kargl]

On Sun, Jan 20, 2019 at 05:04:24PM -0800, Steve Kargl wrote:
> On Tue, Jan 08, 2019 at 10:27:25PM +0100, Thomas Koenig wrote:
> > Hi Steve,
> > 
> > > Well, that was quick.  Moving code around is problematic.
> > 
> > Thanks for checking. The patch is OK for trunk.
> > 
> 
> Thanks.  I decided to see if long term approach would work.
> It almost does.  The attached patch put ieee_selected_real_kind
> into the table of intrinsic functions.  It automatically gets
> us a generic routine with argument chekcing and simplification.
> This just works:
> 
> program foo
>use ieee_arithmetic, only : ieee_selected_real_kind
>integer, parameter :: n = ieee_selected_real_kind(6_2)
>i = 6
>print *, n, ieee_selected_real_kind(6_8), ieee_selected_real_kind(i)
> end program foo
> 
> Now, the downside.  I can't finesse rename on USE.  This does not
> work, and I'm stuck at the moment.
> 
> subroutine bar
>use ieee_arithmetic, only : isrk => ieee_selected_real_kind
>integer, parameter :: n = isrk(6)
>i = 6
>print *, n, isrk(6), isrk(i)
> end subroutine bar
> 
> If anyone has an idea, I would be quite happy to hear about it.
> 

Well, I found a way to at least deal with the renaming issue.
It is ugly, and won't be pursued.

-- 
Steve

Re: Fix random_sample_n and random_shuffle when RAND_MAX is small

[Giovanni Bajo]

Il giorno mar 15 gen 2019 alle ore 03:38 Jonathan Wakely 
ha scritto:

> On 12/12/18 22:31 +0100, Giovanni Bajo wrote:
> >Hello,
> >
> >we hit a bug today while cross-compiling a C++ program with mingw32:
> >if random_shuffle or random_sample_n are called with a sequence of
> >elements whose length is higher than RAND_MAX, the functions don't
> >behave as expected because they ignore elements beyond RAND_MAX. This
> >does not happen often on Linux where glibc defines RAND_MAX to 2**31,
> >but mingw32 (all released versions) relies on the very old msvcrt.lib,
> >where RAND_MAX is just 2**15.
> >
> >I found mentions of this problem in 2011
> >(
> http://mingw-users.1079350.n2.nabble.com/RAND-MAX-still-16bit-td6299546.html
> )
> >and 2006 (
> https://mingw-users.narkive.com/gAIO4G5V/rand-max-problem-why-is-it-only-16-bit
> ).
> >
> >I'm attaching a proof-of-concept patch that fixes the problem by
> >introducing an embedded xorshift generator, seeded with std::rand (so
> >that the functions still depend on srand — it looks like this is not
> >strictly required by the standard, but it sounds like a good thing to
> >do for backward compatibility with existing programs). I was wondering
> >if this approach is OK or something else is preferred.
>
> I'd prefer not to introduce that change unconditionally. The existing
> code works fine when std::distance(first, last) < RAND_MAX, and as we
> have random access iterators we can check that cheaply.
>
> We'd prefer a bug report in Bugzilla with a testcase that demonstrates
> the bug. A portable regression test for our testsuite might not be
> practical if it needs more than RAND_MAX elements, but one that runs
> for mingw and verifies the fix there would be needed.
>
> See https://gcc.gnu.org/contribute.html#patches for guidelines for
> submitting patches (and the rest of the page for other requirements,
> like copyright assignment or disclaimers).
>

Thanks Jonathan. We have opened a Bugzilla report here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88935

In the bug, we highlighted that the current algorithm is also (less
severely) broken when the number of elements is less but close to RAND_MAX;
the farther you move away from RAND_MAX, the better it becomes. Would you
still prefer to have a different version of the algorithm, gated by a
comparison to RAND_MAX? Our patch fixes everything by switching to an
inline 64-bit PRNG which is seeded by std::rand().
-- 
Giovanni Bajo   ::  ra...@develer.com
Develer S.r.l.  ::  http://www.develer.com

Re: [PATCH] PR fortran/69101 -- IEEE_SELECTED_REAL_KIND part I

[Steve Kargl]

On Tue, Jan 08, 2019 at 10:27:25PM +0100, Thomas Koenig wrote:
> Hi Steve,
> 
> > Well, that was quick.  Moving code around is problematic.
> 
> Thanks for checking. The patch is OK for trunk.
> 

Thanks.  I decided to see if long term approach would work.
It almost does.  The attached patch put ieee_selected_real_kind
into the table of intrinsic functions.  It automatically gets
us a generic routine with argument chekcing and simplification.
This just works:

program foo
   use ieee_arithmetic, only : ieee_selected_real_kind
   integer, parameter :: n = ieee_selected_real_kind(6_2)
   i = 6
   print *, n, ieee_selected_real_kind(6_8), ieee_selected_real_kind(i)
end program foo

Now, the downside.  I can't finesse rename on USE.  This does not
work, and I'm stuck at the moment.

subroutine bar
   use ieee_arithmetic, only : isrk => ieee_selected_real_kind
   integer, parameter :: n = isrk(6)
   i = 6
   print *, n, isrk(6), isrk(i)
end subroutine bar

If anyone has an idea, I would be quite happy to hear about it.

-- 
Steve
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c	(revision 268106)
+++ gcc/fortran/check.c	(working copy)
@@ -4426,6 +4426,59 @@ gfc_check_selected_real_kind (gfc_expr *p, gfc_expr *r
 
 
 bool
+gfc_check_ieee_selected_real_kind (gfc_expr *p, gfc_expr *r, gfc_expr *radix)
+{
+  gfc_intrinsic_sym *sym;
+
+  sym = gfc_find_function ("ieee_selected_real_kind");
+  if (!sym->ieee)
+{
+  gfc_warning_now (0, "check: whoops at %C");
+  return false;
+}
+
+  if (p == NULL && r == NULL
+  && !gfc_notify_std (GFC_STD_F2008, "%qs with neither % nor % "
+			  "argument at %L", gfc_current_intrinsic,
+			  gfc_current_intrinsic_where))
+return false;
+
+  if (p)
+{
+  if (!type_check (p, 0, BT_INTEGER))
+	return false;
+
+  if (!scalar_check (p, 0))
+	return false;
+}
+
+  if (r)
+{
+  if (!type_check (r, 1, BT_INTEGER))
+	return false;
+
+  if (!scalar_check (r, 1))
+	return false;
+}
+
+  if (radix)
+{
+  if (!gfc_notify_std (GFC_STD_F2008, "%qs intrinsic with "
+			   "RADIX argument at %L", gfc_current_intrinsic,
+			   >where))
+	return false;
+
+  if (!type_check (radix, 1, BT_INTEGER))
+	return false;
+
+  if (!scalar_check (radix, 1))
+	return false;
+}
+
+  return true;
+}
+
+bool
 gfc_check_set_exponent (gfc_expr *x, gfc_expr *i)
 {
   if (!type_check (x, 0, BT_REAL))
Index: gcc/fortran/gfortran.h
===
--- gcc/fortran/gfortran.h	(revision 268106)
+++ gcc/fortran/gfortran.h	(working copy)
@@ -592,7 +592,7 @@ enum gfc_isym_id
   GFC_ISYM_SPREAD,
   GFC_ISYM_SQRT,
   GFC_ISYM_SRAND,
-  GFC_ISYM_SR_KIND,
+  GFC_ISYM_SR_KIND, GFC_ISYM_IEEE_SR_KIND, 
   GFC_ISYM_STAT,
   GFC_ISYM_STOPPED_IMAGES,
   GFC_ISYM_STORAGE_SIZE,
@@ -2071,7 +2071,7 @@ typedef struct gfc_intrinsic_sym
   gfc_typespec ts;
   unsigned elemental:1, inquiry:1, transformational:1, pure:1,
 generic:1, specific:1, actual_ok:1, noreturn:1, conversion:1,
-from_module:1, vararg:1;
+from_module:1, vararg:1, ieee:1;
 
   int standard;
 
Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c	(revision 268106)
+++ gcc/fortran/intrinsic.c	(working copy)
@@ -2891,6 +2891,15 @@ add_functions (void)
 
   make_generic ("selected_real_kind", GFC_ISYM_SR_KIND, GFC_STD_F95);
 
+  add_sym_3 ("ieee_selected_real_kind", GFC_ISYM_IEEE_SR_KIND,
+	 CLASS_TRANSFORMATIONAL, ACTUAL_NO, BT_INTEGER, di, GFC_STD_F95,
+	 gfc_check_ieee_selected_real_kind,
+	 gfc_simplify_ieee_selected_real_kind, NULL,
+	 p, BT_INTEGER, di, OPTIONAL, r, BT_INTEGER, di, OPTIONAL,
+	 "radix", BT_INTEGER, di, OPTIONAL);
+
+  make_generic ("ieee_selected_real_kind", GFC_ISYM_IEEE_SR_KIND, GFC_STD_F95);
+
   add_sym_2 ("set_exponent", GFC_ISYM_SET_EXPONENT, CLASS_ELEMENTAL, ACTUAL_NO, BT_REAL, dr, GFC_STD_F95,
 	 gfc_check_set_exponent, gfc_simplify_set_exponent,
 	 gfc_resolve_set_exponent,
Index: gcc/fortran/intrinsic.h
===
--- gcc/fortran/intrinsic.h	(revision 268106)
+++ gcc/fortran/intrinsic.h	(working copy)
@@ -150,6 +150,8 @@ bool gfc_check_secnds (gfc_expr *);
 bool gfc_check_selected_char_kind (gfc_expr *);
 bool gfc_check_selected_int_kind (gfc_expr *);
 bool gfc_check_selected_real_kind (gfc_expr *, gfc_expr *, gfc_expr *);
+bool gfc_check_ieee_selected_real_kind (gfc_expr *, gfc_expr *, gfc_expr *);
+
 bool gfc_check_set_exponent (gfc_expr *, gfc_expr *);
 bool gfc_check_shape (gfc_expr *, gfc_expr *);
 bool gfc_check_shift (gfc_expr *, gfc_expr *);
@@ -397,6 +399,8 @@ gfc_expr *gfc_simplify_scan (gfc_expr *, gfc_expr *, g
 gfc_expr *gfc_simplify_selected_char_kind (gfc_expr *);
 gfc_expr *gfc_simplify_selected_int_kind (gfc_expr *);
 gfc_expr *gfc_simplify_selected_real_kind (gfc_expr 

Re: [PR88579, patch] Calculating power of powers of two

[Harald Anlauf]

I was too anxious pressing the send button so that I forgot to mention:

Regtested with no new regressions on x86_64-pc-linux-gnu.

Sorry for that.

Harald

On 01/20/19 23:18, Harald Anlauf wrote:
> Dear all,
> 
> here's my revised patch for the treatment of (2**e) ** n and (- 2**e) **
> n, trying to take into account the bitwidth of the result.
> 
> I've also extended the testcase to sample different integer kinds.
> 
> ChangeLogs see below.
> 
> Note: I don't have commit rights, so please somebody else take care
> of it after review.
> 
> Thanks,
> Harald

Re: [PR88579, patch] Calculating power of powers of two

[Harald Anlauf]

Dear all,

here's my revised patch for the treatment of (2**e) ** n and (- 2**e) **
n, trying to take into account the bitwidth of the result.

I've also extended the testcase to sample different integer kinds.

ChangeLogs see below.

Note: I don't have commit rights, so please somebody else take care
of it after review.

Thanks,
Harald

2019-01-20  Harald Anlauf  

PR fortran/88579
* trans-expr.c (gfc_conv_power_op): Handle cases of (2**e) ** integer
and (- 2**e) ** integer.



2019-01-20  Harald Anlauf  

PR fortran/88579
* gfortran.dg/power_8.f90: New test.



On 01/19/19 16:45, Thomas Koenig wrote:
> Hi Harald,
> 
> 
>> now that my copyright assignment is on file, here's my first attempt
>> at a non-trivial patch.
> 
> Excellent :-)
> 
>> I have slightly rearranged Thomas' code, removed some, and added
>> generalizations for (2**e)**n and (-2**e)**n.  It works with the
>> testcase below.
> 
> That looks good.
> 
>> I'd like some feedback how to properly handle the case when
>> (-2**e) = -HUGE()-1, i.e. the number that falls outside the
>> symmetric range.  Should one skip that one?  Does anyone have
>> a template how to detect that case easily?  Regtesting otherwise
>> would fail for the last test (which most likely should be removed
>> later).
> 
> I think it is fine to fall back on the library version (which still
> exists) for that one.
> 
> The best way to check this is probably by getting the bit size
> of the expression by using something like
> 
>   ikind = gfc_validate_kind (BT_INTEGER, expr->ts.kind, false);
>   bit_size = gfc_integer_kinds[ikind].bit_size;
> 
> and take it from there.
> 
> Regards
> 
> Thomas
> 
> 

Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c	(revision 268106)
+++ gcc/fortran/trans-expr.c	(working copy)
@@ -3060,8 +3060,16 @@
   && TREE_CODE (TREE_TYPE (rse.expr)) == INTEGER_TYPE)
 {
   wi::tree_to_wide_ref wlhs = wi::to_wide (lse.expr);
-  HOST_WIDE_INT v;
+  HOST_WIDE_INT v, w;
+  int kind, ikind, bit_size;
+
   v = wlhs.to_shwi ();
+  w = abs (v);
+
+  kind = expr->value.op.op1->ts.kind;
+  ikind = gfc_validate_kind (BT_INTEGER, kind, false);
+  bit_size = gfc_integer_kinds[ikind].bit_size;
+
   if (v == 1)
 	{
 	  /* 1**something is always 1.  */
@@ -3068,11 +3076,28 @@
 	  se->expr = build_int_cst (TREE_TYPE (lse.expr), 1);
 	  return;
 	}
-  else if (v == 2 || v == 4 || v == 8 || v == 16)
+  else if (v == -1)
 	{
-	  /* 2**n = 1 0 && ((w & (w-1)) == 0) && ((w >> (bit_size-1)) == 0))
+	{
+	  /* Here v is +/- 2**e.  The further simplification uses
+	 2**n = 1 0)
+	{
+	  se->expr = tmp1;
+	}
+	  else
+	{
+	  /* for v < 0, calculate v**n = |v|**n * (-1)**n */
+	  tree tmp2;
+	  tmp2 = fold_build2_loc (input_location, BIT_AND_EXPR, type,
+  rse.expr, build_int_cst (type, 1));
+	  tmp2 = fold_build2_loc (input_location, LSHIFT_EXPR, type,
+  tmp2, build_int_cst (type, 1));
+	  tmp2 = fold_build2_loc (input_location, MINUS_EXPR, type,
+  build_int_cst (type, 1), tmp2);
+	  se->expr = fold_build2_loc (input_location, MULT_EXPR, type,
+	  tmp1, tmp2);
+	}
 	  return;
 	}
-  else if (v == -1)
-	{
-	  /* (-1)**n is 1 - ((n & 1) << 1) */
-	  tree type;
-	  tree tmp;
-
-	  type = TREE_TYPE (lse.expr);
-	  tmp = fold_build2_loc (input_location, BIT_AND_EXPR, type,
- rse.expr, build_int_cst (type, 1));
-	  tmp = fold_build2_loc (input_location, LSHIFT_EXPR, type,
- tmp, build_int_cst (type, 1));
-	  tmp = fold_build2_loc (input_location, MINUS_EXPR, type,
- build_int_cst (type, 1), tmp);
-	  se->expr = tmp;
-	  return;
-	}
 }
 
   gfc_int4_type_node = gfc_get_int_type (4);
Index: gcc/testsuite/gfortran.dg/power_8.f90
===
--- gcc/testsuite/gfortran.dg/power_8.f90   (nonexistent)
+++ gcc/testsuite/gfortran.dg/power_8.f90   (working copy)
@@ -0,0 +1,64 @@
+! { dg-do run }
+! { dg-additional-options "-fdump-tree-original" }
+!
+! PR88579 - Test optimizations for bases that are powers of 2 or -2.
+program p
+  implicit none
+  integer(4) :: i, u
+  integer(1) :: j, v
+  integer(2) :: k, w
+  integer(8) :: z
+  ! Test selected positive bases
+  u = 1
+  do i=1,5
+ u = u * 64_4
+ if (u /= 64_4 ** i) stop 1
+  end do
+  z = 1
+  do i=1,7
+ z = z * 256_8
+ if (z /= 256_8 ** i) stop 2
+  end do
+  z = 1
+  do i=1,3
+ z = z * 65536_8
+ if (z /= 65536_8 ** i) stop 3
+  end do
+  ! Test selected negative bases and integer kind combinations
+  u = 1
+  do 

Re: [PR 87615] Limit AA walking in IPA summary generation

[Martin Jambor]

On Thu, Dec 20 2018, Jan Hubicka wrote:
> Dne 2018-12-20 15:36, Martin Jambor napsal:
>> Hi,
>> 
>> Ping:
>> 
>> On Fri, Dec 07 2018, Martin Jambor wrote:
>> Hi,
>> 
>> the patch below adds alias analysis (AA) walk limiting to all
>> walk_alias_vdefs calls invoked as IPA-CP and ipa-fnsummary summary
>> generation.  Eventually the two should be unified into just one phase
>> but that is something for stage1.  This patch gives them both
>> independent budgets, both initialized to
>> PARAM_VALUE(PARAM_IPA_MAX_AA_STEPS) - as a consequence, the real limit
>> is twice the given value.
>> 
>> I'm not sure whether the ipa-prop AA limiting was written before
>> walk_alias_vdefs had its limit parameter added, but I changed the code
>> to use it and also modified the budget counter to go from the parameter
>> value down to zero as opposed to incrementing it and checking manually
>> before each call into AA.  I always pass the current budget + 1 to
>> walk_alias_vdefs limit so that I do not have to check whether it is 
>> zero
>> which means no limiting at all, and also so that loads from a parameter
>> right at the top of a function get detected as unmodified even if some
>> previous analysis already used up all the budget.
>> 
>> As far as the testcase for PR 87615 is concerned, this patch makes the
>> compile time go down from approx. 340 seconds to about 160 seconds on 
>> my
>> desktop and IPA-CP gets zeros in -ftime-reportbut we still do not reach
>> the 40 second compile time we get with -fno-ipa-cp -fno-inline.
>> 
>> Bootstrapped and tested on x86_64-linux.  OK for trunk?
>> 
>> Thanks,
>> 
>> Martin
>> 
>> 
>> 2018-12-06  Martin Jambor  
>> 
>>  PR ipa/87615
>>  * ipa-prop.h (struct ipa_func_body_info): Replaced field aa_walked
>>  with aa_walk_budget.
>>  * cgraph.h (ipa_polymorphic_call_context::get_dynamic_type): Add
>>  aa_walk_budget_p parameter.
>>  * ipa-fnsummary.c (unmodified_parm_1): New parameter fbi.  Limit AA
>>  walk.  Updated all callers.
>>  (unmodified_parm): New parameter fbi, pass it to unmodified_parm_1.
>>  (eliminated_by_inlining_prob): New parameter fbi, pass it on to
>>  unmodified_parm.
>>  (will_be_nonconstant_expr_predicate): New parameter fbi, removed
>>  parameter info.  Extract info from fbi.  Pass fbi to recursive calls
>>  and to unmodified_parm.
>>  (phi_result_unknown_predicate): New parameter fbi, removed parameter
>>  info, updated call to will_be_nonconstant_expr_predicate.
>>  (param_change_prob): New parameter fbi, limit AA walking.
>>  (analyze_function_body): Initialize aa_walk_budget in fbi.  Update
>>  calls to various above functions.
>>  * ipa-polymorphic-call.c (get_dynamic_type): Add aa_walk_budget_p
>>  parameter.  Use it to limit AA walking.
>>  * ipa-prop.c (detect_type_change_from_memory_writes): New parameter
>>  fbi, limit AA walk.
>>  (detect_type_change): New parameter fbi, pass it on to
>>  detect_type_change_from_memory_writes.
>>  (detect_type_change_ssa): Likewise.
>>  (aa_overwalked): Removed.
>>  (parm_preserved_before_stmt_p): Assume fbi is never NULL, stream line
>>  accordingly, adjust to the neew AA limiting scheme.
>>  (parm_ref_data_preserved_p): Likewise.
>>  (ipa_compute_jump_functions_for_edge): Adjust call to
>>  get_dynamic_type.
>>  (ipa_analyze_call_uses): Likewise.
>>  (ipa_analyze_virtual_call_uses): Pass fbi to detect_type_change_ssa.
>>  (ipa_analyze_node): Initialize aa_walk_budget.
>>  (ipcp_transform_function): Likewise.
>>  * tree-ssa-sccvn.c (eliminate_dom_walker::eliminate_stmt): Update call
>>  to get_dynamic_type.
>
> OK
>

My apologies for forgetting about this and committing it only now (after
a re-bootstrapping and re-testing on an x86_64-limux).

Thanks,

Martin


2019-01-20  Martin Jambor  

PR ipa/87615
* ipa-prop.h (struct ipa_func_body_info): Replaced field aa_walked
with aa_walk_budget.
* cgraph.h (ipa_polymorphic_call_context::get_dynamic_type): Add
aa_walk_budget_p parameter.
* ipa-fnsummary.c (unmodified_parm_1): New parameter fbi.  Limit AA
walk.  Updated all callers.
(unmodified_parm): New parameter fbi, pass it to unmodified_parm_1.
(eliminated_by_inlining_prob): New parameter fbi, pass it on to
unmodified_parm.
(will_be_nonconstant_expr_predicate): New parameter fbi, removed
parameter info.  Extract info from fbi.  Pass fbi to recursive calls
and to unmodified_parm.
(phi_result_unknown_predicate): New parameter fbi, removed parameter
info, updated call to will_be_nonconstant_expr_predicate.
(param_change_prob): New parameter fbi, limit AA walking.
(analyze_function_body): Initialize aa_walk_budget in fbi.  Update
calls to various above functions.
* ipa-polymorphic-call.c (get_dynamic_type): Add aa_walk_budget_p
  

[PATCH, zlib] Rename libzgcj_convenience to libz_convenience

[Iain Buclaw]

Hi,

As a prerequisite for enabling subdir-objects to libphobos configure
scripts, the build should be linking to a zlib convenience library,
rather than building the zlib sources directly from libphobos.

Looking at the existing configure scripts, there's already a
libzgcj_convenience.a, it is not in use any more as far as I can tell,
neither is target_all.

Is it OK to drop the reference to gcj in the name?

-- 
Iain
---
zlib/ChangeLog.gcj:

2019-01-20  Iain Buclaw  

* Makefile.am (noinst_LTLIBRARIES): Rename libzgcj_convience.la to
libz_convenience.la.
* Makefile.in: Regenerate.
* configure.ac: Remove target_all.
* configure: Regenerate.
---
diff --git a/zlib/Makefile.am b/zlib/Makefile.am
index 520f06592d8..29359614baa 100644
--- a/zlib/Makefile.am
+++ b/zlib/Makefile.am
@@ -11,8 +11,8 @@ inflate.h inftrees.c inftrees.h trees.c trees.h uncompr.c zconf.h \
 zconf.h.in zlib.h zutil.c zutil.h
 
 if TARGET_LIBRARY
-noinst_LTLIBRARIES = libzgcj_convenience.la
-libzgcj_convenience_la_SOURCES = $(ZLIB_SOURCES)
+noinst_LTLIBRARIES = libz_convenience.la
+libz_convenience_la_SOURCES = $(ZLIB_SOURCES)
 else
 toolexeclib_LIBRARIES = libz.a
 libz_a_SOURCES = $(ZLIB_SOURCES)
diff --git a/zlib/Makefile.in b/zlib/Makefile.in
index 062dc04e80d..7b99bd84c16 100644
--- a/zlib/Makefile.in
+++ b/zlib/Makefile.in
@@ -161,8 +161,8 @@ am__objects_1 = libz_a-adler32.$(OBJEXT) libz_a-compress.$(OBJEXT) \
 @TARGET_LIBRARY_FALSE@am_libz_a_OBJECTS = $(am__objects_1)
 libz_a_OBJECTS = $(am_libz_a_OBJECTS)
 LTLIBRARIES = $(noinst_LTLIBRARIES)
-libzgcj_convenience_la_LIBADD =
-am__libzgcj_convenience_la_SOURCES_DIST = adler32.c compress.c crc32.c \
+libz_convenience_la_LIBADD =
+am__libz_convenience_la_SOURCES_DIST = adler32.c compress.c crc32.c \
 	crc32.h deflate.c deflate.h gzguts.h gzread.c gzclose.c \
 	gzwrite.c gzlib.c infback.c inffast.c inffast.h inffixed.h \
 	inflate.c inflate.h inftrees.c inftrees.h trees.c trees.h \
@@ -170,14 +170,14 @@ am__libzgcj_convenience_la_SOURCES_DIST = adler32.c compress.c crc32.c \
 am__objects_2 = adler32.lo compress.lo crc32.lo deflate.lo gzread.lo \
 	gzclose.lo gzwrite.lo gzlib.lo infback.lo inffast.lo \
 	inflate.lo inftrees.lo trees.lo uncompr.lo zutil.lo
-@TARGET_LIBRARY_TRUE@am_libzgcj_convenience_la_OBJECTS =  \
+@TARGET_LIBRARY_TRUE@am_libz_convenience_la_OBJECTS =  \
 @TARGET_LIBRARY_TRUE@	$(am__objects_2)
-libzgcj_convenience_la_OBJECTS = $(am_libzgcj_convenience_la_OBJECTS)
+libz_convenience_la_OBJECTS = $(am_libz_convenience_la_OBJECTS)
 AM_V_lt = $(am__v_lt_@AM_V@)
 am__v_lt_ = $(am__v_lt_@AM_DEFAULT_V@)
 am__v_lt_0 = --silent
 am__v_lt_1 = 
-@TARGET_LIBRARY_TRUE@am_libzgcj_convenience_la_rpath =
+@TARGET_LIBRARY_TRUE@am_libz_convenience_la_rpath =
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
 am__v_P_0 = false
@@ -212,9 +212,9 @@ AM_V_CCLD = $(am__v_CCLD_@AM_V@)
 am__v_CCLD_ = $(am__v_CCLD_@AM_DEFAULT_V@)
 am__v_CCLD_0 = @echo "  CCLD" $@;
 am__v_CCLD_1 = 
-SOURCES = $(libz_a_SOURCES) $(libzgcj_convenience_la_SOURCES)
+SOURCES = $(libz_a_SOURCES) $(libz_convenience_la_SOURCES)
 DIST_SOURCES = $(am__libz_a_SOURCES_DIST) \
-	$(am__libzgcj_convenience_la_SOURCES_DIST)
+	$(am__libz_convenience_la_SOURCES_DIST)
 am__can_run_installinfo = \
   case $$AM_UPDATE_INFO_DIR in \
 n|no|NO) false;; \
@@ -378,7 +378,6 @@ srcdir = @srcdir@
 sysconfdir = @sysconfdir@
 target = @target@
 target_alias = @target_alias@
-target_all = @target_all@
 target_cpu = @target_cpu@
 target_os = @target_os@
 target_vendor = @target_vendor@
@@ -395,8 +394,8 @@ infback.c inffast.c inffast.h inffixed.h inflate.c \
 inflate.h inftrees.c inftrees.h trees.c trees.h uncompr.c zconf.h \
 zconf.h.in zlib.h zutil.c zutil.h
 
-@TARGET_LIBRARY_TRUE@noinst_LTLIBRARIES = libzgcj_convenience.la
-@TARGET_LIBRARY_TRUE@libzgcj_convenience_la_SOURCES = $(ZLIB_SOURCES)
+@TARGET_LIBRARY_TRUE@noinst_LTLIBRARIES = libz_convenience.la
+@TARGET_LIBRARY_TRUE@libz_convenience_la_SOURCES = $(ZLIB_SOURCES)
 @TARGET_LIBRARY_FALSE@toolexeclib_LIBRARIES = libz.a
 @TARGET_LIBRARY_FALSE@libz_a_SOURCES = $(ZLIB_SOURCES)
 @TARGET_LIBRARY_FALSE@libz_a_CFLAGS = $(AM_CFLAGS) $(PICFLAG)
@@ -534,8 +533,8 @@ clean-noinstLTLIBRARIES:
 	  rm -f $${locs}; \
 	}
 
-libzgcj_convenience.la: $(libzgcj_convenience_la_OBJECTS) $(libzgcj_convenience_la_DEPENDENCIES) $(EXTRA_libzgcj_convenience_la_DEPENDENCIES) 
-	$(AM_V_CCLD)$(LINK) $(am_libzgcj_convenience_la_rpath) $(libzgcj_convenience_la_OBJECTS) $(libzgcj_convenience_la_LIBADD) $(LIBS)
+libz_convenience.la: $(libz_convenience_la_OBJECTS) $(libz_convenience_la_DEPENDENCIES) $(EXTRA_libz_convenience_la_DEPENDENCIES) 
+	$(AM_V_CCLD)$(LINK) $(am_libz_convenience_la_rpath) $(libz_convenience_la_OBJECTS) $(libz_convenience_la_LIBADD) $(LIBS)
 
 mostlyclean-compile:
 	-rm -f *.$(OBJEXT)
diff --git a/zlib/configure b/zlib/configure
index 041cbdbf715..7a8b49b0b3e 100755
--- a/zlib/configure
+++ b/zlib/configure
@@ -639,7 +639,6 @@ TARGET_LIBRARY_FALSE
 

[PATCH, d] Committed fix GNU_StackGrowsDown version always predefined

[Iain Buclaw]

Hi,

This patch fixes a small logic bug, where GNU_StackGrowsDown was
always predefined in the D language environment.  Instead, don't
define it where STACK_GROWS_DOWNWARD is defined as zero.  With this,
the correct libphobos code paths will now be compiled on hppa-*
targets.

Bootstrapped and regression tested on x86_64-linux-gnu.

Committed to trunk as r268106.

-- 
Iain
---
gcc/d/ChangeLog:

2019-01-20  Iain Buclaw  

* d-builtins.cc (d_init_versions): Check value of
STACK_GROWS_DOWNWARD.
---
diff --git a/gcc/d/d-builtins.cc b/gcc/d/d-builtins.cc
index 564e8c6a7b1..b0a315a3ed9 100644
--- a/gcc/d/d-builtins.cc
+++ b/gcc/d/d-builtins.cc
@@ -417,9 +417,8 @@ d_init_versions (void)
   if (!targetm.have_tls)
 VersionCondition::addPredefinedGlobalIdent ("GNU_EMUTLS");
 
-#ifdef STACK_GROWS_DOWNWARD
-  VersionCondition::addPredefinedGlobalIdent ("GNU_StackGrowsDown");
-#endif
+  if (STACK_GROWS_DOWNWARD)
+VersionCondition::addPredefinedGlobalIdent ("GNU_StackGrowsDown");
 
   /* Should define this anyway to set us apart from the competition.  */
   VersionCondition::addPredefinedGlobalIdent ("GNU_InlineAsm");

Re: [PATCH] Fix issues with -Waddress-of-packed-member

[H.J. Lu]

On Sun, Jan 20, 2019 at 9:10 AM Bernd Edlinger
 wrote:
>
> On 1/20/19 4:40 PM, H.J. Lu wrote:
> > On Sun, Jan 20, 2019 at 5:29 AM Bernd Edlinger
> >  wrote:
> >>
> >> Hi,
> >>
> >>
> >> I tried to build linux yesterday, and became aware that there are a few
> >> false-positive warnings with -Waddress-of-packed-member:
> >>
> >> struct t {
> >>   char a;
> >>   int b;
> >>   int *c;
> >>   int d[10];
> >> } __attribute__((packed));
> >>
> >> struct t t0;
> >> struct t *t1;
> >> struct t **t2;
> >>
> >> t2 = 
> >> i1 = t0.c;
> >>
> >> I fixed them quickly with the attached patch, and added a new test case,
> >> which also revealed a few missing warnings:
> >>
> >> struct t t100[10][10];
> >> struct t (*baz())[10];
> >>
> >> t2 = (struct t**) t100;
> >> t2 = (struct t**) baz();
> >>
> >>
> >> Well I remembered that Joseph wanted me to use min_align_of_type instead
> >> of TYPE_ALIGN in the -Wcast-align warning, so I changed 
> >> -Waddress-of-packed-member
> >> to do that as well.
> >>
> >> Since I was not sure if the test coverage is good enough, I added a few 
> >> more
> >> test cases, which just make sure the existing warning works properly.
> >
> > You should also fix
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88928
> >
>
> Yes, thanks.  I added a check for NULL from TYPE_STUB_DECL here:
>
> + tree decl = TYPE_STUB_DECL (rhstype);
> + if (decl)
> +   inform (DECL_SOURCE_LOCATION (decl), "defined here");
>
> and the test case from the PR.
>
> >> I am however not sure of a warning that is as noisy as this one, should be
> >> default-enabled, because it might interfere with configure tests.  That 
> >> might
> >
> > These codes can lead unaligned access which may be very hard to track
> > down or fix since  the codes in question may be in a library.  I think it 
> > is a
> > very useful warning.  Besides, these noisy warnings also reveal 
> > implementation
> > issues in GCC, which, otherwise, may not be known for a long time.
> >
>
> No doubt that is a useful warning there is no question about that.
>
> Are you concerned about production code that gets built w/o at least -Wall ?
>
> I am however not sure, why it is limited to packed structures.
>
> >> be better to enable this warning, in -Wall or -Wextra, and, well maybe
> >> enable -Wcast-align=strict also at the same warning level, since it is 
> >> currently
> >> not enabled at all, unless explicitly requested, what do you think?
> >>
>
> I just see, your warning as being similar in spirit as -Wcast-align, since
> if type casts are involved, you don't need packed structures to get unaligned
> pointers.  So what I wonder now is, if it is a bit inconsistent to have
> -Wcast-align=strict not being enabled at least with -Wextra, while
> -Waddress-of-packed-member being default enabled.  I am just unsure if one day
> -Wcast-align should be enabled by -Wall/-Wextra or per default as well, or 
> being
> superseded by -Waddress-of-packed-member.  I mean, except for the limitation
> on requiring the packed keyword on structures, -Waddress-of-packed-member is 
> now
> a superset of -Wcast-align=strict, you know.

Unlike -Wcast-align=strict in

typedef char __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__))) c;
typedef struct __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)))
{
  char x;
} d;

char *x;
c *y;
d *z;
struct s { long long x; } *p;
struct t { double x; } *q;

which has a workaround by increasing source alignment, there is no workaround
for  -Waddress-of-packed-member.

>
> Anyway, new patch version with fix for PR 88928 attached.

Thanks.

>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
>


-- 
H.J.

Re: [PATCH] i386: Move Intel intrinsics head files to

[H.J. Lu]

On Sun, Jan 20, 2019 at 10:12 AM Uros Bizjak  wrote:
>
> On Sun, Jan 20, 2019 at 7:09 PM Uros Bizjak  wrote:
> >
> > On Sun, Jan 20, 2019 at 4:11 PM H.J. Lu  wrote:
> > >
> > > On Sun, Jan 20, 2019 at 4:03 AM Uros Bizjak  wrote:
> > > >
> > > > On 1/19/19, H.J. Lu  wrote:
> > > > > According to Intel Intrinsics Guide:
> > > > >
> > > > > https://software.intel.com/sites/landingpage/IntrinsicsGuide/
> > > > >
> > > > > Intel intrinsics should be available by including .  This
> > > > > patch moves remaining Intel intrinsics head files from  
> > > > > to
> > > > > .
> > > >
> > > > I can't find the quoted requirement in the provided link.
> > >
> > > That is an interactive website.  If you type in "_xgetbv" and click on it,
> > > you will get
> > >
> > > Synopsis
> > >
> > > unsigned __int64 _xgetbv (unsigned int a)
> > > #include 
> > > Instruction: xgetbv
> > > CPUID Flags: XSAVE
> > >
> > > Description
> > >
> > > Copy up to 64-bits from the value of the extended control register
> > > (XCR) specified by a into dst. Currently only XFEATURE_ENABLED_MASK
> > > XCR is supported.
> > >
> > > Operation
> > >
> > > dst[63:0] := XCR[a]
> >
> > Ah, thanks for the hint. LGTM, but still needs RM approval.
>
> I wonder, what is/was the purpose of x86intrin.h, considering that
> everything can be included from immintrin.h?

Some intrinsics aren't covered by Intel Intrinsics Guide, like AMD
specific ones.

-- 
H.J.

Re: [PATCH] i386: Move Intel intrinsics head files to

[Uros Bizjak]

On Sun, Jan 20, 2019 at 7:09 PM Uros Bizjak  wrote:
>
> On Sun, Jan 20, 2019 at 4:11 PM H.J. Lu  wrote:
> >
> > On Sun, Jan 20, 2019 at 4:03 AM Uros Bizjak  wrote:
> > >
> > > On 1/19/19, H.J. Lu  wrote:
> > > > According to Intel Intrinsics Guide:
> > > >
> > > > https://software.intel.com/sites/landingpage/IntrinsicsGuide/
> > > >
> > > > Intel intrinsics should be available by including .  This
> > > > patch moves remaining Intel intrinsics head files from  to
> > > > .
> > >
> > > I can't find the quoted requirement in the provided link.
> >
> > That is an interactive website.  If you type in "_xgetbv" and click on it,
> > you will get
> >
> > Synopsis
> >
> > unsigned __int64 _xgetbv (unsigned int a)
> > #include 
> > Instruction: xgetbv
> > CPUID Flags: XSAVE
> >
> > Description
> >
> > Copy up to 64-bits from the value of the extended control register
> > (XCR) specified by a into dst. Currently only XFEATURE_ENABLED_MASK
> > XCR is supported.
> >
> > Operation
> >
> > dst[63:0] := XCR[a]
>
> Ah, thanks for the hint. LGTM, but still needs RM approval.

I wonder, what is/was the purpose of x86intrin.h, considering that
everything can be included from immintrin.h?

Uros.

Re: [PATCH] i386: Move Intel intrinsics head files to

[Uros Bizjak]

On Sun, Jan 20, 2019 at 4:11 PM H.J. Lu  wrote:
>
> On Sun, Jan 20, 2019 at 4:03 AM Uros Bizjak  wrote:
> >
> > On 1/19/19, H.J. Lu  wrote:
> > > According to Intel Intrinsics Guide:
> > >
> > > https://software.intel.com/sites/landingpage/IntrinsicsGuide/
> > >
> > > Intel intrinsics should be available by including .  This
> > > patch moves remaining Intel intrinsics head files from  to
> > > .
> >
> > I can't find the quoted requirement in the provided link.
>
> That is an interactive website.  If you type in "_xgetbv" and click on it,
> you will get
>
> Synopsis
>
> unsigned __int64 _xgetbv (unsigned int a)
> #include 
> Instruction: xgetbv
> CPUID Flags: XSAVE
>
> Description
>
> Copy up to 64-bits from the value of the extended control register
> (XCR) specified by a into dst. Currently only XFEATURE_ENABLED_MASK
> XCR is supported.
>
> Operation
>
> dst[63:0] := XCR[a]

Ah, thanks for the hint. LGTM, but still needs RM approval.

Thanks.
Uros.

> > > OK for trunk?
> >
> > You will need a RM approval for a non-regression fix patch at this point.
>
> Richard, is this OK for GCC 9?
>
> > Uros.
> >
> > > H.J.
> > > ---
> > >   PR target/71659
> > >   * config/i386/adxintrin.h: Just check _IMMINTRIN_H_INCLUDED.
> > >   * config/i386/clflushoptintrin.h: Check _IMMINTRIN_H_INCLUDED
> > >   instead of _X86INTRIN_H_INCLUDED.
> > >   * onfig/i386/clwbintrin.h: Likewise.
> > >   * config/i386/pkuintrin.h: Likewise.
> > >   * config/i386/prfchwintrin.h: Likewise.
> > >   * config/i386/rdseedintrin.h: Likewise.
> > >   * config/i386/wbnoinvdintrin.h: Likewise.
> > >   * config/i386/xsavecintrin.h: Likewise.
> > >   * config/i386/xsavesintrin.h: Likewise.
> > >   * config/i386/fxsrintrin.h: Enable _IMMINTRIN_H_INCLUDED check.
> > >   * config/i386/xsaveintrin.h: Likewise.
> > >   * config/i386/xsaveoptintrin.h: Likewise.
> > >   * config/i386/x86intrin.h: Move "#include" ,
> > >   , , ,
> > >   , , ,
> > >   , , ,
> > >and  to ...
> > >   * config/i386/immintrin.h: Here.
> > > ---
> > >  gcc/config/i386/adxintrin.h|  4 ++--
> > >  gcc/config/i386/clflushoptintrin.h |  4 ++--
> > >  gcc/config/i386/clwbintrin.h   |  4 ++--
> > >  gcc/config/i386/fxsrintrin.h   |  6 +++---
> > >  gcc/config/i386/immintrin.h| 24 
> > >  gcc/config/i386/pkuintrin.h|  4 ++--
> > >  gcc/config/i386/prfchwintrin.h |  4 ++--
> > >  gcc/config/i386/rdseedintrin.h |  4 ++--
> > >  gcc/config/i386/wbnoinvdintrin.h   |  4 ++--
> > >  gcc/config/i386/x86intrin.h| 28 
> > >  gcc/config/i386/xsavecintrin.h |  4 ++--
> > >  gcc/config/i386/xsaveintrin.h  |  6 +++---
> > >  gcc/config/i386/xsaveoptintrin.h   |  6 +++---
> > >  gcc/config/i386/xsavesintrin.h |  4 ++--
> > >  14 files changed, 51 insertions(+), 55 deletions(-)
> > >
> > > diff --git a/gcc/config/i386/adxintrin.h b/gcc/config/i386/adxintrin.h
> > > index e01b77ddb4b..e8cb004390c 100644
> > > --- a/gcc/config/i386/adxintrin.h
> > > +++ b/gcc/config/i386/adxintrin.h
> > > @@ -21,8 +21,8 @@
> > > see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> > > .  */
> > >
> > > -#if !defined _X86INTRIN_H_INCLUDED && !defined _IMMINTRIN_H_INCLUDED
> > > -# error "Never use  directly; include  
> > > instead."
> > > +#if !defined _IMMINTRIN_H_INCLUDED
> > > +# error "Never use  directly; include  
> > > instead."
> > >  #endif
> > >
> > >  #ifndef _ADXINTRIN_H_INCLUDED
> > > diff --git a/gcc/config/i386/clflushoptintrin.h
> > > b/gcc/config/i386/clflushoptintrin.h
> > > index 1e720c2515c..89aa0f68fc2 100644
> > > --- a/gcc/config/i386/clflushoptintrin.h
> > > +++ b/gcc/config/i386/clflushoptintrin.h
> > > @@ -21,8 +21,8 @@
> > > see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> > > .  */
> > >
> > > -#if !defined _X86INTRIN_H_INCLUDED
> > > -# error "Never use  directly; include 
> > > instead."
> > > +#if !defined _IMMINTRIN_H_INCLUDED
> > > +# error "Never use  directly; include 
> > > instead."
> > >  #endif
> > >
> > >  #ifndef _CLFLUSHOPTINTRIN_H_INCLUDED
> > > diff --git a/gcc/config/i386/clwbintrin.h b/gcc/config/i386/clwbintrin.h
> > > index 217fb3babf2..68b20ea1635 100644
> > > --- a/gcc/config/i386/clwbintrin.h
> > > +++ b/gcc/config/i386/clwbintrin.h
> > > @@ -21,8 +21,8 @@
> > > see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> > > .  */
> > >
> > > -#if !defined _X86INTRIN_H_INCLUDED
> > > -# error "Never use  directly; include 
> > > instead."
> > > +#if !defined _IMMINTRIN_H_INCLUDED
> > > +# error "Never use  directly; include 
> > > instead."
> > >  #endif
> > >
> > >  #ifndef _CLWBINTRIN_H_INCLUDED
> > > diff --git a/gcc/config/i386/fxsrintrin.h b/gcc/config/i386/fxsrintrin.h
> > > index 

Re: [PATCH] Fix issues with -Waddress-of-packed-member

[Bernd Edlinger]

On 1/20/19 4:40 PM, H.J. Lu wrote:
> On Sun, Jan 20, 2019 at 5:29 AM Bernd Edlinger
>  wrote:
>>
>> Hi,
>>
>>
>> I tried to build linux yesterday, and became aware that there are a few
>> false-positive warnings with -Waddress-of-packed-member:
>>
>> struct t {
>>   char a;
>>   int b;
>>   int *c;
>>   int d[10];
>> } __attribute__((packed));
>>
>> struct t t0;
>> struct t *t1;
>> struct t **t2;
>>
>> t2 = 
>> i1 = t0.c;
>>
>> I fixed them quickly with the attached patch, and added a new test case,
>> which also revealed a few missing warnings:
>>
>> struct t t100[10][10];
>> struct t (*baz())[10];
>>
>> t2 = (struct t**) t100;
>> t2 = (struct t**) baz();
>>
>>
>> Well I remembered that Joseph wanted me to use min_align_of_type instead
>> of TYPE_ALIGN in the -Wcast-align warning, so I changed 
>> -Waddress-of-packed-member
>> to do that as well.
>>
>> Since I was not sure if the test coverage is good enough, I added a few more
>> test cases, which just make sure the existing warning works properly.
> 
> You should also fix
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88928
> 

Yes, thanks.  I added a check for NULL from TYPE_STUB_DECL here:

+ tree decl = TYPE_STUB_DECL (rhstype);
+ if (decl)
+   inform (DECL_SOURCE_LOCATION (decl), "defined here");

and the test case from the PR.

>> I am however not sure of a warning that is as noisy as this one, should be
>> default-enabled, because it might interfere with configure tests.  That might
> 
> These codes can lead unaligned access which may be very hard to track
> down or fix since  the codes in question may be in a library.  I think it is a
> very useful warning.  Besides, these noisy warnings also reveal implementation
> issues in GCC, which, otherwise, may not be known for a long time.
> 

No doubt that is a useful warning there is no question about that.

Are you concerned about production code that gets built w/o at least -Wall ?

I am however not sure, why it is limited to packed structures.

>> be better to enable this warning, in -Wall or -Wextra, and, well maybe
>> enable -Wcast-align=strict also at the same warning level, since it is 
>> currently
>> not enabled at all, unless explicitly requested, what do you think?
>>

I just see, your warning as being similar in spirit as -Wcast-align, since
if type casts are involved, you don't need packed structures to get unaligned
pointers.  So what I wonder now is, if it is a bit inconsistent to have
-Wcast-align=strict not being enabled at least with -Wextra, while
-Waddress-of-packed-member being default enabled.  I am just unsure if one day
-Wcast-align should be enabled by -Wall/-Wextra or per default as well, or being
superseded by -Waddress-of-packed-member.  I mean, except for the limitation
on requiring the packed keyword on structures, -Waddress-of-packed-member is now
a superset of -Wcast-align=strict, you know.


Anyway, new patch version with fix for PR 88928 attached.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
2019-01-20  Bernd Edlinger  

	PR c/88928
	* c-warn.c (check_alignment_of_packed_member): Add a boolean parameter
	for rvalue context.  Handle rvalues correctly.  Use min_align_of_type
	instead of TYPE_ALIGN.
	(check_address_or_pointer_of_packed_member): Handle rvalues coorrectly.
	Use min_align_of_type instead of TYPE_ALIGN_UNIT.  Check for NULL
	pointer from TYPE_STUB_DECL.

testsuite:
2019-01-20  Bernd Edlinger  

	PR c/88928
	* c-c++-common/Waddress-of-packed-member-1.c: New test case.
	* gcc.dg/pr88928.c: New test case.

Index: gcc/c-family/c-warn.c
===
--- gcc/c-family/c-warn.c	(revision 268102)
+++ gcc/c-family/c-warn.c	(working copy)
@@ -35,6 +35,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimplify.h"
 #include "c-family/c-indentation.h"
 #include "calls.h"
+#include "stor-layout.h"
 
 /* Print a warning if a constant expression had overflow in folding.
Invoke this function on every expression that the language
@@ -2688,25 +2689,26 @@ warn_for_multistatement_macros (location_t body_lo
 }
 
 /* Return struct or union type if the alignment of data memeber, FIELD,
-   is less than the alignment of TYPE.  Otherwise, return NULL_TREE.  */
+   is less than the alignment of TYPE.  Otherwise, return NULL_TREE.
+   If RVALUE is true, only arrays evaluate to pointers.  */
 
 static tree
-check_alignment_of_packed_member (tree type, tree field)
+check_alignment_of_packed_member (tree type, tree field, bool rvalue)
 {
   /* Check alignment of the data member.  */
   if (TREE_CODE (field) == FIELD_DECL
-  && (DECL_PACKED (field)
-	  || TYPE_PACKED (TREE_TYPE (field
+  && (DECL_PACKED (field) || TYPE_PACKED (TREE_TYPE (field)))
+  && (!rvalue || TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE))
 {
   /* Check the expected alignment against the field alignment.  */
-  unsigned int type_align 

RE: [PATCH] [ARC] atomics: Add operand to DMB instruction

[Claudiu Zissulescu]

Hi,
> 
> 2019-01-18  Vineet Gupta 
> 
>* config/arc/atomic.md: Add operand to DMB instruction
> 

This is ok. I'll push it asap,
Claudiu

Implement C++20 feature P0600r1: nodiscard in the library

[Ulrich Drepper]

Since a previous patch introduced the _GLIBCXX_NODISCARD macro it is now
simple to implement the rest of P0600.  The parts specific to C++20 were
already added, this patch adds the attribute to the other functions.

Even though the feature specifies the nodiscard attribute only for C++20
it makes no sense to restrict its use.  Code which provokes the warning
but uses C++17 also has a problem.  I do not propose to go beyond C++17
yet.  Just as for the shared_ptr comparison patch, let's first see how
things go and then we can extend the attribute to previous revisions.

If a code base is compiled with multiple compilers chances are that no
problem will be flagged.  Other library implementations are much more
aggressive with the use of this flag.  In the gcc code base on one test
case was flagged and that code sequence obviously should never appear in
real code (allocate and discard the result).

The test suite shows no additional errors and given that only the
functions mentioned in the feature (allocate, empty, new, async) are
changed I think this is a patch which can be applied to the trunk.  It
can catch real mistakes.

OK?

gcc/testsuite/ChangeLog
2019-02-20  Ulrich Drepper  

Fix after P0600.
* g++.dg/init/new39.C: Don't just ignore result of new.

libstdc++/ChangeLog
2019-02-20  Ulrich Drepper  

Implement C++20 P0600r1.
* include/backward/hash_map: Add nodiscard attribute to empty.
* include/backward/hash_set: Likewise.
* backward/hashtable.h: Likewise.
* include/bits/basic_string.h: Likewise.
* include/bits/forward_list.h: Likewise.
* include/bits/hashtable.h: Likewise.
* include/bits/regex.h: Likewise.
* include/bits/stl_deque.h: Likewise.
* include/bits/stl_list.h: Likewise.
* include/bits/stl_map.h: Likewise.
* include/bits/stl_multimap.h: Likewise.
* include/bits/stl_multiset.h: Likewise.
* include/bits/stl_queue.h: Likewise.
* include/bits/stl_set.h: Likewise.
* include/bits/stl_stack.h: Likewise.
* include/bits/stl_tree.h: Likewise.
* include/bits/stl_vector.h: Likewise.
* include/bits/unordered_map.h: Likewise.
* include/bits/unordered_set.h: Likewise.
* include/debug/array: Likewise.
* include/experimental/any: Likewise.
* include/experimental/bits/fs_path.h: Likewise.
* include/experimental/internet: Likewise.
* include/experimental/string_view: Likewise.
* include/ext/pb_ds/detail/bin_search_tree_/info_fn_imps.hpp:
Likewise.
* include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp:
Likewise.
* include/ext/pb_ds/detail/binary_heap_/info_fn_imps.hpp:
Likewise.
* include/ext/pb_ds/detail/cc_hash_table_map_/cc_ht_map_.hpp:
Likewise.
* include/ext/pb_ds/detail/cc_hash_table_map_/info_fn_imps.hpp:
Likewise.
* include/ext/pb_ds/detail/cc_hash_table_map_/size_fn_imps.hpp:
Likewise.
* include/ext/pb_ds/detail/gp_hash_table_map_/gp_ht_map_.hpp:
Likewise.
* include/ext/pb_ds/detail/gp_hash_table_map_/info_fn_imps.hpp:
Likewise.
* 
include/ext/pb_ds/detail/left_child_next_sibling_heap_/info_fn_imps.hpp:
Likewise.
*
include/ext/pb_ds/detail/left_child_next_sibling_heap_/left_child_next_sibling_heap_.hpp:
Likewise.
* include/ext/pb_ds/detail/list_update_map_/info_fn_imps.hpp:
Likewise.
* include/ext/pb_ds/detail/list_update_map_/lu_map_.hpp:
Likewise.
* include/ext/pb_ds/detail/ov_tree_map_/info_fn_imps.hpp:
Likewise.
* include/ext/pb_ds/detail/ov_tree_map_/ov_tree_map_.hp:
Likewise.
* include/ext/pb_ds/detail/pat_trie_/info_fn_imps.hpp:
Likewise.
* include/ext/pb_ds/detail/pat_trie_/pat_trie_.hpp:
Likewise.
* include/ext/pb_ds/detail/rc_binomial_heap_/rc.hpp:
Likewise.
* include/ext/pb_ds/detail/tree_trace_base.hpp: Likewise.
* include/ext/pb_ds/trie_policy.hpp: Likewise.
* include/ext/rope: Likewise.
* include/ext/slist: Likewise.
* include/ext/vstring.h: Likewise.
* include/profile/array: Likewise.
* include/std/array: Likewise.
* include/tr1/array: Likewise.
* include/tr1/hashtable.h: Likewise.
* include/tr1/regex: Likewise.
* include/tr2/dynamic_bitset: Likewise.
* include/bits/alloc_traits.h: Add nodiscard attribute to
allocate.
* include/experimental/memory_resource: Likewise.
* include/ext/alloc_traits.h: Likewise.
* include/ext/array_allocator.h: Likewise.
* include/ext/bitmap_allocator.h: Likewise.
* include/ext/debug_allocator.h: Likewise.
* include/ext/extptr_allocator.h: Likewise.
* include/ext/mt_allocator.h: Likewise.
* 

RE: [PATCH][GCC][Arm] Rewrite arm testcase to use intrinsics

[Tamar Christina]

Hi Segher,

Yes, that's why the PR is still open 
The ICE can be reproduced with a much simpler testcase which is the one we use 
for repro in the PR, which is now a P1.

The reason for changing this testcase was that it was invalid code.

Regards,
Tamar

-Original Message-
From: Segher Boessenkool  
Sent: Sunday, January 20, 2019 3:48 PM
To: Tamar Christina 
Cc: gcc-patches@gcc.gnu.org; nd ; Ramana Radhakrishnan 
; Richard Earnshaw ; 
ni...@redhat.com; Kyrylo Tkachov 
Subject: Re: [PATCH][GCC][Arm] Rewrite arm testcase to use intrinsics

Hi!

On Thu, Jan 17, 2019 at 03:02:00PM +, Tamar Christina wrote:
> This test was added back when builtins were being used instead of ACLE 
> intrinsics.  The test as far as I can tell is really testing vcombine, 
> however some of these builtins no longer exist and causes an ICE.
> 
> This fixes the testcase by changing it to use neon intrinsics.

Shouldn't the ICE be fixed as well?  [ Sorry if you send a separate patch for 
that and I missed it ].


Segher

Re: [PATCH][GCC][Arm] Rewrite arm testcase to use intrinsics

[Segher Boessenkool]

Hi!

On Thu, Jan 17, 2019 at 03:02:00PM +, Tamar Christina wrote:
> This test was added back when builtins were being used instead of ACLE
> intrinsics.  The test as far as I can tell is really testing vcombine,
> however some of these builtins no longer exist and causes an ICE.
> 
> This fixes the testcase by changing it to use neon intrinsics.

Shouldn't the ICE be fixed as well?  [ Sorry if you send a separate patch
for that and I missed it ].


Segher

Re: [PATCH] Fix issues with -Waddress-of-packed-member

[H.J. Lu]

On Sun, Jan 20, 2019 at 5:29 AM Bernd Edlinger
 wrote:
>
> Hi,
>
>
> I tried to build linux yesterday, and became aware that there are a few
> false-positive warnings with -Waddress-of-packed-member:
>
> struct t {
>   char a;
>   int b;
>   int *c;
>   int d[10];
> } __attribute__((packed));
>
> struct t t0;
> struct t *t1;
> struct t **t2;
>
> t2 = 
> i1 = t0.c;
>
> I fixed them quickly with the attached patch, and added a new test case,
> which also revealed a few missing warnings:
>
> struct t t100[10][10];
> struct t (*baz())[10];
>
> t2 = (struct t**) t100;
> t2 = (struct t**) baz();
>
>
> Well I remembered that Joseph wanted me to use min_align_of_type instead
> of TYPE_ALIGN in the -Wcast-align warning, so I changed 
> -Waddress-of-packed-member
> to do that as well.
>
> Since I was not sure if the test coverage is good enough, I added a few more
> test cases, which just make sure the existing warning works properly.

You should also fix

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88928

with something like

diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c
index 7821cc894a7..4daadc0f6c7 100644
--- a/gcc/c-family/c-warn.c
+++ b/gcc/c-family/c-warn.c
@@ -2744,9 +2744,14 @@ check_address_or_pointer_of_packed_member (tree type, tre
e rhs)
 rhs = TREE_TYPE (rhs);   /* Function type.  */
   }
   tree rhstype = TREE_TYPE (rhs);
+  tree basetype = type;
+  while (POINTER_TYPE_P (basetype))
+  basetype = TREE_TYPE (basetype);
   if ((POINTER_TYPE_P (rhstype)
  || TREE_CODE (rhstype) == ARRAY_TYPE)
-&& TYPE_PACKED (TREE_TYPE (rhstype)))
+&& TYPE_PACKED (TREE_TYPE (rhstype))
+&& (!RECORD_OR_UNION_TYPE_P (basetype)
+|| TYPE_FIELDS (basetype) != NULL_TREE))
   {
 unsigned int type_align = TYPE_ALIGN_UNIT (type);
 unsigned int rhs_align = TYPE_ALIGN_UNIT (TREE_TYPE (rhstype));
@@ -2759,7 +2764,8 @@ check_address_or_pointer_of_packed_member (tree
type, tree rhs)
   "unaligned pointer value",
   rhstype, rhs_align, type, type_align);
 tree decl = TYPE_STUB_DECL (TREE_TYPE (rhstype));
-inform (DECL_SOURCE_LOCATION (decl), "defined here");
+if (decl)
+ inform (DECL_SOURCE_LOCATION (decl), "defined here");
 decl = TYPE_STUB_DECL (type);
 if (decl)
  inform (DECL_SOURCE_LOCATION (decl), "defined here");

> I am however not sure of a warning that is as noisy as this one, should be
> default-enabled, because it might interfere with configure tests.  That might

These codes can lead unaligned access which may be very hard to track
down or fix since  the codes in question may be in a library.  I think it is a
very useful warning.  Besides, these noisy warnings also reveal implementation
issues in GCC, which, otherwise, may not be known for a long time.

> be better to enable this warning, in -Wall or -Wextra, and, well maybe
> enable -Wcast-align=strict also at the same warning level, since it is 
> currently
> not enabled at all, unless explicitly requested, what do you think?
>
>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
>
>

-- 
H.J.

Re: [PATCH] i386: Move Intel intrinsics head files to

[H.J. Lu]

On Sun, Jan 20, 2019 at 4:03 AM Uros Bizjak  wrote:
>
> On 1/19/19, H.J. Lu  wrote:
> > According to Intel Intrinsics Guide:
> >
> > https://software.intel.com/sites/landingpage/IntrinsicsGuide/
> >
> > Intel intrinsics should be available by including .  This
> > patch moves remaining Intel intrinsics head files from  to
> > .
>
> I can't find the quoted requirement in the provided link.

That is an interactive website.  If you type in "_xgetbv" and click on it,
you will get

Synopsis

unsigned __int64 _xgetbv (unsigned int a)
#include 
Instruction: xgetbv
CPUID Flags: XSAVE

Description

Copy up to 64-bits from the value of the extended control register
(XCR) specified by a into dst. Currently only XFEATURE_ENABLED_MASK
XCR is supported.

Operation

dst[63:0] := XCR[a]

> > OK for trunk?
>
> You will need a RM approval for a non-regression fix patch at this point.

Richard, is this OK for GCC 9?

> Uros.
>
> > H.J.
> > ---
> >   PR target/71659
> >   * config/i386/adxintrin.h: Just check _IMMINTRIN_H_INCLUDED.
> >   * config/i386/clflushoptintrin.h: Check _IMMINTRIN_H_INCLUDED
> >   instead of _X86INTRIN_H_INCLUDED.
> >   * onfig/i386/clwbintrin.h: Likewise.
> >   * config/i386/pkuintrin.h: Likewise.
> >   * config/i386/prfchwintrin.h: Likewise.
> >   * config/i386/rdseedintrin.h: Likewise.
> >   * config/i386/wbnoinvdintrin.h: Likewise.
> >   * config/i386/xsavecintrin.h: Likewise.
> >   * config/i386/xsavesintrin.h: Likewise.
> >   * config/i386/fxsrintrin.h: Enable _IMMINTRIN_H_INCLUDED check.
> >   * config/i386/xsaveintrin.h: Likewise.
> >   * config/i386/xsaveoptintrin.h: Likewise.
> >   * config/i386/x86intrin.h: Move "#include" ,
> >   , , ,
> >   , , ,
> >   , , ,
> >and  to ...
> >   * config/i386/immintrin.h: Here.
> > ---
> >  gcc/config/i386/adxintrin.h|  4 ++--
> >  gcc/config/i386/clflushoptintrin.h |  4 ++--
> >  gcc/config/i386/clwbintrin.h   |  4 ++--
> >  gcc/config/i386/fxsrintrin.h   |  6 +++---
> >  gcc/config/i386/immintrin.h| 24 
> >  gcc/config/i386/pkuintrin.h|  4 ++--
> >  gcc/config/i386/prfchwintrin.h |  4 ++--
> >  gcc/config/i386/rdseedintrin.h |  4 ++--
> >  gcc/config/i386/wbnoinvdintrin.h   |  4 ++--
> >  gcc/config/i386/x86intrin.h| 28 
> >  gcc/config/i386/xsavecintrin.h |  4 ++--
> >  gcc/config/i386/xsaveintrin.h  |  6 +++---
> >  gcc/config/i386/xsaveoptintrin.h   |  6 +++---
> >  gcc/config/i386/xsavesintrin.h |  4 ++--
> >  14 files changed, 51 insertions(+), 55 deletions(-)
> >
> > diff --git a/gcc/config/i386/adxintrin.h b/gcc/config/i386/adxintrin.h
> > index e01b77ddb4b..e8cb004390c 100644
> > --- a/gcc/config/i386/adxintrin.h
> > +++ b/gcc/config/i386/adxintrin.h
> > @@ -21,8 +21,8 @@
> > see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> > .  */
> >
> > -#if !defined _X86INTRIN_H_INCLUDED && !defined _IMMINTRIN_H_INCLUDED
> > -# error "Never use  directly; include  instead."
> > +#if !defined _IMMINTRIN_H_INCLUDED
> > +# error "Never use  directly; include  instead."
> >  #endif
> >
> >  #ifndef _ADXINTRIN_H_INCLUDED
> > diff --git a/gcc/config/i386/clflushoptintrin.h
> > b/gcc/config/i386/clflushoptintrin.h
> > index 1e720c2515c..89aa0f68fc2 100644
> > --- a/gcc/config/i386/clflushoptintrin.h
> > +++ b/gcc/config/i386/clflushoptintrin.h
> > @@ -21,8 +21,8 @@
> > see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> > .  */
> >
> > -#if !defined _X86INTRIN_H_INCLUDED
> > -# error "Never use  directly; include 
> > instead."
> > +#if !defined _IMMINTRIN_H_INCLUDED
> > +# error "Never use  directly; include 
> > instead."
> >  #endif
> >
> >  #ifndef _CLFLUSHOPTINTRIN_H_INCLUDED
> > diff --git a/gcc/config/i386/clwbintrin.h b/gcc/config/i386/clwbintrin.h
> > index 217fb3babf2..68b20ea1635 100644
> > --- a/gcc/config/i386/clwbintrin.h
> > +++ b/gcc/config/i386/clwbintrin.h
> > @@ -21,8 +21,8 @@
> > see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> > .  */
> >
> > -#if !defined _X86INTRIN_H_INCLUDED
> > -# error "Never use  directly; include 
> > instead."
> > +#if !defined _IMMINTRIN_H_INCLUDED
> > +# error "Never use  directly; include 
> > instead."
> >  #endif
> >
> >  #ifndef _CLWBINTRIN_H_INCLUDED
> > diff --git a/gcc/config/i386/fxsrintrin.h b/gcc/config/i386/fxsrintrin.h
> > index ff6c6f848eb..c4b12cf25f3 100644
> > --- a/gcc/config/i386/fxsrintrin.h
> > +++ b/gcc/config/i386/fxsrintrin.h
> > @@ -21,9 +21,9 @@
> > see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> > .  */
> >
> > -/* #if !defined _X86INTRIN_H_INCLUDED && !defined _IMMINTRIN_H_INCLUDED */
> > -/* # error "Never use  directly; include 
> > instead." */
> > -/* #endif 

Re: [libbacktrace,PATCH] Fix non-portable printf format in allocfail.c

[Ian Lance Taylor]

Gerald Pfeifer  writes:

> 2019-01-20  Gerald Pfeifer  
>
>   * allocfail.c (main): Increase portability of printf statement.

This is OK.

Thanks.

Ian

Re: [RS6000] PR88614, output_operand: invalid %z value

[Alan Modra]

On Fri, Jan 18, 2019 at 04:02:14PM -0600, Segher Boessenkool wrote:
> Hi Alan,
> 
> On Mon, Jan 07, 2019 at 09:29:18AM +1030, Alan Modra wrote:
> > The direct cause of this PR is the fact that tls_gdld_nomark didn't
> > handle indirect calls.  Adding the missing support revealed that most
> > indirect calls were being optimised back to direct calls anyway, due
> > to tls_gdld_nomark not checking any of the parallel elements except
> > the first (plus the extra element that distinguishes this call from
> > normal calls).  Just checking the number of elements is enough to
> > separate the indirect calls from direct for ABI_ELFv2 and ABI_AIX,
> > while checking for the LONG_CALL bit in the cookie works for ABI_V4.
> > Direct calls being substituted for indirect calls is not the only
> > unwanted substitution.  See the tls_nomark_call comment.  I also saw a
> > _GLOBAL_OFFSET_TABLE_ symbol_ref being substituted for the GOT reg,
> > hence the unspec_tls change.
> 
> > Bootstrap and regression testing on powerpc64le-linux and
> > powerpc64-linux in progress.  Note that the patch requires
> > https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00252.html or the
> > earlier version for the attribute support.
> 
> (Did you commit that yet?)

Yes, the prerequisite patches have been committed.

> > +;; Verify that elements of the tls_gdld_nomark call insn parallel past the
> > +;; second element (added to distinguish this call from normal calls) match
> > +;; the normal contours of a call insn.  This is necessary to prevent
> > +;; substitutions we don't want, for example, an indirect call being
> > +;; optimised to a direct call, or (set (reg:r2) (unspec [] UNSPEC_TOCSLOT))
> > +;; being cleverly optimised to (set (reg:r2) (reg:r2)) because gcc
> > +;; "knows" that r2 hasn't changed from a previous call.
> > +(define_predicate "tls_nomark_call"
> > +  (match_code "parallel")
> > +{
> > +  int n = XVECLEN (op, 0);
> > +  rtvec v = XVEC (op, 0);
> > +  rtx set = RTVEC_ELT (v, 0);
> > +  if (GET_CODE (set) != SET)
> > +return 0;
> > +  rtx call = XEXP (set, 1);
> > +  if (GET_CODE (call) != CALL)
> > +return 0;
> > +  rtx mem = XEXP (call, 0);
> > +  if (GET_CODE (mem) != MEM)
> > +return 0;
> > +  rtx addr = XEXP (mem, 0);
> > +  if (GET_CODE (addr) == SYMBOL_REF)
> > +{
> > +  if (DEFAULT_ABI == ABI_ELFv2 || DEFAULT_ABI == ABI_AIX)
> > +   return (n == 3 && GET_CODE (RTVEC_ELT (v, 2)) == CLOBBER
> > +   && REG_P (XEXP (RTVEC_ELT (v, 2), 0))
> > +   && REGNO (XEXP (RTVEC_ELT (v, 2), 0)) == LR_REGNO);
> > +  else if (DEFAULT_ABI == ABI_V4)
> > +   return (n >= 4 && n <= 5 && GET_CODE (RTVEC_ELT (v, 2)) == USE
> > +   && CONST_INT_P (XEXP (RTVEC_ELT (v, 2), 0))
> > +   && (INTVAL (XEXP (RTVEC_ELT (v, 2), 0)) & CALL_LONG) == 0
> > +   && (n == 4
> > +   || (GET_CODE (RTVEC_ELT (v, 3)) == USE
> > +   && REG_P (XEXP (RTVEC_ELT (v, 3), 0
> > +   && GET_CODE (RTVEC_ELT (v, n - 1)) == CLOBBER
> > +   && REG_P (XEXP (RTVEC_ELT (v, n - 1), 0))
> > +   && REGNO (XEXP (RTVEC_ELT (v, n - 1), 0)) == LR_REGNO);
> > +  else
> > +   gcc_unreachable ();
> > +}
> > +  else if (indirect_call_operand (addr, mode))
> > +{
> > +  if (DEFAULT_ABI == ABI_ELFv2)
> > +   return (n == 4 && GET_CODE (RTVEC_ELT (v, 2)) == SET
> > +   && REG_P (XEXP (RTVEC_ELT (v, 2), 0))
> > +   && REGNO (XEXP (RTVEC_ELT (v, 2), 0)) == TOC_REGNUM
> > +   && GET_CODE (XEXP (RTVEC_ELT (v, 2), 1)) == UNSPEC
> > +   && XINT (XEXP (RTVEC_ELT (v, 2), 1), 1) == UNSPEC_TOCSLOT
> > +   && XVECLEN (XEXP (RTVEC_ELT (v, 2), 1), 0) == 1
> > +   && CONST_INT_P (XVECEXP (XEXP (RTVEC_ELT (v, 2), 1), 0, 0))
> > +   && GET_CODE (RTVEC_ELT (v, 3)) == CLOBBER
> > +   && REG_P (XEXP (RTVEC_ELT (v, 3), 0))
> > +   && REGNO (XEXP (RTVEC_ELT (v, 3), 0)) == LR_REGNO);
> > +  else if (DEFAULT_ABI == ABI_AIX)
> > +   return (n == 5 && GET_CODE (RTVEC_ELT (v, 2)) == USE
> > +   && GET_CODE (XEXP (RTVEC_ELT (v, 2), 0)) == MEM
> > +   && GET_CODE (RTVEC_ELT (v, 3)) == SET
> > +   && REG_P (XEXP (RTVEC_ELT (v, 3), 0))
> > +   && REGNO (XEXP (RTVEC_ELT (v, 3), 0)) == TOC_REGNUM
> > +   && GET_CODE (XEXP (RTVEC_ELT (v, 3), 1)) == UNSPEC
> > +   && XINT (XEXP (RTVEC_ELT (v, 3), 1), 1) == UNSPEC_TOCSLOT
> > +   && XVECLEN (XEXP (RTVEC_ELT (v, 3), 1), 0) == 1
> > +   && CONST_INT_P (XVECEXP (XEXP (RTVEC_ELT (v, 3), 1), 0, 0))
> > +   && GET_CODE (RTVEC_ELT (v, 4)) == CLOBBER
> > +   && REG_P (XEXP (RTVEC_ELT (v, 4), 0))
> > +   && REGNO (XEXP (RTVEC_ELT (v, 4), 0)) == LR_REGNO);
> > +  else if (DEFAULT_ABI == ABI_V4)
> > +   return (n == 4 && GET_CODE (RTVEC_ELT (v, 2)) == USE
> > +   && CONST_INT_P (XEXP (RTVEC_ELT (v, 2), 0))
> > +   && GET_CODE (RTVEC_ELT (v, 3)) == CLOBBER
> > + 

[PATCH] Fix issues with -Waddress-of-packed-member

[Bernd Edlinger]

Hi,


I tried to build linux yesterday, and became aware that there are a few
false-positive warnings with -Waddress-of-packed-member:

struct t {
  char a;
  int b;
  int *c;
  int d[10];
} __attribute__((packed));

struct t t0;
struct t *t1;
struct t **t2;

t2 = 
i1 = t0.c;

I fixed them quickly with the attached patch, and added a new test case,
which also revealed a few missing warnings:

struct t t100[10][10];
struct t (*baz())[10];

t2 = (struct t**) t100;
t2 = (struct t**) baz();


Well I remembered that Joseph wanted me to use min_align_of_type instead
of TYPE_ALIGN in the -Wcast-align warning, so I changed 
-Waddress-of-packed-member
to do that as well.

Since I was not sure if the test coverage is good enough, I added a few more
test cases, which just make sure the existing warning works properly.

I am however not sure of a warning that is as noisy as this one, should be
default-enabled, because it might interfere with configure tests.  That might
be better to enable this warning, in -Wall or -Wextra, and, well maybe
enable -Wcast-align=strict also at the same warning level, since it is currently
not enabled at all, unless explicitly requested, what do you think?


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
2019-01-20  Bernd Edlinger  

	* c-warn.c (check_alignment_of_packed_member): Add a boolean parameter
	for rvalue context.  Handle rvalues correctly.  Use min_align_of_type
	instead of TYPE_ALIGN.
	(check_address_or_pointer_of_packed_member): Handle rvalues coorrectly.
	Use min_align_of_type instead of TYPE_ALIGN_UNIT.

testsuite:
2019-01-20  Bernd Edlinger  

	* c-c++-common/Waddress-of-packed-member-1.c: New test case.

Index: gcc/c-family/c-warn.c
===
--- gcc/c-family/c-warn.c	(revision 268084)
+++ gcc/c-family/c-warn.c	(working copy)
@@ -35,6 +35,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimplify.h"
 #include "c-family/c-indentation.h"
 #include "calls.h"
+#include "stor-layout.h"
 
 /* Print a warning if a constant expression had overflow in folding.
Invoke this function on every expression that the language
@@ -2688,25 +2689,26 @@ warn_for_multistatement_macros (location_t body_lo
 }
 
 /* Return struct or union type if the alignment of data memeber, FIELD,
-   is less than the alignment of TYPE.  Otherwise, return NULL_TREE.  */
+   is less than the alignment of TYPE.  Otherwise, return NULL_TREE.
+   If RVALUE is true, only arrays evaluate to pointers.  */
 
 static tree
-check_alignment_of_packed_member (tree type, tree field)
+check_alignment_of_packed_member (tree type, tree field, bool rvalue)
 {
   /* Check alignment of the data member.  */
   if (TREE_CODE (field) == FIELD_DECL
-  && (DECL_PACKED (field)
-	  || TYPE_PACKED (TREE_TYPE (field
+  && (DECL_PACKED (field) || TYPE_PACKED (TREE_TYPE (field)))
+  && (!rvalue || TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE))
 {
   /* Check the expected alignment against the field alignment.  */
-  unsigned int type_align = TYPE_ALIGN (type);
+  unsigned int type_align = min_align_of_type (type);
   tree context = DECL_CONTEXT (field);
-  unsigned int record_align = TYPE_ALIGN (context);
-  if ((record_align % type_align) != 0)
+  unsigned int record_align = min_align_of_type (context);
+  if (record_align < type_align)
 	return context;
   tree field_off = byte_position (field);
   if (!multiple_of_p (TREE_TYPE (field_off), field_off,
-			  size_int (type_align / BITS_PER_UNIT)))
+			  size_int (type_align)))
 	return context;
 }
 
@@ -2722,19 +2724,27 @@ static tree
 static tree
 check_address_or_pointer_of_packed_member (tree type, tree rhs)
 {
+  bool rvalue = true;
+
   if (INDIRECT_REF_P (rhs))
 rhs = TREE_OPERAND (rhs, 0);
 
   if (TREE_CODE (rhs) == ADDR_EXPR)
-rhs = TREE_OPERAND (rhs, 0);
+{
+  rhs = TREE_OPERAND (rhs, 0);
+  rvalue = false;
+}
 
-  if (POINTER_TYPE_P (type))
-type = TREE_TYPE (type);
+  if (!POINTER_TYPE_P (type))
+return NULL_TREE;
 
+  type = TREE_TYPE (type);
+
   if (TREE_CODE (rhs) == PARM_DECL
   || VAR_P (rhs)
   || TREE_CODE (rhs) == CALL_EXPR)
 {
+  tree rhstype = TREE_TYPE (rhs);
   if (TREE_CODE (rhs) == CALL_EXPR)
 	{
 	  rhs = CALL_EXPR_FN (rhs);	/* Pointer expression.  */
@@ -2742,23 +2752,28 @@ check_address_or_pointer_of_packed_member (tree ty
 	return NULL_TREE;
 	  rhs = TREE_TYPE (rhs);	/* Pointer type.  */
 	  rhs = TREE_TYPE (rhs);	/* Function type.  */
+	  rhstype = TREE_TYPE (rhs);
+	  if (!POINTER_TYPE_P (rhstype))
+	return NULL_TREE;
+	  rvalue = true;
 	}
-  tree rhstype = TREE_TYPE (rhs);
-  if ((POINTER_TYPE_P (rhstype)
-	   || TREE_CODE (rhstype) == ARRAY_TYPE)
-	  && TYPE_PACKED (TREE_TYPE (rhstype)))
+  if (rvalue && POINTER_TYPE_P (rhstype))
+	rhstype = TREE_TYPE (rhstype);
+  while (TREE_CODE (rhstype) == 

Re: [PATCH, V2, d] Fix IdentityExp comparison for complex floats

[Iain Buclaw]

On Mon, 17 Dec 2018 at 23:05, Iain Buclaw  wrote:
>
> On Wed, 28 Nov 2018 at 23:46, Iain Buclaw  wrote:
> >
> > On Wed, 28 Nov 2018 at 22:32, Johannes Pfau  wrote:
> > >
> > > Next version, addresses the review comments.
> > >
> > > Tested at https://github.com/D-Programming-GDC/GDC/pull/768
> > > ---
> > > gcc/d/ChangeLog:
> > >
> > > 2018-11-28  Johannes Pfau  
> > >
> > > * expr.cc (ExprVisitor::visit(IdentityExp)): Add support for 
> > > complex types.
> > > (build_float_identity): New function.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > 2018-11-28  Johannes Pfau  
> > >
> > > * gdc.dg/runnable.d: Test IdentityExp for complex types.
> > >
> > >
> > >  gcc/d/expr.cc   | 40 -
> > >  gcc/testsuite/gdc.dg/runnable.d | 22 ++
> > >  2 files changed, 51 insertions(+), 11 deletions(-)
> > >
> >
> > As I've said before, looks reasonable to me.  Thanks.
> >
>
> I'll send a supplementary patch, and commit both together.
>

Committed to trunk along with patch that handles creal fields.

Bootstrapped and regression tested on x86_64-linux-gnu.

-- 
Iain
---
gcc/d/ChangeLog:

2019-01-20  Iain Buclaw  

* d-codegen.cc (identity_compare_p): Return false if seen built-in
type with padding.
(build_float_identity): Moved here from expr.cc.
(lower_struct_comparison): Handle real and complex types.
* d-tree.h (build_float_identity): New.
* expr.cc (build_float_identity): Move to d-codegen.cc.

gcc/testsuite/ChangeLog:

2019-01-20  Iain Buclaw  

* gdc.dg/runnable.d: Add more tests for comparing complex types.

---
diff --git a/gcc/d/d-codegen.cc b/gcc/d/d-codegen.cc
index 7ca0acffcc4..58c8257c63c 100644
--- a/gcc/d/d-codegen.cc
+++ b/gcc/d/d-codegen.cc
@@ -798,15 +798,21 @@ identity_compare_p (StructDeclaration *sd)
   for (size_t i = 0; i < sd->fields.dim; i++)
 {
   VarDeclaration *vd = sd->fields[i];
+  Type *tb = vd->type->toBasetype ();
 
   /* Check inner data structures.  */
-  if (vd->type->ty == Tstruct)
+  if (tb->ty == Tstruct)
 	{
-	  TypeStruct *ts = (TypeStruct *) vd->type;
+	  TypeStruct *ts = (TypeStruct *) tb;
 	  if (!identity_compare_p (ts->sym))
 	return false;
 	}
 
+  /* Check for types that may have padding.  */
+  if ((tb->ty == Tcomplex80 || tb->ty == Tfloat80 || tb->ty == Timaginary80)
+	  && Target::realpad != 0)
+	return false;
+
   if (offset <= vd->offset)
 	{
 	  /* There's a hole in the struct.  */
@@ -824,6 +830,20 @@ identity_compare_p (StructDeclaration *sd)
   return true;
 }
 
+/* Build a floating-point identity comparison between T1 and T2, ignoring any
+   excessive padding in the type.  CODE is EQ_EXPR or NE_EXPR comparison.  */
+
+tree
+build_float_identity (tree_code code, tree t1, tree t2)
+{
+  tree tmemcmp = builtin_decl_explicit (BUILT_IN_MEMCMP);
+  tree size = size_int (TYPE_PRECISION (TREE_TYPE (t1)) / BITS_PER_UNIT);
+
+  tree result = build_call_expr (tmemcmp, 3, build_address (t1),
+ build_address (t2), size);
+  return build_boolop (code, result, integer_zero_node);
+}
+
 /* Lower a field-by-field equality expression between T1 and T2 of type SD.
CODE is the EQ_EXPR or NE_EXPR comparison.  */
 
@@ -859,29 +879,45 @@ lower_struct_comparison (tree_code code, StructDeclaration *sd,
   for (size_t i = 0; i < sd->fields.dim; i++)
 {
   VarDeclaration *vd = sd->fields[i];
+  Type *type = vd->type->toBasetype ();
   tree sfield = get_symbol_decl (vd);
 
   tree t1ref = component_ref (t1, sfield);
   tree t2ref = component_ref (t2, sfield);
   tree tcmp;
 
-  if (vd->type->ty == Tstruct)
+  if (type->ty == Tstruct)
 	{
 	  /* Compare inner data structures.  */
-	  StructDeclaration *decl = ((TypeStruct *) vd->type)->sym;
+	  StructDeclaration *decl = ((TypeStruct *) type)->sym;
 	  tcmp = lower_struct_comparison (code, decl, t1ref, t2ref);
 	}
+  else if (type->ty != Tvector && type->isintegral ())
+	{
+	  /* Integer comparison, no special handling required.  */
+	  tcmp = build_boolop (code, t1ref, t2ref);
+	}
+  else if (type->ty != Tvector && type->isfloating ())
+	{
+	  /* Floating-point comparison, don't compare padding in type.  */
+	  if (!type->iscomplex ())
+	tcmp = build_float_identity (code, t1ref, t2ref);
+	  else
+	{
+	  tree req = build_float_identity (code, real_part (t1ref),
+	   real_part (t2ref));
+	  tree ieq = build_float_identity (code, imaginary_part (t1ref),
+	   imaginary_part (t2ref));
+
+	  tcmp = build_boolop (tcode, req, ieq);
+	}
+	}
   else
 	{
-	  tree stype = build_ctype (vd->type);
+	  tree stype = build_ctype (type);
 	  opt_scalar_int_mode mode = int_mode_for_mode (TYPE_MODE (stype));
 
-	  if (vd->type->ty != Tvector && vd->type->isintegral ())
-	{
-	  /* Integer comparison, no special handling required.  */
-	  tcmp = build_boolop (code, t1ref, t2ref);
-	}
-	  else if 

Re: [PATCH] i386: Move Intel intrinsics head files to

[Uros Bizjak]

On 1/19/19, H.J. Lu  wrote:
> According to Intel Intrinsics Guide:
>
> https://software.intel.com/sites/landingpage/IntrinsicsGuide/
>
> Intel intrinsics should be available by including .  This
> patch moves remaining Intel intrinsics head files from  to
> .

I can't find the quoted requirement in the provided link.

> OK for trunk?

You will need a RM approval for a non-regression fix patch at this point.

Uros.

> H.J.
> ---
>   PR target/71659
>   * config/i386/adxintrin.h: Just check _IMMINTRIN_H_INCLUDED.
>   * config/i386/clflushoptintrin.h: Check _IMMINTRIN_H_INCLUDED
>   instead of _X86INTRIN_H_INCLUDED.
>   * onfig/i386/clwbintrin.h: Likewise.
>   * config/i386/pkuintrin.h: Likewise.
>   * config/i386/prfchwintrin.h: Likewise.
>   * config/i386/rdseedintrin.h: Likewise.
>   * config/i386/wbnoinvdintrin.h: Likewise.
>   * config/i386/xsavecintrin.h: Likewise.
>   * config/i386/xsavesintrin.h: Likewise.
>   * config/i386/fxsrintrin.h: Enable _IMMINTRIN_H_INCLUDED check.
>   * config/i386/xsaveintrin.h: Likewise.
>   * config/i386/xsaveoptintrin.h: Likewise.
>   * config/i386/x86intrin.h: Move "#include" ,
>   , , ,
>   , , ,
>   , , ,
>and  to ...
>   * config/i386/immintrin.h: Here.
> ---
>  gcc/config/i386/adxintrin.h|  4 ++--
>  gcc/config/i386/clflushoptintrin.h |  4 ++--
>  gcc/config/i386/clwbintrin.h   |  4 ++--
>  gcc/config/i386/fxsrintrin.h   |  6 +++---
>  gcc/config/i386/immintrin.h| 24 
>  gcc/config/i386/pkuintrin.h|  4 ++--
>  gcc/config/i386/prfchwintrin.h |  4 ++--
>  gcc/config/i386/rdseedintrin.h |  4 ++--
>  gcc/config/i386/wbnoinvdintrin.h   |  4 ++--
>  gcc/config/i386/x86intrin.h| 28 
>  gcc/config/i386/xsavecintrin.h |  4 ++--
>  gcc/config/i386/xsaveintrin.h  |  6 +++---
>  gcc/config/i386/xsaveoptintrin.h   |  6 +++---
>  gcc/config/i386/xsavesintrin.h |  4 ++--
>  14 files changed, 51 insertions(+), 55 deletions(-)
>
> diff --git a/gcc/config/i386/adxintrin.h b/gcc/config/i386/adxintrin.h
> index e01b77ddb4b..e8cb004390c 100644
> --- a/gcc/config/i386/adxintrin.h
> +++ b/gcc/config/i386/adxintrin.h
> @@ -21,8 +21,8 @@
> see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> .  */
>
> -#if !defined _X86INTRIN_H_INCLUDED && !defined _IMMINTRIN_H_INCLUDED
> -# error "Never use  directly; include  instead."
> +#if !defined _IMMINTRIN_H_INCLUDED
> +# error "Never use  directly; include  instead."
>  #endif
>
>  #ifndef _ADXINTRIN_H_INCLUDED
> diff --git a/gcc/config/i386/clflushoptintrin.h
> b/gcc/config/i386/clflushoptintrin.h
> index 1e720c2515c..89aa0f68fc2 100644
> --- a/gcc/config/i386/clflushoptintrin.h
> +++ b/gcc/config/i386/clflushoptintrin.h
> @@ -21,8 +21,8 @@
> see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> .  */
>
> -#if !defined _X86INTRIN_H_INCLUDED
> -# error "Never use  directly; include 
> instead."
> +#if !defined _IMMINTRIN_H_INCLUDED
> +# error "Never use  directly; include 
> instead."
>  #endif
>
>  #ifndef _CLFLUSHOPTINTRIN_H_INCLUDED
> diff --git a/gcc/config/i386/clwbintrin.h b/gcc/config/i386/clwbintrin.h
> index 217fb3babf2..68b20ea1635 100644
> --- a/gcc/config/i386/clwbintrin.h
> +++ b/gcc/config/i386/clwbintrin.h
> @@ -21,8 +21,8 @@
> see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> .  */
>
> -#if !defined _X86INTRIN_H_INCLUDED
> -# error "Never use  directly; include 
> instead."
> +#if !defined _IMMINTRIN_H_INCLUDED
> +# error "Never use  directly; include 
> instead."
>  #endif
>
>  #ifndef _CLWBINTRIN_H_INCLUDED
> diff --git a/gcc/config/i386/fxsrintrin.h b/gcc/config/i386/fxsrintrin.h
> index ff6c6f848eb..c4b12cf25f3 100644
> --- a/gcc/config/i386/fxsrintrin.h
> +++ b/gcc/config/i386/fxsrintrin.h
> @@ -21,9 +21,9 @@
> see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
> .  */
>
> -/* #if !defined _X86INTRIN_H_INCLUDED && !defined _IMMINTRIN_H_INCLUDED */
> -/* # error "Never use  directly; include 
> instead." */
> -/* #endif */
> +#if !defined _IMMINTRIN_H_INCLUDED
> +# error "Never use  directly; include 
> instead."
> +#endif
>
>  #ifndef _FXSRINTRIN_H_INCLUDED
>  #define _FXSRINTRIN_H_INCLUDED
> diff --git a/gcc/config/i386/immintrin.h b/gcc/config/i386/immintrin.h
> index 6ce00012b42..10e1f27c605 100644
> --- a/gcc/config/i386/immintrin.h
> +++ b/gcc/config/i386/immintrin.h
> @@ -38,6 +38,16 @@
>
>  #include 
>
> +#include 
> +
> +#include 
> +
> +#include 
> +
> +#include 
> +
> +#include 
> +
>  #include 
>
>  #include 
> @@ -120,6 +130,20 @@
>
>  #include 
>
> +#include 
> +
> +#include 
> +
> +#include 
> +
> +#include 
> +
> +#include 
> +
> +#include 
> +
> +#include 
> +
>  extern __inline void
>  

[libbacktrace,PATCH] Fix non-portable printf format in allocfail.c

[Gerald Pfeifer]

This addresses another fallout from the libbacktrace changes applied
in November.


libbacktrace/allocfail.c has the following declaration:

  extern uint64_t get_nr_allocs (void);

And in line 133 then the following:

  fprintf (stderr, "%lu\n", get_nr_allocs ());

On a 32-bit system such as x86 this creates a mismatch between %lu 
(32-bit) and the third parameter (64-bit).


The patch below addresses it; tested on i586-unknown-freebsd11.3.

Okay?

Gerald

2019-01-20  Gerald Pfeifer  

* allocfail.c (main): Increase portability of printf statement.

Index: libbacktrace/allocfail.c
===
--- libbacktrace/allocfail.c(revision 268102)
+++ libbacktrace/allocfail.c(working copy)
@@ -130,7 +130,7 @@ main (int argc, char **argv)
 #endif
 
   if (argc == 1)
-fprintf (stderr, "%lu\n", get_nr_allocs ());
+fprintf (stderr, "%llu\n", (long long unsigned) get_nr_allocs ());
 
   exit (failures ? EXIT_FAILURE : EXIT_SUCCESS);
 }

[PATCH] doc: showcase a "union of vectors" pattern (PR 88698)

[Alexander Monakov]

Hi,

PR 88698 ("Relax generic vector conversions") is asking to be more permissive
about type compatibility for generic vector types.  While I don't think that's
a good idea per se, from a "compiler user" point of view I also see how writing
code for SSE/AVX using both generic vectors and x86 intrinsics is inconvenient
because all intrinsics use the same type such as __m128i, regardless of whether
they operate on 8/16/32/64-bit signed/unsigned lanes.

My solution to that is to introduce a union type that holds both the type
accepted by intrinsics and generic vector types used by my code. It also has
an interesting effect that each statement spells out the lane type.

Is it appropriate to showcase this approach in our documentation, as done in
this patch?  What to do with the PR, should I leave it open?

PR c/88698
* doc/extend.texi (Vector Extensions): Add an example of using vector
types together with x86 intrinsics.

--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -10632,6 +10632,40 @@ v4si g = __builtin_convertvector (f, v4si); /* g is 
@{1,-2,3,7@} */
 v4si h = __builtin_convertvector (c, v4si); /* h is @{1,5,0,10@} */
 @end smallexample
 
+@cindex vector types, using with x86 intrinsics
+Sometimes it is desirable to write code using a mix of generic vector
+operations (for clarity) and machine-specific vector intrinsics (to
+access vector instructions that are not exposed via generic built-ins).
+On x86, intrinsic functions for integer vectors typically use the same
+vector type @code{__m128i} irrespective of how they interpret the vector,
+making it necessary to cast their arguments and return values from/to
+other vector types.  In C, you can make use of a @code{union} type:
+@c In C++ such type punning via a union is not allowed by the language
+@smallexample
+#include 
+
+typedef unsigned char u8x16 __attribute__ ((vector_size (16)));
+typedef unsigned int  u32x4 __attribute__ ((vector_size (16)));
+
+typedef union @{
+u8x16   u8;
+u32x4   u32;
+__m128i mm;
+@} v128;
+@end smallexample
+
+@noindent
+for variables that can be used with both built-in operations and x86
+intrinsics:
+
+@smallexample
+v128 x, y = @{ 0 @};
+memcpy (, ptr, sizeof x);
+y.u8  += 0x80;
+x.mm  = _mm_adds_epu8 (x.mm, y.mm);
+x.u32 &= 0xff;
+@end smallexample
+
 @node Offsetof
 @section Support for @code{offsetof}
 @findex __builtin_offsetof