[Bug bootstrap/92699] Slash should be removed from C/C++ plugin install destination

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-28
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
OK, so almost all other uses of $(DESTDIR) do not have a following '/'
character
so the proposed change sounds quite obvious.  All cases containing
'$(DESTDIR)/':

./gcc/c/Make-lang.in:   $(INSTALL_DATA) cc1$(exeext).a
$(DESTDIR)/$(plugin_resourcesdir)/cc1$(exeext).a
./gcc/jit/ChangeLog.jit:"$(DESTDIR)/$(libdir)/pkgconfig".
./gcc/jit/Make-lang.in:   $(DESTDIR)/$(libdir)/$(LIBGCCJIT_FILENAME)
./gcc/jit/Make-lang.in:   $(DESTDIR)/$(libdir)/$(LIBGCCJIT_SONAME_SYMLINK)
./gcc/jit/Make-lang.in:   $(DESTDIR)/$(libdir)/$(LIBGCCJIT_LINKER_NAME_SYMLINK)
./gcc/jit/Make-lang.in:   $(DESTDIR)/$(includedir)/libgccjit.h
./gcc/jit/Make-lang.in:   $(DESTDIR)/$(includedir)/libgccjit++.h
./gcc/cp/Make-lang.in:  $(INSTALL_DATA) cc1plus$(exeext).a
$(DESTDIR)/$(plugin_resourcesdir)/cc1plus$(exeext).a

David - most of them are in libjit, would you please take care of adjusting
those and also the rest and do some testing (you seem to play with plugins
as well recently ;)).  The other '/' in libjit are probably similarly
bogus.  Thanks.

[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit

[paul.richard.thomas at gmail dot com]

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

--- Comment #21 from paul.richard.thomas at gmail dot com  ---
Hi All,

I took one of the other fn_spec's as a template - it might well have
been internal_pack.

Thanks for looking at this.

Cheers

Paul

On Mon, 25 Nov 2019 at 13:04, jakub at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
>
> --- Comment #15 from Jakub Jelinek  ---
> I think other fn spec attributes in trans-decl.c should be checked.
> E.g. for internal_pack, I see ".r", when the function sometimes returns a
> pointer to a field pointed by the first argument.  The address of the
> descriptor doesn't escape then, but there is indirect escape.  What about
> internal_unpack?
> Both cfi_desc_to_gfc_desc and gfc_desc_to_cfi_desc should be ".w." as Richi
> said.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug preprocessor/92696] #pragma GCC diagnostic ... interferes with if/else

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Richard Biener  ---
Not a bug then.

[Bug bootstrap/92699] Slash should be removed from C/C++ plugin install destination

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
   Host||MinGW-w64

--- Comment #1 from Richard Biener  ---
Hmm, I think people just call make install DESTDIR=/foo/bar without a trailing
slash so we do need some kind of dir separator or canonicalization of DESTDIR?

[Bug c++/92700] wrong "unintialized" warning with std::optional

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Blocks||24639

--- Comment #1 from Richard Biener  ---
We at least do have other PRs complaining about std::optional


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063

[zhroma at gcc dot gnu.org]

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

Roman Zhuykov  changed:

   What|Removed |Added

  Attachment #47379|0   |1
is obsolete||

--- Comment #4 from Roman Zhuykov  ---
Created attachment 47386
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47386=edit
Proposed patch v2

Found a mistake in previous patch

[Bug target/92566] rs6000_preferred_simd_mode isn't very good

[linkw at gcc dot gnu.org]

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

Kewen Lin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Kewen Lin  ---
Fixed.

[Bug target/92566] rs6000_preferred_simd_mode isn't very good

[linkw at gcc dot gnu.org]

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

--- Comment #13 from Kewen Lin  ---
Author: linkw
Date: Thu Nov 28 06:34:31 2019
New Revision: 278800

URL: https://gcc.gnu.org/viewcvs?rev=278800=gcc=rev
Log:
[rs6000] Fix PR92566 by checking VECTOR_UNIT_NONE_P

As Segher pointed out in PR92566, we shouldn't offer some vector modes which
aren't supported under current setting.  This patch is to make it check by
VECTOR_UNIT_NONE_P which is initialized as current architecture masks.

2019-11-28  Kewen Lin  

PR target/92566
* gcc/config/rs6000/rs6000.c (rs6000_preferred_simd_mode): Check by
VECTOR_UNIT_NONE_P instead.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

Re: C++ PATCH for c++/91363 - P0960R3: Parenthesized initialization of aggregates

[Jason Merrill]

On 11/27/19 5:25 PM, Marek Polacek wrote:

On Wed, Nov 27, 2019 at 04:54:55PM -0500, Jason Merrill wrote:

@@ -921,8 +921,20 @@ perform_member_init (tree member, tree init)
inform (DECL_SOURCE_LOCATION (member),
"%q#D should be initialized", member );
}
- finish_expr_stmt (build_aggr_init (decl, init, flags,
-tf_warning_or_error));
+ init = build_aggr_init (decl, init, flags, tf_warning_or_error);
+ /* In C++20, a member initializer list can be initializing an
+aggregate from a parenthesized list of values:
+
+  struct S {
+A aggr;
+S() : aggr(1, 2, 3) { }
+  };
+
+ In such case, build_aggr_init will build up an INIT_EXPR like
+ we do for aggr{1, 2, 3}, so that build_data_member_initialization
+ can grok it.  */
+ if (TREE_CODE (init) != INIT_EXPR)
+   finish_expr_stmt (init);


Why don't we want to finish_expr_stmt an INIT_EXPR?


Because expand_default_init has already finish_expr_stmt-ed it.  Adding it
twice sounds wrong.


But the finish_expr_stmt in expand_default_init is inside the STATEMENT_LIST
we pushed into in build_aggr_init.  If finish_init_stmts returned the
INIT_EXPR, we still need to add it to the enclosing STATEMENT_LIST.


I don't understand why none of my tests broke


This seems to be because build_aggr_init returns an EXPR_STMT, so the 
test didn't affect anything.



but here's a patch with that if removed:

dg.exp passed, bootstrap/regtest running.

2019-11-27  Marek Polacek  

PR c++/91363 - P0960R3: Parenthesized initialization of aggregates.
* c-cppbuiltin.c (c_cpp_builtins): Predefine
__cpp_aggregate_paren_init=201902 for -std=c++2a.

* call.c (build_new_method_call_1): Handle parenthesized initialization
of aggregates by building up a CONSTRUCTOR.
(extend_ref_init_temps): Do nothing for CONSTRUCTOR_IS_PAREN_INIT.
* cp-tree.h (CONSTRUCTOR_IS_PAREN_INIT, LOOKUP_AGGREGATE_PAREN_INIT):
Define.
* decl.c (grok_reference_init): Handle aggregate initialization from
a parenthesized list of values.
(reshape_init): Do nothing for CONSTRUCTOR_IS_PAREN_INIT.
(check_initializer): Handle initialization of an array from a
parenthesized list of values.  Use NULL_TREE instead of NULL.
* init.c (expand_default_init): Set LOOKUP_AGGREGATE_PAREN_INIT for the
build_special_member_call call.  If it returns a
BRACE_ENCLOSED_INITIALIZER_P, call digest_init and build an INIT_EXPR.
Set TREE_SIDE_EFFECTS on it.
* tree.c (build_cplus_new): Handle BRACE_ENCLOSED_INITIALIZER_P.
* typeck2.c (digest_init_r): Set LOOKUP_AGGREGATE_PAREN_INIT if it
receives a CONSTRUCTOR with CONSTRUCTOR_IS_PAREN_INIT set.  Allow
narrowing when LOOKUP_AGGREGATE_PAREN_INIT.
(massage_init_elt): Don't lose LOOKUP_AGGREGATE_PAREN_INIT when passing
flags to digest_init_r.

* g++.dg/cpp0x/constexpr-99.C: Only expect an error in C++17 and
lesser.
* g++.dg/cpp0x/explicit7.C: Likewise.
* g++.dg/cpp0x/initlist12.C: Adjust dg-error.
* g++.dg/cpp0x/pr31437.C: Likewise.
* g++.dg/cpp2a/feat-cxx2a.C: Add __cpp_aggregate_paren_init test.
* g++.dg/cpp2a/paren-init1.C: New test.
* g++.dg/cpp2a/paren-init10.C: New test.
* g++.dg/cpp2a/paren-init11.C: New test.
* g++.dg/cpp2a/paren-init12.C: New test.
* g++.dg/cpp2a/paren-init13.C: New test.
* g++.dg/cpp2a/paren-init14.C: New test.
* g++.dg/cpp2a/paren-init15.C: New test.
* g++.dg/cpp2a/paren-init16.C: New test.
* g++.dg/cpp2a/paren-init17.C: New test.
* g++.dg/cpp2a/paren-init18.C: New test.
* g++.dg/cpp2a/paren-init2.C: New test.
* g++.dg/cpp2a/paren-init3.C: New test.
* g++.dg/cpp2a/paren-init4.C: New test.
* g++.dg/cpp2a/paren-init5.C: New test.
* g++.dg/cpp2a/paren-init6.C: New test.
* g++.dg/cpp2a/paren-init7.C: New test.
* g++.dg/cpp2a/paren-init8.C: New test.
* g++.dg/cpp2a/paren-init9.C: New test.
* g++.dg/ext/desig10.C: Adjust dg-error.
* g++.dg/template/crash107.C: Likewise.
* g++.dg/template/crash95.C: Likewise.
* g++.old-deja/g++.jason/crash3.C: Only expect an error in C++17 and
lesser.
* g++.old-deja/g++.law/ctors11.C: Likewise.
* g++.old-deja/g++.law/ctors9.C: Likewise.
* g++.old-deja/g++.mike/net22.C: Likewise.
* g++.old-deja/g++.niklas/t128.C: Likewise.

diff --git gcc/c-family/c-cppbuiltin.c gcc/c-family/c-cppbuiltin.c
index 50066e4dd8b..2f30b2a3235 100644
--- gcc/c-family/c-cppbuiltin.c
+++ gcc/c-family/c-cppbuiltin.c
@@ -1004,6 +1004,7 @@ c_cpp_builtins (cpp_reader *pfile)
  cpp_define (pfile, 

[Bug c/66773] sign-compare warning for == and != are pretty useless

[daniel.marjamaki at gmail dot com]

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

--- Comment #20 from Daniel Marjamäki  ---
(In reply to Segher Boessenkool from comment #15)
> (In reply to Daniel Marjamäki from comment #12)
> > So, how would you fix the warning for `f`? Many programmers would "fix" it
> > with a cast.
> > 
> > Assuming that `s` and `u` can have arbitrary values, here is the proper 
> > code:
> > 
> > void f(long s, unsigned long u) { if (s >= 0 && s == u) g(); }
> > 
> > For this correct code, gcc warns.
> 
> A much better fix is
> 
> void f1(long s, unsigned long u) { unsigned long su = s; if (su == u) g(); }
> 
> which makes it rather explicit what is going on.
> 
> Still much better is to not mixed signedness in types at all.

Ping. Your "much better" code does not work. This code prints "equal" on the
screen:


void f1(long s, unsigned long u) {
unsigned long su = s;
if (su == u) printf("equal\n");
}

int main() { f1(-1L, ~0UL); return 0; }


Please try again.

You proved my point somewhat. The programmer gets a warning, the programmer
tries to fix it, the code still has the same bug but the warning has gone away.
However I feel that your fix is much safer than a cast because Cppcheck,
sanitizers, etc can still warn.

Re: [C++ PATCH] Avoid weird warning about pure virtual inline being used but not defined (PR c++/92695)

[Jason Merrill]

On 11/27/19 6:43 PM, Jakub Jelinek wrote:

Hi!

While working on the PR92695 bug, I've noticed a weird warning, when
the testcase contained (pointless, but not invalid) constexpr specifier on
pure virtual function.  constexpr implies DECL_DECLARED_INLINE_P and
we would note_vague_linkage_fn and later complain that the inline
function wasn't ever defined.
As can be seen in the testcase, for inline pure virtual we warn the same.
The specifiers don't make much sense, but Jonathan nor I could find anything
that would say that inline pure virtual or constexpr pure virtual is
invalid.  clang++ accepts those without warnings too.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?


OK.



2019-11-27  Jakub Jelinek  

PR c++/92695
* decl2.c (mark_used): Don't call note_vague_linkage_fn for pure
virtual functions, even if they are declared inline.

* g++.dg/warn/inline3.C: New test.

--- gcc/cp/decl2.c.jj   2019-11-12 09:09:33.658814862 +0100
+++ gcc/cp/decl2.c  2019-11-27 18:26:53.698018564 +0100
@@ -5596,8 +5596,11 @@ mark_used (tree decl, tsubst_flags_t com
vec_safe_push (no_linkage_decls, decl);
  }
  
-  if (TREE_CODE (decl) == FUNCTION_DECL && DECL_DECLARED_INLINE_P (decl)

-  && !DECL_INITIAL (decl) && !DECL_ARTIFICIAL (decl))
+  if (TREE_CODE (decl) == FUNCTION_DECL
+  && DECL_DECLARED_INLINE_P (decl)
+  && !DECL_INITIAL (decl)
+  && !DECL_ARTIFICIAL (decl)
+  && !DECL_PURE_VIRTUAL_P (decl))
  /* Remember it, so we can check it was defined.  */
  note_vague_linkage_fn (decl);
  
--- gcc/testsuite/g++.dg/warn/inline3.C.jj	2019-11-27 18:13:46.685074239 +0100

+++ gcc/testsuite/g++.dg/warn/inline3.C 2019-11-27 18:18:40.688577837 +0100
@@ -0,0 +1,20 @@
+struct S {
+  inline virtual void foo () = 0;  // { dg-bogus "used but never defined" }
+#if __cplusplus > 201703L
+  constexpr virtual void bar () = 0;   // { dg-bogus "used but never defined" 
"" { target c++2a } }
+#else
+  inline virtual void bar () = 0;  // { dg-bogus "used but never defined" 
"" { target c++17_down }  }
+#endif
+  S () {}
+};
+struct T : public S {
+  inline virtual void foo () {}
+#if __cplusplus > 201703L
+  constexpr virtual void bar () {}
+#else
+  inline virtual void bar () {}
+#endif
+  T () {}
+};
+T t;
+void foo (S *s) { s->foo (); s->bar (); }

Jakub

Re: [C++ PATCH] c++/91353 - P1331R2: Allow trivial default init in constexpr contexts.

[Jason Merrill]

On 11/27/19 6:35 PM, Marek Polacek wrote:

On Wed, Nov 27, 2019 at 04:47:01PM -0500, Jason Merrill wrote:

On 11/27/19 2:36 PM, Marek Polacek wrote:

On Sun, Nov 24, 2019 at 12:24:48PM -0500, Jason Merrill wrote:

On 11/16/19 5:23 PM, Marek Polacek wrote:

[ Working virtually on Baker Island. ]

This patch implements C++20 P1331, allowing trivial default initialization in
constexpr contexts.

I used Jakub's patch from the PR which allowed uninitialized variables in
constexpr contexts.  But the hard part was handling CONSTRUCTOR_NO_CLEARING
which is always cleared in cxx_eval_call_expression.  We need to set it in
the case a constexpr constructor doesn't initialize all the members, so that
we can give proper diagnostic instead of value-initializing.  A lot of my
attempts flopped but then I came up with this approach, which handles various
cases as tested in constexpr-init8.C, where S is initialized by a non-default
constexpr constructor, and constexpr-init9.C, using delegating constructors.
And the best part is that I didn't need any new cx_check_missing_mem_inits
calls!  Just save the information whether a constructor is missing an init
into constexpr_fundef_table and retrieve it when needed.


Is it necessary to clear the flag for constructors that do happen to
initialize all the members?  I would think that leaving that clearing to
reduced_constant_expression_p would be enough.


It seems so: if I tweak cxx_eval_call_expression to only call 
clear_no_implicit_zero
when 'fun' isn't DECL_CONSTRUCTOR_P, then a lot breaks, e.g. constexpr-base.C
where the constructor initializes all the members.  By breaking I mean spurious
errors coming from

5937   if (TREE_CODE (r) == CONSTRUCTOR && CONSTRUCTOR_NO_CLEARING (r))
5938 {
5939   if (!allow_non_constant)
5940 error ("%qE is not a constant expression because it refers to "
5941"an incompletely initialized variable", t);
5942   TREE_CONSTANT (r) = false;
5943   non_constant_p = true;
5944 }


Why didn't reduced_constant_expression_p unset CONSTRUCTOR_NO_CLEARING?


We have a constructor that initializes a base class and members of a class:

   {.D.2364={.i=12}, .a={.i=24}, .j=36}

Say we don't clear CONSTRUCTOR_NO_CLEARING in this ctor in 
cxx_eval_call_expression.
Then soon in reduced_constant_expression_p we do
2221 field = next_initializable_field (TYPE_FIELDS (TREE_TYPE (t)));
and since "Implement P0017R1, C++17 aggregates with bases. / r241187" we skip
base fields in C++17 so 'field' is set to 'a'.


Hmm?


next_initializable_field (tree field)
{
  while (field
 && (TREE_CODE (field) != FIELD_DECL
 || DECL_UNNAMED_BIT_FIELD (field)
 || (DECL_ARTIFICIAL (field)
 && !(cxx_dialect >= cxx17 && DECL_FIELD_IS_BASE (field)
field = DECL_CHAIN (field);


This skips artificial fields except that in C++17 and up base fields are 
*not* skipped.


How are you getting field starting with 'a'?  Are you compiling in a 
lower standard mode?  The code using next_initializable_field doesn't 
work for lower -std because of skipping base fields.


So perhaps we want to always clear_no_implicit_zero before c++20, and 
always for c++20 and up?



Now we look at each element of the constructor; the first one is
D.2364={.i=12}.  But we hit

2233   if (idx != field)
2234 return false;

because field is 'a' and idx is D.2364.  Were you thinking of tweaking
reduced_constant_expression_p's behavior in C++20 and dropping the whole
cxx_eval_call_expression hunk?

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: Branch and tag deletions

[Eric S. Raymond]

Joseph Myers :
> One more observation on that: in my last test conversion, deleting the 
> emptycommit-* tags took over 7 hours (i.e. the bulk of the time for the 
> conversion was spent just deleting those tags).  Deleting tags matching 
> /-root$/ took about half an hour.  So I think there is a performance issue 
> somewhere with (some cases of) tag deletion by regexp, at least when the 
> regexp matches a large number of tags (but some other bulk deletions seem 
> to run much quicker per tag).  Taking a few seconds per tag is fine for an 
> individual deletion, but a problem when you want to delete 4070 tags at 
> once.

File that as an issue, please. Go has very good profiling tools, finding
the hotspot(s) in situations like this is easy and thus we should be able to
fix this quickly when it reaches the top of the priority list,
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

Re: [PATCH] Support multi-versioning on self-recursive function (ipa/92133)

[Feng Xue OS]

Have no a complete idea for new cost model, but there are something we can try:
o.  adjust estimated profile for recursive function so that we can get a higher 
threshold.
o.  introduce a strength level for ipa-cp-clone, by default, it is same as 
current configuration,
and with larger number, ipa-cp works more aggressively.
o. integrate frequency information to computation of prop_time_benefit.

Feng


From: Jan Hubicka 
Sent: Wednesday, November 27, 2019 10:27 PM
To: Feng Xue OS
Cc: Martin Jambor; Richard Biener; luoxhu; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Support multi-versioning on self-recursive function 
(ipa/92133)

> 2019-11-15  Feng Xue 
>
> PR ipa/92133
> * doc/invoke.texi (ipa-cp-max-recursive-depth): Document new option.
> (ipa-cp-min-recursive-probability): Likewise.
> * params.opt (ipa-cp-max-recursive-depth): New.
> (ipa-cp-min-recursive-probability): Likewise.
> * ipa-cp.c (ipcp_lattice::add_value): Add two new parameters
> val_p and unlimited.
> (self_recursively_generated_p): New function.
> (get_val_across_arith_op): Likewise.
> (propagate_vals_across_arith_jfunc): Add constant propagation for
> self-recursive function.
> (incorporate_penalties): Do not penalize pure self-recursive function.
> (good_cloning_opportunity_p): Dump node_is_self_scc flag.
> (propagate_constants_topo): Set node_is_self_scc flag for cgraph node.
> (get_info_about_necessary_edges): Relax hotness check for edge to
> self-recursive function.
> * ipa-prop.h (ipa_node_params): Add new field node_is_self_scc.

OK, thanks!
do you have some plans on the better cost model for the recursive
cloning? Also it would be nice to have this info available in recursive
inliner and give it a higher priority when inlining is going to turn
previously recrusive call into non-recursive.

Honza

[Bug tree-optimization/92689] Improve stmt_may_clobber_ref_p_1 on constant memory reference

[fxue at os dot amperecomputing.com]

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

--- Comment #6 from Feng Xue  ---
Good case. I did missed something, a const pointer does not imply it is
restrict and for a real const data, we can even create a non-const pointer
alias to it by using explicit type cast.

Ping: [PATCH] Add explicit description for -finline

[luoxhu]

On 2019/11/4 11:42, luoxhu wrote:

On 2019/11/2 00:23, Joseph Myers wrote:

On Thu, 31 Oct 2019, Xiong Hu Luo wrote:


+@code{-finline} enables inlining of function declared \"inline\".
+@code{-finline} is enabled at levels -O1, -O2, -O3 and -Os, but not -Og.


Use @option{} to mark up option names (both -finline and all the -O
options in this paragraph).  Use @code{} to mark up keyword names, not
\"\".



Thanks.  So shall I commit the tiny patch with below updates?

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 1407d019d14..ea0d407fe11 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -8576,6 +8576,10 @@ optimizing.
  Single functions can be exempted from inlining by marking them
  with the @code{noinline} attribute.

+@option{-finline} enables inlining of function declared @code{inline}.
+@option{-finline} is enabled at levels @option{-O1}, @option{-O2}, @option{-O3}
+and @option{-Os}, but not @option{-Og}.
+
  @item -finline-small-functions
  @opindex finline-small-functions
  Integrate functions into their callers when their body is smaller than 
expected

[Bug c++/92675] sign-conversion C++ unsigned int j = -1;

[jg at jguk dot org]

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

--- Comment #5 from Jonny Grant  ---
I tried godbolt trunk again for C++ today with  -Wsign-conversion and it does
give a warning. I can only think I made a mistake while checking - unless a
patch has just gone in?

Re: Autoinc vs reload and LRA

[Segher Boessenkool]

On Mon, Nov 25, 2019 at 09:22:55PM +0100, Bernd Schmidt wrote:
> So I was curious what would happen if I turned on LRA for m68k. It turns
> out my autoinc patches from the cc0 patch set expose a bug in how LRA
> handles autoincrement. While it copies the logic from reload's
> inc_for_reload, it appears to be missing the find_reloads_address code
> to ensure an autoinc address is reloaded entirely if it is part of a
> jump. LRA can reload just the register inside a POST_INC, which leads to
> creating an output reload.
> 
> Hence, a new version of the autoinc changes, below. Since reload is
> known to work, we allow autoinc in jumps unless targetm.lra_p. One part
> of the patch is a fix for the earlier combine patch which was already
> checked in, the other part is a new version of the auto-inc-dec patch.
> Bootstrapped and tested on the gcc135 machine
> (powerpc64le-unknown-linux-gnu). OK?

Thanks :-)

Could you open a PR for the LRA problem please?


Segher

Re: [PATCH] Reformat PowerPC movdi_internal64

[Michael Meissner]

Here is the patch I committed for movdi_internal64:

2019-11-27  Michael Meissner  

* config/rs6000/rs6000.md (movdi_internal64): Reformat.

Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 278787)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -8827,24 +8827,33 @@ (define_split
   DONE;
 })
 
-;;  GPR store  GPR load   GPR move   GPR li GPR lis GPR #
-;;  FPR store  FPR load   FPR move   AVX store  AVX store   AVX 
load
-;;  AVX load   VSX move   P9 0   P9 -1  AVX 0/-1VSX 0
-;;  VSX -1 P9 const   AVX const  From SPR   To SPR  
SPR<->SPR
-;;  VSX->GPR   GPR->VSX
+;; GPR store  GPR load   GPR move
+;; GPR li GPR lisGPR #
+;; FPR store  FPR load   FPR move
+;; AVX store  AVX store  AVX load   AVX load   VSX move
+;; P9 0   P9 -1  AVX 0/-1   VSX 0  VSX -1
+;; P9 const   AVX const
+;; From SPR   To SPR SPR<->SPR
+;; VSX->GPR   GPR->VSX
 (define_insn "*movdi_internal64"
   [(set (match_operand:DI 0 "nonimmediate_operand"
-   "=YZ,   r, r, r, r,  r,
-m, ^d,^d,wY,Z,  $v,
-$v,^wa,   wa,wa,v,  wa,
-wa,v, v, r, *h, *h,
-?r,?wa")
+   "=YZ,   r,  r,
+   r,  r,  r,
+   m,  ^d, ^d,
+   wY, Z,  $v, $v, ^wa,
+   wa, wa, v,  wa, wa,
+   v,  v,
+   r,  *h, *h,
+   ?r, ?wa")
(match_operand:DI 1 "input_operand"
-   "r, YZ,r, I, L,  nF,
-^d,m, ^d,^v,$v, wY,
-Z, ^wa,   Oj,wM,OjwM,   Oj,
-wM,wS,wB,*h,r,  0,
-wa,r"))]
+   "r, YZ, r,
+   I,  L,  nF,
+   ^d, m,  ^d,
+   ^v, $v, wY, Z,  ^wa,
+   Oj, wM, OjwM,   Oj, wM,
+   wS, wB,
+   *h, r,  0,
+   wa, r"))]
   "TARGET_POWERPC64
&& (gpc_reg_operand (operands[0], DImode)
|| gpc_reg_operand (operands[1], DImode))"
@@ -8876,24 +8885,33 @@ (define_insn "*movdi_internal64"
mfvsrd %0,%x1
mtvsrd %x0,%1"
   [(set_attr "type"
-   "store,  load,  *, *, *, *,
-fpstore,fpload, fpsimple,  fpstore,   fpstore,   
fpload,
-fpload, veclogical, vecsimple, vecsimple, vecsimple, 
veclogical,
-veclogical, vecsimple,  vecsimple, mfjmpr,mtjmpr,*,
-mftgpr,mffgpr")
+   "store,  load,   *,
+   *,   *,  *,
+   fpstore, fpload, fpsimple,
+   fpstore, fpstore,fpload, fpload, veclogical,
+   vecsimple,   vecsimple,  vecsimple,  veclogical, veclogical,
+   vecsimple,   vecsimple,
+   mfjmpr,  mtjmpr, *,
+   mftgpr,  mffgpr")
(set_attr "size" "64")
(set_attr "length"
-   "*, *, *, *, *,  20,
-*, *, *, *, *,  *,
-*, *, *, *, *,  *,
-*, 8, *, *, *,  *,
-*, *")
+   "*, *,  *,
+   *,  *,  20,
+   *,  *,  *,
+   *,  *,  *,  *,  *,
+   *,  *,  *,  *,  *,
+   8,  *,
+   *,  *,  *,
+   *,  *")
(set_attr "isa"
-   "*, *, *, *, *,  *,
-*, *, *, p9v,   p7v,p9v,
-p7v,   *, p9v,   p9v,   p7v,*,
-*, p7v,   p7v,   *, *,  *,
-p8v,   p8v")])
+   "*, *,  *,
+   *,  *,  *,
+   *,  *,  *,
+   

Re: [PATCH] Reformat PowerPC movsi_internal

[Michael Meissner]

Here is the patch that I committed for movsi_internal:

2019-11-27  Michael Meissner  

* config/rs6000/rs6000.md (movsi_internal): Reformat.

Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 278781)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -6889,24 +6889,34 @@ (define_split
 UNSPEC_MOVSI_GOT))]
   "")
 
-;; MR   LA   LWZ  LFIWZX   LXSIWZX
-;; STW  STFIWX   STXSIWX  LI   LIS
-;; #XXLORXXSPLTIB 0   XXSPLTIB -1  VSPLTISW
-;; XXLXOR 0 XXLORC -1P9 const MTVSRWZ  MFVSRWZ
-;; MF%1 MT%0 NOP
+;; MR   LA
+;; LWZ  LFIWZX  LXSIWZX
+;; STW  STFIWX  STXSIWX
+;; LI   LIS #
+;; XXLORXXSPLTIB 0  XXSPLTIB -1 VSPLTISW
+;; XXLXOR 0 XXLORC -1   P9 const
+;; MTVSRWZ  MFVSRWZ
+;; MF%1 MT%0NOP
+
 (define_insn "*movsi_internal1"
   [(set (match_operand:SI 0 "nonimmediate_operand"
-   "=r, r,   r,   d,   v,
-m,  Z,   Z,   r,   r,
-r,  wa,  wa,  wa,  v,
-wa, v,   v,   wa,  r,
-r,  *h,  *h")
+   "=r, r,
+   r,   d,  v,
+   m,   Z,  Z,
+   r,   r,  r,
+   wa,  wa, wa, v,
+   wa,  v,  v,
+   wa,  r,
+   r,   *h, *h")
(match_operand:SI 1 "input_operand"
-   "r,  U,   m,   Z,   Z,
-r,  d,   v,   I,   L,
-n,  wa,  O,   wM,  wB,
-O,  wM,  wS,  r,   wa,
-*h, r,   0"))]
+   "r,  U,
+   m,   Z,  Z,
+   r,   d,  v,
+   I,   L,  n,
+   wa,  O,  wM, wB,
+   O,   wM, wS,
+   r,   wa,
+   *h,  r,  0"))]
   "gpc_reg_operand (operands[0], SImode)
|| gpc_reg_operand (operands[1], SImode)"
   "@
@@ -6934,23 +6944,32 @@ (define_insn "*movsi_internal1"
mt%0 %1
nop"
   [(set_attr "type"
-   "*,  *,   load,fpload,  fpload,
-store,  fpstore, fpstore, *,   *,
-*,  veclogical,  vecsimple,   vecsimple,   vecsimple,
-veclogical, veclogical,  vecsimple,   mffgpr,  mftgpr,
-*,  *,   *")
+   "*, *,
+   load,   fpload, fpload,
+   store,  fpstore,fpstore,
+   *,  *,  *,
+   veclogical, vecsimple,  vecsimple,  vecsimple,
+   veclogical, veclogical, vecsimple,
+   mffgpr, mftgpr,
+   *,  *,  *")
(set_attr "length"
-   "*,  *,   *,   *,   *,
-*,  *,   *,   *,   *,
-8,  *,   *,   *,   *,
-*,  *,   8,   *,   *,
-*,  *,   *")
+   "*, *,
+   *,  *,   *,
+   *,  *,   *,
+   *,  *,   8,
+   *,  *,   *,  *,
+   *,  *,   8,
+   *,  *,
+   *,  *,   *")
(set_attr "isa"
-   "*,  *,   *,   p8v, p8v,
-*,  p8v, p8v, *,   *,
-*,  p8v, p9v, p9v, p8v,
-p9v,p8v, p9v, p8v, p8v,
-*,  *,   *")])
+   "*,  *,
+   *,   p8v,   p8v,
+   *,   p8v,   p8v,
+   *,   *, *,
+   p8v, p9v,   p9v,   p8v,
+   p9v, p8v,   p9v,
+   p8v, p8v,
+   *,   *, *")])
 
 ;; Like movsi, but adjust a SF value to be 

Re: [C++ PATCH] Fix OBJ_TYPE_REF constexpr handling (PR c++/92695)

[Marek Polacek]

On Thu, Nov 28, 2019 at 12:44:43AM +0100, Jakub Jelinek wrote:
> Hi!
> 
> On the following testcase the constexpr evaluation of the virtual call
> fails, because what cxx_eval_constant_expression returns for
> OBJ_TYPE_REF_OBJECT is actually not ADDR_EXPR, but ADDR_EXPR wrapped in
> a NOP_EXPR.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?

Looks ok.  In fact, when working on constexpr dynamic_cast, I ran into a very
similar problem and also added STRIP_NOPS.

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

[C++ PATCH] Fix OBJ_TYPE_REF constexpr handling (PR c++/92695)

[Jakub Jelinek]

Hi!

On the following testcase the constexpr evaluation of the virtual call
fails, because what cxx_eval_constant_expression returns for
OBJ_TYPE_REF_OBJECT is actually not ADDR_EXPR, but ADDR_EXPR wrapped in
a NOP_EXPR.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2019-11-27  Jakub Jelinek  

PR c++/92695
* constexpr.c (cxx_eval_constant_expression) : Use
STRIP_NOPS before checking for ADDR_EXPR.

* g++.dg/cpp2a/constexpr-virtual15.C: New test.

--- gcc/cp/constexpr.c.jj   2019-11-27 17:53:37.477566346 +0100
+++ gcc/cp/constexpr.c  2019-11-27 21:16:51.094188509 +0100
@@ -5566,6 +5566,7 @@ cxx_eval_constant_expression (const cons
tree obj = OBJ_TYPE_REF_OBJECT (t);
obj = cxx_eval_constant_expression (ctx, obj, lval, non_constant_p,
overflow_p);
+   STRIP_NOPS (obj);
/* We expect something in the form of  get x. */
if (TREE_CODE (obj) != ADDR_EXPR
|| !DECL_P (get_base_address (TREE_OPERAND (obj, 0
--- gcc/testsuite/g++.dg/cpp2a/constexpr-virtual15.C.jj 2019-11-27 
21:18:15.418895652 +0100
+++ gcc/testsuite/g++.dg/cpp2a/constexpr-virtual15.C2019-11-27 
21:17:48.602306802 +0100
@@ -0,0 +1,7 @@
+// PR c++/92695
+// { dg-do compile { target c++2a } }
+
+struct A { virtual int get() = 0; };
+struct B : A { constexpr int get() override { return 10; } };
+struct D { B b[2]; A* c{&(b[0])}; };
+static_assert(D{}.c->get() == 10);

Jakub

[C++ PATCH] Avoid weird warning about pure virtual inline being used but not defined (PR c++/92695)

[Jakub Jelinek]

Hi!

While working on the PR92695 bug, I've noticed a weird warning, when
the testcase contained (pointless, but not invalid) constexpr specifier on
pure virtual function.  constexpr implies DECL_DECLARED_INLINE_P and
we would note_vague_linkage_fn and later complain that the inline
function wasn't ever defined.
As can be seen in the testcase, for inline pure virtual we warn the same.
The specifiers don't make much sense, but Jonathan nor I could find anything
that would say that inline pure virtual or constexpr pure virtual is
invalid.  clang++ accepts those without warnings too.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2019-11-27  Jakub Jelinek  

PR c++/92695
* decl2.c (mark_used): Don't call note_vague_linkage_fn for pure
virtual functions, even if they are declared inline.

* g++.dg/warn/inline3.C: New test.

--- gcc/cp/decl2.c.jj   2019-11-12 09:09:33.658814862 +0100
+++ gcc/cp/decl2.c  2019-11-27 18:26:53.698018564 +0100
@@ -5596,8 +5596,11 @@ mark_used (tree decl, tsubst_flags_t com
vec_safe_push (no_linkage_decls, decl);
 }
 
-  if (TREE_CODE (decl) == FUNCTION_DECL && DECL_DECLARED_INLINE_P (decl)
-  && !DECL_INITIAL (decl) && !DECL_ARTIFICIAL (decl))
+  if (TREE_CODE (decl) == FUNCTION_DECL
+  && DECL_DECLARED_INLINE_P (decl)
+  && !DECL_INITIAL (decl)
+  && !DECL_ARTIFICIAL (decl)
+  && !DECL_PURE_VIRTUAL_P (decl))
 /* Remember it, so we can check it was defined.  */
 note_vague_linkage_fn (decl);
 
--- gcc/testsuite/g++.dg/warn/inline3.C.jj  2019-11-27 18:13:46.685074239 
+0100
+++ gcc/testsuite/g++.dg/warn/inline3.C 2019-11-27 18:18:40.688577837 +0100
@@ -0,0 +1,20 @@
+struct S {
+  inline virtual void foo () = 0;  // { dg-bogus "used but never defined" }
+#if __cplusplus > 201703L
+  constexpr virtual void bar () = 0;   // { dg-bogus "used but never defined" 
"" { target c++2a } }
+#else
+  inline virtual void bar () = 0;  // { dg-bogus "used but never defined" 
"" { target c++17_down }  }
+#endif
+  S () {}
+};
+struct T : public S {
+  inline virtual void foo () {}
+#if __cplusplus > 201703L
+  constexpr virtual void bar () {}
+#else
+  inline virtual void bar () {}
+#endif
+  T () {}
+};
+T t;
+void foo (S *s) { s->foo (); s->bar (); }

Jakub

[C++ PATCH] Fix up constexpr virtual calls (PR c++/92695)

[Jakub Jelinek]

Hi!

The OBJ_TYPE_REF constexpr handling looks through DECL_FIELD_IS_BASE
COMPONENT_REFs to find the actual object on which the method is called,
but as the following testcase shows, we need to do the similar thing also
for the argument passed as this, because cxx_eval_indirect_ref otherwise
fails to fold it.  It can handle going from derived to base, not not vice
versa.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2019-11-27  Jakub Jelinek  

PR c++/92695
* constexpr.c (cxx_bind_parameters_in_call): For virtual calls,
adjust the first argument to point to the derived object rather
than its base.

* g++.dg/cpp2a/constexpr-virtual14.C: New test.

--- gcc/cp/constexpr.c.jj   2019-11-27 17:26:57.229014008 +0100
+++ gcc/cp/constexpr.c  2019-11-27 17:53:37.477566346 +0100
@@ -1441,6 +1441,24 @@ cxx_bind_parameters_in_call (const const
arg = adjust_temp_type (type, arg);
  if (!TREE_CONSTANT (arg))
*non_constant_args = true;
+ /* For virtual calls, adjust the this argument, so that it is
+the object on which the method is called, rather than
+one of its bases.  */
+ if (i == 0 && DECL_VIRTUAL_P (fun))
+   {
+ tree addr = arg;
+ STRIP_NOPS (addr);
+ if (TREE_CODE (addr) == ADDR_EXPR)
+   {
+ tree obj = TREE_OPERAND (addr, 0);
+ while (TREE_CODE (obj) == COMPONENT_REF
+&& DECL_FIELD_IS_BASE (TREE_OPERAND (obj, 1)))
+   obj = TREE_OPERAND (obj, 0);
+ if (obj != TREE_OPERAND (addr, 0))
+   arg = build_fold_addr_expr_with_type (obj,
+ TREE_TYPE (arg));
+   }
+   }
  TREE_VEC_ELT (binds, i) = arg;
}
   parms = TREE_CHAIN (parms);
--- gcc/testsuite/g++.dg/cpp2a/constexpr-virtual14.C.jj 2019-11-27 
18:01:17.181532622 +0100
+++ gcc/testsuite/g++.dg/cpp2a/constexpr-virtual14.C2019-11-27 
18:00:49.620954471 +0100
@@ -0,0 +1,27 @@
+// PR c++/92695
+// { dg-do compile { target c++2a } }
+
+struct A {
+  virtual int get () = 0;
+  virtual int set (A *o) = 0;
+};
+struct B : A {
+  constexpr int get () override { return 10; }
+  constexpr int set (A *o) override { a = o; return 20; }
+  A *a {};
+};
+constexpr auto addressof = [] (A ) { return  };
+struct C {
+  B b;
+  A *c { addressof (b) };
+  constexpr int add () { return c->set (addressof (b)); }
+};
+struct D {
+  B b[2];
+  A *c { addressof (b[0]) };
+  constexpr int add () { return c->set (addressof (b[0])); }
+};
+template 
+constexpr int get () { T f; return f.add (); }
+static_assert (get () == 20);
+static_assert (get () == 20);


Jakub

Re: [C++ PATCH] c++/91353 - P1331R2: Allow trivial default init in constexpr contexts.

[Marek Polacek]

On Wed, Nov 27, 2019 at 04:47:01PM -0500, Jason Merrill wrote:
> On 11/27/19 2:36 PM, Marek Polacek wrote:
> > On Sun, Nov 24, 2019 at 12:24:48PM -0500, Jason Merrill wrote:
> > > On 11/16/19 5:23 PM, Marek Polacek wrote:
> > > > [ Working virtually on Baker Island. ]
> > > > 
> > > > This patch implements C++20 P1331, allowing trivial default 
> > > > initialization in
> > > > constexpr contexts.
> > > > 
> > > > I used Jakub's patch from the PR which allowed uninitialized variables 
> > > > in
> > > > constexpr contexts.  But the hard part was handling 
> > > > CONSTRUCTOR_NO_CLEARING
> > > > which is always cleared in cxx_eval_call_expression.  We need to set it 
> > > > in
> > > > the case a constexpr constructor doesn't initialize all the members, so 
> > > > that
> > > > we can give proper diagnostic instead of value-initializing.  A lot of 
> > > > my
> > > > attempts flopped but then I came up with this approach, which handles 
> > > > various
> > > > cases as tested in constexpr-init8.C, where S is initialized by a 
> > > > non-default
> > > > constexpr constructor, and constexpr-init9.C, using delegating 
> > > > constructors.
> > > > And the best part is that I didn't need any new 
> > > > cx_check_missing_mem_inits
> > > > calls!  Just save the information whether a constructor is missing an 
> > > > init
> > > > into constexpr_fundef_table and retrieve it when needed.
> > > 
> > > Is it necessary to clear the flag for constructors that do happen to
> > > initialize all the members?  I would think that leaving that clearing to
> > > reduced_constant_expression_p would be enough.
> > 
> > It seems so: if I tweak cxx_eval_call_expression to only call 
> > clear_no_implicit_zero
> > when 'fun' isn't DECL_CONSTRUCTOR_P, then a lot breaks, e.g. 
> > constexpr-base.C
> > where the constructor initializes all the members.  By breaking I mean 
> > spurious
> > errors coming from
> > 
> > 5937   if (TREE_CODE (r) == CONSTRUCTOR && CONSTRUCTOR_NO_CLEARING (r))
> > 5938 {
> > 5939   if (!allow_non_constant)
> > 5940 error ("%qE is not a constant expression because it refers to "
> > 5941"an incompletely initialized variable", t);
> > 5942   TREE_CONSTANT (r) = false;
> > 5943   non_constant_p = true;
> > 5944 }
> 
> Why didn't reduced_constant_expression_p unset CONSTRUCTOR_NO_CLEARING?

We have a constructor that initializes a base class and members of a class:

  {.D.2364={.i=12}, .a={.i=24}, .j=36}

Say we don't clear CONSTRUCTOR_NO_CLEARING in this ctor in 
cxx_eval_call_expression.
Then soon in reduced_constant_expression_p we do
2221 field = next_initializable_field (TYPE_FIELDS (TREE_TYPE (t)));
and since "Implement P0017R1, C++17 aggregates with bases. / r241187" we skip
base fields in C++17 so 'field' is set to 'a'.

Now we look at each element of the constructor; the first one is
D.2364={.i=12}.  But we hit

2233   if (idx != field)
2234 return false;

because field is 'a' and idx is D.2364.  Were you thinking of tweaking
reduced_constant_expression_p's behavior in C++20 and dropping the whole
cxx_eval_call_expression hunk?

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

[PATCH] Fix ICE in tree-ssa-strlen.c (PR tree-optimization/92691)

[Jakub Jelinek]

Hi!

The various routines propagate to the caller whether
  if (check_and_optimize_stmt (, _eh, evrp.get_vr_values ()))
gsi_next ();
should do gsi_next or not (return false if e.g. gsi_remove is done, thus
gsi is already moved to the next stmt).
handle_printf_call returns that too, though with the values swapped,
but since the move of handle_printf_call (then called handle_gimple_call)
from the separate sprintf pass to strlen pass, the return value is ignored,
while it must not be.  In some cases it means the following statement is not
processed by the strlen pass, which can e.g. mean wrong-code because some
strlen information is not invalidated when it should, or in other cases like
in this testcase where the sprintf call that was removed was at the end of a bb
it means an ICE, because gsi_next when gsi is already at the end of bb is
invalid.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2019-11-27  Jakub Jelinek  

PR tree-optimization/92691
* tree-ssa-strlen.c (handle_store): Clarify return value meaning
in function comment.
(strlen_check_and_optimize_call): Likewise.  For handle_printf_call
calls, return !handle_printf_call rather than always returning true.
(check_and_optimize_stmt): Describe return value meaning in function
comment.  Formatting fix.

* gcc.dg/tree-ssa/builtin-snprintf-10.c: New test.

--- gcc/tree-ssa-strlen.c.jj2019-11-22 19:11:54.901951408 +0100
+++ gcc/tree-ssa-strlen.c   2019-11-27 12:25:14.778564388 +0100
@@ -4300,7 +4300,8 @@ count_nonzero_bytes (tree exp, unsigned
 /* Handle a single or multibyte store other than by a built-in function,
either via a single character assignment or by multi-byte assignment
either via MEM_REF or via a type other than char (such as in
-   '*(int*)a = 12345').  Return true when handled.  */
+   '*(int*)a = 12345').  Return true to let the caller advance *GSI to
+   the next statement in the basic block and false otherwise.  */
 
 static bool
 handle_store (gimple_stmt_iterator *gsi, bool *zero_write, const vr_values 
*rvals)
@@ -4728,8 +4729,8 @@ is_char_type (tree type)
 }
 
 /* Check the built-in call at GSI for validity and optimize it.
-   Return true to let the caller advance *GSI to the statement
-   in the CFG and false otherwise.  */
+   Return true to let the caller advance *GSI to the next statement
+   in the basic block and false otherwise.  */
 
 static bool
 strlen_check_and_optimize_call (gimple_stmt_iterator *gsi,
@@ -4738,16 +4739,13 @@ strlen_check_and_optimize_call (gimple_s
 {
   gimple *stmt = gsi_stmt (*gsi);
 
+  /* When not optimizing we must be checking printf calls which
+ we do even for user-defined functions when they are declared
+ with attribute format.  */
   if (!flag_optimize_strlen
   || !strlen_optimize
   || !valid_builtin_call (stmt))
-{
-  /* When not optimizing we must be checking printf calls which
-we do even for user-defined functions when they are declared
-with attribute format.  */
-  handle_printf_call (gsi, rvals);
-  return true;
-}
+return !handle_printf_call (gsi, rvals);
 
   tree callee = gimple_call_fndecl (stmt);
   switch (DECL_FUNCTION_CODE (callee))
@@ -4806,7 +4804,8 @@ strlen_check_and_optimize_call (gimple_s
return false;
   break;
 default:
-  handle_printf_call (gsi, rvals);
+  if (handle_printf_call (gsi, rvals))
+   return false;
   break;
 }
 
@@ -4932,7 +4931,8 @@ handle_integral_assign (gimple_stmt_iter
 /* Attempt to check for validity of the performed access a single statement
at *GSI using string length knowledge, and to optimize it.
If the given basic block needs clean-up of EH, CLEANUP_EH is set to
-   true.  */
+   true.  Return true to let the caller advance *GSI to the next statement
+   in the basic block and false otherwise.  */
 
 static bool
 check_and_optimize_stmt (gimple_stmt_iterator *gsi, bool *cleanup_eh,
@@ -4973,32 +4973,32 @@ check_and_optimize_stmt (gimple_stmt_ite
/* Handle assignment to a character.  */
handle_integral_assign (gsi, cleanup_eh);
   else if (TREE_CODE (lhs) != SSA_NAME && !TREE_SIDE_EFFECTS (lhs))
-  {
-   tree type = TREE_TYPE (lhs);
-   if (TREE_CODE (type) == ARRAY_TYPE)
- type = TREE_TYPE (type);
-
-   bool is_char_store = is_char_type (type);
-   if (!is_char_store && TREE_CODE (lhs) == MEM_REF)
- {
-   /* To consider stores into char objects via integer types
-  other than char but not those to non-character objects,
-  determine the type of the destination rather than just
-  the type of the access.  */
-   tree ref = TREE_OPERAND (lhs, 0);
-   type = TREE_TYPE (ref);
-   if (TREE_CODE (type) == POINTER_TYPE)
- type = TREE_TYPE (type);
-   if (TREE_CODE (type) == 

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Wilco from comment #5)
> Well I'm looking at the latest version
> (https://static.docs.arm.com/ddi0487/ea/DDI0487E_a_armv8_arm.pdf) where in
> figure B2-5 it explicitly states that a store that does not match the
> reservation granule on the same CPU must not change the exclusive state.
> 
> However if a store does match the granule it is implementation defined,
> hence the reason for the text you quote to guarantee forward progress -
> otherwise a random store in the loop could accidentally match the exclusive
> granule and block progress. However I don't see it saying anywhere that all
> stores must clear the exclusive state.

That is for the global monitor which yes is depdenent on the granule.  But the
local monitor is taken into account too and you missed that. 
As mentioned in Section B2.9.2:
"For shareable memory locations, exclusive access instructions rely on:
• A local monitor for each PE in the system, that marks any address from which
the PE executes a
Load-Exclusive."

The local monitor is described in B2.9.1 and figure B2-4 which has the
following note about the local monitor state machine:
"The IMPLEMENTATION DEFINED options for the local monitor are consistent with
the local monitor being
constructed so that it does not hold any PA, but instead treats any access as
matching the address of the
previous Load-Exclusive instruction."

Re: Branch and tag deletions

[Joseph Myers]

On Tue, 26 Nov 2019, Eric S. Raymond wrote:

> Joseph Myers :
> > A further note: in a previous run of the conversion I didn't see any 
> > emptycommit-* tags.  In my most recent conversion run, I see 4070 such 
> > tags.  How do I tell reposurgeon never to create such tags?  Or should I 
> > add a tag deletion command for them in gcc.lift, once tag deletion is 
> > working reliably?
> 
> That's what tag deletion by regexp is for.

One more observation on that: in my last test conversion, deleting the 
emptycommit-* tags took over 7 hours (i.e. the bulk of the time for the 
conversion was spent just deleting those tags).  Deleting tags matching 
/-root$/ took about half an hour.  So I think there is a performance issue 
somewhere with (some cases of) tag deletion by regexp, at least when the 
regexp matches a large number of tags (but some other bulk deletions seem 
to run much quicker per tag).  Taking a few seconds per tag is fine for an 
individual deletion, but a problem when you want to delete 4070 tags at 
once.

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

[Bug fortran/92701] ICE assigning to assumed rank derived type component

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-27
 CC||burnus at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Tobias Burnus  ---
No regression as 'select rank' is new.

In gfc_check_vardef_context, assoc->variable == NULL and
assoc->target == NULL  [this one causes the segfault] and
assoc->st->name == "__tmp_class___class_a_R_15_0t_rank_1"

On the other hand, e->symtree->n.sym->assoc->target exists and
e->symtree->n.sym->assoc->target->symtree == assoc->st.

assoc gets set (ll. 6213–6219) as:
  gfc_expr* t = sym->assoc->target;
  gcc_assert (t->expr_type == EXPR_VARIABLE);
  name = t->symtree->name;
  if (t->symtree->n.sym->assoc)
assoc = t->symtree->n.sym->assoc;
  else
assoc = sym->assoc;
That's sufficient for:
  gcc_assert (name && assoc);
But then it fails when doing:
  assoc->target->expr_type
(That's for !assoc->variable – but also the else branch assumes that
assoc->target != NULL.)

[analyzer] Convert from "--analyzer" to "-fanalyzer"/"-fno-analyzer"

[David Malcolm]

This patch updates the command-line option used to enable the analyzer
from "--analyzer" to "-fanalyzer" (--analyzer is still accepted, via
the map from prefix "--" to "-f" in option_map in opts-common.c)

The patch also adds support for -fno-analyzer: given uses of -fno-analyzer
and -fanalyzer, the last one used on the command line "wins".

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

Pushed to branch "dmalcolm/analyzer" on the GCC git mirror.

gcc/ChangeLog:
* analyzer/Make-plugin.in (ANALYZER_SELFTEST_FLAGS): Replace
"--analyzer" with "-fanalyzer".
* common.opt (-analyzer): Replace with..
(fanalyzer): ...this.
* doc/invoke.texi: Replace "--analyzer" with "-fanalyzer" throughout.
Add -fno-analyzer to index.
* gcc.c (driver_handle_option): Handle -fanalyzer by simplying
updating flag_analyzer, moving the injection of the plugin to:
(process_command): ...here.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/analyzer.exp: Replace "--analyzer" with
"-fanalyzer".
* gcc.dg/analyzer/disabling.c: New test.
* gcc.dg/analyzer/malloc-dce.c: Replace "dg-options" with
"dg-additional-options", dropping usage of "-fanalyzer".
* gcc.dg/analyzer/malloc-ipa-8-double-free.c: Replace "dg-options"
with "dg-additional-options", dropping usage of "-fanalyzer".  Add
"-fdiagnostics-path-format=inline-events".
* gcc.dg/analyzer/malloc-ipa-8-unchecked.c: Replace "dg-options"
with "dg-additional-options", dropping usage of "-fanalyzer".
* gcc.dg/analyzer/malloc-ipa-9.c: Likewise.
* gcc.dg/analyzer/malloc-macro-inline-events.c: Likewise.
* gcc.dg/analyzer/malloc-macro-separate-events.c: Likewise.
* lib/target-supports.exp
(check_effective_target_lto_incremental): Replace "--analyzer"
with "-fanalyzer".
---
 gcc/analyzer/Make-plugin.in   |  2 +-
 gcc/common.opt|  6 +--
 gcc/doc/invoke.texi   | 38 ++-
 gcc/gcc.c | 25 ++--
 gcc/testsuite/gcc.dg/analyzer/analyzer.exp|  2 +-
 gcc/testsuite/gcc.dg/analyzer/disabling.c | 10 +
 gcc/testsuite/gcc.dg/analyzer/malloc-dce.c|  2 +-
 .../analyzer/malloc-ipa-8-double-free.c   |  2 +-
 .../gcc.dg/analyzer/malloc-ipa-8-unchecked.c  |  2 +-
 gcc/testsuite/gcc.dg/analyzer/malloc-ipa-9.c  |  2 +-
 .../analyzer/malloc-macro-inline-events.c |  2 +-
 .../analyzer/malloc-macro-separate-events.c   |  2 +-
 gcc/testsuite/lib/target-supports.exp |  2 +-
 13 files changed, 54 insertions(+), 43 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/disabling.c

diff --git a/gcc/analyzer/Make-plugin.in b/gcc/analyzer/Make-plugin.in
index 08c96f12203e..08f58f467a2a 100644
--- a/gcc/analyzer/Make-plugin.in
+++ b/gcc/analyzer/Make-plugin.in
@@ -105,7 +105,7 @@ $(ANALYZER_PLUGIN_SO): $(analyzer_OBJS) $(plugin_builddir)
 # at each stage of the build:
 selftest-analyzer: s-selftest-analyzer
 
-ANALYZER_SELFTEST_FLAGS = -xc $(SELFTEST_FLAGS) --analyzer
+ANALYZER_SELFTEST_FLAGS = -xc $(SELFTEST_FLAGS) -fanalyzer
 ANALYZER_SELFTEST_DEPS = cc1$(exeext) $(SELFTEST_DEPS) $(ANALYZER_PLUGIN_SO)
 
 # Run the analyzer selftests:
diff --git a/gcc/common.opt b/gcc/common.opt
index 3f6de9629899..840e9f435657 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -266,9 +266,6 @@ Driver Joined Alias(e)
 -extra-warnings
 Common Warning Alias(Wextra)
 
--analyzer
-Driver Var(analyzer_flag)
-
 -for-assembler
 Driver Separate Alias(Xassembler)
 
@@ -992,6 +989,9 @@ fallow-store-data-races
 Common Report Var(flag_store_data_races) Optimization
 Allow the compiler to introduce new data races on stores.
 
+fanalyzer
+Driver Var(flag_analyzer)
+
 fargument-alias
 Common Ignore
 Does nothing. Preserved for backward compatibility.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index caeb9ce30f53..286c1623aaa7 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -289,7 +289,7 @@ Objective-C and Objective-C++ Dialects}.
 
 @item Warning Options
 @xref{Warning Options,,Options to Request or Suppress Warnings}.
-@gccoptlist{--analyzer -fsyntax-only  -fmax-errors=@var{n}  -Wpedantic @gol
+@gccoptlist{-fanalyzer -fsyntax-only  -fmax-errors=@var{n}  -Wpedantic @gol
 -pedantic-errors @gol
 -w  -Wextra  -Wall  -Waddress  -Waddress-of-packed-member @gol
 -Waggregate-return  -Waligned-new @gol
@@ -6428,7 +6428,7 @@ equivalent to 
@option{-Walloca-larger-than=}@samp{SIZE_MAX} or larger.
 @item -Wno-analyzer-double-fclose
 @opindex Wanalyzer-double-fclose
 @opindex Wno-analyzer-double-fclose
-This warning requires @option{--analyzer}, which enables it; use
+This warning requires @option{-fanalyzer}, which enables it; use
 @option{-Wno-analyzer-double-fclose} to disable it.
 
 This diagnostic warns for paths through the code in which a @code{FILE *}
@@ -6437,7 

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

[wilco at gcc dot gnu.org]

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

--- Comment #5 from Wilco  ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Wilco from comment #3)
> > (In reply to Andrew Pinski from comment #2)
> > > I think this has been a latent bug since revision 243200:
> > > [AArch64] Separate shrink wrapping hooks implementation
> > > 
> > > I think aarch64_disqualify_components would be a location which should
> > > disqualify the Separate for the register 19.
> > 
> > What is the "exclusives reservation granule" size? It could only fail if the
> > granule is large and the spill happens to be in the same granule as the 
> > stxr.
> NO "exclusives reservation granule" does not matter here, please read the
> ARMv8 spec again copied below (B2-142):
> LoadExcl/StoreExcl loops are guaranteed to make forward progress only if,
> for any LoadExcl/StoreExcl loop
> within a single thread of execution, the software meets all of the following
> conditions:
> 1 Between the Load-Exclusive and the Store-Exclusive, there are no
> explicit memory accesses,
> preloads, direct or indirect System register writes, address translation
> instructions, cache or TLB
> maintenance instructions, exception generating instructions, exception
> returns, or indirect branches.
> --- CUT 
> 
> no explicit memory accesses
> Is a requirement so it does not matter what "exclusives reservation granule"
> size is really.
> We had gone through this beforehand with the ARM architectures and made sure
> that the specifications was worded correctly to the above effect.  The
> wording change happened in 2016.

Well I'm looking at the latest version
(https://static.docs.arm.com/ddi0487/ea/DDI0487E_a_armv8_arm.pdf) where in
figure B2-5 it explicitly states that a store that does not match the
reservation granule on the same CPU must not change the exclusive state.

However if a store does match the granule it is implementation defined, hence
the reason for the text you quote to guarantee forward progress - otherwise a
random store in the loop could accidentally match the exclusive granule and
block progress. However I don't see it saying anywhere that all stores must
clear the exclusive state.

[wwwdocs] Make the formatting of the tag and block more uniform.

[Gerald Pfeifer]

This is not a functional change at all (or at least should not be).

Rather this will ease automatic processing as we include even more 
of what is currently coming from style.mhtml and reduce the chance 
of missing some files or changes over time.

Committed.

Gerald


commit cfa6e237e33dfad556618251869bf7d519e32a40
Author: Gerald Pfeifer 
Date:   Wed Nov 27 15:46:26 2019 +0100

Make the formatting of the  tag and block more uniform.

This will ease automatic processing as we include even more of what
is currently coming from style.mhtmland reduce the chance of missing
some files or changes over time.

diff --git a/htdocs/bzkanban/index.html b/htdocs/bzkanban/index.html
index ba3c23b..aa651f4 100644
--- a/htdocs/bzkanban/index.html
+++ b/htdocs/bzkanban/index.html
@@ -1,10 +1,10 @@
 
 
 
-
-Bz Kanban Board
+
+Bz Kanban Board
 https://gcc.gnu.org/gcc.css; />
-https://maxcdn.bootstrapcdn.com/font-awesome/4.4.0/css/font-awesome.min.css;>
+https://maxcdn.bootstrapcdn.com/font-awesome/4.4.0/css/font-awesome.min.css;>
 
 
 body {
@@ -144,7 +144,8 @@
 /* display: none; */
 }
 
-
+
+
 
 
 
diff --git a/htdocs/gcc-3.2/c++-abi.html b/htdocs/gcc-3.2/c++-abi.html
index 555beb9..3c9a09f 100644
--- a/htdocs/gcc-3.2/c++-abi.html
+++ b/htdocs/gcc-3.2/c++-abi.html
@@ -1,9 +1,10 @@
 
 
-  
-A Common C++ ABI for GNU/Linux
+
+
+A Common C++ ABI for GNU/Linux
 https://gcc.gnu.org/gcc.css; />
-  
+
 
   
 A Common C++ ABI for GNU/Linux
diff --git a/htdocs/projects/cxx0x.html b/htdocs/projects/cxx0x.html
index bd6c9bd..ef41d64 100644
--- a/htdocs/projects/cxx0x.html
+++ b/htdocs/projects/cxx0x.html
@@ -1,15 +1,16 @@
 
 
-   
-
+
+
+
 
-
-  window.location.href = "cxx-status.html#cxx11"
-
+
+  window.location.href = "cxx-status.html#cxx11"
+
 
-Page Redirection
+Page Redirection
 https://gcc.gnu.org/gcc.css; />
-  
+
 
   
 This page has been incorporated into another.  If you are not redirected
diff --git a/htdocs/projects/cxx1y.html b/htdocs/projects/cxx1y.html
index e9236b6..ef85126 100644
--- a/htdocs/projects/cxx1y.html
+++ b/htdocs/projects/cxx1y.html
@@ -1,15 +1,16 @@
 
 
-   
-
+
+
+
 
-
-  window.location.href = "cxx-status.html#cxx14"
-
+
+  window.location.href = "cxx-status.html#cxx14"
+
 
-Page Redirection
+Page Redirection
 https://gcc.gnu.org/gcc.css; />
-  
+
 
   
 This page has been incorporated into another.  If you are not redirected
diff --git a/htdocs/projects/strees/index.html 
b/htdocs/projects/strees/index.html
index 044f6f3..90523da 100644
--- a/htdocs/projects/strees/index.html
+++ b/htdocs/projects/strees/index.html
@@ -1,7 +1,11 @@
 
 
-Stree design notes
-https://gcc.gnu.org/gcc.css; 
/>
+
+
+Stree design notes
+https://gcc.gnu.org/gcc.css; />
+
+
 
 
 Stree design notes
diff --git a/htdocs/projects/tree-ssa/tree-browser.html 
b/htdocs/projects/tree-ssa/tree-browser.html
index 94ffdd0..4e06662 100644
--- a/htdocs/projects/tree-ssa/tree-browser.html
+++ b/htdocs/projects/tree-ssa/tree-browser.html
@@ -1,9 +1,10 @@
 
 
-  
-Tree Browser
+
+
+Tree Browser
 https://gcc.gnu.org/gcc.css; />
-  
+
   
   
 Tree Browser
diff --git a/htdocs/simtest-howto.html b/htdocs/simtest-howto.html
index 0d8fc49..e1a6381 100644
--- a/htdocs/simtest-howto.html
+++ b/htdocs/simtest-howto.html
@@ -1,9 +1,10 @@
 
 
-  
-How to test GCC on a simulator
+
+
+How to test GCC on a simulator
 https://gcc.gnu.org/gcc.css; />
-  
+
 
   
 How to test GCC on a simulator

---

Summary of changes:
 htdocs/bzkanban/index.html |9 +
 htdocs/gcc-3.2/c++-abi.html|7 ---
 htdocs/projects/cxx0x.html |   15 ---
 htdocs/projects/cxx1y.html |   15 ---
 htdocs/projects/strees/index.html  |8 ++--
 htdocs/projects/tree-ssa/tree-browser.html |7 ---
 htdocs/simtest-howto.html  |7 ---
 7 files changed, 39 insertions(+), 29 deletions(-)

[Bug rtl-optimization/90007] [9/10 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

[vmakarov at gcc dot gnu.org]

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

--- Comment #14 from Vladimir Makarov  ---
(In reply to Segher Boessenkool from comment #13)
> Does that work?  You cannot put all hard registers in memory I think?
> Or do we require that and it is just not documented?

It depends on insns.  For example, if insn only requires memory operand but we
have hard register instead, we spill it into memory.

Generally speaking I think we can "invent" an architecture where such feature
may result in problems.  But the same possible for other aspects of LRA/reload
work.

In practice, I believe it is not a problem for real architectures.

Re: Prevent all uses of DFP when unsupported (PR c/91985)

[Joseph Myers]

On Wed, 27 Nov 2019, Thomas Schwinge wrote:

> If I turn that conditional cited above into 'if (1)', then nvptx
> offloading testing seems to return to normality, but I have not yet
> assessed whether that has any ill effects on decimal float types support,
> and/or how this should be fixed properly.  (Julian, please have a look,
> if you can, or tell me if you're busy with other things.)

Whatever allows this to work for _FloatN types (when x86_64 supports 
_Float128 but nxptx doesn't, for example) should be applied to the DFP 
types as well.

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

[Bug fortran/92701] New: ICE assigning to assumed rank derived type component

[abensonca at gmail dot com]

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

Bug ID: 92701
   Summary: ICE assigning to assumed rank derived type component
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following code causes an ICE with gfortran 10.0 (r278783):

module a

  type :: r
  end type r

  type, extends(r) :: rr
 double precision:: d
  end type rr 

contains

  subroutine abd(p)
implicit none
class(r), intent(inout), dimension(..) :: p
double precision, dimension(:), allocatable :: d
select rank (p)
rank (1)
   select type (p)
   type is (rr)
  allocate(d(size(p,dim=1)))
  d=0.0d0
  p%d=d
   end select
end select
return
  end subroutine abd

end module a

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib : (reconfigured)
../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--disable-multilib --enable-languages=c,c++,fortran,lto --no-create
--no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20191127 (experimental) (GCC) 


$ gfortran -c bug.F90 -o bug.o
f951: internal compiler error: Segmentation fault
0xdd4adf crash_signal
../../gcc-trunk/gcc/toplev.c:328
0x7fa79dd101ef ???
   
/data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7d41a1 gfc_check_vardef_context(gfc_expr*, bool, bool, bool, char const*)
../../gcc-trunk/gcc/fortran/expr.c:6237
0x84cff7 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:11768
0x8508b7 resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:17180
0x83c2ce gfc_resolve(gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:17215
0x83c2ce gfc_resolve(gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:17194
0x84cc58 resolve_block_construct
../../gcc-trunk/gcc/fortran/resolve.c:10549
0x84cc58 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:11899
0x84ef43 gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:10691
0x84fa0b resolve_select_type
../../gcc-trunk/gcc/fortran/resolve.c:9544
0x84cbe1 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:11891
0x84ef43 gfc_resolve_blocks(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:10691
0x84c3b8 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:11654
0x8508b7 resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:17180
0x8507ee resolve_codes
../../gcc-trunk/gcc/fortran/resolve.c:17163
0x83c2ce gfc_resolve(gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:17215
0x83c2ce gfc_resolve(gfc_namespace*)
../../gcc-trunk/gcc/fortran/resolve.c:17194
0x82f078 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6443
0x87f30f gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:210
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.



The ICE seems to be triggered by the "p%d=d" assignment.

Re: C++ PATCH for c++/91363 - P0960R3: Parenthesized initialization of aggregates

[Marek Polacek]

On Wed, Nov 27, 2019 at 04:54:55PM -0500, Jason Merrill wrote:
> > > > @@ -921,8 +921,20 @@ perform_member_init (tree member, tree init)
> > > > inform (DECL_SOURCE_LOCATION (member),
> > > > "%q#D should be initialized", member );
> > > > }
> > > > - finish_expr_stmt (build_aggr_init (decl, init, flags,
> > > > -tf_warning_or_error));
> > > > + init = build_aggr_init (decl, init, flags, 
> > > > tf_warning_or_error);
> > > > + /* In C++20, a member initializer list can be initializing an
> > > > +aggregate from a parenthesized list of values:
> > > > +
> > > > +  struct S {
> > > > +A aggr;
> > > > +S() : aggr(1, 2, 3) { }
> > > > +  };
> > > > +
> > > > + In such case, build_aggr_init will build up an INIT_EXPR 
> > > > like
> > > > + we do for aggr{1, 2, 3}, so that 
> > > > build_data_member_initialization
> > > > + can grok it.  */
> > > > + if (TREE_CODE (init) != INIT_EXPR)
> > > > +   finish_expr_stmt (init);
> > > 
> > > Why don't we want to finish_expr_stmt an INIT_EXPR?
> > 
> > Because expand_default_init has already finish_expr_stmt-ed it.  Adding it
> > twice sounds wrong.
> 
> But the finish_expr_stmt in expand_default_init is inside the STATEMENT_LIST
> we pushed into in build_aggr_init.  If finish_init_stmts returned the
> INIT_EXPR, we still need to add it to the enclosing STATEMENT_LIST.

I don't understand why none of my tests broke but here's a patch with that if
removed:

dg.exp passed, bootstrap/regtest running.

2019-11-27  Marek Polacek  

PR c++/91363 - P0960R3: Parenthesized initialization of aggregates.
* c-cppbuiltin.c (c_cpp_builtins): Predefine
__cpp_aggregate_paren_init=201902 for -std=c++2a.

* call.c (build_new_method_call_1): Handle parenthesized initialization
of aggregates by building up a CONSTRUCTOR.
(extend_ref_init_temps): Do nothing for CONSTRUCTOR_IS_PAREN_INIT.
* cp-tree.h (CONSTRUCTOR_IS_PAREN_INIT, LOOKUP_AGGREGATE_PAREN_INIT):
Define.
* decl.c (grok_reference_init): Handle aggregate initialization from
a parenthesized list of values.
(reshape_init): Do nothing for CONSTRUCTOR_IS_PAREN_INIT.
(check_initializer): Handle initialization of an array from a
parenthesized list of values.  Use NULL_TREE instead of NULL.
* init.c (expand_default_init): Set LOOKUP_AGGREGATE_PAREN_INIT for the
build_special_member_call call.  If it returns a
BRACE_ENCLOSED_INITIALIZER_P, call digest_init and build an INIT_EXPR.
Set TREE_SIDE_EFFECTS on it.
* tree.c (build_cplus_new): Handle BRACE_ENCLOSED_INITIALIZER_P.
* typeck2.c (digest_init_r): Set LOOKUP_AGGREGATE_PAREN_INIT if it
receives a CONSTRUCTOR with CONSTRUCTOR_IS_PAREN_INIT set.  Allow
narrowing when LOOKUP_AGGREGATE_PAREN_INIT.
(massage_init_elt): Don't lose LOOKUP_AGGREGATE_PAREN_INIT when passing
flags to digest_init_r.

* g++.dg/cpp0x/constexpr-99.C: Only expect an error in C++17 and
lesser.
* g++.dg/cpp0x/explicit7.C: Likewise.
* g++.dg/cpp0x/initlist12.C: Adjust dg-error.
* g++.dg/cpp0x/pr31437.C: Likewise.
* g++.dg/cpp2a/feat-cxx2a.C: Add __cpp_aggregate_paren_init test.
* g++.dg/cpp2a/paren-init1.C: New test.
* g++.dg/cpp2a/paren-init10.C: New test.
* g++.dg/cpp2a/paren-init11.C: New test.
* g++.dg/cpp2a/paren-init12.C: New test.
* g++.dg/cpp2a/paren-init13.C: New test.
* g++.dg/cpp2a/paren-init14.C: New test.
* g++.dg/cpp2a/paren-init15.C: New test.
* g++.dg/cpp2a/paren-init16.C: New test.
* g++.dg/cpp2a/paren-init17.C: New test.
* g++.dg/cpp2a/paren-init18.C: New test.
* g++.dg/cpp2a/paren-init2.C: New test.
* g++.dg/cpp2a/paren-init3.C: New test.
* g++.dg/cpp2a/paren-init4.C: New test.
* g++.dg/cpp2a/paren-init5.C: New test.
* g++.dg/cpp2a/paren-init6.C: New test.
* g++.dg/cpp2a/paren-init7.C: New test.
* g++.dg/cpp2a/paren-init8.C: New test.
* g++.dg/cpp2a/paren-init9.C: New test.
* g++.dg/ext/desig10.C: Adjust dg-error.
* g++.dg/template/crash107.C: Likewise.
* g++.dg/template/crash95.C: Likewise.
* g++.old-deja/g++.jason/crash3.C: Only expect an error in C++17 and
lesser.
* g++.old-deja/g++.law/ctors11.C: Likewise.
* g++.old-deja/g++.law/ctors9.C: Likewise.
* g++.old-deja/g++.mike/net22.C: Likewise.
* g++.old-deja/g++.niklas/t128.C: Likewise.

diff --git gcc/c-family/c-cppbuiltin.c gcc/c-family/c-cppbuiltin.c
index 50066e4dd8b..2f30b2a3235 100644
--- gcc/c-family/c-cppbuiltin.c
+++ gcc/c-family/c-cppbuiltin.c
@@ -1004,6 +1004,7 @@ 

[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill  ---
Author: jason
Date: Wed Nov 27 22:05:41 2019
New Revision: 278784

URL: https://gcc.gnu.org/viewcvs?rev=278784=gcc=rev
Log:
PR c++/92206 - ICE with typedef to dependent alias.

rsandifo's patch for 92206 demonstrated a problem with the existing checking
for alias template specializations: they were returning false for a typedef
to an alias template specialization.  Which is sometimes what the caller
wants, and sometimes not: Sometimes we're interested in whether the type was
written as an alias template-id, and sometimes whether it represents one.

The testcase illustrates a case that remained wrong with the earlier patch:
if the typedef is itself an alias template specialization, we can't strip an
underlying dependent alias.

* pt.c (dependent_alias_template_spec_p)
(alias_template_specialization_p): Add transparent_typedefs
parameter.
(iterative_hash_template_arg, any_template_parm_r)
(primary_template_specialization_p, tsubst, dependent_type_p_r):
Adjust.
* decl.c (check_elaborated_type_specifier): Adjust.
* error.c (dump_template_bindings, dump_aggr_type): Adjust.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-pr92206-4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/error.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck.c

Re: [C++ PATCH] Implement C++20 P1814R0, CTAD for alias templates.

[Jason Merrill]

On 11/16/19 5:51 PM, Jason Merrill wrote:
This patch implements C++20 class template argument deduction for alias 
templates, which works by a moderately arcane transformation of the 
deduction guides for the underlying class template.  When implementing 
it, I found that I could simplify the rules in the draft a bit and get 
the same effect; I'll be emailing the committee to that effect soon.


While working on this I ran into various shortcomings in our handling of 
constrained alias templates (like B in the testcase), and fixed those in 
a separate patch.


Tested x86_64-pc-linux-gnu.  I'm going to clean this up a bit more 
before checking it in, but am sending this functional patch now before 
the end of stage 1.


Here's what I'm checking in now:


commit f68b1a418b7b8b294bd274a3028dd4fd6c5e367d
Author: Jason Merrill 
Date:   Sat Nov 16 15:43:07 2019 -0500

Fix constrained alias template transparency.

A constrained alias template can't be treated as equivalent to its
underlying template/type for much the same reason that an alias template
like void_t can't; we're relying on checking during substitution.

* cxx-pretty-print.c (pp_cxx_unqualified_id): Handle alias
template-id.
* pt.c (complex_alias_template_p): True if constraints.
(get_underlying_template, tsubst): Check alias constraints.
(push_template_decl_real): Set alias constraints here.
* parser.c (cp_parser_alias_declaration): Not here.
* constraint.cc (get_constraints): Take const_tree.

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index d8e12e99ba3..fd3be60d407 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7772,7 +7772,8 @@ extern cp_expr finish_constraint_and_expr	(location_t, cp_expr, cp_expr);
 extern cp_expr finish_constraint_primary_expr	(cp_expr);
 extern tree finish_concept_definition		(cp_expr, tree);
 extern tree combine_constraint_expressions  (tree, tree);
-extern tree get_constraints (tree);
+extern tree append_constraint			(tree, tree);
+extern tree get_constraints (const_tree);
 extern void set_constraints (tree, tree);
 extern void remove_constraints  (tree);
 extern tree current_template_constraints	(void);
@@ -7834,6 +7835,7 @@ extern bool subsumes_constraints(tree, tree);
 extern bool strictly_subsumes			(tree, tree, tree);
 extern bool weakly_subsumes			(tree, tree, tree);
 extern int more_constrained (tree, tree);
+extern bool at_least_as_constrained (tree, tree);
 extern bool constraints_equivalent_p(tree, tree);
 extern bool atomic_constraints_identical_p	(tree, tree);
 extern hashval_t iterative_hash_constraint  (tree, hashval_t);
diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index fadbe7c8ac0..0d1c27a6d16 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -1124,7 +1124,7 @@ static GTY ((cache)) decl_tree_cache_map *decl_constraints;
constrained, return NULL_TREE. Note that T must be non-null. */
 
 tree
-get_constraints (tree t)
+get_constraints (const_tree t)
 {
   if (!flag_concepts)
 return NULL_TREE;
@@ -1134,7 +1134,7 @@ get_constraints (tree t)
   gcc_assert (DECL_P (t));
   if (TREE_CODE (t) == TEMPLATE_DECL)
 t = DECL_TEMPLATE_RESULT (t);
-  tree* found = decl_constraints->get (t);
+  tree* found = decl_constraints->get (CONST_CAST_TREE (t));
   if (found)
 return *found;
   else
@@ -2966,6 +2966,17 @@ more_constrained (tree d1, tree d2)
   return winner;
 }
 
+/* Return whether D1 is at least as constrained as D2.  */
+
+bool
+at_least_as_constrained (tree d1, tree d2)
+{
+  tree n1 = get_normalized_constraints_from_decl (d1);
+  tree n2 = get_normalized_constraints_from_decl (d2);
+
+  return subsumes (n1, n2);
+}
+
 /*---
 Constraint diagnostics
 ---*/
diff --git a/gcc/cp/cxx-pretty-print.c b/gcc/cp/cxx-pretty-print.c
index 8ece11d276e..909b2a4ef1d 100644
--- a/gcc/cp/cxx-pretty-print.c
+++ b/gcc/cp/cxx-pretty-print.c
@@ -172,11 +172,11 @@ pp_cxx_unqualified_id (cxx_pretty_printer *pp, tree t)
 case TYPENAME_TYPE:
 case UNBOUND_CLASS_TEMPLATE:
   pp_cxx_unqualified_id (pp, TYPE_NAME (t));
-  if (CLASS_TYPE_P (t) && CLASSTYPE_USE_TEMPLATE (t))
+  if (tree ti = TYPE_TEMPLATE_INFO_MAYBE_ALIAS (t))
 	{
 	  pp_cxx_begin_template_argument_list (pp);
-	  pp_cxx_template_argument_list (pp, INNERMOST_TEMPLATE_ARGS
- (CLASSTYPE_TI_ARGS (t)));
+	  tree args = INNERMOST_TEMPLATE_ARGS (TI_ARGS (ti));
+	  pp_cxx_template_argument_list (pp, args);
 	  pp_cxx_end_template_argument_list (pp);
 	}
   break;
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 27318d3aeed..c08b7b32a32 

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Wilco from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > I think this has been a latent bug since revision 243200:
> > [AArch64] Separate shrink wrapping hooks implementation
> > 
> > I think aarch64_disqualify_components would be a location which should
> > disqualify the Separate for the register 19.
> 
> What is the "exclusives reservation granule" size? It could only fail if the
> granule is large and the spill happens to be in the same granule as the stxr.
NO "exclusives reservation granule" does not matter here, please read the ARMv8
spec again copied below (B2-142):
LoadExcl/StoreExcl loops are guaranteed to make forward progress only if, for
any LoadExcl/StoreExcl loop
within a single thread of execution, the software meets all of the following
conditions:
1 Between the Load-Exclusive and the Store-Exclusive, there are no explicit
memory accesses,
preloads, direct or indirect System register writes, address translation
instructions, cache or TLB
maintenance instructions, exception generating instructions, exception returns,
or indirect branches.
--- CUT 

no explicit memory accesses
Is a requirement so it does not matter what "exclusives reservation granule"
size is really.
We had gone through this beforehand with the ARM architectures and made sure
that the specifications was worded correctly to the above effect.  The wording
change happened in 2016.

Re: C++ PATCH for c++/91363 - P0960R3: Parenthesized initialization of aggregates

[Jason Merrill]

On 11/27/19 1:58 PM, Marek Polacek wrote:

On Wed, Nov 20, 2019 at 08:11:27PM -0500, Jason Merrill wrote:

On 11/20/19 8:37 PM, Marek Polacek wrote:

On Tue, Nov 19, 2019 at 05:33:09PM -0500, Jason Merrill wrote:

On 11/19/19 1:44 AM, Marek Polacek wrote:

It also looks like you're using the LOOKUP flag to mean two different
things:

1) try to treat parenthesized args as an aggregate initializer
(build_new_method_call_1)
2) treat this CONSTRUCTOR as coming from parenthesized args
(store_init_value/digest_init)


Correct.


Why is the flag needed for #1?  When do we not want to try to treat the args
as an aggregate initializer?


There are cases where treating the args as an aggregate initializer causes
spurious overload resolution successes, e.g.

void swap(int&, int&);

int& get();

struct pair {
  void swap(pair&) noexcept(noexcept(swap(get(), get( { } // { dg-error "no 
matching function for call" }
};

There are no viable candidates for pair::swap (# of args mismatch) but since
pair is an aggregate, build_new_method_call_1 would return a CONSTRUCTOR so
overload resolution would succeed.  Another case had to do with SFINAE and
decltype where we didn't evaluate the arg, but succeeding in the
no-viable-function case caused the compiler to choose the wrong function.


Hmm, but then the parenthesized list is arguments for swap, not an
initializer for a single argument of swap.  That would be using it for
copy-initialization, and we only want to treat parenthesized args as an
aggregate initializer in direct-initialization.  Can we check for
direct-init (i.e. !LOOKUP_ONLYCONVERTING) instead?


Unfortunately that doesn't work.  We call build_new_method_call from context
where LOOKUP_ONLYCONVERTING isn't set and so it would still break things.


How so?  If we call it for a constructor, surely we can check that flag to
distinguish between copy- and direct-initialization, or I'd expect wrong
behavior wrt explicit.


[ Sorry for the delayed response, been too busy with other stuff.  Hope to be
more prompt from now on. ]

Indeed, if I check DECL_CONSTRUCTOR_P, it works.  But I was confused by a test
like the newly-added paren-init17.C.  Here we're checking if A can be trivially
initialized by B, so constructible_expr builds up a build_stub_object object
and calls build_special_member_call.  It doesn't find a viable constructor for
A, but A is an aggregate and there are arguments, so it does parenthesized
initialization, and then we think A can be trivially initialized from B.  But
I don't think we should attempt to handle this case.  I also saw a similar
problem with decltype/declval.  Fixed by checking cp_unevaluated_operand...

Another difference is that g++.old-deja/g++.jason/crash3.C now passes in
C++20.  But that should be fine.


+  if (BRACE_ENCLOSED_INITIALIZER_P (exp))
+{
+  gcc_assert (cxx_dialect >= cxx2a);
+  return finish_compound_literal (type, exp, complain,
+ fcl_functional_paren);
+}


How about handling this in build_cplus_new instead of places that also call
build_cplus_new?


Is it really what we want?  We now have two spots where we need to handle
the case when build_special_member_call returns a BRACE_ENCLOSED_INITIALIZER_P
but build_cplus_new is called in many other spots where we don't expect to see
a CONSTRUCTOR.


I think build_cplus_new should be able to handle whatever
build_special_member_call returns.


Ok, adjusted.


@@ -921,8 +921,20 @@ perform_member_init (tree member, tree init)
inform (DECL_SOURCE_LOCATION (member),
"%q#D should be initialized", member );
}
- finish_expr_stmt (build_aggr_init (decl, init, flags,
-tf_warning_or_error));
+ init = build_aggr_init (decl, init, flags, tf_warning_or_error);
+ /* In C++20, a member initializer list can be initializing an
+aggregate from a parenthesized list of values:
+
+  struct S {
+A aggr;
+S() : aggr(1, 2, 3) { }
+  };
+
+ In such case, build_aggr_init will build up an INIT_EXPR like
+ we do for aggr{1, 2, 3}, so that build_data_member_initialization
+ can grok it.  */
+ if (TREE_CODE (init) != INIT_EXPR)
+   finish_expr_stmt (init);


Why don't we want to finish_expr_stmt an INIT_EXPR?


Because expand_default_init has already finish_expr_stmt-ed it.  Adding it
twice sounds wrong.


But the finish_expr_stmt in expand_default_init is inside the 
STATEMENT_LIST we pushed into in build_aggr_init.  If finish_init_stmts 
returned the INIT_EXPR, we still need to add it to the enclosing 
STATEMENT_LIST.



@@ -1272,8 +1274,13 @@ digest_init_r (tree type, tree init, int nested, int 
flags,
inform (loc, "remove %<{ }%> around initializer");
}
  else if (flag_checking)
-   /* We should 

Re: Prevent all uses of DFP when unsupported (PR c/91985)

[Thomas Schwinge]

Hi!

Re , which reports
(and I hereby confirm) that these changes quoted below introduce "lto1:
internal compiler error" for (at least) nvptx offloading, and such a
backtrace seemed vaguely familiar, and I did remember having fixed a
similar issue before, and indeed it seems to be another instance of such
a problem.  In particular, and assuming that I'm understanding this
correctly, the following part of the changes (for brevity formatted with
'diff --ignore-space-change'):

--- gcc/tree.c
+++ gcc/tree.c
@@ -10334,6 +10334,8 @@ build_common_tree_nodes (bool signed_char)
   uint64_type_node = make_or_reuse_type (64, 1);
 
   /* Decimal float types. */
+  if (targetm.decimal_float_supported_p ())
+{
   dfloat32_type_node = make_node (REAL_TYPE);
   TYPE_PRECISION (dfloat32_type_node) = DECIMAL32_TYPE_SIZE;
   SET_TYPE_MODE (dfloat32_type_node, SDmode);
@@ -10351,6 +10353,7 @@ build_common_tree_nodes (bool signed_char)
   SET_TYPE_MODE (dfloat128_type_node, TDmode);
   layout_type (dfloat128_type_node);
   dfloat128_ptr_type_node = build_pointer_type (dfloat128_type_node);
+}
 
   complex_integer_type_node = build_complex_type (integer_type_node, true);
   complex_float_type_node = build_complex_type (float_type_node, true);

... does introduce a mismatch in the 'preload_common_nodes' between
target (for example, x86_64-pc-linux-gnu with
'targetm.decimal_float_supported_p'), and the offload target (for
example, nvptx-none without 'targetm.decimal_float_supported_p'), and
then LTO read-in explodes because the codes are then offset between
producer (target) and consumer (offload target).

For reference/context of the previous issue, see
,
and following messages.

If I turn that conditional cited above into 'if (1)', then nvptx
offloading testing seems to return to normality, but I have not yet
assessed whether that has any ill effects on decimal float types support,
and/or how this should be fixed properly.  (Julian, please have a look,
if you can, or tell me if you're busy with other things.)


For reference:

On 2019-11-22T16:40:01+, Joseph Myers  wrote:
> Code that directly uses _Decimal* types on architectures not
> supporting DFP is properly diagnosed ("error: decimal floating-point
> not supported for this target"), via a call to
> targetm.decimal_float_supported_p, if the _Decimal32, _Decimal64 or
> _Decimal128 keywords are used to access it.  Use via mode attributes
> is also diagnosed ("unable to emulate 'SD'"); so is use of the
> FLOAT_CONST_DECIMAL64 pragma.  However, it is possible to access those
> types via typeof applied to constants or built-in functions without
> such an error.  I expect that there are ways to get an ICE from this;
> certainly it uses a completely undefined ABI.
>
> This patch arranges for the types not to exist in the compiler at all
> when DFP is not supported.  As is done with unsupported _FloatN /
> _FloatNx types, the global tree nodes are left as NULL_TREE, and the
> built-in function machinery is made to use error_mark_node for them in
> that case in builtin-types.def, so that the built-in functions are
> unavailable.  Code handling constants is adjusted to give an error,
> and other code that might not work with the global tree nodes being
> NULL_TREE is also updated.
>
> Bootstrapped with no regressions for x86_64-pc-linux-gnu.  Also tested
> with no regressions for cross to aarch64-linux-gnu, as a configuration
> without DFP support.  OK to commit (the changes that aren't C front-end 
> changes)?
>
> gcc:
> 2019-11-22  Joseph Myers  
>
>   PR c/91985
>   * builtin-types.def (BT_DFLOAT32, BT_DFLOAT64, BT_DFLOAT128)
>   (BT_DFLOAT32_PTR, BT_DFLOAT64_PTR, BT_DFLOAT128_PTR): Define to
>   error_mark_node if corresponding global tree node is NULL.
>   * tree.c (build_common_tree_nodes): Do not initialize
>   dfloat32_type_node, dfloat64_type_node or dfloat128_type_node if
>   decimal floating-point not supported.
>
> gcc/c:
> 2019-11-22  Joseph Myers  
>
>   PR c/91985
>   * c-decl.c (finish_declspecs): Use int instead of decimal
>   floating-point types if decimal floating-point not supported.
>
> gcc/c-family:
> 2019-11-22  Joseph Myers  
>
>   PR c/91985
>   * c-common.c (c_common_type_for_mode): Handle decimal
>   floating-point types being NULL_TREE.
>   * c-format.c (get_format_for_type_1): Handle specified types being
>   NULL_TREE.
>   * c-lex.c (interpret_float): Give an error for decimal
>   floating-point constants when decimal floating-point not
>   supported.
>
> gcc/lto:
> 2019-11-22  Joseph Myers  
>
>   PR c/91985
>   * lto-lang.c (lto_type_for_mode): Handle decimal floating-point
>   types being NULL_TREE.
>
> gcc/testsuite:
> 2019-11-22  

Re: [C++ PATCH] c++/91353 - P1331R2: Allow trivial default init in constexpr contexts.

[Jason Merrill]

On 11/27/19 2:36 PM, Marek Polacek wrote:

On Sun, Nov 24, 2019 at 12:24:48PM -0500, Jason Merrill wrote:

On 11/16/19 5:23 PM, Marek Polacek wrote:

[ Working virtually on Baker Island. ]

This patch implements C++20 P1331, allowing trivial default initialization in
constexpr contexts.

I used Jakub's patch from the PR which allowed uninitialized variables in
constexpr contexts.  But the hard part was handling CONSTRUCTOR_NO_CLEARING
which is always cleared in cxx_eval_call_expression.  We need to set it in
the case a constexpr constructor doesn't initialize all the members, so that
we can give proper diagnostic instead of value-initializing.  A lot of my
attempts flopped but then I came up with this approach, which handles various
cases as tested in constexpr-init8.C, where S is initialized by a non-default
constexpr constructor, and constexpr-init9.C, using delegating constructors.
And the best part is that I didn't need any new cx_check_missing_mem_inits
calls!  Just save the information whether a constructor is missing an init
into constexpr_fundef_table and retrieve it when needed.


Is it necessary to clear the flag for constructors that do happen to
initialize all the members?  I would think that leaving that clearing to
reduced_constant_expression_p would be enough.


It seems so: if I tweak cxx_eval_call_expression to only call 
clear_no_implicit_zero
when 'fun' isn't DECL_CONSTRUCTOR_P, then a lot breaks, e.g. constexpr-base.C
where the constructor initializes all the members.  By breaking I mean spurious
errors coming from

5937   if (TREE_CODE (r) == CONSTRUCTOR && CONSTRUCTOR_NO_CLEARING (r))
5938 {
5939   if (!allow_non_constant)
5940 error ("%qE is not a constant expression because it refers to "
5941"an incompletely initialized variable", t);
5942   TREE_CONSTANT (r) = false;
5943   non_constant_p = true;
5944 }


Why didn't reduced_constant_expression_p unset CONSTRUCTOR_NO_CLEARING?


constexpr-init10.C demonstrates that we can now elide a constructor call,
this is caused by the walk_field_subobs hunk.  I hope that's OK.


So long as the object's vptr is initialized properly, absolutely.  Since a
has static storage duration, constant zero-initialization plus the default
constructor fully initialize the object.


Ah, that's comforting to hear, thanks.

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

[C++ PATCH] More fun with typedef to dependent alias.

[Jason Merrill]

rsandifo's patch for 92206 demonstrated a problem with the existing checking
for alias template specializations: they were returning false for a typedef
to an alias template specialization.  Which is sometimes what the caller
wants, and sometimes not: Sometimes we're interested in whether the type was
written as an alias template-id, and sometimes whether it represents one.

The testcase illustrates a case that remained wrong with the earlier patch:
if the typedef is itself an alias template specialization, we can't strip an
underlying dependent alias.

Tested x86_64-pc-linux-gnu, applying to trunk.

* pt.c (dependent_alias_template_spec_p)
(alias_template_specialization_p): Add transparent_typedefs
parameter.
(iterative_hash_template_arg, any_template_parm_r)
(primary_template_specialization_p, tsubst, dependent_type_p_r):
Adjust.
* decl.c (check_elaborated_type_specifier): Adjust.
* error.c (dump_template_bindings, dump_aggr_type): Adjust.
---
 gcc/cp/cp-tree.h  |  5 +-
 gcc/cp/decl.c |  2 +-
 gcc/cp/error.c|  6 +-
 gcc/cp/pt.c   | 70 ---
 gcc/cp/tree.c | 11 ++-
 gcc/cp/typeck.c   | 11 +--
 .../g++.dg/cpp0x/alias-decl-pr92206-4.C   | 11 +++
 7 files changed, 77 insertions(+), 39 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-pr92206-4.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 4b4bc245d81..d8e12e99ba3 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6938,8 +6938,9 @@ extern tree instantiate_non_dependent_expr_internal 
(tree, tsubst_flags_t);
 extern tree instantiate_non_dependent_or_null   (tree);
 extern bool variable_template_specialization_p  (tree);
 extern bool alias_type_or_template_p(tree);
-extern bool alias_template_specialization_p (const_tree);
-extern bool dependent_alias_template_spec_p (const_tree);
+enum { nt_opaque = false, nt_transparent = true };
+extern tree alias_template_specialization_p (const_tree, bool);
+extern tree dependent_alias_template_spec_p (const_tree, bool);
 extern bool template_parm_object_p (const_tree);
 extern bool explicit_class_specialization_p (tree);
 extern bool push_tinst_level(tree);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 26120720f07..7d5bc914d2d 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -14548,7 +14548,7 @@ check_elaborated_type_specifier (enum tag_types 
tag_code,
   && !DECL_SELF_REFERENCE_P (decl)
   && tag_code != typename_type)
 {
-  if (alias_template_specialization_p (type))
+  if (alias_template_specialization_p (type, nt_opaque))
error ("using alias template specialization %qT after %qs",
   type, tag_name (tag_code));
   else
diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 4261d3c4cc9..a15230a1f01 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -421,7 +421,7 @@ dump_template_bindings (cxx_pretty_printer *pp, tree parms, 
tree args,
 static void
 dump_alias_template_specialization (cxx_pretty_printer *pp, tree t, int flags)
 {
-  gcc_assert (alias_template_specialization_p (t));
+  gcc_assert (alias_template_specialization_p (t, nt_opaque));
 
   tree decl = TYPE_NAME (t);
   if (!(flags & TFF_UNQUALIFIED_NAME))
@@ -454,7 +454,7 @@ dump_type (cxx_pretty_printer *pp, tree t, int flags)
? STF_USER_VISIBLE : 0);
  t = strip_typedefs (t, NULL, stf_flags);
}
-  else if (alias_template_specialization_p (t))
+  else if (alias_template_specialization_p (t, nt_opaque))
{
  dump_alias_template_specialization (pp, t, flags);
  return;
@@ -711,7 +711,7 @@ dump_aggr_type (cxx_pretty_printer *pp, tree t, int flags)
   typdef = (!DECL_ARTIFICIAL (name)
/* An alias specialization is not considered to be a
   typedef.  */
-   && !alias_template_specialization_p (t));
+   && !alias_template_specialization_p (t, nt_opaque));
 
   if ((typdef
   && ((flags & TFF_CHASE_TYPEDEF)
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 3eed27bb426..244eb7d4ff3 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -1882,7 +1882,7 @@ iterative_hash_template_arg (tree arg, hashval_t val)
   switch (tclass)
 {
 case tcc_type:
-  if (alias_template_specialization_p (arg))
+  if (tree ats = alias_template_specialization_p (arg, nt_transparent))
{
  // We want an alias specialization that survived strip_typedefs
  // to hash differently from its TYPE_CANONICAL, to avoid hash
@@ -1891,7 +1891,7 @@ iterative_hash_template_arg (tree arg, hashval_t val)
  // left alone, or untouched specializations because
  // coerce_template_parms returns the 

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #3 from Wilco  ---
(In reply to Andrew Pinski from comment #2)
> I think this has been a latent bug since revision 243200:
> [AArch64] Separate shrink wrapping hooks implementation
> 
> I think aarch64_disqualify_components would be a location which should
> disqualify the Separate for the register 19.

What is the "exclusives reservation granule" size? It could only fail if the
granule is large and the spill happens to be in the same granule as the stxr.

I guess it's easy to fix by delaying the expansion or inserting a clobber of
x19 before the loop starts.

[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #10 from Peter Bergner  ---
The commit above fixes the bootstrap issue.  However, we still have an issue
with the testsuite test case dtstsfi-0.c.  That test case calls a builtin
function that overloads one of the DFP builtins we skipped defining with per
this commit.  The current code uses standin types rather than DFP types, so we
do not recognize that DFP has been disabled.

[PATCH] rs6000: Fix PR92661, Do not define DFP builtin functions, if DFP has been disabled

[Peter Bergner]

This patch fixes the bootstrap breakage in the rs6000 port caused by the
recent patch from Joseph that disables adding the _Decimal* types when
DFP has been disabled.  It's based on Joseph's suggestion from the
bugzilla.

This passed bootstrap and regtesting on powerpc64*-linux and Iain
confirmed this fixes his Darwin build as well.  Segher preapproved
this patch, so I have committed it now to get bootstrap working
again.

We still have some testsuite fallout due to builtin functions that overload
builtins that have been disabled due to the decimal types being disabled.
I'm still working on resolving that.

Peter

PR bootstrap/92661
* config/rs6000/rs6000-call.c: (def_builtin): Do not define the
builtin if we don't have an actual type.
(builtin_function_type): If the builtin function uses a DFP type
and decimal float has been disabled, then return NULL_TREE.

Index: gcc/config/rs6000/rs6000-call.c
===
--- gcc/config/rs6000/rs6000-call.c (revision 278692)
+++ gcc/config/rs6000/rs6000-call.c (working copy)
@@ -2935,6 +2935,10 @@ def_builtin (const char *name, tree type
   unsigned classify = rs6000_builtin_info[(int)code].attr;
   const char *attr_string = "";
 
+  /* Don't define the builtin if it doesn't have a type.  See PR92661.  */
+  if (type == NULL_TREE)
+return;
+
   gcc_assert (name != NULL);
   gcc_assert (IN_RANGE ((int)code, 0, (int)RS6000_BUILTIN_COUNT));
 
@@ -7702,6 +7706,11 @@ builtin_function_type (machine_mode mode
   if (!ret_type && h.uns_p[0])
 ret_type = builtin_mode_to_type[h.mode[0]][0];
 
+  /* If the required decimal float type has been disabled,
+ then return NULL_TREE.  */
+  if (!ret_type && DECIMAL_FLOAT_MODE_P (h.mode[0]))
+return NULL_TREE;
+
   if (!ret_type)
 fatal_error (input_location,
 "internal error: builtin function %qs had an unexpected "
@@ -7719,6 +7728,11 @@ builtin_function_type (machine_mode mode
   if (!arg_type[i] && uns_p)
arg_type[i] = builtin_mode_to_type[m][0];
 
+  /* If the required decimal float type has been disabled,
+then return NULL_TREE.  */
+  if (!arg_type[i] && DECIMAL_FLOAT_MODE_P (m))
+   return NULL_TREE;
+
   if (!arg_type[i])
fatal_error (input_location,
 "internal error: builtin function %qs, argument %d "

[Bug c++/92411] conformance issue with reinterpret_cast in constant expressions

[Darrell.Wright at gmail dot com]

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

--- Comment #1 from Darrell Wright  ---
sorry, posted incorrect CE link, but code below demonstrates it

[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #47383|0   |1
is obsolete||

--- Comment #9 from Jakub Jelinek  ---
Created attachment 47385
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47385=edit
gcc10-pr92695-2.patch

Oops, the second patch I've attached was the same as the first one, instead of
this one.

Re: Branch and tag deletions

[Eric S. Raymond]

Joseph Myers :
> > I'm more worried about missing files. I saw a bunch of those on my
> > last test.  This could be spurious - the elaborate set of branch
> > mappings you specified confuses my validation test, because there is
> > no longer a 1-1 corresponsence between Subversion and git branches.
> 
> I'm hoping any such missing file problems come from bugs in the old SVN 
> dump reader with complicated commits mixing copies / deletions / 
> replacements with copies from other locations and that your rewrite will 
> fix the semantics in such cases.

Also possible.  

The old code was a hairball. The new code is a bunch of relatively simple
sequential passes - 10 so far, final version likely to have 12 or 13 - with
well-defined preconditions and exit contracts. If nothing else this is
going to make troubleshooting any remaining defects much easier.

> All the current gcc-conversion merge requests, both mine and Richard's, 
> should now be set to allow rebasing.

They were, and are all merged now, except for one that Richard just landed. 
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 47384
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47384=edit
gcc10-pr92695-3.patch

That is another bug.

[Bug c++/92700] New: wrong "unintialized" warning with std::optional

[f.heckenb...@fh-soft.de]

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

Bug ID: 92700
   Summary: wrong "unintialized" warning with std::optional
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: f.heckenb...@fh-soft.de
  Target Milestone: ---

#include 
#include 

int e;

template  std::optional  f ()
{
  if (auto i = std::string ().find ('a'))
return i;
  return { };
}

int main ()
{
  size_t j = 1;
  while (j)
{
  auto i = f  ();
  if (e != 1 && e != 4 && e != 7)
throw 0;
  if (i)
j = *i;
}
}

% g++-9 --version
g++-9 (GCC) 9.1.0

% g++-9 --std=c++17 test.cpp -Wall -O3
test.cpp: In function 'int main()':
test.cpp:10:12: warning: '' may be used uninitialized in this
function [-Wmaybe-uninitialized]

This may be a duplicate, but I can't really tell since this warning seems to
depend on many seemingly unrelated conditions, e.g. f must be a template,
std::string::find seems required (at least a simple external function won't
do),
the seemingly unrelated test of e is required (and must contain at least
3 clauses with specific values -- 1, 2, 3 won't do).

[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648

[rsandifo at gcc dot gnu.org]

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

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
(In reply to Uroš Bizjak from comment #8)
> (In reply to Liu Hao from comment #7)
> > MSDN says 'the upper portions of YMM0-15 and ZMM0-15 are considered volatile
> > and must be considered destroyed on function calls' explicitly [1].
> > 
> > I am not clear about the cause of OP's ICE, but I think it should conform to
> > MSABI to emit VZEROUPPER in the epilog, followed by restoring XMM6 - XMM15,
> > destroying their upper halves. Similar with the prolog.
> 
> The insertion of vzeroupper is not "invisible" to stack frame management
> code any more, since vzeroupper is now defined as:
> 
> (insn 738 619 434 2 (parallel [
> (unspec_volatile [
> (const_int 0 [0])
> ] UNSPECV_VZEROUPPER)
> (clobber (reg:V2DI 20 xmm0))
> (clobber (reg:V2DI 21 xmm1))
> (clobber (reg:V2DI 22 xmm2))
> (clobber (reg:V2DI 23 xmm3))
> (clobber (reg:V2DI 24 xmm4))
> (clobber (reg:V2DI 25 xmm5))
> (set (reg:V2DI 26 xmm6)
> (reg:V2DI 26 xmm6))
> (clobber (reg:V2DI 27 xmm7))
> (clobber (reg:V2DI 44 xmm8))
> (clobber (reg:V2DI 45 xmm9))
> (clobber (reg:V2DI 46 xmm10))
> (clobber (reg:V2DI 47 xmm11))
> (clobber (reg:V2DI 48 xmm12))
> (clobber (reg:V2DI 49 xmm13))
> (clobber (reg:V2DI 50 xmm14))
> (clobber (reg:V2DI 51 xmm15))
> ]) "pr92190.c":8:3 -1
>  (nil))
> 
> 
> . The insertion point of vzeroupper pass is just after reload pass, and now
> all xmm registers (xmm0 - xmm15) become live. This is not a problem in SYSV
> ABI, where all registers are call_used, but in MS ABI, the prologue now
> tries to save xmm6 - xmm15 to the stack.
> 
> So, vzeroupper should be described in a way that won't trigger saves of xmm6
> - xmm15 to the stack, while still mark that high part of the register is
> clobbered.

Ah, OK.  It should be safe to leave out a clobber if
!df_regs_ever_live_p and if we're guaranteed not to introduce
new references to the register later.

[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change

[bergner at gcc dot gnu.org]

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

--- Comment #9 from Peter Bergner  ---
Author: bergner
Date: Wed Nov 27 20:55:56 2019
New Revision: 278783

URL: https://gcc.gnu.org/viewcvs?rev=278783=gcc=rev
Log:
Do not define DFP builtin functions, if DFP has been disabled.

PR bootstrap/92661
* config/rs6000/rs6000-call.c: (def_builtin): Do not define the
builtin if we don't have an actual type.
(builtin_function_type): If the builtin function uses a DFP type
and decimal float has been disabled, then return NULL_TREE.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-call.c

[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Liu Hao from comment #7)
> MSDN says 'the upper portions of YMM0-15 and ZMM0-15 are considered volatile
> and must be considered destroyed on function calls' explicitly [1].

BTW: MSDN is clear that xMM16-31 are volatile (call_used), so the current
definition of CALL_USER_REGISTERS is wrong. At least this part should be:

Index: i386.h
===
--- i386.h  (revision 278455)
+++ i386.h  (working copy)
@@ -1126,9 +1126,9 @@
 /*xmm8,xmm9,xmm10,xmm11,xmm12,xmm13,xmm14,xmm15*/  \
  6,   6,6,6,6,6,6,6,   \
 /*xmm16,xmm17,xmm18,xmm19,xmm20,xmm21,xmm22,xmm23*/\
- 6,6, 6,6,6,6,6,6, \
+ 1,1, 1,1,1,1,1,1, \
 /*xmm24,xmm25,xmm26,xmm27,xmm28,xmm29,xmm30,xmm31*/\
- 6,6, 6,6,6,6,6,6, \
+ 1,1, 1,1,1,1,1,1, \
  /* k0,  k1,  k2,  k3,  k4,  k5,  k6,  k7*/\
  1,   1,   1,   1,   1,   1,   1,   1 }

[Bug c/92699] New: Slash should be removed from C/C++ plugin install destination

[brechtsanders at users dot sourceforge.net]

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

Bug ID: 92699
   Summary: Slash should be removed from C/C++ plugin install
destination
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brechtsanders at users dot sourceforge.net
  Target Milestone: ---

I was trying to GCC with the --enable-plugin parameter on Windows with
MinGW-w64.
There was an error in the installation which I was able to solve by fixing
gcc/c/Make-lang.in and gcc/cp/Make-lang.in with this command:
sed -i.bak -e "s?\(\$(DESTDIR)\)/\(\$(plugin_resourcesdir)\)?\1\2?"
gcc/c/Make-lang.in gcc/cp/Make-lang.in

Basically the slash in $(DESTDIR)/$(plugin_resourcesdir) should be removed, so
this reads as $(DESTDIR)$(plugin_resourcesdir), which is how it was done in the
line above it that makes the directory if needed.
Otherwise the path starts with 2 slashes, which on Windows would make it a UNC
path instead of a local path. I can image this probably worked on almost any
other OS.

Re: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?

[Andreas Schwab]

On Nov 27 2019, Andrew Dean via gcc wrote:

> 2. export 
> LD_LIBRARY_PATH=${BuildRoot}/install/glibcs/aarch64-linux-gnu/lib64:${BuildRoot}/install/compilers/aarch64-linux-gnu/aarch64-glibc-linux-gnu/lib64
>  
> 3. sudo ln -s 
> ${BuildRoot}/install/glibcs/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 
> /lib/ld-linux-aarch64.so.1

Just set QEMU_LD_PREFIX to your sysroot.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org

--- Comment #8 from Segher Boessenkool  ---
Assigning this to Peter.

[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
(In reply to Liu Hao from comment #7)
> MSDN says 'the upper portions of YMM0-15 and ZMM0-15 are considered volatile
> and must be considered destroyed on function calls' explicitly [1].
> 
> I am not clear about the cause of OP's ICE, but I think it should conform to
> MSABI to emit VZEROUPPER in the epilog, followed by restoring XMM6 - XMM15,
> destroying their upper halves. Similar with the prolog.

The insertion of vzeroupper is not "invisible" to stack frame management code
any more, since vzeroupper is now defined as:

(insn 738 619 434 2 (parallel [
(unspec_volatile [
(const_int 0 [0])
] UNSPECV_VZEROUPPER)
(clobber (reg:V2DI 20 xmm0))
(clobber (reg:V2DI 21 xmm1))
(clobber (reg:V2DI 22 xmm2))
(clobber (reg:V2DI 23 xmm3))
(clobber (reg:V2DI 24 xmm4))
(clobber (reg:V2DI 25 xmm5))
(set (reg:V2DI 26 xmm6)
(reg:V2DI 26 xmm6))
(clobber (reg:V2DI 27 xmm7))
(clobber (reg:V2DI 44 xmm8))
(clobber (reg:V2DI 45 xmm9))
(clobber (reg:V2DI 46 xmm10))
(clobber (reg:V2DI 47 xmm11))
(clobber (reg:V2DI 48 xmm12))
(clobber (reg:V2DI 49 xmm13))
(clobber (reg:V2DI 50 xmm14))
(clobber (reg:V2DI 51 xmm15))
]) "pr92190.c":8:3 -1
 (nil))


. The insertion point of vzeroupper pass is just after reload pass, and now all
xmm registers (xmm0 - xmm15) become live. This is not a problem in SYSV ABI,
where all registers are call_used, but in MS ABI, the prologue now tries to
save xmm6 - xmm15 to the stack.

So, vzeroupper should be described in a way that won't trigger saves of xmm6 -
xmm15 to the stack, while still mark that high part of the register is
clobbered.

An alternative would be to consider the mode of call_used register and save
only wide (> 128bits) registers in the caller. I'm not sure if the current
implementation already clobbers the high part of the 256bit register.

RE: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?

[Andrew Dean via gcc]

> On 11/25/19 2:43 PM, Andrew Dean via gcc wrote:
> >> I get errors like this:
> >>
> >> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
> >> 'rdimon.specs': No such file or directory
> >>
> >> I can see that the rdimon.specs flag is added based on this line
> >> in aarch64-
> > sim.exp:
> >
> > Where does aarch64-sim.exp comes from?
> 
>  /usr/share/dejagnu/baseboards/aarch64-sim.exp
> 
> >
> >>
> >> set_board_info ldflags  "[libgloss_link_flags]
> >> [newlib_link_flags]
> >> -
> > specs=rdimon.specs"
> >>
> > I think this is for baremetal/newlib targets, ie. aarch64-elf, not
> > for aarch64- linux-gnu.
> 
> >>
> >> Yes -specs=rdimon.specs and other such flags are for use only on
> >> bare-metal targets.
> >>
>  Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or
>  aarch64-linux-
> >> elf...
>  I get a KeyError in build_compilers and build_glibcs when it tries
>  to look up
> >> the config with either of those values.
> 
> >>>
> >>> Unfortunately the build-many-glibcs.py does not have support for
> >>> baremetal build yet (since it is a tool created to build
> >>> cross-compiling toolchain using glibc).
> >>
> >> And glibc doesn't work bare-metal ..
> >>
> >> regards
> >> Ramana
> > I guess that means that the dejagnu baseboard "aarch64-sim" is only meant
> to do bare-metal testing? How would one build/test GCC hosted on x86_64 and
> targeting aarch64 then? Is there a different simulator approach I should be
> using?
> I've used qemu for this kind of testing.  In my environment I have root
> filesystems with native binaries/libraries.  I can just chroot into those
> filesystems and qemu handles everything.
> 
> In theory one wouldn't even need to chroot into the filesystems if you set the
> library paths right.
> 
> jeff

Thanks, Jeff. qemu did the trick. Specifically, I did the following:

1. sudo apt-get install qemu-user-static
2. export 
LD_LIBRARY_PATH=${BuildRoot}/install/glibcs/aarch64-linux-gnu/lib64:${BuildRoot}/install/compilers/aarch64-linux-gnu/aarch64-glibc-linux-gnu/lib64
 
3. sudo ln -s 
${BuildRoot}/install/glibcs/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 
/lib/ld-linux-aarch64.so.1
4. Run the gcc tests as previously described
5. Remove the symlink
6. Restore the previous value of LD_LIBRARY_PATH

There are still a few test failures that we will need to investigate, but this 
was a huge leap forward.

[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array

[lutztonineubert at gmail dot com]

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

--- Comment #7 from Toni Neubert  ---
First of all thank you very much for your extremly fast help!
I testet the patch and it did work for my second example.

But this one still fails, if we do not use the addressof function:

struct A {
virtual int get() = 0;
};
struct B : A {
constexpr int get() override {
return 10;
}
};

struct D {
B b[2];
A* c{&(b[0])};
};

static_assert(D{}.c->get() == 10);

Error:

main.cpp:20:28: error: non-constant condition for static assertion
   20 | static_assert(D{}.c->get() == 10);
  |   ~^
main.cpp:20:28: error: expression 'A::get' is not a constant expression

[PATCH v2][MSP430] -Add fno-exceptions multilib

[Jozef Lawrynowicz]

Original patch here: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00619.html

Late for stage 1 I know, but it's an iteration on a patch submitted before the
transition to stage 3 and the functional changes to the compiler are constrained
to the msp430 target.

The code size bloat added by building C++ programs using libraries containing
support for exceptions is significant. When using simple constructs such as
static variables, sometimes many kB from the libraries are unnecessarily
pulled in.

Since C++ libraries are built with exceptions enabled by default, there is
nothing the end user can do about this, even when they pass -fno-exceptions on
the command line.
So this patch adds a new -fno-exceptions multilib configuration for MSP430,
to reduce the code size linked executables when using C++ with -fno-exceptions.

Since building double the multilibs does significantly increase build time,
the patch also adds a configure option --disable-no-exceptions. This disables
the fno-exceptions multilibs from being built.

The changes from the original patch linked above are:
- Wrapped new gcc-dg-prune directives checking for disabled exception handling
  in an if statement, so they are only used if exception handling has been
  disabled in the global test configuration.
- Extended the spec strings used to check for when crt{begin,end}_no_eh.o can be
  used. When linking a C program where exceptions are implicitly disabled, 
  crt{begin,end}_no_eh.o can always be used unless -fexceptions is explicitly
  passed.

Successfully regtested for x86_64-pc-linux-gnu. There was no change in any of
the testresults (pass/fail/unsupported).

Regtested -fno-exceptions vs the default configuration for msp430-elf. There was
some fallout from exception handling tests not working, but nothing unexpected.

Ok to apply?
>From b74f34e5ae7f649296f7f6bcce35b75c34a2b0fd Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Mon, 25 Nov 2019 12:07:24 +
Subject: [PATCH] MSP430: Add fno-exceptions multilib

ChangeLog:

2019-11-27  Jozef Lawrynowicz  

	* config-ml.in: Support --disable-no-exceptions configure flag.

gcc/ChangeLog:

2019-11-27  Jozef Lawrynowicz  

	* config/msp430/msp430.h (STARTFILE_SPEC) [!fexceptions]: Use
	crtbegin_no_eh.o if building for the C language.
	[fno-exceptions]: Use crtbegin_no_eh.o if building for any language
	except C.
	(ENDFILE_SPEC) [!fexceptions]: Use crtend_no_eh.o if building for 
	the C language.
	[fno-exceptions]: Use crtend_no_eh.o if building for any language
	except C.
	* config/msp430/t-msp430: Add -fno-exceptions multilib.
	* doc/install.texi: Document --disable-no-exceptions multilib configure
	option.

gcc/testsuite/ChangeLog:

2019-11-27  Jozef Lawrynowicz  

	* lib/gcc-dg.exp: Add dg-prune messages for when exception handling is
	disabled.
	* lib/target-supports.exp (check_effective_target_exceptions_enabled):
	New.

libgcc/ChangeLog:

2019-11-27  Jozef Lawrynowicz  

	* config.host: Add crt{begin,end}_no_eh.o to "extra_parts".
	* config/msp430/t-msp430: Add rules to build crt{begin,end}_no_eh.o.
---
 config-ml.in  | 13 +
 gcc/config/msp430/msp430.h| 11 +--
 gcc/config/msp430/t-msp430|  9 +
 gcc/doc/install.texi  |  3 +++
 gcc/testsuite/lib/gcc-dg.exp  | 12 
 gcc/testsuite/lib/target-supports.exp | 18 ++
 libgcc/config.host|  3 ++-
 libgcc/config/msp430/t-msp430 |  6 ++
 8 files changed, 68 insertions(+), 7 deletions(-)

diff --git a/config-ml.in b/config-ml.in
index 3e37f875c88..5720d38d23f 100644
--- a/config-ml.in
+++ b/config-ml.in
@@ -383,6 +383,19 @@ mips*-*-*)
 	  done
 	fi
 	;;
+msp430-*-*)
+	if [ x$enable_no_exceptions = xno ]
+	then
+	  old_multidirs="${multidirs}"
+	  multidirs=""
+	  for x in ${old_multidirs}; do
+	case "$x" in
+	  *no-exceptions* ) : ;;
+	  *) multidirs="${multidirs} ${x}" ;;
+	esac
+	  done
+	fi
+	;;
 powerpc*-*-* | rs6000*-*-*)
 	if [ x$enable_aix64 = xno ]
 	then
diff --git a/gcc/config/msp430/msp430.h b/gcc/config/msp430/msp430.h
index 0ea6b0a093e..7b94918a55d 100644
--- a/gcc/config/msp430/msp430.h
+++ b/gcc/config/msp430/msp430.h
@@ -44,13 +44,20 @@ extern bool msp430x;
 }		\
   while (0)
 
+/* For the "c" language where exceptions are implicitly disabled, use
+   crt*_no_eh.o unless -fexceptions is passed.  For other languages, only use
+   crt*_no_eh.o if -fno-exceptions is explicitly passed.  */
 #undef  STARTFILE_SPEC
 #define STARTFILE_SPEC "%{pg:gcrt0.o%s}" \
-  "%{!pg:%{minrt:crt0-minrt.o%s}%{!minrt:crt0.o%s}} %{!minrt:crtbegin.o%s}"
+  "%{!pg:%{minrt:crt0-minrt.o%s}%{!minrt:crt0.o%s}} " \
+  "%{!minrt:%{,c:%{!fexceptions:crtbegin_no_eh.o%s; :crtbegin.o%s}; " \
+":%{fno-exceptions:crtbegin_no_eh.o%s; :crtbegin.o%s}}}"
 
 /* -lgcc is included because crtend.o needs __mspabi_func_epilog_1.  */
 #undef  ENDFILE_SPEC
-#define ENDFILE_SPEC "%{!minrt:crtend.o%s} 

Re: [C++ PATCH] c++/91353 - P1331R2: Allow trivial default init in constexpr contexts.

[Marek Polacek]

On Sun, Nov 24, 2019 at 12:24:48PM -0500, Jason Merrill wrote:
> On 11/16/19 5:23 PM, Marek Polacek wrote:
> > [ Working virtually on Baker Island. ]
> > 
> > This patch implements C++20 P1331, allowing trivial default initialization 
> > in
> > constexpr contexts.
> > 
> > I used Jakub's patch from the PR which allowed uninitialized variables in
> > constexpr contexts.  But the hard part was handling CONSTRUCTOR_NO_CLEARING
> > which is always cleared in cxx_eval_call_expression.  We need to set it in
> > the case a constexpr constructor doesn't initialize all the members, so that
> > we can give proper diagnostic instead of value-initializing.  A lot of my
> > attempts flopped but then I came up with this approach, which handles 
> > various
> > cases as tested in constexpr-init8.C, where S is initialized by a 
> > non-default
> > constexpr constructor, and constexpr-init9.C, using delegating constructors.
> > And the best part is that I didn't need any new cx_check_missing_mem_inits
> > calls!  Just save the information whether a constructor is missing an init
> > into constexpr_fundef_table and retrieve it when needed.
> 
> Is it necessary to clear the flag for constructors that do happen to
> initialize all the members?  I would think that leaving that clearing to
> reduced_constant_expression_p would be enough.

It seems so: if I tweak cxx_eval_call_expression to only call 
clear_no_implicit_zero
when 'fun' isn't DECL_CONSTRUCTOR_P, then a lot breaks, e.g. constexpr-base.C
where the constructor initializes all the members.  By breaking I mean spurious
errors coming from

5937   if (TREE_CODE (r) == CONSTRUCTOR && CONSTRUCTOR_NO_CLEARING (r))
5938 {
5939   if (!allow_non_constant)
5940 error ("%qE is not a constant expression because it refers to "
5941"an incompletely initialized variable", t);
5942   TREE_CONSTANT (r) = false;
5943   non_constant_p = true;
5944 }

> > constexpr-init10.C demonstrates that we can now elide a constructor call,
> > this is caused by the walk_field_subobs hunk.  I hope that's OK.
> 
> So long as the object's vptr is initialized properly, absolutely.  Since a
> has static storage duration, constant zero-initialization plus the default
> constructor fully initialize the object.

Ah, that's comforting to hear, thanks.

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: Add a new combine pass

[Segher Boessenkool]

On Wed, Nov 27, 2019 at 09:29:27AM +0100, Richard Biener wrote:
> On Tue, Nov 26, 2019 at 2:42 AM Segher Boessenkool
>  wrote:
> > combine actually *calculates* DU chains almost completely, it just throws
> > away most of that information (it wants to have LOG_LINKS, as it did ages
> > ago).  The only thing stopping us from doing that right now is that not
> > all uses are counted (some are skipped).
> >
> > Since combine works only within BBs, DU chains are linear to compute, and
> > UD chains are trivial (and just linear to compute).
> 
> quadraticness appears for RTL DU/UD chains because of partial definitions,
> that doesn't change for BBs so even there computing is them is quadratic
> (because recording them is).  The situation is simply having N partial
> defs all reaching M uses which gives you a chain of size N * M.

And both N and M are constants here (bounded by a constant).  The only
dimensions we care about are those the user can grow unlimited: number
of registers, number of instructions, number of functions, that kind of
thing.

The control flow graph in a basic block is a DAG, making most of this
linear to compute.  Only updating it after every separate change is not
easily linear in total.

> Updating is linear as well if you can disregard partial defs.  Updating cannot
> be quadratic if compute is linear ;)

Sure it can.  Updating has to be O(1) (amortized) per change for the whole
pass to be O(n).  If it is O(n) per change you are likely O(n^2) in total.

I don't see how to make combine itself O(1) per change, but yeah I can
see how that can work (or almost work) for something simpler (and less
weighed down by history :-) ).


Segher

Re: [PATCH] Fix gen_lowpart_for_combine (PR rtl-optimization/92510)

[Segher Boessenkool]

On Wed, Nov 27, 2019 at 10:03:10AM +0100, Jakub Jelinek wrote:
> and it is just combine subst + simplification that turns it into
> ... (subreg:DI (subreg:V1DI (ne:DI (reg:CCZ 17 flags) (const_int 0 [0])) 0) 
> 0) ...
> The restriction that subreg must be of a reg or mem certainly isn't honored
> in debug_insns (there subregs can be of anything that has
> non-VOIDmode/BLKmode).

debug_insns aren't valid RTL often :-(

> Though, just grepping the backends, there are tons
> of cases where the *.md files have subregs of other rtxes (though as I said,
> this is not the case of this testcase, there it is created only during
> substing):

[ snip ]
Wow, lots of it.  That's not good.  Most of these should use truncate
instead.

> config/arm/iwmmxt.md: (subreg:V8QI (ashiftrt:TI

But there *is* no rtx code for this?

> config/msp430/msp430.md:  (subreg:PSI (zero_extend:SI (match_operand:HI 1 
> "general_operand" "0,r")) 0))]

There doesn't sesem to be a way to write this conversion, either.

> config/sparc/sparc.md:(and:DI (subreg:DI (lshiftrt:SI 
> (match_operand:SI 1 "register_operand" "r")

zero_extend

> > > gen_lowpart_for_combine turns that into (ne:V1DI (reg:CC flags) 
> > > (const_int 0))
> > > which looks wrong to me,
> > 
> > Why would that be wrong?
> 
> Because (reg:CC flags) (const_int 0) comparison computes a scalar (boolean),
> not a vector, for vector comparisons I think we only allow say:
> (ne:V1DI (reg:V1DI ...) (reg:V1DI ...)) or const_vector as the other
> operand.

Yeah okay, I see.

> Sure, V1*mode vectors are weird vectors, but still are vectors.
> If we talk about V4DImode, it should be clearer that something that produces
> a scalar can't have vector mode.

It's still not clear to me that
  (ne:V1DI (reg:CC flags) (const_int 0))
produces a scalar: it explicitly produces a vector, instead!  But it's
not clear what the semantics are, sure.  Pity that it isn't documented.


Segher

Re: C++ PATCH for c++/91363 - P0960R3: Parenthesized initialization of aggregates

[Marek Polacek]

On Wed, Nov 20, 2019 at 08:11:27PM -0500, Jason Merrill wrote:
> On 11/20/19 8:37 PM, Marek Polacek wrote:
> > On Tue, Nov 19, 2019 at 05:33:09PM -0500, Jason Merrill wrote:
> > > On 11/19/19 1:44 AM, Marek Polacek wrote:
> > > > > It also looks like you're using the LOOKUP flag to mean two different
> > > > > things:
> > > > > 
> > > > > 1) try to treat parenthesized args as an aggregate initializer
> > > > > (build_new_method_call_1)
> > > > > 2) treat this CONSTRUCTOR as coming from parenthesized args
> > > > > (store_init_value/digest_init)
> > > > 
> > > > Correct.
> > > > 
> > > > > Why is the flag needed for #1?  When do we not want to try to treat 
> > > > > the args
> > > > > as an aggregate initializer?
> > > > 
> > > > There are cases where treating the args as an aggregate initializer 
> > > > causes
> > > > spurious overload resolution successes, e.g.
> > > > 
> > > >void swap(int&, int&);
> > > > 
> > > >int& get();
> > > > 
> > > >struct pair {
> > > >  void swap(pair&) noexcept(noexcept(swap(get(), get( { } // { 
> > > > dg-error "no matching function for call" }
> > > >};
> > > > 
> > > > There are no viable candidates for pair::swap (# of args mismatch) but 
> > > > since
> > > > pair is an aggregate, build_new_method_call_1 would return a 
> > > > CONSTRUCTOR so
> > > > overload resolution would succeed.  Another case had to do with SFINAE 
> > > > and
> > > > decltype where we didn't evaluate the arg, but succeeding in the
> > > > no-viable-function case caused the compiler to choose the wrong 
> > > > function.
> > > 
> > > Hmm, but then the parenthesized list is arguments for swap, not an
> > > initializer for a single argument of swap.  That would be using it for
> > > copy-initialization, and we only want to treat parenthesized args as an
> > > aggregate initializer in direct-initialization.  Can we check for
> > > direct-init (i.e. !LOOKUP_ONLYCONVERTING) instead?
> > 
> > Unfortunately that doesn't work.  We call build_new_method_call from context
> > where LOOKUP_ONLYCONVERTING isn't set and so it would still break things.
> 
> How so?  If we call it for a constructor, surely we can check that flag to
> distinguish between copy- and direct-initialization, or I'd expect wrong
> behavior wrt explicit.

[ Sorry for the delayed response, been too busy with other stuff.  Hope to be
more prompt from now on. ]

Indeed, if I check DECL_CONSTRUCTOR_P, it works.  But I was confused by a test
like the newly-added paren-init17.C.  Here we're checking if A can be trivially
initialized by B, so constructible_expr builds up a build_stub_object object
and calls build_special_member_call.  It doesn't find a viable constructor for
A, but A is an aggregate and there are arguments, so it does parenthesized
initialization, and then we think A can be trivially initialized from B.  But
I don't think we should attempt to handle this case.  I also saw a similar
problem with decltype/declval.  Fixed by checking cp_unevaluated_operand...

Another difference is that g++.old-deja/g++.jason/crash3.C now passes in
C++20.  But that should be fine.

> > > > +  if (BRACE_ENCLOSED_INITIALIZER_P (exp))
> > > > +{
> > > > +  gcc_assert (cxx_dialect >= cxx2a);
> > > > +  return finish_compound_literal (type, exp, complain,
> > > > + fcl_functional_paren);
> > > > +}
> > > 
> > > How about handling this in build_cplus_new instead of places that also 
> > > call
> > > build_cplus_new?
> > 
> > Is it really what we want?  We now have two spots where we need to handle
> > the case when build_special_member_call returns a 
> > BRACE_ENCLOSED_INITIALIZER_P
> > but build_cplus_new is called in many other spots where we don't expect to 
> > see
> > a CONSTRUCTOR.
> 
> I think build_cplus_new should be able to handle whatever
> build_special_member_call returns.

Ok, adjusted.

> > @@ -921,8 +921,20 @@ perform_member_init (tree member, tree init)
> > inform (DECL_SOURCE_LOCATION (member),
> > "%q#D should be initialized", member );
> > }
> > - finish_expr_stmt (build_aggr_init (decl, init, flags,
> > -tf_warning_or_error));
> > + init = build_aggr_init (decl, init, flags, tf_warning_or_error);
> > + /* In C++20, a member initializer list can be initializing an
> > +aggregate from a parenthesized list of values:
> > +
> > +  struct S {
> > +A aggr;
> > +S() : aggr(1, 2, 3) { }
> > +  };
> > +
> > + In such case, build_aggr_init will build up an INIT_EXPR like
> > + we do for aggr{1, 2, 3}, so that build_data_member_initialization
> > + can grok it.  */
> > + if (TREE_CODE (init) != INIT_EXPR)
> > +   finish_expr_stmt (init);
> 
> Why don't we want to finish_expr_stmt an INIT_EXPR?

Because expand_default_init has already finish_expr_stmt-ed it.  Adding it
twice sounds wrong.

> > @@ 

[PING] Re: [PATCH 2/2][MIPS][RFC] Emit .note.GNU-stack for hard-float linux targets.

[Dragan Mladjenovic]

On 07.11.2019. 18:05, Dragan Mladjenovic wrote:
> On 01.11.2019. 11:32, Dragan Mladjenovic wrote:
>> On 10.08.2019. 00:15, Joseph Myers wrote:
>>> On Fri, 9 Aug 2019, Jeff Law wrote:
>>>
> 2019-08-05  Dragan Mladjenovic  
>
> * config.in: Regenerated.
> * config/mips/linux.h (NEED_INDICATE_EXEC_STACK): Define to 1
> for TARGET_LIBC_GNUSTACK.
> * configure: Regenerated.
> * configure.ac: Define TARGET_LIBC_GNUSTACK if glibc version is
> found 2.31 or greater.
 My only concern here is the configure bits.  So for example, will it do
 the right thing if you're cross-compiling to a MIPS linux target?  If
 so, how?  If not, do we need to make it a first class configure option
 so that it can be specified when building cross MIPS linux toolchains?
>>>
>>> The key point of using GCC_GLIBC_VERSION_GTE_IFELSE is that (a) it
>>> checks
>>> the target glibc headers if available when GCC is built and (b) if not
>>> available, you can still use --with-glibc-version when configuring
>>> GCC, to
>>> get the right configuration in a bootstrap compiler built before
>>> glibc is
>>> built (the latter is necessary on some architectures to get the right
>>> stack-protector configuration for bootstrapping glibc, but may be useful
>>> in other cases as well).
>>>
>>> My main concern about this patch is the one I gave in
>>>  about what
>>> the configuration mechanism should be, on a whole-toolchain level, to
>>> say
>>> whether you are OK with a requirement for a 4.8 or later kernel.
>>>
>>
>> Sorry for the late reply.
>>
>> I was waiting to backport [1] to most of the glibc release branches in
>> use, but I got sidetracked along the way.
>>
>> After this patch lands the preferred way to configure gcc would be using
>> --with-glibc-version=2.31 and to use said glibc.
>> If the user/distribution can live with minimal kernel requirement of 4.8
>> the glibc used should be configured with --enable-kernel=4.8.
>> I also plan to backport the [1] to limit the opportunity for building
>> the possibly broken glibc with the gcc w/ enabled .note.GNU-stack.
>>
>> This is all tedious and user has to be aware of all of it to make it
>> work, but hopefully over time the distributions will default to
>> --with-glibc-version=2.31 and --enable-kernel=4.8. I guess providing the
>> detailed NEWS entry for this change would help a bit.
>>
>> Is there any objections to getting this on the trunk before the end of
>> stage1?
>>
>> [1] https://sourceware.org/ml/libc-alpha/2019-08/msg00639.html
>>
>
> Small update and gentle ping. The glibc change was backported all the
> way back to 2.24.
>
> Best regards,
> Dragan
>

Ping.

[analyzer] Introduce point_and_state::validate

[David Malcolm]

This patch adds various validate functions to assert that the internal
state of the analyzer is consistent.

In particular, it asserts that the call_string in the program_point
agrees with the stack_region in the region_model (in terms of the
stack depth, and which function is at each depth).

Doing so uncovered some inconsistencies in e.g. setjmp-3.c due to
creating a "next" node after the on_longjmp containing an
"after-supernode" point directly after the "longjmp" call with the
same call_string as the longjmp call, but with a program_state
containing popped frames due to rewinding the stack.

The patch fixes this by adding a new flag to exploded_node::on_stmt so
that we can stop analyzing the path in the normal way at a longjmp
call, relying on the special-case node/edge creation in
exploded_node::on_longjmp.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.

Pushed to branch "dmalcolm/analyzer" on the GCC git mirror.

gcc/ChangeLog:
* analyzer/call-string.cc (call_string::validate): New function.
* analyzer/call-string.h (call_string::validate): New decl.
* analyzer/engine.cc (point_and_state::validate): New function.
(exploded_node::on_stmt): Convert return type from bool to
exploded_node::on_stmt_flags.  Terminate the path after handling
longjmp.
(exploded_graph::get_or_create_node): Validate the point_and_state
after creating it, and after any merging.
(exploded_graph::process_node): Bail out after on_stmt if
m_terminate_path is set.
* analyzer/exploded-graph.h (point_and_state::validate): New decl.
(exploded_node::on_stmt_flags): New struct.
(exploded_node::on_stmt): Convert return type from bool to
exploded_node::on_stmt_flags.
* analyzer/program-point.cc
(program_point::get_function_at_depth): New function.
(program_point::validate): New function.
* analyzer/program-point.h (program_point::get_function_at_depth):
New decl.
(program_point::validate): New decl.
* analyzer/region-model.cc (region_model::get_function_at_depth):
New function.
(selftest::test_state_merging): Add coverage for
region_model::get_stack_depth and
region_model::get_function_at_depth.
* analyzer/region-model.h (region_model::get_function_at_depth):
New decl.
---
 gcc/analyzer/call-string.cc   | 19 +
 gcc/analyzer/call-string.h|  2 ++
 gcc/analyzer/engine.cc| 53 ++-
 gcc/analyzer/exploded-graph.h | 45 +
 gcc/analyzer/program-point.cc | 30 
 gcc/analyzer/program-point.h  |  3 ++
 gcc/analyzer/region-model.cc  | 17 +++
 gcc/analyzer/region-model.h   |  1 +
 8 files changed, 158 insertions(+), 12 deletions(-)

diff --git a/gcc/analyzer/call-string.cc b/gcc/analyzer/call-string.cc
index 796b5e798187..a9a9ce51ea52 100644
--- a/gcc/analyzer/call-string.cc
+++ b/gcc/analyzer/call-string.cc
@@ -199,3 +199,22 @@ call_string::cmp_1 (const call_string ,
   // TODO: test coverage for this
 }
 }
+
+/* Assert that this object is sane.  */
+
+void
+call_string::validate () const
+{
+  /* Skip this in a release build.  */
+#if !CHECKING_P
+  return;
+#endif
+
+  /* Each entry's "caller" should be the "callee" of the previous entry.  */
+  const return_superedge *e;
+  int i;
+  FOR_EACH_VEC_ELT (m_return_edges, i, e)
+if (i > 0)
+  gcc_assert (e->get_caller_function ()
+ == m_return_edges[i - 1]->get_callee_function ());
+}
diff --git a/gcc/analyzer/call-string.h b/gcc/analyzer/call-string.h
index e5657e6799bd..221867652e95 100644
--- a/gcc/analyzer/call-string.h
+++ b/gcc/analyzer/call-string.h
@@ -64,6 +64,8 @@ public:
 return m_return_edges[idx];
   }
 
+  void validate () const;
+
 private:
   static int cmp_1 (const call_string ,
const call_string );
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index e02ac7de6577..b1624777a221 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -595,6 +595,38 @@ impl_region_model_context::on_condition (tree lhs, enum 
tree_code op, tree rhs)
 
 
 
+/* struct point_and_state.  */
+
+/* Assert that this object is sane.  */
+
+void
+point_and_state::validate (const extrinsic_state _state) const
+{
+  /* Skip this in a release build.  */
+#if !CHECKING_P
+  return;
+#endif
+
+  m_point.validate ();
+
+  m_state.validate (ext_state);
+
+  /* Verify that the callstring's model of the stack corresponds to that
+ of the region_model.  */
+  /* They should have the same depth.  */
+  gcc_assert (m_point.get_stack_depth ()
+ == m_state.m_region_model->get_stack_depth ());
+  /* Check the functions in the callstring vs those in the frames
+ at each depth.  */
+  for (int depth = 0; depth < 

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from Andrew Pinski  ---
I think this has been a latent bug since revision 243200:
[AArch64] Separate shrink wrapping hooks implementation

I think aarch64_disqualify_components would be a location which should
disqualify the Separate for the register 19.

Re: [PATCH] [rs6000] Fix PR92098

[Segher Boessenkool]

Hi!

On Wed, Nov 27, 2019 at 12:31:30AM -0600, Li Jia He wrote:
> In order to fix PR92098, we need to define vec_cmp_* and vcond_mask_*.  In 
> fact,
> PR92132 already fixed the issue on the trunk.  We need to backport PR92132 int
> part to gcc-9-branch.

(Part of that patch).

> 2019-11-27  Li Jia He  
> 
>   PR target/92098
>   * config/rs6000/predicates.md
>   (signed_or_equality_comparison_operator): New predicate.
>   (unsigned_or_equality_comparison_operator): Likewise.
>   * config/rs6000/rs6000.md (one_cmpl2): Remove expand.
>   (one_cmpl3_internal): Rename to one_cmpl2.
>   * config/rs6000/vector.md
>   (vcond_mask_ for VEC_I and VEC_I): New expand.
>   (vec_cmp for VEC_I and VEC_I): Likewise.
>   (vec_cmpu for VEC_I and VEC_I): Likewise.

The changelog should say it is a backport.  See other changelog entries
for how that is done.  For this, you would say "Partial backport" or
something similar, since it is not a plain backport.

Okay for GCC 9.  Thanks!


Segher

[Bug fortran/92698] New: Unnecessary copy in overlapping array assignment

[mjr19 at cam dot ac.uk]

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

Bug ID: 92698
   Summary: Unnecessary copy in overlapping array assignment
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjr19 at cam dot ac.uk
  Target Milestone: ---

subroutine cpy(a,src,dest,len)
  integer, intent(in) :: src,dest,len
  real(kind(1d0)), intent(inout) :: a(:)

  a(dest:dest+len-1)=a(src:src+len-1)

end subroutine cpy


seems to compile to malloc tmp array, inline copy to tmp, inline copy from tmp,
free tmp in gfortran 7.4 and 8.3. Gfortran 9.2 modifies this by replacing the
inline copies with memcpy at -O3.

Fortran permits the source and destination to overlap, so a single call to
memcpy would be wrong. However, it is always possible to do an overlapping copy
in place either by incrementing from the start or by decrementing from the end,
as glibc's memmove does. The use of a temporary array, whilst given as an
example in the Fortran standard to illustrate that overlap is permitted, seems
in practice unnecessary. Would it not be better to call memmove once rather
than memcpy twice? Or perhaps a single inline copy, direction to be determined
by the nature of the overlap?

(Above observations from Linux / x86_64)

[Bug preprocessor/92696] #pragma GCC diagnostic ... interferes with if/else

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Also #pragma are considered statements.  There is another issue like this
> but instead using _Pragma .

I should say some Pragmas are considered statements.

See PR 90400 Which shows the similar issue but with _Pragma.  In this case,
these Pragmas are considered statements.

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>it turns out the issue is a gcc issue and a glibc issue.
NOTE I had missed out a word here:
This should have read:
it turns out the issue is a gcc issue and NOT a glibc issue.

[Bug tree-optimization/92596] [10 Regression] ICE in exact_div, at poly-int.h:2162 since r278406

[rsandifo at gcc dot gnu.org]

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

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
Since it's been a while since the last update: I've been trying
various non-invasive ways of fixing it, but even if they seem to be
strict improvements, they still leave open obvious traps of a similar
nature for later.

I think we'll just have to get rid of the special deferred handling
of boolean_type_node and stop computing so much of this stuff on
the fly.  I'm now testing a series of patches to do that.

Re: [PATCH, rs6000] Fix PR92566 by checking VECTOR_UNIT_NONE_P

[Segher Boessenkool]

On Wed, Nov 27, 2019 at 02:01:05PM +0800, Kewen.Lin wrote:
> As Segher pointed out in PR92566, we shouldn't offer some vector modes which
> aren't supported under current setting.  This patch is to make it check by
> VECTOR_UNIT_NONE_P which is initialized as current architecture masks.
> 
> Bootstrapped and tested on powerpc64le-linux-gnu.
> Is it ok for trunk?

Okay.  Thanks!


Segher


> 2019-11-27  Kewen Lin  
> 
>   PR tree-optimization/91790
>   * gcc/config/rs6000/rs6000.c (rs6000_preferred_simd_mode): Check by
>   VECTOR_UNIT_NONE_P instead.

Re: [PATCH] Reformat PowerPC movdi_internal64

[Segher Boessenkool]

Hi!

On Tue, Nov 26, 2019 at 08:33:34PM -0500, Michael Meissner wrote:
> This patch changes just the movdi_internal64 insn.

All of the same comments as for the movsi patch.  Also:

> -;;  GPR store  GPR load   GPR move   GPR li GPR lis GPR #
> -;;  FPR store  FPR load   FPR move   AVX store  AVX store   AVX 
> load
> -;;  AVX load   VSX move   P9 0   P9 -1  AVX 0/-1VSX 0
> -;;  VSX -1 P9 const   AVX const  From SPR   To SPR  
> SPR<->SPR
> +;;  GPR store  GPR load   GPR move
> +;;  GPR li GPR lisGPR #
> +;;  FPR store  FPR load   FPR move
> +;;  AVX store  AVX store  AVX load   AVX load   VSX move
> +;;  P9 0   P9 -1  AVX 0/-1   VSX 0  VSX -1
> +;;  P9 const   AVX const
> +;;  From SPR   To SPR SPR<->SPR
>  ;;  VSX->GPR   GPR->VSX
> +

Please do not add empty lines in the middle of a definition.  Also in
the movsi patch, if I missed it there.

> +   "store,  load,*,

There's a stray tab here (pre-existing, but fix please).

> +*,  *,  *,
> +*,  *")
> +   (set_attr "num_insns"
> +"*, *, *,
> +*,  *, 5,

Indent is wrong here (second line should have one column more -- or
probably the first should have one less.  Hard to tell, since it doesn't
use tabs to indent (as it should)).

Okay for trunk with the changelg and layout fixed.  Thanks!


Segher

[Bug ipa/92697] IPA-SRA modifies ifunc_resolvers

[jamborm at gcc dot gnu.org]

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

--- Comment #1 from Martin Jambor  ---
And for the record, I'm testing a patch.

Re: Prevent all uses of DFP when unsupported (PR c/91985)

[Jakub Jelinek]

On Wed, Nov 27, 2019 at 05:48:21PM +, Joseph Myers wrote:
> > > On 26/11/19 00:57 +, Joseph Myers wrote:
> > >>On Mon, 25 Nov 2019, Rainer Orth wrote:
> > >>
> > >>> and a few more, all DFP related.  They used to be emitted by g++ for
> > >>> __fundamental_type_info in libsupc++/fundamental_type_info.cc and lived
> > >>> in the CXXABI_1.3.4 version.  However, since Solaris *does* lack DFP
> > >>> support, that's no longer the case.  I'm uncertain how best to deal with
> > >>> this, however.
> > >>
> > >>As I understand it, _GLIBCXX_USE_DECIMAL_FLOAT should already have been
> > >>undefined for this target, and so std::decimal::decimal32 etc. should not
> > >>have been usable (both the header not working without that define, and the
> > >>mode attributes in the header being rejected by the front end when DFP is
> > >>unsupported).  I.e. such defines in libsupc++ would never have been usable
> > >>on this target, so I think they are something it should be safe to remove
> > >>from the ABI baseline.
> > >
> > > If it's actually impossible that any real program could have depended
> > > on those symbols, then I agree.
> > 
> > this is exactly what I've got no way of telling, that's why I was asking
> > for guidance.  Just removing the DFP symbols from the baselines works,
> > of course.
> 
> I don't think any real program could have used those symbols; it would 
> have required using __typeof (__builtin_fabsd32 (0)) or similar to access 
> types that weren't normally available for those targets (and by accessing 
> the types using builtins like that, you're getting a completely undefined 
> function-calling ABI for them anyway).

I think various tools we use to check ABI will be unhappy about removal
of symbols.  Can't we on targets that do support aliases and don't support
decimal float e.g. alias the DFP rtti symbols to void rtti symbols?

Jakub

Re: [patch, libgomp] Add tests for print from offload target

[Thomas Schwinge]

Hi!

On 2019-11-14T18:22:39+0100, Jakub Jelinek  wrote:
> On Thu, Nov 14, 2019 at 05:18:41PM +, Andrew Stubbs wrote:
>> On 14/11/2019 17:05, Jakub Jelinek wrote:
>> > On Thu, Nov 14, 2019 at 04:47:49PM +, Andrew Stubbs wrote:
>> > > This patch adds new libgomp tests to ensure that C "printf" and Fortran
>> > > "write" work correctly within offload kernels.

Thanks.

>> > > Both should work for amdgcn,
>> > > but nvptx uses the libgfortran "minimal" mode which lacks "write" 
>> > > support.
>> > 
>> > So, do those *.f90 testcases now FAIL with nvptx offloading?

Note that for libgomp OpenMP testing that means FAIL as soon as nvptx
plus possibly any other offload targets are configured, as we will always
compile for all offload targets, as no specific '-foffload' gets passed
-- in contrast to the libgomp OpenACC testing.  (Changing that would be a
separate discussion.)

>> > If yes, perhaps there should be effective target check that it is not nvptx
>> > offloading.

>> Here's the version with the nvptx xfails.
>> 
>> OK?
>
> Ok.

... but that doesn't work as expected:

{+ERROR: libgomp.fortran/target-print-1.f90   -O0 : can't read 
"openacc_device_type": no such variable for " dg-xfail-if 5 "no write for 
nvidia" { openacc_nvidia_accel_selected } "+}
[Etc.]

..., and:

{+XFAIL: libgomp.oacc-fortran/print-1.f90 -DACC_DEVICE_TYPE_nvidia=1 
-DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  (test for excess errors)+}
{+UNRESOLVED: libgomp.oacc-fortran/print-1.f90 -DACC_DEVICE_TYPE_nvidia=1 
-DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  compilation failed to produce 
executable+}
[Etc.]

To fix the ERRORs, I'm adding
'check_effective_target_offload_target_nvptx' to generally test whether
"compiling for offload target nvptx", and to fix the UNRESOLVEDs, I'm
adding separate "nvptx" variants, as I couldn't find a way to express the
'dg-*' directives in one combined file.  I want to actually see the nvptx
XFAILs, so that we'll notice XPASSes once/if nvptx switches away from the
minimal libgfortran.  (Changing that would be a separate discussion.)

Committed "Fix 'libgomp.fortran/target-print-1.f90',
'libgomp.oacc-fortran/print-1.f90' for offload target nvptx" to trunk in
r278779, see attached.


Grüße
 Thomas


From 21d18541ada7c3bdc70f92d9c79ced33a2f5f98a Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Wed, 27 Nov 2019 17:50:55 +
Subject: [PATCH] Fix 'libgomp.fortran/target-print-1.f90',
 'libgomp.oacc-fortran/print-1.f90' for offload target nvptx

	libgomp/
	* testsuite/lib/libgomp.exp
	(check_effective_target_offload_target_nvptx): New proc.
	* testsuite/libgomp.fortran/target-print-1.f90: Use it with
	'dg-skip-if'.
	* testsuite/libgomp.oacc-fortran/print-1.f90: Likewise.
	* testsuite/libgomp.fortran/target-print-1-nvptx.f90: New file.
	* testsuite/libgomp.oacc-fortran/print-1-nvptx.f90: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@278779 138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog | 10 +
 libgomp/testsuite/lib/libgomp.exp | 21 +++
 .../libgomp.fortran/target-print-1-nvptx.f90  | 11 ++
 .../libgomp.fortran/target-print-1.f90|  6 --
 .../libgomp.oacc-fortran/print-1-nvptx.f90| 11 ++
 .../libgomp.oacc-fortran/print-1.f90  |  6 --
 6 files changed, 61 insertions(+), 4 deletions(-)
 create mode 100644 libgomp/testsuite/libgomp.fortran/target-print-1-nvptx.f90
 create mode 100644 libgomp/testsuite/libgomp.oacc-fortran/print-1-nvptx.f90

diff --git a/libgomp/ChangeLog b/libgomp/ChangeLog
index 65478302ba8..d8d76ba3ce8 100644
--- a/libgomp/ChangeLog
+++ b/libgomp/ChangeLog
@@ -1,3 +1,13 @@
+2019-11-27  Thomas Schwinge  
+
+	* testsuite/lib/libgomp.exp
+	(check_effective_target_offload_target_nvptx): New proc.
+	* testsuite/libgomp.fortran/target-print-1.f90: Use it with
+	'dg-skip-if'.
+	* testsuite/libgomp.oacc-fortran/print-1.f90: Likewise.
+	* testsuite/libgomp.fortran/target-print-1-nvptx.f90: New file.
+	* testsuite/libgomp.oacc-fortran/print-1-nvptx.f90: Likewise.
+
 2019-11-21  Rainer Orth  
 
 	* testsuite/libgomp.c/pr39591-1.c: Rename err to e.
diff --git a/libgomp/testsuite/lib/libgomp.exp b/libgomp/testsuite/lib/libgomp.exp
index 74d032623c9..06e3186d966 100644
--- a/libgomp/testsuite/lib/libgomp.exp
+++ b/libgomp/testsuite/lib/libgomp.exp
@@ -336,6 +336,27 @@ proc offload_target_to_openacc_device_type { offload_target } {
 }
 }
 
+# Return 1 if compiling for offload target nvptx.
+proc check_effective_target_offload_target_nvptx { } {
+# Consider all actual options, including the flags passed to
+# 'gcc-dg-runtest', or 'gfortran-dg-runtest' (see the 'libgomp.*/*.exp'
+# files; in particular, '-foffload', 'libgomp.oacc-*/*.exp'), which don't
+# get passed on to 'check_effective_target_*' functions.  (Not caching the
+# result due to that.)
+set options [current_compiler_flags]
+# Instead of inspecting command-line 

Re: [PATCH] Translate header for -fdbg-cnt-list.

[Joseph Myers]

On Wed, 27 Nov 2019, Martin Liška wrote:

> Hi.
> 
> The patch is about translation of titles in -fdbg-cnt-list table.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?

OK.

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

Re: Prevent all uses of DFP when unsupported (PR c/91985)

[Joseph Myers]

On Wed, 27 Nov 2019, Rainer Orth wrote:

> Hi Jonathan,
> 
> > On 26/11/19 00:57 +, Joseph Myers wrote:
> >>On Mon, 25 Nov 2019, Rainer Orth wrote:
> >>
> >>> and a few more, all DFP related.  They used to be emitted by g++ for
> >>> __fundamental_type_info in libsupc++/fundamental_type_info.cc and lived
> >>> in the CXXABI_1.3.4 version.  However, since Solaris *does* lack DFP
> >>> support, that's no longer the case.  I'm uncertain how best to deal with
> >>> this, however.
> >>
> >>As I understand it, _GLIBCXX_USE_DECIMAL_FLOAT should already have been
> >>undefined for this target, and so std::decimal::decimal32 etc. should not
> >>have been usable (both the header not working without that define, and the
> >>mode attributes in the header being rejected by the front end when DFP is
> >>unsupported).  I.e. such defines in libsupc++ would never have been usable
> >>on this target, so I think they are something it should be safe to remove
> >>from the ABI baseline.
> >
> > If it's actually impossible that any real program could have depended
> > on those symbols, then I agree.
> 
> this is exactly what I've got no way of telling, that's why I was asking
> for guidance.  Just removing the DFP symbols from the baselines works,
> of course.

I don't think any real program could have used those symbols; it would 
have required using __typeof (__builtin_fabsd32 (0)) or similar to access 
types that weren't normally available for those targets (and by accessing 
the types using builtins like that, you're getting a completely undefined 
function-calling ABI for them anyway).

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

[Bug lto/91273] [8/9/10 Regression] ICE in warn_types_mismatch at ipa-devirt.c:995

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #11 from Martin Liška  ---
Dup.

*** This bug has been marked as a duplicate of bug 91222 ***

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[marxin at gcc dot gnu.org]

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

--- Comment #30 from Martin Liška  ---
*** Bug 91273 has been marked as a duplicate of this bug. ***

[Bug bootstrap/92661] [10 Regression] Bootstrap failure with builtin-types.def change

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 CC||green at redhat dot com

--- Comment #7 from Joseph S. Myers  ---
*** Bug 92694 has been marked as a duplicate of this bug. ***

[Bug target/92694] Can't build powerpc-eabi cross compiler: : fatal error: internal error: builtin function ‘__builtin_ddedpd’ had an unexpected return type ‘DD’

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Joseph S. Myers  ---
Duplicate.

*** This bug has been marked as a duplicate of bug 92661 ***

Re: [PATCH] Reformat PowerPC movsi_internal

[Segher Boessenkool]

Hi Mike,

On Tue, Nov 26, 2019 at 08:32:12PM -0500, Michael Meissner wrote:
> As we discussed in the V6 patches #1 and #2, before submitting the patches
> adding eI support for movdi and movsi, you prefered that I reformat the 
> patches
> to make them easier in the future to identify the changes.

No, that is not the reason.  It is to make it easier to handle patches
(review, revert, rebase, backport, etc.)  A patch should do one thing.

If you need to (say) rebase a big patch that merely changes layout, that
is not so hard to do (just a bit tedious sometimes).  If there are actual
changes mixed in...  *good luck*!

> This patch changes just the movsi_internal insn.  All of the constraints are 
> in
> the same order as the current sources.  I did add setting "num_insns" to this
> patch, but I left in setting "length".  I found otherwise the Spec benchmarks
> did not generate the same code with the patch.

Yes, "length" is still required everywhere, as I said before.  This is a
big problem.

>   * config/rs6000/rs6000.md (movsi_internal): Logically align the
>   columns of constraints and attributes to make it easier to add new
>   patterns in the middle.  Set the num_insns insn attribute.

* config/rs6000/rs6000.md (movsi_internal): Reformat.
(and the attribute thing, yes, if you have to do that in this same patch.
Please don't, in the future.)

> --- gcc/config/rs6000/rs6000.md   (revision 278746)
> +++ gcc/config/rs6000/rs6000.md   (working copy)
> @@ -6889,24 +6889,36 @@ (define_split
>UNSPEC_MOVSI_GOT))]
>"")
>  
> -;;   MR   LA   LWZ  LFIWZX   LXSIWZX
> -;;   STW  STFIWX   STXSIWX  LI   LIS
> -;;   #XXLORXXSPLTIB 0   XXSPLTIB -1  VSPLTISW
> -;;   XXLXOR 0 XXLORC -1P9 const MTVSRWZ  MFVSRWZ
> -;;   MF%1 MT%0 NOP
> +;;  MR   LA
> +;;  LWZ  LFIWZX  LXSIWZX
> +;;  STW  STFIWX  STXSIWX
> +;;  LI   LIS #
> +;;  XXLORXXSPLTIB 0  XXSPLTIB -1 VSPLTISW
> +;;  XXLXOR 0 XXLORC -1   P9 const
> +;;  MTVSRWZ  MFVSRWZ
> +;;   MF%1 MT%0NOP

That has broken whitespace (mixing tabs and spaces).  All eight leading
spaces should be tabs, not just on some lines and not the others.

(Similar later, please fix all).

> + "*, *,
> + load,   fpload, fpload,
> + store,  fpstore,fpstore,
> + *,  *,  *,
> + veclogical, vecsimple,  vecsimple,  vecsimple,
> + veclogical, veclogical, vecsimple,
> + mffgpr, mftgpr,
> + *,  *,  *")
> (set_attr "length"
> - "*,  *,   *,   *,   *,
> -  *,  *,   *,   *,   *,
> -  8,  *,   *,   *,   *,
> -  *,  *,   8,   *,   *,
> -  *,  *,   *")
> + "*, *,
> + *,  *,   *,
> + *,  *,   *,
> + *,  *,   8,
> + *,  *,   *,  *,
> + *,  *,   8,
> + *,  *,   *,
> + *,  *")

You have 2 and 3 on the last two lines elsewhere.

> +   (set_attr "num_insns"
> + "*,  *,
> + *,   *, *,
> + *,   *, *,
> + *,   *, 2,
> + *,   *, *,  *,
> + *,   *, 2,
> + *,   *,
> + *,   *, *")

Different indent on the columns here (that is true elsewhere, too).
It would help a lot if you kept all columns the same width, too.

Okay for trunk with the changelog and the layout fixed.  Thanks!


Segher

[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 47383
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47383=edit
gcc10-pr92695.patch

And here is a fix for the bogus warning.  inline or constexpr on pure virtual
functions looks useless, but the standard doesn't disallow that it seems.

Re: Branch and tag deletions

[Joseph Myers]

On Wed, 27 Nov 2019, Eric S. Raymond wrote:

> Joseph Myers :
> > My current test conversion run is testing two changes: deleting 
> > emptycommit tags, and using --user-ignores to prefer the .gitignore file 
> > in SVN over one auto-generated from svn:ignore properties.  For the next 
> > one after that I'll try eliminating all branch/tag removals that shouldn't 
> > be doing anything, based on the current sets of branches and tags in SVN, 
> > and report bugs if I see anything appearing in the converted repository 
> > that shouldn't be.
> 
> I'm more worried about missing files. I saw a bunch of those on my
> last test.  This could be spurious - the elaborate set of branch
> mappings you specified confuses my validation test, because there is
> no longer a 1-1 corresponsence between Subversion and git branches.

I'm hoping any such missing file problems come from bugs in the old SVN 
dump reader with complicated commits mixing copies / deletions / 
replacements with copies from other locations and that your rewrite will 
fix the semantics in such cases.

All the current gcc-conversion merge requests, both mine and Richard's, 
should now be set to allow rebasing.

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

[Bug rtl-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[rguenther at suse dot de]

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

--- Comment #25 from rguenther at suse dot de  ---
On November 27, 2019 2:36:38 PM GMT+01:00, "vmakarov at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
>
>--- Comment #24 from Vladimir Makarov  ---
>(In reply to Richard Biener from comment #23)
>> Vladimir, can you look into this LRA inheritance issue?
>
>Yes, I've started to work on this.  I can not reproduce it on the
>current
>trunk.  But yesterday, I've reproduced it on the revision mentioned in
>the
>title.
>
>Inheritance problems are usually hard to fix.  So I can not say when I
>find a
>reason for the problem and solution for it.  But I guess it will be
>fixed on
>the next week

Heh, no problem. It took me a week to nail down the actual issue as well...

Re: [Patch, gcc-wwdocs] Update to Fortran changes

[Mark Eggleston]

On 27/11/2019 08:29, Tobias Burnus wrote:

On 11/27/19 8:58 AM, Janne Blomqvist wrote:
On Tue, Nov 26, 2019 at 1:12 PM Tobias Burnus 
 wrote:

AUTOMATIC attribute

Speaking of which, to avoid confusion maybe we should rename the
-f[no-]automatic option to something like -f[no-]save, since the
Fortran standard description of an "automatic data object" doesn't
really have anything to do with the option, and neither does the
option have anything to do specifically with the DEC AUTOMATIC
specifier?


-fno-automatic means that all local variables are saved however a local 
variable can still be automatic if it explicitly has the AUTOMATIC 
attribute, this is only possible with -fdec-static/-fdec, it is not 
possible in standard fortran, SAVE equates to STATIC but there is no 
standard attribute that equates to AUTOMATIC.


regards

Mark



While in principle I concur that the naming is bad, I fear this will 
break several makefiles – hence, I am not sure it is worth the trouble 
– and I am declined to say that it isn't.


Cheers,

Tobias



--
https://www.codethink.co.uk/privacy.html

Re: Branch and tag deletions

[Eric S. Raymond]

Joseph Myers :
> My current test conversion run is testing two changes: deleting 
> emptycommit tags, and using --user-ignores to prefer the .gitignore file 
> in SVN over one auto-generated from svn:ignore properties.  For the next 
> one after that I'll try eliminating all branch/tag removals that shouldn't 
> be doing anything, based on the current sets of branches and tags in SVN, 
> and report bugs if I see anything appearing in the converted repository 
> that shouldn't be.

I'm more worried about missing files. I saw a bunch of those on my
last test.  This could be spurious - the elaborate set of branch
mappings you specified confuses my validation test, because there is
no longer a 1-1 corresponsence between Subversion and git branches.

The next test I run I'm going to comment out your branch mappings.
If I get a validated conversion out of that I think it's all over
but the cleanup and policy tinkering.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

[Bug target/92693] Inconsistency between __UINTPTR_TYPE__ and __UINT32_TYPE__ on ARM

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from Andrew Pinski  ---
Or just use the foundalmential types instead. And then layer above them.

[Bug preprocessor/92696] #pragma GCC diagnostic ... interferes with if/else

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Also #pragma are considered statements.  There is another issue like this but
instead using _Pragma .

[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|mpolacek at gcc dot gnu.org|jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Created attachment 47382
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47382=edit
gcc10-pr92695.patch

Untested fix.

[Bug rtl-optimization/92510] [10 Regression] ICE in native_encode_rtx, at simplify-rtx.c:6272

[rsandifo at gcc dot gnu.org]

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
(In reply to rsand...@gcc.gnu.org from comment #7)
> As Jakub mentioned in comment 1, the native_encode_rtx ICE is coming
> from the call:
> 
>   simplify_subreg (DImode, const1_rtx, V1DImode, 0)
>// (outermode, op, innermode, byte)
> 
> i.e. the caller is claiming that the inner const1_rtx has mode V1DI.
> And that can't be true, because vector constants have to be const_vectors
> rather than const_ints.  (The combination of outermode, innermode and op

I meant "byte" rather than "op" :-)

> are fine of course.  The problem is "just" that the given innermode
> doesn't match the inner rtx.)

[Bug rtl-optimization/92510] [10 Regression] ICE in native_encode_rtx, at simplify-rtx.c:6272

[rsandifo at gcc dot gnu.org]

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
(In reply to Segher Boessenkool from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > I don't mind if simplify_subreg doesn't call native_encode_rtx in the cases
> > where it ICEs and instead fails.
> 
> I don't think native_encode_rtx (or simplify_immed_subreg) should ICE for
> any valid input.  This is valid input, for this API.

As Jakub mentioned in comment 1, the native_encode_rtx ICE is coming
from the call:

  simplify_subreg (DImode, const1_rtx, V1DImode, 0)
   // (outermode, op, innermode, byte)

i.e. the caller is claiming that the inner const1_rtx has mode V1DI.
And that can't be true, because vector constants have to be const_vectors
rather than const_ints.  (The combination of outermode, innermode and op
are fine of course.  The problem is "just" that the given innermode
doesn't match the inner rtx.)

So IMO the ICE is justified and we shouldn't change change simplify_subreg
to handle cases in which innermode doesn't tally with op/GET_MODE (op).

[Bug rtl-optimization/92510] [10 Regression] ICE in native_encode_rtx, at simplify-rtx.c:6272

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 27 16:32:54 2019
New Revision: 278777

URL: https://gcc.gnu.org/viewcvs?rev=278777=gcc=rev
Log:
PR rtl-optimization/92510
* combine.c (gen_lowpart_for_combine): Only transform lowpart subreg
of comparison into a comparison with different mode if both imode and
omode are scalar integral modes.

* gcc.dg/pr92510.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr92510.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference QoI issue

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Either the function guarantees that *seq will be always non-NULL (at least if
the call doesn't return negative), but then there is no point in using out &&
*out, you can as well just use *out, because out will never be NULL.  Or the
function doesn't guarantee it and if it is NULL, the code will crash.

[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference QoI issue

[zhroma at gcc dot gnu.org]

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

--- Comment #6 from Roman Zhuykov  ---
Ok, this seems quite clear from compiler developer point of view.

But I still want to add, that for compiler user, who knows how asprintf
function works, "Line A" version is correct and warning seems unnecessary.
While "Line B" version where user forget about bail-out is compiled smoothly.

[Bug ipa/92697] New: IPA-SRA modifies ifunc_resolvers

[jamborm at gcc dot gnu.org]

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

Bug ID: 92697
   Summary: IPA-SRA modifies ifunc_resolvers
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: jamborm at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47381
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47381=edit
testcase

In the attached testcase, IPA-SRA thinks that an ifunc resolver
(meanwhile IPA-split into two functions) function can be changed and
so goes ahead.  The cgraph machinery then however throws away the new
clone of the caller instead of the "old" caller and inliner inlines
the clone of the ".part" function into the original resolver, which
results into an interesting miscompilation because IPA-SRA counted on
that both the caller and the callee are modified.

In any event, changing the signature of an ifunc resolver must not be
done.

[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063

[zhroma at gcc dot gnu.org]

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

--- Comment #3 from Roman Zhuykov  ---
Created attachment 47380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47380=edit
Parameters patch