Re: [PATCH 0/4 GCC11] IVOPTs consider step cost for different forms when unrolling

[Segher Boessenkool]

On Tue, Feb 11, 2020 at 08:34:15AM +0100, Richard Biener wrote:
> On Mon, 10 Feb 2020, Segher Boessenkool wrote:
> > Yes, we should decide how often we want to unroll things somewhere before
> > ivopts already, and just use that info here.
> > 
> > Or are there advantage to doing it *in* ivopts?  It sounds like doing
> > it there is probably expensive, but maybe not, and we need to do similar
> > analysis there anyway.
> 
> Well, if the only benefit of doing the unrolling is that IVs get
> cheaper then yes, IVOPTs should drive it.

We need to know much earlier in the pass pipeline how often a loop will
be unrolled.  We don't have to *do* it early.

If we want to know it before ivopts, then obviously it has to be done
earlier.  Otherwise, maybe it is a good idea to do it in ivopts itself.
Or maybe not.  It's just an idea :-)

We know we do not want it *later*, ivopts needs to know this to make
good decisions of its own.

> But usually unrolling exposes redundancies (catched by predictive
> commoning which drives some unrolling) or it enables better use
> of CPU resources via scheduling (only catched later in RTL).
> For scheduling we have the additional complication that the RTL
> side doesn't have as much of a fancy data dependence analysis
> framework as on the GIMPLE side.  So I'd put my bet on trying to
> move something like SMS to GIMPLE and combine it with unrolling
> (IIRC SMS at most interleaves 1 1/2 loop iterations).

SMS on RTL always was quite disappointing...  Do you expect it will be
more useful on Gimple?  Moving it there is a good idea in any case ;-)

I don't quite see the synergy between SMS and loop unrolling, but maybe
I need to look harder.


Segher

New Chinese (traditional) PO file for 'cpplib' (version 10.1-b20200209)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'cpplib' has been submitted
by the Chinese (traditional) team of translators.  The file is available at:

https://translationproject.org/latest/cpplib/zh_TW.po

(This file, 'cpplib-10.1-b20200209.zh_TW.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Contents of PO file 'cpplib-10.1-b20200209.zh_TW.po'

[Translation Project Robot]

cpplib-10.1-b20200209.zh_TW.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New Chinese (traditional) PO file for 'gcc' (version 10.1-b20200209)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/gcc/zh_TW.po

(This file, 'gcc-10.1-b20200209.zh_TW.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH 0/4 GCC11] IVOPTs consider step cost for different forms when unrolling

[Richard Biener]

On Mon, 10 Feb 2020, Segher Boessenkool wrote:

> Hi!
> 
> On Mon, Feb 10, 2020 at 02:17:04PM +0800, Kewen.Lin wrote:
> > on 2020/1/20 下午8:33, Segher Boessenkool wrote:
> > > On Thu, Jan 16, 2020 at 05:36:52PM +0800, Kewen.Lin wrote:
> > >> As we discussed in the thread
> > >> https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00196.html
> > >> Original: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00104.html,
> > >> I'm working to teach IVOPTs to consider D-form group access during 
> > >> unrolling.
> > >> The difference on D-form and other forms during unrolling is we can put 
> > >> the
> > >> stride into displacement field to avoid additional step increment. eg:
> > > 
> > > 
> > > 
> > >> Imagining that if the loop get unrolled by 8 times, then 3 step updates 
> > >> with
> > >> D-form vs. 8 step updates with X-form. Here we only need to check stride
> > >> meet D-form field requirement, since if OFF doesn't meet, we can 
> > >> construct
> > >> baseA' with baseA + OFF.
> > > 
> > > So why doesn't the existing code do this already?  Why does it make all
> > > the extra induction variables?  Is the existing cost model bad, are our
> > > target costs bad, or something like that?
> > > 
> > 
> > I think the main cause is IVOPTs runs before RTL unroll, when it's 
> > determining
> > the IV sets, it can only take the normal step cost into account, since its
> > input isn't unrolled yet.  After unrolling, the x-form indexing register 
> > has to
> > play with more UF-1 times update, but we can probably hide them in d-form
> > displacement field.  The way I proposed here is to adjust IV cost with
> > additional cost_step according to estimated unroll.  It doesn't introduce 
> > new
> > IV cand but can affect the final optimal set.
> 
> Yes, we should decide how often we want to unroll things somewhere before
> ivopts already, and just use that info here.
> 
> Or are there advantage to doing it *in* ivopts?  It sounds like doing
> it there is probably expensive, but maybe not, and we need to do similar
> analysis there anyway.

Well, if the only benefit of doing the unrolling is that IVs get
cheaper then yes, IVOPTs should drive it.

But usually unrolling exposes redundancies (catched by predictive
commoning which drives some unrolling) or it enables better use
of CPU resources via scheduling (only catched later in RTL).
For scheduling we have the additional complication that the RTL
side doesn't have as much of a fancy data dependence analysis
framework as on the GIMPLE side.  So I'd put my bet on trying to
move something like SMS to GIMPLE and combine it with unrolling
(IIRC SMS at most interleaves 1 1/2 loop iterations).

Richard.

Re: coroutines: Update to n4849 allocation/deallocation.

[Nathan Sidwell]

On 2/7/20 1:06 PM, Iain Sandoe wrote:

Hi,

This is the first of the (small number of) anticipated changes to bring
the implementation into line with the latest published C++20 draft (this
is now expected to be very close to the final, although some wording
might still be adjusted).

The allocation for the coroutine state frame is quite flexible - which means
in reality a number of permutations to cater for and to test for.

Partial or complete adoption of p2014r0 would be additive to this, but it
seems better to me to separate changes for that to a future patch.

Because of the number of permutations, the error messages are somewhat
long-winded in an effort to point the user to the specific problem.

OK for trunk?
thanks
Iain



This updates the coroutine frame allocation and deallocation usage to
match n4849.

[dcl.fct.def.coroutine] /9, /10, /12.

9 An implementation may need to allocate additional storage for a coroutine.
   This storage is known as the coroutine state and is obtained by calling a
   non-array allocation function.  The allocation function’s name is looked up
   in the scope of the promise type.  If this lookup fails, the allocation
   function’s name is looked up in the global scope.  If the lookup finds an
   allocation function in the scope of the promise type, overload resolution
   is performed on a function call created by assembling an argument list.
   The first argument is the amount of space requested, and has type
   std::size_t.  The lvalues p1 . . . pn are the succeeding [user's function]
   arguments. If no viable function is found, overload resolution is performed
   again on a function call created by passing just the amount of space required
   as an argument of type std::size_t.

10 The unqualified-id get_return_object_on_allocation_failure is looked up in
   the scope of the promise type by class member access lookup. If any
   declarations are found, then the result of a call to an allocation function
   used to obtain storage for the coroutine state is assumed to return nullptr
   if it fails to obtain storage, and if a global allocation function is
   selected, the ::operator new(size_t, nothrow_t) form is used. The allocation
   function used in this case shall have a non-throwing noexcept-specification.
   If the allocation function returns nullptr, the coroutine returns control to
   the caller of the coroutine and the return value is obtained by a call to
   T::get_return_object_on_allocation_failure(), where T is the promise type.

12 The deallocation function’s name is looked up in the scope of the promise
   type. If this lookup fails, the deallocation function’s name is looked up in
   the global scope.  If deallocation function lookup finds both a usual
   deallocation function with only a pointer parameter and a usual deallocation
   function with both a pointer parameter and a size parameter, then the
   selected deallocation function shall be the one with two parameters.
   Otherwise, the selected deallocation function shall be the function with one
   parameter. If no usual deallocation function is found, the program is ill-
   formed.  The selected deallocation function shall be called with the address
   of the block of storage to be reclaimed as its first argument.  If a
   deallocation function with a parameter of type std::size_t is used, the size
   of the block is passed as the corresponding argument.

gcc/cp/ChangeLog:

2020-02-07  Iain Sandoe  

* coroutines.cc (build_actor_fn): Implement deallocation function
selection per n4849, dcl.fct.def.coroutine bullet 12.
(morph_fn_to_coro): Implement allocation function selection per
n4849, dcl.fct.def.coroutine bullets 9 and 10.

gcc/testsuite/ChangeLog:



This is ok.  I was having a dumb wrt to the type_size thing we talked about.


nathan


--
Nathan Sidwell

Re: [PATCH], Rename and document PowerPC -mprefixed-addr to -mprefixed

[Segher Boessenkool]

On Mon, Feb 10, 2020 at 10:22:37PM -0600, Bill Schmidt wrote:
> On 2/10/20 9:24 PM, Segher Boessenkool wrote:
> >>If you use -mpcrel, the compiler will generate PC-relative
> >>loads and stores to access items, rather than the current TOC based loads 
> >>and
> >>stores.
> >Where that is the best thing to do.  Is that always now?  :-)
> 
> Yes.  :-)

Ah right, -mcmodel=medium is required, that makes many things much easier.


Segher

Re: [PATCH 1/4 v3 GCC11] Add middle-end unroll factor estimation

[Segher Boessenkool]

Hi!

On Tue, Feb 11, 2020 at 02:50:03PM +0800, Kewen.Lin wrote:
> v3 changes:
>   - Updated _uf to _unroll for some function names.

Thanks.

> By the way, should I guard the current i386/s390 loop_unroll_adjust
> ealy return with (current_pass->type != RTL_PASS)?  I'm inclined not
> to, since this analysis isn't enabled by default, if those targets
> want to adopt this analysis, they will get ICE immediately then users
> can notice it and make up the gimple part check.  A guard can make
> ICE disappear but the hook works poorly silently, users probably miss
> to update it.

Just tell the maintainers of those ports about it?  They are responsive,
and of course they will know what they will want to do :-)


Segher

[PATCH 1/4 v3 GCC11] Add middle-end unroll factor estimation

[Kewen.Lin]

Hi,

v3 changes:
  - Updated _uf to _unroll for some function names.

By the way, should I guard the current i386/s390 loop_unroll_adjust
ealy return with (current_pass->type != RTL_PASS)?  I'm inclined not
to, since this analysis isn't enabled by default, if those targets
want to adopt this analysis, they will get ICE immediately then users
can notice it and make up the gimple part check.  A guard can make
ICE disappear but the hook works poorly silently, users probably miss
to update it.

BR,
Kewen

-

gcc/ChangeLog

2020-02-11  Kewen Lin  

* cfgloop.h (struct loop): New field estimated_unroll.
* tree-ssa-loop-manip.c (decide_unroll_const_iter): New function.
(decide_unroll_runtime_iter): Likewise.
(decide_unroll_stupid): Likewise.
(estimate_unroll_factor): Likewise.
* tree-ssa-loop-manip.h (estimate_unroll_factor): New declaration.
* tree-ssa-loop.c (tree_average_num_loop_insns): New function.
* tree-ssa-loop.h (tree_average_num_loop_insns): New declaration.

on 2020/2/11 上午7:34, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, Feb 10, 2020 at 02:20:17PM +0800, Kewen.Lin wrote:
>>  * tree-ssa-loop-manip.c (decide_uf_const_iter): New function.
>>  (decide_uf_runtime_iter): Likewise.
>>  (decide_uf_stupid): Likewise.
> 
> These names still use "uf".  (Those are the last I see).
> 

Good catch!

>>  * tree-ssa-loop-manip.h (estimate_unroll_factor): New declare.
> 
> "New declaration."
>
Done.

---
 gcc/cfgloop.h |   3 +
 gcc/tree-ssa-loop-manip.c | 253 ++
 gcc/tree-ssa-loop-manip.h |   3 +-
 gcc/tree-ssa-loop.c   |  33 ++
 gcc/tree-ssa-loop.h   |   2 +
 5 files changed, 292 insertions(+), 2 deletions(-)

diff --git a/gcc/cfgloop.h b/gcc/cfgloop.h
index 11378ca..c5bcca7 100644
--- a/gcc/cfgloop.h
+++ b/gcc/cfgloop.h
@@ -232,6 +232,9 @@ public:
  Other values means unroll with the given unrolling factor.  */
   unsigned short unroll;
 
+  /* Like unroll field above, but it's estimated in middle-end.  */
+  unsigned short estimated_unroll;
+
   /* If this loop was inlined the main clique of the callee which does
  not need remapping when copying the loop body.  */
   unsigned short owned_clique;
diff --git a/gcc/tree-ssa-loop-manip.c b/gcc/tree-ssa-loop-manip.c
index 120b35b..8a5a1a9 100644
--- a/gcc/tree-ssa-loop-manip.c
+++ b/gcc/tree-ssa-loop-manip.c
@@ -21,6 +21,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "system.h"
 #include "coretypes.h"
 #include "backend.h"
+#include "target.h"
 #include "tree.h"
 #include "gimple.h"
 #include "cfghooks.h"
@@ -42,6 +43,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "cfgloop.h"
 #include "tree-scalar-evolution.h"
 #include "tree-inline.h"
+#include "wide-int.h"
 
 /* All bitmaps for rewriting into loop-closed SSA go on this obstack,
so that we can free them all at once.  */
@@ -1592,3 +1594,254 @@ canonicalize_loop_ivs (class loop *loop, tree *nit, 
bool bump_in_latch)
 
   return var_before;
 }
+
+/* Try to determine estimated unroll factor for given LOOP with constant number
+   of iterations, mainly refer to decide_unroll_constant_iterations.
+- NITER_DESC holds number of iteration description if it isn't NULL.
+- NUNROLL holds a unroll factor value computed with instruction numbers.
+- ITER holds estimated or likely max loop iterations.
+   Return true if it succeeds, also update estimated_unroll.  */
+
+static bool
+decide_unroll_const_iter (class loop *loop, const tree_niter_desc *niter_desc,
+ unsigned nunroll, const widest_int *iter)
+{
+  /* Skip big loops.  */
+  if (nunroll <= 1)
+return false;
+
+  gcc_assert (niter_desc && niter_desc->assumptions);
+
+  /* Check number of iterations is constant, return false if no.  */
+  if ((niter_desc->may_be_zero && !integer_zerop (niter_desc->may_be_zero))
+  || !tree_fits_uhwi_p (niter_desc->niter))
+return false;
+
+  unsigned HOST_WIDE_INT const_niter = tree_to_uhwi (niter_desc->niter);
+
+  /* If unroll factor is set explicitly, use it as estimated_unroll.  */
+  if (loop->unroll > 0 && loop->unroll < USHRT_MAX)
+{
+  /* It should have been peeled instead.  */
+  if (const_niter == 0 || (unsigned) loop->unroll > const_niter - 1)
+   loop->estimated_unroll = 1;
+  else
+   loop->estimated_unroll = loop->unroll;
+  return true;
+}
+
+  /* Check whether the loop rolls enough to consider.  */
+  if (const_niter < 2 * nunroll || wi::ltu_p (*iter, 2 * nunroll))
+return false;
+
+  /* Success; now compute number of iterations to unroll.  */
+  unsigned best_unroll = 0, n_copies = 0;
+  unsigned best_copies = 2 * nunroll + 10;
+  unsigned i = 2 * nunroll + 2;
+
+  if (i > const_niter - 2)
+i = const_niter - 2;
+
+  for (; i >= nunroll - 1; i--)
+{
+  unsigned exit_mod = const_niter % (i + 1);
+
+  if (!empty_block_p 

[PATCH] Make __glibcxx_assert constexpr compatible

[François Dumont]

By making __glibcxx_assert constexpr compatible we can get rid of a 
FIXME in basic_string_view and so fix following XPASS in _GLIBCXX_DEBUG 
modes.


XPASS: 21_strings/basic_string_view/element_access/char/2.cc execution test
XPASS: 21_strings/basic_string_view/element_access/wchar_t/2.cc 
execution test


Should I also rename those in 2_neg.cc ?

I had to move the assert block in c++config to benefit from 
_GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED definition. The generation 
of the compilation error is not very nice but it is still better than no 
error and we can see the assertion:


/home/fdt/dev/gcc/git/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr_neg.cc:31:22: 
erreur: condition non constante pour l'assertion statique
   31 | static_assert(test() == 0); // { dg-error "non-constant 
condition" }

  |   ~~~^~~~
Dans le fichier inclus depuis 
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/limits:42,
 depuis 
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/string_view:40,
 depuis 
/home/fdt/dev/gcc/git/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr_neg.cc:21:
/home/fdt/dev/gcc/git/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr_neg.cc:31:19: 
dans l'expansion « constexpr » de « test() »
/home/fdt/dev/gcc/git/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr_neg.cc:28:13: 
dans l'expansion « constexpr » de 
« s.std::basic_string_view::operator[](4) »
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/string_view:206:2: 
erreur: inline assembly is not a constant expression

  206 |  __glibcxx_assert(__pos < this->_M_len);
  |  ^~~~
/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/string_view:206:2: 
note: only unevaluated inline assembly is allowed in a « constexpr » 
function in C++2a


    * include/bits/c++config
[_GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED](__glibcxx_assert_impl):
    New.
    * include/std/string_view 
(basic_string_view<>:operator[](size_type)):

    Restore __glibcxx_assert.
    (basic_string_view<>::front()): Likewise.
    (basic_string_view<>::back()): Likewise.
    * 
testsuite/21_strings/basic_string_view/element_access/char/back_constexpr_neg.cc:

    New.
    * 
testsuite/21_strings/basic_string_view/element_access/char/constexpr.cc:

    New.
    * 
testsuite/21_strings/basic_string_view/element_access/char/constexpr_neg.cc:

    New.
    * 
testsuite/21_strings/basic_string_view/element_access/char/front_back_constexpr.cc:

    New.
    * 
testsuite/21_strings/basic_string_view/element_access/char/front_constexpr_neg.cc:

    New.
    * 
testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr.cc:

    New.
    * 
testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr_neg.cc:

    New.

Tested under Linux x86_64 normal and debug modes.

Ok to commit ?

François

diff --git a/libstdc++-v3/include/bits/c++config b/libstdc++-v3/include/bits/c++config
index b1fad59d4b3..4d821627447 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -441,37 +441,6 @@ namespace std
 # define _GLIBCXX_EXTERN_TEMPLATE -1
 #endif
 
-// Assert.
-#if defined(_GLIBCXX_ASSERTIONS) \
-  || defined(_GLIBCXX_PARALLEL) || defined(_GLIBCXX_PARALLEL_ASSERTIONS)
-namespace std
-{
-  // Avoid the use of assert, because we're trying to keep the 
-  // include out of the mix.
-  extern "C++" inline void
-  __replacement_assert(const char* __file, int __line,
-		   const char* __function, const char* __condition)
-  {
-__builtin_printf("%s:%d: %s: Assertion '%s' failed.\n", __file, __line,
-		 __function, __condition);
-__builtin_abort();
-  }
-}
-#define __glibcxx_assert_impl(_Condition) \
-  do 	 \
-  {			  		 \
-if (! (_Condition))  \
-  std::__replacement_assert(__FILE__, __LINE__, __PRETTY_FUNCTION__, \
-#_Condition); \
-  } while (false)
-#endif
-
-#if defined(_GLIBCXX_ASSERTIONS)
-# define __glibcxx_assert(_Condition) __glibcxx_assert_impl(_Condition)
-#else
-# define __glibcxx_assert(_Condition)
-#endif
-
 // Macros for race detectors.
 // _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(A) and
 // _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(A) should be used to explain
@@ -663,6 +632,53 @@ namespace std
 # endif
 #endif // GCC
 
+// Assert.
+#if defined(_GLIBCXX_ASSERTIONS) \
+  || defined(_GLIBCXX_PARALLEL) || defined(_GLIBCXX_PARALLEL_ASSERTIONS)
+namespace std
+{
+  // Avoid the use of assert, because we're trying to keep the 
+  // include out of the mix.
+  extern "C++" inline void
+  

Re: [PATCH], Rename and document PowerPC -mprefixed-addr to -mprefixed

[Bill Schmidt]

On 2/10/20 9:24 PM, Segher Boessenkool wrote:

Hi!

On Mon, Feb 10, 2020 at 01:45:42PM -0500, Michael Meissner wrote:

This patch renames the PowerPC internal switch -mprefixed-addr to be
-mprefixed.
If you use -mpcrel, you must be using the 64-bit ELF v2 ABI, and the code model
must be medium.

Currently, anyway.


If you use -mpcrel, the compiler will generate PC-relative
loads and stores to access items, rather than the current TOC based loads and
stores.

Where that is the best thing to do.  Is that always now?  :-)



Yes.  :-)

Bill




If you use -mpcrel, it implies -mprefixed.  If you use -mno-prefixed, you
cannot use -mpcrel.

-mno-prefixed should imply -mno-pcrel; does it?


* doc/invoke.texi (RS/6000 and PowerPC Options): Docment the

(typo)


--- /tmp/1ySv8k_invoke.texi 2020-02-07 17:56:52.700489015 -0500
+++ gcc/doc/invoke.texi 2020-02-07 17:34:02.925611138 -0500
@@ -22327,7 +22328,6 @@ faster on processors with 32-bit busses
  aligns structures containing the above types differently than
  most published application binary interface specifications for the m68k.
  
-@item -mpcrel

  @opindex mpcrel
  Use the pc-relative addressing mode of the 68000 directly, instead of
  using a global offset table.  At present, this option implies @option{-fpic},

This isn't a correct change.

Okay for trunk modulo the m68k change.  Thanks!


Segher

Re: [PATCH] Add ppc_ieee128_ok target-supports proc

[Segher Boessenkool]

Hi!

On Mon, Feb 10, 2020 at 03:39:49PM -0600, will schmidt wrote:
> This adds a target_supports entry to check that the
> _ieee128 keyword is understood by the target.

(Two underscores, "__ieee128".)

> Also adds that require-effective-target check to the
> existing pr92796 testcase.

> +# See if the __ieee128 keyword is understood.
> +proc check_effective_target_ppc_ieee128_ok { } {
> +return [check_cached_effective_target ppc_ieee128_ok {
> + # disable on Darwin, AIX.
> + if { [istarget powerpc-*-eabi]
> +  || [istarget powerpc*-*-eabispe]
> +  || [istarget *-*-darwin*]
> +  || [istarget *-*-aix*] } {
> + expr 0

Do we need to exclude those two explicitly?  Why?  And why eabi?  And
you don't need eabispe either.

> + } else {
> + set options "-mvsx"
> + check_runtime_nocache ppc_ieee128_ok {
> + int main()
> + {
> +   __ieee128 a;
> +   return 0;
> + }
> + } $options
> + }

Why do you use -mvsx while we actually need a superset of that?


Segher

Re: [PATCH] Tweak testcases for pr70010

[Segher Boessenkool]

Hi!

On Mon, Feb 10, 2020 at 03:39:44PM -0600, will schmidt wrote:
>   This fixes up a few tests that explicitly disable vsx,
>   but still require altivec be enabled by adding the -maltivec
>   option.  (Noted on AIX, also seen on Linux/Power6).

> diff --git a/gcc/testsuite/gcc.target/powerpc/pr70010-2.c 
> b/gcc/testsuite/gcc.target/powerpc/pr70010-2.c
> index 0c04c53..3c38fe4 100644
> --- a/gcc/testsuite/gcc.target/powerpc/pr70010-2.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr70010-2.c
> @@ -1,7 +1,7 @@
>  /* { dg-do compile } */
> -/* { dg-options "-O2 -flto -mno-vsx" } */
> +/* { dg-options "-O2 -flto -maltivec -mno-vsx" } */
>  /* { dg-require-effective-target lto } */

You need to check for powerpc_altivec_ok if you use -maltivec?

Okay for trunk with that.  Thanks!


Segher

Re: [PATCH], Rename and document PowerPC -mprefixed-addr to -mprefixed

[Segher Boessenkool]

Hi!

On Mon, Feb 10, 2020 at 01:45:42PM -0500, Michael Meissner wrote:
> This patch renames the PowerPC internal switch -mprefixed-addr to be
> -mprefixed.

> If you use -mpcrel, you must be using the 64-bit ELF v2 ABI, and the code 
> model
> must be medium.

Currently, anyway.

> If you use -mpcrel, the compiler will generate PC-relative
> loads and stores to access items, rather than the current TOC based loads and
> stores.

Where that is the best thing to do.  Is that always now?  :-)

> If you use -mpcrel, it implies -mprefixed.  If you use -mno-prefixed, you
> cannot use -mpcrel.

-mno-prefixed should imply -mno-pcrel; does it?

>   * doc/invoke.texi (RS/6000 and PowerPC Options): Docment the

(typo)

> --- /tmp/1ySv8k_invoke.texi   2020-02-07 17:56:52.700489015 -0500
> +++ gcc/doc/invoke.texi   2020-02-07 17:34:02.925611138 -0500
> @@ -22327,7 +22328,6 @@ faster on processors with 32-bit busses
>  aligns structures containing the above types differently than
>  most published application binary interface specifications for the m68k.
>  
> -@item -mpcrel
>  @opindex mpcrel
>  Use the pc-relative addressing mode of the 68000 directly, instead of
>  using a global offset table.  At present, this option implies @option{-fpic},

This isn't a correct change.

Okay for trunk modulo the m68k change.  Thanks!


Segher

Re: [PATCH 1/4 v2 GCC11] Add middle-end unroll factor estimation

[Kewen.Lin]

Hi Jeff,

on 2020/2/11 上午10:14, Jiufu Guo wrote:
> "Kewen.Lin"  writes:
> 
>> Hi Segher,
>>
>> Thanks for your comments!  Updated to v2 as below:
>>
>>   1) Removed unnecessary hook loop_unroll_adjust_tree.
>>   2) Updated estimated_uf to estimated_unroll and some comments.
>>
>> gcc/ChangeLog
>>
>> 2020-02-10  Kewen Lin  
>>
>>  * cfgloop.h (struct loop): New field estimated_unroll.
>>  * tree-ssa-loop-manip.c (decide_uf_const_iter): New function.
>>  (decide_uf_runtime_iter): Likewise.
>>  (decide_uf_stupid): Likewise.
>>  (estimate_unroll_factor): Likewise.
> In RTL unroller, target hooks are also involved when decide unroll
> factor, so these decide_uf_xx functions may not same with final real
> unroll factor in RTL. For example, at O2 by default, small loops will be
> unrolled 2 times. 

I didn't quite follow your comments, the patch already had
targetm.loop_unroll_adjust in these decide_uf_xx functions, exactly
the same as what we have in loop-unroll.c (for RTL unroll).

Or anything I missed?

BR,
Kewen

Re: [PATCH 0/4 GCC11] IVOPTs consider step cost for different forms when unrolling

[Kewen.Lin]

on 2020/2/11 上午5:29, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, Feb 10, 2020 at 02:17:04PM +0800, Kewen.Lin wrote:
>> on 2020/1/20 下午8:33, Segher Boessenkool wrote:
>>> On Thu, Jan 16, 2020 at 05:36:52PM +0800, Kewen.Lin wrote:
 As we discussed in the thread
 https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00196.html
 Original: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00104.html,
 I'm working to teach IVOPTs to consider D-form group access during 
 unrolling.
 The difference on D-form and other forms during unrolling is we can put the
 stride into displacement field to avoid additional step increment. eg:
>>>
>>> 
>>>
 Imagining that if the loop get unrolled by 8 times, then 3 step updates 
 with
 D-form vs. 8 step updates with X-form. Here we only need to check stride
 meet D-form field requirement, since if OFF doesn't meet, we can construct
 baseA' with baseA + OFF.
>>>
>>> So why doesn't the existing code do this already?  Why does it make all
>>> the extra induction variables?  Is the existing cost model bad, are our
>>> target costs bad, or something like that?
>>>
>>
>> I think the main cause is IVOPTs runs before RTL unroll, when it's 
>> determining
>> the IV sets, it can only take the normal step cost into account, since its
>> input isn't unrolled yet.  After unrolling, the x-form indexing register has 
>> to
>> play with more UF-1 times update, but we can probably hide them in d-form
>> displacement field.  The way I proposed here is to adjust IV cost with
>> additional cost_step according to estimated unroll.  It doesn't introduce new
>> IV cand but can affect the final optimal set.
> 
> Yes, we should decide how often we want to unroll things somewhere before
> ivopts already, and just use that info here.

Agreed! If some passes are interested on this unroll factor estimation, we
can move backward there if it's before IVOPTs.  As patch 1/4, once it's set,
the later pass can just reuse that info.  As Richard B. suggested, we can
even skip the later RTL unroll factor determination.

> 
> Or are there advantage to doing it *in* ivopts?  It sounds like doing
> it there is probably expensive, but maybe not, and we need to do similar
> analysis there anyway.
> 

Good question.  I didn't consider that, the reason putting here is we need
this information in IVOPTs for some cases.  :)

BR,
Kewen

[PATCH coroutines] Set side effects flag for BIND_EXPR which build in maybe_promote_captured_temps

[JunMa]

Hi
As title. in maybe_promote_captured_temps, we promote captured temporaries
and co_await_expr into a new BIND_EXPR. As the BIND_EXPR contains
co_await_expr and maybe other function calls, the side effects flag should
be set.

This patch fix one mismatch in cppcoro, the testcase comes from cppcoro
and is reduced by creduce.

Bootstrap and test on X86_64, is it OK?

Regards
JunMa

gcc/cp
2020-02-11  Jun Ma 

    * coroutines.cc (maybe_promote_captured_temps): Set side effects
    flag for BIND_EXPR.

gcc/testsuite
2020-02-11  Jun Ma 

    * g++.dg/coroutines/torture/lambda-10-co-await-lambda.C: New test.

Re: [committed] i386: Fix strncmp last arguments in x86_64_elf_section_type_flags [PR93641]

[Segher Boessenkool]

On Mon, Feb 10, 2020 at 07:07:46PM +0100, Jakub Jelinek wrote:
> We use sizeof ("...") - 1 or sizeof "..." - 1 in a lot of places though.

[...]

> config/rs6000/rs6000.c:spaces += sizeof ("  Reload=sl") - 1;
> config/rs6000/rs6000.c:spaces += sizeof ("  Upper=y") - 1;
> config/rs6000/rs6000.c:  strcpy (name, bname + sizeof ("__builtin_") - 1);
> config/rs6000/rs6000.c: len += sizeof ("no-") - 1;
> config/rs6000/rs6000.c: len += sizeof ("no-") - 1;
> config/rs6000/rs6000.c:  comma_len = sizeof (", ") - 1;

Okay, I fixed those :-)


Segher

[PATCH] rs6000: Use strlen instead of sizeof - 1

[Segher Boessenkool]

It is easier to read and understand  strlen ("string")  than it is to
read and understrand  sizeof ("string") - 1  .

Tested on powerpc64-linux {-m32,-m64}.  Committing to trunk.


Segher


2020-02-10  Segher Boessenkool  

* config/rs6000/rs6000.c (rs6000_debug_print_mode): Don't use sizeof
where strlen is more legible.
(rs6000_builtin_vectorized_libmass): Ditto.
(rs6000_print_options_internal): Ditto.

---
 gcc/config/rs6000/rs6000.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index fc68976..a6fd1e6 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -2135,7 +2135,7 @@ rs6000_debug_print_mode (ssize_t m)
   spaces = 0;
 }
   else
-spaces += sizeof ("  Reload=sl") - 1;
+spaces += strlen ("  Reload=sl");
 
   if (reg_addr[m].scalar_in_vmx_p)
 {
@@ -2143,7 +2143,7 @@ rs6000_debug_print_mode (ssize_t m)
   spaces = 0;
 }
   else
-spaces += sizeof ("  Upper=y") - 1;
+spaces += strlen ("  Upper=y");
 
   if (rs6000_vector_unit[m] != VECTOR_NONE
   || rs6000_vector_mem[m] != VECTOR_NONE)
@@ -5206,7 +5206,7 @@ rs6000_builtin_vectorized_libmass (combined_fn fn, tree 
type_out,
   if (!bname)
 return NULL_TREE;
 
-  strcpy (name, bname + sizeof ("__builtin_") - 1);
+  strcpy (name, bname + strlen ("__builtin_"));
   strcat (name, suffix);
 
   if (n_args == 1)
@@ -23547,7 +23547,7 @@ rs6000_print_options_internal (FILE *file,
  if ((flags & mask) == 0)
{
  no_str = "no-";
- len += sizeof ("no-") - 1;
+ len += strlen ("no-");
}
 
  flags &= ~mask;
@@ -23558,7 +23558,7 @@ rs6000_print_options_internal (FILE *file,
  if ((flags & mask) != 0)
{
  no_str = "no-";
- len += sizeof ("no-") - 1;
+ len += strlen ("no-");
}
 
  flags |= mask;
@@ -23574,7 +23574,7 @@ rs6000_print_options_internal (FILE *file,
 
   fprintf (file, "%s%s%s%s", comma, prefix, no_str, name);
   comma = ", ";
-  comma_len = sizeof (", ") - 1;
+  comma_len = strlen (", ");
 }
 
   fputs ("\n", file);
-- 
1.8.3.1

Re: [PATCH] correct COUNT and PROB for unrolled loop

[Jiufu Guo]

Jan Hubicka  writes:

>> On Mon, 2020-02-03 at 10:04 -0600, Pat Haugen wrote:
>> > On 2/3/20 2:17 AM, Jiufu Guo wrote:
>> > > +/* { dg-final { scan-rtl-dump-times "REG_BR_PROB 937042044" 1 
>> > > "loop2_unroll"} } */
>> > 
>> > Sorry I didn't catch this addition to the original testcase
>> > earlier, but I wonder how stable this test is going to be. If
>> > there are future changes to default count/probability, or changes
>> > in their representation, this may fail and need to be updated. The
>> > fact that the loop is still getting aligned is the main concern.
>> Unless you're really interested in those probabilities, I'd suggest not
>> testing for them.  If you really need to test for them, then I'd
>> suggest testing for them being "close" rather than a specific value for
>> REG_BR_PROB.
>
> Note that REG_BR_PROB now encodes the actual probability as well as the
> profile quality (i.e. it is m_val * 8 + m_quality).
> We may want to invent better way to dump them, but it is better to match
> for CFG edge probability rather than the REG_BR_PROB_NOTE.
Thanks Honza, Pat, Jeff.
String like "count 661119332" in dump file may also not perfect.
I would removing this line before commit.

Welcome for any other comments!

Thanks,
Jiufu Guo.

>
> honza
>> 
>> jeff
>> 

Re: [PATCH 1/4 v2 GCC11] Add middle-end unroll factor estimation

[Jiufu Guo]

"Kewen.Lin"  writes:

> Hi Segher,
>
> Thanks for your comments!  Updated to v2 as below:
>
>   1) Removed unnecessary hook loop_unroll_adjust_tree.
>   2) Updated estimated_uf to estimated_unroll and some comments.
>
> gcc/ChangeLog
>
> 2020-02-10  Kewen Lin  
>
>   * cfgloop.h (struct loop): New field estimated_unroll.
>   * tree-ssa-loop-manip.c (decide_uf_const_iter): New function.
>   (decide_uf_runtime_iter): Likewise.
>   (decide_uf_stupid): Likewise.
>   (estimate_unroll_factor): Likewise.
In RTL unroller, target hooks are also involved when decide unroll
factor, so these decide_uf_xx functions may not same with final real
unroll factor in RTL. For example, at O2 by default, small loops will be
unrolled 2 times. 
>   * tree-ssa-loop-manip.h (estimate_unroll_factor): New declare.
>   * tree-ssa-loop.c (tree_average_num_loop_insns): New function.
>   * tree-ssa-loop.h (tree_average_num_loop_insns): New declare.
>
> BR,
> Kewen
>
> on 2020/1/20 下午9:02, Segher Boessenkool wrote:
>> Hi!
>> 
>> On Thu, Jan 16, 2020 at 05:39:40PM +0800, Kewen.Lin wrote:
>>> --- a/gcc/cfgloop.h
>>> +++ b/gcc/cfgloop.h
>>> @@ -232,6 +232,9 @@ public:
>>>   Other values means unroll with the given unrolling factor.  */
>>>unsigned short unroll;
>>>  
>>> +  /* Like unroll field above, but it's estimated in middle-end.  */
>>> +  unsigned short estimated_uf;
>> 
>> Please use full words?  "estimated_unroll" perhaps?  (Similar for other
>> new names).
>> 
>
> Done.
>
>>> +/* Implement targetm.loop_unroll_adjust_tree, strictly refers to
>>> +   targetm.loop_unroll_adjust.  */
>>> +
>>> +static unsigned
>>> +rs6000_loop_unroll_adjust_tree (unsigned nunroll, struct loop *loop)
>>> +{
>>> +  /* For now loop_unroll_adjust is simple, just invoke directly.  */
>>> +  return rs6000_loop_unroll_adjust (nunroll, loop);
>>> +}
>> 
>> Since the two hooks have the same arguments as well, it should really
>> just be one hook, and an implementation can check whether
>>   current_pass->type == RTL_PASS
>> if it needs to do something special for RTL, etc.?  Or it can use some
>> more appropriate condition -- the point is you need no extra hook.
>> 
>
> Good point, removed it.
>
>>> +  /* Check number of iterations is constant.  */
>>> +  if ((niter_desc->may_be_zero && !integer_zerop (niter_desc->may_be_zero))
>>> +  || !tree_fits_uhwi_p (niter_desc->niter))
>>> +return false;
>> 
>> Check, and do what?  It's easier to read if you say.
>> 
>
> Done.
>
>> 
>> "If loop->unroll is set, use that as loop->estimated_unroll"?
>> 
>
> Done.

[PATCH coroutines] Do not strip cleanup_point when promote temporaries out of current stmt

[JunMa]

Hi
In maybe_promote_captured_temps, the cleanup_point_stmt has been
stripped when handle temporaries captured by reference. However, maybe
there are non-reference temporaries in current stmt which cause ice in
gimpilify pass.

This patch fix this. The testcase comes from cppcoro and is reduced by
creduce.

Bootstrap and test on X86_64, is it OK?

Regards
JunMa

gcc/cp
2020-02-11  Jun Ma 

    * coroutines.cc (maybe_promote_captured_temps): Do not strip
    cleanup_point_stmt.

gcc/testsuite
2020-02-11  Jun Ma 

    * g++.dg/coroutines/torture/lambda-09-capture-object.C: New test.
---
 gcc/cp/coroutines.cc  |   8 +-
 .../torture/lambda-09-capture-object.C| 132 ++
 2 files changed, 135 insertions(+), 5 deletions(-)
 create mode 100644 
gcc/testsuite/g++.dg/coroutines/torture/lambda-09-capture-object.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 9fcbb647201..3095b46ecb1 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -2681,11 +2681,9 @@ maybe_promote_captured_temps (tree *stmt, void *d)
   location_t sloc = EXPR_LOCATION (*stmt);
   tree aw_bind
= build3_loc (sloc, BIND_EXPR, void_type_node, NULL, NULL, NULL);
-  tree aw_statement_current;
-  if (TREE_CODE (*stmt) == CLEANUP_POINT_EXPR)
-   aw_statement_current = TREE_OPERAND (*stmt, 0);
-  else
-   aw_statement_current = *stmt;
+  /* Do not skip cleanup_point since maybe there are other temporaries
+ need cleanup.  */
+  tree aw_statement_current = *stmt;
   /* Collected the scope vars we need move the temps to regular. */
   tree aw_bind_body = push_stmt_list ();
   tree varlist = NULL_TREE;
diff --git a/gcc/testsuite/g++.dg/coroutines/torture/lambda-09-capture-object.C 
b/gcc/testsuite/g++.dg/coroutines/torture/lambda-09-capture-object.C
new file mode 100644
index 000..1297b72cc8f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/torture/lambda-09-capture-object.C
@@ -0,0 +1,132 @@
+//  { dg-do compile }
+//  { dg-additional-options "-Wno-return-type" }
+
+#include "../coro.h"
+#include 
+#include 
+
+template > struct a;
+template 
+struct a().await_resume())>>
+: std::conjunction<> {};
+template 
+auto c(b value, int) -> decltype(value.operator co_await());
+template ::value, int> = 0> b c(b, int);
+template  auto d(b value) -> decltype(c(value, 3)) {}
+template  struct f {
+  using e = decltype(d(std::declval()));
+  using h = decltype(std::declval().await_resume());
+};
+template  class s;
+template  class s> {
+public:
+  s(std::tuple);
+  auto operator co_await() {
+struct aa {
+  std::tuple await_resume() {};
+  s i;
+};
+return aa{*this};
+  }
+};
+template  class k {
+public:
+  using l = std::coroutine_handle;
+  j m();
+};
+template  class ab {
+public:
+  using promise_type = k;
+  using l = typename promise_type::l;
+  auto m() { return n.promise().m(); }
+  auto ac() { return m(); }
+  l n;
+};
+template ::h,
+  std::enable_if_t, int> = 0>
+ab p(o);
+template  struct u { using ad = b; };
+template  using t = typename u::ad;
+template , int> = 0>
+auto af(ae... ag) {
+  return s>>::h>...>>(
+  std::make_tuple(p(ag)...));
+}
+template  class ah {
+  using e = typename f::e;
+
+public:
+  ah(q ai, o aj) : r(ai), ak(d(aj)) {}
+  auto await_ready() { return 0; }
+  template  auto await_suspend(std::coroutine_handle) {}
+  template , int> = 0>
+  auto await_resume() {
+return invoke(r, ak.await_resume());
+  }
+  q r;
+  e ak;
+};
+template  class x {
+public:
+  template , int> = 0>
+  x(y ai, al aj) : r(ai), i(aj) {}
+  auto operator co_await() { return ah(r, i); }
+  q r;
+  o i;
+};
+template  auto am(q ai, o aj) {
+  return x>,
+   std::remove_cv_t>>(ai, aj);
+}
+template , int> = 0>
+auto an(ae... ag) {
+  return am(
+  [](auto ao) {
+auto ap =
+apply([](auto... aq) { return std::make_tuple(aq.ac()...); }, ao);
+return ap;
+  },
+  af(ag...));
+}
+class ar;
+class z {
+public:
+  ar as();
+};
+class at {
+public:
+  ~at();
+};
+class ar {
+public:
+  at await_resume();
+};
+class au;
+class av {
+  struct aw {
+bool await_ready();
+template  void await_suspend(std::coroutine_handle);
+void await_resume();
+  };
+
+public:
+  auto initial_suspend() { return std::suspend_always{}; }
+  auto final_suspend() { return aw{}; }
+};
+class ax : public av {
+public:
+  au get_return_object();
+  void unhandled_exception();
+};
+class au {
+public:
+  using promise_type = ax;
+};
+void d() {
+  []() -> au {
+z ay;
+co_await an(ay.as());
+  };
+}
-- 
2.19.1.3.ge56e4f7

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

[Andrew Benson]

*ping*

On Tuesday, January 28, 2020 4:45:59 PM PST Andrew Benson wrote:
> I opened PR93486 for this problem:
> 
> The following causes an ICE with revision
> ad690d79cfbb905c5546c9333c5fd089d906505b:
> 
> module ivs
>   interface l
>  module procedure l_
>   end interface l
> contains
>   function l_()
>   end function l_
> end module ivs
> 
> module aModeratleyLongModuleName
>   use ivs
>   interface
>  module subroutine cmo()
>  end subroutine cmo
>   end interface
> end module aModeratleyLongModuleName
> 
> submodule (aModeratleyLongModuleName)
> aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill
> contains
>   module procedure cmo
>   end procedure cmo
> end submodule aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill
> 
> submodule
> (aModeratleyLongModuleName:aNameForASubmoduleThatIsVeryLongButWhichIsLegalSt
> ill) sb
> end submodule sb
> 
> submodule (aModeratleyLongModuleName:sb) sc
> end submodule sc
> 
> 
> $ gfortran -v
> Using built-in specs.
> COLLECT_GCC=gfortran
> COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel_Install/bin/../
> libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/
> Tools_Devel --enable-languages=c,c++,fortran --disable-multilib
> Thread model: posix
> Supported LTO compression algorithms: zlib
> gcc version 10.0.1 20200128 (experimental) (GCC)
> 
> 
> $ gfortran -c test.F90 -o test.o
> f951: internal compiler error: Segmentation fault
> 0xe1bc9f crash_signal
> ../../gcc-git/gcc/toplev.c:328
> 0x7f98119c71ef ???
>
> /data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/
> sysv/linux/x86_64/sigaction.c:0
> 0x84b3f0 gfc_use_modules()
> ../../gcc-git/gcc/fortran/module.c:7315
> 0x85acc8 use_modules
> ../../gcc-git/gcc/fortran/parse.c:114
> 0x866daa parse_module
> ../../gcc-git/gcc/fortran/parse.c:6111
> 0x86733c gfc_parse_file()
> ../../gcc-git/gcc/fortran/parse.c:6428
> 0x8b780f gfc_be_parse_file
> ../../gcc-git/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  for instructions.
> 
> 
> The ICE goes away if the module and/or submodule names are made shorter.
> 
> The problem is caused when loading (generic or operator) interfaces from a
> module file. The module name can include the submodule name, so a size of
> 2*GFC_MAX_SYMBOL_LEN+2 is required to read this in.
> 
> The attached patch fixes this problem and regression tests cleanly *if* the
> patch for PR87103 is applied (otherwise that problem gets triggered by the
> new test case).
> 
> PR87103 has been a long-standing issue - there's a patch that works (either
> my original ugly fix, or the better fix proposed by Bernhard at https://
> gcc.gnu.org/ml/fortran/2018-09/msg00044.html ). It would be very nice to
> get one of these patches committed.
> 
> -Andrew


-- 

* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html

* Galacticus: https://github.com/galacticusorg/galacticus

Re: [PATCH 4/4 v2 GCC11] rs6000: P9 D-form test cases

[Segher Boessenkool]

On Mon, Feb 10, 2020 at 02:24:15PM +0800, Kewen.Lin wrote:
> 2020-02-10  Kelvin Nilsen  
> Kewen Lin  
> 
>   * gcc.target/powerpc/p9-dform-0.c: New test.
>   * gcc.target/powerpc/p9-dform-1.c: New test.
>   * gcc.target/powerpc/p9-dform-2.c: New test.
>   * gcc.target/powerpc/p9-dform-3.c: New test.
>   * gcc.target/powerpc/p9-dform-4.c: New test.
>   * gcc.target/powerpc/p9-dform-generic.h: New test.

This is fine for trunk (after the other patches are in so this no longer
fails, of course ;-) ).


Segher

Re: [PATCH 1/4 v2 GCC11] Add middle-end unroll factor estimation

[Segher Boessenkool]

Hi!

On Mon, Feb 10, 2020 at 02:20:17PM +0800, Kewen.Lin wrote:
>   * tree-ssa-loop-manip.c (decide_uf_const_iter): New function.
>   (decide_uf_runtime_iter): Likewise.
>   (decide_uf_stupid): Likewise.

These names still use "uf".  (Those are the last I see).

>   * tree-ssa-loop-manip.h (estimate_unroll_factor): New declare.

"New declaration."


Segher

[committed] analyzer.opt: fix typos in descriptions (PR 93659)

[David Malcolm]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as  r10-6568-geb031d4ba27b3fdc292f5a1092e66024f5ee239c.

gcc/analyzer/ChangeLog:
PR analyzer/93659
* analyzer.opt (-param=analyzer-max-recursion-depth=): Fix "tha"
-> "that" typo.
(Wanalyzer-use-of-uninitialized-value): Fix "initialized" ->
"uninitialized" typo.
---
 gcc/analyzer/analyzer.opt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/analyzer/analyzer.opt b/gcc/analyzer/analyzer.opt
index af8d81d697a..7d40c88ed1a 100644
--- a/gcc/analyzer/analyzer.opt
+++ b/gcc/analyzer/analyzer.opt
@@ -32,7 +32,7 @@ The maximum number of exploded nodes per program point within 
the analyzer, befo
 
 -param=analyzer-max-recursion-depth=
 Common Joined UInteger Var(param_analyzer_max_recursion_depth) Init(2) Param
-The maximum number of times a callsite can appear in a call stack within the 
analyzer, before terminating analysis of a call tha would recurse deeper.
+The maximum number of times a callsite can appear in a call stack within the 
analyzer, before terminating analysis of a call that would recurse deeper.
 
 -param=analyzer-min-snodes-for-call-summary=
 Common Joined UInteger Var(param_analyzer_min_snodes_for_call_summary) 
Init(10) Param
@@ -100,7 +100,7 @@ Warn about code paths in which a pointer to a stale stack 
frame is used.
 
 Wanalyzer-use-of-uninitialized-value
 Common Var(warn_analyzer_use_of_uninitialized_value) Init(1) Warning
-Warn about code paths in which an initialized value is used.
+Warn about code paths in which an uninitialized value is used.
 
 Wanalyzer-too-complex
 Common Var(warn_analyzer_too_complex) Init(0) Warning
-- 
2.21.0

[committed] analyzer: handle vector types (PR 93350)

[David Malcolm]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r10-6567-ge87deb37649cfe480217fc83c8d56fe925600f93.

gcc/analyzer/ChangeLog:
PR analyzer/93350
* region-model.cc (region_model::get_lvalue_1):
Handle BIT_FIELD_REF.
(make_region_for_type): Handle VECTOR_TYPE.

gcc/testsuite/ChangeLog:
PR analyzer/93350
* gcc.dg/analyzer/torture/pr93350.c: New test.
---
 gcc/analyzer/region-model.cc| 11 ++-
 gcc/testsuite/gcc.dg/analyzer/torture/pr93350.c | 11 +++
 2 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/torture/pr93350.c

diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index fd82360cc6e..ae810f5eb4b 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -4662,6 +4662,14 @@ region_model::get_lvalue_1 (path_var pv, 
region_model_context *ctxt)
   }
   break;
 
+case BIT_FIELD_REF:
+  {
+   /* For now, create a view, as if a cast, ignoring the bit positions.  */
+   tree obj = TREE_OPERAND (expr, 0);
+   return get_or_create_view (get_lvalue (obj, ctxt), TREE_TYPE (expr));
+  };
+  break;
+
 case MEM_REF:
   {
tree ptr = TREE_OPERAND (expr, 0);
@@ -6035,7 +6043,8 @@ make_region_for_type (region_id parent_rid, tree type)
   if (INTEGRAL_TYPE_P (type)
   || SCALAR_FLOAT_TYPE_P (type)
   || POINTER_TYPE_P (type)
-  || TREE_CODE (type) == COMPLEX_TYPE)
+  || TREE_CODE (type) == COMPLEX_TYPE
+  || TREE_CODE (type) == VECTOR_TYPE)
 return new primitive_region (parent_rid, type);
 
   if (TREE_CODE (type) == RECORD_TYPE)
diff --git a/gcc/testsuite/gcc.dg/analyzer/torture/pr93350.c 
b/gcc/testsuite/gcc.dg/analyzer/torture/pr93350.c
new file mode 100644
index 000..1799da1936c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/torture/pr93350.c
@@ -0,0 +1,11 @@
+/* { dg-require-effective-target vect_int } */
+/* { dg-additional-options "-Wno-psabi" } */
+
+typedef __INT32_TYPE__   int32_t;
+typedef int32_t vnx4si __attribute__((vector_size (32)));
+
+__attribute__((noipa))
+vnx4si foo(int a, int b)
+{
+  return (vnx4si) { 1, 2, 3, 4, 5, 6, a, b };
+}
-- 
2.21.0

[committed] analyzer: fix ICE reporting NULL dereference (PR 93647)

[David Malcolm]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r10-6566-ge953f9588d4a7ea4183d14914f915329cc37941f.

gcc/analyzer/ChangeLog:
PR analyzer/93647
* diagnostic-manager.cc
(diagnostic_manager::prune_for_sm_diagnostic): Bulletproof against
VAR being constant.
* region-model.cc (region_model::get_lvalue_1): Provide a better
error message when encountering an unhandled tree code.

gcc/testsuite/ChangeLog:
PR analyzer/93647
* gcc.dg/analyzer/torture/pr93647.c: New test.
---
 gcc/analyzer/diagnostic-manager.cc  |  6 ++
 gcc/analyzer/region-model.cc|  2 ++
 gcc/testsuite/gcc.dg/analyzer/torture/pr93647.c | 14 ++
 3 files changed, 22 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/torture/pr93647.c

diff --git a/gcc/analyzer/diagnostic-manager.cc 
b/gcc/analyzer/diagnostic-manager.cc
index 1a82d5f22ec..580152586f4 100644
--- a/gcc/analyzer/diagnostic-manager.cc
+++ b/gcc/analyzer/diagnostic-manager.cc
@@ -965,6 +965,12 @@ diagnostic_manager::prune_for_sm_diagnostic (checker_path 
*path,
 tree var,
 state_machine::state_t state) const
 {
+  /* If we have a constant (such as NULL), assume its state is also
+ constant, so as not to attempt to get its lvalue whilst tracking the
+ origin of the state.  */
+  if (var && CONSTANT_CLASS_P (var))
+var = NULL_TREE;
+
   int idx = path->num_events () - 1;
   while (idx >= 0 && idx < (signed)path->num_events ())
 {
diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index 0ae7536a032..fd82360cc6e 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -4641,6 +4641,8 @@ region_model::get_lvalue_1 (path_var pv, 
region_model_context *ctxt)
   switch (TREE_CODE (expr))
 {
 default:
+  internal_error ("unhandled tree code in region_model::get_lvalue_1: %qs",
+ get_tree_code_name (TREE_CODE (expr)));
   gcc_unreachable ();
 
 case ARRAY_REF:
diff --git a/gcc/testsuite/gcc.dg/analyzer/torture/pr93647.c 
b/gcc/testsuite/gcc.dg/analyzer/torture/pr93647.c
new file mode 100644
index 000..fbfe570780b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/torture/pr93647.c
@@ -0,0 +1,14 @@
+/* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } { "" } } */
+
+int *tz;
+
+void
+ky (int);
+
+void
+wd (void)
+{
+  tz = 0;
+  ky (*tz); /* { dg-warning "dereference of NULL" } */
+}
+
-- 
2.21.0

Re: [PATCH] Fix -ffast-math flags handling inconsistencies

[Joseph Myers]

On Mon, 10 Feb 2020, Ulrich Weigand wrote:

> Given the above rule, in the last case __FINITE_MATH_ONLY__ should
> also be 0, right?

Yes.

> I'm not sure how this can be implemented in the current option handling
> framework.  The -ffast-math handling case would have to check whether
> or not there is any explicit use of -f(no-)finite-math-only; is there
> any infrastructure to readily perform such a test?

Pass opts_set as well as opts to set_fast_math_flags, and use it for 
checking whether an option was explicitly specified (whether enabled or 
disabled) on the command line.

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

Contents of PO file 'cpplib-10.1-b20200209.pt_BR.po'

[Translation Project Robot]

cpplib-10.1-b20200209.pt_BR.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New Brazilian Portuguese PO file for 'cpplib' (version 10.1-b20200209)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/cpplib/pt_BR.po

(This file, 'cpplib-10.1-b20200209.pt_BR.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH] Use a non-empty test program to test ability to link

[Joseph Myers]

On Sat, 8 Feb 2020, Sandra Loosemore wrote:

> > > BTW, I did run autoconf in every subdirectory that contains a
> > > configure.ac,
> > > but it appears only libstc++-v3 actually uses this test; all the other
> > > regenerated configure scripts were unchanged.
> > 
> > There's some problem with that regeneration, then; every directory where
> > configure.ac mentions GCC_NO_EXECUTABLES should have a resulting change (I
> > tested regenerating in libgcc/ with this patch applied and got such a
> > change, for example).
> 
> Hmmm.  I just tried that again and got nothing.  Do I have to do something
> other than just run "autoconf" in that directory?  I'm always confused by
> anything involving configuration changes.  :-(

Just running autoconf in that directory should suffice to get configure 
regenerated with the change.

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

[PATCH] issue -Wstringop-overflow for potential overflow, not -truncation (PR 93646)

[Martin Sebor]

The reporter of RHBZ #1798636 was mislead and confused by GCC
issuing -Wstringop-truncation for a possible overflow in strncat.
It took a few iterations to appreciate this subtlety and realize
the warning was of the wrong kind.

The attached patch adjusts the logic of the function responsible
for the warning not to issue -Wstringop-truncation only for strncpy
and -Wstringop-overflow for strncat.

I'm not sure if the bug is strictly speaking a regression: GCC 8
didn't issue any warning so it could be viewed as one, but then
again, issuing a warning in this instance is intended, but not
a misleading one.

Tested on x86_64-linux.

Martin
PR middle-end/93646 - confusing -Wstringop-truncation on strncat where -Wstringop-overflow is expected

gcc/ChangeLog:

	PR middle-end/93646
	* tree-ssa-strlen.c (handle_builtin_stxncpy): Rename...
	(handle_builtin_stxncpy_strncat): ...to this.  Change first argument.
	Issue only -Wstringop-overflow strncat, never -Wstringop-truncation.
	(strlen_check_and_optimize_call): Adjust callee name.

gcc/testsuite/ChangeLog:

	PR middle-end/93646
	* gcc.dg/Wstringop-overflow-31.c: New test.

diff --git a/gcc/testsuite/gcc.dg/Wstringop-overflow-31.c b/gcc/testsuite/gcc.dg/Wstringop-overflow-31.c
new file mode 100644
index 000..24be256a547
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Wstringop-overflow-31.c
@@ -0,0 +1,40 @@
+/* PR middle-end/93646 - confusing -Wstringop-truncation on strncat where
+   -Wstringop-overflow is expected
+   { dg-do compile }
+   { dg-options "-O2 -Wall" } */
+
+extern __SIZE_TYPE__ strlen (const char*);
+extern char* strncat (char*, const char*, __SIZE_TYPE__);
+
+
+char a[4];
+
+
+void f0 (char *d, const char *s)
+{
+  strncat (d, s, strlen (s));   // { dg-warning "specified bound depends on the length of the source argument" }
+  /* { dg-message "function 'f0'.*inlined from 'f1'" "inlining stack" { target *-*-* } 0 }  */
+
+  // Prevent f0 from being replaced by g0.
+  *d = 'f';
+}
+
+void f1 (const char *s)
+{
+  f0 (a, s);
+}
+
+
+static void g0 (char *d, const char *s)
+{
+  strncat (d, s, strlen (s));   // { dg-warning "specified bound 3 equals source length" }
+  /* { dg-message "function 'g0'.*inlined from 'g1'" "inlining stack" { target *-*-* } 0 }  */
+
+  // Prevent g0 from being replaced by f0.
+  *d = 'g';
+}
+
+void g1 (void)
+{
+  g0 (a, "123");
+}
diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 1cd64302d8b..9a88a85b07c 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -192,7 +192,7 @@ struct laststmt_struct
 } laststmt;
 
 static int get_stridx_plus_constant (strinfo *, unsigned HOST_WIDE_INT, tree);
-static void handle_builtin_stxncpy (built_in_function, gimple_stmt_iterator *);
+static void handle_builtin_stxncpy_strncat (bool, gimple_stmt_iterator *);
 
 /* Sets MINMAX to either the constant value or the range VAL is in
and returns either the constant value or VAL on success or null
@@ -2876,10 +2876,10 @@ handle_builtin_strcpy (enum built_in_function bcode, gimple_stmt_iterator *gsi,
and if so, issue an appropriate warning.  */
 
 static void
-handle_builtin_strncat (built_in_function bcode, gimple_stmt_iterator *gsi)
+handle_builtin_strncat (built_in_function, gimple_stmt_iterator *gsi)
 {
   /* Same as stxncpy().  */
-  handle_builtin_stxncpy (bcode, gsi);
+  handle_builtin_stxncpy_strncat (true, gsi);
 }
 
 /* Return true if LEN depends on a call to strlen(SRC) in an interesting
@@ -2974,8 +2974,8 @@ is_strlen_related_p (tree src, tree len)
   return false;
 }
 
-/* Called by handle_builtin_stxncpy and by gimple_fold_builtin_strncpy
-   in gimple-fold.c.
+/* Called by handle_builtin_stxncpy_strncat and by
+   gimple_fold_builtin_strncpy in gimple-fold.c.
Check to see if the specified bound is a) equal to the size of
the destination DST and if so, b) if it's immediately followed by
DST[CNT - 1] = '\0'.  If a) holds and b) does not, warn.  Otherwise,
@@ -3283,13 +3283,14 @@ maybe_diag_stxncpy_trunc (gimple_stmt_iterator gsi, tree src, tree cnt)
   return false;
 }
 
-/* Check the arguments to the built-in forms of stpncpy and strncpy for
-   out-of-bounds offsets or overlapping access, and to see if the size
-   is derived from calling strlen() on the source argument, and if so,
-   issue the appropriate warning.  */
+/* Check the arguments to the built-in forms of stpncpy, strncpy, and
+   strncat, for out-of-bounds offsets or overlapping access, and to see
+   if the size is derived from calling strlen() on the source argument,
+   and if so, issue the appropriate warning.
+   APPEND_P is true for strncat.  */
 
 static void
-handle_builtin_stxncpy (built_in_function, gimple_stmt_iterator *gsi)
+handle_builtin_stxncpy_strncat (bool append_p, gimple_stmt_iterator *gsi)
 {
   if (!strlen_to_stridx)
 return;
@@ -3385,7 +3386,8 @@ handle_builtin_stxncpy (built_in_function, gimple_stmt_iterator *gsi)
  whether its value is known.  Otherwise, issue the more generic
  

[PATCH] Add ppc_ieee128_ok target-supports proc

[will schmidt]

Hi,

This adds a target_supports entry to check that the
_ieee128 keyword is understood by the target.
Also adds that require-effective-target check to the
existing pr92796 testcase.

Sniff tested on Linux (power6,power9) and AIX.

OK for master?

Thanks
-Will

[testsuite]
* lib/target-supports.exp (check_effective_target_ppc_ieee128_ok): New.
* gcc.target/powerpc/pr92796.c: Add
require-effective-target ppc64_ieee128_ok.

diff --git a/gcc/testsuite/gcc.target/powerpc/pr92796.c 
b/gcc/testsuite/gcc.target/powerpc/pr92796.c
index aa15b2d..da4b6a4 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr92796.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr92796.c
@@ -1,7 +1,8 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fstack-protector-strong -mcpu=power8" } */
+/* { dg-require-effective-target ppc_ieee128_ok } */
 
 typedef union
 {
   __ieee128 a;
   int b;
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index d3b2798..0154457 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2248,10 +2248,32 @@ proc check_ppc_float128_hw_available { } {
} $options
}
 }]
 }
 
+# See if the __ieee128 keyword is understood.
+proc check_effective_target_ppc_ieee128_ok { } {
+return [check_cached_effective_target ppc_ieee128_ok {
+   # disable on Darwin, AIX.
+   if { [istarget powerpc-*-eabi]
+|| [istarget powerpc*-*-eabispe]
+|| [istarget *-*-darwin*]
+|| [istarget *-*-aix*] } {
+   expr 0
+   } else {
+   set options "-mvsx"
+   check_runtime_nocache ppc_ieee128_ok {
+   int main()
+   {
+ __ieee128 a;
+ return 0;
+   }
+   } $options
+   }
+}]
+}
+
 # Return 1 if the target supports executing VSX instructions, 0
 # otherwise.  Cache the result.
 
 proc check_vsx_hw_available { } {
 return [check_cached_effective_target vsx_hw_available {

[PATCH] Tweak testcases for pr70010

[will schmidt]

Hi,
  This fixes up a few tests that explicitly disable vsx,
  but still require altivec be enabled by adding the -maltivec
  option.  (Noted on AIX, also seen on Linux/Power6).

OK for master?

Thanks,
-Will

[testsuite]
* gcc.target/powerpc/pr70010-2.c: Add -maltivec.
* gcc.target/powerpc/pr70010-3.c: Add -maltivec.

diff --git a/gcc/testsuite/gcc.target/powerpc/pr70010-2.c 
b/gcc/testsuite/gcc.target/powerpc/pr70010-2.c
index 0c04c53..3c38fe4 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr70010-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr70010-2.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -flto -mno-vsx" } */
+/* { dg-options "-O2 -flto -maltivec -mno-vsx" } */
 /* { dg-require-effective-target lto } */
 
 vector int c, a, b;
 
 static inline void __attribute__ ((__always_inline__, target ("no-vsx")))
diff --git a/gcc/testsuite/gcc.target/powerpc/pr70010-3.c 
b/gcc/testsuite/gcc.target/powerpc/pr70010-3.c
index bca3187..f5ca1f7 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr70010-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr70010-3.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -mno-vsx" } */
+/* { dg-options "-O2 -maltivec -mno-vsx" } */
 
 vector int c, a, b;
 
 static inline void __attribute__ ((__always_inline__, target ("no-vsx")))
 foo ()

Re: [PATCH 0/4 GCC11] IVOPTs consider step cost for different forms when unrolling

[Segher Boessenkool]

Hi!

On Mon, Feb 10, 2020 at 02:17:04PM +0800, Kewen.Lin wrote:
> on 2020/1/20 下午8:33, Segher Boessenkool wrote:
> > On Thu, Jan 16, 2020 at 05:36:52PM +0800, Kewen.Lin wrote:
> >> As we discussed in the thread
> >> https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00196.html
> >> Original: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00104.html,
> >> I'm working to teach IVOPTs to consider D-form group access during 
> >> unrolling.
> >> The difference on D-form and other forms during unrolling is we can put the
> >> stride into displacement field to avoid additional step increment. eg:
> > 
> > 
> > 
> >> Imagining that if the loop get unrolled by 8 times, then 3 step updates 
> >> with
> >> D-form vs. 8 step updates with X-form. Here we only need to check stride
> >> meet D-form field requirement, since if OFF doesn't meet, we can construct
> >> baseA' with baseA + OFF.
> > 
> > So why doesn't the existing code do this already?  Why does it make all
> > the extra induction variables?  Is the existing cost model bad, are our
> > target costs bad, or something like that?
> > 
> 
> I think the main cause is IVOPTs runs before RTL unroll, when it's determining
> the IV sets, it can only take the normal step cost into account, since its
> input isn't unrolled yet.  After unrolling, the x-form indexing register has 
> to
> play with more UF-1 times update, but we can probably hide them in d-form
> displacement field.  The way I proposed here is to adjust IV cost with
> additional cost_step according to estimated unroll.  It doesn't introduce new
> IV cand but can affect the final optimal set.

Yes, we should decide how often we want to unroll things somewhere before
ivopts already, and just use that info here.

Or are there advantage to doing it *in* ivopts?  It sounds like doing
it there is probably expensive, but maybe not, and we need to do similar
analysis there anyway.


Segher

Fix libgcc build failure on FRV

[Jeff Law]

Alan recently changed the diagnostic in binutils for changing various
attributes of a section from a warning to a hard error.


This caused the FRV port to fail to build frvbegin/frvend because of
differences in the flags for the .ctors/.dtors sections.

This patch twiddles frvbegin.c/frvend.c in libgcc to avoid the error.

I've verified this fixes the libgcc build failure for FRV and verified
that the GCC testresults have returned to normal.

Installed on the trunk,

Jeff
commit 7214fce3024d726ad548d7003fa162eb5021c491
Author: Jeff Law 
Date:   Mon Feb 10 14:12:32 2020 -0700

Fix libgcc build failure for FRV with recent versions of gas.

* config/frv/frvbegin.c: Use right flags for .ctors and .dtors
sections.
* config/frv/frvend.c: Similarly.

diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
index 4c7443a0457..917d0e76568 100644
--- a/libgcc/ChangeLog
+++ b/libgcc/ChangeLog
@@ -1,3 +1,9 @@
+2020-02-10  Jeff Law  
+
+   * config/frv/frvbegin.c: Use right flags for .ctors and .dtors
+   sections.
+   * config/frv/frvend.c: Similarly.
+
 2020-02-10  H.J. Lu  
 
PR libgcc/85334
diff --git a/libgcc/config/frv/frvbegin.c b/libgcc/config/frv/frvbegin.c
index 8ab1a1b989d..0f54bf19646 100644
--- a/libgcc/config/frv/frvbegin.c
+++ b/libgcc/config/frv/frvbegin.c
@@ -59,8 +59,8 @@ __asm__ (".section " SECTION "," FLAGS "\n\t" 
\
 /* Beginning of .ctor/.dtor sections that provides a list of constructors and
destructors to run.  */
 
-INIT_SECTION_NEG_ONE (".ctors", "\"aw\"", "__CTOR_LIST__");
-INIT_SECTION_NEG_ONE (".dtors", "\"aw\"", "__DTOR_LIST__");
+INIT_SECTION_NEG_ONE (".ctors", "\"a\"", "__CTOR_LIST__");
+INIT_SECTION_NEG_ONE (".dtors", "\"a\"", "__DTOR_LIST__");
 
 /* Beginning of .eh_frame section that provides all of the exception handling
tables.  */
diff --git a/libgcc/config/frv/frvend.c b/libgcc/config/frv/frvend.c
index eb3494cad96..d2b83b294ca 100644
--- a/libgcc/config/frv/frvend.c
+++ b/libgcc/config/frv/frvend.c
@@ -52,8 +52,8 @@ __asm__ (".section " SECTION "," FLAGS "\n\t" 
\
 /* End of .ctor/.dtor sections that provides a list of constructors and
destructors to run.  */
 
-FINI_SECTION_ZERO (".ctors", "\"aw\"", "__CTOR_END__");
-FINI_SECTION_ZERO (".dtors", "\"aw\"", "__DTOR_END__");
+FINI_SECTION_ZERO (".ctors", "\"a\"", "__CTOR_END__");
+FINI_SECTION_ZERO (".dtors", "\"a\"", "__DTOR_END__");
 
 /* End of .eh_frame section that provides all of the exception handling
tables.  */

Re: [PATCH 1/2] analyzer: gfortran testsuite support

[Steve Kargl]

On Mon, Feb 10, 2020 at 03:52:13PM -0500, David Malcolm wrote:
> On Sun, 2020-02-09 at 16:38 -0800, Steve Kargl wrote:
> > 
> > Having now looked at the patch, I think it's okay to commit.
> > As you note, it is new functionality in 10 so technically 
> > cannot be a regression.  But, it does fix an issue before 
> > 10 is even released.
> > 
> > OK to commit.
> 
> Thanks.
> 
> Is the Fortran testcase part of patch 2 OK as well?
> https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00394.html
> 

Yes.

-- 
Steve

New German PO file for 'cpplib' (version 10.1-b20200209)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/cpplib/de.po

(This file, 'cpplib-10.1-b20200209.de.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Contents of PO file 'cpplib-10.1-b20200209.de.po'

[Translation Project Robot]

cpplib-10.1-b20200209.de.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH 1/2] analyzer: gfortran testsuite support

[David Malcolm]

On Sun, 2020-02-09 at 16:38 -0800, Steve Kargl wrote:
> On Sun, Feb 09, 2020 at 04:19:13PM -0500, David Malcolm wrote:
> > On Sun, 2020-02-09 at 12:55 -0800, Steve Kargl wrote:
> > > On Sun, Feb 09, 2020 at 09:15:46PM +0100, Toon Moene wrote:
> > > > On 2/6/20 9:01 PM, David Malcolm wrote:
> > > > 
> > > > > PR analyzer/93405 reports an ICE when attempting to use
> > > > > -fanalyzer on
> > > > > certain gfortran code.  The second patch in this kit fixes
> > > > > that,
> > > > > but
> > > > > in the meantime I need somewhere to put regression tests for
> > > > > -fanalyzer
> > > > > with gfortran.
> > > > > 
> > > > > This patch adds a gfortran.dg/analyzer subdirectory with an
> > > > > analyzer.exp,
> > > > > setting DEFAULT_FFLAGS on the tests run within it.
> > > > 
> > > > I have seen no objections against this proposal, so please go
> > > > ahead.
> > > > 
> > > 
> > > Perhaps, there are no objections because the people who
> > > contribute
> > > patches and provide reviews for gfortran have twindled to 1 or 2
> > > people
> > > with sporadic available time.  Did you actually review the
> > > proposed
> > > changes?  If not, how can you rubber stamp this commit?  You have
> > > a
> > > total of 12 ChangeLog entries over 18 years with the last
> > > occurring
> > > in
> > > 2011, and I do not recall you ever reviewing a patch. 
> > 
> > FWIW Toon reported in BZ that patch 2 in the kit fixed the ICE he
> > had
> > reported, and I asked there if he was able to review this patch,
> > which
> > is what led to his email.
> > 
> > I'm sorry if I overstepped the mark here.
> 
> You didn't overstep the mark.  I was questioning the manner in
> which approval seem to be rubber stamped.
> 
> > >  Finally, trunk
> > > is in stage 4 (regression fixes & docs only).  This does not look
> > > like
> > > either.
> > 
> > Indeed.  The analyzer is a new feature in GCC 10.  I'm hoping some
> > latitude can be granted here given it's new (and hence all of its
> > ICEs
> > are, strictly speaking, not regressions), and this is about adding
> > test
> > coverage for fixing them.
> 
> Having now looked at the patch, I think it's okay to commit.
> As you note, it is new functionality in 10 so technically 
> cannot be a regression.  But, it does fix an issue before 
> 10 is even released.
> 
> OK to commit.

Thanks.

Is the Fortran testcase part of patch 2 OK as well?
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00394.html


Dave

Re: [PATCH] i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637]

[Uros Bizjak]

On Mon, Feb 10, 2020 at 3:33 PM Jakub Jelinek  wrote:
>
> Hi!
>
> As mentioned in the PR, for -mavx -mno-avx2 the backend does support
> vcondv4div4df and vcondv8siv8sf optabs (while generally 32-byte vectors
> aren't much supported in that case, it is performed using
> vandps/vandnps/vorps).  The problem is that after the last generic vector
> lowering (where the VEC_COND_EXPR still compares two V4DF vectors and
> has two V4DI last operands and V4DI result and so is considered ok) fre4
> folds the condition into constant, at which point the middle-end during
> expansion will try vcond_mask_optab and fall back to trying to expand it
> as the constant vector < 0 vcondv4div4di, but neither of them is supported
> for -mavx -mno-avx2 and thus we ICE.
>
> So, the options I see is either what the following patch does, also support
> vcond_mask_v4div4di and vcond_mask_v4siv4si already for TARGET_AVX, or
> require for vcondv4div4df and vcondv8siv8sf TARGET_AVX2 rather than current
> TARGET_AVX.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> Or do you prefer the disabling of the vcond patterns instead?
>
> 2020-02-10  Jakub Jelinek  
>
> PR target/93637
> * config/i386/sse.md (VI_256_AVX2): New mode iterator.
> (vcond_mask_): Use it instead of VI_256.
> Change condition from TARGET_AVX2 to TARGET_AVX.
>
> * gcc.target/i386/avx-pr93637.c: New test.

LGTM as an ICE fix for stage4. We can try Richard's suggestion "later".

Thanks,
Uros.

>
> --- gcc/config/i386/sse.md.jj   2020-02-10 13:14:02.970131692 +0100
> +++ gcc/config/i386/sse.md  2020-02-10 13:15:54.343473253 +0100
> @@ -3430,13 +3430,19 @@ (define_expand "vcond_mask_   (match_operand: 3 "register_operand")))]
>"TARGET_AVX512BW")
>
> +;; As vcondv4div4df and vcondv8siv8sf are enabled already with TARGET_AVX,
> +;; and their condition can be folded late into a constant, we need to
> +;; support vcond_mask_v4div4di and vcond_mask_v8siv8si for TARGET_AVX.
> +(define_mode_iterator VI_256_AVX2 [(V32QI "TARGET_AVX2") (V16HI 
> "TARGET_AVX2")
> +  V8SI V4DI])
> +
>  (define_expand "vcond_mask_"
> -  [(set (match_operand:VI_256 0 "register_operand")
> -   (vec_merge:VI_256
> - (match_operand:VI_256 1 "nonimmediate_operand")
> - (match_operand:VI_256 2 "nonimm_or_0_operand")
> +  [(set (match_operand:VI_256_AVX2 0 "register_operand")
> +   (vec_merge:VI_256_AVX2
> + (match_operand:VI_256_AVX2 1 "nonimmediate_operand")
> + (match_operand:VI_256_AVX2 2 "nonimm_or_0_operand")
>   (match_operand: 3 "register_operand")))]
> -  "TARGET_AVX2"
> +  "TARGET_AVX"
>  {
>ix86_expand_sse_movcc (operands[0], operands[3],
>  operands[1], operands[2]);
> --- gcc/testsuite/gcc.target/i386/avx-pr93637.c.jj  2020-02-10 
> 13:19:18.212437488 +0100
> +++ gcc/testsuite/gcc.target/i386/avx-pr93637.c 2020-02-10 13:18:25.651220171 
> +0100
> @@ -0,0 +1,17 @@
> +/* PR target/93637 */
> +/* { dg-do compile } */
> +/* { dg-options "-mavx -mno-avx2 -O3 --param 
> sccvn-max-alias-queries-per-access=3" } */
> +
> +double
> +foo (void)
> +{
> +  int i;
> +  double r = 7.0;
> +  double a[] = { 0.0, 0.0, -0.0, 0.0, 0.0, -0.0, 1.0, 0.0, 0.0, -0.0, 1.0, 
> 0.0, 1.0, 1.0 };
> +
> +  for (i = 0; i < sizeof (a) / sizeof (a[0]); ++i)
> +if (a[i] == 0.0)
> +  r = a[i];
> +
> +  return r;
> +}
>
> Jakub
>

Re: [PATCH] i386: Skip ENDBR32 at nested function entry

[Uros Bizjak]

On Mon, Feb 10, 2020 at 8:53 PM H.J. Lu  wrote:
>
> On Mon, Feb 10, 2020 at 11:40 AM Uros Bizjak  wrote:
> >
> > On Mon, Feb 10, 2020 at 8:22 PM H.J. Lu  wrote:
> > >
> > > Since nested function isn't only called directly, there is ENDBR32 at
> > > function entry and we need to skip it for direct jump in trampoline.
> >
> > Hm, I'm afraid I don't understand this comment. Can you perhaps rephrase it?
> >
>
> ix86_trampoline_init has
>
>  /* Compute offset from the end of the jmp to the target function.
>  In the case in which the trampoline stores the static chain on
>  the stack, we need to skip the first insn which pushes the
>  (call-saved) register static chain; this push is 1 byte.  */
>   offset += 5;
>   disp = expand_binop (SImode, sub_optab, fnaddr,
>plus_constant (Pmode, XEXP (m_tramp, 0),
>   offset - (MEM_P (chain) ? 1 : 0)),
>NULL_RTX, 1, OPTAB_DIRECT);
>   emit_move_insn (mem, disp);
>
> Without CET, we got
>
> 011 :
>   11: 56push   %esi
>   12: 55push   %ebp   << trampoline jumps here.
>   13: 89 e5mov%esp,%ebp
>   15: 83 ec 08  sub$0x8,%esp
>
> With CET, if bar isn't only called directly, we got
>
> 0015 :
>   15: f3 0f 1e fb  endbr32
>   19: 56push   %esi
>   1a: 55push   %ebp    trampoline jumps here.
>   1b: 89 e5mov%esp,%ebp
>   1d: 83 ec 08  sub$0x8,%esp
>
> We need to add 4 bytes for trampoline to skip endbr32.
>
> Here is the updated patch to check if nested function isn't only
> called directly,

Please figure out the final patch. I don't want to waste my time
reviewing different version every half hour. Ping me in a couple of
days.

Uros.

>
>
> --
> H.J.

Re: [PATCH] i386: Skip ENDBR32 at nested function entry

[H.J. Lu]

On Mon, Feb 10, 2020 at 11:40 AM Uros Bizjak  wrote:
>
> On Mon, Feb 10, 2020 at 8:22 PM H.J. Lu  wrote:
> >
> > Since nested function isn't only called directly, there is ENDBR32 at
> > function entry and we need to skip it for direct jump in trampoline.
>
> Hm, I'm afraid I don't understand this comment. Can you perhaps rephrase it?
>

ix86_trampoline_init has

 /* Compute offset from the end of the jmp to the target function.
 In the case in which the trampoline stores the static chain on
 the stack, we need to skip the first insn which pushes the
 (call-saved) register static chain; this push is 1 byte.  */
  offset += 5;
  disp = expand_binop (SImode, sub_optab, fnaddr,
   plus_constant (Pmode, XEXP (m_tramp, 0),
  offset - (MEM_P (chain) ? 1 : 0)),
   NULL_RTX, 1, OPTAB_DIRECT);
  emit_move_insn (mem, disp);

Without CET, we got

011 :
  11: 56push   %esi
  12: 55push   %ebp   << trampoline jumps here.
  13: 89 e5mov%esp,%ebp
  15: 83 ec 08  sub$0x8,%esp

With CET, if bar isn't only called directly, we got

0015 :
  15: f3 0f 1e fb  endbr32
  19: 56push   %esi
  1a: 55push   %ebp    trampoline jumps here.
  1b: 89 e5mov%esp,%ebp
  1d: 83 ec 08  sub$0x8,%esp

We need to add 4 bytes for trampoline to skip endbr32.

Here is the updated patch to check if nested function isn't only
called directly,


-- 
H.J.
From 10ffeb41d1cdbd42f19ba08fdd6ce4a9913a5b5b Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Mon, 10 Feb 2020 11:10:52 -0800
Subject: [PATCH] i386: Skip ENDBR32 at nested function entry

If nested function isn't only called directly, there is ENDBR32 at
function entry and we need to skip it for direct jump in trampoline.

Tested on Linux/x86-64 CET machine with and without -m32.

gcc/

	PR target/93656
	* config/i386/i386.c (ix86_trampoline_init): Skip ENDBR32 at
	nested function entry.

gcc/testsuite/

	PR target/93656
	* gcc.target/i386/pr93656.c: New test.
---
 gcc/config/i386/i386.c  | 8 +++-
 gcc/testsuite/gcc.target/i386/pr93656.c | 4 
 2 files changed, 11 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr93656.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 44bc0e0176a..bc494ec19b6 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -16839,9 +16839,15 @@ ix86_trampoline_init (rtx m_tramp, tree fndecl, rtx chain_value)
 	 the stack, we need to skip the first insn which pushes the
 	 (call-saved) register static chain; this push is 1 byte.  */
   offset += 5;
+  int skip = MEM_P (chain) ? 1 : 0;
+  /* If nested function isn't only called directly, there is ENDBR32
+	 at function entry and we need to skip it.  */
+  if (need_endbr
+	  && !cgraph_node::get (fndecl)->only_called_directly_p ())
+	skip += 4;
   disp = expand_binop (SImode, sub_optab, fnaddr,
 			   plus_constant (Pmode, XEXP (m_tramp, 0),
-	  offset - (MEM_P (chain) ? 1 : 0)),
+	  offset - skip),
 			   NULL_RTX, 1, OPTAB_DIRECT);
   emit_move_insn (mem, disp);
 }
diff --git a/gcc/testsuite/gcc.target/i386/pr93656.c b/gcc/testsuite/gcc.target/i386/pr93656.c
new file mode 100644
index 000..f0ac8c8edaa
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr93656.c
@@ -0,0 +1,4 @@
+/* { dg-do run { target { ia32 && cet } } } */
+/* { dg-options "-O2 -fcf-protection" } */
+
+#include "pr67770.c"
-- 
2.24.1

Re: [PATCH] c++: Fix return type deduction with an abbreviated function template

[Jason Merrill]

On 2/10/20 8:21 PM, Patrick Palka wrote:

On Mon, 10 Feb 2020, Jason Merrill wrote:


On 2/10/20 2:20 PM, Patrick Palka wrote:

This patch fixes two issues with return type deduction in the presence of an
abbreviated function template.

The first issue (PR 69448) is that if a placeholder auto return type
contains
any modifiers such as & or *, then the abbreviated-function-template
compensation in splice_late_return_type does not get performed for the
underlying auto node, leading to incorrect return type deduction.  This
happens
because splice_late_return_type checks for a placeholder auto with is_auto,
which does not look through modifiers.  This patch replaces the use of
is_auto
with find_type_usage, but it first refactors find_type_usage to return a
pointer
to the matched tree so that we next subsequently replace it.

The second issue (PR 80471) is that the AUTO_IS_DECLTYPE flag is not being
preserved in splice_late_return_type when compensating for an abbreviated
function template, leading to us treating a decltype(auto) return type as if
it
was an auto return type.  Fixed by propagating AUTO_IS_DECLTYPE.  The test
for
PR 80471 is adjusted to expect the correct behavior.


The comment in make_constrained_decltype_auto suggests that we should set
AUTO_IS_DECLTYPE in make_auto_1 if name == decltype_auto_identifier; then
callers won't need to worry about it.


Updated the patch to make_auto_1 to set AUTO_IS_DECLTYPE when
appropriate, and adjusted callers accordingly.  Now make_auto_1 is the
only place where we set AUTO_IS_DECLTYPE.




Bootstrapped and regtested on x86_64-pc-linux-gnu, is this OK to commit?

gcc/cp/ChangeLog:

PR c++/69448
PR c++/80471
* type-utils.h (find_type_usage): Refactor to take a tree * and to
return a tree *, and update documentation accordingly.
* pt.c (splice_late_return_type): Use find_type_usage to find and
replace a possibly nested auto node.  Preserve the AUTO_IS_DECLTYPE
flag when replacing the node.
(type_uses_auto): Adjust the call to find_type_usage.

gcc/testsuite/ChangeLog:

PR c++/69448
PR c++/80471
* g++.dg/concepts/abbrev3.C: New test.
* g++.dg/cpp2a/concepts-pr80471.C: Adjust a static_assert to expect
the
correct behavior.
---
   gcc/cp/pt.c   | 26 ---
   gcc/cp/type-utils.h   | 26 +--
   gcc/testsuite/g++.dg/concepts/abbrev3.C   | 11 
   gcc/testsuite/g++.dg/cpp2a/concepts-pr80471.C |  2 +-
   4 files changed, 41 insertions(+), 24 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/concepts/abbrev3.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2fb52caa5d4..c83aaa7c7e1 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -28904,17 +28904,21 @@ do_auto_deduction (tree type, tree init, tree
auto_node,
   tree
   splice_late_return_type (tree type, tree late_return_type)
   {
-  if (is_auto (type))
-{
-  if (late_return_type)
-   return late_return_type;
+  if (is_auto (type) && late_return_type)
+return late_return_type;


It occurs to me that we could just check late_return_type here, maybe change
the is_auto test to an assert.


Done -- I had to add a seen_error test to the assert to accomodate error
recovery and also adjust a dg-error directive in g++.dg/cpp0x/auto9.C.
Does this version look OK after testing?


OK, thanks.

Jason


-- >8 --

gcc/cp/ChangeLog:

PR c++/69448
PR c++/80471
* type-utils.h (find_type_usage): Refactor to take a tree * and to
return a tree *, and update documentation accordingly.
* pt.c (make_auto_1): Set AUTO_IS_DECLTYPE when building a
decltype(auto) node.
(make_constrained_decltype_auto): No need to explicitly set
AUTO_IS_DECLTYPE anymore.
(splice_late_return_type): Use find_type_usage to find and
replace a possibly nested auto node instead of using is_auto.
Check test for is_auto into an assert when deciding whether
to late_return_type.
(type_uses_auto): Adjust the call to find_type_usage.
* parser.c (cp_parser_decltype): No need to explicitly set
AUTO_IS_DECLTYPE anymore.

gcc/libcc1/ChangeLog:

* libcp1plugin.cc (plugin_get_expr_type): No need to explicitly set
AUTO_IS_DECLTYPE anymore.

gcc/testsuite/ChangeLog:

PR c++/69448
PR c++/80471
* g++.dg/concepts/abbrev3.C: New test.
* g++.dg/cpp2a/concepts-pr80471.C: Adjust a static_assert to expect the
correct behavior.
* g++.dg/cpp0x/auto9.C: Adjust a dg-error directive.
---
  gcc/cp/parser.c   |  7 ++---
  gcc/cp/pt.c   | 21 +--
  gcc/cp/type-utils.h   | 26 +--
  gcc/testsuite/g++.dg/concepts/abbrev3.C   | 11 
  gcc/testsuite/g++.dg/cpp0x/auto9.C|  2 +-
 

Re: [PATCH] i386: Skip ENDBR32 at nested function entry

[Uros Bizjak]

On Mon, Feb 10, 2020 at 8:22 PM H.J. Lu  wrote:
>
> Since nested function isn't only called directly, there is ENDBR32 at
> function entry and we need to skip it for direct jump in trampoline.

Hm, I'm afraid I don't understand this comment. Can you perhaps rephrase it?

Uros.

> Tested on Linux/x86-64 CET machine with and without -m32.
>
> gcc/
>
> PR target/93656
> * config/i386/i386.c (ix86_trampoline_init): Skip ENDBR32 at
> nested function entry.
>
> gcc/testsuite/
>
> PR target/93656
> * gcc.target/i386/pr93656.c: New test.
> ---
>  gcc/config/i386/i386.c  | 7 ++-
>  gcc/testsuite/gcc.target/i386/pr93656.c | 4 
>  2 files changed, 10 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr93656.c
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 44bc0e0176a..dbcae244acb 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -16839,9 +16839,14 @@ ix86_trampoline_init (rtx m_tramp, tree fndecl, rtx 
> chain_value)
>  the stack, we need to skip the first insn which pushes the
>  (call-saved) register static chain; this push is 1 byte.  */
>offset += 5;
> +  int skip = MEM_P (chain) ? 1 : 0;
> +  /* Since nested function isn't only called directly, there is
> +ENDBR32 at function entry and we need to skip it.  */
> +  if (need_endbr)
> +   skip += 4;
>disp = expand_binop (SImode, sub_optab, fnaddr,
>plus_constant (Pmode, XEXP (m_tramp, 0),
> - offset - (MEM_P (chain) ? 1 : 0)),
> + offset - skip),
>NULL_RTX, 1, OPTAB_DIRECT);
>emit_move_insn (mem, disp);
>  }
> diff --git a/gcc/testsuite/gcc.target/i386/pr93656.c 
> b/gcc/testsuite/gcc.target/i386/pr93656.c
> new file mode 100644
> index 000..f0ac8c8edaa
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr93656.c
> @@ -0,0 +1,4 @@
> +/* { dg-do run { target { ia32 && cet } } } */
> +/* { dg-options "-O2 -fcf-protection" } */
> +
> +#include "pr67770.c"
> --
> 2.24.1
>

[committed] Darwin: -Wformat-diag fix (PR93641)

[Iain Sandoe]

Hi

As show in the PR, The length used for the comparison for 'CFStringRef’ was
only comparing for 'CFString', potentially allowing mismatched identifiers.

fixed thus,
tested on x86_64-darwin16,
applied to master
thanks
Iain



Darwin: -Wformat-diag fix (PR93641)

The length used for the comparison for ‘CFStringRef' was only comparing
for ‘CFString' potentially allowing mismatched identifiers.

2020-02-10  Iain Sandoe  

   PR other/93641
   * config/darwin-c.c (darwin_cfstring_ref_p): Fix up last
   argument of strncmp.

diff --git a/gcc/config/darwin-c.c b/gcc/config/darwin-c.c
index 6b2ba2f961c..85d775f056a 100644
--- a/gcc/config/darwin-c.c
+++ b/gcc/config/darwin-c.c
@@ -809,7 +809,8 @@ darwin_cfstring_ref_p (const_tree strp)
tn = DECL_NAME (tn);
  return (tn 
  && IDENTIFIER_POINTER (tn)
- && !strncmp (IDENTIFIER_POINTER (tn), "CFStringRef", 8));
+ && !strncmp (IDENTIFIER_POINTER (tn), "CFStringRef",
+  strlen ("CFStringRef")));
}

/* At present the behavior of this is undefined and it does nothing.  */

New template for 'gcc' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'gcc' has been made available
to the language teams for translation.  It is archived as:

https://translationproject.org/POT-files/gcc-10.1-b20200209.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://gcc.gnu.org/pub/gcc/snapshots/10-20200209/gcc-10-20200209.tar.xz

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[PATCH] i386: Skip ENDBR32 at nested function entry

[H.J. Lu]

Since nested function isn't only called directly, there is ENDBR32 at
function entry and we need to skip it for direct jump in trampoline.

Tested on Linux/x86-64 CET machine with and without -m32.

gcc/

PR target/93656
* config/i386/i386.c (ix86_trampoline_init): Skip ENDBR32 at
nested function entry.

gcc/testsuite/

PR target/93656
* gcc.target/i386/pr93656.c: New test.
---
 gcc/config/i386/i386.c  | 7 ++-
 gcc/testsuite/gcc.target/i386/pr93656.c | 4 
 2 files changed, 10 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr93656.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 44bc0e0176a..dbcae244acb 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -16839,9 +16839,14 @@ ix86_trampoline_init (rtx m_tramp, tree fndecl, rtx 
chain_value)
 the stack, we need to skip the first insn which pushes the
 (call-saved) register static chain; this push is 1 byte.  */
   offset += 5;
+  int skip = MEM_P (chain) ? 1 : 0;
+  /* Since nested function isn't only called directly, there is
+ENDBR32 at function entry and we need to skip it.  */
+  if (need_endbr)
+   skip += 4;
   disp = expand_binop (SImode, sub_optab, fnaddr,
   plus_constant (Pmode, XEXP (m_tramp, 0),
- offset - (MEM_P (chain) ? 1 : 0)),
+ offset - skip),
   NULL_RTX, 1, OPTAB_DIRECT);
   emit_move_insn (mem, disp);
 }
diff --git a/gcc/testsuite/gcc.target/i386/pr93656.c 
b/gcc/testsuite/gcc.target/i386/pr93656.c
new file mode 100644
index 000..f0ac8c8edaa
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr93656.c
@@ -0,0 +1,4 @@
+/* { dg-do run { target { ia32 && cet } } } */
+/* { dg-options "-O2 -fcf-protection" } */
+
+#include "pr67770.c"
-- 
2.24.1

Re: [PATCH] c++: Fix return type deduction with an abbreviated function template

[Patrick Palka]

On Mon, 10 Feb 2020, Jason Merrill wrote:

> On 2/10/20 2:20 PM, Patrick Palka wrote:
> > This patch fixes two issues with return type deduction in the presence of an
> > abbreviated function template.
> > 
> > The first issue (PR 69448) is that if a placeholder auto return type
> > contains
> > any modifiers such as & or *, then the abbreviated-function-template
> > compensation in splice_late_return_type does not get performed for the
> > underlying auto node, leading to incorrect return type deduction.  This
> > happens
> > because splice_late_return_type checks for a placeholder auto with is_auto,
> > which does not look through modifiers.  This patch replaces the use of
> > is_auto
> > with find_type_usage, but it first refactors find_type_usage to return a
> > pointer
> > to the matched tree so that we next subsequently replace it.
> > 
> > The second issue (PR 80471) is that the AUTO_IS_DECLTYPE flag is not being
> > preserved in splice_late_return_type when compensating for an abbreviated
> > function template, leading to us treating a decltype(auto) return type as if
> > it
> > was an auto return type.  Fixed by propagating AUTO_IS_DECLTYPE.  The test
> > for
> > PR 80471 is adjusted to expect the correct behavior.
> 
> The comment in make_constrained_decltype_auto suggests that we should set
> AUTO_IS_DECLTYPE in make_auto_1 if name == decltype_auto_identifier; then
> callers won't need to worry about it.

Updated the patch to make_auto_1 to set AUTO_IS_DECLTYPE when
appropriate, and adjusted callers accordingly.  Now make_auto_1 is the
only place where we set AUTO_IS_DECLTYPE.

> 
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, is this OK to commit?
> > 
> > gcc/cp/ChangeLog:
> > 
> > PR c++/69448
> > PR c++/80471
> > * type-utils.h (find_type_usage): Refactor to take a tree * and to
> > return a tree *, and update documentation accordingly.
> > * pt.c (splice_late_return_type): Use find_type_usage to find and
> > replace a possibly nested auto node.  Preserve the AUTO_IS_DECLTYPE
> > flag when replacing the node.
> > (type_uses_auto): Adjust the call to find_type_usage.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR c++/69448
> > PR c++/80471
> > * g++.dg/concepts/abbrev3.C: New test.
> > * g++.dg/cpp2a/concepts-pr80471.C: Adjust a static_assert to expect
> > the
> > correct behavior.
> > ---
> >   gcc/cp/pt.c   | 26 ---
> >   gcc/cp/type-utils.h   | 26 +--
> >   gcc/testsuite/g++.dg/concepts/abbrev3.C   | 11 
> >   gcc/testsuite/g++.dg/cpp2a/concepts-pr80471.C |  2 +-
> >   4 files changed, 41 insertions(+), 24 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/concepts/abbrev3.C
> > 
> > diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> > index 2fb52caa5d4..c83aaa7c7e1 100644
> > --- a/gcc/cp/pt.c
> > +++ b/gcc/cp/pt.c
> > @@ -28904,17 +28904,21 @@ do_auto_deduction (tree type, tree init, tree
> > auto_node,
> >   tree
> >   splice_late_return_type (tree type, tree late_return_type)
> >   {
> > -  if (is_auto (type))
> > -{
> > -  if (late_return_type)
> > -   return late_return_type;
> > +  if (is_auto (type) && late_return_type)
> > +return late_return_type;
> 
> It occurs to me that we could just check late_return_type here, maybe change
> the is_auto test to an assert.

Done -- I had to add a seen_error test to the assert to accomodate error
recovery and also adjust a dg-error directive in g++.dg/cpp0x/auto9.C.
Does this version look OK after testing?

-- >8 --

gcc/cp/ChangeLog:

PR c++/69448
PR c++/80471
* type-utils.h (find_type_usage): Refactor to take a tree * and to
return a tree *, and update documentation accordingly.
* pt.c (make_auto_1): Set AUTO_IS_DECLTYPE when building a
decltype(auto) node.
(make_constrained_decltype_auto): No need to explicitly set
AUTO_IS_DECLTYPE anymore.
(splice_late_return_type): Use find_type_usage to find and
replace a possibly nested auto node instead of using is_auto.
Check test for is_auto into an assert when deciding whether
to late_return_type.
(type_uses_auto): Adjust the call to find_type_usage.
* parser.c (cp_parser_decltype): No need to explicitly set
AUTO_IS_DECLTYPE anymore.

gcc/libcc1/ChangeLog:

* libcp1plugin.cc (plugin_get_expr_type): No need to explicitly set
AUTO_IS_DECLTYPE anymore.

gcc/testsuite/ChangeLog:

PR c++/69448
PR c++/80471
* g++.dg/concepts/abbrev3.C: New test.
* g++.dg/cpp2a/concepts-pr80471.C: Adjust a static_assert to expect the
correct behavior.
* g++.dg/cpp0x/auto9.C: Adjust a dg-error directive.
---
 gcc/cp/parser.c   |  7 ++---
 gcc/cp/pt.c   | 21 +--
 gcc/cp/type-utils.h  

New Ukrainian PO file for 'cpplib' (version 10.1-b20200209)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

https://translationproject.org/latest/cpplib/uk.po

(This file, 'cpplib-10.1-b20200209.uk.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/cpplib/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/cpplib.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Contents of PO file 'cpplib-10.1-b20200209.uk.po'

[Translation Project Robot]

cpplib-10.1-b20200209.uk.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New template for 'cpplib' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'cpplib' has been made available
to the language teams for translation.  It is archived as:

https://translationproject.org/POT-files/cpplib-10.1-b20200209.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://gcc.gnu.org/pub/gcc/snapshots/10-20200209/gcc-10-20200209.tar.xz

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: patch, fortan] PR83113 Bogus "duplicate allocatable attribute" error for submodule character function

[Andrew Benson]

Thanks - that worked.

On Monday, February 10, 2020 12:18:57 PM PST Segher Boessenkool wrote:
> On Mon, Feb 10, 2020 at 10:05:48AM -0800, Andrew Benson wrote:
> > I don't think I have the ability to mark the PR as resolved. Can someone
> > do
> > that?
> 
> You have an @gcc.gnu.org account; if you use that for your BZ account,
> you will magically get everything you need here.
> 
> 
> Segher


-- 

* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html

* Galacticus: https://github.com/galacticusorg/galacticus

[PATCH], Rename and document PowerPC -mprefixed-addr to -mprefixed

[Michael Meissner]

This patch renames the PowerPC internal switch -mprefixed-addr to be
-mprefixed.

Last week, Bill, Segher, and I were talking, and we came to the conclusion that
we needed to make the prefixed addressing option more public.  This is
particularly true, when you consider that only 64-bit little endian Linux will
have support for these mode.  Other OSes, ABI's, etc. out there that may/may
not support all of the new addressing modes in the 'future' computer.  And we
also decided, we preferred the simpler '-mprefixed' option over
'-mprefixed-addr'.

If you use -mno-prefixed, you get the current addressing modes on your system
for power9 and the compiler will not generate the prefixed loads or stores.

If you use -mprefixed -mno-pcrel, the compiler will generate prefixed loads and
stores utilizing 34-bit offset addressing with numeric offsets that don't need
relocation.  It will not generate PC-relative loads and stores.

If you use -mpcrel, you must be using the 64-bit ELF v2 ABI, and the code model
must be medium.  If you use -mpcrel, the compiler will generate PC-relative
loads and stores to access items, rather than the current TOC based loads and
stores.

If you use -mpcrel, it implies -mprefixed.  If you use -mno-prefixed, you
cannot use -mpcrel.

With the exception of making the switch a public switch, and documenting it,
this patch is just a simple mechanical conversion, converting
TARGET_PREFIXED_ADDR to TARGET_PREFIXED, etc.

Because the -mprefixed-addr was just an internal and undocumented switch, I
have not provided for an alias between -mprefixed to -mprefixed-addr (though I
can do that if desired).

I have tested these patches on both little endian and big endian Linux 64-bit
systems, and there were no regressions.  Can I check these patches into the
master GCC branch for GCC 10?

2020-02-10  Michael Meissner  

* config/rs6000/predicates.md (cint34_operand): Rename the
-mprefixed-addr option to be -mprefixed.
* config/rs6000/rs6000-cpus.def (ISA_FUTURE_MASKS_SERVER): Rename
the -mprefixed-addr option to be -mprefixed.
(OTHER_FUTURE_MASKS): Likewise.
(POWERPC_MASKS): Likewise.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Rename
the -mprefixed-addr option to be -mprefixed.  Change error
messages to refer to -mprefixed.
(num_insns_constant_gpr): Rename the -mprefixed-addr option to be
-mprefixed.
(rs6000_legitimate_offset_address_p): Likewise.
(rs6000_mode_dependent_address): Likewise.
(rs6000_opt_masks): Change the spelling of "-mprefixed-addr" to be
"-mprefixed" for target attributes and pragmas.
(address_to_insn_form): Rename the -mprefixed-addr option to be
-mprefixed.
(rs6000_adjust_insn_length): Likewise.
* config/rs6000/rs6000.h (FINAL_PRESCAN_INSN): Rename the
-mprefixed-addr option to be -mprefixed.
(ASM_OUTPUT_OPCODE): Likewise.
* config/rs6000/rs6000.md (prefixed insn attribute): Rename the
-mprefixed-addr option to be -mprefixed.
* config/rs6000/rs6000.opt (-mprefixed): Rename the
-mprefixed-addr option to be prefixed.  Change the option from
being undocumented to being documented.
* doc/invoke.texi (RS/6000 and PowerPC Options): Docment the
-mprefixed option.  Update the -mpcrel documentation to mention
-mprefixed.

--- /tmp/N41Ptv_predicates.md   2020-02-07 17:56:52.590487419 -0500
+++ gcc/config/rs6000/predicates.md 2020-02-07 17:34:02.891610645 -0500
@@ -306,7 +306,7 @@ (define_predicate "const_0_to_15_operand
 (define_predicate "cint34_operand"
   (match_code "const_int")
 {
-  if (!TARGET_PREFIXED_ADDR)
+  if (!TARGET_PREFIXED)
 return 0;
 
   return SIGNED_INTEGER_34BIT_P (INTVAL (op));
--- /tmp/aS8nV8_rs6000-cpus.def 2020-02-07 17:56:52.599487550 -0500
+++ gcc/config/rs6000/rs6000-cpus.def   2020-02-07 17:34:02.894610688 -0500
@@ -79,11 +79,11 @@
is fully functional.  */
 #define ISA_FUTURE_MASKS_SERVER(ISA_3_0_MASKS_SERVER   
\
 | OPTION_MASK_FUTURE   \
-| OPTION_MASK_PREFIXED_ADDR)
+| OPTION_MASK_PREFIXED)
 
 /* Flags that need to be turned off if -mno-future.  */
 #define OTHER_FUTURE_MASKS (OPTION_MASK_PCREL  \
-| OPTION_MASK_PREFIXED_ADDR)
+| OPTION_MASK_PREFIXED)
 
 /* Flags that need to be turned off if -mno-power9-vector.  */
 #define OTHER_P9_VECTOR_MASKS  (OPTION_MASK_FLOAT128_HW\
@@ -143,7 +143,7 @@
 | OPTION_MASK_POWERPC64\
 | OPTION_MASK_PPC_GFXOPT   \
 | OPTION_MASK_PPC_GPOPT\
-| OPTION_MASK_PREFIXED_ADDR

Re: [PATCH] c++: Fix return type deduction with an abbreviated function template

[Jason Merrill]

On 2/10/20 2:20 PM, Patrick Palka wrote:

This patch fixes two issues with return type deduction in the presence of an
abbreviated function template.

The first issue (PR 69448) is that if a placeholder auto return type contains
any modifiers such as & or *, then the abbreviated-function-template
compensation in splice_late_return_type does not get performed for the
underlying auto node, leading to incorrect return type deduction.  This happens
because splice_late_return_type checks for a placeholder auto with is_auto,
which does not look through modifiers.  This patch replaces the use of is_auto
with find_type_usage, but it first refactors find_type_usage to return a pointer
to the matched tree so that we next subsequently replace it.

The second issue (PR 80471) is that the AUTO_IS_DECLTYPE flag is not being
preserved in splice_late_return_type when compensating for an abbreviated
function template, leading to us treating a decltype(auto) return type as if it
was an auto return type.  Fixed by propagating AUTO_IS_DECLTYPE.  The test for
PR 80471 is adjusted to expect the correct behavior.


The comment in make_constrained_decltype_auto suggests that we should 
set AUTO_IS_DECLTYPE in make_auto_1 if name == decltype_auto_identifier; 
then callers won't need to worry about it.



Bootstrapped and regtested on x86_64-pc-linux-gnu, is this OK to commit?

gcc/cp/ChangeLog:

PR c++/69448
PR c++/80471
* type-utils.h (find_type_usage): Refactor to take a tree * and to
return a tree *, and update documentation accordingly.
* pt.c (splice_late_return_type): Use find_type_usage to find and
replace a possibly nested auto node.  Preserve the AUTO_IS_DECLTYPE
flag when replacing the node.
(type_uses_auto): Adjust the call to find_type_usage.

gcc/testsuite/ChangeLog:

PR c++/69448
PR c++/80471
* g++.dg/concepts/abbrev3.C: New test.
* g++.dg/cpp2a/concepts-pr80471.C: Adjust a static_assert to expect the
correct behavior.
---
  gcc/cp/pt.c   | 26 ---
  gcc/cp/type-utils.h   | 26 +--
  gcc/testsuite/g++.dg/concepts/abbrev3.C   | 11 
  gcc/testsuite/g++.dg/cpp2a/concepts-pr80471.C |  2 +-
  4 files changed, 41 insertions(+), 24 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/concepts/abbrev3.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2fb52caa5d4..c83aaa7c7e1 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -28904,17 +28904,21 @@ do_auto_deduction (tree type, tree init, tree 
auto_node,
  tree
  splice_late_return_type (tree type, tree late_return_type)
  {
-  if (is_auto (type))
-{
-  if (late_return_type)
-   return late_return_type;
+  if (is_auto (type) && late_return_type)
+return late_return_type;


It occurs to me that we could just check late_return_type here, maybe 
change the is_auto test to an assert.


  
-  tree idx = get_template_parm_index (type);

+  if (tree *auto_node = find_type_usage (, is_auto))
+{
+  tree idx = get_template_parm_index (*auto_node);
if (TEMPLATE_PARM_LEVEL (idx) <= processing_template_decl)
-   /* In an abbreviated function template we didn't know we were dealing
-  with a function template when we saw the auto return type, so update
-  it to have the correct level.  */
-   return make_auto_1 (TYPE_IDENTIFIER (type), true);
+   {
+ /* In an abbreviated function template we didn't know we were dealing
+with a function template when we saw the auto return type, so
+update it to have the correct level.  */
+ tree new_node = make_auto_1 (TYPE_IDENTIFIER (*auto_node), true);
+ AUTO_IS_DECLTYPE (new_node) = AUTO_IS_DECLTYPE (*auto_node);
+ *auto_node = new_node;
+   }
  }
return type;
  }
@@ -28960,8 +28964,10 @@ type_uses_auto (tree type)
else
return NULL_TREE;
  }
+  else if (tree *tp = find_type_usage (, is_auto))
+return *tp;
else
-return find_type_usage (type, is_auto);
+return NULL_TREE;
  }
  
  /* Report ill-formed occurrences of auto types in ARGUMENTS.  If

diff --git a/gcc/cp/type-utils.h b/gcc/cp/type-utils.h
index 680b2497a36..4ad0d822119 100644
--- a/gcc/cp/type-utils.h
+++ b/gcc/cp/type-utils.h
@@ -20,36 +20,36 @@ along with GCC; see the file COPYING3.  If not see
  #ifndef GCC_CP_TYPE_UTILS_H
  #define GCC_CP_TYPE_UTILS_H
  
-/* Returns the first tree within T that is directly matched by PRED.  T may be a

-   type or PARM_DECL and is incrementally decomposed toward its type-specifier
-   until a match is found.  NULL_TREE is returned if PRED does not match any
-   part of T.
+/* Returns a pointer to the first tree within *TP that is directly matched by
+   PRED.  *TP may be a type or PARM_DECL and is incrementally decomposed toward
+   its type-specifier until a match is found.  NULL is returned if 

Re: patch, fortan] PR83113 Bogus "duplicate allocatable attribute" error for submodule character function

[Segher Boessenkool]

On Mon, Feb 10, 2020 at 10:05:48AM -0800, Andrew Benson wrote:
> I don't think I have the ability to mark the PR as resolved. Can someone do 
> that?

You have an @gcc.gnu.org account; if you use that for your BZ account,
you will magically get everything you need here.


Segher

Re: [PATCH] c++: Improve dump_decl for standard concepts

[Jason Merrill]

On 2/10/20 5:28 PM, Patrick Palka wrote:

This patch improves the pretty printing of standard concept definitions in error
messages.  In particular, standard concepts are now printed qualified whenever
appropriate, and the "concept" specifier is printed only when the
TFF_DECL_SPECIFIERS flag is specified.

In the below test, the first error message changes from
   9:15: error: ‘b’ was not declared in this scope; did you mean ‘concept b’?
to
   9:15: error: ‘b’ was not declared in this scope; did you mean ‘a::b’?

Tested on x86_64-pc-linux-gnu, is this OK to commit?


OK.


gcc/cp/ChangeLog:

* error.c (dump_decl) [CONCEPT_DECL]: Use dump_simple_decl.
(dump_simple_decl): Handle standard concept definitions as well as
variable concept definitions.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts6.C: New test.
---
  gcc/cp/error.c | 18 --
  gcc/testsuite/g++.dg/cpp2a/concepts6.C | 18 ++
  2 files changed, 26 insertions(+), 10 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts6.C

diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 973b3034e12..a56d83e1f45 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -1037,14 +1037,13 @@ dump_simple_decl (cxx_pretty_printer *pp, tree t, tree 
type, int flags)
  
if (flags & TFF_DECL_SPECIFIERS)

  {
-  if (VAR_P (t) && DECL_DECLARED_CONSTEXPR_P (t))
-{
- if (DECL_LANG_SPECIFIC (t) && DECL_DECLARED_CONCEPT_P (t))
-   pp_cxx_ws_string (pp, "concept");
- else
-   pp_cxx_ws_string (pp, "constexpr");
-   }
-  dump_type_prefix (pp, type, flags & ~TFF_UNQUALIFIED_NAME);
+  if (concept_definition_p (t))
+   pp_cxx_ws_string (pp, "concept");
+  else if (VAR_P (t) && DECL_DECLARED_CONSTEXPR_P (t))
+   pp_cxx_ws_string (pp, "constexpr");
+
+  if (!standard_concept_p (t))
+   dump_type_prefix (pp, type, flags & ~TFF_UNQUALIFIED_NAME);
pp_maybe_space (pp);
  }
if (! (flags & TFF_UNQUALIFIED_NAME)
@@ -1296,8 +1295,7 @@ dump_decl (cxx_pretty_printer *pp, tree t, int flags)
break;
  
  case CONCEPT_DECL:

-  pp_cxx_ws_string (pp, "concept");
-  dump_decl_name (pp, DECL_NAME (t), flags);
+  dump_simple_decl (pp, t, TREE_TYPE (t), flags);
break;
  
  case WILDCARD_DECL:

diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts6.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts6.C
new file mode 100644
index 000..d69628b0318
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts6.C
@@ -0,0 +1,18 @@
+// { dg-do compile { target c++2a } }
+
+namespace a
+{
+  template
+concept b = true; // { dg-message ".a::b. declared here" }
+}
+
+static_assert(b); // { dg-error "did you mean .a::b." }
+
+namespace c
+{
+  template
+concept b = true; // { dg-message "concept c::b." }
+
+  template
+concept b = true; // { dg-error "concept c::b." }
+}

Re: [committed] i386: Fix strncmp last arguments in x86_64_elf_section_type_flags [PR93641]

[Jakub Jelinek]

On Mon, Feb 10, 2020 at 12:00:28PM -0600, Segher Boessenkool wrote:
> On Mon, Feb 10, 2020 at 03:07:49PM +0100, Jakub Jelinek wrote:
> > +  || strncmp (name, ".lbss.", sizeof (".lbss.") - 1) == 0
> 
> You can just use  strlen (".lbss.")  which is nicer to read and compiles
> to the same thing?

By GCC yes, non-GCC compilers might not.  Though admittedly, we probably
don't care.

We use sizeof ("...") - 1 or sizeof "..." - 1 in a lot of places though.

gcc.c:&& (p1[sizeof "%include" - 1] == ' '
gcc.c:|| p1[sizeof "%include" - 1] == '\t'))
gcc.c:else if (!strncmp (p1, "%include_noerr", sizeof "%include_noerr" - 1)
gcc.c: && (p1[sizeof "%include_noerr" - 1] == ' '
gcc.c: || p1[sizeof "%include_noerr" - 1] == '\t'))
gcc.c:else if (!strncmp (p1, "%rename", sizeof "%rename" - 1)
gcc.c: && (p1[sizeof "%rename" - 1] == ' '
gcc.c: || p1[sizeof "%rename" - 1] == '\t'))
gcc.c:  if (sl->name_len == sizeof "self_spec" - 1
c-family/c-format.c:  if (!strncmp (format_chars, "__attribute", sizeof 
"__attribute" - 1))
c-family/c-format.c:  unsigned nchars = sizeof "__attribute" - 1;
c-family/c-format.c:  && (!strncmp (format_chars + 2, "atomic", sizeof 
"atomic" - 1)
c-family/c-format.c:  || !strncmp (format_chars + 2, "builtin", sizeof 
"builtin" - 1)
c-family/c-format.c:  || !strncmp (format_chars + 2, "sync", sizeof "sync" 
- 1)))
[jakub@tucnak gcc]$ grep 'sizeof ("[^"]*") - 1' *.[ch] */*.[ch] */*/*.[ch]
asan.c:  name[sizeof ("__odr_asan") - 1] = '.';
asan.c:  name[sizeof ("__odr_asan") - 1] = '$';
collect2.c:  if (strncmp (name, "not found", sizeof ("not found") - 1) == 0)
gcc.c:if (!strncmp (p1, "%include", sizeof ("%include") - 1)
gcc.c:  if (len > (int) sizeof ("/lib/gcc/") - 1
gcc.c:  len -= sizeof ("/lib/gcc/") - 1;
gcc.c:  sizeof ("COLLECT_GCC_OPTIONS=") - 1);
gcc.c:  obstack_grow (_obstack, "COLLECT_GCC=", sizeof ("COLLECT_GCC=") 
- 1);
gcc.c:  sizeof ("COLLECT_LTO_WRAPPER=") - 1);
gcc.c:  sizeof ("OFFLOAD_TARGET_NAMES=") - 1);
lto-wrapper.c: sizeof ("-foffload-objects=") - 1) == 0)
lto-wrapper.c:  = argv[i] + sizeof ("-foffload-objects=") - 1;
c/c-parser.c:  + sizeof ("omp declare reduction ") 
- 1,
fortran/module.c: const char *p = name + sizeof ("operator ") - 1;
fortran/trans-io.c:  memcpy (name + sizeof ("__st_parameter_") - 1, 
st_parameter[ptype].name,
config/arm/driver-arm.c:  if (strncmp (buf, "CPU implementer", sizeof ("CPU 
implementer") - 1) == 0)
config/arm/driver-arm.c:  if (strncmp (buf, "CPU part", sizeof ("CPU part") 
- 1) == 0)
config/frv/frv.h: sizeof ("__trampoline_setup bad size\n") - 1);
\
config/frv/frv.h: sizeof ("__trampoline_setup bad size\n") - 1);
\
config/i386/i386.c:  || strncmp (name, ".lbss.", sizeof (".lbss.") - 1) == 0
config/i386/i386.c:   sizeof (".gnu.linkonce.lb.") - 1) == 0)
config/mips/driver-native.c:if (strncmp (buf, "cpu model", sizeof ("cpu 
model") - 1) == 0)
config/msp430/msp430.c: sizeof ("__mspabi_mpy") - 1) == 0;
config/msp430/msp430-devices.c:  if (len > (int) sizeof ("/lib/gcc/") - 1
config/msp430/msp430-devices.c:   len -= sizeof ("/lib/gcc/") - 1;
config/pa/som.h:   sizeof ("shared library list:") - 1) == 0)   
\
config/pa/som.h:sizeof ("shared library binding:") - 1) == 
0)\
config/pa/som.h:sizeof ("static branch prediction 
disabled") - 1) == 0)\
config/pa/som.h:   &&  strncmp (PTR, "dynamic", sizeof ("dynamic") - 1) 
== 0) \
config/pa/som.h:  PTR += sizeof ("dynamic") - 1;
\
config/pa/som.h:   && strncmp (PTR, "static", sizeof ("static") - 1) == 
0) \
config/pa/som.h:  PTR += sizeof ("static") - 1; 
\
config/rs6000/rs6000.c:spaces += sizeof ("  Reload=sl") - 1;
config/rs6000/rs6000.c:spaces += sizeof ("  Upper=y") - 1;
config/rs6000/rs6000.c:  strcpy (name, bname + sizeof ("__builtin_") - 1);
config/rs6000/rs6000.c:   len += sizeof ("no-") - 1;
config/rs6000/rs6000.c:   len += sizeof ("no-") - 1;
config/rs6000/rs6000.c:  comma_len = sizeof (", ") - 1;
config/sparc/driver-sparc.c:if (strncmp (buf, "cpu\t\t:", sizeof 
("cpu\t\t:") - 1) == 0)

Jakub

Re: patch, fortan] PR83113 Bogus "duplicate allocatable attribute" error for submodule character function

[Andrew Benson]

I don't think I have the ability to mark the PR as resolved. Can someone do 
that?

On Monday, February 10, 2020 10:02:24 AM PST Andrew Benson wrote:
> This is now committed (after adding the macro as Steve suggested):
> 
> https://gcc.gnu.org/g:7848054c68bad6e2aa40cb59f77cc99bd8448d52
> 
> On Sunday, February 9, 2020 4:32:26 PM PST Steve Kargl wrote:
> > Patch looks to me.  OK to commit.
> > 
> > I'm wondering if we need a macro or helper function to
> > simplify in conditional from
> > 
> > +  if (gfc_state_stack->previous && gfc_state_stack->previous->previous
> > +  && gfc_state_stack->previous->previous->state == COMP_SUBMODULE
> > +  && sym->attr.module_procedure)
> > 
> > to for example
> > 
> > +  if (IN_SUBMODULE (sym))
> > 
> > where is
> > 
> > #define IN_SUBMODULE (x) \
> > 
> >(gfc_state_stack->previous && gfc_state_stack->previous->previous \
> >
> > && gfc_state_stack->previous->previous->state == COMP_SUBMODULE \
> > && sym->attr.module_procedure)
> > > 
> > > *ping*
> > > 
> > > On Friday, January 31, 2020 5:06:49 PM PST Andrew Benson wrote:
> > > > I've attached on updated patch for PR83113. The now removes the ICE
> > > > when
> > > > a
> > > > duplicate DIMENSION attribute is specified in a submodule function. 
> > > > The
> > > > patch reg tests cleanly.
> > > > 
> > > > OK to commit?
> > > > 
> > > > Note that this patch doesn't check that the attributes of duplicate
> > > > declarations in a submodule function are valid or consistent with
> > > > those
> > > > declared in the module. For example both:
> > > > 
> > > > module mm
> > > > 
> > > >   implicit none
> > > >   interface
> > > >   
> > > >  module function c()
> > > >  
> > > >integer, dimension(2)  :: c !! Dimension 2 here
> > > >  
> > > >  end function c
> > > >   
> > > >   end interface
> > > > 
> > > > end module mm
> > > > 
> > > > submodule (mm) oo
> > > > 
> > > >   implicit none
> > > > 
> > > > contains
> > > > 
> > > >   module function c()
> > > >   
> > > > integer, dimension(3)  :: c  !! Inconsistent dimension 3 here
> > > >   
> > > >   end function c
> > > > 
> > > > end submodule oo
> > > > 
> > > > 
> > > > and
> > > > 
> > > > 
> > > > module mm
> > > > 
> > > >   implicit none
> > > >   interface
> > > >   
> > > >  module function c()
> > > >  
> > > >integer, dimension(2)  :: c !! Dimension 2 here
> > > >  
> > > >  end function c
> > > >   
> > > >   end interface
> > > > 
> > > > end module mm
> > > > 
> > > > submodule (mm) oo
> > > > 
> > > >   implicit none
> > > > 
> > > > contains
> > > > 
> > > >   module function c()
> > > >   
> > > > integer, dimension(:)  :: c !! Invalid cannot have a deferred
> > > > shape
> > > >   
> > > >   end function c
> > > > 
> > > > end submodule oo
> > > > 
> > > > 
> > > > compile successfully, but should be rejected. Presumably we should add
> > > > some
> > > > check that the attributes of the declaration in the submodule match
> > > > those in the module?
> > > > 
> > > > If so, I can go ahead and open a PR for this problem.
> > > > 
> > > > -Andrew
> > > > 
> > > > On Friday, January 24, 2020 10:54:24 AM PST Andrew Benson wrote:
> > > > > Below is a partial patch for PR 83113
> > > > > 
> > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83113
> > > > > 
> > > > > It simply circumvents the check for duplicate attributes when
> > > > > looking
> > > > > at
> > > > > declarations in a module procedure during compilation of a
> > > > > submodule.
> > > > > 
> > > > > As it stands, the patch handles the cases of "allocatable",
> > > > > "dimension",
> > > > > and "pointer" attributes (corresponding to the two test cases in the
> > > > > PR
> > > > > plus a case that showed up in my own code). There are other
> > > > > attributes
> > > > > which should be handled similarly but before I make those changes I
> > > > > wanted to seek some opinions on whether this is the correct/best way
> > > > > to
> > > > > fix this issue.
> > > > > 
> > > > > The patch regression tests cleanly - however,  while the patch
> > > > > solves
> > > > > the
> > > > > "duplicate attribute" problem for the test case in comment #4:
> > > > > 
> > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83113#c4
> > > > > 
> > > > > that test case then ICEs with:
> > > > > 
> > > > > $ gfortran -c pr83113_2.F90 -o pr83113_2.o
> > > > > f951: internal compiler error: in gfc_set_array_spec, at
> > > > > fortran/array.c:879 0x5fd22f gfc_set_array_spec(gfc_symbol*,
> > > > > gfc_array_spec*, locus*)
> > > > > 
> > > > > ../../gcc-git/gcc/fortran/array.c:879
> > > > > 
> > > > > 0x7e868e build_sym
> > > > > 
> > > > > ../../gcc-git/gcc/fortran/decl.c:1670
> > > > > 
> > > > > 0x7f0ada variable_decl
> > > > > 
> > > > > ../../gcc-git/gcc/fortran/decl.c:2760
> > > > > 
> > > > > 0x7f0ada gfc_match_data_decl()
> > > > > 
> > > > > ../../gcc-git/gcc/fortran/decl.c:6120
> > > > > 
> > > 

Re: patch, fortan] PR83113 Bogus "duplicate allocatable attribute" error for submodule character function

[Andrew Benson]

This is now committed (after adding the macro as Steve suggested):

https://gcc.gnu.org/g:7848054c68bad6e2aa40cb59f77cc99bd8448d52

On Sunday, February 9, 2020 4:32:26 PM PST Steve Kargl wrote:
> Patch looks to me.  OK to commit.
> 
> I'm wondering if we need a macro or helper function to
> simplify in conditional from
> 
> +  if (gfc_state_stack->previous && gfc_state_stack->previous->previous
> +  && gfc_state_stack->previous->previous->state == COMP_SUBMODULE
> +  && sym->attr.module_procedure)
> 
> to for example
> 
> +  if (IN_SUBMODULE (sym))
> 
> where is
> 
> #define IN_SUBMODULE (x) \
>(gfc_state_stack->previous && gfc_state_stack->previous->previous \
> && gfc_state_stack->previous->previous->state == COMP_SUBMODULE \
> && sym->attr.module_procedure)
> 
> > *ping*
> > 
> > On Friday, January 31, 2020 5:06:49 PM PST Andrew Benson wrote:
> > > I've attached on updated patch for PR83113. The now removes the ICE when
> > > a
> > > duplicate DIMENSION attribute is specified in a submodule function.  The
> > > patch reg tests cleanly.
> > > 
> > > OK to commit?
> > > 
> > > Note that this patch doesn't check that the attributes of duplicate
> > > declarations in a submodule function are valid or consistent with those
> > > declared in the module. For example both:
> > > 
> > > module mm
> > > 
> > >   implicit none
> > >   interface
> > >   
> > >  module function c()
> > >  
> > >integer, dimension(2)  :: c !! Dimension 2 here
> > >  
> > >  end function c
> > >   
> > >   end interface
> > > 
> > > end module mm
> > > 
> > > submodule (mm) oo
> > > 
> > >   implicit none
> > > 
> > > contains
> > > 
> > >   module function c()
> > >   
> > > integer, dimension(3)  :: c  !! Inconsistent dimension 3 here
> > >   
> > >   end function c
> > > 
> > > end submodule oo
> > > 
> > > 
> > > and
> > > 
> > > 
> > > module mm
> > > 
> > >   implicit none
> > >   interface
> > >   
> > >  module function c()
> > >  
> > >integer, dimension(2)  :: c !! Dimension 2 here
> > >  
> > >  end function c
> > >   
> > >   end interface
> > > 
> > > end module mm
> > > 
> > > submodule (mm) oo
> > > 
> > >   implicit none
> > > 
> > > contains
> > > 
> > >   module function c()
> > >   
> > > integer, dimension(:)  :: c !! Invalid cannot have a deferred shape
> > >   
> > >   end function c
> > > 
> > > end submodule oo
> > > 
> > > 
> > > compile successfully, but should be rejected. Presumably we should add
> > > some
> > > check that the attributes of the declaration in the submodule match
> > > those in the module?
> > > 
> > > If so, I can go ahead and open a PR for this problem.
> > > 
> > > -Andrew
> > > 
> > > On Friday, January 24, 2020 10:54:24 AM PST Andrew Benson wrote:
> > > > Below is a partial patch for PR 83113
> > > > 
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83113
> > > > 
> > > > It simply circumvents the check for duplicate attributes when looking
> > > > at
> > > > declarations in a module procedure during compilation of a submodule.
> > > > 
> > > > As it stands, the patch handles the cases of "allocatable",
> > > > "dimension",
> > > > and "pointer" attributes (corresponding to the two test cases in the
> > > > PR
> > > > plus a case that showed up in my own code). There are other attributes
> > > > which should be handled similarly but before I make those changes I
> > > > wanted to seek some opinions on whether this is the correct/best way
> > > > to
> > > > fix this issue.
> > > > 
> > > > The patch regression tests cleanly - however,  while the patch solves
> > > > the
> > > > "duplicate attribute" problem for the test case in comment #4:
> > > > 
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83113#c4
> > > > 
> > > > that test case then ICEs with:
> > > > 
> > > > $ gfortran -c pr83113_2.F90 -o pr83113_2.o
> > > > f951: internal compiler error: in gfc_set_array_spec, at
> > > > fortran/array.c:879 0x5fd22f gfc_set_array_spec(gfc_symbol*,
> > > > gfc_array_spec*, locus*)
> > > > 
> > > > ../../gcc-git/gcc/fortran/array.c:879
> > > > 
> > > > 0x7e868e build_sym
> > > > 
> > > > ../../gcc-git/gcc/fortran/decl.c:1670
> > > > 
> > > > 0x7f0ada variable_decl
> > > > 
> > > > ../../gcc-git/gcc/fortran/decl.c:2760
> > > > 
> > > > 0x7f0ada gfc_match_data_decl()
> > > > 
> > > > ../../gcc-git/gcc/fortran/decl.c:6120
> > > > 
> > > > 0x85b66d match_word
> > > > 
> > > > ../../gcc-git/gcc/fortran/parse.c:65
> > > > 
> > > > 0x85b66d decode_statement
> > > > 
> > > > ../../gcc-git/gcc/fortran/parse.c:376
> > > > 
> > > > 0x861094 next_free
> > > > 
> > > > ../../gcc-git/gcc/fortran/parse.c:1279
> > > > 
> > > > 0x861094 next_statement
> > > > 
> > > > ../../gcc-git/gcc/fortran/parse.c:1511
> > > > 
> > > > 0x8638ac parse_spec
> > > > 
> > > > ../../gcc-git/gcc/fortran/parse.c:3738
> > > > 
> > > > 0x86591c parse_progunit
> > > > 
> > > >   

Re: [committed] i386: Fix strncmp last arguments in x86_64_elf_section_type_flags [PR93641]

[Segher Boessenkool]

On Mon, Feb 10, 2020 at 03:07:49PM +0100, Jakub Jelinek wrote:
> +  || strncmp (name, ".lbss.", sizeof (".lbss.") - 1) == 0

You can just use  strlen (".lbss.")  which is nicer to read and compiles
to the same thing?


Segher

Re: [PATCH] fix off-by-one mistakes in attribute access syntax checking (PR 93640)

[Jakub Jelinek]

On Mon, Feb 10, 2020 at 10:20:50AM -0700, Martin Sebor wrote:
> PR 93641 points out a number of off-by-one mistakes in calls to strncmp
> in GCC where the bound is (unintentionally) less than the length of
> the string literal argument.
> 
> PR 93640 is a separate report of another such mistake in the code that
> validates the mode argument in attribute access.  As a result, the code
> accepts even some invalid modes.  The attached patch fixes these.
> 
> It's not technically a regression so I was going to wait until stage
> 1 to submit a fix but seeing that Jakub already committed fixes for
> the former I figure I should also handle this one for GCC 10.
> 
> Tested on x86_64-linux.

Ok, thanks.

> PR c/93640 - The write_only and read_write attributes can be mistyped due to 
> invalid strncmp size argument
> 
> gcc/c-family/ChangeLog:
> 
>   PR c/93640
>   * c-attribs.c (handle_access_attribute): Correct off-by-one mistakes.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c/93640
>   * gcc.dg/attr-access.c: New test.

Jakub

[PATCH] fix off-by-one mistakes in attribute access syntax checking (PR 93640)

[Martin Sebor]

PR 93641 points out a number of off-by-one mistakes in calls to strncmp
in GCC where the bound is (unintentionally) less than the length of
the string literal argument.

PR 93640 is a separate report of another such mistake in the code that
validates the mode argument in attribute access.  As a result, the code
accepts even some invalid modes.  The attached patch fixes these.

It's not technically a regression so I was going to wait until stage
1 to submit a fix but seeing that Jakub already committed fixes for
the former I figure I should also handle this one for GCC 10.

Tested on x86_64-linux.

Martin
PR c/93640 - The write_only and read_write attributes can be mistyped due to invalid strncmp size argument

gcc/c-family/ChangeLog:

	PR c/93640
	* c-attribs.c (handle_access_attribute): Correct off-by-one mistakes.

gcc/testsuite/ChangeLog:

	PR c/93640
	* gcc.dg/attr-access.c: New test.

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 7ec6fc848ac..2ea5fd5ff46 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -3999,8 +3999,8 @@ handle_access_attribute (tree *node, tree name, tree args,
 }
 
   const bool read_only = strncmp (ps, "read_only", 9) == 0;
-  const bool write_only = strncmp (ps, "write_only", 9) == 0;
-  if (!read_only && !write_only && strncmp (ps, "read_write", 9))
+  const bool write_only = strncmp (ps, "write_only", 10) == 0;
+  if (!read_only && !write_only && strncmp (ps, "read_write", 10))
 {
   error ("attribute %qE invalid mode %qs; expected one of "
 	 "%qs, %qs, or %qs", name, access_str,
diff --git a/gcc/testsuite/gcc.dg/attr-access.c b/gcc/testsuite/gcc.dg/attr-access.c
new file mode 100644
index 000..f859c461b96
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/attr-access.c
@@ -0,0 +1,21 @@
+/* PR c/93640 - The write_only and read_write attributes can be mistyped
+   due to invalid strncmp size argument
+   { dg-do compile }
+   { dg-options "-Wall" } */
+
+__attribute__ ((access (read_onl))) int f0 (char*); // { dg-error "attribute 'access' invalid mode 'read_onl'" }
+__attribute__ ((access (write_onl))) int f1 (char*);// { dg-error "attribute 'access' invalid mode 'write_onl'" }
+__attribute__ ((access (read_writ))) int f2 (char*);// { dg-error "attribute 'access' invalid mode 'read_writ'" }
+
+__attribute__ ((access (read_onlX))) int f3 (char*);// { dg-error "attribute 'access' invalid mode 'read_onlX'" }
+__attribute__ ((access (write_onlX))) int f4 (char*);   // { dg-error "attribute 'access' invalid mode 'write_onlX'" }
+__attribute__ ((access (read_writX))) int f5 (char*);   // { dg-error "attribute 'access' invalid mode 'read_writX'" }
+
+
+__attribute__ ((access (read_onl, 1))) int f7 (char*);  // { dg-error "attribute 'access' invalid mode 'read_onl'" }
+__attribute__ ((access (write_onl, 1))) int f8 (char*); // { dg-error "attribute 'access' invalid mode 'write_onl'" }
+__attribute__ ((access (read_writ, 1))) int f9 (char*); // { dg-error "attribute 'access' invalid mode 'read_writ'" }
+
+__attribute__ ((access (read_onlX, 1))) int f10 (char*);// { dg-error "attribute 'access' invalid mode 'read_onlX'" }
+__attribute__ ((access (write_onlX, 1))) int f11 (char*);   // { dg-error "attribute 'access' invalid mode 'write_onlX'" }
+__attribute__ ((access (read_writX, 1))) int f12 (char*);   // { dg-error "attribute 'access' invalid mode 'read_writX'" }

[6/6 CRIS cc0-preparations] gcc.target/cris/dbr-1.c: New test.

[Hans-Peter Nilsson]

Random spotting.  Exposes the missed benefit for delay-slot
filling of a splitter for indexed addressing mode (the [rN+M]
one).  To be considered for common instructions and perhaps only
for suitable M; at least +-63 is obious (when there's a register
available) as both the original and the add fit in delay-slots.

I forgot to mention that all previously posted patches have been
regression-tested for cris-elf and all are committed.

---
 gcc/testsuite/gcc.target/cris/dbr-1.c | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/cris/dbr-1.c

diff --git a/gcc/testsuite/gcc.target/cris/dbr-1.c 
b/gcc/testsuite/gcc.target/cris/dbr-1.c
new file mode 100644
index 0..9f79a7627
--- /dev/null
+++ b/gcc/testsuite/gcc.target/cris/dbr-1.c
@@ -0,0 +1,11 @@
+/* Check that delayed-branch-slot is able to fill a trivially fillable
+   slot.  The xfail is due to the "move.d [$r10+4],$r10" not being split
+   up into "addq 4,$r10" and "move.d [$r10],$r10"; both slottable and of
+   the same actual cost in size and cycles as the unsplit insn.  */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-not "\tnop" { xfail *-*-* } } } */
+void *f(void **p)
+{
+  return p[1];
+}
-- 
2.11.0

brgds, H-P

[5/6 CRIS cc0-preparations] gcc.target/cris/pr93372-3.c, -4.c...-35.c: New tests.

[Hans-Peter Nilsson]

PR target/93372
* gcc.target/cris/pr93372-3.c, gcc.target/cris/pr93372-4.c,
gcc.target/cris/pr93372-6.c, gcc.target/cris/pr93372-7.c,
gcc.target/cris/pr93372-9.c, gcc.target/cris/pr93372-10.c,
gcc.target/cris/pr93372-11.c, gcc.target/cris/pr93372-12.c,
gcc.target/cris/pr93372-13.c, gcc.target/cris/pr93372-14.c,
gcc.target/cris/pr93372-15.c, gcc.target/cris/pr93372-16.c,
gcc.target/cris/pr93372-17.c, gcc.target/cris/pr93372-18.c,
gcc.target/cris/pr93372-19.c, gcc.target/cris/pr93372-20.c,
gcc.target/cris/pr93372-21.c, gcc.target/cris/pr93372-22.c,
gcc.target/cris/pr93372-23.c, gcc.target/cris/pr93372-24.c,
gcc.target/cris/pr93372-25.c, gcc.target/cris/pr93372-26.c,
gcc.target/cris/pr93372-27.c, gcc.target/cris/pr93372-28.c,
gcc.target/cris/pr93372-29.c, gcc.target/cris/pr93372-30.c,
gcc.target/cris/pr93372-31.c, gcc.target/cris/pr93372-32.c,
gcc.target/cris/pr93372-33.c, gcc.target/cris/pr93372-34.c,
gcc.target/cris/pr93372-35.c: New tests.

Check that somewhat-trivially eliminable compare-instructions
are eliminated, for all instructions.  Note that pr93372-23.c
and pr93372-24.c are xfailed with cc0.
---
 gcc/testsuite/gcc.target/cris/pr93372-10.c |  9 
 gcc/testsuite/gcc.target/cris/pr93372-11.c | 46 
 gcc/testsuite/gcc.target/cris/pr93372-12.c |  7 +++
 gcc/testsuite/gcc.target/cris/pr93372-13.c | 18 +++
 gcc/testsuite/gcc.target/cris/pr93372-14.c | 13 +
 gcc/testsuite/gcc.target/cris/pr93372-15.c | 15 ++
 gcc/testsuite/gcc.target/cris/pr93372-16.c | 42 +++
 gcc/testsuite/gcc.target/cris/pr93372-17.c |  7 +++
 gcc/testsuite/gcc.target/cris/pr93372-18.c | 24 +
 gcc/testsuite/gcc.target/cris/pr93372-19.c |  8 +++
 gcc/testsuite/gcc.target/cris/pr93372-20.c |  8 +++
 gcc/testsuite/gcc.target/cris/pr93372-21.c |  8 +++
 gcc/testsuite/gcc.target/cris/pr93372-22.c |  8 +++
 gcc/testsuite/gcc.target/cris/pr93372-23.c | 21 
 gcc/testsuite/gcc.target/cris/pr93372-24.c | 19 +++
 gcc/testsuite/gcc.target/cris/pr93372-25.c |  8 +++
 gcc/testsuite/gcc.target/cris/pr93372-26.c |  7 +++
 gcc/testsuite/gcc.target/cris/pr93372-27.c |  8 +++
 gcc/testsuite/gcc.target/cris/pr93372-28.c |  8 +++
 gcc/testsuite/gcc.target/cris/pr93372-29.c | 40 ++
 gcc/testsuite/gcc.target/cris/pr93372-3.c  | 15 ++
 gcc/testsuite/gcc.target/cris/pr93372-30.c | 31 +++
 gcc/testsuite/gcc.target/cris/pr93372-31.c | 33 
 gcc/testsuite/gcc.target/cris/pr93372-32.c | 10 
 gcc/testsuite/gcc.target/cris/pr93372-33.c | 10 
 gcc/testsuite/gcc.target/cris/pr93372-34.c | 45 
 gcc/testsuite/gcc.target/cris/pr93372-35.c | 49 +
 gcc/testsuite/gcc.target/cris/pr93372-4.c  | 12 +
 gcc/testsuite/gcc.target/cris/pr93372-6.c  | 18 +++
 gcc/testsuite/gcc.target/cris/pr93372-7.c  | 85 ++
 gcc/testsuite/gcc.target/cris/pr93372-9.c  |  9 
 31 files changed, 641 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-10.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-11.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-12.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-13.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-14.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-15.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-16.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-17.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-18.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-19.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-20.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-21.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-22.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-23.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-24.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-25.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-26.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-27.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-28.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-29.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-3.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-30.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-31.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-32.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-33.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-34.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-35.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-4.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-6.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-7.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-9.c

diff --git a/gcc/testsuite/gcc.target/cris/pr93372-10.c 
b/gcc/testsuite/gcc.target/cris/pr93372-10.c

[4/6 CRIS cc0-preparations] gcc.target/cris/pr93372-2.c, -5.c, -8.c: New tests.

[Hans-Peter Nilsson]

* gcc.target/cris/pr93372-2.c, gcc.target/cris/pr93372-5.c,
gcc.target/cris/pr93372-8.c: New tests.

These tests fails miserably both at being an example of cc0
eliminating compare instructions, and post-cc0-CRIS at showing a
significant improvement.  They're here to track suboptimal
comparison code for CRIS.
---
 gcc/testsuite/gcc.target/cris/pr93372-2.c | 19 +++
 gcc/testsuite/gcc.target/cris/pr93372-5.c | 19 +++
 gcc/testsuite/gcc.target/cris/pr93372-8.c | 16 
 3 files changed, 54 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-2.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-5.c
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-8.c

diff --git a/gcc/testsuite/gcc.target/cris/pr93372-2.c 
b/gcc/testsuite/gcc.target/cris/pr93372-2.c
new file mode 100644
index 0..912069c01
--- /dev/null
+++ b/gcc/testsuite/gcc.target/cris/pr93372-2.c
@@ -0,0 +1,19 @@
+/* Check that eliminable compare-instructions are eliminated. */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-not "\tcmp|\ttest" { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-not "\tnot" { xfail cc0 } } } */
+/* { dg-final { scan-assembler-not "\tlsr" { xfail cc0 } } } */
+
+int f(int a, int b, int *d)
+{
+  int c = a - b;
+
+  /* Whoops!  We get a cmp.d with the original operands here. */
+  *d = (c == 0);
+
+  /* Whoops!  While we don't get a test.d for the result here for cc0,
+ we get a sequence of insns: a move, a "not" and a shift of the
+ subtraction-result, where a simple "spl" would have done. */
+  return c >= 0;
+}
diff --git a/gcc/testsuite/gcc.target/cris/pr93372-5.c 
b/gcc/testsuite/gcc.target/cris/pr93372-5.c
new file mode 100644
index 0..351764c6c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/cris/pr93372-5.c
@@ -0,0 +1,19 @@
+/* Check that eliminable compare-instructions are eliminated. */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-not "\tcmp|\ttest|\tor" { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-not "\tnot" { xfail cc0 } } } */
+/* { dg-final { scan-assembler-not "\tlsr" { xfail cc0 } } } */
+
+int f(long long int a, long long int b, int *d)
+{
+  long long int c = a - b;
+
+  *d = (c == 0LL);
+
+  /* See pr93372-2.c; we have the same problem for DImode, but it's
+ worsened by the generic double-word "optimizations"; or:ing
+ together the DI parts and then testing the result for the equality
+ test.  */
+  return c >= 0LL;
+}
diff --git a/gcc/testsuite/gcc.target/cris/pr93372-8.c 
b/gcc/testsuite/gcc.target/cris/pr93372-8.c
new file mode 100644
index 0..95abc4b6b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/cris/pr93372-8.c
@@ -0,0 +1,16 @@
+/* Check that eliminable compare-instructions are eliminated. */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* See pr93372-5.c regarding the xfails.  */
+/* { dg-final { scan-assembler-not "\tcmp|\ttest|\tor" { xfail *-*-* } } } */
+/* { dg-final { scan-assembler-not "\tnot" { xfail cc0 } } } */
+/* { dg-final { scan-assembler-not "\tlsr" { xfail cc0 } } } */
+
+int f(long long int a, long long int b, int *d)
+{
+  long long int c = a + b;
+
+  *d = (c == 0);
+
+  return c >= 0;
+}
-- 
2.11.0

brgds, H-P

[3/6 CRIS cc0-preparations] gcc.target/cris/pr93372-1.c: New test.

[Hans-Peter Nilsson]

This test was separated from the posted and approved patch named
"dbr: Filter-out TARGET_FLAGS_REGNUM from end_of_function_needs"
and applied: it doesn't fail yet.  It differs from the posted
version in that function "g" is commented-out; see the added
comment.
---
 gcc/testsuite/gcc.target/cris/pr93372-1.c | 72 +++
 1 file changed, 72 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/cris/pr93372-1.c

diff --git a/gcc/testsuite/gcc.target/cris/pr93372-1.c 
b/gcc/testsuite/gcc.target/cris/pr93372-1.c
new file mode 100644
index 0..20aa65e8d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/cris/pr93372-1.c
@@ -0,0 +1,72 @@
+/* Check that all more-or-less trivially fillable delayed-branch-slots
+   are filled. */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-not "\tnop" } } */
+
+void *f(void **p)
+{
+  /* Supposedly the memory read finds its way into the "ret"
+ delay-slot. */
+  return *p;
+}
+
+#if 0
+/* Until the negative effects of g:897a73086b2 a.k.a. r10-6395
+   a.k.a. "One more fix for PR 91333 - suboptimal register allocation
+   for inline asm", which appears to have caused a "nop" (unfilled
+   delay-slot) to appear for this function for CRIS-decc0rated (but not
+   CRIS-cc0) and increasing one execution-path by one instruction (and
+   the size of the whole function), it's left out.  It was but a mere
+   attempt to expose the flaw better noticed with xlshrdi3.  It exposes
+   a real issue, just less important.  FIXME: extract to separate test.  */
+int g(int *x, int *y, char *v, int n)
+{
+  int z = *x;
+  int w = *v + 31;
+
+  /* Two branch and two return slots, all filled. */
+  if (z != 23 && z != n+1)
+return *x+*y+24+w;
+  return *y+24+w;
+}
+#endif
+
+/* No problem with the two examples above, but with a more involved
+   example, the epilogue contents matter (the condition-code register
+   clobber was mistaken for a register that needed to be alive). */
+
+struct DWstruct {int low, high;};
+typedef unsigned long long DItype;
+typedef unsigned int USItype;
+
+typedef union
+{
+  struct DWstruct s;
+  DItype ll;
+} DWunion;
+
+unsigned long long
+xlshrdi3 (DItype u, unsigned int b)
+{
+  if (b == 0)
+return u;
+
+  const DWunion uu = {.ll = u};
+  const int bm = (4 * 8) - b;
+  DWunion w;
+
+  if (bm <= 0)
+{
+  w.s.high = 0;
+  w.s.low = (USItype) uu.s.high >> -bm;
+}
+  else
+{
+  const USItype carries = (USItype) uu.s.high << bm;
+  w.s.high = (USItype) uu.s.high >> b;
+  w.s.low = ((USItype) uu.s.low >> b) | carries;
+}
+
+  return w.ll;
+}
-- 
2.11.0

brgds, H-P

[2/6 CRIS cc0-preparations] gcc.target/cris/cris.exp (check_effective_target_cc0): New.

[Hans-Peter Nilsson]

To simplify separating the cc0-specific xfails, let's have an
effective-target.

This likely fits all targets.
---
 gcc/testsuite/gcc.target/cris/cris.exp | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/gcc/testsuite/gcc.target/cris/cris.exp 
b/gcc/testsuite/gcc.target/cris/cris.exp
index c85c849e8..52164514d 100644
--- a/gcc/testsuite/gcc.target/cris/cris.exp
+++ b/gcc/testsuite/gcc.target/cris/cris.exp
@@ -25,6 +25,17 @@ if { ![istarget cris-*-*] && ![istarget crisv32-*-*] } then {
 # Load support procs.
 load_lib gcc-dg.exp
 
+# For the time being, provide a means to tell whether the target is "cc0".
+# Some targets may split cbranch and cstore late, but for a cc0-target,
+# all the fun happens at "final" time, so this should be a safe time for
+# a scan.
+proc check_effective_target_cc0 { } {
+return [check_no_messages_and_pattern cc0 "\\(cc0\\)" rtl-final {
+   extern void g (void);
+   void f (int *p, int *q) { *q = *p == 42; if (*p == 7) g (); }
+}]
+}
+
 # If a testcase doesn't have special options, use these.
 global DEFAULT_CFLAGS
 if ![info exists DEFAULT_CFLAGS] then {
-- 
2.11.0

brgds, H-P

[1/6 CRIS cc0-preparations] try to generate zero-based comparisons

[Hans-Peter Nilsson]

* config/cris/cris.c (cris_reduce_compare): New function.
* config/cris/cris-protos.h  (cris_reduce_compare): Add prototype.
* config/cris/cris.md ("cbranch4", "cbranchdi4", "cstoredi4")
(cstore4"): Apply cris_reduce_compare in expanders.

The decc0ration work of the CRIS port made me look closer at the
code for trivial comparisons, as in the condition for branches
and conditional-stores, like in:

void g(short int a, short int b)
{
  short int c = a + b;

  if (c >= 0)
foo ();
}

At -O2, the cc0 version of the CRIS port has an explicit
*uneliminated* compare instruction ("cmp.w -1,$r10") instead of
an (eliminated) compare against 0 (which below I'll call a
zero-compare).  This for the CRIS-cc0 version, but I see this
also for a much older gcc, at 4.7.  For the decc0rated port, the
compare *is* a test against 0, eventually eliminated.  To wit,
for cc0 (mind the delay-slot):

_g:
subq 4,$sp
add.w $r11,$r10
cmp.w -1,$r10
ble .L9
move $srp,[$sp]

jsr _foo
.L9:
jump [$sp+]

The compare instruction is expected to be eliminated, i.e.  the
following diff to the above is desired, modulo the missing
sibling call, which corresponds to what I get from 4.7 and for
the decc0rated port:

!--- a  Wed Feb  5 15:22:27 2020
!+++ b  Wed Feb  5 15:22:51 2020
!@@ -1,8 +1,7 @@
! _g:
!subq 4,$sp
!add.w $r11,$r10
!-  cmp.w -1,$r10
!-  ble .L9
!+  bmi .L9
!move $srp,[$sp]
!
!jsr _foo

Tracking this difference, I see that for both cc0-CRIS and the
decc0rated CRIS, the comparison actually starts out as a compare
against -1 at "expand" time, but is transformed for decc0rated
CRIS to a zero-compare in "cse1".

For CRIS-cc0 "cse1" does try to replace the compare with a
zero-compare, but fails because at the same time it tries to
replace the c operand with (a + b).  Or some such; it fails and
no other pass succeeds.  I was not into fixing cc0-handling in
core gcc, so I didn't look closer.

BTW, at first, I was a bit surprised to see that for compares
against a constant, a zero-compare is not canonical RTX for
*all* conditions, and that instead only a subset of all RTX
conditions against a constant are canonical, transforming one
condition to the canonical one by adding 1 or -1 to the
constant.  It does makes sense at a closer look, but still not
so much when emitting RTL.

There are several places that mention in comments that emitting
RTX as zero-compare is preferable, but nothing is done about it.
Some generic code instead seems confused that the *target* is
helped by seeing canonical RTX, or perhaps it (its authors) like
me, confused about what a canonical comparison is.  For example,
prepare_cmp_insn calls canonicalize_comparison last before
emitting the actual instructions.  I see most ports for various
port-specific reasons does their own massaging in their cbranch
and cstore expanders.  Still, the suboptimal compares *should*
be fixed at expand time; better start out right than just
relying on later optimizations.

This kind of change is not acceptable in the current gcc
development stage, at least as a change in generic code.
However, it's problematic enough that I chose to fix this right
now in the CRIS port.  For that, I claim a possibly
long-standing regression.  After this, code before and after
decc0ration is similar enough that I can spot
compare-elimination-efforts and apply regression test-cases
without them drowning in cc0-specific xfailing.

I hope to eventually lift out cris_reduce_compare (renamed) into
say expmed.c, called in e.g. emit_store_flag_1 (replacing the
in-line code) and prepare_cmp_insn.  Later.
---
 gcc/config/cris/cris-protos.h |  1 +
 gcc/config/cris/cris.c| 57 +++
 gcc/config/cris/cris.md   |  6 +++--
 3 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/gcc/config/cris/cris-protos.h b/gcc/config/cris/cris-protos.h
index 2105256cc..6f6d81567 100644
--- a/gcc/config/cris/cris-protos.h
+++ b/gcc/config/cris/cris-protos.h
@@ -38,6 +38,7 @@ extern bool cris_constant_index_p (const_rtx);
 extern bool cris_base_p (const_rtx, bool);
 extern bool cris_base_or_autoincr_p (const_rtx, bool);
 extern bool cris_bdap_index_p (const_rtx, bool);
+extern void cris_reduce_compare (rtx *, rtx *, rtx *);
 extern bool cris_biap_index_p (const_rtx, bool);
 extern bool cris_legitimate_address_p (machine_mode, rtx, bool);
 extern bool cris_store_multiple_op_p (rtx);
diff --git a/gcc/config/cris/cris.c b/gcc/config/cris/cris.c
index 01388b3d0..91cb63c01 100644
--- a/gcc/config/cris/cris.c
+++ b/gcc/config/cris/cris.c
@@ -3053,6 +3053,63 @@ cris_split_movdx (rtx *operands)
   return val;
 }
 
+/* Try to change a comparison against a constant to be against zero, and
+   an unsigned compare against zero to be an equality test.  Beware:
+   only valid for compares of integer-type operands.  Also, note that we
+   don't use operand 0 at the moment.  */
+
+void

[0/6 CRIS cc0-preparations]

[Hans-Peter Nilsson]

Stuff I broke out from the CRIS decc0ration work;
compare-decanonicalization and tests that would be regressions
in a future timeline, but fixed later on.

Besides the first patch, nothing you'd normally care about, and
perhaps for people doing CC0 work: the test-cases and the cc0
effective-target may be of use to you.

brgds, H-P

Re: [ARM] Fix -mpure-code for v6m

[Richard Earnshaw (lists)]

On 10/02/2020 09:27, Christophe Lyon wrote:

On Fri, 7 Feb 2020 at 17:55, Richard Earnshaw (lists)
 wrote:


On 07/02/2020 16:43, Christophe Lyon wrote:

On Fri, 7 Feb 2020 at 14:49, Richard Earnshaw (lists)
 wrote:


On 07/02/2020 13:19, Christophe Lyon wrote:

When running the testsuite with -fdisable-rtl-fwprop2 and -mpure-code
for cortex-m0, I noticed that some testcases were failing because we
still generate "ldr rX, .LCY", which is what we want to avoid with
-mpure-code. This is latent since a recent improvement in fwprop
(PR88833).

In this patch I change the thumb1_movsi_insn pattern so that it emits
the desired instruction sequence when arm_disable_literal_pool is set.

I tried to add a define_split instead, but couldn't make it work: the
compiler then complains it cannot split the instruction, while my new
define_split accepts the same operand types as thumb1_movsi_insn:

c-c++-common/torture/complex-sign-mixed-add.c:41:1: error: could not split insn
(insn 2989 425 4844 (set (reg/f:SI 3 r3 [1342])
   (symbol_ref/u:SI ("*.LC6") [flags 0x2])) 836 {*thumb1_movsi_insn}
(expr_list:REG_EQUIV (symbol_ref/u:SI ("*.LC6") [flags 0x2])
   (nil)))
during RTL pass: final

(define_split
 [(set (match_operand:SI 0 "register_operand" "")
   (match_operand:SI 1 "general_operand" ""))]
 "TARGET_THUMB1
  && arm_disable_literal_pool
  && GET_CODE (operands[1]) == SYMBOL_REF"
 [(clobber (const_int 0))]
 "
   gen_thumb1_movsi_symbol_ref(operands[0], operands[1]);
   DONE;
 "
)
and I put this in thumb1_movsi_insn:
if (GET_CODE (operands[1]) == SYMBOL_REF && arm_disable_literal_pool)
 {
   return \"#\";
 }
 return \"ldr\\t%0, %1\";

2020-02-07  Christophe Lyon  

   * config/arm/thumb1.md (thumb1_movsi_insn): Fix ldr alternative to
   work with -mpure-code.



+case 0:
+case 1:
+  return \"movs%0, %1\";
+case 2:
+  return \"movw%0, %1\";

This is OK, but please replace the hard tab in the strings for MOVS/MOVW
with \\t.



OK that was merely a cut & paste from the existing code.

I'm concerned that the length attribute is becoming wrong with my
patch, isn't this a problem?



Potentially yes.  The branch range code needs this to handle overly long
jumps correctly.



Do you mean that the probability of problems due to that shortcoming
is low enough that I can commit my patch?


It's hard to say that.  The number of instructions you generate for this 
is significant, so it likely will throw off the calculations and 
somebody will get unlucky.  On the other hand, I don't think we should 
pessimize code for the non-pure-code variants by inflating the size for 
this unconditionally.


It seems there are two ways to fix this.

1) create a new alternative for the pure-code variant with its own 
length attribute, then only enable that for the case you need.  That 
would also allow you to go back to the templated asm format.
2) use a level of indirection to calculate the length - I haven't tried 
this, but it would be something like:


 - create a new attribute - lets say default_length
 - rename length for this pattern to default_length
 - create another new attribute - lets say purecode_length, add lengths 
for each alternative but adjusted for the purecode variant.
 - make the length attribute for this pattern select based on the 
disable_literal_pool variable between the default_length and 
purecode_length attributes.


R.



Thanks,

Christophe


R.


Thanks,

Christophe


R.

[PATCH] c++: Improve dump_decl for standard concepts

[Patrick Palka]

This patch improves the pretty printing of standard concept definitions in error
messages.  In particular, standard concepts are now printed qualified whenever
appropriate, and the "concept" specifier is printed only when the
TFF_DECL_SPECIFIERS flag is specified.

In the below test, the first error message changes from
  9:15: error: ‘b’ was not declared in this scope; did you mean ‘concept b’?
to
  9:15: error: ‘b’ was not declared in this scope; did you mean ‘a::b’?

Tested on x86_64-pc-linux-gnu, is this OK to commit?

gcc/cp/ChangeLog:

* error.c (dump_decl) [CONCEPT_DECL]: Use dump_simple_decl.
(dump_simple_decl): Handle standard concept definitions as well as
variable concept definitions.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts6.C: New test.
---
 gcc/cp/error.c | 18 --
 gcc/testsuite/g++.dg/cpp2a/concepts6.C | 18 ++
 2 files changed, 26 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts6.C

diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 973b3034e12..a56d83e1f45 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -1037,14 +1037,13 @@ dump_simple_decl (cxx_pretty_printer *pp, tree t, tree 
type, int flags)
 
   if (flags & TFF_DECL_SPECIFIERS)
 {
-  if (VAR_P (t) && DECL_DECLARED_CONSTEXPR_P (t))
-{
- if (DECL_LANG_SPECIFIC (t) && DECL_DECLARED_CONCEPT_P (t))
-   pp_cxx_ws_string (pp, "concept");
- else
-   pp_cxx_ws_string (pp, "constexpr");
-   }
-  dump_type_prefix (pp, type, flags & ~TFF_UNQUALIFIED_NAME);
+  if (concept_definition_p (t))
+   pp_cxx_ws_string (pp, "concept");
+  else if (VAR_P (t) && DECL_DECLARED_CONSTEXPR_P (t))
+   pp_cxx_ws_string (pp, "constexpr");
+
+  if (!standard_concept_p (t))
+   dump_type_prefix (pp, type, flags & ~TFF_UNQUALIFIED_NAME);
   pp_maybe_space (pp);
 }
   if (! (flags & TFF_UNQUALIFIED_NAME)
@@ -1296,8 +1295,7 @@ dump_decl (cxx_pretty_printer *pp, tree t, int flags)
   break;
 
 case CONCEPT_DECL:
-  pp_cxx_ws_string (pp, "concept");
-  dump_decl_name (pp, DECL_NAME (t), flags);
+  dump_simple_decl (pp, t, TREE_TYPE (t), flags);
   break;
 
 case WILDCARD_DECL:
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts6.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts6.C
new file mode 100644
index 000..d69628b0318
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts6.C
@@ -0,0 +1,18 @@
+// { dg-do compile { target c++2a } }
+
+namespace a
+{
+  template
+concept b = true; // { dg-message ".a::b. declared here" }
+}
+
+static_assert(b); // { dg-error "did you mean .a::b." }
+
+namespace c
+{
+  template
+concept b = true; // { dg-message "concept c::b." }
+
+  template
+concept b = true; // { dg-error "concept c::b." }
+}
-- 
2.25.0.191.gde93cc14ab

Re: [PATCH] Fix -ffast-math flags handling inconsistencies

[Ulrich Weigand]

Segher Boessenkool wrote:
> On Fri, Feb 07, 2020 at 05:47:32PM +0100, Ulrich Weigand wrote:
> > > but what happens to -fsignalling-nans -ffast-math then?  Better leave 
> > > those
> > > in I'd say.
> > 
> > Ah, it seems I was confused about the intended semantics here.
> > 
> > I thought that a *more specific* option like -fsignalling-nans was always
> > intended to override a more generic option like -ffast-math, no matter
> > whether it comes before or after it on the command line.
> 
> -fsignaling-nans is an independent option.  Signaling NaNs don't do much
> at all when you also have -ffinite-math-only, of course, which says you
> don't have *any* NaNs.

That's a good point, thanks for pointing this out!  I agree that
-fsignaling-nans is not a good example then; it really should be
independent of -ffast-math.

However, there's still one other option that has a similar issue:
-frounding-math.  This *is* properly related to -ffast-math, in
that -ffast-math really ought to imply -fno-rounding-math, but the
latter is (currently) also the default in GCC.

Bye,
Ulrich


-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

Re: [PATCH] Fix -ffast-math flags handling inconsistencies

[Ulrich Weigand]

Joseph Myers wrote:
> On Fri, 7 Feb 2020, Ulrich Weigand wrote:
> 
> > I thought that a *more specific* option like -fsignalling-nans was always
> > intended to override a more generic option like -ffast-math, no matter
> > whether it comes before or after it on the command line.
> 
> Yes, that's correct.  (There are cases where it's ambiguous which option 
> is more specific - see what I said in 
>  about -Werror= - but I 
> don't think -ffast-math involves such cases.)

I see.  However, this does not appear to be implemented in current code.
GCC (without my patch) behaves like this (using -fno-finite-math-only
as an example instead of -fsignaling-nans, given the separate point
about the latter option raised by Segher):

gcc -dD -E -x c /dev/null | grep FINITE
#define __FINITE_MATH_ONLY__ 0
gcc -dD -E -x c /dev/null -ffast-math | grep FINITE
#define __FINITE_MATH_ONLY__ 1
gcc -dD -E -x c /dev/null -ffast-math -fno-finite-math-only | grep FINITE
#define __FINITE_MATH_ONLY__ 0
gcc -dD -E -x c /dev/null -fno-finite-math-only -ffast-math | grep FINITE
#define __FINITE_MATH_ONLY__ 1

Given the above rule, in the last case __FINITE_MATH_ONLY__ should
also be 0, right?

I'm not sure how this can be implemented in the current option handling
framework.  The -ffast-math handling case would have to check whether
or not there is any explicit use of -f(no-)finite-math-only; is there
any infrastructure to readily perform such a test?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  ulrich.weig...@de.ibm.com

[PATCH] Fix stack pointer handling in ms_hook_prologue functions for i386 target.

[Paul Gofman]

ChangeLog:
PR target/91489
* config/i386/i386.md (simple_return): Also check
for ms_hook_prologue function attribute.
* config/i386/i386.c (ix86_can_use_return_insn_p):
Also check for ms_hook_prologue function attribute.

testsuite/ChangeLog:
PR target/91489
* gcc.target/i386/ms_hook_prologue.c: Expand testcase
to reproduce PR target/91489 issue.

Signed-off-by: Paul Gofman 
---
 gcc/config/i386/i386-protos.h|  1 +
 gcc/config/i386/i386.c   |  3 +++
 gcc/config/i386/i386.md  |  5 -
 gcc/testsuite/gcc.target/i386/ms_hook_prologue.c | 13 -
 4 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index 266381ca5a6..966ce426a18 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -26,6 +26,7 @@ extern bool ix86_handle_option (struct gcc_options *opts,
 /* Functions in i386.c */
 extern bool ix86_target_stack_probe (void);
 extern bool ix86_can_use_return_insn_p (void);
+extern bool ix86_function_ms_hook_prologue (const_tree fn);
 extern void ix86_setup_frame_addresses (void);
 extern bool ix86_rip_relative_addr_p (struct ix86_address *parts);
 
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 44bc0e0176a..68e2a7519f4 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -4954,6 +4954,9 @@ symbolic_reference_mentioned_p (rtx op)
 bool
 ix86_can_use_return_insn_p (void)
 {
+  if (ix86_function_ms_hook_prologue (current_function_decl))
+return false;
+
   if (ix86_function_naked (current_function_decl))
 return false;
 
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index f14683cd14f..a7302b886c6 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -13445,10 +13445,13 @@
 ;; static chain pointer - the first instruction has to be pushl %esi
 ;; and it can't be moved around, as we use alternate entry points
 ;; in that case.
+;; Also disallow for ms_hook_prologue functions which have frame
+;; pointer set up in function label which is correctly handled in
+;; ix86_expand_{prologue|epligoue}() only.
 
 (define_expand "simple_return"
   [(simple_return)]
-  "!TARGET_SEH && !ix86_static_chain_on_stack"
+  "!TARGET_SEH && !ix86_static_chain_on_stack && 
!ix86_function_ms_hook_prologue (cfun->decl)"
 {
   if (crtl->args.pops_args)
 {
diff --git a/gcc/testsuite/gcc.target/i386/ms_hook_prologue.c 
b/gcc/testsuite/gcc.target/i386/ms_hook_prologue.c
index e11bcc049cb..12e54c0e4ad 100644
--- a/gcc/testsuite/gcc.target/i386/ms_hook_prologue.c
+++ b/gcc/testsuite/gcc.target/i386/ms_hook_prologue.c
@@ -4,6 +4,8 @@
 /* { dg-require-effective-target ms_hook_prologue } */
 /* { dg-options "-O2 -fomit-frame-pointer" } */
 
+#include 
+
 int __attribute__ ((__ms_hook_prologue__)) foo ()
 {
   unsigned char *ptr = (unsigned char *) foo;
@@ -32,7 +34,16 @@ int __attribute__ ((__ms_hook_prologue__)) foo ()
   return 0;
 }
 
+unsigned int __attribute__ ((noinline, __ms_hook_prologue__)) test_func()
+{
+  static int value;
+
+  if (value++) puts("");
+
+  return 0;
+}
+
 int main ()
 {
-  return foo();
+  return foo() || test_func();
 }
-- 
2.24.1

[PATCH] arm: correct constraints on movsi_compare0 [PR91913]

[Richard Earnshaw]

The peephole that detects a mov of one register to another followed by
a comparison of the original register against zero is only used in Arm
state; but the instruction that matches this is generic to all 32-bit
compilation states.  That instruction lacks support for SP which is
permitted in Arm state, but has restrictions in Thumb2 code.

This patch fixes the problem by allowing SP when in ARM state for all
registers; in Thumb state it allows SP only as a source when the
register really is copied to another target.

* config/arm/arm.md (movsi_compare0): Allow SP as a source register
in Thumb state and also as a destination in Arm state.  Add T16
variants.
---
 gcc/config/arm/arm.md | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 5baf82d2ad6..ab277996462 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -6627,16 +6627,21 @@ (define_expand "builtin_setjmp_receiver"
 
 (define_insn "*movsi_compare0"
   [(set (reg:CC CC_REGNUM)
-	(compare:CC (match_operand:SI 1 "s_register_operand" "0,r")
+	(compare:CC (match_operand:SI 1 "s_register_operand" "0,0,l,rk,rk")
 		(const_int 0)))
-   (set (match_operand:SI 0 "s_register_operand" "=r,r")
+   (set (match_operand:SI 0 "s_register_operand" "=l,rk,l,r,rk")
 	(match_dup 1))]
   "TARGET_32BIT"
   "@
cmp%?\\t%0, #0
+   cmp%?\\t%0, #0
+   subs%?\\t%0, %1, #0
+   subs%?\\t%0, %1, #0
subs%?\\t%0, %1, #0"
   [(set_attr "conds" "set")
-   (set_attr "type" "alus_imm,alus_imm")]
+   (set_attr "arch" "t2,*,t2,t2,a")
+   (set_attr "type" "alus_imm")
+   (set_attr "length" "2,4,2,4,4")]
 )
 
 ;; Subroutine to store a half word from a register into memory.

Re: [PATCH] arm: Fix ICE with movsi + cmpsi -> movsi_compare0 peephole2 [PR91913]

[Richard Earnshaw (lists)]

On 01/02/2020 08:30, Jakub Jelinek wrote:

Hi!

The following testcase ICEs on arm.  The problem is that the following
peephole tries to match adjacent *arm_movsi_insn + *arm_cmpsi_insn;
the *arm_movsi_insn uses =rk, rk constraints and *arm_cmpsi_insn
uses r, IL constraints for what is matched by the peephole2.  Peephole2s
work only with predicates and not constraints, and the instruction that
the peephole2 turns those two into is *movsi_compare0, which uses
=r, r constraints.  As operands[1] is the same between the two insns,
sp (k constraint) is not possible for it, but as appears in the testcase,
we try to match sp = non-sp; cc = cmp (non-sp, 0) into
[ cc = cmp (non-sp, 0); sp = non-sp ] insn which isn't then recognized,
because it doesn't match the =r constraint.
I couldn't find a predicate that would do what we need here, the peephole2
uses arm_general_register_operand which matches SUBREGs as well as REGs
and requires <= 15 REGNO or pseudo register.  There is also
arm_hard_general_register_operand predicate that matches only REGs and
requires <= 15 REGNO, so slightly closer to what we need, but nothing
that would require <= LAST_ARM_REGNUM && != SP_REGNUM.

The following patch fixes it just by excluding SP destination in the
peephole2 condition, bootstrapped/regtested on armv7hl-linux-gnueabi,
ok for trunk?

Yet another option would be
s/arm_general_register_operand/arm_hard_general_register_operand/g
in the peephole2 and use
"TARGET_ARM && REGNO (operands[0]) != SP_REGNUM"
as condition.
And yet another option would be to add some predicate that would be
arm_hard_general_register_operand and would require that REGNO != SP_REGNUM
and use it in this peephole2.  But I'd need a suggestion how to call
that predicate, because I have no idea how arm calls core? registers
except sp.


And yet another option would be specify the constraints to 
movsi_compare0 correctly...


The restriction on using SP applies only to Thumb code.  In Arm state SP 
can be used just fine (as was the case when this pattern was originally
written and SP was permitted in constraint 'r'.  When thumb2 support was 
added we split SP into a separate class, but not all patterns were fully 
updated for this.


Since the peephole applies only to Arm state (TARGET_ARM), there's no 
need to change that, but the pattern it hits needs some additional 
variants so that it will match.


I'll commit a patch to do that shortly, but feel free to commit your 
testcase.


Thanks for looking into this though.


R.

(sorry for the delay replying, was in meetings nearly all last week).



2020-02-01  Jakub Jelinek  

PR target/91913
* config/arm/arm.md (movsi + cmpsi -> movsi_compare0 peephole2):
Punt if destination is sp register.

* gfortran.dg/pr91913.f90: New test.

--- gcc/config/arm/arm.md.jj2020-01-30 12:57:52.062102735 +0100
+++ gcc/config/arm/arm.md   2020-01-31 15:55:47.199979148 +0100
@@ -11227,7 +11227,7 @@ (define_peephole2
(match_operand:SI 1 "arm_general_register_operand" ""))
 (set (reg:CC CC_REGNUM)
(compare:CC (match_dup 1) (const_int 0)))]
-  "TARGET_ARM"
+  "TARGET_ARM && REG_P (operands[0]) && REGNO (operands[0]) != SP_REGNUM"
[(parallel [(set (reg:CC CC_REGNUM) (compare:CC (match_dup 1) (const_int 
0)))
  (set (match_dup 0) (match_dup 1))])]
""
--- gcc/testsuite/gfortran.dg/pr91913.f90.jj2020-01-31 15:54:06.839475636 
+0100
+++ gcc/testsuite/gfortran.dg/pr91913.f90   2020-01-31 15:53:52.265692947 
+0100
@@ -0,0 +1,5 @@
+! PR target/91913
+! { dg-do compile }
+! { dg-options "-std=legacy -Ofast --param max-cse-insns=0 -fno-schedule-insns 
-fsanitize=null" }
+
+include 'string_ctor_1.f90'

Jakub

committed: fix typo in define_subst example, md.texi

[Hans-Peter Nilsson]

Committed as obvious.

gcc:
* md.texi (Define Subst): Match closing paren in example.

diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index cec74ea78..66c5eea3b 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -10545,7 +10545,7 @@ generated with the following @code{define_subst}:
   ""
   [(set (match_dup 0)
 (match_dup 1))
-   (clobber (reg:CC FLAGS_REG))]
+   (clobber (reg:CC FLAGS_REG))])
 @end smallexample
 
 This @code{define_subst} can be applied to any RTL pattern containing
-- 
2.11.0

brgds, H-P

Re: [PATCH] libstdc++: Make sure iterator_traits is populated

[Patrick Palka]

On Mon, 10 Feb 2020, Jonathan Wakely wrote:

> On 07/02/20 13:59 -0500, Patrick Palka wrote:
> > Since basic_istream_view::iterator is neither a cpp17 iterator (because it's
> > move-only) nor does it define all four of the types {difference_type,
> > value_type, reference, iterator_category}, then by the rule in
> > [iterator.traits], its iterator_traits has no members.
> > 
> > More concretely this means that it can't e.g. be composed with a
> > views::transform or a views::filter because they look at the iterator_traits
> > of
> > the underlying view.
> > 
> > This seems to be a defect in the current spec.
> 
> Agreed, but Casey Carter doesn't think this fix is correct, as it
> would make this iterator appear to be a Cpp17InputIterator, which is
> unwanted.
> 
> Please don't make this change, we should wait for guidance from LWG.

Sounds good.

Re: [PATCH] i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637]

[Jakub Jelinek]

On Mon, Feb 10, 2020 at 03:40:18PM +0100, Richard Biener wrote:
> Hmm.  Maybe with FP operands we can also try to implement the mask
> as != 0.0 FP condition?  Not sure if -1 (or 1) is enough non-NaNish to
> not cause problems of course.

Well, by the time we reach expansion, we have just the VECTOR_CST integral
operand, and we use right now:
  gcc_assert (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (op0)));
  if (get_vcond_mask_icode (mode, TYPE_MODE (TREE_TYPE (op0)))
  != CODE_FOR_nothing)
return expand_vec_cond_mask_expr (vec_cond_type, op0, op1,
  op2, target);
  /* Fake op0 < 0.  */
  else
{
  gcc_assert (GET_MODE_CLASS (TYPE_MODE (TREE_TYPE (op0)))
  == MODE_VECTOR_INT);
  op0a = op0;
  op0b = build_zero_cst (TREE_TYPE (op0));
  tcode = LT_EXPR;
}
so we'd need to try that op0 < 0 case and if that fails, try to find some
floating point (or other?) mode that has the same element size and precision
and change the condition back to comparison of two floating point constants
and then hope combine will fold it back to vcond_mask* again.

Jakub

Re: [PATCH] i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637]

[Richard Biener]

On Mon, Feb 10, 2020 at 3:33 PM Jakub Jelinek  wrote:
>
> Hi!
>
> As mentioned in the PR, for -mavx -mno-avx2 the backend does support
> vcondv4div4df and vcondv8siv8sf optabs (while generally 32-byte vectors
> aren't much supported in that case, it is performed using
> vandps/vandnps/vorps).  The problem is that after the last generic vector
> lowering (where the VEC_COND_EXPR still compares two V4DF vectors and
> has two V4DI last operands and V4DI result and so is considered ok) fre4
> folds the condition into constant, at which point the middle-end during
> expansion will try vcond_mask_optab and fall back to trying to expand it
> as the constant vector < 0 vcondv4div4di, but neither of them is supported
> for -mavx -mno-avx2 and thus we ICE.

Hmm.  Maybe with FP operands we can also try to implement the mask
as != 0.0 FP condition?  Not sure if -1 (or 1) is enough non-NaNish to
not cause problems of course.

> So, the options I see is either what the following patch does, also support
> vcond_mask_v4div4di and vcond_mask_v4siv4si already for TARGET_AVX, or
> require for vcondv4div4df and vcondv8siv8sf TARGET_AVX2 rather than current
> TARGET_AVX.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> Or do you prefer the disabling of the vcond patterns instead?
>
> 2020-02-10  Jakub Jelinek  
>
> PR target/93637
> * config/i386/sse.md (VI_256_AVX2): New mode iterator.
> (vcond_mask_): Use it instead of VI_256.
> Change condition from TARGET_AVX2 to TARGET_AVX.
>
> * gcc.target/i386/avx-pr93637.c: New test.
>
> --- gcc/config/i386/sse.md.jj   2020-02-10 13:14:02.970131692 +0100
> +++ gcc/config/i386/sse.md  2020-02-10 13:15:54.343473253 +0100
> @@ -3430,13 +3430,19 @@ (define_expand "vcond_mask_   (match_operand: 3 "register_operand")))]
>"TARGET_AVX512BW")
>
> +;; As vcondv4div4df and vcondv8siv8sf are enabled already with TARGET_AVX,
> +;; and their condition can be folded late into a constant, we need to
> +;; support vcond_mask_v4div4di and vcond_mask_v8siv8si for TARGET_AVX.
> +(define_mode_iterator VI_256_AVX2 [(V32QI "TARGET_AVX2") (V16HI 
> "TARGET_AVX2")
> +  V8SI V4DI])
> +
>  (define_expand "vcond_mask_"
> -  [(set (match_operand:VI_256 0 "register_operand")
> -   (vec_merge:VI_256
> - (match_operand:VI_256 1 "nonimmediate_operand")
> - (match_operand:VI_256 2 "nonimm_or_0_operand")
> +  [(set (match_operand:VI_256_AVX2 0 "register_operand")
> +   (vec_merge:VI_256_AVX2
> + (match_operand:VI_256_AVX2 1 "nonimmediate_operand")
> + (match_operand:VI_256_AVX2 2 "nonimm_or_0_operand")
>   (match_operand: 3 "register_operand")))]
> -  "TARGET_AVX2"
> +  "TARGET_AVX"
>  {
>ix86_expand_sse_movcc (operands[0], operands[3],
>  operands[1], operands[2]);
> --- gcc/testsuite/gcc.target/i386/avx-pr93637.c.jj  2020-02-10 
> 13:19:18.212437488 +0100
> +++ gcc/testsuite/gcc.target/i386/avx-pr93637.c 2020-02-10 13:18:25.651220171 
> +0100
> @@ -0,0 +1,17 @@
> +/* PR target/93637 */
> +/* { dg-do compile } */
> +/* { dg-options "-mavx -mno-avx2 -O3 --param 
> sccvn-max-alias-queries-per-access=3" } */
> +
> +double
> +foo (void)
> +{
> +  int i;
> +  double r = 7.0;
> +  double a[] = { 0.0, 0.0, -0.0, 0.0, 0.0, -0.0, 1.0, 0.0, 0.0, -0.0, 1.0, 
> 0.0, 1.0, 1.0 };
> +
> +  for (i = 0; i < sizeof (a) / sizeof (a[0]); ++i)
> +if (a[i] == 0.0)
> +  r = a[i];
> +
> +  return r;
> +}
>
> Jakub
>

Re: [COMMITTED] c++: Fix ICE on nonsense requires-clause.

[Christophe Lyon]

On Mon, 10 Feb 2020 at 14:53, Jason Merrill  wrote:
>
> On Mon, Feb 10, 2020 at 2:13 PM Christophe Lyon  
> wrote:
>>
>> On Fri, 7 Feb 2020 at 14:54, Jason Merrill  wrote:
>> >
>> > Here we were swallowing all the syntax errors by parsing tentatively, and
>> > returning error_mark_node without ever actually giving an error.  Fixed by
>> > using save_tokens/rollback_tokens instead.
>> >
>> > Tested x86_64-pc-linux-gnu, applying to trunk.
>> >
>> > PR c++/92517
>> > * parser.c (cp_parser_constraint_primary_expression): Do the main
>> > parse non-tentatively.
>> > ---
>> >  gcc/cp/parser.c   | 17 +++--
>> >  gcc/testsuite/g++.dg/cpp2a/concepts-syntax1.C |  9 +
>> >  2 files changed, 16 insertions(+), 10 deletions(-)
>> >  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-syntax1.C
>> >
>>
>> Hi,
>>
>> This patch is causing several regressions on arm and aarch64.
>>
>> For instance on aarch64:
>> FAIL: g++.dg/vect/pr89653.cc  -std=c++2a (test for excess errors)
>> Excess errors:
>> /aarch64-none-linux-gnu/libstdc++-v3/include/bits/ranges_algo.h:1254:4:
>> error: expected primary-expression before '&&' token
>>
>> and on arm:
>> FAIL: g++.dg/cpp0x/lambda/lambda-pass.C  -std=c++2a (test for excess errors)
>> Excess errors:
>> /arm-none-linux-gnueabi/libstdc++-v3/include/bits/ranges_algo.h:1254:4:
>> error: expected primary-expression before '&&' token
>>
>> Christophe
>
>
> This is fixed in r10-6512-ga04f635d1e4df9679caf763f744eb41a938468f4
>

Thanks. Sorry for missing it, but I understand why when I read the
commit message ;-)

> Jason
>

Re: [PATCH] c-format: -Wformat-diag fix [PR93641]

[Marek Polacek]

On Mon, Feb 10, 2020 at 03:25:43PM +0100, Jakub Jelinek wrote:
> Hi!
> 
> The last argument to strncasecmp is incorrect, so it matched even when
> can%' wasn't followed by t.  Also, the !ISALPHA (format_chars[1]) test
> looks pointless, format_chars[1] must be ' if strncasecmp succeeded and
> so will never be ISALPHA.
> 
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?

Ok, thanks.

Marek

Re: [PATCH] arm: Fix up arm installed unwind.h for use in pedantic modes [PR93615]

[Christophe Lyon]

On Mon, 10 Feb 2020 at 14:26, Jakub Jelinek  wrote:
>
> On Mon, Feb 10, 2020 at 02:03:47PM +0100, Christophe Lyon wrote:
> > > 2020-02-07  Jakub Jelinek  
> > >
> > > PR target/93615
> > > * config/arm/unwind-arm.h (gnu_Unwind_Find_got): Rename to ...
> > > (_Unwind_gnu_Find_got): ... this.  Use __asm instead of asm.  
> > > Remove
> > > trailing :s in asm.  Formatting fixes.
> > > (_Unwind_decode_typeinfo_ptr): Adjust caller.
> > >
> > > * gcc.dg/pr93615.c: New test.
> > >
> >
> > This broke the build of GCC for the arm-none-uclinuxfdpiceabi target 
> > (FDPIC).
>
> Oops, sorry.
>
> > The attached patch fixes this by updating other uses of gnu_Unwind_Find_got.
> >
> > OK?
>
> Looks obvious to me.

OK, thanks, pushed as r10-6546-g5602b48b2ed84feb1a5792e3d73b00b42138ca6e

>
> Jakub
>

[PATCH] i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637]

[Jakub Jelinek]

Hi!

As mentioned in the PR, for -mavx -mno-avx2 the backend does support
vcondv4div4df and vcondv8siv8sf optabs (while generally 32-byte vectors
aren't much supported in that case, it is performed using
vandps/vandnps/vorps).  The problem is that after the last generic vector
lowering (where the VEC_COND_EXPR still compares two V4DF vectors and
has two V4DI last operands and V4DI result and so is considered ok) fre4
folds the condition into constant, at which point the middle-end during
expansion will try vcond_mask_optab and fall back to trying to expand it
as the constant vector < 0 vcondv4div4di, but neither of them is supported
for -mavx -mno-avx2 and thus we ICE.

So, the options I see is either what the following patch does, also support
vcond_mask_v4div4di and vcond_mask_v4siv4si already for TARGET_AVX, or
require for vcondv4div4df and vcondv8siv8sf TARGET_AVX2 rather than current
TARGET_AVX.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or do you prefer the disabling of the vcond patterns instead?

2020-02-10  Jakub Jelinek  

PR target/93637
* config/i386/sse.md (VI_256_AVX2): New mode iterator.
(vcond_mask_): Use it instead of VI_256.
Change condition from TARGET_AVX2 to TARGET_AVX.

* gcc.target/i386/avx-pr93637.c: New test.

--- gcc/config/i386/sse.md.jj   2020-02-10 13:14:02.970131692 +0100
+++ gcc/config/i386/sse.md  2020-02-10 13:15:54.343473253 +0100
@@ -3430,13 +3430,19 @@ (define_expand "vcond_mask_ 3 "register_operand")))]
   "TARGET_AVX512BW")
 
+;; As vcondv4div4df and vcondv8siv8sf are enabled already with TARGET_AVX,
+;; and their condition can be folded late into a constant, we need to
+;; support vcond_mask_v4div4di and vcond_mask_v8siv8si for TARGET_AVX.
+(define_mode_iterator VI_256_AVX2 [(V32QI "TARGET_AVX2") (V16HI "TARGET_AVX2")
+  V8SI V4DI])
+
 (define_expand "vcond_mask_"
-  [(set (match_operand:VI_256 0 "register_operand")
-   (vec_merge:VI_256
- (match_operand:VI_256 1 "nonimmediate_operand")
- (match_operand:VI_256 2 "nonimm_or_0_operand")
+  [(set (match_operand:VI_256_AVX2 0 "register_operand")
+   (vec_merge:VI_256_AVX2
+ (match_operand:VI_256_AVX2 1 "nonimmediate_operand")
+ (match_operand:VI_256_AVX2 2 "nonimm_or_0_operand")
  (match_operand: 3 "register_operand")))]
-  "TARGET_AVX2"
+  "TARGET_AVX"
 {
   ix86_expand_sse_movcc (operands[0], operands[3],
 operands[1], operands[2]);
--- gcc/testsuite/gcc.target/i386/avx-pr93637.c.jj  2020-02-10 
13:19:18.212437488 +0100
+++ gcc/testsuite/gcc.target/i386/avx-pr93637.c 2020-02-10 13:18:25.651220171 
+0100
@@ -0,0 +1,17 @@
+/* PR target/93637 */
+/* { dg-do compile } */
+/* { dg-options "-mavx -mno-avx2 -O3 --param 
sccvn-max-alias-queries-per-access=3" } */
+
+double
+foo (void)
+{
+  int i;
+  double r = 7.0;
+  double a[] = { 0.0, 0.0, -0.0, 0.0, 0.0, -0.0, 1.0, 0.0, 0.0, -0.0, 1.0, 
0.0, 1.0, 1.0 };
+
+  for (i = 0; i < sizeof (a) / sizeof (a[0]); ++i)
+if (a[i] == 0.0)
+  r = a[i];
+
+  return r;
+}

Jakub

[PATCH] c-format: -Wformat-diag fix [PR93641]

[Jakub Jelinek]

Hi!

The last argument to strncasecmp is incorrect, so it matched even when
can%' wasn't followed by t.  Also, the !ISALPHA (format_chars[1]) test
looks pointless, format_chars[1] must be ' if strncasecmp succeeded and
so will never be ISALPHA.

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

2020-02-10  Jakub Jelinek  

PR other/93641
* c-format.c (check_plain): Fix up last argument of strncasecmp.
Remove useless extra test.

* gcc.dg/format/gcc_diag-11.c (test_cdiag_bad_words): Add two further
tests.

--- gcc/c-family/c-format.c.jj  2020-01-12 11:54:36.202416592 +0100
+++ gcc/c-family/c-format.c 2020-02-10 10:03:49.224547303 +0100
@@ -3270,8 +3270,7 @@ check_plain (location_t format_string_lo
   "quoted %qs directive in format; "
   "use %qs instead", "%s", "%qs");
   else if (format_chars - orig_format_chars > 2
-  && !strncasecmp (format_chars - 3, "can%'t", 5)
-  && !ISALPHA (format_chars[1]))
+  && !strncasecmp (format_chars - 3, "can%'t", 6))
format_warning_substr (format_string_loc,
   format_string_cst,
   fmtchrpos - 3, fmtchrpos + 3, opt,
--- gcc/testsuite/gcc.dg/format/gcc_diag-11.c.jj2020-01-12 
11:54:37.423398171 +0100
+++ gcc/testsuite/gcc.dg/format/gcc_diag-11.c   2020-02-10 10:04:50.594632918 
+0100
@@ -400,6 +400,8 @@ void test_cdiag_bad_words (tree t, gimpl
   cdiag ("you can't do that"); /* { dg-warning "contraction 'can't' in format" 
} */
   cdiag ("you can%'t do that");/* { dg-warning "contraction 'can%'t' in 
format" } */
   cdiag ("Can%'t touch this.");/* { dg-warning "contraction 'Can%'t' in 
format" } */
+  cdiag ("can%'");
+  cdiag ("can%' whatever");
   cdiag ("on the commandline");/* { dg-warning "misspelled term 'commandline' 
in format; use 'command line' instead" } */
   cdiag ("command line option");/* { dg-warning "misspelled term 'command line 
option' in format; use 'command-line option' instead" } */
   cdiag ("it mustn't be"); /* { dg-warning "contraction 'mustn't' in 
format" } */

Jakub

[committed] c++: Fix strncmp last argument in dump_decl_name [PR93641]

[Jakub Jelinek]

Hi!

I'm not aware of symbols starting with _ZG that don't start with _ZGR
prefix, but perhaps in the future there might be some.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk as obvious.

2020-02-10  Jakub Jelinek  

PR other/93641
* error.c (dump_decl_name): Fix up last argument to strncmp.

--- gcc/cp/error.c.jj   2020-02-08 10:58:28.450865914 +0100
+++ gcc/cp/error.c  2020-02-10 09:39:48.207008572 +0100
@@ -1098,7 +1098,7 @@ dump_decl_name (cxx_pretty_printer *pp,
 }
 
   const char *str = IDENTIFIER_POINTER (t);
-  if (!strncmp (str, "_ZGR", 3))
+  if (!strncmp (str, "_ZGR", 4))
 {
   pp_cxx_ws_string (pp, "");
   return;


Jakub

[committed] i386: Fix strncmp last arguments in x86_64_elf_section_type_flags [PR93641]

[Jakub Jelinek]

Hi!

Clearly I can't count, so we would consider as SECTION_BSS even sections
like .lbssfoo or .gnu.linkonce.lbbar, even when linker only considers as
special .lbss or .lbss.baz or .gnu.linkonce.lb.qux.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk as obvious.

2020-02-10  Jakub Jelinek  

PR target/58218
PR other/93641
* config/i386/i386.c (x86_64_elf_section_type_flags): Fix up last
arguments of strncmp.

--- gcc/config/i386/i386.c.jj   2020-02-07 19:11:57.378982855 +0100
+++ gcc/config/i386/i386.c  2020-02-10 09:24:18.247860282 +0100
@@ -751,8 +751,9 @@ x86_64_elf_section_type_flags (tree decl
 flags |= SECTION_RELRO;
 
   if (strcmp (name, ".lbss") == 0
-  || strncmp (name, ".lbss.", 5) == 0
-  || strncmp (name, ".gnu.linkonce.lb.", 16) == 0)
+  || strncmp (name, ".lbss.", sizeof (".lbss.") - 1) == 0
+  || strncmp (name, ".gnu.linkonce.lb.",
+ sizeof (".gnu.linkonce.lb.") - 1) == 0)
 flags |= SECTION_BSS;
 
   return flags;

Jakub

Re: [COMMITTED] c++: Fix ICE on nonsense requires-clause.

[Jason Merrill]

On Mon, Feb 10, 2020 at 2:13 PM Christophe Lyon 
wrote:

> On Fri, 7 Feb 2020 at 14:54, Jason Merrill  wrote:
> >
> > Here we were swallowing all the syntax errors by parsing tentatively, and
> > returning error_mark_node without ever actually giving an error.  Fixed
> by
> > using save_tokens/rollback_tokens instead.
> >
> > Tested x86_64-pc-linux-gnu, applying to trunk.
> >
> > PR c++/92517
> > * parser.c (cp_parser_constraint_primary_expression): Do the main
> > parse non-tentatively.
> > ---
> >  gcc/cp/parser.c   | 17 +++--
> >  gcc/testsuite/g++.dg/cpp2a/concepts-syntax1.C |  9 +
> >  2 files changed, 16 insertions(+), 10 deletions(-)
> >  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-syntax1.C
> >
>
> Hi,
>
> This patch is causing several regressions on arm and aarch64.
>
> For instance on aarch64:
> FAIL: g++.dg/vect/pr89653.cc  -std=c++2a (test for excess errors)
> Excess errors:
> /aarch64-none-linux-gnu/libstdc++-v3/include/bits/ranges_algo.h:1254:4:
> error: expected primary-expression before '&&' token
>
> and on arm:
> FAIL: g++.dg/cpp0x/lambda/lambda-pass.C  -std=c++2a (test for excess
> errors)
> Excess errors:
> /arm-none-linux-gnueabi/libstdc++-v3/include/bits/ranges_algo.h:1254:4:
> error: expected primary-expression before '&&' token
>
> Christophe
>

This is fixed in r10-6512-ga04f635d1e4df9679caf763f744eb41a938468f4

Jason

Re: [FYI] Patches that fix testing santiziers with qemu user mode

[Christophe Lyon]

Hi Andrew,


On Sat, 8 Feb 2020 at 10:16, Andrew Pinski  wrote:
>
> Hi,
>   These two patches are what I use to fix testing of the santizers
> with qemu.  The first one disables coloring always as for some reason
> when running with qemu (but not normally), coloring is detected.  I
> have not gone and debugged the reason why the sanitizers does not
> detect coloring when run under dejagnu even though, it is designed to
> be running under a psedu-TTY.

I looked at that a long time ago (2013 according to the list archives...), see
https://gcc.gnu.org/ml/gcc-patches/2013-05/msg00280.html

When I enabled ASAN on arm, I did update some of the expected outputs,
because of this coloring. I think I had to fix a few *SAN tests added
since then for that reason.

>
> The second patch disables LSAN when clone with the arguments that are
> needed to stop the world fail.  This second patch should in theory go
> upstream but I am not going to that right now; plus maybe it should
> only disable it when used with asan instead of in general.

On my side, I run the tests with ASAN_OPTIONS=detect_leaks=0

>
> With these two patches, I get clean test results on aarch64-linux-gnu.
> I am mainly sending them here as I think they are useful for people
> who are doing testing; especially cross testing.

Indeed, thanks for sharing them.

Christophe

>
> Thanks,
> Andrew Pinski

[Pingx3][GCC][PATCH][ARM]Add ACLE intrinsics for dot product (vusdot - vector, vdot - by element) for AArch32 AdvSIMD ARMv8.6 Extension

[Stam Markianos-Wright]

On 2/3/20 11:20 AM, Stam Markianos-Wright wrote:



On 1/27/20 3:54 PM, Stam Markianos-Wright wrote:


On 1/16/20 4:05 PM, Stam Markianos-Wright wrote:



On 1/10/20 6:48 PM, Stam Markianos-Wright wrote:



On 12/18/19 1:25 PM, Stam Markianos-Wright wrote:



On 12/13/19 10:22 AM, Stam Markianos-Wright wrote:

Hi all,

This patch adds the ARMv8.6 Extension ACLE intrinsics for dot product
operations (vector/by element) to the ARM back-end.

These are:
usdot (vector), dot (by element).

The functions are optional from ARMv8.2-a as -march=armv8.2-a+i8mm and
for ARM they remain optional as of ARMv8.6-a.

The functions are declared in arm_neon.h, RTL patterns are defined to
generate assembler and tests are added to verify and perform adequate checks.

Regression testing on arm-none-eabi passed successfully.

This patch depends on:

https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02195.html

for ARM CLI updates, and on:

https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00857.html

for testsuite effective_target update.

Ok for trunk?




New diff addressing review comments from Aarch64 version of the patch.

_Change of order of operands in RTL patterns.
_Change tests to use check-function-bodies, compile with optimisation and 
check for exact registers.

_Rename tests to remove "-compile-" in filename.




.Ping!


Ping :)

Diff re-attached in this ping email is same as the one posted on 10/01

Thank you!

.


Cheers,
Stam




ACLE documents are at https://developer.arm.com/docs/101028/latest
ISA documents are at https://developer.arm.com/docs/ddi0596/latest

PS. I don't have commit rights, so if someone could commit on my behalf,
that would be great :)


gcc/ChangeLog:

2019-11-28  Stam Markianos-Wright  

 * config/arm/arm-builtins.c (enum arm_type_qualifiers):
 (USTERNOP_QUALIFIERS): New define.
 (USMAC_LANE_QUADTUP_QUALIFIERS): New define.
 (SUMAC_LANE_QUADTUP_QUALIFIERS): New define.
 (arm_expand_builtin_args):
 Add case ARG_BUILTIN_LANE_QUADTUP_INDEX.
 (arm_expand_builtin_1): Add qualifier_lane_quadtup_index.
 * config/arm/arm_neon.h (vusdot_s32): New.
 (vusdot_lane_s32): New.
 (vusdotq_lane_s32): New.
 (vsudot_lane_s32): New.
 (vsudotq_lane_s32): New.
 * config/arm/arm_neon_builtins.def
 (usdot,usdot_lane,sudot_lane): New.
 * config/arm/iterators.md (DOTPROD_I8MM): New.
 (sup, opsuffix): Add .
    * config/arm/neon.md (neon_usdot, dot_lane: New.
 * config/arm/unspecs.md (UNSPEC_DOT_US, UNSPEC_DOT_SU): New.


gcc/testsuite/ChangeLog:

2019-12-12  Stam Markianos-Wright  

 * gcc.target/arm/simd/vdot-2-1.c: New test.
 * gcc.target/arm/simd/vdot-2-2.c: New test.
 * gcc.target/arm/simd/vdot-2-3.c: New test.
 * gcc.target/arm/simd/vdot-2-4.c: New test.




diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index df84560588a..1b4316d0e93 100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -86,7 +86,10 @@ enum arm_type_qualifiers
   qualifier_const_void_pointer = 0x802,
   /* Lane indices selected in pairs - must be within range of previous
  argument = a vector.  */
-  qualifier_lane_pair_index = 0x1000
+  qualifier_lane_pair_index = 0x1000,
+  /* Lane indices selected in quadtuplets - must be within range of previous
+ argument = a vector.  */
+  qualifier_lane_quadtup_index = 0x2000
 };
 
 /*  The qualifier_internal allows generation of a unary builtin from
@@ -122,6 +125,13 @@ arm_unsigned_uternop_qualifiers[SIMD_MAX_BUILTIN_ARGS]
   qualifier_unsigned };
 #define UTERNOP_QUALIFIERS (arm_unsigned_uternop_qualifiers)
 
+/* T (T, unsigned T, T).  */
+static enum arm_type_qualifiers
+arm_usternop_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+  = { qualifier_none, qualifier_none, qualifier_unsigned,
+  qualifier_none };
+#define USTERNOP_QUALIFIERS (arm_usternop_qualifiers)
+
 /* T (T, immediate).  */
 static enum arm_type_qualifiers
 arm_binop_imm_qualifiers[SIMD_MAX_BUILTIN_ARGS]
@@ -176,6 +186,20 @@ arm_umac_lane_qualifiers[SIMD_MAX_BUILTIN_ARGS]
   qualifier_unsigned, qualifier_lane_index };
 #define UMAC_LANE_QUALIFIERS (arm_umac_lane_qualifiers)
 
+/* T (T, unsigned T, T, lane index).  */
+static enum arm_type_qualifiers
+arm_usmac_lane_quadtup_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+  = { qualifier_none, qualifier_none, qualifier_unsigned,
+  qualifier_none, qualifier_lane_quadtup_index };
+#define USMAC_LANE_QUADTUP_QUALIFIERS (arm_usmac_lane_quadtup_qualifiers)
+
+/* T (T, T, unsigend T, lane index).  */
+static enum arm_type_qualifiers
+arm_sumac_lane_quadtup_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+  = { qualifier_none, qualifier_none, qualifier_none,
+  qualifier_unsigned, qualifier_lane_quadtup_index };
+#define SUMAC_LANE_QUADTUP_QUALIFIERS (arm_sumac_lane_quadtup_qualifiers)
+
 /* T (T, T, immediate).  */
 static enum arm_type_qualifiers
 arm_ternop_imm_qualifiers[SIMD_MAX_BUILTIN_ARGS]
@@ -2148,6 +2172,7 @@ typedef enum {
   

Re: [PATCH v2] [MIPS] Prevent allocation of a GPR for a floating mode pseudo

[Andrew Pinski]

On Mon, Feb 10, 2020 at 5:33 AM Mihailo Stojanovic
 wrote:
>
> Similar to the mirror case of allocating an FPR for an integer mode
> pseudo, prevent GPRs from being allocated for a floating mode pseudo.

Can you expand on why you want to do this?
Provide benchmarking or a testcase which this improves the code generation?
I can see this producing much worse code for soft-float (which I still
care about).

Thanks,
Andrew Pinski

>
> gcc/ChangeLog:
>
> * gcc/config/mips/mips.c (mips_ira_change_pseudo_allocno_class):
> Limit the allocation of floating mode pseudos to FP_REGS.
> ---
>  gcc/config/mips/mips.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
> index 513fc5f..ffcb14d 100644
> --- a/gcc/config/mips/mips.c
> +++ b/gcc/config/mips/mips.c
> @@ -22492,6 +22492,12 @@ mips_ira_change_pseudo_allocno_class (int regno, 
> reg_class_t allocno_class,
>   instructions that say integer mode values must be placed in FPRs.  */
>if (INTEGRAL_MODE_P (PSEUDO_REGNO_MODE (regno)) && allocno_class == 
> ALL_REGS)
>  return GR_REGS;
> +
> +  /* Likewise for the mirror case of floating mode pseudos being allocated in
> + a GPR.  */
> +  if (FLOAT_MODE_P (PSEUDO_REGNO_MODE (regno)) && allocno_class == ALL_REGS)
> +return FP_REGS;
> +
>return allocno_class;
>  }
>
> --
> 2.7.4
>

[PATCH v2] [MIPS] Prevent allocation of a GPR for a floating mode pseudo

[Mihailo Stojanovic]

Similar to the mirror case of allocating an FPR for an integer mode
pseudo, prevent GPRs from being allocated for a floating mode pseudo.

gcc/ChangeLog:

* gcc/config/mips/mips.c (mips_ira_change_pseudo_allocno_class):
Limit the allocation of floating mode pseudos to FP_REGS.
---
 gcc/config/mips/mips.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 513fc5f..ffcb14d 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -22492,6 +22492,12 @@ mips_ira_change_pseudo_allocno_class (int regno, 
reg_class_t allocno_class,
  instructions that say integer mode values must be placed in FPRs.  */
   if (INTEGRAL_MODE_P (PSEUDO_REGNO_MODE (regno)) && allocno_class == ALL_REGS)
 return GR_REGS;
+
+  /* Likewise for the mirror case of floating mode pseudos being allocated in
+ a GPR.  */
+  if (FLOAT_MODE_P (PSEUDO_REGNO_MODE (regno)) && allocno_class == ALL_REGS)
+return FP_REGS;
+
   return allocno_class;
 }
 
-- 
2.7.4

Re: [PATCH] [MIPS] Prevent allocation of a GPR for a floating mode pseudo

[Mihailo Stojanović]

Please disregard this.

Forgot to add the ChangeLog entry.

Mihailo

Re: [PATCH] arm: Fix up arm installed unwind.h for use in pedantic modes [PR93615]

[Jakub Jelinek]

On Mon, Feb 10, 2020 at 02:03:47PM +0100, Christophe Lyon wrote:
> > 2020-02-07  Jakub Jelinek  
> >
> > PR target/93615
> > * config/arm/unwind-arm.h (gnu_Unwind_Find_got): Rename to ...
> > (_Unwind_gnu_Find_got): ... this.  Use __asm instead of asm.  Remove
> > trailing :s in asm.  Formatting fixes.
> > (_Unwind_decode_typeinfo_ptr): Adjust caller.
> >
> > * gcc.dg/pr93615.c: New test.
> >
> 
> This broke the build of GCC for the arm-none-uclinuxfdpiceabi target (FDPIC).

Oops, sorry.

> The attached patch fixes this by updating other uses of gnu_Unwind_Find_got.
> 
> OK?

Looks obvious to me.

Jakub

[PATCH] c++: Fix return type deduction with an abbreviated function template

[Patrick Palka]

This patch fixes two issues with return type deduction in the presence of an
abbreviated function template.

The first issue (PR 69448) is that if a placeholder auto return type contains
any modifiers such as & or *, then the abbreviated-function-template
compensation in splice_late_return_type does not get performed for the
underlying auto node, leading to incorrect return type deduction.  This happens
because splice_late_return_type checks for a placeholder auto with is_auto,
which does not look through modifiers.  This patch replaces the use of is_auto
with find_type_usage, but it first refactors find_type_usage to return a pointer
to the matched tree so that we next subsequently replace it.

The second issue (PR 80471) is that the AUTO_IS_DECLTYPE flag is not being
preserved in splice_late_return_type when compensating for an abbreviated
function template, leading to us treating a decltype(auto) return type as if it
was an auto return type.  Fixed by propagating AUTO_IS_DECLTYPE.  The test for
PR 80471 is adjusted to expect the correct behavior.

Bootstrapped and regtested on x86_64-pc-linux-gnu, is this OK to commit?

gcc/cp/ChangeLog:

PR c++/69448
PR c++/80471
* type-utils.h (find_type_usage): Refactor to take a tree * and to
return a tree *, and update documentation accordingly.
* pt.c (splice_late_return_type): Use find_type_usage to find and
replace a possibly nested auto node.  Preserve the AUTO_IS_DECLTYPE
flag when replacing the node.
(type_uses_auto): Adjust the call to find_type_usage.

gcc/testsuite/ChangeLog:

PR c++/69448
PR c++/80471
* g++.dg/concepts/abbrev3.C: New test.
* g++.dg/cpp2a/concepts-pr80471.C: Adjust a static_assert to expect the
correct behavior.
---
 gcc/cp/pt.c   | 26 ---
 gcc/cp/type-utils.h   | 26 +--
 gcc/testsuite/g++.dg/concepts/abbrev3.C   | 11 
 gcc/testsuite/g++.dg/cpp2a/concepts-pr80471.C |  2 +-
 4 files changed, 41 insertions(+), 24 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/concepts/abbrev3.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2fb52caa5d4..c83aaa7c7e1 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -28904,17 +28904,21 @@ do_auto_deduction (tree type, tree init, tree 
auto_node,
 tree
 splice_late_return_type (tree type, tree late_return_type)
 {
-  if (is_auto (type))
-{
-  if (late_return_type)
-   return late_return_type;
+  if (is_auto (type) && late_return_type)
+return late_return_type;
 
-  tree idx = get_template_parm_index (type);
+  if (tree *auto_node = find_type_usage (, is_auto))
+{
+  tree idx = get_template_parm_index (*auto_node);
   if (TEMPLATE_PARM_LEVEL (idx) <= processing_template_decl)
-   /* In an abbreviated function template we didn't know we were dealing
-  with a function template when we saw the auto return type, so update
-  it to have the correct level.  */
-   return make_auto_1 (TYPE_IDENTIFIER (type), true);
+   {
+ /* In an abbreviated function template we didn't know we were dealing
+with a function template when we saw the auto return type, so
+update it to have the correct level.  */
+ tree new_node = make_auto_1 (TYPE_IDENTIFIER (*auto_node), true);
+ AUTO_IS_DECLTYPE (new_node) = AUTO_IS_DECLTYPE (*auto_node);
+ *auto_node = new_node;
+   }
 }
   return type;
 }
@@ -28960,8 +28964,10 @@ type_uses_auto (tree type)
   else
return NULL_TREE;
 }
+  else if (tree *tp = find_type_usage (, is_auto))
+return *tp;
   else
-return find_type_usage (type, is_auto);
+return NULL_TREE;
 }
 
 /* Report ill-formed occurrences of auto types in ARGUMENTS.  If
diff --git a/gcc/cp/type-utils.h b/gcc/cp/type-utils.h
index 680b2497a36..4ad0d822119 100644
--- a/gcc/cp/type-utils.h
+++ b/gcc/cp/type-utils.h
@@ -20,36 +20,36 @@ along with GCC; see the file COPYING3.  If not see
 #ifndef GCC_CP_TYPE_UTILS_H
 #define GCC_CP_TYPE_UTILS_H
 
-/* Returns the first tree within T that is directly matched by PRED.  T may be 
a
-   type or PARM_DECL and is incrementally decomposed toward its type-specifier
-   until a match is found.  NULL_TREE is returned if PRED does not match any
-   part of T.
+/* Returns a pointer to the first tree within *TP that is directly matched by
+   PRED.  *TP may be a type or PARM_DECL and is incrementally decomposed toward
+   its type-specifier until a match is found.  NULL is returned if PRED does 
not
+   match any part of *TP.
 
-   This is primarily intended for detecting whether T uses `auto' or a concept
+   This is primarily intended for detecting whether *TP uses `auto' or a 
concept
identifier.  Since either of these can only appear as a type-specifier for
the declaration in question, only top-level qualifications are traversed;

Re: [COMMITTED] c++: Fix ICE on nonsense requires-clause.

[Christophe Lyon]

On Fri, 7 Feb 2020 at 14:54, Jason Merrill  wrote:
>
> Here we were swallowing all the syntax errors by parsing tentatively, and
> returning error_mark_node without ever actually giving an error.  Fixed by
> using save_tokens/rollback_tokens instead.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> PR c++/92517
> * parser.c (cp_parser_constraint_primary_expression): Do the main
> parse non-tentatively.
> ---
>  gcc/cp/parser.c   | 17 +++--
>  gcc/testsuite/g++.dg/cpp2a/concepts-syntax1.C |  9 +
>  2 files changed, 16 insertions(+), 10 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-syntax1.C
>

Hi,

This patch is causing several regressions on arm and aarch64.

For instance on aarch64:
FAIL: g++.dg/vect/pr89653.cc  -std=c++2a (test for excess errors)
Excess errors:
/aarch64-none-linux-gnu/libstdc++-v3/include/bits/ranges_algo.h:1254:4:
error: expected primary-expression before '&&' token

and on arm:
FAIL: g++.dg/cpp0x/lambda/lambda-pass.C  -std=c++2a (test for excess errors)
Excess errors:
/arm-none-linux-gnueabi/libstdc++-v3/include/bits/ranges_algo.h:1254:4:
error: expected primary-expression before '&&' token

Christophe

> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index e0f72302e5e..d4c9523289f 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -27478,7 +27478,7 @@ cp_parser_constraint_primary_expression (cp_parser 
> *parser, bool lambda_p)
>return e;
>  }
>
> -  cp_parser_parse_tentatively (parser);
> +  cp_lexer_save_tokens (parser->lexer);
>cp_id_kind idk;
>location_t loc = input_location;
>cp_expr expr = cp_parser_primary_expression (parser,
> @@ -27494,19 +27494,16 @@ cp_parser_constraint_primary_expression (cp_parser 
> *parser, bool lambda_p)
>/* The primary-expression could be part of an unenclosed non-logical
>  compound expression.  */
>pce = cp_parser_constraint_requires_parens (parser, lambda_p);
> -  if (pce != pce_ok)
> -   cp_parser_simulate_error (parser);
> -  else
> -   expr = finish_constraint_primary_expr (expr);
>  }
> -  if (cp_parser_parse_definitely (parser))
> -return expr;
> -  if (expr == error_mark_node)
> -return error_mark_node;
> +  if (pce == pce_ok)
> +{
> +  cp_lexer_commit_tokens (parser->lexer);
> +  return finish_constraint_primary_expr (expr);
> +}
>
>/* Retry the parse at a lower precedence. If that succeeds, diagnose the
>   error, but return the expression as if it were valid.  */
> -  gcc_assert (pce != pce_ok);
> +  cp_lexer_rollback_tokens (parser->lexer);
>cp_parser_parse_tentatively (parser);
>if (pce == pce_maybe_operator)
>  expr = cp_parser_assignment_expression (parser, NULL, false, false);
> diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-syntax1.C 
> b/gcc/testsuite/g++.dg/cpp2a/concepts-syntax1.C
> new file mode 100644
> index 000..0a47682c456
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-syntax1.C
> @@ -0,0 +1,9 @@
> +// PR c++/92517
> +// { dg-do compile { target concepts } }
> +
> +template 
> +concept C = true;
> +
> +template
> +requires C decltype // { dg-error "" }
> +void f() {}
>
> base-commit: 3c7a03bc360c3511fae3747a71e579e9fd0824f9
> --
> 2.18.1
>

Re: [PATCH] arm: Fix up arm installed unwind.h for use in pedantic modes [PR93615]

[Christophe Lyon]

Hi,

On Fri, 7 Feb 2020 at 09:19, Jakub Jelinek  wrote:
>
> Hi!
>
> As the following testcase shows, unwind.h on ARM can't be (starting with GCC
> 10) compiled with -std=c* modes, only -std=gnu* modes.
> The problem is it uses asm keyword, which isn't a keyword in those modes
> (system headers vs. non-system ones don't make a difference here).
> glibc and other installed headers use __asm or __asm__ keywords instead that
> work fine in both standard and gnu modes.
>
> While there, as it is an installed header, I think it is also wrong to
> completely ignore any identifier namespace rules.
> The generic unwind.h defines just _Unwind* namespace identifiers plus
> _sleb128_t/_uleb128_t (but e.g. unlike libstdc++/glibc headers doesn't
> uglify operand names), the ARM unwind.h is much worse here.  I've just
> changed the gnu_Unwind_Find_got function at least not be in user identifier
> namespace, but perhaps it would be good to go further and rename e.g.
> #define UNWIND_STACK_REG 13
> #define UNWIND_POINTER_REG 12
> #define FDPIC_REGNUM 9
> #define STR(x) #x
> #define XSTR(x) STR(x)
> or e.g.
>   typedef _Unwind_Reason_Code (*personality_routine) (_Unwind_State,
>   _Unwind_Control_Block *, _Unwind_Context *);
> in unwind-arm-common.h.
>
> Bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?
>
> 2020-02-07  Jakub Jelinek  
>
> PR target/93615
> * config/arm/unwind-arm.h (gnu_Unwind_Find_got): Rename to ...
> (_Unwind_gnu_Find_got): ... this.  Use __asm instead of asm.  Remove
> trailing :s in asm.  Formatting fixes.
> (_Unwind_decode_typeinfo_ptr): Adjust caller.
>
> * gcc.dg/pr93615.c: New test.
>

This broke the build of GCC for the arm-none-uclinuxfdpiceabi target (FDPIC).

The attached patch fixes this by updating other uses of gnu_Unwind_Find_got.

OK?

Thanks,

Christophe

>From 667227c7d3d5c3e471be02adc0ce7dc2c4ebfd25 Mon Sep 17 00:00:00 2001
From: Christophe Lyon 
Date: Mon, 10 Feb 2020 12:54:39 +
Subject: [PATCH 1/1] arm: Fix up arm installed unwind.h for use in pedantic
 modes [PR93615]

Commit r10-6500-g811a475ea3fcc55ee4aea7c81171891ef19dfc25 broke the
GCC build for arm-none-uclinuxfdpiceabi, as it forgot to update some
uses of gnu_Unwind_Find_got.

2020-02-10  Christophe Lyon  

libgcc/
* unwind-arm-common.inc: Replace uses of gnu_Unwind_Find_got with
_Unwind_gnu_Find_got.
* unwind-pe.h: Likewise.
---
 libgcc/unwind-arm-common.inc | 8 
 libgcc/unwind-pe.h   | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/libgcc/unwind-arm-common.inc b/libgcc/unwind-arm-common.inc
index 3c774b8..31a072b 100644
--- a/libgcc/unwind-arm-common.inc
+++ b/libgcc/unwind-arm-common.inc
@@ -419,7 +419,7 @@ get_eit_entry (_Unwind_Control_Block *ucbp, _uw
return_address)
   UCB_PR_ADDR (ucbp) = selfrel_offset31 (ucbp->pr_cache.ehtp);
 #if __FDPIC__
   UCB_PR_GOT (ucbp)
- = (unsigned int) gnu_Unwind_Find_got ((_Unwind_Ptr) UCB_PR_ADDR (ucbp));
+ = (unsigned int) _Unwind_gnu_Find_got ((_Unwind_Ptr) UCB_PR_ADDR (ucbp));
 #endif
 }
   return _URC_OK;
@@ -462,7 +462,7 @@ unwind_phase2 (_Unwind_Control_Block * ucbp,
phase2_vrs * vrs)

 #if __FDPIC__
   /* r9 could have been lost due to PLT jump.  Restore correct value.  */
-  vrs->core.r[FDPIC_REGNUM] = gnu_Unwind_Find_got (VRS_PC (vrs));
+  vrs->core.r[FDPIC_REGNUM] = _Unwind_gnu_Find_got (VRS_PC (vrs));
 #endif

   uw_restore_core_regs (vrs, >core);
@@ -562,7 +562,7 @@ unwind_phase2_forced (_Unwind_Control_Block *ucbp,
phase2_vrs *entry_vrs,

 #if __FDPIC__
   /* r9 could have been lost due to PLT jump.  Restore correct value.  */
-  saved_vrs.core.r[FDPIC_REGNUM] = gnu_Unwind_Find_got (VRS_PC (_vrs));
+  saved_vrs.core.r[FDPIC_REGNUM] = _Unwind_gnu_Find_got (VRS_PC (_vrs));
 #endif

   uw_restore_core_regs (_vrs, _vrs.core);
@@ -698,7 +698,7 @@ __gnu_Unwind_Resume (_Unwind_Control_Block * ucbp,
phase2_vrs * entry_vrs)
   /* Upload the registers to enter the landing pad.  */
 #if __FDPIC__
   /* r9 could have been lost due to PLT jump.  Restore correct value.  */
-  entry_vrs->core.r[FDPIC_REGNUM] = gnu_Unwind_Find_got (VRS_PC
(entry_vrs));
+  entry_vrs->core.r[FDPIC_REGNUM] = _Unwind_gnu_Find_got (VRS_PC
(entry_vrs));
 #endif
   uw_restore_core_regs (entry_vrs, _vrs->core);

diff --git a/libgcc/unwind-pe.h b/libgcc/unwind-pe.h
index a336127..a6b4bff 100644
--- a/libgcc/unwind-pe.h
+++ b/libgcc/unwind-pe.h
@@ -267,7 +267,7 @@ read_encoded_value_with_base (unsigned char
encoding, _Unwind_Ptr base,
   into account.  */
if ((encoding & DW_EH_PE_pcrel) && (encoding & DW_EH_PE_indirect))
  {
-   result += gnu_Unwind_Find_got ((_Unwind_Ptr) u);
+   result += _Unwind_gnu_Find_got ((_Unwind_Ptr) u);
result = *(_Unwind_Internal_Ptr *) result;
  }
else
-- 
2.7.4


> --- libgcc/config/arm/unwind-arm.h.jj   2020-01-12 11:54:38.616380172 +0100
> +++ libgcc/config/arm/unwind-arm.h  2020-02-06 16:16:54.244624408 +0100

Re: [PATCH Coroutines]Insert the default return_void call at correct position

[Iain Sandoe]

Hi Bin,

Bin.Cheng  wrote:

> Ping.

We are seeking to clarify the standard wording around this (and the cases where
unhandled_exception() returns - hopefully during the WG21 meeting this week,

FWIW, I think your interpretation makes sense here.

thanks
Iain

> 
> Thanks,
> bin
> 
> On Mon, Feb 3, 2020 at 1:55 PM bin.cheng  wrote:
>> Hi,
>> 
>> Exception in coroutine is not correctly handled because the default
>> return_void call is now inserted before the finish suspend point,
>> rather than at the end of the original coroutine body.  This patch
>> fixes the issue by generating following code:
>>  co_await promise.initial_suspend();
>>  try {
>>// The original coroutine body
>> 
>>promise.return_void(); // The default return_void call.
>>  } catch (...) {
>>promise.unhandled_exception();
>>  }
>>  final_suspend:
>>  // ...
>> 
>> Bootstrap and test on x86_64.  Is it OK?
>> 
>> Thanks,
>> bin
>> 
>> gcc/cp
>> 2020-02-03  Bin Cheng  
>> 
>>* coroutines.cc (build_actor_fn): Factor out code inserting the
>>default return_void call to...
>>(morph_fn_to_coro): ...here, also hoist local var declarations.
>> 
>> gcc/testsuite
>> 2020-02-03  Bin Cheng  
>> 
>>* g++.dg/coroutines/torture/co-ret-15-default-return_void.C: New.