date:20200412

[committed] Darwin, testsuite: Adjust indirect thunk tests for default flags.

2020-04-12 Thread Iain Sandoe

Hi,

This has been on my TODO for a while, it fixes up a bunch of tests
that changed when the default shifted to no-common.

tested on x86_64-darwin16 / x86-64-linux-gnu
applied to master,
thanks
Iain
  
Darwin mandates an indirection for variables in the commmon
section.  Since the change to -fno-common, variables in some
of the thunk tests are now in the .data section where they
may be accessed directly.  Remove the indirections from the
scan-assembler matches.

gcc/testsuite/ChangeLog:

2020-04-12  Iain Sandoe  

* gcc.target/i386/indirect-thunk-1.c: Adjust for fno-common
change, removing indirections for vars in .data.
* gcc.target/i386/indirect-thunk-2.c: Likewise.
* gcc.target/i386/indirect-thunk-3.c: Likewise.
* gcc.target/i386/indirect-thunk-4.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-1.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-2.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-3.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-4.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-5.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-6.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-1.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-2.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-3.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-4.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-1.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-2.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-3.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-4.c: Likewise.

diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-1.c 
b/gcc/testsuite/gcc.target/i386/indirect-thunk-1.c
index e2914a8333c..77593c97ab9 100644
--- a/gcc/testsuite/gcc.target/i386/indirect-thunk-1.c
+++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-1.c
@@ -14,7 +14,7 @@ male_indirect_jump (long offset)
 
 /* { dg-final { scan-assembler "mov(?:l|q)\[ \t\]*dispatch" { target 
*-*-linux* } } } */
 /* { dg-final { scan-assembler {movq[ \t]*_dispatch} { target { lp64 && 
*-*-darwin* } } } } */
-/* { dg-final { scan-assembler {movl[ 
\t]*[Ll]_dispatch\$non_lazy_ptr-L[0-9]+\$pb} { target { ia32 && *-*-darwin* } } 
} } */
+/* { dg-final { scan-assembler {movl[ \t]*_dispatch-L[0-9]+\$pb} { target { 
ia32 && *-*-darwin* } } } } */
 /* { dg-final { scan-assembler "jmp\[ \t\]*_?__x86_indirect_thunk_(r|e)ax" } } 
*/
 /* { dg-final { scan-assembler {jmp[ \t]*\.?LIND} } } */
 /* { dg-final { scan-assembler {call[ \t]*\.?LIND} } } */
diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-2.c 
b/gcc/testsuite/gcc.target/i386/indirect-thunk-2.c
index d2b7c74b143..91e606b96d2 100644
--- a/gcc/testsuite/gcc.target/i386/indirect-thunk-2.c
+++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-2.c
@@ -13,8 +13,8 @@ male_indirect_jump (long offset)
 }
 
 /* { dg-final { scan-assembler "mov(?:l|q)\[ \t\]*dispatch" { target 
*-*-linux* } } } */
-/* { dg-final { scan-assembler {movq[ \t]*_dispatch} { target { lp64 && 
*-*-darwin* } } } } */
-/* { dg-final { scan-assembler {movl[ 
\t]*[Ll]_dispatch\$non_lazy_ptr-L[0-9]+\$pb} { target { ia32 && *-*-darwin* } } 
} } */
+/* { dg-final { scan-assembler {leaq[ \t]*_dispatch} { target { lp64 && 
*-*-darwin* } } } } */
+/* { dg-final { scan-assembler {movl[ \t]*_dispatch-L[0-9]+\$pb} { target { 
ia32 && *-*-darwin* } } } } */
 /* { dg-final { scan-assembler "jmp\[ \t\]*_?__x86_indirect_thunk_(r|e)ax" } } 
*/
 /* { dg-final { scan-assembler {jmp[ \t]*\.?LIND} } } */
 /* { dg-final { scan-assembler {call[ \t]*\.?LIND} } } */
diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-3.c 
b/gcc/testsuite/gcc.target/i386/indirect-thunk-3.c
index 129fb2125f0..bf6573292db 100644
--- a/gcc/testsuite/gcc.target/i386/indirect-thunk-3.c
+++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-3.c
@@ -15,7 +15,7 @@ male_indirect_jump (long offset)
 
 /* { dg-final { scan-assembler "mov(?:l|q)\[ \t\]*dispatch" { target 
*-*-linux* } } } */
 /* { dg-final { scan-assembler {movq[ \t]*_dispatch} { target { lp64 && 
*-*-darwin* } } } } */
-/* { dg-final { scan-assembler {movl[ 
\t]*[Ll]_dispatch\$non_lazy_ptr-L[0-9]+\$pb} { target { ia32 && *-*-darwin* } } 
} } */
+/* { dg-final { scan-assembler {movl[ \t]*_dispatch-L[0-9]+\$pb} { target { 
ia32 && *-*-darwin* } } } } */
 /* { dg-final { scan-assembler "call\[ \t\]*_?__x86_indirect_thunk_(r|e)ax" } 
} */
 /* { dg-final { scan-assembler {jmp[ \t]*\.?LIND} } } */
 /* { dg-final { scan-assembler {call[ \t]*\.?LIND} } } */
diff --git a/gcc/testsuite/gcc.target/i386/indirect-thunk-4.c 
b/gcc/testsuite/gcc.target/i386/indirect-thunk-4.c
index 01996fb029f..2ece2d7215d 100644
--- a/gcc/testsuite/gcc.target/i386/indirect-thunk-4.c
+++ b/gcc/testsuite/gcc.target/i386/indirect-thunk-4.c
@@ -14,8 +14,8 @@ male_indirect_jump (long offset)
 }
 
 /* { dg-final { scan-assembler "mov(?:l|q)\[ \t\]*dispatch

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

2020-04-12 Thread Patrick Palka via Gcc-patches

On Sat, 11 Apr 2020, Jason Merrill wrote:

> On 4/10/20 5:47 PM, Patrick Palka wrote:
> > On Fri, 10 Apr 2020, Jason Merrill wrote:
> > > On 4/10/20 2:15 PM, Patrick Palka wrote:
> > > > On Fri, 10 Apr 2020, Patrick Palka wrote:
> > > > 
> > > > > On Fri, 10 Apr 2020, Jason Merrill wrote:
> > > > > 
> > > > > > On 4/10/20 1:04 PM, Patrick Palka wrote:
> > > > > > > On Thu, 9 Apr 2020, Patrick Palka wrote:
> > > > > > > > On Thu, 9 Apr 2020, Jason Merrill wrote:
> > > > > > > > 
> > > > > > > > > On 4/8/20 7:49 PM, Patrick Palka wrote:
> > > > > > > > > > When evaluating the initializer of 'a' in the following
> > > > > > > > > > example
> > > > > > > > > > 
> > > > > > > > > >   struct A { A *p = this; };
> > > > > > > > > >   constexpr A foo() { return {}; }
> > > > > > > > > >   constexpr A a = foo();
> > > > > > > > > > 
> > > > > > > > > > the PLACEHOLDER_EXPR for 'this' in the aggregate initializer
> > > > > > > > > > returned
> > > > > > > > > > by foo
> > > > > > > > > > gets resolved to the RESULT_DECL of foo.  But due to
> > > > > > > > > > guaranteed
> > > > > > > > > > RVO,
> > > > > > > > > > the
> > > > > > > > > > 'this'
> > > > > > > > > > should really be resolved to '&a'.
> > > > > > > > > 
> > > > > > > > > > It seems to me that the right approach would be to
> > > > > > > > > > immediately
> > > > > > > > > > resolve
> > > > > > > > > > the
> > > > > > > > > > PLACEHOLDER_EXPR to the correct target object during
> > > > > > > > > > evaluation
> > > > > > > > > > of
> > > > > > > > > > 'foo()',
> > > > > > > > > > so
> > > > > > > > > > that we could use 'this' to access objects adjacent to the
> > > > > > > > > > current
> > > > > > > > > > object in
> > > > > > > > > > the
> > > > > > > > > > ultimate storage location.  (I think #c2 of PR c++/94537 is
> > > > > > > > > > an
> > > > > > > > > > example
> > > > > > > > > > of
> > > > > > > > > > such
> > > > > > > > > > usage of 'this', which currently doesn't work.  But as #c1
> > > > > > > > > > shows
> > > > > > > > > > we
> > > > > > > > > > don't
> > > > > > > > > > seem
> > > > > > > > > > to handle this case correctly in non-constexpr
> > > > > > > > > > initialization
> > > > > > > > > > either.)
> > > > > > > > > 
> > > > > > > > > As I commented in the PR, the standard doesn't require this to
> > > > > > > > > work
> > > > > > > > > because A
> > > > > > > > > is trivially copyable, and our ABI makes it impossible.  But
> > > > > > > > > there's
> > > > > > > > > still a
> > > > > > > > > constexpr bug when we add
> > > > > > > > > 
> > > > > > > > > A() = default; A(const A&);
> > > > > > > > > 
> > > > > > > > > clang doesn't require the constructors to make this work for
> > > > > > > > > constant
> > > > > > > > > initialization, but similarly can't make it work for
> > > > > > > > > non-constant
> > > > > > > > > initialization.
> > > > > > > > 
> > > > > > > > That makes a lot of sense, thanks for the detailed explanation.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > I haven't yet been able to make a solution using the above
> > > > > > > > > > approach
> > > > > > > > > > work --
> > > > > > > > > > making sure we use the ultimate object instead of the
> > > > > > > > > > RESULT_DECL
> > > > > > > > > > whenever
> > > > > > > > > > we
> > > > > > > > > > access ctx->global->values is proving to be tricky and
> > > > > > > > > > subtle.
> > > > > > > > > 
> > > > > > > > > Do we need to go through ctx->global->values?  Would it work
> > > > > > > > > for
> > > > > > > > > the
> > > > > > > > > RESULT_DECL case in cxx_eval_constant_expression to go to
> > > > > > > > > straight
> > > > > > > > > to
> > > > > > > > > ctx->object or ctx->ctor instead?
> > > > > > > > 
> > > > > > > > I attempted that at some point, but IIRC we still end up not
> > > > > > > > resolving
> > > > > > > > some RESULT_DECLs because not all of them get processed through
> > > > > > > > cxx_eval_constant_expression before we manipulate
> > > > > > > > ctx->global->values
> > > > > > > > with them.  I'll try this approach more carefully and report
> > > > > > > > back
> > > > > > > > with
> > > > > > > > more specifics.
> > > > > > > 
> > > > > > > It turns out that immediately resolving RESULT_DECLs/'this' to the
> > > > > > > ultimate ctx->object would not interact well with constexpr_call
> > > > > > > caching:
> > > > > > > 
> > > > > > >  struct A { A() = default; A(const A&); A *ap = this; };
> > > > > > >  constexpr A foo() { return {}; }
> > > > > > >  constexpr A a = foo();
> > > > > > >  constexpr A b = foo();
> > > > > > >  static_assert(b.ap == &b); // fails
> > > > > > > 
> > > > > > > Evaluation of the first call to foo() returns {&a}, since we
> > > > > > > resolve
> > > > > > > 'this' to &a due to guaranteed RVO, and we cache this result.
> > > > > > > Evaluation of the second call to foo() just returns the cached
> > > > > > > result
> > > > > > > from the constexpr_call cache, and so we get

[PATCH] c++: Infinite diagnostic loop with decltype([]{}) [PR94521]

2020-04-12 Thread Patrick Palka via Gcc-patches

We are hitting a recursive loop when printing the signature of a function
containing a decltype([]{}) type.  The loop is

  dump_function_decl -> dump_substitution
 -> dump_template_bindings
 -> dump_type
 -> dump_aggr_type
 -> dump_scope -> dump_function_decl

and we loop because dump_template_bindings wants to print the resolved type of
decltype([]{}) (i.e. just a lambda type), so it calls dump_aggr_type, which
wants to print the function scope of the lambda type.  But the function scope of
the lambda type is the function which we're in the middle of printing.

This patch breaks the loop by passing TFF_NO_FUNCTION_ARGUMENTS to
dump_function_decl from dump_scope, so that we avoid recursing into
dump_substitution and ultimately looping.

This also means we no longer print a "[with ...]" clause when printing a
function template scope, and we instead just print its template argument list in
a more natural way, e.g. instead of
foo(int, char) [with T=bool]::x
we would now print
foo::x
which seems like an improvement on its own.

The full signature of the function 'spam' in the below testcase is now
  void spam(decltype ()*) [with T = int; decltype () = 
spam::]

Successfully bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK to commit?

gcc/cp/ChangeLog:

PR c++/94521
* error.c (dump_scope): Pass TFF_NO_FUNCTION_ARGUMENTS to
dump_function_decl when printing a function template instantiation as a
scope.

gcc/testsuite/ChangeLog:

PR c++/94521
* g++.dg/cpp2a/lambda-uneval12.C: New test.
---
 gcc/cp/error.c   |  2 ++
 gcc/testsuite/g++.dg/cpp2a/lambda-uneval12.C | 13 +
 2 files changed, 15 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-uneval12.C

diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 61d1218dc90..98c163db572 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -211,6 +211,8 @@ dump_scope (cxx_pretty_printer *pp, tree scope, int flags)
 }
   else if ((flags & TFF_SCOPE) && TREE_CODE (scope) == FUNCTION_DECL)
 {
+  if (DECL_USE_TEMPLATE (scope))
+   f |= TFF_NO_FUNCTION_ARGUMENTS;
   dump_function_decl (pp, scope, f);
   pp_cxx_colon_colon (pp);
 }
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-uneval12.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-uneval12.C
new file mode 100644
index 000..24d2e701e44
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-uneval12.C
@@ -0,0 +1,13 @@
+// PR c++/94521
+// { dg-do compile { target c++2a } }
+
+template 
+void spam(decltype([]{}) *s)
+{
+  static_assert(__is_same(int, decltype(s))); // { dg-error "static assertion 
failed" }
+}
+
+void foo()
+{
+  spam(nullptr);
+}
-- 
2.26.0.106.g9fadedd637

Committed Fortran test case for PR

2020-04-12 Thread Thomas Koenig via Gcc-patches


Hi,

I just committed a test case for PR 94091 as obvious.
I had to fight git tooth and nail to do this.

I'm sure that git does wonderful things for you when you
have a mental picture in your mind of what is actually
going on For people who don't, it is a catastrophe, and
this includes most of the current gfortran maintainers.

(I was going to write up what I did to commit this patch,
but being surprised by error messages and then trying to
get around them does not really make for a good recipe...)

Regards

Thomas

2020-04-12  Thomas Koenig  

PR fortran/94091
* gfortran.dg/char_length_22.f90: New test.
! { dg-do compile }
! { dg-options "-O -Wall" }
! PR 94091 - this used to give a bogus warning.
! Test case by "MikeS".
program tester
  character(50) cname,fred
  fred='1234567890123456789012345678901234567890' ! 40 characters
  kk=len_trim(fred)
  cname=fred(5:kk)
  print *,kk,cname
end program tester

[PATCH] x86: Restore the frame pointer in word_mode

2020-04-12 Thread H.J. Lu via Gcc-patches

We must restore the frame pointer in word_mode for eh_return epilogues
since the upper 32 bits of RBP register can have any values.

Tested on Linux/x32 and Linux/x86-64.  OK for master and backport to
GCC 8/9 branches?

Thanks.

H.J.
---
PR target/94556
* config/i386/i386.c (ix86_expand_epilogue): Restore the frame
pointer in word_mode for eh_return epilogues.
---
 gcc/config/i386/i386.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index ca3b7dc06c2..f9c8f75b559 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -9052,8 +9052,14 @@ ix86_expand_epilogue (int style)
  t = plus_constant (Pmode, t, m->fs.fp_offset - UNITS_PER_WORD);
  emit_insn (gen_rtx_SET (sa, t));
 
- t = gen_frame_mem (Pmode, hard_frame_pointer_rtx);
- insn = emit_move_insn (hard_frame_pointer_rtx, t);
+ /* NB: eh_return epilogues must restore the frame pointer
+in word_mode since the upper 32 bits of RBP register
+can have any values.  */
+ t = gen_frame_mem (word_mode, hard_frame_pointer_rtx);
+ rtx frame_reg = hard_frame_pointer_rtx;
+ if (Pmode != word_mode)
+   frame_reg = gen_rtx_REG (word_mode, REGNO (frame_reg));
+ insn = emit_move_insn (frame_reg, t);
 
  /* Note that we use SA as a temporary CFA, as the return
 address is at the proper place relative to it.  We
@@ -9068,7 +9074,7 @@ ix86_expand_epilogue (int style)
  add_reg_note (insn, REG_CFA_DEF_CFA,
plus_constant (Pmode, sa, UNITS_PER_WORD));
  ix86_add_queued_cfa_restore_notes (insn);
- add_reg_note (insn, REG_CFA_RESTORE, hard_frame_pointer_rtx);
+ add_reg_note (insn, REG_CFA_RESTORE, frame_reg);
  RTX_FRAME_RELATED_P (insn) = 1;
 
  m->fs.cfa_reg = sa;
-- 
2.25.2

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

2020-04-12 Thread Martin Sebor via Gcc-patches


On 4/10/20 8:52 AM, Jason Merrill wrote:

On 4/9/20 4:23 PM, Martin Sebor wrote:

On 4/9/20 1:32 PM, Jason Merrill wrote:

On 4/9/20 3:24 PM, Martin Sebor wrote:

On 4/9/20 1:03 PM, Jason Merrill wrote:

On 4/8/20 1:23 PM, Martin Sebor wrote:

On 4/7/20 3:36 PM, Marek Polacek wrote:

On Tue, Apr 07, 2020 at 02:46:52PM -0600, Martin Sebor wrote:

On 4/7/20 1:50 PM, Marek Polacek wrote:
On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via 
Gcc-patches wrote:

Among the numerous regressions introduced by the change committed
to GCC 9 to allow string literals as template arguments is a 
failure
to recognize the C++ nullptr and GCC's __null constants as 
pointers.
For one, I didn't realize that nullptr, being a null pointer 
constant,
doesn't have a pointer type, and two, I didn't think of __null 
(which

is a special integer constant that NULL sometimes expands to).

The attached patch adjusts the special handling of trailing zero
initializers in reshape_init_array_1 to recognize both kinds of
constants and avoid treating them as zeros of the array integer
element type.  This restores the expected diagnostics when either
constant is used in the initializer list.

Martin


PR c++/94510 - nullptr_t implicitly cast to zero twice in 
std::array


gcc/cp/ChangeLog:

PR c++/94510
* decl.c (reshape_init_array_1): Exclude mismatches with 
all kinds

of pointers.

gcc/testsuite/ChangeLog:

PR c++/94510
* g++.dg/init/array57.C: New test.
* g++.dg/init/array58.C: New test.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index a127734af69..692c8ed73f4 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6041,9 +6041,14 @@ reshape_init_array_1 (tree elt_type, 
tree max_index, reshape_iter *d,

   TREE_CONSTANT (new_init) = false;
 /* Pointers initialized to strings must be treated as 
non-zero

- even if the string is empty.  */
+ even if the string is empty.  Handle all kinds of pointers,
+ including std::nullptr and GCC's __nullptr, neither of 
which

+ has a pointer type.  */
 tree init_type = TREE_TYPE (elt_init);
-  if (POINTER_TYPE_P (elt_type) != POINTER_TYPE_P 
(init_type)

+  bool init_is_ptr = (POINTER_TYPE_P (init_type)
+  || NULLPTR_TYPE_P (init_type)
+  || null_node_p (elt_init));
+  if (POINTER_TYPE_P (elt_type) != init_is_ptr
 || !type_initializer_zero_p (elt_type, elt_init))
   last_nonzero = index;


It looks like this still won't handle e.g. pointers to member 
functions,

e.g.

struct S { };
int arr[3] = { (void (S::*) ()) 0, 0, 0 };

would still be accepted.  You could use TYPE_PTR_OR_PTRMEM_P 
instead of

POINTER_TYPE_P to catch this case.


Good catch!  That doesn't fail because unlike null data member 
pointers
which are represented as -1, member function pointers are 
represented

as a zero.

I had looked for an API that would answer the question: "is this
expression a pointer?" without having to think of all the different
kinds of them but all I could find was null_node_p().  Is this a 
rare,

isolated case that having an API like that wouldn't be worth having
or should I add one like in the attached update?

Martin


PR c++/94510 - nullptr_t implicitly cast to zero twice in 
std::array


gcc/cp/ChangeLog:

PR c++/94510
* decl.c (reshape_init_array_1): Exclude mismatches with all 
kinds

of pointers.
* gcc/cp/cp-tree.h (null_pointer_constant_p): New function.


(Drop the gcc/cp/.)

+/* Returns true if EXPR is a null pointer constant of any 
type.  */

+
+inline bool
+null_pointer_constant_p (tree expr)
+{
+  STRIP_ANY_LOCATION_WRAPPER (expr);
+  if (expr == null_node)
+    return true;
+  tree type = TREE_TYPE (expr);
+  if (NULLPTR_TYPE_P (type))
+    return true;
+  if (POINTER_TYPE_P (type))
+    return integer_zerop (expr);
+  return null_member_pointer_value_p (expr);
+}
+


We already have a null_ptr_cst_p so it would be sort of confusing 
to have
this as well.  But are you really interested in whether it's a 
null pointer,

not just a pointer?


The goal of the code is to detect a mismatch in "pointerness" between
an initializer expression and the type of the initialized element, so
it needs to know if the expression is a pointer (non-nulls pointers
are detected in type_initializer_zero_p).  That means testing a 
number

of IMO unintuitive conditions:

   TYPE_PTR_OR_PTRMEM_P (TREE_TYPE (expr))
   || NULLPTR_TYPE_P (TREE_TYPE (expr))
   || null_node_p (expr)

I don't know if this type of a query is common in the C++ FE but 
unless

this is an isolated use case then besides fixing the bug I thought it
would be nice to make it easier to get the test above right, or at 
least

come close to it.

Since null_pointer_constant_p already exists (but isn't suitable here
because it returns true for plain literal zeros)


Why is that unsuitable?  A literal zero is a perfectly good 
zero-initializer for a pointer.


Right, that's why it's not suitable here.  Because a literal zero

[PATCH v2] rs6000: Don't use HARD_FRAME_POINTER_REGNUM if it's not live in pro_and_epilogue (PR91518)

2020-04-12 Thread luoxhu via Gcc-patches

This bug is exposed by FRE refactor of r263875.  Comparing the fre
dump file shows no obvious change of the segment fault function proves
it to be a target issue.
frame_pointer_needed is set to true in reload pass setup_can_eliminate,
but regs_ever_live[31] is false, pro_and_epilogue uses it without live
check causing CPU2006 465.tonto segment fault of loading from invalid
addresses due to r31 not saved/restored.  Thus, add HARD_FRAME_POINTER_REGNUM
live check with frame_pointer_needed_indeed_p when generating pro_and_epilogue
instructions.

Bootstrap and regression tested pass on Power8-LE.  Backport to gcc-9
required once approved.

gcc/ChangeLog

2020-04-13  Xiong Hu Luo  

PR target/91518
* config/rs6000/rs6000-logue.c (frame_pointer_needed_indeed_p):
New function.
(rs6000_emit_prologue_components):
Check with frame_pointer_needed_indeed_p.
(rs6000_emit_epilogue_components): Likewise.
(rs6000_emit_prologue): Likewise.
(rs6000_emit_epilogue): Likewise.
---
 gcc/config/rs6000/rs6000-logue.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/gcc/config/rs6000/rs6000-logue.c b/gcc/config/rs6000/rs6000-logue.c
index 4cbf228eb79..d17876ac0fb 100644
--- a/gcc/config/rs6000/rs6000-logue.c
+++ b/gcc/config/rs6000/rs6000-logue.c
@@ -2730,14 +2730,22 @@ rs6000_disqualify_components (sbitmap components, edge 
e,
 }
 }
 
+/* Determine whether HARD_FRAM_POINTER_REGNUM is really needed.  */
+static bool
+frame_pointer_needed_indeed_p (void)
+{
+  return frame_pointer_needed
+&& df_regs_ever_live_p (HARD_FRAME_POINTER_REGNUM);
+}
+
 /* Implement TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS.  */
 void
 rs6000_emit_prologue_components (sbitmap components)
 {
   rs6000_stack_t *info = rs6000_stack_info ();
-  rtx ptr_reg = gen_rtx_REG (Pmode, frame_pointer_needed
-? HARD_FRAME_POINTER_REGNUM
-: STACK_POINTER_REGNUM);
+  rtx ptr_reg = gen_rtx_REG (Pmode, frame_pointer_needed_indeed_p ()
+ ? HARD_FRAME_POINTER_REGNUM
+ : STACK_POINTER_REGNUM);
 
   machine_mode reg_mode = Pmode;
   int reg_size = TARGET_32BIT ? 4 : 8;
@@ -2815,9 +2823,9 @@ void
 rs6000_emit_epilogue_components (sbitmap components)
 {
   rs6000_stack_t *info = rs6000_stack_info ();
-  rtx ptr_reg = gen_rtx_REG (Pmode, frame_pointer_needed
-? HARD_FRAME_POINTER_REGNUM
-: STACK_POINTER_REGNUM);
+  rtx ptr_reg = gen_rtx_REG (Pmode, frame_pointer_needed_indeed_p ()
+ ? HARD_FRAME_POINTER_REGNUM
+ : STACK_POINTER_REGNUM);
 
   machine_mode reg_mode = Pmode;
   int reg_size = TARGET_32BIT ? 4 : 8;
@@ -3658,7 +3666,7 @@ rs6000_emit_prologue (void)
 }
 
   /* Set frame pointer, if needed.  */
-  if (frame_pointer_needed)
+  if (frame_pointer_needed_indeed_p ())
 {
   insn = emit_move_insn (gen_rtx_REG (Pmode, HARD_FRAME_POINTER_REGNUM),
 sp_reg_rtx);
@@ -4534,7 +4542,7 @@ rs6000_emit_epilogue (enum epilogue_type epilogue_type)
 }
   /* If we have a frame pointer, we can restore the old stack pointer
  from it.  */
-  else if (frame_pointer_needed)
+  else if (frame_pointer_needed_indeed_p ())
 {
   frame_reg_rtx = sp_reg_rtx;
   if (DEFAULT_ABI == ABI_V4)
-- 
2.21.0.777.g83232e3864

Re: [PATCH] Support the new ("v0") mangling scheme in rust-demangle.

2020-04-12 Thread Eduard-Mihai Burtescu

Ping 3: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html

Thanks,
- Eddy B.

On Tue, Apr 7, 2020, at 00:52, Eduard-Mihai Burtescu wrote:
> Ping 2: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html
> 
> Thanks,
> - Eddy B.
> 
> On Fri, Mar 13, 2020, at 10:28 PM, Eduard-Mihai Burtescu wrote:
> > This is the libiberty (mainly for binutils/gdb) counterpart of
> > https://github.com/alexcrichton/rustc-demangle/pull/23.
> > 
> > Relevant links for the new Rust mangling scheme (aka "v0"):
> > * Rust RFC: https://github.com/rust-lang/rfcs/pull/2603
> > * tracking issue: https://github.com/rust-lang/rust/issues/60705
> > * implementation: https://github.com/rust-lang/rust/pull/57967
> > 
> > This implementation includes full support for UTF-8 identifiers
> > via punycode, so I've included a testcase for that as well.
> > (Let me know if it causes any issues and I'll take it out)
> > 
> > Last year I've submitted several small patches to rust-demangle
> > in preparation for upstreaming the entire new demangler, and
> > feedback from that has proven useful.
> > For example, I started with error-handling macros, but instead
> > the code now has "rdm->errored = 1;" before several returns/gotos.
> > 
> > The patch is attached instead of inline, as it's over 1000 lines long.
> > 
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > 
> > Also, I have no commit access, so I'd be thankful if
> > someone would commit this for me if/once approved.
> > Attachments:
> > * 0001-Support-the-new-v0-mangling-scheme-in-rust-demangle.patch

Re: [PATCH v2 2/2] RISC-V: Handle implied extension for -march parser.

2020-04-12 Thread Kito Cheng

On Sat, Apr 11, 2020 at 1:48 AM Jim Wilson  wrote:
>
> On Fri, Apr 10, 2020 at 2:20 AM Kito Cheng  wrote:
> >   - Implied rule are introduced into latest RISC-V ISA spec.
> >   - Only implemented D implied F-extension. Zicsr and Zifence are not
> > implement yet, so the rule not included in this patch.
> >   - Pass preprocessed arch string to arch.
> >   - Verified with binutils 2.30 and 2.34.
>
> This is OK.
>
> Do we really need this now?  It is a new feature not a bug fix, so it
> might be better to wait until we reach stage1.  We have limited time
> to test this before the gcc-10 release.

Yeah, agree, there is no urgency to merge this in gcc-10, so let it
delay committing those two patches until stage 1.

[PING] [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

2020-04-12 Thread xiezhiheng

Ping for:


Xie Zhiheng


> -Original Message-
> From: xiezhiheng
> Sent: Thursday, April 2, 2020 2:35 PM
> To: 'gcc-patches@gcc.gnu.org' 
> Subject: [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted
> at -O3
> 
> Hi,
>   I've created a bug for this issue:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94442
> 
>   And I'm going to solve this problem by propagating def's insn to its use
>   when they are at the same loop in fwprop pass.
>   I mean something like:
> diff --git a/gcc/fwprop.c b/gcc/fwprop.c
> index 705d2885aae..0edbbc65047 100644
> --- a/gcc/fwprop.c
> +++ b/gcc/fwprop.c
> @@ -416,7 +416,7 @@ should_replace_address (rtx old_rtx, rtx new_rtx,
> machine_mode mode,
>  gain = (set_src_cost (new_rtx, VOIDmode, speed)
> - set_src_cost (old_rtx, VOIDmode, speed));
> 
> -  return (gain > 0);
> +  return (gain >= 0);
>  }
> 
> 
> @@ -1573,10 +1573,14 @@ fwprop (bool fwprop_addr_p)
>df_ref use = DF_USES_GET (i);
>if (use)
> {
> + df_ref def = get_def_for_use (use);
>   if (DF_REF_TYPE (use) == DF_REF_REG_USE
>   || DF_REF_BB (use)->loop_father == NULL
>   /* The outer most loop is not really a loop.  */
> - || loop_outer (DF_REF_BB (use)->loop_father) == NULL)
> + || loop_outer (DF_REF_BB (use)->loop_father) == NULL
> + || (def && (DF_REF_BB (def)->loop_father == DF_REF_BB
> (use)->loop_father
> + || flow_loop_nested_p
> (DF_REF_BB(use)->loop_father,
> +
> DF_REF_BB(def)->loop_father
> forward_propagate_into (use, fwprop_addr_p);
> 
>   else if (fwprop_addr_p)
> 
> Any suggestions?
> 
> Best regards
> Xie Zhiheng

[committed] Darwin, testsuite: Adjust indirect thunk tests for default flags.

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[PATCH] c++: Infinite diagnostic loop with decltype([]{}) [PR94521]

Committed Fortran test case for PR

[PATCH] x86: Restore the frame pointer in word_mode

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

[PATCH v2] rs6000: Don't use HARD_FRAME_POINTER_REGNUM if it's not live in pro_and_epilogue (PR91518)

Re: [PATCH] Support the new ("v0") mangling scheme in rust-demangle.

Re: [PATCH v2 2/2] RISC-V: Handle implied extension for -march parser.

[PING] [PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

10 matches

Site Navigation

Mail list logo

Footer information