[PATCH] PR libgcc/59714 complex division is surprising on aarch64

[vladimir . mezentsev]

From: Vladimir Mezentsev 

Tested on aarch64-linux-gnu, x86_64-pc-linux-gnu and sparc64-unknown-linux-gnu.
No regression. New tests now passed.
There is a performance degradation for complex double type:

  failed cases  |time
   old   new|   old  new
complex-32  150 |  3.51  3.56
complex-64  190 |  1.88  2.34
complex-128 340 |  3.71  2.88

The formula for complex division (a+bi)/(c+di) is (a*c+b*d)/(c*c+d*d) + 
(b*c-a*d)/(c*c+d*d)i
The current implementation avoids overflow in (c*c + d*d) using
  x=MAX(|c|, |d|);  c1=c/x; d1=d/x;
and then calculating the result as
  (a*c1+b*d1)/(c1*c1+d1*d1)*(1.0/x) + (b*c1-a*d1)/(c1*c1+d1*d1)*(1.0/x)i

This approach has two issues:
  1. Unexpected rounding when x is not a power of 2.0
 For example, (1.0+3.0i) /(1.0+3.0i) should be 1.0
 but it is (1.0 - 1.66533e-17i) on aarch64 (PR59714)
  2. Unexpected underflow in c/x or d/x.
 For example, (0x1.0p+1023 + 0x0.8p-1022 i)/(0x1.0p+677 + 0x1.0p-677 i)
 should be (0x1.0p+346 - 0x1.0p-1008 i) but it is (0x1.0p+346)

My implementation avoids these issues.
I use soft-fp instead built-in functions because performance with built-in
functions (like __builtin_ilogb) is in two times worse.
Also libm is needed for built-in functions.

Restrictions:
  An old implementation is used when an architecture doesn't provide 
sfp-machine.h
  An old implementation is used for __divkc3 (I have no access on rs6000 for 
testing)

ChangeLog:
2018-02-05  Vladimir Mezentsev  

PR libgcc/59714
* libgcc/libgcc2.c: New complex division implementation
* libgcc/soft-fp/quad.h: struct _FP_STRUCT_LAYOUT was redefined
* libgcc/config/no-sfp-machine.h: Add _NO_SFP_MACHINE_H
* libgcc/config/sparc/sfp-machine.h: New
* gcc/testsuite/gcc.c-torture/execute/pr59714_128.c: New test
* gcc/testsuite/gcc.c-torture/execute/pr59714_32.c: New test
* gcc/testsuite/gcc.c-torture/execute/pr59714_64.c: New test
---
 gcc/testsuite/gcc.c-torture/execute/pr59714_128.c | 506 ++
 gcc/testsuite/gcc.c-torture/execute/pr59714_32.c  | 506 ++
 gcc/testsuite/gcc.c-torture/execute/pr59714_64.c  | 506 ++
 libgcc/config/no-sfp-machine.h|   3 +
 libgcc/config/sparc/sfp-machine.h |  14 +
 libgcc/libgcc2.c  | 178 +++-
 libgcc/soft-fp/quad.h |   2 +-
 7 files changed, 1710 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr59714_128.c
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr59714_32.c
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr59714_64.c
 create mode 100644 libgcc/config/sparc/sfp-machine.h

diff --git a/gcc/testsuite/gcc.c-torture/execute/pr59714_128.c 
b/gcc/testsuite/gcc.c-torture/execute/pr59714_128.c
new file mode 100644
index 000..e26f40a
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr59714_128.c
@@ -0,0 +1,506 @@
+#include 
+#include 
+
+extern void abort (void);
+#define FABS(x) ((x) >= 0 ? (x) : -(x))
+#define FTYPE   long double
+#define FMT "%-39.28La"
+
+/*
+   Tables of numbers for complex division testing
+   All values in hex format
+   z[i] == correctly rounded value of x[i]/y[i];
+ */
+
+#define NUMCNT 100
+
+__complex FTYPE x[NUMCNT] =
+  {
+0x1.0p0L + 0x1.0p0Li,  /* #1 */
+0x1.0p0L + 0x1.0p0Li,  /* #2 */
+0x1.0p1023L + 0x1.0p-1023Li,   /* #3 */
+0x1.0p1023L + 0x1.0p1023Li,/* #4 */
+0x1.0p1020L + 0x1.0p-844Li,/* #5 */
+0x1.0p-71L + 0x1.0p1021Li, /* #6 */
+0x1.0p-347L + 0x1.0p-54Li, /* #7 */
+0x1.0p-1074L + 0x1.0p-1074Li,  /* #8 */
+0x1.0p1015L + 0x1.0p-989Li,/* #9 */
+0x1.0p-622L + 0x1.0p-1071Li,   /* #10 */
+0x1.0p0L + 0x3.0p0Li,  /* #11 */
+-0x1.0p0L + 0x3.0p0Li, /* #12 */
+0x1.0p0L - 0x3.0p0Li,  /* #13 */
+0x3.0p0L + 0x1.0p0Li,  /* #14 */
+0x3.0p0L + 0x4.0p0Li,  /* #15 */
+0x1.0p0L - 0x3.1p-20Li,/* #16 */
+0x1.0p0L + 0x3.001p-20Li,  /* #17 */
+0x1.0p0L + 0x1.80002p1Li,  /* #18 */
+0x1.0p0L + 0x1.80004p1Li,  /* #19 */
+0x1.0p0L + 0x1.80008p1Li,  /* #20 */
+0x1.0p0L + 0x1.80010p1Li,  /* #21 */
+0x1.0p0L + 0x1.80020p1Li,  /* #22 */
+0x1.0p0L + 0x1.80040p1Li,  /* #23 */
+0x1.0p0L + 0x1.80080p1Li,  /* #24 */
+0x1.0p0L + 0x1.7ff8p1Li,   /* #25 */
+0x1.0p0L + 0x1.7ff0p1Li,   /* #26 */
+0x1.0p0L + 0x1.7f80p1Li,   /* #27 */
+0x1.0p0L + 0x1.7f00p1Li,   /* #28 */
+0x5.0p0L + 0x5.0p0Li,  /* #29 */
+0x4.0p0L + 0x3.0p0Li,  /* #30 */
+-0x4.0p0L + 0x3.1p0Li, /* #31 */
+

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

[David Edelsohn]

On Mon, Feb 5, 2018 at 9:43 PM, Peter Bergner  wrote:
> On 2/5/18 7:32 PM, David Edelsohn wrote:
>> Peter,
>>
>> Why can't you place the tests into the final condition of the pattern
>> so that the pattern fails and the normal GCC fallback machinery is
>> used instead of manually implementing the fallback emulation?
>
> You mean something like the following which I already tried?
>
> (define_expand "div3"
>   [(set (match_operand:GPR 0 "gpc_reg_operand" "")
> (div:GPR (match_operand:GPR 1 "gpc_reg_operand" "")
>  (match_operand:GPR 2 "reg_or_cint_operand" "")))]
>   "mode != DImode || TARGET_POWERPC64"
> {
>   if (CONST_INT_P (operands[2])
>   && INTVAL (operands[2]) > 0
>   && exact_log2 (INTVAL (operands[2])) >= 0)
> {
>   emit_insn (gen_div3_sra (operands[0], operands[1], operands[2]));
>   DONE;
> }
>   operands[2] = force_reg (mode, operands[2]);
> })
>
>
> The problem with the above is that the condition doesn't seem to be able
> to stop explicit calls to the gen_divdi3() function as long as there is
> some conditions in which the conditional test is true.  Since the condition
> is true for -m64, we create the gen_divdi3() function in insn-emit.c and
> then it seems any explicit calls to that function are fair game, even
> when they come from -m32 compiles.  In this case, the explicit call is
> coming from:
>
> ; Emulate vector with scalar for vec_div in V2DImode
> (define_insn_and_split "vsx_div_v2di"
>   [(set (match_operand:V2DI 0 "vsx_register_operand" "=wa")
> (unspec:V2DI [(match_operand:V2DI 1 "vsx_register_operand" "wa")
>   (match_operand:V2DI 2 "vsx_register_operand" "wa")]
>  UNSPEC_VSX_DIVSD))]
>   "VECTOR_MEM_VSX_P (V2DImode)"
>   "#"
>   "VECTOR_MEM_VSX_P (V2DImode) && !reload_completed"
>   [(const_int 0)]
>   "
> {
>   rtx op0 = operands[0];
>   rtx op1 = operands[1];
>   rtx op2 = operands[2];
>   rtx op3 = gen_reg_rtx (DImode);
>   rtx op4 = gen_reg_rtx (DImode);
>   rtx op5 = gen_reg_rtx (DImode);
>   emit_insn (gen_vsx_extract_v2di (op3, op1, GEN_INT (0)));
>   emit_insn (gen_vsx_extract_v2di (op4, op2, GEN_INT (0)));
>   emit_insn (gen_divdi3 (op5, op3, op4));   <-- Here
>   emit_insn (gen_vsx_extract_v2di (op3, op1, GEN_INT (1)));
>   emit_insn (gen_vsx_extract_v2di (op4, op2, GEN_INT (1)));
>   emit_insn (gen_divdi3 (op3, op3, op4));   <-- Here
>   emit_insn (gen_vsx_concat_v2di (op0, op5, op3));
>   DONE;
> }"
>   [(set_attr "type" "div")])
>
> I did also try calling expand_divmod() here which did generate correct
> code, the problem was that it wasn't as clean/optimized as the change
> to gen_divdi3.

Why not fix it at the site of the call to gen_divdi3 instead of the
divdi3 pattern?

Your patch is trying to clean up invocations of methods under
circumstances that they should not be called. This should be avoided
at the call site.  vsx_div_v2di is violating the API when it makes the
call.  vsx_div_v2di knows whether TARGET_POWERPC64 is in effect.
vsx_div_v2di can choose the emulation path.

Your patch seems to be fixing the symptom, not the problem.

Thanks, David

[PING #2] [PATCH] make -Wrestrict for strcat more meaningful (PR 83698)

[Martin Sebor]

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01488.html

As I mentioned, this doesn't solve a regression per se but
rather implements what I consider an important usability
improvement to the -Wrestrict warnings.  Printing offsets
that are the most meaningful makes debugging the problems
the warnings point out easier.

On 01/30/2018 10:24 AM, Martin Sebor wrote:

Ping: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01488.html

This is a minor improvement but there have been a couple of
comments lately pointing out that the numbers in the -Wrestrict
messages can make them confusing.

Jakub, since you made one of those comments (the other came up
in the context of bug 84095 - [8 Regression] false-positive
-Wrestrict warnings for memcpy within array).  Can you please
either approve this patch or suggest changes?

On 01/16/2018 05:35 PM, Martin Sebor wrote:

On 01/16/2018 02:32 PM, Jakub Jelinek wrote:

On Tue, Jan 16, 2018 at 01:36:26PM -0700, Martin Sebor wrote:

--- gcc/gimple-ssa-warn-restrict.c(revision 256752)
+++ gcc/gimple-ssa-warn-restrict.c(working copy)
@@ -384,6 +384,12 @@ builtin_memref::builtin_memref (tree expr, tree si
   base = SSA_NAME_VAR (base);
   }

+  if (DECL_P (base) && TREE_CODE (TREE_TYPE (base)) == ARRAY_TYPE)
+{
+  if (offrange[0] < 0 && offrange[1] > 0)
+offrange[0] = 0;
+}


Why the 2 nested ifs?


No particular reason.  There may have been more code in there
that I ended up removing.  Or a comment.  I can remove the
extra braces when the patch is approved.




@@ -1079,14 +1085,35 @@ builtin_access::strcat_overlap ()
 return false;

   /* When strcat overlap is certain it is always a single byte:
- the terminatinn NUL, regardless of offsets and sizes.  When
+ the terminating NUL, regardless of offsets and sizes.  When
  overlap is only possible its range is [0, 1].  */
   acs.ovlsiz[0] = dstref->sizrange[0] == dstref->sizrange[1] ? 1 : 0;
   acs.ovlsiz[1] = 1;
-  acs.ovloff[0] = (dstref->sizrange[0] +
dstref->offrange[0]).to_shwi ();
-  acs.ovloff[1] = (dstref->sizrange[1] +
dstref->offrange[1]).to_shwi ();


You use to_shwi many times in the patch, do the callers or something
earlier
in this function guarantee that you aren't throwing away any bits
(unlike
tree_to_shwi, to_shwi method doesn't ICE, just throws away upper bits).
Especially when you perform additions like here, even if both
wide_ints fit
into a shwi, the result might not.


No, I'm not sure.  In fact, it wouldn't surprise me if it did
happen.  It doesn't cause false positives or negatives but it
can make the offsets less than meaningful in cases where they
are within valid bounds.  There are also cases where they are
meaningless to begin with and there is little the pass can do
about that.

IMO, the ideal solution to the first problem is to add a format
specifier for wide ints to the pretty printer and get rid of
the conversions.  It's probably too late for something like
that now but I'd like to do it for GCC 9.  Unless someone
files a bug/regression, it's also too late for me to go and
try to find and fix these conversions now.

Martin

PS While looking for a case you asked about I came up with
the following.  I don't think there's any slicing involved
but the offsets are just as meaningless as if there were.
I think the way to do significantly better is to detect
out-of-bounds offsets earlier (e.g., as in this patch:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02143.html)

$ cat z.c && gcc -O2 -S -Warray-bounds -m32 z.c
extern int a[];

void f (__PTRDIFF_TYPE__ i)
{
  if (i < __PTRDIFF_MAX__ - 7 || __PTRDIFF_MAX__ - 5 < i)
i = __PTRDIFF_MAX__ -  7;

  const int *s = a + i;

  __builtin_memcpy (a, [i], 3);
}
z.c: In function ‘f’:
z.c:10:3: warning: ‘__builtin_memcpy’ offset [-64, -48] is out of the
bounds of object ‘a’ with type ‘int[]’ [-Warray-bounds]
   __builtin_memcpy (a, [i], 3);
   ^~
z.c:1:12: note: ‘a’ declared here
 extern int a[];
^

Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)

[Martin Sebor]

On 02/05/2018 05:55 PM, Joseph Myers wrote:

On Mon, 5 Feb 2018, Martin Sebor wrote:


On 02/05/2018 04:44 PM, Joseph Myers wrote:

On Sun, 4 Feb 2018, Martin Sebor wrote:


We've talked about (2) in the past (bug 71463) but this seems
like an opportunity to revisit it and (hopefully) make a change
to treat these the same as all other function attributes rather
than type attributes.  Besides fixing the wrong code bugs and


I'd say that actually more attributes should be made into type attributes
where they are currently function attributes - anything that affects
optimizations or warnings in the caller based on properties of the callee
is something where it's meaningful to have a pointer-to-function where the
pointed-to function type has that property.


What then happens when the pointer to which the attributes are
transferred (presumably by initialization) is then assigned
the address of a function that has different attributes that?


The pointer object gets the attributes by being declared with the
appropriate attribute.  (Example: the error member of struct cpp_callbacks
in cpplib.h.)  If a pointer to a function that lacks the required property
is stored in the object with pointer-to-attributed-function type, that's a
bug - just as it's a bug if a function is declared with an attribute
without satisfying the required properties.


Oh, I see what you mean.  I thought you were suggesting to
transparently transfer the attributes to the pointer type
on initialization.

I agree that making it possible to explictly specify some
of these attributes on function pointers (i.e., making
them type attributes) would be useful.  Provided, of
course, that incompatible conversions were diagnosed.

Martin

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

[Peter Bergner]

On 2/5/18 7:32 PM, David Edelsohn wrote:
> Peter,
> 
> Why can't you place the tests into the final condition of the pattern
> so that the pattern fails and the normal GCC fallback machinery is
> used instead of manually implementing the fallback emulation?

You mean something like the following which I already tried?

(define_expand "div3"
  [(set (match_operand:GPR 0 "gpc_reg_operand" "")
(div:GPR (match_operand:GPR 1 "gpc_reg_operand" "")
 (match_operand:GPR 2 "reg_or_cint_operand" "")))]
  "mode != DImode || TARGET_POWERPC64"
{
  if (CONST_INT_P (operands[2])
  && INTVAL (operands[2]) > 0
  && exact_log2 (INTVAL (operands[2])) >= 0)
{
  emit_insn (gen_div3_sra (operands[0], operands[1], operands[2]));
  DONE;
}
  operands[2] = force_reg (mode, operands[2]);
})


The problem with the above is that the condition doesn't seem to be able
to stop explicit calls to the gen_divdi3() function as long as there is
some conditions in which the conditional test is true.  Since the condition
is true for -m64, we create the gen_divdi3() function in insn-emit.c and
then it seems any explicit calls to that function are fair game, even
when they come from -m32 compiles.  In this case, the explicit call is
coming from:

; Emulate vector with scalar for vec_div in V2DImode
(define_insn_and_split "vsx_div_v2di"
  [(set (match_operand:V2DI 0 "vsx_register_operand" "=wa")
(unspec:V2DI [(match_operand:V2DI 1 "vsx_register_operand" "wa")
  (match_operand:V2DI 2 "vsx_register_operand" "wa")]
 UNSPEC_VSX_DIVSD))]
  "VECTOR_MEM_VSX_P (V2DImode)"
  "#"
  "VECTOR_MEM_VSX_P (V2DImode) && !reload_completed"
  [(const_int 0)]
  "
{
  rtx op0 = operands[0];
  rtx op1 = operands[1];
  rtx op2 = operands[2];
  rtx op3 = gen_reg_rtx (DImode);
  rtx op4 = gen_reg_rtx (DImode);
  rtx op5 = gen_reg_rtx (DImode);
  emit_insn (gen_vsx_extract_v2di (op3, op1, GEN_INT (0)));
  emit_insn (gen_vsx_extract_v2di (op4, op2, GEN_INT (0)));
  emit_insn (gen_divdi3 (op5, op3, op4));   <-- Here
  emit_insn (gen_vsx_extract_v2di (op3, op1, GEN_INT (1)));
  emit_insn (gen_vsx_extract_v2di (op4, op2, GEN_INT (1)));
  emit_insn (gen_divdi3 (op3, op3, op4));   <-- Here
  emit_insn (gen_vsx_concat_v2di (op0, op5, op3));
  DONE;
}"
  [(set_attr "type" "div")])

I did also try calling expand_divmod() here which did generate correct
code, the problem was that it wasn't as clean/optimized as the change
to gen_divdi3.

Peter

Re: [PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

[David Edelsohn]

Peter,

Why can't you place the tests into the final condition of the pattern
so that the pattern fails and the normal GCC fallback machinery is
used instead of manually implementing the fallback emulation?

The GPR iterator only defines DI for TARGET_POWERPC64, so how does GCC
get into the muldi3 pattern, for example, and also satisfy both

(define_mode_iterator GPR [SI (DI "TARGET_POWERPC64")])

mode == DImode && !TARGET_POWERPC64

This seems contradictory.

Thanks, David

Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)

[Joseph Myers]

On Mon, 5 Feb 2018, Martin Sebor wrote:

> On 02/05/2018 04:44 PM, Joseph Myers wrote:
> > On Sun, 4 Feb 2018, Martin Sebor wrote:
> > 
> > > We've talked about (2) in the past (bug 71463) but this seems
> > > like an opportunity to revisit it and (hopefully) make a change
> > > to treat these the same as all other function attributes rather
> > > than type attributes.  Besides fixing the wrong code bugs and
> > 
> > I'd say that actually more attributes should be made into type attributes
> > where they are currently function attributes - anything that affects
> > optimizations or warnings in the caller based on properties of the callee
> > is something where it's meaningful to have a pointer-to-function where the
> > pointed-to function type has that property.
> 
> What then happens when the pointer to which the attributes are
> transferred (presumably by initialization) is then assigned
> the address of a function that has different attributes that?

The pointer object gets the attributes by being declared with the 
appropriate attribute.  (Example: the error member of struct cpp_callbacks 
in cpplib.h.)  If a pointer to a function that lacks the required property 
is stored in the object with pointer-to-attributed-function type, that's a 
bug - just as it's a bug if a function is declared with an attribute 
without satisfying the required properties.

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

Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)

[Martin Sebor]

On 02/05/2018 04:44 PM, Joseph Myers wrote:

On Sun, 4 Feb 2018, Martin Sebor wrote:


We've talked about (2) in the past (bug 71463) but this seems
like an opportunity to revisit it and (hopefully) make a change
to treat these the same as all other function attributes rather
than type attributes.  Besides fixing the wrong code bugs and


I'd say that actually more attributes should be made into type attributes
where they are currently function attributes - anything that affects
optimizations or warnings in the caller based on properties of the callee
is something where it's meaningful to have a pointer-to-function where the
pointed-to function type has that property.


What then happens when the pointer to which the attributes are
transferred (presumably by initialization) is then assigned
the address of a function that has different attributes that?

Based on testing, transferring type attributes doesn't seem to
have a beneficial effect on the generated code.  For example,
G++ treats const and pure as function attributes but
returns_nonnull as a type attribute.  Calls made from function
templates via a pointer are treated according to the constness
and "pureness" of the actual argument to the template (i.e.,
that of the function passed to it as an argument).  But similar
calls seem to disregard the returns_nonnull attribute and lead
to suboptimal code when a function with the attribute is passed
to the template.  I haven't spent enough time to understand why
that is yet, but anecdotally what I have seen suggests using
type attributes leads to problems.  At least in C++.

Martin

[PATCH, rs6000] Fix PR83926, ICE using __builtin_vsx_{div,udiv,mul}_2di builtins

[Peter Bergner]

PR83926 shows a problem in expanding the _builtin_vsx_{div,udiv,mul}_2di
builtins in 32-bit mode.  The problem is that the splitters for the
patterns explicitly call gen_{div,udiv,mul}di3 patterns, even in 32-bit
mode and those patterns assume the associated 64-bit HW instructions exist
when they do not.  The "fix" implemented here is to modify gen_{div,udiv,mul}
to catch the case when we have DImode operands in 32-bit mode (and not using
-mpowerpc64) and do the right thing.  In the case of gen_{div,udiv}di3, that
means calling their lib functions and for gen_muldi3, we call expand_mult()
which emits code that does the 64-bit multiply.

This passes bootstrap and regtesting on powerpc64le-linux, as well as on
powerpc64-linux (running the testsuite in both 32-bit and 64-bit modes).
Ok for trunk?

Peter

gcc/
PR target/83926
* config/rs6000/rs6000.md (*mul3): Rename to this...
(mul3): ...from this.  Declare new define_expand.
(*udiv3): Rename to this...
(udiv3): ...from this.  Declare new define_expand.
(div3): Handle DImode operands in 32-bit mode.

gcc/testsuite/
PR target/83926
* gcc.target/powerpc/pr83926.c: New test.

Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 257390)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -2872,8 +2872,21 @@
   DONE;
 }")
 
+(define_expand "mul3"
+  [(set (match_operand:GPR 0 "gpc_reg_operand" "")
+   (mult:GPR (match_operand:GPR 1 "gpc_reg_operand" "")
+ (match_operand:GPR 2 "reg_or_short_operand" "")))]
+  ""
+{
+  if (mode == DImode && !TARGET_POWERPC64)
+{
+  rtx ret = expand_mult (DImode, operands[1], operands[2], NULL, 0, false);
+  emit_move_insn (operands[0], ret);
+  DONE;
+}
+})
 
-(define_insn "mul3"
+(define_insn "*mul3"
   [(set (match_operand:GPR 0 "gpc_reg_operand" "=r,r")
(mult:GPR (match_operand:GPR 1 "gpc_reg_operand" "%r,r")
  (match_operand:GPR 2 "reg_or_short_operand" "r,I")))]
@@ -3040,7 +3053,25 @@
   "maddld %0,%1,%2,%3"
   [(set_attr "type" "mul")])
 
-(define_insn "udiv3"
+(define_expand "udiv3"
+  [(set (match_operand:GPR 0 "gpc_reg_operand" "")
+   (udiv:GPR (match_operand:GPR 1 "gpc_reg_operand" "")
+ (match_operand:GPR 2 "gpc_reg_operand" "")))]
+  ""
+{
+  if (mode == DImode && !TARGET_POWERPC64)
+{
+  rtx libfunc = optab_libfunc (udiv_optab, mode);
+  rtx target = emit_library_call_value (libfunc,
+   operands[0], LCT_NORMAL, mode,
+   operands[1], mode,
+   operands[2], mode);
+  emit_move_insn (operands[0], target);
+  DONE;
+}
+})
+
+(define_insn "*udiv3"
   [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
 (udiv:GPR (match_operand:GPR 1 "gpc_reg_operand" "r")
  (match_operand:GPR 2 "gpc_reg_operand" "r")))]
@@ -3066,7 +3097,16 @@
   emit_insn (gen_div3_sra (operands[0], operands[1], operands[2]));
   DONE;
 }
-
+  else if (mode == DImode && !TARGET_POWERPC64)
+{
+  rtx libfunc = optab_libfunc (sdiv_optab, mode);
+  rtx target = emit_library_call_value (libfunc,
+   operands[0], LCT_NORMAL, mode,
+   operands[1], mode,
+   operands[2], mode);
+  emit_move_insn (operands[0], target);
+  DONE;
+}
   operands[2] = force_reg (mode, operands[2]);
 })
 
Index: gcc/testsuite/gcc.target/powerpc/pr83926.c
===
--- gcc/testsuite/gcc.target/powerpc/pr83926.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr83926.c  (working copy)
@@ -0,0 +1,22 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
+/* { dg-options "-O2 -mcpu=power8 -mno-fold-gimple" } */
+
+__attribute__ ((altivec(vector__))) long long
+sdiv (__attribute__ ((altivec(vector__))) long long a,
+  __attribute__ ((altivec(vector__))) long long b)
+{
+  return __builtin_vsx_div_2di (a, b);
+}
+__attribute__ ((altivec(vector__))) unsigned long long
+udiv (__attribute__ ((altivec(vector__))) unsigned long long a,
+  __attribute__ ((altivec(vector__))) unsigned long long b)
+{
+  return __builtin_vsx_udiv_2di (a, b);
+}
+__attribute__ ((altivec(vector__))) long long
+smul (__attribute__ ((altivec(vector__))) long long a,
+  __attribute__ ((altivec(vector__))) long long b)
+{
+  return __builtin_vsx_mul_2di (a, b);
+}

Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)

[Joseph Myers]

On Sun, 4 Feb 2018, Martin Sebor wrote:

> We've talked about (2) in the past (bug 71463) but this seems
> like an opportunity to revisit it and (hopefully) make a change
> to treat these the same as all other function attributes rather
> than type attributes.  Besides fixing the wrong code bugs and

I'd say that actually more attributes should be made into type attributes 
where they are currently function attributes - anything that affects 
optimizations or warnings in the caller based on properties of the callee 
is something where it's meaningful to have a pointer-to-function where the 
pointed-to function type has that property.

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

Re: [PATCH] PowerPC PR target/84154, fix floating point to small integer conversion regression

[Michael Meissner]

On Mon, Feb 05, 2018 at 08:01:32AM -0600, Segher Boessenkool wrote:
> On Mon, Feb 05, 2018 at 07:54:58AM -0500, Michael Meissner wrote:
> > On Mon, Feb 05, 2018 at 05:57:25AM -0600, Segher Boessenkool wrote:
> > > On Thu, Feb 01, 2018 at 02:31:17PM -0500, Michael Meissner wrote:
> > > > This patch fixes the optimization regression that occurred on GCC 7 
> > > > where
> > > > conversions from the various floating point types to small integers 
> > > > would at
> > > > times generate a store and a load.
> > > 
> > > [ snip big explanation; thanks for that! ]
> > > 
> > > Could you merge the signed and unsigned patterns, using any_fix?  Or is
> > > there a reason that cannot work (other than that  unsigned_fix seems
> > > buggy, it should say "u")?
> > 
> > Well that's the way the instructions are.  For traditional FPR instructions 
> > we
> > have FCTIWZ vs. FCTIWUZ, while on the VSX side we have XSCVDPSXWS
> > vs. XSCVDPUXWS.  If you mean the name of the insn, I can change it if 
> > desired,
> > but originally it was based on the FPR insn name.
> 
> We have
> 
> (define_code_attr su [(sign_extend  "s")
>   (zero_extend  "u")
>   (fix  "s")
>   (unsigned_fix "s")
>   (float"s")
>   (unsigned_float   "u")])
> 
> and "s" for unsigned_fix seems like it should be "u".  Very surprising
> otherwise (if this is needed in some case, it should just write "s" there
> instead of "").
> 
> > > Okay for trunk even without that (but please try).  Also okay for 7 after
> > > looking for fallout.
> > 
> > In the past, I have found that combining code iterators with two mode 
> > iterators
> > has a bug where it would use the wrong code iterator, so I just avoided 
> > doing
> > that.  I'll see if it is still a bug.
> 
> Hrm.  If you have multiple iterators you often need to use ":" syntax,
> and you might want that anyway because the precedence rules are non-obvious;
> but you are hitting something else?  Please open a PR if so :-)

I already do use the : syntax.

I found as long as I avoid putting the  or  in the output template
(i.e. use an output statement instead of a template) it works.  It only
seems to fail in the IEEE128 case, and not in the SFDF case.  I will submit a
bug report  on it after this gets checked in, as it will be simpler to provide
a patch that people can test.

This patch cleans up all of the {,unsigned_}fix patterns that convert to QImode
or HImode.  It adds the memory combiner to include SImode to the mix.  While I
was at it, I combined the IEEE insns to use any_fix.

I have checked this patch on both little endian and big endian power8 systems,
and I have have hand checked the code for power7 and power9 systems.  There
were no regressions in the test suite, the new tests were verified to run, and
I did bootstrap builds on both systems.  The big endian power8 system also
32-bit tests as well as 64-bit tests.  Can I apply this patch to the trunk and
after a waiting period, apply the patch to the GCC 7 branch?

[gcc]
2018-02-05  Michael Meissner  

PR target/84154
* config/rs6000/rs6000.md (fix_trunc2):
Convert from define_expand to be define_insn_and_split.  Rework
float/double/_Float128 conversions to QI/HI/SImode to work with
both ISA 2.07 (power8) or ISA 3.0 (power9).  Fix regression where
conversions to QI/HImode types did a store and then a load to
truncate the value.  For conversions to VSX registers, don't split
the insn, instead emit the code directly.  Use the code iterator
any_fix to combine signed and unsigned conversions.
(fix_truncsi2_p8): Likewise.
(fixuns_trunc2): Likewise.
(fix_trunc2): Likewise.
(fix_trunc2): Likewise.
(fix_di2_hw): Likewise.
(fixuns_di2_hw): Likewise.
(fix_si2_hw): Likewise.
(fixuns_si2_hw): Likewise.
(fix_2_hw): Likewise.
(fix_trunc2): Likewise.
(fctiwz__smallint): Rename fctiwz__smallint to
fix_truncsi2_p8.
(fix_trunc2_internal): Delete, no longer
used.
(fixuns_trunc2_internal): Likewise.
(fix__mem): Likewise.
(fctiwz__mem): Likewise.
(fix__mem): Likewise.
(fix_trunc2_mem): On ISA 3.0, prevent
the register allocator from doing a direct move to the GPRs to do
a store, and instead use the ISA 3.0 store byte/half-word from
vector register instruction.  For IEEE 128-bit floating point,
also optimize stores of 32-bit ints.
(fix_trunc2_mem): Likewise.

[gcc/testsuite]
2018-02-05  Michael Meissner  

PR target/84154
* gcc.target/powerpc/pr84154-1.c: New tests.
* gcc.target/powerpc/pr84154-2.c: Likewise.
* gcc.target/powerpc/pr84154-3.c: Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 

Re: [RFC PATCH] avoid applying attributes to explicit specializations (PR 83871)

[Jason Merrill]

On 02/04/2018 07:07 PM, Martin Sebor wrote:

To resolve the underlying root cause of the P1 bug c++/83503
- bogus -Wattributes for const and pure on function template
specialization, that we discussed last week, I've taken a stab
at making the change to avoid applying primary template's
attributes to its explicit specializations.  (The bug tracking
the underlying root cause is 83871 - wrong code for attribute
const and pure on distinct template specializations).

The attached patch is what I have so far.  It's incomplete
and not all the tests pass for a couple of reasons:

1) it only handles function templates (not class templates),
    and I have no tests for those yet,


Class templates may already work the way you expect; at least aligned 
does, though that doesn't involve TYPE_ATTRIBUTES.


Hmm, it seems that we currently don't propagate unused even to implicit 
instantiations, a bug in the other direction:


template  struct [[gnu::unused]] A { };

int main()
{
  A a; // shouldn't warn
}


2) it isn't effective for the nonnull and returns_nonnull
    attributes because they are treated as type attributes,
3) the change to deal with attributes on function arguments
    may be unnecessary (I couldn't come up with any that would
    be propagated from the primary -- are there some?).


Yes, I think this is unnecessary.


Before I proceed with it I first want to make sure that it should
be fixed for GCC 8,


Some of it, I think.  Probably not the whole issue.


that duplicate_decls is the right place for these changes


I think so.


and that (2) should be fixed by treating those
and other such attributes by applying them to function decls.


This seems out of bounds for GCC 8.  It would also mean that we couldn't 
use such attributes on pointers to functions.



+ TREE_NOTHROW (newdecl) |= TREE_NOTHROW (olddecl);


TREE_NOTHROW is mostly a non-attribute property, so I'd leave it out of 
this.



+ DECL_IS_MALLOC (olddecl) = DECL_IS_MALLOC (newdecl);


If a template is declared to be malloc, IMO we should really warn if a 
specialization is missing that attribute, it seems certain to be a mistake.


In general, I think we should (optionally) warn if a template has 
attributes and a specialization doesn't, as a user might have been 
relying on the current behavior.



+  if (!merge_attr)
+   {
+ /* Remove the two function attributes that are, in fact,
+treated as (quasi) type attributes.  */
+ tree attrs = TYPE_ATTRIBUTES (newtype);
+ tree newattrs = remove_attribute ("nonnull", attrs);
+ newattrs = remove_attribute ("returns_nonnull", attrs);
+ if (newattrs != attrs)
+   TYPE_ATTRIBUTES (newtype) = newattrs;
+   }


Instead of this, we should avoid calling merge_types and just use 
TREE_TYPE (newdecl) for newtype.


Jason

New Swedish PO file for 'gcc' (version 8.1-b20180128)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

http://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-8.1-b20180128.sv.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/gcc/

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/gcc.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.

Re: [testsuite] Make lto.exp work with Tcl 8.4

[Mike Stump]

On Feb 5, 2018, at 9:54 AM, Richard Sandiford  
wrote:
> 
> "dict" was added in Tcl 8.5, but until a couple of weeks ago the
> testsuite has worked with 8.4.
> 
> This patch uses arrays instead, like we do for the caching in
> target-supports.exp.  It is a bit uglier than using dicts was,
> but hopefully not too bad...
> 
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Ok.

Re: [patch, libfortran] Use flexible array members for array descriptor

[Thomas Koenig]

Am 05.02.2018 um 13:09 schrieb Janne Blomqvist:

On Sun, Feb 4, 2018 at 9:49 PM, Thomas Koenig  wrote:

Hello world,

in the attached patch, I have used flexible array members for
using the different descriptor types (following Richi's advice).
This does not change the binary ABI, but the library code
maches what we are actually doing in the front end.  I have
not yet given up hope of enabling LTO for the library :-)
and this, I think, will be a prerequisite.

OK for trunk?


Given that Jakub and Richi apparently weren't yet unanimous in their
recommendations on the best path forward, maybe wait a bit for the
smoke to clear?


Make sense.  Depending on what the solution is, this (or a variant)
will probably part of the patch.


In the meantime, a few comments:

1) Is there some particular benefit to all those macroized
descriptors, given that the only thing different is the type of the
base_addr pointer? Wouldn't it be simpler to just have a single
descriptor type with base_addr a void pointer, then typecast that
pointer to whatever type is needed?


I don't particulary like going through void* pointers - it is
clearer to leave an int* as an int*.


2)

Index: intrinsics/date_and_time.c
===
--- intrinsics/date_and_time.c (Revision 257347)
+++ intrinsics/date_and_time.c (Arbeitskopie)
@@ -268,7 +268,7 @@ secnds (GFC_REAL_4 *x)
GFC_REAL_4 temp1, temp2;

/* Make the INTEGER*4 array for passing to date_and_time.  */
-  gfc_array_i4 *avalues = xmalloc (sizeof (gfc_array_i4));
+  gfc_array_i4 *avalues = xmalloc (sizeof (gfc_full_array_i4));


Since date_and_time requires the values array to always be rank 1,
can't this be "xmalloc (sizeof (gfc_array_i4) +
sizeof(dimension_data))" ?


I think we can be fairly sure that this would be OK at the moment, since
(I think) there are no gaps in our descriptors at the moment. Anybody
invents an architecture where this is not the case, we introduce
a bug. This way is safer.

Regards

Thomas

Re: [PATCH][PR c++/82888] smarter code for default initialization of scalar arrays

[Jason Merrill]

On Thu, Dec 21, 2017 at 1:51 PM, Jason Merrill  wrote:
> On Wed, Nov 29, 2017 at 4:30 PM, Jason Merrill  wrote:
>> On Fri, Nov 17, 2017 at 11:04 PM, Nathan Froyd  wrote:
>>> On Fri, Nov 17, 2017 at 8:50 AM, Jason Merrill  wrote:
 On Thu, Nov 16, 2017 at 11:21 AM, Nathan Froyd  wrote:
> diff --git a/gcc/cp/init.c b/gcc/cp/init.c
> index c76460d..53d6133 100644
> --- a/gcc/cp/init.c
> +++ b/gcc/cp/init.c
> @@ -4038,6 +4038,15 @@ build_vec_init (tree base, tree maxindex, tree 
> init,
> }
>  }
>
> +  /* Default-initialize scalar arrays directly.  */
> +  if (TREE_CODE (atype) == ARRAY_TYPE
> +  && SCALAR_TYPE_P (TREE_TYPE (atype))
> +  && !init)

 This should check explicit_value_init._p rather than !init.  And also
 check zero_init_p.
>>>
>>> Do you mean explicit_value_init_p && zero_init_p (atype)?
>>
>> Yes.
>>
>>> zero_init_p
>>> doesn't sound like the correct thing to use here, because it doesn't
>>> take into account whether a class array type has a constructor.  I am
>>> probably misunderstanding the purpose of the zero_init_p check,
>>> though.
>>
>> Since you're already checking for scalar type, we don't need to worry
>> about classes.  The zero_init_p check is to handle pointers to data
>> members properly.
>
> Any update?

?

Re: Go patch committed: Avoid negative zero in float constants

[Rainer Orth]

Hi Ian,

>> unfortunately, this broke bootstrap with mpfr 2.4.2, which is still the
>> minimum version documented in install.texi:
>
> Bother.  Thanks for the note.  I've rolled back the patch, as follows.

thanks.  I'm right now experimenting to bootstrap with the current
versions.  As I'd reported before, there are testsuite failures on
Solaris (both sparc and x86)

https://gcc.gnu.org/ml/gcc/2018-01/msg00217.html

but I don't yet know if they affect gcc.

Rainer

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

Re: Go patch committed: Avoid negative zero in float constants

[Ian Lance Taylor]

On Mon, Feb 5, 2018 at 10:47 AM, Rainer Orth
 wrote:
>
>> This patch to the Go frontend checks for negative numbers with very
>> small magnitudes that will round to negative zero, and forces them to
>> positive zero instead.  This implements the spec clarification in
>> https://golang.org/cl/14727.  The test is in
>> https://golang.org/cl/91895.  This fixes golang.org/issue/12621.
>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
>> to mainline.
>
> unfortunately, this broke bootstrap with mpfr 2.4.2, which is still the
> minimum version documented in install.texi:

Bother.  Thanks for the note.  I've rolled back the patch, as follows.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 257390)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-7eebd495df915ab87926b8dd88f554674cfdacea
+c02c71187c9794b50444e2858c582e66a3442ee8
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc(revision 257390)
+++ gcc/go/gofrontend/expressions.cc(working copy)
@@ -16158,16 +16158,10 @@ Numeric_constant::set_float(Type* type,
   this->clear();
   this->classification_ = NC_FLOAT;
   this->type_ = type;
-
   // Numeric constants do not have negative zero values, so remove
   // them here.  They also don't have infinity or NaN values, but we
   // should never see them here.
-  int bits = 0;
-  if (type != NULL
-  && type->float_type() != NULL
-  && !type->float_type()->is_abstract())
-bits = type->float_type()->bits();
-  if (Numeric_constant::is_float_zero(val, bits))
+  if (mpfr_zero_p(val))
 mpfr_init_set_ui(this->u_.float_val, 0, GMP_RNDN);
   else
 mpfr_init_set(this->u_.float_val, val, GMP_RNDN);
@@ -16181,50 +16175,8 @@ Numeric_constant::set_complex(Type* type
   this->clear();
   this->classification_ = NC_COMPLEX;
   this->type_ = type;
-
-  // Avoid negative zero as in set_float.
-  int bits = 0;
-  if (type != NULL
-  && type->complex_type() != NULL
-  && !type->complex_type()->is_abstract())
-bits = type->complex_type()->bits() / 2;
-
-  mpfr_t real;
-  mpfr_init_set(real, mpc_realref(val), GMP_RNDN);
-  if (Numeric_constant::is_float_zero(real, bits))
-mpfr_set_ui(real, 0, GMP_RNDN);
-
-  mpfr_t imag;
-  mpfr_init_set(imag, mpc_imagref(val), GMP_RNDN);
-  if (Numeric_constant::is_float_zero(imag, bits))
-mpfr_set_ui(imag, 0, GMP_RNDN);
-
   mpc_init2(this->u_.complex_val, mpc_precision);
-  mpc_set_fr_fr(this->u_.complex_val, real, imag, MPC_RNDNN);
-
-  mpfr_clear(real);
-  mpfr_clear(imag);
-}
-
-// Return whether VAL, at a precision of BITS, is zero.  BITS may be
-// zero in which case it is ignored.
-
-bool
-Numeric_constant::is_float_zero(const mpfr_t val, int bits)
-{
-  if (mpfr_zero_p(val))
-return true;
-  switch (bits)
-{
-case 0:
-  return false;
-case 32:
-  return mpfr_get_flt(val, GMP_RNDN) == 0;
-case 64:
-  return mpfr_get_d(val, GMP_RNDN) == 0;
-default:
-  go_unreachable();
-}
+  mpc_set(this->u_.complex_val, val, MPC_RNDNN);
 }
 
 // Get an int value.
Index: gcc/go/gofrontend/expressions.h
===
--- gcc/go/gofrontend/expressions.h (revision 257390)
+++ gcc/go/gofrontend/expressions.h (working copy)
@@ -4220,9 +4220,6 @@ class Numeric_constant
   bool
   check_complex_type(Complex_type*, bool, Location);
 
-  static bool
-  is_float_zero(const mpfr_t, int bits);
-
   // The kinds of constants.
   enum Classification
   {

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

[Peter Bergner]

On 2/1/18 1:25 PM, Peter Bergner wrote:
> On 2/1/18 8:50 AM, Segher Boessenkool wrote:
>> I think we also want this for 7 (after a bit of burn in).  I wouldn't
>> bother with 6 though (the problem has existed since 4.7).
> 
> Ok, committed.  I'll wait a few days before committing the FSF 7 back port.

And now committed to the FSF 7 release branch.

Peter

Re: RFA: Sanitize deprecation messages (PR 84195)

[Martin Sebor]

On 02/05/2018 10:07 AM, Nick Clifton wrote:

Hi Martin, Hi Dodji, Hi David,

  PR 84195 makes the point that deprecation messages do not follow the
  formatting guidelines set out by the -fmessage-length option, and that
  they could even contain unwanted control characters:

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

  Below is my attempt at a patch to fix this.  It is not very clever,
  just replacing the control characters with spaces, and doing it each
  time that a deprecation warning is displayed.  But I figured that
  such warnings are going to be rare and do not need to be efficiently
  handled.  So I choose to keep it simple. :-)


Thanks for working on this!  I agree your patch is an improvement.

My only suggestions are to consider how control characters and
excessively messages are handled in other contexts and adopt
the same approach here.  In the tests I did, control characters
were mostly escaped (e.g., as \n or as \x0a) rather than replaced
with spaces.  I haven't thought too hard about how excessively
long messages should be handled, or about the interactions with
-fmessage-length= (i.e., if messages longer than the limit should
be broken up.)

Martin



  No regressions with an x86_64-pc-linux-gnu toolchain.

  OK to apply ?

Cheers
  Nick

gcc/ChangeLog
2018-02-05  Nick Clifton  

PR 84195
* tree.c (warn_deprecated_use): Sanitize deprecation messages.

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 257389)
+++ gcc/tree.c  (working copy)
@@ -12436,6 +12436,39 @@
   else
 msg = NULL;

+  char * new_msg = NULL;
+  if (msg)
+{
+  unsigned int i; /* FIXME: Do we need to check to see if msg is longer
+than 2^32 ?  */
+
+  /* PR 84195: Sanitize the message:
+   
+If -fmessage-length is set to 0 then replace newline characters with
+spaces.  Replace other non-printing ASCII characters with spaces too.
+
+We do this check here, rather than where the deprecated attribute is
+recorded because the setting of -fmessage-length can be changed
+between those two locations.  */
+  for (i = 0; i < strlen (msg); i++)
+   {
+ char c = msg[i];
+   
+ if (! ISCNTRL (c))
+   continue;
+
+ if (c != '\n' || ! pp_is_wrapping_line (global_dc->printer))
+   {
+ if (new_msg == NULL)
+   new_msg = xstrdup (msg);
+ new_msg [i] = ' ';
+   }
+   }
+
+  if (new_msg)
+   msg = new_msg;
+}
+
   bool w;
   if (DECL_P (node))
 {
@@ -12505,6 +12538,8 @@
}
}
 }
+
+  free (new_msg);
 }

 /* Return true if REF has a COMPONENT_REF with a bit-field field declaration

Re: Go patch committed: Avoid negative zero in float constants

[Rainer Orth]

Hi Ian,

> This patch to the Go frontend checks for negative numbers with very
> small magnitudes that will round to negative zero, and forces them to
> positive zero instead.  This implements the spec clarification in
> https://golang.org/cl/14727.  The test is in
> https://golang.org/cl/91895.  This fixes golang.org/issue/12621.
> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
> to mainline.

unfortunately, this broke bootstrap with mpfr 2.4.2, which is still the
minimum version documented in install.texi:

/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/expressions.cc: In static member 
function 'static bool Numeric_constant::is_float_zero(const __mpfr_struct*, 
int)':
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/expressions.cc:16222:14: error: 
'mpfr_get_flt' was not declared in this scope
   return mpfr_get_flt(val, GMP_RNDN) == 0;
  ^~~~
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/expressions.cc:16222:14: note: 
suggested alternative: 'mpfr_get_ld'
   return mpfr_get_flt(val, GMP_RNDN) == 0;
  ^~~~
  mpfr_get_ld

Rainer

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

Re: C++ PATCH to fix rejects-valid with constexpr ctor in C++17 (PR c++/83692)

[Jason Merrill]

On Mon, Feb 5, 2018 at 8:37 AM, Marek Polacek  wrote:
> On Fri, Feb 02, 2018 at 02:11:27PM -0500, Jason Merrill wrote:
>> On Thu, Jan 25, 2018 at 4:16 PM, Marek Polacek  wrote:
>> > This is a similar problem to 83116: we'd cached a constexpr call, but 
>> > after a
>> > store the result had become invalid, yet we used the wrong result again 
>> > when
>> > encountering the same call later.  This resulted in evaluating a THROW_EXPR
>> > which doesn't work.  Details in
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83692#c5
>> >
>> > The fix for 83116 didn't work here, because when evaluating the body of the
>> > ctor via store_init_value -> cxx_constant_value we are in STRICT, so we do
>> > cache.
>>
>> > It seems that we may no longer rely on the constexpr call table when we
>> > do cxx_eval_store_expression, because that just rewrites *valp, i.e. the
>> > value of an object.  Might be too big a hammer again, but I couldn't think
>> > of how I could guard the caching of a constexpr call.
>>
>> > This doesn't manifest in C++14 because build_special_member_call in C++17 
>> > is
>> > more aggressive with copy elisions (as required by P0135 which changed how 
>> > we
>> > view prvalues).  In C++14 build_special_member_call produces a CALL_EXPR, 
>> > so
>> > expand_default_init calls maybe_constant_init, for which STRICT is false, 
>> > so
>> > we avoid caching as per 83116.
>>
>> So it sounds like the problem is using cxx_constant_value for the
>> diagnostic when it has different semantics from the
>> maybe_constant_init that follows right after.  I guess we want a
>> cxx_constant_init function that is a hybrid of the two.
>
> So like the following?  Thanks,
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-02-04  Marek Polacek  
>
> PR c++/83692
> * constexpr.c (cxx_constant_init): New function.
> * cp-tree.h (cxx_constant_init): Declare.
> * typeck2.c (store_init_value): Call cxx_constant_init instead of
> cxx_constant_value.
>
> +/* Like cxx_constant_value, but non-strict mode.  */
> +
> +tree
> +cxx_constant_init (tree t, tree decl)
> +{
> +  return cxx_eval_outermost_constant_expr (t, false, false, decl);
> +}

Hmm, that doesn't do the TARGET_EXPR stripping that
maybe_constant_init does.  I was thinking of a version of
maybe_constant_init that passes false to allow_non_constant.  Probably
by making "maybe_constant_init" and cxx_constant_init both call the
current function with an additional parameter.  And then the existing
call to maybe_constant_init can move under an 'else' to avoid
redundant constexpr evaluation.

Jason

[PATCH, rs6000] Deprecate -mno-speculate-indirect-jumps

[Bill Schmidt]

Hi,

It's been determined that we won't recommend use of the recently added
undocumented option -mno-speculate-indirect-jumps.  This patch provides
a warning indicating that the option is deprecated.  We will leave the
code in place for potential emergency use (not expected), and plan to
remove it completely in GCC 9.

Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Is this okay for trunk?  At least one distribution partner has also
requested that we backport this to the GCC 7 branch for 7.4.  Is that
okay as well?

Thanks,
Bill


[gcc]

2018-02-05  Bill Schmidt  

* config/rs6000/rs6000.c (rs6000_option_override_internal):
Display warning message for -mno-speculate-indirect-jumps.

[gcc/testsuite]

2018-02-05  Bill Schmidt  

* gcc.target/powerpc/safe-indirect-jump-1.c: Detect deprecation
warning for -mno-speculate-indirect-jumps.
* gcc.target/powerpc/safe-indirect-jump-2.c: Likewise.
* gcc.target/powerpc/safe-indirect-jump-3.c: Likewise.
* gcc.target/powerpc/safe-indirect-jump-4.c: Likewise.
* gcc.target/powerpc/safe-indirect-jump-5.c: Likewise.
* gcc.target/powerpc/safe-indirect-jump-6.c: Likewise.
* gcc.target/powerpc/safe-indirect-jump-7.c: Likewise.


Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 257367)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -5295,6 +5295,11 @@ rs6000_option_override_internal (bool global_init_
   if (TARGET_LINK_STACK == -1)
 SET_TARGET_LINK_STACK (rs6000_tune == PROCESSOR_PPC476 && flag_pic);
 
+  /* Deprecate use of -mno-speculate-indirect-jumps.  */
+  if (!rs6000_speculate_indirect_jumps)
+warning (0, "%qs is deprecated and not recommended in any circumstances",
+"-mno-speculate-indirect-jumps");
+
   return ret;
 }
 
Index: gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-1.c
===
--- gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-1.c (revision 
257367)
+++ gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-1.c (working copy)
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-additional-options "-mno-speculate-indirect-jumps" } */
+/* { dg-warning "'-mno-speculate-indirect-jumps' is deprecated" "" { target 
*-*-* } 0 } */
 
 /* Test for deliberate misprediction of indirect calls.  */
 
Index: gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-2.c
===
--- gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-2.c (revision 
257367)
+++ gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-2.c (working copy)
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-mno-speculate-indirect-jumps" } */
+/* { dg-warning "'-mno-speculate-indirect-jumps' is deprecated" "" { target 
*-*-* } 0 } */
 
 /* Test for deliberate misprediction of computed goto.  */
 
Index: gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-3.c
===
--- gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-3.c (revision 
257367)
+++ gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-3.c (working copy)
@@ -1,5 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-mno-speculate-indirect-jumps" } */
+/* { dg-warning "'-mno-speculate-indirect-jumps' is deprecated" "" { target 
*-*-* } 0 } */
 
 /* Test for deliberate misprediction of jump tables.  */
 
Index: gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-4.c
===
--- gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-4.c (revision 
257367)
+++ gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-4.c (working copy)
@@ -1,5 +1,6 @@
 /* { dg-do run } */
 /* { dg-additional-options "-mno-speculate-indirect-jumps" } */
+/* { dg-warning "'-mno-speculate-indirect-jumps' is deprecated" "" { target 
*-*-* } 0 } */
 
 /* Test for deliberate misprediction of indirect calls for ELFv2.  */
 
Index: gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-5.c
===
--- gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-5.c (revision 
257367)
+++ gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-5.c (working copy)
@@ -1,5 +1,6 @@
 /* { dg-do run } */
 /* { dg-additional-options "-mno-speculate-indirect-jumps -Wno-pedantic" } */
+/* { dg-warning "'-mno-speculate-indirect-jumps' is deprecated" "" { target 
*-*-* } 0 } */
 
 /* Test for deliberate misprediction of computed goto.  */
 
Index: gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-6.c
===
--- gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-6.c (revision 
257367)
+++ 

[testsuite] Make lto.exp work with Tcl 8.4

[Richard Sandiford]

"dict" was added in Tcl 8.5, but until a couple of weeks ago the
testsuite has worked with 8.4.

This patch uses arrays instead, like we do for the caching in
target-supports.exp.  It is a bit uglier than using dicts was,
but hopefully not too bad...

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Richard


2018-02-05  Richard Sandiford  

gcc/testsuite/
* lib/lto.exp (lto_handle_diagnostics): Remove messages_by_file
argument and use dg-messages-by-file instead.  Expect it to be
an array rather than a dict.
(lto-link-and-maybe-run): Remove messages_by_file argument and
use an upvar for dg-messages-by-file.  Update call to
lto_handle_diagnostics.
(lt-get-options): Treat dg-messages-by-file as an array
rather than a dict.
(lto-get-options-main): Likewise.  Set the entry rather than appending.
(lto-execute): Treat dg-messages-by-file as an array rather than
a dict.  Update call to lto-link-and-maybe-run.

Index: gcc/testsuite/lib/lto.exp
===
--- gcc/testsuite/lib/lto.exp   2018-01-19 11:57:10.397017291 +
+++ gcc/testsuite/lib/lto.exp   2018-02-05 17:51:17.386215067 +
@@ -111,18 +111,22 @@ proc lto_handle_diagnostics_for_file { n
 # the expected diagnostics within TEXT, issuing PASS/FAIL results.
 # Return TEXT, stripped of any diagnostics that were handled.
 #
-# MESSAGES_BY_FILE is a dict; the keys are source files (with paths)
-# the values are lists of expected messages, akin to DejaGnu's "dg-messages"
-# variable.
 # TEXT is the textual output from the LTO link.
 
-proc lto_handle_diagnostics { messages_by_file text } {
+proc lto_handle_diagnostics { text } {
 global testcase
 
+upvar dg-messages-by-file messages_by_file
+
 verbose "lto_handle_diagnostics: entry: $text" 2
-verbose "  messages_by_file $messages_by_file" 3
 
-dict for {src dg-messages} $messages_by_file {
+if { ![array exists messages_by_file] } {
+   error "lto_handle_diagnostics: messages_by_file not defined"
+}
+
+foreach src [lsort [array names messages_by_file]] {
+   set dg-messages $messages_by_file($src)
+   verbose "  messages for $src: ${dg-messages}" 3
set text [lto_handle_diagnostics_for_file $testcase $src \
  ${dg-messages} $text]
 }
@@ -294,16 +298,15 @@ proc lto-obj { source dest optall optfil
 # OPTALL is a list of compiler and linker options to use for all tests
 # OPTFILE is a list of compiler and linker options to use for this test
 # OPTSTR is the list of options to list in messages
-# MESSAGES_BY_FILE is a dict of (src, dg-messages)
-proc lto-link-and-maybe-run { testname objlist dest optall optfile optstr \
- messages_by_file } {
+proc lto-link-and-maybe-run { testname objlist dest optall optfile optstr } {
 global testcase
 global tool
 global compile_type
 global board_info
 
+upvar dg-messages-by-file dg-messages-by-file
+
 verbose "lto-link-and-maybe-run" 2
-verbose "  messages_by_file $messages_by_file" 3
 
 # Check that all of the objects were built successfully.
 foreach obj [split $objlist] {
@@ -342,7 +345,7 @@ proc lto-link-and-maybe-run { testname o
 }
 
 # Check for diagnostics specified by directives
-set comp_output [lto_handle_diagnostics $messages_by_file $comp_output]
+set comp_output [lto_handle_diagnostics $comp_output]
 
 # Prune unimportant visibility warnings before checking output.
 set comp_output [lto_prune_warns $comp_output]
@@ -527,7 +530,7 @@ proc lto-get-options-main { src } {
 }
 
 verbose "dg-messages: ${dg-messages}" 3
-dict append dg-messages-by-file $src ${dg-messages}
+set dg-messages-by-file($src) ${dg-messages}
 
 # Return flags to use for compiling the primary source file and for
 # linking.
@@ -578,7 +581,11 @@ proc lto-get-options { src } {
 }
 
 verbose "dg-messages: ${dg-messages}" 3
-dict append dg-messages-by-file $src ${dg-messages}
+if { [info exists dg-messages-by-file($src)] } {
+   append dg-messages-by-file($src) ${dg-messages}
+} else {
+   set dg-messages-by-file($src) ${dg-messages}
+}
 
 return ${dg-extra-tool-flags}
 }
@@ -609,7 +616,7 @@ proc lto-execute { src1 sid } {
 verbose "lto-execute: $src1" 1
 set compile_type "run"
 set dg-do-what [list ${dg-do-what-default} "" P]
-set dg-messages-by-file [dict create]
+array set dg-messages-by-file [list]
 set extra_flags(0) [lto-get-options-main $src1]
 set compile_xfail(0) "" 
 
@@ -733,7 +740,7 @@ proc lto-execute { src1 sid } {
lto-link-and-maybe-run \
"[lindex $obj_list 0]-[lindex $obj_list end]" \
$obj_list $execname $filtered ${dg-extra-ld-options} \
-   $filtered ${dg-messages-by-file}
+

Re: Do not lose track of resolution info due to tree merging

[Richard Biener]

On February 5, 2018 3:49:25 PM GMT+01:00, Jan Hubicka  wrote:
>Hi,
>in the testcase of PR81004 we produce wrong code (reference to
>optimized out
>comdat symbol) due to strange sequence of events that is initiated by
>fact
>that after streaming in a comdat group we sed one of resolution infos
>to
>LDPR_UNKNOWN.
>
>This is because of tree merging with earlier unit that streams the
>symbol for
>debug info but does not use it and thus there is no symtab entry.
>
>Currently resolutions are streamed in a funny way - they are indexed by
>decls
>and passed through plugin to be read back as array and later attached
>into hash
>to tree nodes to be later written into symtab node (where they belong).
>This is quite crazy design but I do not see how to easy clean it up, so
>this
>fixes the problem and I will add cleanup to my todo for next stage1.
>
>patch also adds sanity checking so we error out on missing relocation
>info.
>I have checked this works with non-plugin path.
>I did not add testcase because it is very fragile (depends on what we
>stream)
>and it already does not reproduce on mainline without Jakub's patch to
>clear
>abstract origins in free_lang_data reverted.
>
>Bootstrapped/regtested x86_64-linux, ltobootstrap in progress (passing
>stage2)
>OK?

I think unify_scc is only ever called from WPA so you can elide the flag_ltrans 
checks. 

Otherwise OK. 

Thanks, 
Richard. 

>Honza
>   PR lto/81004
>   * lto.c (register_resolution): Merge resolutions in case trees was
>   merged across units.
>   (lto_maybe_register_decl): Break out from ...
>   (lto_read_decls): ... here.
>   (unify_scc): Also register decls here.
>   (read_cgraph_and_symbols): Sanity check that all resolutions was
>   read.
>   * symtab.c (symtab_node::verify_base): Verify that externaly visible
>   symbol has PUBLIC decl.
>Index: lto/lto.c
>===
>--- lto/lto.c  (revision 257382)
>+++ lto/lto.c  (working copy)
>@@ -830,12 +830,20 @@ static void
> register_resolution (struct lto_file_decl_data *file_data, tree decl,
>enum ld_plugin_symbol_resolution resolution)
> {
>+  bool existed;
>   if (resolution == LDPR_UNKNOWN)
> return;
>   if (!file_data->resolution_map)
> file_data->resolution_map
>   = new hash_map;
>-  file_data->resolution_map->put (decl, resolution);
>+  ld_plugin_symbol_resolution_t 
>+ = file_data->resolution_map->get_or_insert (decl, );
>+  gcc_assert (!existed || res == resolution);
>+  if (!existed
>+  || resolution == LDPR_PREVAILING_DEF_IRONLY
>+  || resolution == LDPR_PREVAILING_DEF
>+  || resolution == LDPR_PREVAILING_DEF_IRONLY_EXP)
>+res = resolution;
> }
> 
> /* Register DECL with the global symbol table and change its
>@@ -878,6 +886,18 @@ lto_register_function_decl_in_symtab (st
>decl, get_resolution (data_in, ix));
> }
> 
>+/* Check if T is a decl and needs register its resolution info.  */
>+
>+static void
>+lto_maybe_register_decl (struct data_in *data_in, tree t, unsigned ix)
>+{
>+  if (TREE_CODE (t) == VAR_DECL)
>+lto_register_var_decl_in_symtab (data_in, t, ix);
>+  else if (TREE_CODE (t) == FUNCTION_DECL
>+ && !DECL_BUILT_IN (t))
>+lto_register_function_decl_in_symtab (data_in, t, ix);
>+}
>+
> 
> /* For the type T re-materialize it in the type variant list and
>the pointer/reference-to chains.  */
>@@ -1617,7 +1637,11 @@ unify_scc (struct data_in *data_in, unsi
> /* Fixup the streamer cache with the prevailing nodes according
>to the tree node mapping computed by compare_tree_sccs.  */
> if (len == 1)
>-  streamer_tree_cache_replace_tree (cache, pscc->entries[0], from);
>+  {
>+if (!flag_ltrans)
>+  lto_maybe_register_decl (data_in, pscc->entries[0], from);
>+ streamer_tree_cache_replace_tree (cache, pscc->entries[0],
>from);
>+  }
> else
>   {
> tree *map2 = XALLOCAVEC (tree, 2 * len);
>@@ -1625,6 +1649,8 @@ unify_scc (struct data_in *data_in, unsi
>   {
> map2[i*2] = (tree)(uintptr_t)(from + i);
> map2[i*2+1] = scc->entries[i];
>+if (!flag_ltrans)
>+  lto_maybe_register_decl (data_in, scc->entries[i], from + 
>i);
>   }
> qsort (map2, len, 2 * sizeof (tree), cmp_tree);
> qsort (map, len, 2 * sizeof (tree), cmp_tree);
>@@ -1761,13 +1787,7 @@ lto_read_decls (struct lto_file_decl_dat
>   cache_integer_cst (t);
> if (!flag_ltrans)
>   {
>-/* Register variables and functions with the
>-   symbol table.  */
>-if (TREE_CODE (t) == VAR_DECL)
>-  lto_register_var_decl_in_symtab (data_in, t, from + i);
>-else if (TREE_CODE (t) 

Re: Extend aligned_membuf<> usage

[Jonathan Wakely]

On 01/02/18 22:48 +0100, François Dumont wrote:

Hi

    As we just bump version namespace it might be interesting to do 
the following change now. What do you think ?


I'd rather not make the code harder to read in all those places just
for an optional mode that nobody uses.

Wouldn't it make more sense to simply make __aligned_buffer identical
to __aligned_membuf for the versioned-namespace? Then at least the
conditional code is only in one place.

RFA: Sanitize deprecation messages (PR 84195)

[Nick Clifton]

Hi Martin, Hi Dodji, Hi David,

  PR 84195 makes the point that deprecation messages do not follow the
  formatting guidelines set out by the -fmessage-length option, and that
  they could even contain unwanted control characters:
  
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84195

  Below is my attempt at a patch to fix this.  It is not very clever,
  just replacing the control characters with spaces, and doing it each
  time that a deprecation warning is displayed.  But I figured that
  such warnings are going to be rare and do not need to be efficiently
  handled.  So I choose to keep it simple. :-)

  No regressions with an x86_64-pc-linux-gnu toolchain.

  OK to apply ?

Cheers
  Nick

gcc/ChangeLog
2018-02-05  Nick Clifton  

PR 84195
* tree.c (warn_deprecated_use): Sanitize deprecation messages.

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 257389)
+++ gcc/tree.c  (working copy)
@@ -12436,6 +12436,39 @@
   else
 msg = NULL;
 
+  char * new_msg = NULL;
+  if (msg)
+{
+  unsigned int i; /* FIXME: Do we need to check to see if msg is longer
+than 2^32 ?  */
+
+  /* PR 84195: Sanitize the message:
+
+If -fmessage-length is set to 0 then replace newline characters with
+spaces.  Replace other non-printing ASCII characters with spaces too.
+
+We do this check here, rather than where the deprecated attribute is
+recorded because the setting of -fmessage-length can be changed
+between those two locations.  */
+  for (i = 0; i < strlen (msg); i++)
+   {
+ char c = msg[i];
+ 
+ if (! ISCNTRL (c))
+   continue;
+
+ if (c != '\n' || ! pp_is_wrapping_line (global_dc->printer))
+   {
+ if (new_msg == NULL)
+   new_msg = xstrdup (msg);
+ new_msg [i] = ' ';
+   }
+   }
+
+  if (new_msg)
+   msg = new_msg;
+}
+
   bool w;
   if (DECL_P (node))
 {
@@ -12505,6 +12538,8 @@
}
}
 }
+
+  free (new_msg);
 }
 
 /* Return true if REF has a COMPONENT_REF with a bit-field field declaration

Please accept this commit for the trunk

[Douglas Mencken]

I’m about

“ [PATCH 2/4] [Darwin,PPC] Remove uses of LR in
restore_world ” https://gcc.gnu.org/bugzilla/attachment.cgi?id=42304

look at bug #84113 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 for
more info

“ One important question ’s yet: Why this patch has been ignored despite
it’s been made just in time? ”

my 0.04 gccçoins
Douglas

Go patch committed: Avoid negative zero in float constants

[Ian Lance Taylor]

This patch to the Go frontend checks for negative numbers with very
small magnitudes that will round to negative zero, and forces them to
positive zero instead.  This implements the spec clarification in
https://golang.org/cl/14727.  The test is in
https://golang.org/cl/91895.  This fixes golang.org/issue/12621.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 257379)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-36594b69b94326014c331fe50a5a345ef4f8de16
+7eebd495df915ab87926b8dd88f554674cfdacea
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc(revision 257379)
+++ gcc/go/gofrontend/expressions.cc(working copy)
@@ -16158,10 +16158,16 @@ Numeric_constant::set_float(Type* type,
   this->clear();
   this->classification_ = NC_FLOAT;
   this->type_ = type;
+
   // Numeric constants do not have negative zero values, so remove
   // them here.  They also don't have infinity or NaN values, but we
   // should never see them here.
-  if (mpfr_zero_p(val))
+  int bits = 0;
+  if (type != NULL
+  && type->float_type() != NULL
+  && !type->float_type()->is_abstract())
+bits = type->float_type()->bits();
+  if (Numeric_constant::is_float_zero(val, bits))
 mpfr_init_set_ui(this->u_.float_val, 0, GMP_RNDN);
   else
 mpfr_init_set(this->u_.float_val, val, GMP_RNDN);
@@ -16175,8 +16181,50 @@ Numeric_constant::set_complex(Type* type
   this->clear();
   this->classification_ = NC_COMPLEX;
   this->type_ = type;
+
+  // Avoid negative zero as in set_float.
+  int bits = 0;
+  if (type != NULL
+  && type->complex_type() != NULL
+  && !type->complex_type()->is_abstract())
+bits = type->complex_type()->bits() / 2;
+
+  mpfr_t real;
+  mpfr_init_set(real, mpc_realref(val), GMP_RNDN);
+  if (Numeric_constant::is_float_zero(real, bits))
+mpfr_set_ui(real, 0, GMP_RNDN);
+
+  mpfr_t imag;
+  mpfr_init_set(imag, mpc_imagref(val), GMP_RNDN);
+  if (Numeric_constant::is_float_zero(imag, bits))
+mpfr_set_ui(imag, 0, GMP_RNDN);
+
   mpc_init2(this->u_.complex_val, mpc_precision);
-  mpc_set(this->u_.complex_val, val, MPC_RNDNN);
+  mpc_set_fr_fr(this->u_.complex_val, real, imag, MPC_RNDNN);
+
+  mpfr_clear(real);
+  mpfr_clear(imag);
+}
+
+// Return whether VAL, at a precision of BITS, is zero.  BITS may be
+// zero in which case it is ignored.
+
+bool
+Numeric_constant::is_float_zero(const mpfr_t val, int bits)
+{
+  if (mpfr_zero_p(val))
+return true;
+  switch (bits)
+{
+case 0:
+  return false;
+case 32:
+  return mpfr_get_flt(val, GMP_RNDN) == 0;
+case 64:
+  return mpfr_get_d(val, GMP_RNDN) == 0;
+default:
+  go_unreachable();
+}
 }
 
 // Get an int value.
Index: gcc/go/gofrontend/expressions.h
===
--- gcc/go/gofrontend/expressions.h (revision 257379)
+++ gcc/go/gofrontend/expressions.h (working copy)
@@ -4220,6 +4220,9 @@ class Numeric_constant
   bool
   check_complex_type(Complex_type*, bool, Location);
 
+  static bool
+  is_float_zero(const mpfr_t, int bits);
+
   // The kinds of constants.
   enum Classification
   {

RFA: PR 84154: Fix checking -mibt and -mshstk options for control flow protection

[Nick Clifton]

Hi H.J.

  Attached is a potential patch for PR 84145:
  
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84145

  The problem was that the code to check that the --mibt and/or -mshstk
  options have been correctly enabled for control flow protection did
  not take into account that the wrong option might have been enabled.

  So the patch inverts the test, looking at the value of
  flag_cf_protection first and then checking to see if the needed x86
  specific options have been enabled.  This gives results like this:


   % gcc -c main.c
   % gcc -c main.c -fcf-protection=full
cc1: error: '-fcf-protection=full' requires CET support on this target. Use 
-mcet or both of -mibt and -mshstk options to enable CET
   % gcc -c main.c -fcf-protection=full -mcet
   % gcc -c main.c -fcf-protection=full -mibt
cc1: error: '-fcf-protection=full' requires CET support on this target. Use 
-mcet or both of -mibt and -mshstk options to enable CET
   % gcc -c main.c -fcf-protection=full -mibt -mshstk
   % gcc -c main.c -fcf-protection=branch
cc1: error: '-fcf-protection=branch' requires CET support on this target. Use 
-mcet or -mibt to enable CET
   % gcc -c main.c -fcf-protection=branch -mcet
   % gcc -c main.c -fcf-protection=branch -mibt
   % gcc -c main.c -fcf-protection=branch -mshstk
cc1: error: '-fcf-protection=branch' requires CET support on this target. Use 
-mcet or -mibt to enable CET
   % gcc -c main.c -fcf-protection=return
cc1: error: '-fcf-protection=return' requires CET support on this target. Use 
-mcet or -mshstk to enable CET
   % gcc -c main.c -fcf-protection=return -mcet
   % gcc -c main.c -fcf-protection=return -mibt
cc1: error: '-fcf-protection=return' requires CET support on this target. Use 
-mcet or -mshstk to enable CET
   % gcc -c main.c -fcf-protection=return -mshstk
   %
   
  What do you think ?  Is the patch OK for the mainline ?

Cheers
  Nick

gcc/ChangeLog
2018-02-05  Nick Clifton  

PR 84145
* config/i386/i386.c (ix86_option_override_internal): Rework
checks for -fcf-protection and -mibt/-mshstk.

Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 257389)
+++ gcc/config/i386/i386.c  (working copy)
@@ -4915,30 +4915,43 @@
   /* Do not support control flow instrumentation if CET is not enabled.  */
   if (opts->x_flag_cf_protection != CF_NONE)
 {
-  if (!(TARGET_IBT_P (opts->x_ix86_isa_flags2)
-   || TARGET_SHSTK_P (opts->x_ix86_isa_flags)))
+  switch (flag_cf_protection)
{
- if (flag_cf_protection == CF_FULL)
+   case CF_NONE:
+ break;
+   case CF_BRANCH:
+ if (! TARGET_IBT_P (opts->x_ix86_isa_flags2))
{
- error ("%<-fcf-protection=full%> requires CET support "
-"on this target. Use -mcet or one of -mibt, "
-"-mshstk options to enable CET");
+ error ("%<-fcf-protection=branch%> requires CET support "
+"on this target. Use -mcet or -mibt to enable CET");
+ flag_cf_protection = CF_NONE;
+ return false;
}
- else if (flag_cf_protection == CF_BRANCH)
+ break;
+   case CF_RETURN:
+ if (! TARGET_SHSTK_P (opts->x_ix86_isa_flags))
{
- error ("%<-fcf-protection=branch%> requires CET support "
-"on this target. Use -mcet or one of -mibt, "
-"-mshstk options to enable CET");
+ error ("%<-fcf-protection=return%> requires CET support "
+"on this target. Use -mcet or -mshstk to enable CET");
+ flag_cf_protection = CF_NONE;
+ return false;
}
- else if (flag_cf_protection == CF_RETURN)
+ break;
+   case CF_FULL:
+ if (   ! TARGET_IBT_P (opts->x_ix86_isa_flags2)
+|| ! TARGET_SHSTK_P (opts->x_ix86_isa_flags))
{
- error ("%<-fcf-protection=return%> requires CET support "
-"on this target. Use -mcet or one of -mibt, "
+ error ("%<-fcf-protection=full%> requires CET support "
+"on this target. Use -mcet or both of -mibt and "
 "-mshstk options to enable CET");
+ flag_cf_protection = CF_NONE;
+ return false;
}
- flag_cf_protection = CF_NONE;
- return false;
+ break;
+   default:
+ gcc_unreachable ();
}
+
   opts->x_flag_cf_protection =
(cf_protection_level) (opts->x_flag_cf_protection | CF_SET);
 }

Do not lose track of resolution info due to tree merging

[Jan Hubicka]

Hi,
in the testcase of PR81004 we produce wrong code (reference to optimized out
comdat symbol) due to strange sequence of events that is initiated by fact
that after streaming in a comdat group we sed one of resolution infos to
LDPR_UNKNOWN.

This is because of tree merging with earlier unit that streams the symbol for
debug info but does not use it and thus there is no symtab entry.

Currently resolutions are streamed in a funny way - they are indexed by decls
and passed through plugin to be read back as array and later attached into hash
to tree nodes to be later written into symtab node (where they belong).
This is quite crazy design but I do not see how to easy clean it up, so this
fixes the problem and I will add cleanup to my todo for next stage1.

patch also adds sanity checking so we error out on missing relocation info.
I have checked this works with non-plugin path.
I did not add testcase because it is very fragile (depends on what we stream)
and it already does not reproduce on mainline without Jakub's patch to clear
abstract origins in free_lang_data reverted.

Bootstrapped/regtested x86_64-linux, ltobootstrap in progress (passing stage2)
OK?

Honza
PR lto/81004
* lto.c (register_resolution): Merge resolutions in case trees was
merged across units.
(lto_maybe_register_decl): Break out from ...
(lto_read_decls): ... here.
(unify_scc): Also register decls here.
(read_cgraph_and_symbols): Sanity check that all resolutions was
read.
* symtab.c (symtab_node::verify_base): Verify that externaly visible
symbol has PUBLIC decl.
Index: lto/lto.c
===
--- lto/lto.c   (revision 257382)
+++ lto/lto.c   (working copy)
@@ -830,12 +830,20 @@ static void
 register_resolution (struct lto_file_decl_data *file_data, tree decl,
 enum ld_plugin_symbol_resolution resolution)
 {
+  bool existed;
   if (resolution == LDPR_UNKNOWN)
 return;
   if (!file_data->resolution_map)
 file_data->resolution_map
   = new hash_map;
-  file_data->resolution_map->put (decl, resolution);
+  ld_plugin_symbol_resolution_t 
+ = file_data->resolution_map->get_or_insert (decl, );
+  gcc_assert (!existed || res == resolution);
+  if (!existed
+  || resolution == LDPR_PREVAILING_DEF_IRONLY
+  || resolution == LDPR_PREVAILING_DEF
+  || resolution == LDPR_PREVAILING_DEF_IRONLY_EXP)
+res = resolution;
 }
 
 /* Register DECL with the global symbol table and change its
@@ -878,6 +886,18 @@ lto_register_function_decl_in_symtab (st
 decl, get_resolution (data_in, ix));
 }
 
+/* Check if T is a decl and needs register its resolution info.  */
+
+static void
+lto_maybe_register_decl (struct data_in *data_in, tree t, unsigned ix)
+{
+  if (TREE_CODE (t) == VAR_DECL)
+lto_register_var_decl_in_symtab (data_in, t, ix);
+  else if (TREE_CODE (t) == FUNCTION_DECL
+  && !DECL_BUILT_IN (t))
+lto_register_function_decl_in_symtab (data_in, t, ix);
+}
+
 
 /* For the type T re-materialize it in the type variant list and
the pointer/reference-to chains.  */
@@ -1617,7 +1637,11 @@ unify_scc (struct data_in *data_in, unsi
  /* Fixup the streamer cache with the prevailing nodes according
 to the tree node mapping computed by compare_tree_sccs.  */
  if (len == 1)
-   streamer_tree_cache_replace_tree (cache, pscc->entries[0], from);
+   {
+ if (!flag_ltrans)
+   lto_maybe_register_decl (data_in, pscc->entries[0], from);
+  streamer_tree_cache_replace_tree (cache, pscc->entries[0], from);
+   }
  else
{
  tree *map2 = XALLOCAVEC (tree, 2 * len);
@@ -1625,6 +1649,8 @@ unify_scc (struct data_in *data_in, unsi
{
  map2[i*2] = (tree)(uintptr_t)(from + i);
  map2[i*2+1] = scc->entries[i];
+ if (!flag_ltrans)
+   lto_maybe_register_decl (data_in, scc->entries[i], from + 
i);
}
  qsort (map2, len, 2 * sizeof (tree), cmp_tree);
  qsort (map, len, 2 * sizeof (tree), cmp_tree);
@@ -1761,13 +1787,7 @@ lto_read_decls (struct lto_file_decl_dat
cache_integer_cst (t);
  if (!flag_ltrans)
{
- /* Register variables and functions with the
-symbol table.  */
- if (TREE_CODE (t) == VAR_DECL)
-   lto_register_var_decl_in_symtab (data_in, t, from + i);
- else if (TREE_CODE (t) == FUNCTION_DECL
-  && !DECL_BUILT_IN (t))
-   lto_register_function_decl_in_symtab (data_in, t, from + i);
+ lto_maybe_register_decl (data_in, t, from + i);
  /* Scan the tree for references to global functions 

Re: [PATCH][i386] Fix ix86_loop_unroll_adjust

[Jan Hubicka]

Dne 2018-02-05 09:53, Richard Biener napsal:

The following fixes an oversight(?) in ix86_loop_unroll_adjust which
will happily bump unrolling to unreasonable amounts for bdverN.

Bootstrap / regtest running on x86_64-unknown-linux-gnu, ok?


OK,
thanks!

Honza

Re: [PATCH] Fix PR83008

[Christophe Lyon]

On 31 January 2018 at 16:01, Richard Biener  wrote:

> On Wed, 31 Jan 2018, Christophe Lyon wrote:
>
> > On 30 January 2018 at 11:47, Jakub Jelinek  wrote:
> > > On Tue, Jan 30, 2018 at 11:07:50AM +0100, Richard Biener wrote:
> > >>
> > >> I have been asked to push this change, fixing (somewhat) the
> impreciseness
> > >> of costing constant/invariant vector uses in SLP stmts.  The previous
> > >> code always just considered a single constant to be generated in the
> > >> prologue irrespective of how many we'd need.  With this patch we
> > >> properly handle this count and optimize for the case when we can use
> > >> a vector splat.  It doesn't yet handle CSE (or CSE among stmts) which
> > >> means it could in theory regress cases it overall costed correctly
> > >> before "optimistically" (aka by accident).  But at least the costing
> > >> now matches code generation.
> > >>
> > >> Bootstrapped and tested on x86_64-unknown-linux-gnu.  On x86_64
> > >> Haswell with AVX2 SPEC 2k6 shows no off-noise changes.
> > >>
> > >> The patch is said to help the case in the PR when additional backend
> > >> costing changes are done (for AVX512).
> > >>
> > >> Ok for trunk at this stage?
> > >
> > > LGTM.
> > >
> > >> 2018-01-30  Richard Biener  
> > >>
> > >>   PR tree-optimization/83008
> > >>   * tree-vect-slp.c (vect_analyze_slp_cost_1): Properly cost
> > >>   invariant and constant vector uses in stmts when they need
> > >>   more than one stmt.
> > >
> > > Jakub
> >
> > Hi Richard,
> >
> > This patch caused a regression on aarch64*:
> > FAIL: gcc.dg/cse_recip.c scan-tree-dump-times optimized "rdiv_expr" 1
> > (found 2 times)
> > we used to have:
> > PASS: gcc.dg/cse_recip.c scan-tree-dump-times optimized "rdiv_expr" 1
>
> We now vectorize this on aarch64 - looks like there's a V2SFmode
> available.  This means we get 1/x computed and divide by {x, x}.
> The former is non-optimal because we leave dead code around after
> SLP vectorization which the multi-use check of the recip pass
> trips on to make this transform profitable.
>
> That's worth a bugreport I think.
>
OK, I filed
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84214


> For the testcase I'd simply adjust it to pass -fno-slp-vectorize
>
I'll do that.

Thanks,

Christophe


> -- or make sure to run the recip pass before vectorization.  Not
> sure why it runs before loop optimizations?
>
> Index: gcc/passes.def
> ===
> --- gcc/passes.def  (revision 257233)
> +++ gcc/passes.def  (working copy)
> @@ -263,6 +263,7 @@ along with GCC; see the file COPYING3.
>NEXT_PASS (pass_asan);
>NEXT_PASS (pass_tsan);
>NEXT_PASS (pass_dce);
> +  NEXT_PASS (pass_cse_reciprocals);
>/* Pass group that runs when 1) enabled, 2) there are loops
>  in the function.  Make sure to run pass_fix_loops before
>  to discover/remove loops before running the gate function
> @@ -317,7 +318,6 @@ along with GCC; see the file COPYING3.
>POP_INSERT_PASSES ()
>NEXT_PASS (pass_simduid_cleanup);
>NEXT_PASS (pass_lower_vector_ssa);
> -  NEXT_PASS (pass_cse_reciprocals);
>NEXT_PASS (pass_sprintf_length, true);
>NEXT_PASS (pass_reassoc, false /* insert_powi_p */);
>NEXT_PASS (pass_strength_reduction);
>
> puts it right before loop opts and after a DCE pass.  This results
> in us no longer vectorizing the code:
>
>   Vector inside of basic block cost: 4
>   Vector prologue cost: 4
>   Vector epilogue cost: 0
>   Scalar cost of basic block: 6
> /space/rguenther/src/svn/early-lto-debug/gcc/testsuite/
> gcc.dg/cse_recip.c:10:1:
> note: not vectorized: vectorization is not profitable.
>
> Not sure if we want to shuffle passes at this stage though.
>
> Richard.
>

Re: [PATCH] PowerPC PR target/84154, fix floating point to small integer conversion regression

[Segher Boessenkool]

On Mon, Feb 05, 2018 at 07:54:58AM -0500, Michael Meissner wrote:
> On Mon, Feb 05, 2018 at 05:57:25AM -0600, Segher Boessenkool wrote:
> > On Thu, Feb 01, 2018 at 02:31:17PM -0500, Michael Meissner wrote:
> > > This patch fixes the optimization regression that occurred on GCC 7 where
> > > conversions from the various floating point types to small integers would 
> > > at
> > > times generate a store and a load.
> > 
> > [ snip big explanation; thanks for that! ]
> > 
> > Could you merge the signed and unsigned patterns, using any_fix?  Or is
> > there a reason that cannot work (other than that  unsigned_fix seems
> > buggy, it should say "u")?
> 
> Well that's the way the instructions are.  For traditional FPR instructions we
> have FCTIWZ vs. FCTIWUZ, while on the VSX side we have XSCVDPSXWS
> vs. XSCVDPUXWS.  If you mean the name of the insn, I can change it if desired,
> but originally it was based on the FPR insn name.

We have

(define_code_attr su [(sign_extend  "s")
  (zero_extend  "u")
  (fix  "s")
  (unsigned_fix "s")
  (float"s")
  (unsigned_float   "u")])

and "s" for unsigned_fix seems like it should be "u".  Very surprising
otherwise (if this is needed in some case, it should just write "s" there
instead of "").

> > Okay for trunk even without that (but please try).  Also okay for 7 after
> > looking for fallout.
> 
> In the past, I have found that combining code iterators with two mode 
> iterators
> has a bug where it would use the wrong code iterator, so I just avoided doing
> that.  I'll see if it is still a bug.

Hrm.  If you have multiple iterators you often need to use ":" syntax,
and you might want that anyway because the precedence rules are non-obvious;
but you are hitting something else?  Please open a PR if so :-)


Segher

Re: C++ PATCH to fix rejects-valid with constexpr ctor in C++17 (PR c++/83692)

[Marek Polacek]

On Fri, Feb 02, 2018 at 02:11:27PM -0500, Jason Merrill wrote:
> On Thu, Jan 25, 2018 at 4:16 PM, Marek Polacek  wrote:
> > This is a similar problem to 83116: we'd cached a constexpr call, but after 
> > a
> > store the result had become invalid, yet we used the wrong result again when
> > encountering the same call later.  This resulted in evaluating a THROW_EXPR
> > which doesn't work.  Details in
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83692#c5
> >
> > The fix for 83116 didn't work here, because when evaluating the body of the
> > ctor via store_init_value -> cxx_constant_value we are in STRICT, so we do
> > cache.
> 
> > It seems that we may no longer rely on the constexpr call table when we
> > do cxx_eval_store_expression, because that just rewrites *valp, i.e. the
> > value of an object.  Might be too big a hammer again, but I couldn't think
> > of how I could guard the caching of a constexpr call.
> 
> > This doesn't manifest in C++14 because build_special_member_call in C++17 is
> > more aggressive with copy elisions (as required by P0135 which changed how 
> > we
> > view prvalues).  In C++14 build_special_member_call produces a CALL_EXPR, so
> > expand_default_init calls maybe_constant_init, for which STRICT is false, so
> > we avoid caching as per 83116.
> 
> So it sounds like the problem is using cxx_constant_value for the
> diagnostic when it has different semantics from the
> maybe_constant_init that follows right after.  I guess we want a
> cxx_constant_init function that is a hybrid of the two.

So like the following?  Thanks,

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

2018-02-04  Marek Polacek  

PR c++/83692
* constexpr.c (cxx_constant_init): New function.
* cp-tree.h (cxx_constant_init): Declare.
* typeck2.c (store_init_value): Call cxx_constant_init instead of
cxx_constant_value.

* g++.dg/cpp1z/constexpr-83692.C: New test.

diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index 93dd8ae049c..f95aacf2580 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -4902,6 +4902,14 @@ cxx_constant_value (tree t, tree decl)
   return cxx_eval_outermost_constant_expr (t, false, true, decl);
 }
 
+/* Like cxx_constant_value, but non-strict mode.  */
+
+tree
+cxx_constant_init (tree t, tree decl)
+{
+  return cxx_eval_outermost_constant_expr (t, false, false, decl);
+}
+
 /* Helper routine for fold_simple function.  Either return simplified
expression T, otherwise NULL_TREE.
In contrast to cp_fully_fold, and to maybe_constant_value, we try to fold
diff --git gcc/cp/cp-tree.h gcc/cp/cp-tree.h
index a53f4fd9c03..9f973305fbb 100644
--- gcc/cp/cp-tree.h
+++ gcc/cp/cp-tree.h
@@ -7417,6 +7417,7 @@ extern bool require_potential_constant_expression (tree);
 extern bool require_constant_expression (tree);
 extern bool require_potential_rvalue_constant_expression (tree);
 extern tree cxx_constant_value (tree, tree = NULL_TREE);
+extern tree cxx_constant_init  (tree, tree = NULL_TREE);
 extern tree maybe_constant_value   (tree, tree = NULL_TREE);
 extern tree maybe_constant_init(tree, tree = 
NULL_TREE);
 extern tree fold_non_dependent_expr(tree);
diff --git gcc/cp/typeck2.c gcc/cp/typeck2.c
index 899d60e8535..b4abc54f537 100644
--- gcc/cp/typeck2.c
+++ gcc/cp/typeck2.c
@@ -830,7 +830,7 @@ store_init_value (tree decl, tree init, vec** 
cleanups, int flags)
  if (!require_constant_expression (value))
value = error_mark_node;
  else
-   value = cxx_constant_value (value, decl);
+   value = cxx_constant_init (value, decl);
}
   value = maybe_constant_init (value, decl);
   if (TREE_CODE (value) == CONSTRUCTOR && cp_has_mutable_p (type))
diff --git gcc/testsuite/g++.dg/cpp1z/constexpr-83692.C 
gcc/testsuite/g++.dg/cpp1z/constexpr-83692.C
index e69de29bb2d..f6b61eeab85 100644
--- gcc/testsuite/g++.dg/cpp1z/constexpr-83692.C
+++ gcc/testsuite/g++.dg/cpp1z/constexpr-83692.C
@@ -0,0 +1,21 @@
+// PR c++/83692
+// { dg-options -std=c++17 }
+
+struct integer {
+  constexpr int value() const { return m_value;}
+  int m_value;
+};
+
+struct outer {
+  integer m_x{0};
+  constexpr outer()
+{
+  if (m_x.value() != 0)
+   throw 0;
+  m_x.m_value = integer{1}.value();
+  if (m_x.value() != 1)
+   throw 0;
+}
+};
+
+constexpr outer o{};

Marek

Re: [PATCH] PowerPC PR target/84154, fix floating point to small integer conversion regression

[Michael Meissner]

On Mon, Feb 05, 2018 at 05:57:25AM -0600, Segher Boessenkool wrote:
> On Thu, Feb 01, 2018 at 02:31:17PM -0500, Michael Meissner wrote:
> > This patch fixes the optimization regression that occurred on GCC 7 where
> > conversions from the various floating point types to small integers would at
> > times generate a store and a load.
> 
> [ snip big explanation; thanks for that! ]
> 
> Could you merge the signed and unsigned patterns, using any_fix?  Or is
> there a reason that cannot work (other than that  unsigned_fix seems
> buggy, it should say "u")?

Well that's the way the instructions are.  For traditional FPR instructions we
have FCTIWZ vs. FCTIWUZ, while on the VSX side we have XSCVDPSXWS
vs. XSCVDPUXWS.  If you mean the name of the insn, I can change it if desired,
but originally it was based on the FPR insn name.

> Okay for trunk even without that (but please try).  Also okay for 7 after
> looking for fallout.

In the past, I have found that combining code iterators with two mode iterators
has a bug where it would use the wrong code iterator, so I just avoided doing
that.  I'll see if it is still a bug.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

[patch][i386] Adding pconfig, wbnoinvd and wbinvd intrinsics

[Makhotina, Olga]

Hi,

This patch adds new intrinsics: pconfig, wbnoinvd and wbinvd.

05.02.2018  Olga Makhotina  

gcc/
* common/config/i386/i386-common.c (OPTION_MASK_ISA_PCONFIG_SET,
OPTION_MASK_ISA_PCONFIG_UNSET, OPTION_MASK_ISA_WBNOINVD_SET,
OPTION_MASK_ISA_WBNOINVD_UNSET): New definitions.
(ix86_handle_option): Handle -mpconfig and -mwbnoinvd.
* config.gcc (pconfigintrin.h, wbnoinvdintrin.h) : Add headers.
* config/i386/cpuid.h (bit_PCONFIG, bit_WBNOINVD): New.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect -mpconfig
and -mwbnoinvd.
* config/i386/i386-builtin.def (__builtin_ia32_wbnoinvd,
__builtin_ia32_wbinvd): New builtins.
(SPECIAL_ARGS2): New.
* config/i386/i386-c.c (__WBNOINVD__, __PCONFIG__): New.
(SPECIAL_ARGS2): New.
* config/i386/i386.c (ix86_target_string): Add -mpconfig and -mwbnoinvd.
(ix86_valid_target_attribute_inner_p): Ditto.
(ix86_init_mmx_sse_builtins): Add special_args2.
* config/i386/i386.h (TARGET_PCONFIG, TARGET_PCONFIG_P, TARGET_WBNOINVD,
TARGET_WBNOINVD_P): New.
* config/i386/i386.md (UNSPECV_WBINVD, UNSPECV_WBNOINVD): New.
(define_insn "wbinvd", define_insn "wbnoinvd"): New.
* config/i386/i386.opt: Add -mpconfig and -mwbnoinvd.
* config/i386/immintrin.h (_wbinvd): New intrinsic.
* config/i386/sgxintrin.h (_enclv_u32): Ditto.
* config/i386/pconfigintrin.h: New file.
* config/i386/wbnoinvdintrin.h: Ditto.
* config/i386/x86intrin.h: Add headers pconfigintrin.h and 
wbnoinvdintrin.h.
* doc/invoke.texi (-mpconfig, -mwbnoinvd): New.

gcc/testsuite/
* g++.dg/other/i386-2.C: Add -mpconfig and -mwbnoinvd.
* g++.dg/other/i386-3.C: Ditto.
* gcc.target/i386/sse-12.c: Ditto.
* gcc.target/i386/sse-13.c: Ditto.
* gcc.target/i386/sse-14.c: Ditto.
* gcc.target/i386/sgx.c (_enclv_u32): New tests.
* gcc.target/i386/sse-23.c: Add pconfig and wbnoinvd.
* gcc.target/i386/wbinvd-1.c: New test.
* gcc.target/i386/wbnoinvd-1.c: Ditto.
* gcc.target/i386/pconfig-1.c: Ditto.

Is it ok for trunk?

Thanks,
Olga.



0001-patch.patch
Description: 0001-patch.patch

Re: [patch, libfortran] Use flexible array members for array descriptor

[Janne Blomqvist]

On Sun, Feb 4, 2018 at 9:49 PM, Thomas Koenig  wrote:
> Hello world,
>
> in the attached patch, I have used flexible array members for
> using the different descriptor types (following Richi's advice).
> This does not change the binary ABI, but the library code
> maches what we are actually doing in the front end.  I have
> not yet given up hope of enabling LTO for the library :-)
> and this, I think, will be a prerequisite.
>
> OK for trunk?

Given that Jakub and Richi apparently weren't yet unanimous in their
recommendations on the best path forward, maybe wait a bit for the
smoke to clear?

In the meantime, a few comments:

1) Is there some particular benefit to all those macroized
descriptors, given that the only thing different is the type of the
base_addr pointer? Wouldn't it be simpler to just have a single
descriptor type with base_addr a void pointer, then typecast that
pointer to whatever type is needed?

2)

Index: intrinsics/date_and_time.c
===
--- intrinsics/date_and_time.c (Revision 257347)
+++ intrinsics/date_and_time.c (Arbeitskopie)
@@ -268,7 +268,7 @@ secnds (GFC_REAL_4 *x)
   GFC_REAL_4 temp1, temp2;

   /* Make the INTEGER*4 array for passing to date_and_time.  */
-  gfc_array_i4 *avalues = xmalloc (sizeof (gfc_array_i4));
+  gfc_array_i4 *avalues = xmalloc (sizeof (gfc_full_array_i4));


Since date_and_time requires the values array to always be rank 1,
can't this be "xmalloc (sizeof (gfc_array_i4) +
sizeof(dimension_data))" ?

(The GFC_FULL_DESCRIPTOR stuff is useful for stack allocated
descriptors to avoid VLA's / alloca(), but for heap allocated ones we
can allocate only the needed size, I think)


3)

Index: io/format.c
===
--- io/format.c (Revision 257347)
+++ io/format.c (Arbeitskopie)
@@ -1025,7 +1025,7 @@ parse_format_list (st_parameter_dt *dtp, bool *see
   t = format_lex (fmt);

   /* Initialize the vlist to a zero size array.  */
-  tail->u.udf.vlist= xmalloc (sizeof(gfc_array_i4));
+  tail->u.udf.vlist= xmalloc (sizeof(gfc_full_array_i4));
   GFC_DESCRIPTOR_DATA(tail->u.udf.vlist) = NULL;
   GFC_DIMENSION_SET(tail->u.udf.vlist->dim[0],1, 0, 0);


And same here?



-- 
Janne Blomqvist

Re: [PATCH] PowerPC PR target/84154, fix floating point to small integer conversion regression

[Segher Boessenkool]

On Thu, Feb 01, 2018 at 02:31:17PM -0500, Michael Meissner wrote:
> This patch fixes the optimization regression that occurred on GCC 7 where
> conversions from the various floating point types to small integers would at
> times generate a store and a load.

[ snip big explanation; thanks for that! ]

Could you merge the signed and unsigned patterns, using any_fix?  Or is
there a reason that cannot work (other than that  unsigned_fix seems
buggy, it should say "u")?

Okay for trunk even without that (but please try).  Also okay for 7 after
looking for fallout.

Thanks!


Segher

[PATCH][GCC][ARM] Silence ARM_ARCH redefinition warning and keep better track of architecturs already emitted.

[Tamar Christina]

Hi All,

This patch silences the warnings that were emitted when certain ACLE macros 
were being redefined
when using the new target pragma or attribute to change architecture level.

It also keeps better track of which arch directives have already been emitted. 
This allows special
cases that existed before to keep working as they did before.

Regtested on arm-none-eabi and no regressions.
Bootstrapped and regtested on arm-none-Linux-gnueabihf and no issues.

Ok for trunk and backport to the GCC-8 branch?

Thanks,
Tamar


gcc/
2018-02-05  Tamar Christina  

PR target/82641
* config/arm/arm.c (arm_print_asm_arch_directives): Record already
emitted arch directives.
* config/arm/arm-c.c (arm_cpu_builtins): Undefine __ARM_ARCH and
__ARM_FEATURE_COPROC before changing architectures.

gcc/testsuite
2018-02-05  Tamar Christina  

PR target/82641
* gcc.target/arm/pragma_arch_switch_2.c: New.

-- 
diff --git a/gcc/config/arm/arm-c.c b/gcc/config/arm/arm-c.c
index 486cbd132974aba6ac12fa221ed7322d8d54039d..9a16172f1d8af1a2fb3f24b758650e16ff6e810a 100644
--- a/gcc/config/arm/arm-c.c
+++ b/gcc/config/arm/arm-c.c
@@ -113,7 +113,10 @@ arm_cpu_builtins (struct cpp_reader* pfile)
  consistency with armcc.  */
   builtin_define ("__arm__");
   if (TARGET_ARM_ARCH)
-builtin_define_with_int_value ("__ARM_ARCH", TARGET_ARM_ARCH);
+{
+  cpp_undef (pfile, "__ARM_ARCH");
+  builtin_define_with_int_value ("__ARM_ARCH", TARGET_ARM_ARCH);
+}
   if (arm_arch_notm)
 builtin_define ("__ARM_ARCH_ISA_ARM");
   builtin_define ("__APCS_32__");
@@ -204,6 +207,7 @@ arm_cpu_builtins (struct cpp_reader* pfile)
 
   def_or_undef_macro (pfile, "__ARM_ASM_SYNTAX_UNIFIED__", inline_asm_unified);
 
+  cpp_undef (pfile, "__ARM_FEATURE_COPROC");
   if (TARGET_32BIT && arm_arch4 && !(arm_arch8 && arm_arch_notm))
 {
   int coproc_level = 0x1;
@@ -217,8 +221,6 @@ arm_cpu_builtins (struct cpp_reader* pfile)
 
   builtin_define_with_int_value ("__ARM_FEATURE_COPROC", coproc_level);
 }
-  else
-  cpp_undef (pfile, "__ARM_FEATURE_COPROC");
 }
 
 void
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 978c44af327b6769c16120ca08300e41d033..17feba46619c2ff729ec81520b516fb616ffcb11 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -78,6 +78,10 @@
 typedef struct minipool_nodeMnode;
 typedef struct minipool_fixup   Mfix;
 
+/* The last .arch and .fpu assembly strings that we printed.  */
+static std::string arm_last_printed_arch_string;
+static std::string arm_last_printed_fpu_string;
+
 void (*arm_lang_output_object_attributes_hook)(void);
 
 struct four_ints
@@ -26390,6 +26394,7 @@ arm_print_asm_arch_directives ()
   gcc_assert (arch);
 
   asm_fprintf (asm_out_file, "\t.arch %s\n", arm_active_target.arch_name);
+  arm_last_printed_arch_string = arm_active_target.arch_name;
   if (!arch->common.extensions)
 return;
 
@@ -26437,13 +26442,17 @@ arm_file_start (void)
 	  asm_fprintf (asm_out_file, "\t.arch_extension idiv\n");
 	  asm_fprintf (asm_out_file, "\t.arch_extension sec\n");
 	  asm_fprintf (asm_out_file, "\t.arch_extension mp\n");
+	  arm_last_printed_arch_string = "armv7ve";
 	}
 	  else
 	arm_print_asm_arch_directives ();
 	}
   else if (strncmp (arm_active_target.core_name, "generic", 7) == 0)
-	asm_fprintf (asm_out_file, "\t.arch %s\n",
-		 arm_active_target.core_name + 8);
+	{
+	  asm_fprintf (asm_out_file, "\t.arch %s\n",
+		   arm_active_target.core_name + 8);
+	  arm_last_printed_arch_string = arm_active_target.core_name + 8;
+	}
   else
 	{
 	  const char* truncated_name
@@ -30934,10 +30943,6 @@ arm_identify_fpu_from_isa (sbitmap isa)
   gcc_unreachable ();
 }
 
-/* The last .arch and .fpu assembly strings that we printed.  */
-static std::string arm_last_printed_arch_string;
-static std::string arm_last_printed_fpu_string;
-
 /* Implement ASM_DECLARE_FUNCTION_NAME.  Output the ISA features used
by the function fndecl.  */
 void
diff --git a/gcc/testsuite/gcc.target/arm/pragma_arch_switch_2.c b/gcc/testsuite/gcc.target/arm/pragma_arch_switch_2.c
new file mode 100644
index ..fe52191c32c037fe4096c1884e1f6397318bd6a3
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/pragma_arch_switch_2.c
@@ -0,0 +1,17 @@
+/* Test for switching architectures during compilation.  */
+/* { dg-skip-if "instruction not valid on thumb" { *-*-* } { "-mthumb" } { "" } } */
+/* { dg-do assemble } */
+/* { dg-require-effective-target arm_arm_ok } */
+/* { dg-additional-options "-Wall -O2 -march=armv4t -std=gnu99 -marm" } */
+
+#pragma GCC target ("arch=armv5te")
+void cpu_has_iwmmxt (void)
+{
+   int lo;
+   int hi;
+   __asm__ __volatile__ (
+  "mcrr   p0, 0, %2, %3, c0\n"
+  : "=r" (lo), "=r" (hi)
+  : "r" (0), "r" (0x100));
+}
+

[PATCH] Cherry-pick libsanitizer pointer-pair tristate option.

[Martin Liška]

Hi.

This is upstream backport of libsanitizer which makes 
detect-invalid-pointer-pair
a tristate option.

Patch is preapproved by Jakub.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.

Martin

gcc/ChangeLog:

2018-02-05  Martin Liska  

* doc/invoke.texi: Cherry-pick upstream r323995.

gcc/testsuite/ChangeLog:

2018-02-05  Martin Liska  

* c-c++-common/asan/pointer-compare-1.c: Adjust ASAN_OPTIONS
options.
* c-c++-common/asan/pointer-compare-2.c: Likewise.
* c-c++-common/asan/pointer-subtract-1.c: Likewise.
* c-c++-common/asan/pointer-subtract-2.c: Likewise.
* c-c++-common/asan/pointer-subtract-3.c: Likewise.
* c-c++-common/asan/pointer-subtract-4.c: Likewise.
* c-c++-common/asan/pointer-compare-3.c: New test.

libsanitizer/ChangeLog:

2018-02-05  Martin Liska  

* asan/asan_flags.inc: Cherry-pick upstream r323995.
* asan/asan_report.cc (CheckForInvalidPointerPair):
Cherry-pick upstream r323995.
---
 gcc/doc/invoke.texi| 10 +++---
 .../c-c++-common/asan/pointer-compare-1.c  |  2 +-
 .../c-c++-common/asan/pointer-compare-2.c  |  2 +-
 .../c-c++-common/asan/pointer-compare-3.c  | 39 ++
 .../c-c++-common/asan/pointer-subtract-1.c |  2 +-
 .../c-c++-common/asan/pointer-subtract-2.c |  2 +-
 .../c-c++-common/asan/pointer-subtract-3.c |  2 +-
 .../c-c++-common/asan/pointer-subtract-4.c |  2 +-
 libsanitizer/asan/asan_flags.inc   |  6 ++--
 libsanitizer/asan/asan_report.cc   |  6 +++-
 10 files changed, 59 insertions(+), 14 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/asan/pointer-compare-3.c


diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index f3d93367640..cf6d3ae5b99 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -11165,8 +11165,9 @@ The option must be combined with either @option{-fsanitize=kernel-address} or
 The option cannot be combined with @option{-fsanitize=thread}
 and/or @option{-fcheck-pointer-bounds}.
 Note: By default the check is disabled at run time.  To enable it,
-add @code{detect_invalid_pointer_pairs=1} to the environment variable
-@env{ASAN_OPTIONS}.
+add @code{detect_invalid_pointer_pairs=2} to the environment variable
+@env{ASAN_OPTIONS}. Using @code{detect_invalid_pointer_pairs=1} detects
+invalid operation only when both pointers are non-null.
 
 @item -fsanitize=pointer-subtract
 @opindex fsanitize=pointer-subtract
@@ -11176,8 +11177,9 @@ The option must be combined with either @option{-fsanitize=kernel-address} or
 The option cannot be combined with @option{-fsanitize=thread}
 and/or @option{-fcheck-pointer-bounds}.
 Note: By default the check is disabled at run time.  To enable it,
-add @code{detect_invalid_pointer_pairs=1} to the environment variable
-@env{ASAN_OPTIONS}.
+add @code{detect_invalid_pointer_pairs=2} to the environment variable
+@env{ASAN_OPTIONS}. Using @code{detect_invalid_pointer_pairs=1} detects
+invalid operation only when both pointers are non-null.
 
 @item -fsanitize=thread
 @opindex fsanitize=thread
diff --git a/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c b/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c
index 2cc7395241a..cf67fe98bee 100644
--- a/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c
+++ b/gcc/testsuite/c-c++-common/asan/pointer-compare-1.c
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-set-target-env-var ASAN_OPTIONS "detect_invalid_pointer_pairs=1:halt_on_error=0" } */
+/* { dg-set-target-env-var ASAN_OPTIONS "detect_invalid_pointer_pairs=2:halt_on_error=0" } */
 /* { dg-options "-fsanitize=address,pointer-compare" } */
 
 volatile int v;
diff --git a/gcc/testsuite/c-c++-common/asan/pointer-compare-2.c b/gcc/testsuite/c-c++-common/asan/pointer-compare-2.c
index 5539087e856..d2142c8f160 100644
--- a/gcc/testsuite/c-c++-common/asan/pointer-compare-2.c
+++ b/gcc/testsuite/c-c++-common/asan/pointer-compare-2.c
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-set-target-env-var ASAN_OPTIONS "detect_invalid_pointer_pairs=1 halt_on_error=1" } */
+/* { dg-set-target-env-var ASAN_OPTIONS "detect_invalid_pointer_pairs=2 halt_on_error=1" } */
 /* { dg-options "-fsanitize=address,pointer-compare" } */
 
 volatile int v;
diff --git a/gcc/testsuite/c-c++-common/asan/pointer-compare-3.c b/gcc/testsuite/c-c++-common/asan/pointer-compare-3.c
new file mode 100644
index 000..7156e494aeb
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/asan/pointer-compare-3.c
@@ -0,0 +1,39 @@
+/* { dg-do run } */
+/* { dg-set-target-env-var ASAN_OPTIONS "detect_invalid_pointer_pairs=1:halt_on_error=1" } */
+/* { dg-options "-fsanitize=address,pointer-compare" } */
+
+int foo(char *p, char *q) {
+  return p <= q;
+}
+
+char global[8192] = {};
+char small_global[7] = {};
+
+int main() {
+  // Heap allocated memory.
+  

[committed][AArch64] Remove SVE XFAILs

[Richard Sandiford]

These tests started passing after r257293, which had the side-effect
of renumbering the SSA names and leaving the COND_EXPRs in their
natural order.

This does show a deeper underlying issue that code generation is too
sensitive to internal things like SSA_NAME versions, but it no longer
affects these particular tests (for now).

Tested on aarch64-linux-gnu and applied as obvious.

Richard


2018-02-05  Richard Sandiford  

gcc/testsuite/
* gcc.target/aarch64/sve/vcond_4.c: Remove XFAILs.
* gcc.target/aarch64/sve/vcond_5.c: Likewise.

Index: gcc/testsuite/gcc.target/aarch64/sve/vcond_4.c
===
--- gcc/testsuite/gcc.target/aarch64/sve/vcond_4.c  2018-01-13 
17:54:52.936269706 +
+++ gcc/testsuite/gcc.target/aarch64/sve/vcond_4.c  2018-02-05 
10:48:09.591790399 +
@@ -88,12 +88,12 @@ TEST_CMP (nule)
 TEST_CMP (nuge)
 TEST_CMP (nugt)
 
-/* { dg-final { scan-assembler-times {\tfcmeq\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, #0\.0\n} 5 { xfail *-*-* } } } */
-/* { dg-final { scan-assembler-times {\tfcmeq\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, z[0-9]+\.s\n} 10 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times {\tfcmeq\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, #0\.0\n} 5 } } */
+/* { dg-final { scan-assembler-times {\tfcmeq\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, z[0-9]+\.s\n} 10 } } */
 
 /* 5 for ne, 5 for ueq and 5 for nueq.  */
-/* { dg-final { scan-assembler-times {\tfcmne\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, #0\.0\n} 15 { xfail *-*-* } } } */
-/* { dg-final { scan-assembler-times {\tfcmne\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, z[0-9]+\.s\n} 30 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times {\tfcmne\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, #0\.0\n} 15 } } */
+/* { dg-final { scan-assembler-times {\tfcmne\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, z[0-9]+\.s\n} 30 } } */
 
 /* 5 for lt, 5 for ult and 5 for nult.  */
 /* { dg-final { scan-assembler-times {\tfcmlt\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, #0\.0\n} 15 } } */
@@ -115,11 +115,11 @@ TEST_CMP (nugt)
 /* 3 loops * 5 invocations for all 12 unordered comparisons.  */
 /* { dg-final { scan-assembler-times {\tfcmuo\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, z[0-9]+\.s\n} 180 } } */
 
-/* { dg-final { scan-assembler-times {\tfcmeq\tp[0-9]+\.d, p[0-7]/z, 
z[0-9]+\.d, #0\.0\n} 7 { xfail *-*-* } } } */
-/* { dg-final { scan-assembler-times {\tfcmeq\tp[0-9]+\.d, p[0-7]/z, 
z[0-9]+\.d, z[0-9]+\.d\n} 14 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times {\tfcmeq\tp[0-9]+\.d, p[0-7]/z, 
z[0-9]+\.d, #0\.0\n} 7 } } */
+/* { dg-final { scan-assembler-times {\tfcmeq\tp[0-9]+\.d, p[0-7]/z, 
z[0-9]+\.d, z[0-9]+\.d\n} 14 } } */
 
-/* { dg-final { scan-assembler-times {\tfcmne\tp[0-9]+\.d, p[0-7]/z, 
z[0-9]+\.d, #0\.0\n} 21 { xfail *-*-* } } } */
-/* { dg-final { scan-assembler-times {\tfcmne\tp[0-9]+\.d, p[0-7]/z, 
z[0-9]+\.d, z[0-9]+\.d\n} 42 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times {\tfcmne\tp[0-9]+\.d, p[0-7]/z, 
z[0-9]+\.d, #0\.0\n} 21 } } */
+/* { dg-final { scan-assembler-times {\tfcmne\tp[0-9]+\.d, p[0-7]/z, 
z[0-9]+\.d, z[0-9]+\.d\n} 42 } } */
 
 /* { dg-final { scan-assembler-times {\tfcmlt\tp[0-9]+\.d, p[0-7]/z, 
z[0-9]+\.d, #0\.0\n} 21 } } */
 /* { dg-final { scan-assembler-times {\tfcmlt\tp[0-9]+\.d, p[0-7]/z, 
z[0-9]+\.d, z[0-9]+\.d\n} 42 } } */
Index: gcc/testsuite/gcc.target/aarch64/sve/vcond_5.c
===
--- gcc/testsuite/gcc.target/aarch64/sve/vcond_5.c  2018-01-13 
17:54:52.936269706 +
+++ gcc/testsuite/gcc.target/aarch64/sve/vcond_5.c  2018-02-05 
10:48:09.591790399 +
@@ -6,23 +6,23 @@
 #include "vcond_4.c"
 
 /* 5 for eqand 5 for ueq.  */
-/* { dg-final { scan-assembler-times {\tfcmeq\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, #0\.0} 10 { xfail *-*-* } } } */
-/* { dg-final { scan-assembler-times {\tfcmeq\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, z[0-9]+\.s} 20 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times {\tfcmeq\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, #0\.0} 10 } } */
+/* { dg-final { scan-assembler-times {\tfcmeq\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, z[0-9]+\.s} 20 } } */
 
-/* { dg-final { scan-assembler-times {\tfcmne\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, #0\.0} 5 { xfail *-*-* } } } */
-/* { dg-final { scan-assembler-times {\tfcmne\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, z[0-9]+\.s} 10 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times {\tfcmne\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, #0\.0} 5 } } */
+/* { dg-final { scan-assembler-times {\tfcmne\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, z[0-9]+\.s} 10 } } */
 
 /* 5 for lt, 5 for ult, 5 for nueq and 5 for nult.  */
-/* { dg-final { scan-assembler-times {\tfcmlt\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, #0\.0} 20 { xfail *-*-* } } } */
-/* { dg-final { scan-assembler-times {\tfcmlt\tp[0-9]+\.s, p[0-7]/z, 
z[0-9]+\.s, z[0-9]+\.s} 40 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-times 

Re: [Arm] GCC crash in cprop_hardreg when targeting v8-A Thumb

[Kyrill Tkachov]

Hi Michael,

On 04/02/18 02:52, Michael Collison wrote:

This patches fixes a bug affecting two patterns in arm/thumb2.md where the split condition was insufficient 
and allowed illegal rtl to be generated. The split condition for patterns "*thumb2_mov_negscc "and 
"*thumb_mov_notscc " allowed splitting that ignored "arm_restrict_it". This was causing 
illegal rtl to be generated for IT blocks which in turn caused an internal error.

Bootstrapped and regression tested on arm-linux-gnueabihf. Okay for trunk?



Ok.



2018-01-28  Michael Collison 

* config/arm/thumb2.md:
(*thumb2_mov_negscc): Split only if TARGET_THUMB2 && !arm_restrict_it.
(*thumb_mov_notscc): Ditto.
* gcc.target/arm/pr7676.c: New testcase.



Please make sure the testsuite entry goes into the gcc/testsuite/ChangeLog.

Thanks for fixing this, can you please check if this needs fixing on the 
branches too?
Kyrill

[PATCH][OBVIOUS] Fix GCOV documentation (PR gcov-profile/84137).

[Martin Liška]

Hello.

Very simple patch fixes documentation. I'm going to install it to all
active branches.

Martin

gcc/ChangeLog:

2018-02-05  Martin Liska  

PR gcov-profile/84137
* doc/gcov.texi: Fix typo in documentation.
---
 gcc/doc/gcov.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index b55ee852ef9..5af04d6397e 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -369,7 +369,7 @@ program source code.  The format is
 Additional block information may succeed each line, when requested by
 command line option.  The @var{execution_count} is @samp{-} for lines
 containing no code.  Unexecuted lines are marked @samp{#} or
-@samp{}, depending on whether they are reachable by
+@samp{=}, depending on whether they are reachable by
 non-exceptional paths or only exceptional paths such as C++ exception
 handlers, respectively. Given @samp{-a} option, unexecuted blocks are
 marked @samp{$} or @samp{%}, depending on whether a basic block

[PATCH][i386] Fix ix86_loop_unroll_adjust

[Richard Biener]

The following fixes an oversight(?) in ix86_loop_unroll_adjust which
will happily bump unrolling to unreasonable amounts for bdverN.

Bootstrap / regtest running on x86_64-unknown-linux-gnu, ok?

Thanks,
Richard.

2018-02-05  Richard Biener  

* config/i386/i386.c (print_reg): Fix typo.
(ix86_loop_unroll_adjust): Do not unroll beyond the original nunroll.

Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 257382)
+++ gcc/config/i386/i386.c  (working copy)
@@ -17946,7 +17946,7 @@ print_reg (rtx x, int code, FILE *file)
F,f -- likewise, but for floating-point.
O -- if HAVE_AS_IX86_CMOV_SUN_SYNTAX, expand to "w.", "l." or "q.",
otherwise nothing
-   R -- print embeded rounding and sae.
+   R -- print embedded rounding and sae.
r -- print only sae.
z -- print the opcode suffix for the size of the current operand.
Z -- likewise, with special suffixes for x87 instructions.
@@ -50560,7 +50560,7 @@ ix86_loop_unroll_adjust (unsigned nunrol
   free (bbs);
 
   if (mem_count && mem_count <=32)
-return 32/mem_count;
+return MIN (nunroll, 32 / mem_count);
 
   return nunroll;
 }