Re: [PATCH v3 06/12] LoongArch Port: Builtin macros.

2021-12-16 Thread Paul Hua via Gcc-patches
Hi Joseph,

Thanks for your suggestion, Those macros can be removed, we will send
the v4 version soon.

Are there any problems in this series of patches?

In other words, What conditions are required for LoongArch back-end merged?

By the way, We are preparing the LoongArch machine to send to Cfarm for testing.

On Tue, Dec 14, 2021 at 8:13 AM Joseph Myers  wrote:
>
> On Fri, 10 Dec 2021, Chenghua Xu wrote:
>
> > +  /* Macros dependent on the C dialect.  */
> > +  if (preprocessing_asm_p ())
> > +{
> > +  builtin_define_std ("LANGUAGE_ASSEMBLY");
> > +  builtin_define ("_LANGUAGE_ASSEMBLY");
> > +}
> > +  else if (c_dialect_cxx ())
> > +{
> > +  builtin_define ("_LANGUAGE_C_PLUS_PLUS");
> > +  builtin_define ("__LANGUAGE_C_PLUS_PLUS");
> > +  builtin_define ("__LANGUAGE_C_PLUS_PLUS__");
> > +}
> > +  else
> > +{
> > +  builtin_define_std ("LANGUAGE_C");
> > +  builtin_define ("_LANGUAGE_C");
> > +}
> > +  if (c_dialect_objc ())
> > +{
> > +  builtin_define ("_LANGUAGE_OBJECTIVE_C");
> > +  builtin_define ("__LANGUAGE_OBJECTIVE_C");
> > +  /* Bizarre, but retained for backwards compatibility.  */
> > +  builtin_define_std ("LANGUAGE_C");
> > +  builtin_define ("_LANGUAGE_C");
> > +}
> > +}
>
> I think all of this should be removed.  It's a new architecture, there
> should be no need for any such macros for things that are not
> architecture-specific.  In general, be careful to remove anything in the
> port that is actually about the peculiarities of what was once done for
> compatibility with existing software for an old architecture (MIPS?) that
> you modelled the port on and that is not considered best practice for a
> new architecture where you can make a fresh start.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com


[PATCH] libstdc++, v2: Add %j, %U, %w, %W time_get support, fix %y, %Y, %C, %p [PR77760]

2021-12-16 Thread Jakub Jelinek via Gcc-patches
On Thu, Dec 16, 2021 at 03:46:47PM +0100, Jakub Jelinek via Gcc-patches wrote:
> glibc strptime passes around some state, what fields in struct tm have been
> set and what needs to be finalized through possibly recursive calls, and
> at the end performs various finalizations, like applying %p so that it
> works for both %I %p and %p %I orders, or applying century so that both
> %C %y and %y %C works, or computation of missing fields from others
> (e.g. from %Y and %j one can compute tm_mon, tm_mday and tm_wday,
> from %Y %U %w, %Y %W %w, %Y %U %a, or %Y %W %w one can compute
> tm_mon, tm_mday, tm_yday or e.g. from %Y %m %d one can compute tm_wday
> and tm_yday.
...

Here is an updated patch with _M_ prefixes on members instead of __
and no uglification of parameters and automatic vars in *.cc.  No changes
otherwise, bootstrapped/regtested on x86_64-linux and i686-linux
successfully.

2021-12-17  Jakub Jelinek  

PR libstdc++/77760
* include/bits/locale_facets_nonio.h (__time_get_state): New struct.
(time_get::_M_extract_via_format): Declare new method with
__time_get_state& as an extra argument.
* include/bits/locale_facets_nonio.tcc (_M_extract_via_format): Add
__state argument, set various fields in it while parsing.  Handle %j,
%U, %w and %W, fix up handling of %y, %Y and %C, don't adjust tm_hour
for %p immediately.  Add a wrapper around the method without the
__state argument for backwards compatibility.
(_M_extract_num): Remove all __len == 4 special cases.
(time_get::do_get_time, time_get::do_get_date, time_get::do_get): Zero
initialize __state, pass it to _M_extract_via_format and finalize it
at the end.
(do_get_year): For 1-2 digit parsed years, map 0-68 to 2000-2068,
69-99 to 1969-1999.  For 3-4 digit parsed years use that as year.
(get): If do_get isn't overloaded from the locale_facets_nonio.tcc
version, don't call do_get but call _M_extract_via_format instead to
pass around state.
* config/abi/pre/gnu.ver (GLIBCXX_3.4.30): Export _M_extract_via_format
with extra __time_get_state and __time_get_state::_M_finalize_state.
* src/c++98/locale_facets.cc (is_leap, day_of_the_week,
day_of_the_year): New functions in anon namespace.
(mon_yday): New var in anon namespace.
(__time_get_state::_M_finalize_state): Define.
* testsuite/22_locale/time_get/get/char/4.cc: New test.
* testsuite/22_locale/time_get/get/wchar_t/4.cc: New test.
* testsuite/22_locale/time_get/get_year/char/1.cc (test01): Parse 197
as year 197AD instead of error.
* testsuite/22_locale/time_get/get_year/char/5.cc (test01): Parse 1 as
year 2001 instead of error.
* testsuite/22_locale/time_get/get_year/char/6.cc: New test.
* testsuite/22_locale/time_get/get_year/wchar_t/1.cc (test01): Parse
197 as year 197AD instead of error.
* testsuite/22_locale/time_get/get_year/wchar_t/5.cc (test01): Parse
1 as year 2001 instead of error.
* testsuite/22_locale/time_get/get_year/wchar_t/6.cc: New test.

--- libstdc++-v3/include/bits/locale_facets_nonio.h.jj  2021-12-10 
22:17:54.541591942 +0100
+++ libstdc++-v3/include/bits/locale_facets_nonio.h 2021-12-17 
00:21:33.125297992 +0100
@@ -355,6 +355,30 @@ namespace std _GLIBCXX_VISIBILITY(defaul
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
+  struct __time_get_state
+  {
+// Finalize state.
+void
+_M_finalize_state(tm* __tm);
+
+unsigned int _M_have_I : 1;
+unsigned int _M_have_wday : 1;
+unsigned int _M_have_yday : 1;
+unsigned int _M_have_mon : 1;
+unsigned int _M_have_mday : 1;
+unsigned int _M_have_uweek : 1;
+unsigned int _M_have_wweek : 1;
+unsigned int _M_have_century : 1;
+unsigned int _M_is_pm : 1;
+unsigned int _M_want_century : 1;
+unsigned int _M_want_xday : 1;
+unsigned int _M_pad1 : 5;
+unsigned int _M_week_no : 6;
+unsigned int _M_pad2 : 10;
+int _M_century;
+int _M_pad3;
+  };
+
 _GLIBCXX_BEGIN_NAMESPACE_CXX11
 
   /**
@@ -756,6 +780,14 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   _M_extract_via_format(iter_type __beg, iter_type __end, ios_base& __io,
ios_base::iostate& __err, tm* __tm,
const _CharT* __format) const;
+
+  // Extract on a component-by-component basis, via __format argument, with
+  // state.
+  iter_type
+  _M_extract_via_format(iter_type __beg, iter_type __end, ios_base& __io,
+   ios_base::iostate& __err, tm* __tm,
+   const _CharT* __format,
+   __time_get_state &__state) const;
 };
 
   template
--- libstdc++-v3/include/bits/locale_facets_nonio.tcc.jj2021-12-14 
22:48:04.656769701 +0100
+++ libstdc++-v3/include/bits/locale_facets_nonio.tcc   2021-12-17 
00:22:05.2588

Re: [PATCH] [i386][avx512]Add combine splitter to transform vpternlogd/vpcmpeqd/vpxor/vblendvps to vblendvps for ~op0

2021-12-16 Thread Hongtao Liu via Gcc-patches
On Wed, Dec 15, 2021 at 9:26 AM Haochen Jiang via Gcc-patches
 wrote:
>
> Hi all,
>
> This patch fix the regression previously reported on the combine splitter 
> under '-m32 -march=cascadelake' options.
>
> Regtested on x86_64-pc-linux-gnu.
Ok.
>
> BRs,
> Haochen
>
> gcc/ChangeLog:
>
> PR target/100738
> * config/i386/sse.md (*avx_cmp3_lt, *avx_cmp3_ltint):
> Remove MEM_P restriction and add force_reg for operands[2].
> (*avx_cmp3_ltint_not): Add new define_insn_and_split.
>
> gcc/testsuite/ChangeLog:
>
> PR target/100738
> * g++.target/i386/avx512vl-pr100738-1.C: New test.
> ---
>  gcc/config/i386/sse.md| 44 +--
>  .../g++.target/i386/avx512vl-pr100738-1.C |  8 
>  2 files changed, 48 insertions(+), 4 deletions(-)
>  create mode 100755 gcc/testsuite/g++.target/i386/avx512vl-pr100738-1.C
>
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 5421fb51684..8ec9fb075d0 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -3528,8 +3528,7 @@
>  UNSPEC_PCMP)))]
>"TARGET_AVX512VL && ix86_pre_reload_split ()
>/* LT or GE 0 */
> -  && ((INTVAL (operands[5]) == 1 && !MEM_P (operands[2]))
> -  || (INTVAL (operands[5]) == 5 && !MEM_P (operands[1])))"
> +  && ((INTVAL (operands[5]) == 1) || (INTVAL (operands[5]) == 5))"
>"#"
>"&& 1"
>[(set (match_dup 0)
> @@ -3543,6 +3542,7 @@
>  {
>if (INTVAL (operands[5]) == 5)
>  std::swap (operands[1], operands[2]);
> +  operands[2] = force_reg (mode, operands[2]);
>  })
>
>  (define_insn_and_split "*avx_cmp3_ltint"
> @@ -3557,8 +3557,7 @@
>  UNSPEC_PCMP)))]
>"TARGET_AVX512VL && ix86_pre_reload_split ()
>/* LT or GE 0 */
> -  && ((INTVAL (operands[5]) == 1 && !MEM_P (operands[2]))
> -  || (INTVAL (operands[5]) == 5 && !MEM_P (operands[1])))"
> +  && ((INTVAL (operands[5]) == 1) || (INTVAL (operands[5]) == 5))"
>"#"
>"&& 1"
>[(set (match_dup 0)
> @@ -3575,7 +3574,44 @@
>  std::swap (operands[1], operands[2]);
>operands[0] = gen_lowpart (mode, operands[0]);
>operands[1] = gen_lowpart (mode, operands[1]);
> +  operands[2] = force_reg (mode,
> + gen_lowpart (mode, operands[2]));
> +})
> +
> +(define_insn_and_split "*avx_cmp3_ltint_not"
> + [(set (match_operand:VI48_AVX  0 "register_operand")
> +   (vec_merge:VI48_AVX
> +(match_operand:VI48_AVX 1 "vector_operand")
> +(match_operand:VI48_AVX 2 "vector_operand")
> +(unspec:
> +  [(subreg:VI48_AVX
> +   (not:
> + (match_operand: 3 "vector_operand")) 0)
> +   (match_operand:VI48_AVX 4 "const0_operand")
> +   (match_operand:SI 5 "const_0_to_7_operand")]
> +   UNSPEC_PCMP)))]
> +  "TARGET_AVX512VL && ix86_pre_reload_split ()
> +  /* not LT or GE 0 */
> +  && ((INTVAL (operands[5]) == 1) || (INTVAL (operands[5]) == 5))"
> +  "#"
> +  "&& 1"
> +  [(set (match_dup 0)
> +   (unspec:
> + [(match_dup 1)
> +  (match_dup 2)
> +  (subreg:
> +(lt:VI48_AVX
> + (match_dup 3)
> + (match_dup 4)) 0)]
> +   UNSPEC_BLENDV))]
> +{
> +  if (INTVAL (operands[5]) == 5)
> +std::swap (operands[1], operands[2]);
> +  operands[0] = gen_lowpart (mode, operands[0]);
> +  operands[1] = force_reg (mode,
> + gen_lowpart (mode, operands[1]));
>operands[2] = gen_lowpart (mode, operands[2]);
> +  operands[3] = lowpart_subreg (mode, operands[3], mode);
>  })
>
>  (define_insn "avx_vmcmp3"
> diff --git a/gcc/testsuite/g++.target/i386/avx512vl-pr100738-1.C 
> b/gcc/testsuite/g++.target/i386/avx512vl-pr100738-1.C
> new file mode 100755
> index 000..ac4d62b94d1
> --- /dev/null
> +++ b/gcc/testsuite/g++.target/i386/avx512vl-pr100738-1.C
> @@ -0,0 +1,8 @@
> +/* { dg-do compile } */
> +/* { dg-options "-Ofast -march=cascadelake" } */
> +/* { dg-final {scan-assembler-times "vblendvps\[ \\t\]" 2 } } */
> +/* { dg-final {scan-assembler-not "vpcmpeqd\[ \\t\]" } } */
> +/* { dg-final {scan-assembler-not "vpxor\[ \\t\]" } } */
> +/* { dg-final {scan-assembler-not "vpternlogd\[ \\t\]" } } */
> +
> +#include "pr100738-1.C"
> --
> 2.18.1
>


-- 
BR,
Hongtao


[pushed] c++: layout of aggregate base with DMI [PR103681]

2021-12-16 Thread Jason Merrill via Gcc-patches
C++14 changed the definition of 'aggregate' to allow default member
initializers, but such classes still need to be considered "non-POD for the
purpose of layout" for ABI compatibility with C++11 code.  It seems rare to
derive from such a class, as evidenced by how long this bug has
survived (since r216750 in 2014), but it's certainly worth fixing.

We only warn when we were failing to allocate another field into the
tail padding of the newly aggregate class; this is the only ABI impact.

This also changes end_of_class to consider all data members, not just empty
data members; that used to be an additional flag, removed in r9-5710, but I
don't see any reason not to always include them.  This makes the result of
the function correspond to the ABI nvsize term and its nameless counterpart
that does include virtual bases.

When looking closely at other users of end_of_class, I realized that we were
assuming that the latter corresponded to the ABI dsize term, but it doesn't
if the class ends with an empty virtual base (in the rare case that the
empty base can't be assigned offset 0), and this matters for layout of
[[no_unique_address]].  So I added another mode that returns the desired
value for that case.  I'm not adding a warning for this ABI fix because it's
a C++20 feature.

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

PR c++/103681

gcc/ChangeLog:

* common.opt (fabi-version): Add v17.

gcc/cp/ChangeLog:

* cp-tree.h (struct lang_type): Add non_pod_aggregate.
(CLASSTYPE_NON_POD_AGGREGATE): New.
* class.c (check_field_decls): Set it.
(check_bases_and_members): Check it.
(check_non_pod_aggregate): New.
(enum eoc_mode): New.
(end_of_class): Always include non-empty fields.
Add eoc_nv_or_dsize mode.
(include_empty_classes, layout_class_type): Adjust.

gcc/c-family/ChangeLog:

* c-opts.c (c_common_post_options): Update defaults.

gcc/testsuite/ChangeLog:

* g++.dg/abi/macro0.C: Update value.
* g++.dg/abi/no_unique_address6.C: New test.
* g++.dg/abi/nsdmi-aggr1.C: New test.
* g++.dg/abi/nsdmi-aggr1a.C: New test.
---
 gcc/common.opt|   4 +
 gcc/cp/cp-tree.h  |   9 +-
 gcc/c-family/c-opts.c |   6 +-
 gcc/cp/class.c| 145 +-
 gcc/testsuite/g++.dg/abi/macro0.C |   2 +-
 gcc/testsuite/g++.dg/abi/no_unique_address6.C |  23 +++
 gcc/testsuite/g++.dg/abi/nsdmi-aggr1.C|  39 +
 gcc/testsuite/g++.dg/abi/nsdmi-aggr1a.C   |  35 +
 8 files changed, 217 insertions(+), 46 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/abi/no_unique_address6.C
 create mode 100644 gcc/testsuite/g++.dg/abi/nsdmi-aggr1.C
 create mode 100644 gcc/testsuite/g++.dg/abi/nsdmi-aggr1a.C

diff --git a/gcc/common.opt b/gcc/common.opt
index 8f8fc2f9ee7..4af89ce8fd2 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -990,6 +990,10 @@ Driver Undocumented
 ; Adds missing 'on' in mangling of operator names in some cases.
 ; Default in G++ 11.
 ;
+; 17: Fixes layout of classes that inherit from aggregate classes with default
+; member initializers in C++14 and up.
+; Default in G++ 12.
+;
 ; Additional positive integers will be assigned as new versions of
 ; the ABI become the default version of the ABI.
 fabi-version=
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 7f32cf56383..191143025a3 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -2343,6 +2343,7 @@ struct GTY(()) lang_type {
   unsigned unique_obj_representations : 1;
   unsigned unique_obj_representations_set : 1;
   bool erroneous : 1;
+  bool non_pod_aggregate : 1;
 
   /* When adding a flag here, consider whether or not it ought to
  apply to a template instance if it applies to the template.  If
@@ -2351,7 +2352,7 @@ struct GTY(()) lang_type {
   /* There are some bits left to fill out a 32-bit word.  Keep track
  of this by updating the size of this bitfield whenever you add or
  remove a flag.  */
-  unsigned dummy : 4;
+  unsigned dummy : 3;
 
   tree primary_base;
   vec *vcall_indices;
@@ -2671,6 +2672,12 @@ struct GTY(()) lang_type {
 /* True if we saw errors while instantiating this class.  */
 #define CLASSTYPE_ERRONEOUS(NODE) \
   (LANG_TYPE_CLASS_CHECK (NODE)->erroneous)
+
+/* True if this class is non-layout-POD only because it was not an aggregate
+   before C++14.  If we run out of bits in lang_type, this could be replaced
+   with a hash_set only filled in when abi_version_crosses (17).  */
+#define CLASSTYPE_NON_POD_AGGREGATE(NODE) \
+  (LANG_TYPE_CLASS_CHECK (NODE)->non_pod_aggregate)
 
 /* Additional macros for inheritance information.  */
 
diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 93845d57dee..4c20e44f5b5 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -975,9 +975,9 @@ c_common_post_options (const char

[PATCH, rs6000] Implement mffscrni pattern

2021-12-16 Thread HAO CHEN GUI via Gcc-patches
Hi,
   This patch defines a pattern for mffscrni. If the RN is a constant, it can 
call
gen_rs6000_mffscrni directly. The "rs6000-builtin-new.def" defines prototype 
for builtin arguments.
The pattern "rs6000_set_fpscr_rn" is then broken as the mode of its argument is 
DI while its
corresponding builtin has a const int argument. The patch also fixed it.

   Bootstrapped and tested on powerpc64-linux BE and LE with no regressions. Is 
this okay for trunk?
Any recommendations? Thanks a lot.

ChangeLog
2021-12-17 Haochen Gui 

gcc/
* config/rs6000/predicates.md (u2bit_cint_operand): Defined.
* config/rs6000/rs6000-call.c
(rs6000_expand_set_fpscr_rn_builtin): Not copy argument to a reg if
it's a constant. The pattern for constant can be recognized now.
* config/rs6000/rs6000.md (UNSPECV_MFFSCRNI): Defined.
(rs6000_mffscrni): Defined.
(rs6000_set_fpscr_rn): Change the type of operand[0] form DI to SI.
Call gen_rs6000_mffscrni when operand[0] is a const int[0,3].

gcc/testsuite/
* gcc.target/powerpc/mffscrni_p9.c: New testcase for mffscrni.
* gcc.target/powerpc/test_fpscr_rn_builtin.c: Modify the test cases to
test mffscrn and mffscrni separately.

patch.diff
diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md
index f216ffd..b10b4ce 100644
--- a/gcc/config/rs6000/predicates.md
+++ b/gcc/config/rs6000/predicates.md
@@ -219,6 +219,11 @@ (define_predicate "u1bit_cint_operand"
   (and (match_code "const_int")
(match_test "INTVAL (op) >= 0 && INTVAL (op) <= 1")))

+;; Return 1 if op is an unsigned 2-bit constant integer.
+(define_predicate "u2bit_cint_operand"
+  (and (match_code "const_int")
+   (match_test "INTVAL (op) >= 0 && INTVAL (op) <= 3")))
+
 ;; Return 1 if op is a unsigned 3-bit constant integer.
 (define_predicate "u3bit_cint_operand"
   (and (match_code "const_int")
diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index d9736ea..81261a0 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -9610,13 +9610,15 @@ rs6000_expand_set_fpscr_rn_builtin (enum insn_code 
icode, tree exp)
  compile time if the argument is a variable.  The least significant two
  bits of the argument, regardless of type, are used to set the rounding
  mode.  All other bits are ignored.  */
-  if (CONST_INT_P (op0) && !const_0_to_3_operand(op0, VOIDmode))
+  if (CONST_INT_P (op0))
 {
-  error ("Argument must be a value between 0 and 3.");
-  return const0_rtx;
+  if (!const_0_to_3_operand (op0, VOIDmode))
+   {
+ error ("Argument must be a value between 0 and 3.");
+ return const0_rtx;
+   }
 }
-
-  if (! (*insn_data[icode].operand[0].predicate) (op0, mode0))
+  else if (! (*insn_data[icode].operand[0].predicate) (op0, mode0))
 op0 = copy_to_mode_reg (mode0, op0);

   pat = GEN_FCN (icode) (op0);
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 6bec2bd..291396c 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -177,6 +177,7 @@ (define_c_enum "unspecv"
UNSPECV_MFFS; Move from FPSCR
UNSPECV_MFFSL   ; Move from FPSCR light instruction version
UNSPECV_MFFSCRN ; Move from FPSCR float rounding mode
+   UNSPECV_MFFSCRNI; Move from FPSCR float rounding mode with imm
UNSPECV_MFFSCDRN; Move from FPSCR decimal float rounding mode
UNSPECV_MTFSF   ; Move to FPSCR Fields 8 to 15
UNSPECV_MTFSF_HI; Move to FPSCR Fields 0 to 7
@@ -6315,6 +6316,14 @@ (define_insn "rs6000_mffscrn"
"mffscrn %0,%1"
   [(set_attr "type" "fp")])

+(define_insn "rs6000_mffscrni"
+  [(set (match_operand:DF 0 "gpc_reg_operand" "=d")
+   (unspec_volatile:DF [(match_operand:DF 1 "u2bit_cint_operand" "n")]
+   UNSPECV_MFFSCRNI))]
+   "TARGET_P9_MISC"
+   "mffscrni %0,%1"
+  [(set_attr "type" "fp")])
+
 (define_insn "rs6000_mffscdrn"
   [(set (match_operand:DF 0 "gpc_reg_operand" "=d")
(unspec_volatile:DF [(const_int 0)] UNSPECV_MFFSCDRN))
@@ -6324,7 +6333,7 @@ (define_insn "rs6000_mffscdrn"
   [(set_attr "type" "fp")])

 (define_expand "rs6000_set_fpscr_rn"
- [(match_operand:DI 0 "reg_or_cint_operand")]
+ [(match_operand:SI 0 "reg_or_cint_operand")]
   "TARGET_HARD_FLOAT"
 {
   rtx tmp_df = gen_reg_rtx (DFmode);
@@ -6333,9 +6342,15 @@ (define_expand "rs6000_set_fpscr_rn"
  new rounding mode bits from operands[0][62:63] into FPSCR[62:63].  */
   if (TARGET_P9_MISC)
 {
-  rtx src_df = force_reg (DImode, operands[0]);
-  src_df = simplify_gen_subreg (DFmode, src_df, DImode, 0);
-  emit_insn (gen_rs6000_mffscrn (tmp_df, src_df));
+  if (CONST_INT_P (operands[0])
+ && const_0_to_3_operand (operands[0], VOIDmode))
+   emit_insn (gen_rs6000_mffscrni (tmp_df, operands[0]));
+  else
+   {
+  

Re: [RFC] Overflow check in simplifying exit cond comparing two IVs.

2021-12-16 Thread Jiufu Guo via Gcc-patches
Jiufu Guo  writes:

> Jiufu Guo  writes:
>
>> Richard Biener  writes:
>>
>>> On Mon, 18 Oct 2021, Jiufu Guo wrote:
>>>
 With reference the discussions in:
 https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574334.html
 https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572006.html
 https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578672.html
 
 Base on the patches in above discussion, we may draft a patch to fix the
 issue.
 
 In this patch, to make sure it is ok to change '{b0,s0} op {b1,s1}' to
 '{b0,s0-s1} op {b1,0}', we also compute the condition which could assume
 both 2 ivs are not overflow/wrap: the niter "of '{b0,s0-s1} op {b1,0}'"
 < the niter "of untill wrap for iv0 or iv1".
 
 Does this patch make sense?
>>>
>>> Hum, the patch is mightly complex :/  I'm not sure we can throw
>>> artficial IVs at number_of_iterations_cond and expect a meaningful
>>> result.
>>>
>>> ISTR the problem is with number_of_iterations_ne[_max], but I would
>>> have to go and dig in myself again for a full recap of the problem.
>>> I did plan to do that, but not before stage3 starts.
>>>
>>> Thanks,
>>> Richard.
>>
>> Hi Richard,
>>
>> Thanks for your comment!  It is really complex, using artificial IVs and
>> recursively calling number_of_iterations_cond.  We may use a simpler way.
>> Not sure if you had started to dig into the problem.  I refined a patch.
>> Hope this patch is helpful.  This patch enhances the conditions in some
>> aspects. Attached are two test cases that could be handled.
>
> Some questions, I want to consult here, it may help to make the patch
> works better.
>
> - 1. For signed type, I'm wondering if we could leverage the idea about
>   "UB on signed overflow" in the phase to call number_of_iterations_cond
>   where may be far from user source code.
>   If we can, we may just ignore the assumption for signed type.
>   But then, there would be inconsitent behavior between noopt(-O0) and
>   opt (e.g. -O2/-O3).  For example:
>   "{INT_MAX-124, +5} < {INT_MAX-27, +1}".
>   At -O0, the 'niter' would be 28; while, at -O3, it may result as 26.
>
> - 2. For NEQ, which you may also concern, the assumption
>   "delta % step == 0" would make it safe.  It seems current, we handle
>   NEQ where no_overflow is true for both iv0 and iv1.

For overflow behavior on signed, here is a case.  It runs a long time
when build with noopt.  At opt level (e.g. -O3), it runs end quickly,
and gets a number of iteration(25).

--
#define TYPE int
#define FUNC(NAME, CODE, S0, S1)   \
  TYPE __attribute__ ((noinline)) NAME (TYPE b0, TYPE b1)  \
  {\
__builtin_printf ("%s %d, %d\n", __FUNCTION__, b0, b1);\
TYPE n = 0;\
TYPE i0, i1;   \
for (i0 = b0, i1 = b1; i0 CODE i1; i0 += S0, i1 += S1) \
  n++; \
return n;  \
  }

FUNC (ne_4_0, !=, 4, 0);

int
main ()
{
  TYPE r = ne_4_0 (1000, 1103); /* b0 < b1, niter % s != 0 */
  __builtin_printf ("res: %ld\n", r);
  return r;  
}
--

If using unsinged for TYPE, it runs a long time, even build with -O3.
For unsigned, the assumption checking "delta % step == 0" is added.
While for signed, there is no assumption checking.  Here, signed
overflow is treated as UB.  And then with option -fwrapv, it also runs
a long time, since this option defines the behavior on overflow.
So, in some aspects, it seems reasonable for current behavior including
it returns a niter(25).
Then we may keep current behavior for questions 1 and 2.

Thanks for comments!

BR,
Jiufu

>
> - 3. In the current patch, DIV_EXPR is used, the cost may be high in
>   some cases.  I'm wondering if the below idea is workable:
>   Extent to longer type, and using MULT instead DIV, for example:
>   a < b/c ===> a*c < b.  a*c may be need to use longer type than 'a'.
>
> -- 3.1 For some special case, e.g. "{b0, 5} < {b1, -5}", the assumption
>may be able to simplied.  For general case, still thinking to reduce
>the runtime cost from assumption.
>
>
> Thanks again!
>
> BR,
> Jiufu
>
>>
>> ---
>>  gcc/tree-ssa-loop-niter.c | 92 +++
>>  .../gcc.c-torture/execute/pr100740.c  | 11 +++
>>  gcc/testsuite/gcc.dg/vect/pr102131.c  | 47 ++
>>  3 files changed, 134 insertions(+), 16 deletions(-)
>>  create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr100740.c
>>  create mode 100644 gcc/testsuite/gcc.dg/vect/pr102131.c
>>
>> diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
>> index 06954e437f5..ee1d7293c5c 100644
>> --- a/gcc/t

[PATCH, rs6000] new split pattern for TI to V1TI move [PR103124]

2021-12-16 Thread HAO CHEN GUI via Gcc-patches
Hi,
   This patch defines a new split pattern for TI to V1TI move. The pattern 
concatenates two subreg:DI of
a TI to a V2DI. With the pattern, the subreg pass can do register split for TI 
when there is a TI to V1TI
move. The patch optimizes one unnecessary "mr" out on P9. The new test case 
illustrates it.

   Bootstrapped and tested on powerpc64-linux BE and LE with no regressions. Is 
this okay for trunk?
Any recommendations? Thanks a lot.

ChangeLog
2021-12-13 Haochen Gui 

gcc/
* config/rs6000/vsx.md (split pattern for TI to V1TI move): Defined.

gcc/testsuite/
* gcc.target/powerpc/pr103124.c: New testcase.


patch.diff
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index bf033e31c1c..52968eb4609 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -6589,3 +6589,19 @@ (define_insn "xxeval"
[(set_attr "type" "vecperm")
 (set_attr "prefixed" "yes")])

+;; Construct V1TI by vsx_concat_v2di
+(define_split
+  [(set (match_operand:V1TI 0 "vsx_register_operand")
+   (subreg:V1TI
+ (match_operand:TI 1 "int_reg_operand") 0 ))]
+  "TARGET_P9_VECTOR && !reload_completed"
+  [(const_int 0)]
+{
+  rtx tmp1 = simplify_gen_subreg (DImode, operands[1], TImode, 0);
+  rtx tmp2 = simplify_gen_subreg (DImode, operands[1], TImode, 8);
+  rtx tmp3 = gen_reg_rtx (V2DImode);
+  emit_insn (gen_vsx_concat_v2di (tmp3, tmp1, tmp2));
+  rtx tmp4 = simplify_gen_subreg (V1TImode, tmp3, V2DImode, 0);
+  emit_move_insn (operands[0], tmp4);
+  DONE;
+})
diff --git a/gcc/testsuite/gcc.target/powerpc/pr103124.c 
b/gcc/testsuite/gcc.target/powerpc/pr103124.c
new file mode 100644
index 000..e9072d19b8e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr103124.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_p9vector_ok } */
+/* { dg-require-effective-target int128 } */
+/* { dg-options "-O2 -mdejagnu-cpu=power9" } */
+/* { dg-final { scan-assembler-not "\mmr\M" } } */
+
+vector __int128 add (long long a)
+{
+  vector __int128 b;
+  b = (vector __int128) {a};
+  return b;
+}



Re: [PATCH 1/3] loop-invariant: Don't move cold bb instructions to preheader in RTL

2021-12-16 Thread Xionghu Luo via Gcc-patches



On 2021/12/16 19:20, Jan Hubicka wrote:
>>  
>> OK. Comments like?
>>
>> /* Don't move insn of cold BB out of loop to preheader to reduce calculations
>>and register live range in hot loop with cold BB.  */
> 
> Looks good.
>>
>>
>> And maybe some dump log will help tracking in xxx.c.271r.loop2_invariant.
>>
>> --- a/gcc/loop-invariant.c
>> +++ b/gcc/loop-invariant.c
>> @@ -1190,7 +1190,12 @@ find_invariants_bb (class loop *loop, basic_block bb, 
>> bool always_reached,
>>basic_block preheader = loop_preheader_edge (loop)->src;
>>
>>if (preheader->count > bb->count)
>> -return;
>> +{
>> +  if (dump_file)
>> +   fprintf (dump_file, "Don't move invariant from bb: %d in loop %d\n",
>> +bb->index, loop->num);
>> +  return;
>> +}
> 
> This is also a good idea - testcases are quite important for this typo
> of stuff.
>>>
>>> Thinking about this more, you want to test:
>>>   if (!always_executed && preheader->count > bb->count)
>>> return;
>>> This will rule out some profile misupates.
>>>
>>> Also the code updating always_reached is worng:
>>>   if (always_reached
>>>   && CALL_P (insn)
>>>   && (RTL_LOOPING_CONST_OR_PURE_CALL_P (insn)
>>>   || ! RTL_CONST_OR_PURE_CALL_P (insn)))
>>>   always_reached = false;
>>> It misses the case where statement can trhow external exception or
>>> volatile asms that can also terminate execution.
>>>
>>> I bit worry on how often the test will have false positives with guessed
>>> profile where earlier loop optimizations reduced trip count below
>>> realistic estimate.
>>
>> Sorry I don't understand why always_executed and always_reached matters here?
>> the test is based on BB before the FOR_BB_INSNS loop...
> 
> always_executed is useful here to avoid the situation where bb->count or
> preheader->count is wrong and it would disable wanted transformation.
> 
> always_executed is just a bug I noticed while looking at the code.  I
> will produce testcase for bugzilla.
> 
> Honza


Thanks, so is this OK to commit now?  And any additional comments for
the "[PATCH 3/3] Fix loop split incorrect count and probability"
(https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586374.html)?
 

Updated comments and testcase:

[PATCH 1/3] loop-invariant: Don't move cold bb instructions to preheader in RTL

From: Xiong Hu Luo 

gcc/ChangeLog:

* loop-invariant.c (find_invariants_bb): Check profile count
before motion.
(find_invariants_body): Add argument.

gcc/testsuite/ChangeLog:

* gcc.dg/loop-invariant-2.c: New.
---
 gcc/loop-invariant.c| 17 ++---
 gcc/testsuite/gcc.dg/loop-invariant-2.c | 20 
 2 files changed, 34 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/loop-invariant-2.c

diff --git a/gcc/loop-invariant.c b/gcc/loop-invariant.c
index fca0c2b24be..690f7704a0b 100644
--- a/gcc/loop-invariant.c
+++ b/gcc/loop-invariant.c
@@ -1183,9 +1183,21 @@ find_invariants_insn (rtx_insn *insn, bool 
always_reached, bool always_executed)
call.  */
 
 static void
-find_invariants_bb (basic_block bb, bool always_reached, bool always_executed)
+find_invariants_bb (class loop *loop, basic_block bb, bool always_reached,
+   bool always_executed)
 {
   rtx_insn *insn;
+  basic_block preheader = loop_preheader_edge (loop)->src;
+
+  /* Don't move insn of cold BB out of loop to preheader to reduce calculations
+ and register live range in hot loop with cold BB.  */
+  if (!always_executed && preheader->count > bb->count)
+{
+  if (dump_file)
+   fprintf (dump_file, "Don't move invariant from bb: %d out of loop %d\n",
+bb->index, loop->num);
+  return;
+}
 
   FOR_BB_INSNS (bb, insn)
 {
@@ -1214,8 +1226,7 @@ find_invariants_body (class loop *loop, basic_block *body,
   unsigned i;
 
   for (i = 0; i < loop->num_nodes; i++)
-find_invariants_bb (body[i],
-   bitmap_bit_p (always_reached, i),
+find_invariants_bb (loop, body[i], bitmap_bit_p (always_reached, i),
bitmap_bit_p (always_executed, i));
 }
 
diff --git a/gcc/testsuite/gcc.dg/loop-invariant-2.c 
b/gcc/testsuite/gcc.dg/loop-invariant-2.c
new file mode 100644
index 000..df3d8458569
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/loop-invariant-2.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-rtl-loop2_invariant" } */
+
+volatile int x;
+void
+bar (int, char *, char *);
+void
+foo (int *a, int n, int k)
+{
+  int i;
+
+  for (i = 0; i < n; i++)
+{
+  if (__builtin_expect (x, 0))
+   bar (k / 5, "one", "two");
+  a[i] = k;
+}
+}
+
+/* { dg-final { scan-rtl-dump "Don't move invariant from bb: .*out of loop" 
"loop2_invariant" } } */
-- 
2.27.0.90.geebb51ba8c




Re: [PATCH] c++: Improve diagnostic for class tmpl/class redecl [PR103749]

2021-12-16 Thread Jason Merrill via Gcc-patches

On 12/16/21 17:36, Marek Polacek wrote:

For code like

   template
   struct bar;

   struct bar {
 int baz;
   };

   bar var;

we emit a fairly misleading and unwieldy diagnostic:

~
$ g++ -c u.cc
u.cc:6:8: error: template argument required for 'struct bar'
 6 | struct bar {
   |^~~
u.cc:10:5: error: class template argument deduction failed:
10 | bar var;
   | ^~~
u.cc:10:5: error: no matching function for call to 'bar()'
u.cc:3:17: note: candidate: 'template bar()-> bar<  
>'
 3 |   friend struct bar;
   | ^~~
u.cc:3:17: note:   template argument deduction/substitution failed:
u.cc:10:5: note:   couldn't deduce template parameter ''
10 | bar var;
   | ^~~
u.cc:3:17: note: candidate: 'template bar(bar<  >)-> bar< 
 >'
 3 |   friend struct bar;
   | ^~~
u.cc:3:17: note:   template argument deduction/substitution failed:
u.cc:10:5: note:   candidate expects 1 argument, 0 provided
10 | bar var;
   | ^~~
~

but with this patch we get:

~
z.C:6:8: error: 'bar' was declared as template but no template header provided
 6 | struct bar {
   |^~~
z.C:3:17: note: previous declaration here
 3 |   friend struct bar;
   | ^~~
z.C:10:5: error: 'bar<...auto...> var' has incomplete type
10 | bar var;
   | ^~~
~

which is clearer about what the problem is.

I thought it'd be nice to avoid printing the messages about failed CTAD,
too.  To that end, I'm using CLASSTYPE_ERRONEOUS to suppress CTAD.  Not
sure if that's entirely kosher.


A bit dubious, but error-recovery often is.  Let's go with it.


The other direction (first a non-template class declaration followed by
a class template definition) we handle quite well:

~
z.C:11:8: error: 'bar' is not a template
11 | struct bar {};
   |^~~
z.C:8:8: note: previous declaration here
 8 | struct bar;
   |^~~
~

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

PR c++/103749

gcc/cp/ChangeLog:

* decl.c (lookup_and_check_tag): Give an error when a class was
declared as template but no template header has been provided.
* pt.c (do_class_deduction): Don't deduce CLASSTYPE_ERRONEOUS
types.

gcc/testsuite/ChangeLog:

* g++.dg/template/redecl4.C: Adjust dg-error.
* g++.dg/diagnostic/redeclaration-2.C: New test.
---
  gcc/cp/decl.c | 11 +++
  gcc/cp/pt.c   |  7 +++
  .../g++.dg/diagnostic/redeclaration-2.C   | 19 +++
  gcc/testsuite/g++.dg/template/redecl4.C   |  2 +-
  4 files changed, 38 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/diagnostic/redeclaration-2.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 7ca8770bd02..56fa5b3ffeb 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -15438,6 +15438,17 @@ lookup_and_check_tag (enum tag_types tag_code, tree 
name,
return error_mark_node;
  }
  
+  if (DECL_CLASS_TEMPLATE_P (decl)

+  && !template_header_p
+  && how == TAG_how::CURRENT_ONLY)
+{
+  error ("%qD was declared as template but no template header provided",
+name);


Maybe "class template %qD redeclared as non-template" ?

OK with that change.


+  inform (location_of (decl), "previous declaration here");
+  CLASSTYPE_ERRONEOUS (TREE_TYPE (decl)) = true;
+  return error_mark_node;
+}
+
if (DECL_CLASS_TEMPLATE_P (decl)
/* If scope is TAG_how::CURRENT_ONLY we're defining a class,
 so ignore a template template parameter.  */
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 18c6f118ae6..4f0ae6d5851 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29601,6 +29601,13 @@ do_class_deduction (tree ptype, tree tmpl, tree init,
if (DECL_TEMPLATE_TEMPLATE_PARM_P (tmpl))
  return ptype;
  
+  /* If the class was erroneous, don't try to deduce, because that

+ can generate a lot of diagnostic.  */
+  if (TREE_TYPE (tmpl)
+  && TYPE_LANG_SPECIFIC (TREE_TYPE (tmpl))
+  && CLASSTYPE_ERRONEOUS (TREE_TYPE (tmpl)))
+return ptype;
+
/* Wait until the enclosing scope is non-dependent.  */
if (DECL_CLASS_SCOPE_P (tmpl)
&& dependent_type_p (DECL_CONTEXT (tmpl)))
diff --git a/gcc/testsuite/g++.dg/diagnostic/redeclaration-2.C 
b/gcc/testsuite/g++.dg/diagnostic/redeclaration-2.C
new file mode 100644
index 000..ac14c2c135f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/diagnostic/redeclaration-2.C
@@ -0,0 +1,19 @@
+// PR c++/103749
+
+struct foo {
+  template
+  friend struct bar;
+};
+
+struct bar { // { dg-er

Re: [PATCH v2] attribs: Fix wrong error with -Wno-attribute=A::b [PR103649]

2021-12-16 Thread Jason Merrill via Gcc-patches

On 12/16/21 19:52, Marek Polacek wrote:

On Thu, Dec 16, 2021 at 11:53:46PM +0100, Jakub Jelinek wrote:

On Thu, Dec 16, 2021 at 05:35:55PM -0500, Marek Polacek wrote:

My patch to implement -Wno-attribute=A::b caused a bogus error when
parsing

   [[foo::bar(1, 2)]];

when -Wno-attributes=foo::bar was specified on the command line, because
when we create a fake foo::bar attribute and insert it into our attribute
table, it is created with max_length == 0 which doesn't allow any args.
That is wrong -- we know nothing about the attribute, so we shouldn't
require any specific number of arguments.

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

PR c/103649

gcc/ChangeLog:

* attribs.c (handle_ignored_attributes_option): Create the fake
attribute with max_length == -1.

gcc/testsuite/ChangeLog:

* c-c++-common/Wno-attributes-6.c: New test.


I'm afraid this still changes behavior.  0, -1 range attribute arguments
are parsed normally, while unknown attributes have the balanced token
sequence skipped.
E.g. the omp::{directive,sequence} attribute arguments are much more complex
than what the normal parsing can handle.
Can you make max -2 instead and special case it in the C and C++ FE
attribute handling and in a testcase try something that is a balanced token
sequence but not really valid when parsed as ordinary attributes' arguments?


Ah I see what you mean now.  Fixed here, thanks.

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

-- >8 --
My patch to implement -Wno-attribute=A::b caused a bogus error when
parsing

   [[foo::bar(1, 2)]];

when -Wno-attributes=foo::bar was specified on the command line, because
when we create a fake foo::bar attribute and insert it into our attribute
table, it is created with max_length == 0 which doesn't allow any args.
That is wrong -- we know nothing about the attribute, so we shouldn't
require any specific number of arguments.  And since unknown attributes
can be rather complex (see for example omp::{directive,sequence}), we
must skip parsing their arguments.  To that end, I'm using max_length
with value -2.

PR c/103649

gcc/ChangeLog:

* attribs.c (handle_ignored_attributes_option): Create the fake
attribute with max_length == -2.
* tree-core.h (struct attribute_spec): Document that max_length
can be -2.

gcc/c/ChangeLog:

* c-parser.c (c_parser_std_attribute): Skip parsing of the attribute
arguments when max_length == -2.

gcc/cp/ChangeLog:

* parser.c (cp_parser_std_attribute): Skip parsing of the attribute
arguments when max_length == -2.

gcc/testsuite/ChangeLog:

* c-c++-common/Wno-attributes-6.c: New test.
---
  gcc/attribs.c |  2 +-
  gcc/c/c-parser.c  |  4 +++-
  gcc/cp/parser.c   |  4 +++-
  gcc/testsuite/c-c++-common/Wno-attributes-6.c | 14 ++
  gcc/tree-core.h   |  4 +++-
  5 files changed, 24 insertions(+), 4 deletions(-)
  create mode 100644 gcc/testsuite/c-c++-common/Wno-attributes-6.c

diff --git a/gcc/attribs.c b/gcc/attribs.c
index 29703e75fba..6af7f93e61c 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -304,7 +304,7 @@ handle_ignored_attributes_option (vec *v)
 We can't free it here, so squirrel away the pointers.  */
attribute_spec *table = new attribute_spec[2];
ignored_attributes_table.safe_push (table);
-  table[0] = { attr, 0, 0, false, false, false, false, nullptr, nullptr };
+  table[0] = { attr, 0, -2, false, false, false, false, nullptr, nullptr };
table[1] = { nullptr, 0, 0, false, false, false, false, nullptr,
   nullptr };
register_scoped_attributes (table, IDENTIFIER_POINTER (vendor_id), 
!attr);
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index d7e5f051ac0..c9068bdbb8a 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -4943,7 +4943,9 @@ c_parser_std_attribute (c_parser *parser, bool for_tm)
parens.skip_until_found_close (parser);
return error_mark_node;
}
-if (as)
+/* When MAX_LENGTH is -2, this is a fake attribute created to
+   handle -Wno-attributes, and we must skip parsing the arguments.  */
+if (as && as->max_length != -2)
{
bool takes_identifier
  = (ns != NULL_TREE
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 44eed7ea638..763d74eaf6c 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -28979,7 +28979,9 @@ cp_parser_std_attribute (cp_parser *parser, tree 
attr_ns)
/* A GNU attribute that takes an identifier in parameter.  */
attr_flag = id_attr;
  
-if (as == NULL)

+/* When MAX_LENGTH is -2, this is a fake attribute created to
+   handle -Wno-attributes, and we must skip parsing the arguments.  */
+if (as == NULL || as->max_length == -2)
{
if ((flag_openmp || flag_openmp_sim

[PATCH v2] attribs: Fix wrong error with -Wno-attribute=A::b [PR103649]

2021-12-16 Thread Marek Polacek via Gcc-patches
On Thu, Dec 16, 2021 at 11:53:46PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 16, 2021 at 05:35:55PM -0500, Marek Polacek wrote:
> > My patch to implement -Wno-attribute=A::b caused a bogus error when
> > parsing
> > 
> >   [[foo::bar(1, 2)]];
> > 
> > when -Wno-attributes=foo::bar was specified on the command line, because
> > when we create a fake foo::bar attribute and insert it into our attribute
> > table, it is created with max_length == 0 which doesn't allow any args.
> > That is wrong -- we know nothing about the attribute, so we shouldn't
> > require any specific number of arguments.
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > PR c/103649
> > 
> > gcc/ChangeLog:
> > 
> > * attribs.c (handle_ignored_attributes_option): Create the fake
> > attribute with max_length == -1.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * c-c++-common/Wno-attributes-6.c: New test.
> 
> I'm afraid this still changes behavior.  0, -1 range attribute arguments
> are parsed normally, while unknown attributes have the balanced token
> sequence skipped.
> E.g. the omp::{directive,sequence} attribute arguments are much more complex
> than what the normal parsing can handle.
> Can you make max -2 instead and special case it in the C and C++ FE
> attribute handling and in a testcase try something that is a balanced token
> sequence but not really valid when parsed as ordinary attributes' arguments?

Ah I see what you mean now.  Fixed here, thanks.

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

-- >8 --
My patch to implement -Wno-attribute=A::b caused a bogus error when
parsing

  [[foo::bar(1, 2)]];

when -Wno-attributes=foo::bar was specified on the command line, because
when we create a fake foo::bar attribute and insert it into our attribute
table, it is created with max_length == 0 which doesn't allow any args.
That is wrong -- we know nothing about the attribute, so we shouldn't
require any specific number of arguments.  And since unknown attributes
can be rather complex (see for example omp::{directive,sequence}), we
must skip parsing their arguments.  To that end, I'm using max_length
with value -2.

PR c/103649

gcc/ChangeLog:

* attribs.c (handle_ignored_attributes_option): Create the fake
attribute with max_length == -2.
* tree-core.h (struct attribute_spec): Document that max_length
can be -2.

gcc/c/ChangeLog:

* c-parser.c (c_parser_std_attribute): Skip parsing of the attribute
arguments when max_length == -2.

gcc/cp/ChangeLog:

* parser.c (cp_parser_std_attribute): Skip parsing of the attribute
arguments when max_length == -2.

gcc/testsuite/ChangeLog:

* c-c++-common/Wno-attributes-6.c: New test.
---
 gcc/attribs.c |  2 +-
 gcc/c/c-parser.c  |  4 +++-
 gcc/cp/parser.c   |  4 +++-
 gcc/testsuite/c-c++-common/Wno-attributes-6.c | 14 ++
 gcc/tree-core.h   |  4 +++-
 5 files changed, 24 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/Wno-attributes-6.c

diff --git a/gcc/attribs.c b/gcc/attribs.c
index 29703e75fba..6af7f93e61c 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -304,7 +304,7 @@ handle_ignored_attributes_option (vec *v)
 We can't free it here, so squirrel away the pointers.  */
   attribute_spec *table = new attribute_spec[2];
   ignored_attributes_table.safe_push (table);
-  table[0] = { attr, 0, 0, false, false, false, false, nullptr, nullptr };
+  table[0] = { attr, 0, -2, false, false, false, false, nullptr, nullptr };
   table[1] = { nullptr, 0, 0, false, false, false, false, nullptr,
   nullptr };
   register_scoped_attributes (table, IDENTIFIER_POINTER (vendor_id), 
!attr);
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index d7e5f051ac0..c9068bdbb8a 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -4943,7 +4943,9 @@ c_parser_std_attribute (c_parser *parser, bool for_tm)
parens.skip_until_found_close (parser);
return error_mark_node;
   }
-if (as)
+/* When MAX_LENGTH is -2, this is a fake attribute created to
+   handle -Wno-attributes, and we must skip parsing the arguments.  */
+if (as && as->max_length != -2)
   {
bool takes_identifier
  = (ns != NULL_TREE
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 44eed7ea638..763d74eaf6c 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -28979,7 +28979,9 @@ cp_parser_std_attribute (cp_parser *parser, tree 
attr_ns)
   /* A GNU attribute that takes an identifier in parameter.  */
   attr_flag = id_attr;
 
-if (as == NULL)
+/* When MAX_LENGTH is -2, this is a fake attribute created to
+   handle -Wno-attributes, and we must skip parsing the arguments.  */
+if (as == NULL || as->max_length == -2)
   {
if ((

[r12-6022 Regression] FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2b (internal compiler error: tree check: expected none of template_decl, have template_decl in add_specializations, at cp/module.cc

2021-12-16 Thread sunil.k.pandey via Gcc-patches
On Linux/x86_64,

bb2a7f80a98de3febefbb32b1e4898062bdb6af8 is the first bad commit
commit bb2a7f80a98de3febefbb32b1e4898062bdb6af8
Author: Patrick Palka 
Date:   Thu Dec 16 13:40:42 2021 -0500

c++: two-stage name lookup for overloaded operators [PR51577]

caused

FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi  
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (internal compiler error: 
tree check: expected var_decl or function_decl or field_decl or type_decl or 
concept_decl or template_decl, have namespace_decl in get_merge_kind, at 
cp/module.cc:10074)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (internal compiler error: 
tree check: expected var_decl or function_decl or field_decl or type_decl or 
concept_decl or template_decl, have namespace_decl in get_merge_kind, at 
cp/module.cc:10074)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (internal compiler error: 
tree check: expected var_decl or function_decl or field_decl or type_decl or 
concept_decl or template_decl, have namespace_decl in get_merge_kind, at 
cp/module.cc:10074)
FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_a.H module-cmi  
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-5_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++17 (internal compiler error: 
tree check: expected none of template_decl, have template_decl in 
add_specializations, at cp/module.cc:12968)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2a (internal compiler error: 
tree check: expected none of template_decl, have template_decl in 
add_specializations, at cp/module.cc:12968)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2b (internal compiler error: 
tree check: expected none of template_decl, have template_decl in 
add_specializations, at cp/module.cc:12968)
FAIL: g++.dg/modules/xtreme-header-5_a.H -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_a.H module-cmi  
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header_a.H.gcm)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++17 (internal compiler error: 
tree check: expected none of template_decl, have template_decl in 
add_specializations, at cp/module.cc:12968)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2a (internal compiler error: 
tree check: expected none of template_decl, have template_decl in 
add_specializations, at cp/module.cc:12968)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2b (internal compiler error: 
tree check: expected none of template_decl, have template_decl in 
add_specializations, at cp/module.cc:12968)
FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2b (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-6022/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="modules.exp=g++.dg/modules/xtreme-header-3_a.H 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="modules.exp=g++.dg/modules/xtreme-header-3_a.H 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="modules.exp=g++.dg/modules/xtreme-header-3_a.H 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="modules.exp=g++.dg/modules/xtreme-header-3_a.H 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="modules.exp=g++.dg/modules/xtreme-header-5_a.H 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="modules.exp=g++.dg/modules/xtreme-header-5_a.H 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="modules.exp=g++.dg/modules/xtreme-header_a.H 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="modules.exp=g++.dg/modules/xtreme-header_a.H 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)


[committed] Testsuite: Tweak gcc.dg/20021029-1.c for nios2.

2021-12-16 Thread Sandra Loosemore
I've checked in the attached patch to fix a testcase that's been failing 
on nios2 for a while.


-Sandra
commit 840a22e0fee9e7369a2eb1c9e3c70dcae24a20e4
Author: Sandra Loosemore 
Date:   Thu Dec 16 15:17:14 2021 -0800

Testsuite: Tweak gcc.dg/20021029-1.c for nios2.

This test needs to be built with -G0 on nios2 to avoid treating the array
as small data.

2021-12-16  Sandra Loosemore  

	gcc/testsuite/
	* gcc.dg/20021029-1.c: Build with -G0 for nios2.

diff --git a/gcc/testsuite/gcc.dg/20021029-1.c b/gcc/testsuite/gcc.dg/20021029-1.c
index d13f669..f5ddecb 100644
--- a/gcc/testsuite/gcc.dg/20021029-1.c
+++ b/gcc/testsuite/gcc.dg/20021029-1.c
@@ -2,6 +2,7 @@
variables into writable sections.  */
 /* { dg-do compile { target fpic } } */
 /* { dg-options "-O2 -fpic" } */
+/* { dg-additional-options "-G0" { target nios2-*-* } }  */
 /* { dg-final { scan-assembler-not ".data.rel.ro.local" } } */
 /* { dg-final { scan-assembler-symbol-section {^_?ar} {^\.(const|rodata)|\[RO\]} } } */
 /* { dg-require-effective-target label_values } */


[PATCH] config: Add check whether D compiler works (PR103528)

2021-12-16 Thread Iain Buclaw via Gcc-patches
Hi,

This patch extends AC_PROG_GDC so that as well as checking for the
existence of a GDC compiler, also validate that it has also been built
with libphobos, otherwise warn or fail with the message that GDC is
required to build d.

Tested on a system running powerpcle-linux both without a D compiler,
and with a D compiler configured with --disable-libphobos.

This would also help with Solaris and Darwin ports, where support for
both D and runtime isn't present across all current releases. 

OK for mainline?

Regards,
Iain
---
config/ChangeLog:

PR d/103528
* acx.m4 (ACX_PROG_GDC): Add check whether D compiler works.

ChangeLog:

* configure: Regenerate.
---
 config/acx.m4 | 13 +
 configure | 19 +++
 2 files changed, 32 insertions(+)

diff --git a/config/acx.m4 b/config/acx.m4
index 3c65d820628..b86c4f9e51d 100644
--- a/config/acx.m4
+++ b/config/acx.m4
@@ -425,7 +425,20 @@ AC_DEFUN([ACX_PROG_GDC],
 [AC_REQUIRE([AC_CHECK_TOOL_PREFIX])
 AC_REQUIRE([AC_PROG_CC])
 AC_CHECK_TOOL(GDC, gdc, no)
+AC_CACHE_CHECK([whether the D compiler works],
+acx_cv_d_compiler_works,
+[cat >conftest.d <&1 || echo failure`
+  if test x"$errors" = x && test -f conftest.$ac_objext; then
+acx_cv_d_compiler_works=yes
+  fi
+  rm -f conftest.*
+fi])
+if test "x$GDC" != xno && test x$acx_cv_d_compiler_works != xno; then
   have_gdc=yes
 else
   have_gdc=no
diff --git a/configure b/configure
index 7f619d24ec5..869c654ea71 100755
--- a/configure
+++ b/configure
@@ -5721,7 +5721,26 @@ else
   GDC="$ac_cv_prog_GDC"
 fi
 
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the D compiler 
works" >&5
+$as_echo_n "checking whether the D compiler works... " >&6; }
+if ${acx_cv_d_compiler_works+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  cat >conftest.d <&1 || echo failure`
+  if test x"$errors" = x && test -f conftest.$ac_objext; then
+acx_cv_d_compiler_works=yes
+  fi
+  rm -f conftest.*
+fi
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $acx_cv_d_compiler_works" >&5
+$as_echo "$acx_cv_d_compiler_works" >&6; }
+if test "x$GDC" != xno && test x$acx_cv_d_compiler_works != xno; then
   have_gdc=yes
 else
   have_gdc=no
-- 
2.32.0



Re: [PATCH] attribs: Fix wrong error with -Wno-attribute=A::b [PR103649]

2021-12-16 Thread Jakub Jelinek via Gcc-patches
On Thu, Dec 16, 2021 at 05:35:55PM -0500, Marek Polacek wrote:
> My patch to implement -Wno-attribute=A::b caused a bogus error when
> parsing
> 
>   [[foo::bar(1, 2)]];
> 
> when -Wno-attributes=foo::bar was specified on the command line, because
> when we create a fake foo::bar attribute and insert it into our attribute
> table, it is created with max_length == 0 which doesn't allow any args.
> That is wrong -- we know nothing about the attribute, so we shouldn't
> require any specific number of arguments.
> 
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> 
>   PR c/103649
> 
> gcc/ChangeLog:
> 
>   * attribs.c (handle_ignored_attributes_option): Create the fake
>   attribute with max_length == -1.
> 
> gcc/testsuite/ChangeLog:
> 
>   * c-c++-common/Wno-attributes-6.c: New test.

I'm afraid this still changes behavior.  0, -1 range attribute arguments
are parsed normally, while unknown attributes have the balanced token
sequence skipped.
E.g. the omp::{directive,sequence} attribute arguments are much more complex
than what the normal parsing can handle.
Can you make max -2 instead and special case it in the C and C++ FE
attribute handling and in a testcase try something that is a balanced token
sequence but not really valid when parsed as ordinary attributes' arguments?

> --- a/gcc/attribs.c
> +++ b/gcc/attribs.c
> @@ -304,7 +304,7 @@ handle_ignored_attributes_option (vec *v)
>We can't free it here, so squirrel away the pointers.  */
>attribute_spec *table = new attribute_spec[2];
>ignored_attributes_table.safe_push (table);
> -  table[0] = { attr, 0, 0, false, false, false, false, nullptr, nullptr 
> };
> +  table[0] = { attr, 0, -1, false, false, false, false, nullptr, nullptr 
> };
>table[1] = { nullptr, 0, 0, false, false, false, false, nullptr,
>  nullptr };
>register_scoped_attributes (table, IDENTIFIER_POINTER (vendor_id), 
> !attr);
> diff --git a/gcc/testsuite/c-c++-common/Wno-attributes-6.c 
> b/gcc/testsuite/c-c++-common/Wno-attributes-6.c
> new file mode 100644
> index 000..02cdaaa1e89
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/Wno-attributes-6.c
> @@ -0,0 +1,9 @@
> +/* PR c/103649 */
> +/* { dg-do compile { target { c || c++11 } } } */
> +/* { dg-additional-options "-Wno-attributes=foo::bar" } */
> +/* { dg-additional-options "-Wno-attributes=baz::" } */
> +
> +[[foo::bar(1, 2)]]; /* { dg-warning "attribute ignored" } */
> +[[baz::bar(1, 2)]]; /* { dg-warning "attribute ignored" } */
> +[[foo::bar(1, 2)]] void f1();
> +[[baz::bar(1, 2)]] void f2();
> 
> base-commit: f91814c22595e1db642140efe030caf2c092ab6f
> -- 
> 2.33.1

Jakub



[PATCH] c++: Improve diagnostic for class tmpl/class redecl [PR103749]

2021-12-16 Thread Marek Polacek via Gcc-patches
For code like

  template
  struct bar;

  struct bar {
int baz;
  };

  bar var;

we emit a fairly misleading and unwieldy diagnostic:

~
$ g++ -c u.cc
u.cc:6:8: error: template argument required for 'struct bar'
6 | struct bar {
  |^~~
u.cc:10:5: error: class template argument deduction failed:
   10 | bar var;
  | ^~~
u.cc:10:5: error: no matching function for call to 'bar()'
u.cc:3:17: note: candidate: 'template bar()-> bar< 
 >'
3 |   friend struct bar;
  | ^~~
u.cc:3:17: note:   template argument deduction/substitution failed:
u.cc:10:5: note:   couldn't deduce template parameter ''
   10 | bar var;
  | ^~~
u.cc:3:17: note: candidate: 'template bar(bar<  
>)-> bar<  >'
3 |   friend struct bar;
  | ^~~
u.cc:3:17: note:   template argument deduction/substitution failed:
u.cc:10:5: note:   candidate expects 1 argument, 0 provided
   10 | bar var;
  | ^~~
~

but with this patch we get:

~
z.C:6:8: error: 'bar' was declared as template but no template header provided
6 | struct bar {
  |^~~
z.C:3:17: note: previous declaration here
3 |   friend struct bar;
  | ^~~
z.C:10:5: error: 'bar<...auto...> var' has incomplete type
   10 | bar var;
  | ^~~
~

which is clearer about what the problem is.

I thought it'd be nice to avoid printing the messages about failed CTAD,
too.  To that end, I'm using CLASSTYPE_ERRONEOUS to suppress CTAD.  Not
sure if that's entirely kosher.

The other direction (first a non-template class declaration followed by
a class template definition) we handle quite well:

~
z.C:11:8: error: 'bar' is not a template
   11 | struct bar {};
  |^~~
z.C:8:8: note: previous declaration here
8 | struct bar;
  |^~~
~

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

PR c++/103749

gcc/cp/ChangeLog:

* decl.c (lookup_and_check_tag): Give an error when a class was
declared as template but no template header has been provided.
* pt.c (do_class_deduction): Don't deduce CLASSTYPE_ERRONEOUS
types.

gcc/testsuite/ChangeLog:

* g++.dg/template/redecl4.C: Adjust dg-error.
* g++.dg/diagnostic/redeclaration-2.C: New test.
---
 gcc/cp/decl.c | 11 +++
 gcc/cp/pt.c   |  7 +++
 .../g++.dg/diagnostic/redeclaration-2.C   | 19 +++
 gcc/testsuite/g++.dg/template/redecl4.C   |  2 +-
 4 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/diagnostic/redeclaration-2.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 7ca8770bd02..56fa5b3ffeb 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -15438,6 +15438,17 @@ lookup_and_check_tag (enum tag_types tag_code, tree 
name,
   return error_mark_node;
 }
 
+  if (DECL_CLASS_TEMPLATE_P (decl)
+  && !template_header_p
+  && how == TAG_how::CURRENT_ONLY)
+{
+  error ("%qD was declared as template but no template header provided",
+name);
+  inform (location_of (decl), "previous declaration here");
+  CLASSTYPE_ERRONEOUS (TREE_TYPE (decl)) = true;
+  return error_mark_node;
+}
+
   if (DECL_CLASS_TEMPLATE_P (decl)
   /* If scope is TAG_how::CURRENT_ONLY we're defining a class,
 so ignore a template template parameter.  */
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 18c6f118ae6..4f0ae6d5851 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29601,6 +29601,13 @@ do_class_deduction (tree ptype, tree tmpl, tree init,
   if (DECL_TEMPLATE_TEMPLATE_PARM_P (tmpl))
 return ptype;
 
+  /* If the class was erroneous, don't try to deduce, because that
+ can generate a lot of diagnostic.  */
+  if (TREE_TYPE (tmpl)
+  && TYPE_LANG_SPECIFIC (TREE_TYPE (tmpl))
+  && CLASSTYPE_ERRONEOUS (TREE_TYPE (tmpl)))
+return ptype;
+
   /* Wait until the enclosing scope is non-dependent.  */
   if (DECL_CLASS_SCOPE_P (tmpl)
   && dependent_type_p (DECL_CONTEXT (tmpl)))
diff --git a/gcc/testsuite/g++.dg/diagnostic/redeclaration-2.C 
b/gcc/testsuite/g++.dg/diagnostic/redeclaration-2.C
new file mode 100644
index 000..ac14c2c135f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/diagnostic/redeclaration-2.C
@@ -0,0 +1,19 @@
+// PR c++/103749
+
+struct foo {
+  template
+  friend struct bar;
+};
+
+struct bar { // { dg-error "declared as template" }
+  int baz;
+};
+
+template
+struct T; // { dg-message "previous" }
+
+struct T { // { dg-error "declared as template" }
+};
+
+bar var; // { dg-error "" }
+T t; // { dg-error "" }
diff --git a/gcc/testsuite/

[PATCH] attribs: Fix wrong error with -Wno-attribute=A::b [PR103649]

2021-12-16 Thread Marek Polacek via Gcc-patches
My patch to implement -Wno-attribute=A::b caused a bogus error when
parsing

  [[foo::bar(1, 2)]];

when -Wno-attributes=foo::bar was specified on the command line, because
when we create a fake foo::bar attribute and insert it into our attribute
table, it is created with max_length == 0 which doesn't allow any args.
That is wrong -- we know nothing about the attribute, so we shouldn't
require any specific number of arguments.

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

PR c/103649

gcc/ChangeLog:

* attribs.c (handle_ignored_attributes_option): Create the fake
attribute with max_length == -1.

gcc/testsuite/ChangeLog:

* c-c++-common/Wno-attributes-6.c: New test.
---
 gcc/attribs.c | 2 +-
 gcc/testsuite/c-c++-common/Wno-attributes-6.c | 9 +
 2 files changed, 10 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/c-c++-common/Wno-attributes-6.c

diff --git a/gcc/attribs.c b/gcc/attribs.c
index 29703e75fba..4933f020f1a 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -304,7 +304,7 @@ handle_ignored_attributes_option (vec *v)
 We can't free it here, so squirrel away the pointers.  */
   attribute_spec *table = new attribute_spec[2];
   ignored_attributes_table.safe_push (table);
-  table[0] = { attr, 0, 0, false, false, false, false, nullptr, nullptr };
+  table[0] = { attr, 0, -1, false, false, false, false, nullptr, nullptr };
   table[1] = { nullptr, 0, 0, false, false, false, false, nullptr,
   nullptr };
   register_scoped_attributes (table, IDENTIFIER_POINTER (vendor_id), 
!attr);
diff --git a/gcc/testsuite/c-c++-common/Wno-attributes-6.c 
b/gcc/testsuite/c-c++-common/Wno-attributes-6.c
new file mode 100644
index 000..02cdaaa1e89
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/Wno-attributes-6.c
@@ -0,0 +1,9 @@
+/* PR c/103649 */
+/* { dg-do compile { target { c || c++11 } } } */
+/* { dg-additional-options "-Wno-attributes=foo::bar" } */
+/* { dg-additional-options "-Wno-attributes=baz::" } */
+
+[[foo::bar(1, 2)]]; /* { dg-warning "attribute ignored" } */
+[[baz::bar(1, 2)]]; /* { dg-warning "attribute ignored" } */
+[[foo::bar(1, 2)]] void f1();
+[[baz::bar(1, 2)]] void f2();

base-commit: f91814c22595e1db642140efe030caf2c092ab6f
-- 
2.33.1



Re: [patch] Fix PR libfortran/95177, ctype.h functions should not be called with char arguments

2021-12-16 Thread FX via Gcc-patches
Hi Harald,

I’m not on the list for now, please keep me in CC so I don’t miss replies. 
Thought it feels nice to be working on gfortran again :)


> However, I am wondering if calling the macros safe_* gives a false
> impression of what they actually do.  The cases where they are used
> with your patch applied seem sane, for now, though.

I thought about that, it’s not really “safer” than the underlying C library 
obviously. I couldn’t find a better name, but I’ll wait before I commit so 
others can suggest something else.

unrelated PS: I’ve been thinking aloud and benchmarking faster integer I/O for 
libgfortran at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076
Comments are welcome on the proposed design, I think the current proposal is a 
low-hanging fruit (not risky, much faster).


Best,

FX

Re: [PATCH v4 1/6] tree-object-size: Use trees and support negative offsets

2021-12-16 Thread Jakub Jelinek via Gcc-patches
On Fri, Dec 17, 2021 at 12:26:56AM +0530, Siddhesh Poyarekar wrote:
> On 12/16/21 21:19, Jakub Jelinek wrote:
> > Yes, but please fix up formatting, wholeval should go below old_wholeval.
> > Though, perhaps it would be better to:
> > 
> >if (tree_int_cst_compare (oldval, val))
> >  return true;
> > 
> >gcc_checking_assert (tree_int_cst_compare (old_wholeval, wholeval) == 0);
> >return false;
> > 
> > Ok with that change.
> > 
> > Jakub
> > 
> 
> I thought about this some more and I think I'm wrong in assuming that
> wholeval won't change in subsequent passes; my tests show I'm wrong too.
> I'm now testing with the condition fixed up to:
> 
>   return (tree_int_cst_compare (oldval, val) != 0
> || tree_int_cst_compare (old_wholeval, wholeval) != 0);
> 
> as you had suggested earlier and will push it if it passes bootstrap and a
> clean testsuite run.  I'm doing a ubsan bootstrap too because it's been
> quite useful in catching corner cases in __bos before.

Ok.

Jakub



Re: [PATCH] c++: delayed noexcept in member function template [PR99980]

2021-12-16 Thread Jason Merrill via Gcc-patches

On 12/16/21 11:00, Marek Polacek wrote:

Some time ago I noticed that we don't properly delay parsing of
noexcept for member function templates.  This patch fixes that.

It didn't work because even though we set CP_PARSER_FLAGS_DELAY_NOEXCEPT
in cp_parser_member_declaration, member template declarations take
a different path: we call cp_parser_template_declaration and return
prior to setting the flag.

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


OK.


PR c++/99980

gcc/cp/ChangeLog:

* parser.c (cp_parser_single_declaration): Maybe pass
CP_PARSER_FLAGS_DELAY_NOEXCEPT down to cp_parser_init_declarator.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept71.C: New test.
---
  gcc/cp/parser.c |  7 +-
  gcc/testsuite/g++.dg/cpp0x/noexcept71.C | 31 +
  2 files changed, 37 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept71.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index c2564e51e41..c19e5f1359d 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -31673,8 +31673,13 @@ cp_parser_single_declaration (cp_parser* parser,
&& (cp_lexer_next_token_is_not (parser->lexer, CPP_SEMICOLON)
  || decl_specifiers.type != error_mark_node))
  {
+  int flags = CP_PARSER_FLAGS_TYPENAME_OPTIONAL;
+  /* We don't delay parsing for friends, though CWG 2510 may change
+that.  */
+  if (member_p && !(friend_p && *friend_p))
+   flags |= CP_PARSER_FLAGS_DELAY_NOEXCEPT;
decl = cp_parser_init_declarator (parser,
-   CP_PARSER_FLAGS_TYPENAME_OPTIONAL,
+   flags,
&decl_specifiers,
checks,
/*function_definition_allowed_p=*/true,
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept71.C 
b/gcc/testsuite/g++.dg/cpp0x/noexcept71.C
new file mode 100644
index 000..361d6ad7b60
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept71.C
@@ -0,0 +1,31 @@
+// PR c++/99980
+// { dg-do compile { target c++11 } }
+
+#define SA(X) static_assert(X, #X)
+
+struct S {
+  template
+  void f(T) noexcept(B);
+
+  struct N {
+template
+void f2(T) noexcept(B);
+  };
+
+  static constexpr bool B = true;
+};
+
+S s;
+SA(noexcept(s.f(10)));
+S::N n;
+SA(noexcept(n.f2(10)));
+
+struct Bad {
+  template
+  using U = void() noexcept(B); // { dg-error "not declared" }
+
+  template
+  friend void friendo() noexcept(B); // { dg-error "not declared" }
+
+  static constexpr bool B = true;
+};

base-commit: 41cc28405c74a5ec59c6725274aaedefa9ca5887




Re: [PATCH] c++: nested lambda capturing a capture proxy, part 2 [PR94376]

2021-12-16 Thread Jason Merrill via Gcc-patches

On 12/16/21 11:28, Patrick Palka wrote:

On Wed, 15 Dec 2021, Jason Merrill wrote:


On 12/15/21 15:36, Patrick Palka wrote:

The r12-5403 fix apparently doesn't handle the case where the inner
lambda explicitly rather implicitly captures the capture proxy from
the outer lambda, and so we still reject the first example in the
testcase below.

The reason is that compared to an implicit capture, the effective
initializer for an explicit capture is wrapped in a location wrapper
(pointing to the source location of the explicit capture), and this
wrapper foils the is_capture_proxy check.  The simplest fix appears to
be to strip location wrappers accordingly.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

PR c++/94376

gcc/cp/ChangeLog:

* lambda.c (lambda_capture_field_type): Strip location wrappers
before checking for a capture proxy.


I think either is_capture_proxy should strip location wrappers or
gcc_checking_assert that it doesn't see one.


Good idea, here's v2 which adds an assert to is_capture_proxy.  Only one
other caller, mark_const_cap_r, had to be adjusted.


OK.


-- >8 --

The r12-5403 fix apparently doesn't handle the case where the inner
lambda explicitly rather implicitly captures the capture proxy from
the outer lambda, which causes us to reject the first example in the
testcase below.

This is because compared to an implicit capture, the effective initializer
for an explicit capture is wrapped in a location wrapper (pointing to the
capture list), and this wrapper foils the is_capture_proxy check added in
r12-5403.

The simplest fix appears to be to strip location wrappers accordingly
before checking is_capture_proxy.  To help prevent against other
occurrences of this kind of bug, this patch also makes is_capture_proxy
assert it doesn't see a location wrapper.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

PR c++/94376

gcc/cp/ChangeLog:

* lambda.c (lambda_capture_field_type): Strip location wrappers
before checking for a capture proxy.
(is_capture_proxy): Assert that we don't see a location wrapper.
(mark_const_cap_r): Don't call is_constant_capture_proxy on a
location wrapper.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-nested9a.C: New test.
---
  gcc/cp/lambda.c   |  7 
  .../g++.dg/cpp0x/lambda/lambda-nested9a.C | 42 +++
  2 files changed, 49 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested9a.C

diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index c39a2bca416..d14e12c48f0 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -221,6 +221,7 @@ lambda_capture_field_type (tree expr, bool explicit_init_p,
  }
else
  {
+  STRIP_ANY_LOCATION_WRAPPER (expr);
if (!by_reference_p && is_capture_proxy (expr))
{
  /* When capturing by-value another capture proxy from an enclosing
@@ -246,6 +247,10 @@ lambda_capture_field_type (tree expr, bool explicit_init_p,
  bool
  is_capture_proxy (tree decl)
  {
+  /* Location wrappers should be stripped or otherwise handled by the
+ caller before using this predicate.  */
+  gcc_checking_assert (!location_wrapper_p (decl));
+
return (VAR_P (decl)
  && DECL_HAS_VALUE_EXPR_P (decl)
  && !DECL_ANON_UNION_VAR_P (decl)
@@ -1496,6 +1501,8 @@ mark_const_cap_r (tree *t, int *walk_subtrees, void *data)
  *walk_subtrees = 0;
}
  }
+  else if (location_wrapper_p (*t))
+/* is_capture_proxy dislikes location wrappers.  */;
else if (is_constant_capture_proxy (*t))
  var = DECL_CAPTURED_VARIABLE (*t);
  
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested9a.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested9a.C

new file mode 100644
index 000..d62f8f0c952
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested9a.C
@@ -0,0 +1,42 @@
+// PR c++/94376
+// Like lambda-nested9.C but using explicit captures in the inner lambda.
+// { dg-do compile { target c++11 } }
+
+int main() {
+  // We used to incorrectly reject the first two cases.
+  int i = 0;
+  [=] () {
+[i] () mutable {
+  ++i;
+};
+  };
+
+#if __cpp_init_captures
+  [j=0] () {
+[j] () mutable {
+  ++j;
+};
+  };
+#endif
+
+  [=] () {
+[&i] () mutable {
+  ++i; // { dg-error "read-only" }
+};
+  };
+
+  const int j = 0;
+  [=] () {
+[j] () mutable {
+  ++j; // { dg-error "read-only" }
+};
+  };
+
+#if __cpp_init_captures
+  [j=0] () {
+[&j] () mutable {
+  ++j; // { dg-error "read-only" "" { target c++14 } }
+};
+  };
+#endif
+}




Re: [PATCH] c++: ahead-of-time overload set pruning for non-dep calls

2021-12-16 Thread Jason Merrill via Gcc-patches

On 12/16/21 14:53, Patrick Palka wrote:

On Thu, 16 Dec 2021, Patrick Palka wrote:


On Wed, 15 Dec 2021, Jason Merrill wrote:


On 12/15/21 12:49, Patrick Palka wrote:

This patch makes us remember the function selected by overload
resolution during ahead of time processing of a non-dependent call
expression, so that we avoid repeating most of the work of overload
resolution at instantiation time.  This mirrors what we already do for
non-dependent operator expressions via build_min_non_dep_op_overload.

Some caveats:

   * When processing ahead of time a non-dependent call to a member
 function template inside a class template (as in
 g++.dg/template/deduce4.C), we end up generating an "inverted" partial
 instantiation such as S::foo(), the kinds of which we're
 apparently not prepared to fully instantiate (e.g. tsubst_baselink
 mishandles it).  So this patch disables this optimization for such
 functions and adds a FIXME.


I wonder if it would be worthwhile to build a TEMPLATE_ID_EXPR to remember the
deduced template args, even if we are failing to remember the actual function?


Hmm, that transformation could have observable effects, since overload
resolution for f(0) might end up instantiating more things than for
f(0) due to the explicit-args substitution step:

   template struct A { using type = typename T::type; };

   template void f(T);
   template typename A::type f(T);

Here overload resolution for f(0) succeeds and selects the first
overload but for f(0) induces a hard error.  Also I worry that such
a transformation might affect declaration matching in weird ways due
to conflating f(0) with f(0).

We could at least though prune the overload set to the corresponding
selected function template rather than the "inside-out" specialization;
I'll try to implement that.


Here's a bootstrapped and regtested patch which implements that:


OK.


-- >8 --

This patch makes us remember the function selected by overload resolution
during ahead of time processing of a non-dependent call expression, so
that we avoid repeating most of the work of overload resolution for the
call at instantiation time.  Note that we already do this for
non-dependent operator expressions via build_min_non_dep_op_overload.

Some caveats:

  * When processing ahead of time a non-dependent call to a member
function template inside a common class template (as in
g++.dg/template/deduce4.C), we end up generating an "inverted" partial
instantiation such as S::foo(), the likes of which we're
apparently not prepared to fully instantiate (e.g. tsubst_baselink
mishandles it).  So this patch makes us prune to the selected
template instead of the specialization in this case.

  * This change triggered a latent FUNCTION_DECL pretty printing issue
in cpp0x/error2.C -- since we now resolve the call to foo<0> ahead
of time, the error now looks like:

  error: expansion pattern ‘foo()()=0’ contains no parameter pack

where the FUNCTION_DECL for foo<0> is clearly misprinted.  But this
pretty-printing issue could be reproduced without this patch if
we define foo as a non-template function.  Since this testcase was
added to verify pretty printing of TEMPLATE_ID_EXPR, I work around
this test failure by making the call to foo type-dependent and thus
immune to this ahead of time pruning.

  * We now reject parts of cpp0x/fntmp-equiv1.C because we notice that
the call d(f, b) in

  template  e d();

is always non-constexpr because the selected d isn't.  I tried fixing
this by making it constexpr, but then the call to d from main becomes
ambiguous.  So I settled with removing this part of the testcase.

gcc/cp/ChangeLog:

* call.c (build_new_method_call): For a non-dependent call
expression inside a template, returning a templated tree
whose overload set contains just the selected function.
* semantics.c (finish_call_expr): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/error2.C: Make the call to foo type-dependent in
order to avoid latent pretty-printing issue for FUNCTION_DECL
inside MODOP_EXPR.
* g++.dg/cpp0x/fntmp-equiv1.C: Remove ill-formed parts of
testcase that we now diagnose.
* g++.dg/template/non-dependent16.C: New test.
* g++.dg/template/non-dependent16a.C: New test.
* g++.dg/template/non-dependent17.C: New test.
---
  gcc/cp/call.c | 27 ++
  gcc/cp/semantics.c| 15 
  gcc/testsuite/g++.dg/cpp0x/error2.C   |  4 +-
  gcc/testsuite/g++.dg/cpp0x/fntmp-equiv1.C |  4 --
  .../g++.dg/template/non-dependent16.C | 37 +++
  .../g++.dg/template/non-dependent16a.C| 36 ++
  .../g++.dg/template/non-dependent17.C | 21 +++
  7 files changed, 138 insertions(+), 6 deletions(-)
  create mode 100644 gcc/t

Re: [PATCH] i386: simplify cpu_feature handling

2021-12-16 Thread Stefan Kneifel

Am 15.12.21 um 10:57 schrieb Martin Liška:

On 12/14/21 17:12, Jakub Jelinek wrote:

I'd use INT_TYPE_SIZE - 1 instead of 31. Otherwise LGTM.


Installed with that change, thanks.

Moreover, I'm suggesting a simplification:

The patch removes unneeded loops for cpu_features2 and CONVERT_EXPR
that can be simplified with NOP_EXPR.

Survives i386.exp tests, may I install the patch after testing or
is it a stage1 material?

Thanks,
Martin


The loops indeed seem to be unnecessary.

For safety reasons: what would you think about throwing an ICE if (index 
>= SIZE_OF_CPU_FEATURES) ?
This should not happen - however, a lot of things shouldn't happen... 
and it might facilitiate locating a potential bug at a later time.


Regards, Stefan



[patch] Fix PR libfortran/95177, ctype.h functions should not be called with char arguments

2021-12-16 Thread FX via Gcc-patches
Hi,

Functions from  should only be called on values that can be 
represented by unsigned char. On targets where char is a signed type, some of 
libgfortran calls have undefined behaviour.

The solution is to cast the argument to unsigned char type. I’ve defined macros 
in libgfortran.h to do so, to retain legibility of the library code.

Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to commit?

FX



pr95177.patch
Description: Binary data


[PATCH] Use enclosing object size if it's smaller than member [PR 101475]

2021-12-16 Thread Martin Sebor via Gcc-patches

Enabling vectorization at -O2 caused quite a few tests for
warnings to start failing in GCC 12.  These tests were xfailed
and bugs were opened to track the problems until they can be
fully analyzed and ultimately fixed before GCC 12 is released.

I've now started going through these and the first such bug
I tackled is PR 102944.  As it turns out, the xfails there
are all due to a known limitation tracked in PR 101475: when
determining the size of a destination for A COMPONENT_REF,
unless asked for the size of the complete object,
compute_objsize() only considers the size of the referenced
member, even when the member is larger than the object would
allow.  This prevents warnings from diagnosing unvectorized
past-the-end accesses to objects in backing buffers (such as
in character arrays or allocated chunks of memory).

Many (though not all) accesses that are vectorized are diagnosed
because there the COMPONENT_REF is replaced by a MEM_REF.  But
because vectorization depends on target-specific things like
alignment requirements, what is and isn't diagnosed also tends
to be target-specific, making these tests quite brittle..

The attached patch corrects this oversight by using the complete
object's size instead of the member when the former is smaller.
Besides improving the out-of-bounds access detection it also
makes the tests behave more consistently across targets.

Tested on x86_64-linux and by building Glibc and verifying
that the change triggers no new warnings.

Martin
Use enclosing object size if it's smaller than member [PR 101475].

Resolves:
PR middle-end/101475 - missing -Wstringop-overflow storing a compound literal

gcc/ChangeLog:

	PR middle-end/101475
	* pointer-query.cc (handle_component_ref): Use the size of
	the enclosing object if it's smaller than the member.

gcc/testsuite/ChangeLog:

	PR middle-end/101475
	* gcc.dg/Wstringop-overflow-68.c: Adjust, remove xfails.
	* gcc.dg/Wstringop-overflow-88.c: New test.

diff --git a/gcc/pointer-query.cc b/gcc/pointer-query.cc
index 4bedf7fca47..644b4de9bcb 100644
--- a/gcc/pointer-query.cc
+++ b/gcc/pointer-query.cc
@@ -1914,36 +1914,40 @@ handle_component_ref (tree cref, gimple *stmt, bool addr, int ostype,
   gcc_assert (TREE_CODE (cref) == COMPONENT_REF);
 
   const tree base = TREE_OPERAND (cref, 0);
+  const tree field = TREE_OPERAND (cref, 1);
+  access_ref base_ref = *pref;
+
+  /* Unconditionally determine the size of the base object (it could
+ be smaller than the referenced member).  */
+  if (!compute_objsize_r (base, stmt, addr, 0, &base_ref, snlim, qry))
+return false;
+
+  /* Add the offset of the member to the offset into the object computed
+ so far.  */
+  tree offset = byte_position (field);
+  if (TREE_CODE (offset) == INTEGER_CST)
+base_ref.add_offset (wi::to_offset (offset));
+  else
+base_ref.add_max_offset ();
+
+  if (!base_ref.ref)
+/* PREF->REF may have been already set to an SSA_NAME earlier
+   to provide better context for diagnostics.  In that case,
+   leave it unchanged.  */
+base_ref.ref = base;
+
   const tree base_type = TREE_TYPE (base);
   if (TREE_CODE (base_type) == UNION_TYPE)
 /* In accesses through union types consider the entire unions
rather than just their members.  */
 ostype = 0;
 
-  tree field = TREE_OPERAND (cref, 1);
-
   if (ostype == 0)
 {
   /* In OSTYPE zero (for raw memory functions like memcpy), use
 	 the maximum size instead if the identity of the enclosing
 	 object cannot be determined.  */
-  if (!compute_objsize_r (base, stmt, addr, ostype, pref, snlim, qry))
-	return false;
-
-  /* Otherwise, use the size of the enclosing object and add
-	 the offset of the member to the offset computed so far.  */
-  tree offset = byte_position (field);
-  if (TREE_CODE (offset) == INTEGER_CST)
-	pref->add_offset (wi::to_offset (offset));
-  else
-	pref->add_max_offset ();
-
-  if (!pref->ref)
-	/* PREF->REF may have been already set to an SSA_NAME earlier
-	   to provide better context for diagnostics.  In that case,
-	   leave it unchanged.  */
-	pref->ref = base;
-
+  *pref = base_ref;
   return true;
 }
 
@@ -1958,6 +1962,11 @@ handle_component_ref (tree cref, gimple *stmt, bool addr, int ostype,
 }
 
   set_component_ref_size (cref, pref);
+
+  if (base_ref.size_remaining () < pref->size_remaining ())
+/* Use the base object if it's smaller than the member.  */
+*pref = base_ref;
+
   return true;
 }
 
diff --git a/gcc/testsuite/gcc.dg/Wstringop-overflow-68.c b/gcc/testsuite/gcc.dg/Wstringop-overflow-68.c
index 05ea56fca67..4d132394f0f 100644
--- a/gcc/testsuite/gcc.dg/Wstringop-overflow-68.c
+++ b/gcc/testsuite/gcc.dg/Wstringop-overflow-68.c
@@ -2,7 +2,7 @@
a larger scalar into a smaller array
Verify overflow by aggregate stores.
{ dg-do compile }
-   { dg-options "-O2" } */
+   { dg-options "-O2 -fno-tree-vectorize" } */
 
 #define A(N) (A ## N)
 #define Ac1 (AC1){ 0 }
@@ -57

Re: [PATCH] c++: ahead-of-time overload set pruning for non-dep calls

2021-12-16 Thread Patrick Palka via Gcc-patches
On Thu, 16 Dec 2021, Patrick Palka wrote:

> On Wed, 15 Dec 2021, Jason Merrill wrote:
> 
> > On 12/15/21 12:49, Patrick Palka wrote:
> > > This patch makes us remember the function selected by overload
> > > resolution during ahead of time processing of a non-dependent call
> > > expression, so that we avoid repeating most of the work of overload
> > > resolution at instantiation time.  This mirrors what we already do for
> > > non-dependent operator expressions via build_min_non_dep_op_overload.
> > > 
> > > Some caveats:
> > > 
> > >   * When processing ahead of time a non-dependent call to a member
> > > function template inside a class template (as in
> > > g++.dg/template/deduce4.C), we end up generating an "inverted" partial
> > > instantiation such as S::foo(), the kinds of which we're
> > > apparently not prepared to fully instantiate (e.g. tsubst_baselink
> > > mishandles it).  So this patch disables this optimization for such
> > > functions and adds a FIXME.
> > 
> > I wonder if it would be worthwhile to build a TEMPLATE_ID_EXPR to remember 
> > the
> > deduced template args, even if we are failing to remember the actual 
> > function?
> 
> Hmm, that transformation could have observable effects, since overload
> resolution for f(0) might end up instantiating more things than for
> f(0) due to the explicit-args substitution step:
> 
>   template struct A { using type = typename T::type; };
> 
>   template void f(T);
>   template typename A::type f(T);
> 
> Here overload resolution for f(0) succeeds and selects the first
> overload but for f(0) induces a hard error.  Also I worry that such
> a transformation might affect declaration matching in weird ways due
> to conflating f(0) with f(0).
> 
> We could at least though prune the overload set to the corresponding
> selected function template rather than the "inside-out" specialization;
> I'll try to implement that.

Here's a bootstrapped and regtested patch which implements that:

-- >8 --

This patch makes us remember the function selected by overload resolution
during ahead of time processing of a non-dependent call expression, so
that we avoid repeating most of the work of overload resolution for the
call at instantiation time.  Note that we already do this for
non-dependent operator expressions via build_min_non_dep_op_overload.

Some caveats:

 * When processing ahead of time a non-dependent call to a member
   function template inside a common class template (as in
   g++.dg/template/deduce4.C), we end up generating an "inverted" partial
   instantiation such as S::foo(), the likes of which we're
   apparently not prepared to fully instantiate (e.g. tsubst_baselink
   mishandles it).  So this patch makes us prune to the selected
   template instead of the specialization in this case.

 * This change triggered a latent FUNCTION_DECL pretty printing issue
   in cpp0x/error2.C -- since we now resolve the call to foo<0> ahead
   of time, the error now looks like:

 error: expansion pattern ‘foo()()=0’ contains no parameter pack

   where the FUNCTION_DECL for foo<0> is clearly misprinted.  But this
   pretty-printing issue could be reproduced without this patch if
   we define foo as a non-template function.  Since this testcase was
   added to verify pretty printing of TEMPLATE_ID_EXPR, I work around
   this test failure by making the call to foo type-dependent and thus
   immune to this ahead of time pruning.

 * We now reject parts of cpp0x/fntmp-equiv1.C because we notice that
   the call d(f, b) in

 template  e d();

   is always non-constexpr because the selected d isn't.  I tried fixing
   this by making it constexpr, but then the call to d from main becomes
   ambiguous.  So I settled with removing this part of the testcase.

gcc/cp/ChangeLog:

* call.c (build_new_method_call): For a non-dependent call
expression inside a template, returning a templated tree
whose overload set contains just the selected function.
* semantics.c (finish_call_expr): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/error2.C: Make the call to foo type-dependent in
order to avoid latent pretty-printing issue for FUNCTION_DECL
inside MODOP_EXPR.
* g++.dg/cpp0x/fntmp-equiv1.C: Remove ill-formed parts of
testcase that we now diagnose.
* g++.dg/template/non-dependent16.C: New test.
* g++.dg/template/non-dependent16a.C: New test.
* g++.dg/template/non-dependent17.C: New test.
---
 gcc/cp/call.c | 27 ++
 gcc/cp/semantics.c| 15 
 gcc/testsuite/g++.dg/cpp0x/error2.C   |  4 +-
 gcc/testsuite/g++.dg/cpp0x/fntmp-equiv1.C |  4 --
 .../g++.dg/template/non-dependent16.C | 37 +++
 .../g++.dg/template/non-dependent16a.C| 36 ++
 .../g++.dg/template/non-dependent17.C | 21 +++
 7 files changed, 

Re: [PATCH v4 1/6] tree-object-size: Use trees and support negative offsets

2021-12-16 Thread Siddhesh Poyarekar

On 12/16/21 21:19, Jakub Jelinek wrote:

Yes, but please fix up formatting, wholeval should go below old_wholeval.
Though, perhaps it would be better to:

   if (tree_int_cst_compare (oldval, val))
 return true;

   gcc_checking_assert (tree_int_cst_compare (old_wholeval, wholeval) == 0);
   return false;

Ok with that change.

Jakub



I thought about this some more and I think I'm wrong in assuming that 
wholeval won't change in subsequent passes; my tests show I'm wrong too. 
 I'm now testing with the condition fixed up to:


  return (tree_int_cst_compare (oldval, val) != 0
  || tree_int_cst_compare (old_wholeval, wholeval) != 0);

as you had suggested earlier and will push it if it passes bootstrap and 
a clean testsuite run.  I'm doing a ubsan bootstrap too because it's 
been quite useful in catching corner cases in __bos before.


Thanks,
Siddhesh


Re: [gcc r12-6020] Fixed typo

2021-12-16 Thread Joseph Myers
On Thu, 16 Dec 2021, Martin Liška wrote:

> Hello.
> 
> Oh, sorry, it was me and I forgot to send the patch to the mailing list.
> I've basically taken it as: https://github.com/gcc-mirror/gcc/pull/57.
> 
> Should I revert the change?

Updating both config.sub and config.guess to the latest config.git 
versions (2021-10-27 and 2021-11-30) is probably the right thing to do 
now.

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


Re: [gcc r12-6020] Fixed typo

2021-12-16 Thread Martin Liška

On 12/16/21 19:32, Joseph Myers wrote:

On Thu, 16 Dec 2021, Martin Liska via Gcc-cvs wrote:


https://gcc.gnu.org/g:06cd44b4387a9f6ab46f377f42ee5be9cf11bf15

commit r12-6020-g06cd44b4387a9f6ab46f377f42ee5be9cf11bf15
Author: Matthias Seidel 
Date:   Wed Jun 23 20:35:24 2021 +0200

 Fixed typo
 
 ChangeLog:
 
 * config.sub: Fix typo.


I'm not sure where this came from - I don't see it on gcc-patches, either
now or in June - but we shouldn't patch config.sub or config.guess
locally, only update them to the latest version from upstream config.git
without any local changes.  In config.git this change appears with
different attribution as:


Hello.

Oh, sorry, it was me and I forgot to send the patch to the mailing list.
I've basically taken it as: https://github.com/gcc-mirror/gcc/pull/57.

Should I revert the change?
Martin



commit 9428e344e65176b03b69e4bf4ed0d0fc51d4c26f
Author: Kinshuk Dua 
Date:   Mon Oct 18 15:01:31 2021 +0530

 config.sub: Fix typo in comment
 
 Fixes: 5e531d391852a54e7fab2d8ff55625fca514b305

 Signed-off-by: Dmitry V. Levin 





[PATCH] i386: Enable VxHF vector modes lower ABI levels [PR103571]

2021-12-16 Thread Uros Bizjak via Gcc-patches
Enable VxHF vector modes for SSE2, AVX and AVX512F ABIs.

2021-12-16  Uroš Bizjak  

gcc/ChangeLog:

PR target/103571
* config/i386/i386.h (VALID_AVX256_REG_MODE): Add V16HFmode.
(VALID_AVX256_REG_OR_OI_VHF_MODE): Replace with ...
(VALID_AVX256_REG_OR_OI_MODE): ... this.  Remove V16HFmode.
(VALID_AVX512F_SCALAR_MODE): Remove HImode and HFmode.
(VALID_AVX512FP16_SCALAR_MODE): New.
(VALID_AVX512F_REG_MODE): Add V32HFmode.
(VALID_SSE2_REG_MODE): Add V8HFmode, V4HFmode and V2HFmode.
(VALID_SSE2_REG_VHF_MODE): Remove.
(VALID_INT_MODE_P): Add V2HFmode.
* config/i386/i386.c (function_arg_advance_64):
Remove explicit mention of V16HFmode and V32HFmode.
(ix86_hard_regno_mode_ok): Remove explicit mention of XImode
and V32HFmode, use VALID_AVX512F_REG_OR_XI_MODE instead.
Use VALID_AVX512FP_SCALAR_MODE for TARGET_aVX512FP16.
Use VALID_AVX256_REG_OR_OI_MODE instead of
VALID_AVX256_REG_OR_OI_VHF_MODE and VALID_SSE2_REG_MODE instead
of VALID_SSE2_REG_VHF_MODE.
(ix86_set_reg_reg_cost): Remove usge of VALID_AVX512FP16_REG_MODE.
(ix86_vector_mode_supported): Ditto.

gcc/testsuite/ChangeLog:

PR target/103571
* gcc.target/i386/pr102812.c (dg-final): Do not scan for movdqa.

Bootstrapped and regression tested on x86_64-linux-gnu b,-m32}.

Pushed to master.

Uros.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 9f4ed34ffd5..ec155826310 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2942,9 +2942,7 @@ function_arg_advance_64 (CUMULATIVE_ARGS *cum, 
machine_mode mode,
 
   /* Unnamed 512 and 256bit vector mode parameters are passed on stack.  */
   if (!named && (VALID_AVX512F_REG_MODE (mode)
-|| VALID_AVX256_REG_MODE (mode)
-|| mode == V16HFmode
-|| mode == V32HFmode))
+|| VALID_AVX256_REG_MODE (mode)))
 return 0;
 
   if (!examine_argument (mode, type, 0, &int_nregs, &sse_nregs)
@@ -19915,15 +19913,17 @@ ix86_hard_regno_mode_ok (unsigned int regno, 
machine_mode mode)
  - XI mode
  - any of 512-bit wide vector mode
  - any scalar mode.  */
-  /* For AVX512FP16, vmovw supports movement of HImode
-between gpr and sse registser.  */
   if (TARGET_AVX512F
- && (mode == XImode
- || mode == V32HFmode
- || VALID_AVX512F_REG_MODE (mode)
+ && (VALID_AVX512F_REG_OR_XI_MODE (mode)
  || VALID_AVX512F_SCALAR_MODE (mode)))
return true;
 
+  /* For AVX512FP16, vmovw supports movement of HImode
+and HFmode between GPR and SSE registers.  */
+  if (TARGET_AVX512FP16
+ && VALID_AVX512FP16_SCALAR_MODE (mode))
+   return true;
+
   /* For AVX-5124FMAPS or AVX-5124VNNIW
 allow V64SF and V64SI modes for special regnos.  */
   if ((TARGET_AVX5124FMAPS || TARGET_AVX5124VNNIW)
@@ -19934,7 +19934,7 @@ ix86_hard_regno_mode_ok (unsigned int regno, 
machine_mode mode)
   /* TODO check for QI/HI scalars.  */
   /* AVX512VL allows sse regs16+ for 128/256 bit modes.  */
   if (TARGET_AVX512VL
- && (VALID_AVX256_REG_OR_OI_VHF_MODE (mode)
+ && (VALID_AVX256_REG_OR_OI_MODE (mode)
  || VALID_AVX512VL_128_REG_MODE (mode)))
return true;
 
@@ -19944,9 +19944,9 @@ ix86_hard_regno_mode_ok (unsigned int regno, 
machine_mode mode)
 
   /* OImode and AVX modes are available only when AVX is enabled.  */
   return ((TARGET_AVX
-  && VALID_AVX256_REG_OR_OI_VHF_MODE (mode))
+  && VALID_AVX256_REG_OR_OI_MODE (mode))
  || VALID_SSE_REG_MODE (mode)
- || VALID_SSE2_REG_VHF_MODE (mode)
+ || VALID_SSE2_REG_MODE (mode)
  || VALID_MMX_REG_MODE (mode)
  || VALID_MMX_REG_MODE_3DNOW (mode));
 }
@@ -20156,8 +20156,7 @@ ix86_set_reg_reg_cost (machine_mode mode)
 
 case MODE_VECTOR_INT:
 case MODE_VECTOR_FLOAT:
-  if ((TARGET_AVX512FP16 && VALID_AVX512FP16_REG_MODE (mode))
- || (TARGET_AVX512F && VALID_AVX512F_REG_MODE (mode))
+  if ((TARGET_AVX512F && VALID_AVX512F_REG_MODE (mode))
  || (TARGET_AVX && VALID_AVX256_REG_MODE (mode))
  || (TARGET_SSE2 && VALID_SSE2_REG_MODE (mode))
  || (TARGET_SSE && VALID_SSE_REG_MODE (mode))
@@ -22080,8 +22079,6 @@ ix86_vector_mode_supported_p (machine_mode mode)
   if ((TARGET_MMX || TARGET_MMX_WITH_SSE)
   && VALID_MMX_REG_MODE (mode))
 return true;
-  if (TARGET_AVX512FP16 && VALID_AVX512FP16_REG_MODE (mode))
-return true;
   if ((TARGET_3DNOW || TARGET_MMX_WITH_SSE)
   && VALID_MMX_REG_MODE_3DNOW (mode))
 return true;
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 46fdd6e1088..398f7513752 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -1005,20 +1005,22 @@ extern const char *host_detect_local_cpu (int argc, 
const char **argv);
 #define VALID_AVX256_REG_MODE(MODE)

Re: [gcc r12-6020] Fixed typo

2021-12-16 Thread Joseph Myers
On Thu, 16 Dec 2021, Martin Liska via Gcc-cvs wrote:

> https://gcc.gnu.org/g:06cd44b4387a9f6ab46f377f42ee5be9cf11bf15
> 
> commit r12-6020-g06cd44b4387a9f6ab46f377f42ee5be9cf11bf15
> Author: Matthias Seidel 
> Date:   Wed Jun 23 20:35:24 2021 +0200
> 
> Fixed typo
> 
> ChangeLog:
> 
> * config.sub: Fix typo.

I'm not sure where this came from - I don't see it on gcc-patches, either 
now or in June - but we shouldn't patch config.sub or config.guess 
locally, only update them to the latest version from upstream config.git 
without any local changes.  In config.git this change appears with 
different attribution as:

commit 9428e344e65176b03b69e4bf4ed0d0fc51d4c26f
Author: Kinshuk Dua 
Date:   Mon Oct 18 15:01:31 2021 +0530

config.sub: Fix typo in comment

Fixes: 5e531d391852a54e7fab2d8ff55625fca514b305
Signed-off-by: Dmitry V. Levin 

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


Re: [PATCH] testsuite: Robustify aarch64/simd tests against more aggressive DCE

2021-12-16 Thread Eric Botcazou via Gcc-patches
> The calls should still be diagnosed as incorrect, even if we don't
> code-generate them.  The fact that we don't do that is a known bug
> (in aarch64 code).

OK, thanks for the explanation.

> The new variables seem to be unused, so I think slightly stronger
> DCE could remove the calls even after the patch.  Perhaps the containing
> functions should take an int32x4_t *ptr or something, with the calls
> assigning to different ptr[] indices.

We run a minimal DCE pass at -O0 in our compiler to eliminate all the garbage 
generated by the gimplifier for variable-sized types (people care about code 
size at -O0 in specific contexts) but it does not touch anything written by 
the user (and debugging is unaffected of course).  Given that the builtins are 
pure functions and the arguments have no side effects, it eliminates the 
calls, but adding a LHS blocks that because this minimal DCE pass preserves 
anything user-related, in particular assignments to user variables.

> I think it would be better to do that using new calls though,
> and xfail the existing ones when they no longer work.  For example:
> 
>   /* { dg-error "lane -1 out of range 0 - 7" "" {target *-*-*} 0 } */
>   vqdmlal_high_laneq_s16 (int32x4_a, int16x8_b, int16x8_c, -1);
>   /* { dg-error "lane -1 out of range 0 - 7" "" {target *-*-*} 0 } */
>   ptr[0] = vqdmlal_high_laneq_s16 (int32x4_a, int16x8_b, int16x8_c, -1);
> 
> That way we don't lose the existing tests.

Frankly I'm not quite sure of what we can lose by adding a LHS here, can you 
elaborate a bit?  We would need a solution that works out of the box with our 
compiler in the future, i.e. without having to tweak 50 testcases again.

-- 
Eric Botcazou




Re: [PATCH] c++: ahead-of-time overload set pruning for non-dep calls

2021-12-16 Thread Patrick Palka via Gcc-patches
On Wed, 15 Dec 2021, Jason Merrill wrote:

> On 12/15/21 12:49, Patrick Palka wrote:
> > This patch makes us remember the function selected by overload
> > resolution during ahead of time processing of a non-dependent call
> > expression, so that we avoid repeating most of the work of overload
> > resolution at instantiation time.  This mirrors what we already do for
> > non-dependent operator expressions via build_min_non_dep_op_overload.
> > 
> > Some caveats:
> > 
> >   * When processing ahead of time a non-dependent call to a member
> > function template inside a class template (as in
> > g++.dg/template/deduce4.C), we end up generating an "inverted" partial
> > instantiation such as S::foo(), the kinds of which we're
> > apparently not prepared to fully instantiate (e.g. tsubst_baselink
> > mishandles it).  So this patch disables this optimization for such
> > functions and adds a FIXME.
> 
> I wonder if it would be worthwhile to build a TEMPLATE_ID_EXPR to remember the
> deduced template args, even if we are failing to remember the actual function?

Hmm, that transformation could have observable effects, since overload
resolution for f(0) might end up instantiating more things than for
f(0) due to the explicit-args substitution step:

  template struct A { using type = typename T::type; };

  template void f(T);
  template typename A::type f(T);

Here overload resolution for f(0) succeeds and selects the first
overload but for f(0) induces a hard error.  Also I worry that such
a transformation might affect declaration matching in weird ways due
to conflating f(0) with f(0).

We could at least though prune the overload set to the corresponding
selected function template rather than the "inside-out" specialization;
I'll try to implement that.

> 
> >   * WHen trying to make the instantiation machinery handle these partial
> > instantiations, I made a couple of changes in register_specialization
> > and tsubst_function_decl that get us closer to handling such partial
> > instantiations and that seem like improvements on their own, so this
> > patch includes these changes.
> 
> The tsubst_function_decl change makes me nervous; surely there was some reason
> that function wasn't that way in the first place.  Let's hold these changes
> for stage 1 if they aren't actually fixing anything.

Will do.

> 
> >* This change triggered a latent FUNCTION_DECL pretty printing issue
> >  in cpp0x/error2.C -- since we now resolve the call to foo<0> ahead
> >  of time, the error now looks like:
> > 
> >error: expansion pattern ‘foo()()=0’ contains no parameter pack
> > 
> >  where the FUNCTION_DECL foo is clearly misprinted.  But this
> >  pretty-printing issue could be reproduced without this patch if
> >  we replace foo with an ordinary function.  Since this testcase was
> >  added to verify pretty printing of TEMPLATE_ID_EXPR, I work around
> >  this test failure by making the call to foo type-dependent and thus
> >  immune to this ahead of time pruning.
> > 
> >* We now reject parts of cpp0x/fntmp-equiv1.C because we notice that
> >  the call d(f, b) in
> > 
> >template  e d();
> > 
> >  isn't constexpr because the (resolved) d isn't.  I tried fixing this
> >  by making d constexpr, but then the call to d from main becomes
> >  ambiguous.  So I settled with removing this part of the testcase.
> > 
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?  Also tested on cmcstl2 and range-v3.
> > 
> > gcc/cp/ChangeLog:
> > 
> > * call.c (build_new_method_call): For a non-dependent call
> > expression inside a template, returning a templated tree
> > whose overload set contains just the selected function.
> > * pt.c (register_specialization): Check only the innermost
> > template args for dependence in the early exit test.
> > (tsubst_function_decl): Simplify obtaining the template arguments
> > for a partial instantiation.
> > * semantics.c (finish_call_expr): As with build_new_method_call.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > * g++.dg/cpp0x/error2.C: Make the call to foo type-dependent in
> > order to avoid latent pretty-printing issue for FUNCTION_DECL
> > inside MODOP_EXPR.
> > * g++.dg/cpp0x/fntmp-equiv1.C: Remove ill-formed parts of
> > testcase that we now diagnose.
> > * g++.dg/template/non-dependent16.C: New test.
> > * g++.dg/template/non-dependent16a.C: New test.
> > ---
> >   gcc/cp/call.c | 17 +
> >   gcc/cp/pt.c   | 18 ++---
> >   gcc/cp/semantics.c| 15 
> >   gcc/testsuite/g++.dg/cpp0x/error2.C   |  4 +-
> >   gcc/testsuite/g++.dg/cpp0x/fntmp-equiv1.C |  4 --
> >   .../g++.dg/template/non-dependent16.C | 37 +++
> >   .../g++.dg/template/non-dependent16a

Re: [patch] Fix libfortran/101255, wrong IOSTAT value for FLUSH

2021-12-16 Thread FX via Gcc-patches
Patch committed, after changing “call abort” to “stop”.
Thanks for the review.

FX

Re: [patch] Fix libfortran/98507, handling of timezone near year boundaries

2021-12-16 Thread FX via Gcc-patches
> OK after fixing the above, and thanks for the patch!

Patch committed, after changing “call abort” to “stop”.
Thanks for the review.

FX

Re: [PATCH] opts: do not do sanity check when an error is seen

2021-12-16 Thread Jeff Law via Gcc-patches




On 12/16/2021 7:37 AM, Martin Liška wrote:

Do not check global options modification when an error is seen in parsing
of options (pragmas or attributes).

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR target/103709

gcc/c-family/ChangeLog:

* c-pragma.c (handle_pragma_pop_options): Do not check
global options modification when an error is seen in parsing
of options (pragmas or attributes).

OK
jeff



Re: [PATCH] pragma: respect pragma in lambda functions

2021-12-16 Thread Jeff Law via Gcc-patches




On 12/16/2021 4:07 AM, Martin Liška wrote:

In g:01ad8c54fdca we started supporting target pragma changes
that are primarily caused by optimization option. The same can happen
in the opposite way and we need to check for changes both
in optimization_current_node and target_option_current_node.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR c++/103696

gcc/ChangeLog:

* attribs.c (decl_attributes): Check if
target_option_current_node is changed.

gcc/testsuite/ChangeLog:

* g++.target/i386/pr103696.C: New test.

OK
jeff



Re: [patch] Fix libfortran/98507, handling of timezone near year boundaries

2021-12-16 Thread Harald Anlauf via Gcc-patches

Hi FX,

Am 16.12.21 um 15:17 schrieb FX via Fortran:

Hi,

DATE_AND_TIME can return incorrect values for non-UTC timezones, near the new 
year, when the local time and UTC time are in different years. 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507

Attached patch fixes the issue by correcting the logic to account for that 
wrapping of “day of the year” around new year. I include a testcase, which 
checks the sanity of values returned by DATE_AND_TIME. Since the bug only 
occurs for a few hours every year, and depends on local timezone, I could not 
think of a better (systematic) test.


please change "call abort" to "stop n".  The former should no longer be
used in the testsuite.


I also want to propose (it’s not directly needed to fix the bug) that we switch 
our time routines to rely on clock_gettime() instead of gettimeofday(), when 
available. This is in line with POSIX.1-2008, which marks gettimeofday() as 
obsolete, recommending the use of
clock_gettime() instead.


Agreed.


Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to commit?

FX




OK after fixing the above, and thanks for the patch!

Harald


Re: [patch] Fix libfortran/101255, wrong IOSTAT value for FLUSH

2021-12-16 Thread Harald Anlauf via Gcc-patches

Hi FX,

we now use "STOP n" instead of "call abort" in testcases.

OK with this change.

Am 16.12.21 um 17:34 schrieb FX via Fortran:

With correct patch attached, sorry.



Hi,

Bug reported by Tobias at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101255 

Trivial fix, adding a testcase.

Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to commit?

FX



Harald


Re: [patch] Fix libfortran/101255, wrong IOSTAT value for FLUSH

2021-12-16 Thread FX via Gcc-patches
With correct patch attached, sorry.



Hi,

Bug reported by Tobias at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101255 

Trivial fix, adding a testcase.

Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to commit?

FX



pr101255.patch
Description: Binary data


Re: [PATCH] c++: nested lambda capturing a capture proxy, part 2 [PR94376]

2021-12-16 Thread Patrick Palka via Gcc-patches
On Wed, 15 Dec 2021, Jason Merrill wrote:

> On 12/15/21 15:36, Patrick Palka wrote:
> > The r12-5403 fix apparently doesn't handle the case where the inner
> > lambda explicitly rather implicitly captures the capture proxy from
> > the outer lambda, and so we still reject the first example in the
> > testcase below.
> > 
> > The reason is that compared to an implicit capture, the effective
> > initializer for an explicit capture is wrapped in a location wrapper
> > (pointing to the source location of the explicit capture), and this
> > wrapper foils the is_capture_proxy check.  The simplest fix appears to
> > be to strip location wrappers accordingly.
> > 
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> > 
> > PR c++/94376
> > 
> > gcc/cp/ChangeLog:
> > 
> > * lambda.c (lambda_capture_field_type): Strip location wrappers
> > before checking for a capture proxy.
> 
> I think either is_capture_proxy should strip location wrappers or
> gcc_checking_assert that it doesn't see one.

Good idea, here's v2 which adds an assert to is_capture_proxy.  Only one
other caller, mark_const_cap_r, had to be adjusted.

-- >8 --

The r12-5403 fix apparently doesn't handle the case where the inner
lambda explicitly rather implicitly captures the capture proxy from
the outer lambda, which causes us to reject the first example in the
testcase below.

This is because compared to an implicit capture, the effective initializer
for an explicit capture is wrapped in a location wrapper (pointing to the
capture list), and this wrapper foils the is_capture_proxy check added in
r12-5403.

The simplest fix appears to be to strip location wrappers accordingly
before checking is_capture_proxy.  To help prevent against other
occurrences of this kind of bug, this patch also makes is_capture_proxy
assert it doesn't see a location wrapper.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

PR c++/94376

gcc/cp/ChangeLog:

* lambda.c (lambda_capture_field_type): Strip location wrappers
before checking for a capture proxy.
(is_capture_proxy): Assert that we don't see a location wrapper.
(mark_const_cap_r): Don't call is_constant_capture_proxy on a
location wrapper.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-nested9a.C: New test.
---
 gcc/cp/lambda.c   |  7 
 .../g++.dg/cpp0x/lambda/lambda-nested9a.C | 42 +++
 2 files changed, 49 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested9a.C

diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index c39a2bca416..d14e12c48f0 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -221,6 +221,7 @@ lambda_capture_field_type (tree expr, bool explicit_init_p,
 }
   else
 {
+  STRIP_ANY_LOCATION_WRAPPER (expr);
   if (!by_reference_p && is_capture_proxy (expr))
{
  /* When capturing by-value another capture proxy from an enclosing
@@ -246,6 +247,10 @@ lambda_capture_field_type (tree expr, bool explicit_init_p,
 bool
 is_capture_proxy (tree decl)
 {
+  /* Location wrappers should be stripped or otherwise handled by the
+ caller before using this predicate.  */
+  gcc_checking_assert (!location_wrapper_p (decl));
+
   return (VAR_P (decl)
  && DECL_HAS_VALUE_EXPR_P (decl)
  && !DECL_ANON_UNION_VAR_P (decl)
@@ -1496,6 +1501,8 @@ mark_const_cap_r (tree *t, int *walk_subtrees, void *data)
  *walk_subtrees = 0;
}
 }
+  else if (location_wrapper_p (*t))
+/* is_capture_proxy dislikes location wrappers.  */;
   else if (is_constant_capture_proxy (*t))
 var = DECL_CAPTURED_VARIABLE (*t);
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested9a.C 
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested9a.C
new file mode 100644
index 000..d62f8f0c952
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested9a.C
@@ -0,0 +1,42 @@
+// PR c++/94376
+// Like lambda-nested9.C but using explicit captures in the inner lambda.
+// { dg-do compile { target c++11 } }
+
+int main() {
+  // We used to incorrectly reject the first two cases.
+  int i = 0;
+  [=] () {
+[i] () mutable {
+  ++i;
+};
+  };
+
+#if __cpp_init_captures
+  [j=0] () {
+[j] () mutable {
+  ++j;
+};
+  };
+#endif
+
+  [=] () {
+[&i] () mutable {
+  ++i; // { dg-error "read-only" }
+};
+  };
+
+  const int j = 0;
+  [=] () {
+[j] () mutable {
+  ++j; // { dg-error "read-only" }
+};
+  };
+
+#if __cpp_init_captures
+  [j=0] () {
+[&j] () mutable {
+  ++j; // { dg-error "read-only" "" { target c++14 } }
+};
+  };
+#endif
+}
-- 
2.34.1.297.g69a9c10c95



Re: [patch] Fix libfortran/101255, wrong IOSTAT value for FLUSH

2021-12-16 Thread Harald Anlauf via Gcc-patches

Hi FX,

Am 16.12.21 um 15:49 schrieb FX via Fortran:

Hi,

Bug reported by Tobias at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101255
Trivial fix, adding a testcase.


it seems you attached the wrong patch (the one for pr985079).


Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to commit?

FX




Harald


[PATCH] c++: delayed noexcept in member function template [PR99980]

2021-12-16 Thread Marek Polacek via Gcc-patches
Some time ago I noticed that we don't properly delay parsing of
noexcept for member function templates.  This patch fixes that.

It didn't work because even though we set CP_PARSER_FLAGS_DELAY_NOEXCEPT
in cp_parser_member_declaration, member template declarations take
a different path: we call cp_parser_template_declaration and return
prior to setting the flag.

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

PR c++/99980

gcc/cp/ChangeLog:

* parser.c (cp_parser_single_declaration): Maybe pass
CP_PARSER_FLAGS_DELAY_NOEXCEPT down to cp_parser_init_declarator.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept71.C: New test.
---
 gcc/cp/parser.c |  7 +-
 gcc/testsuite/g++.dg/cpp0x/noexcept71.C | 31 +
 2 files changed, 37 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept71.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index c2564e51e41..c19e5f1359d 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -31673,8 +31673,13 @@ cp_parser_single_declaration (cp_parser* parser,
   && (cp_lexer_next_token_is_not (parser->lexer, CPP_SEMICOLON)
  || decl_specifiers.type != error_mark_node))
 {
+  int flags = CP_PARSER_FLAGS_TYPENAME_OPTIONAL;
+  /* We don't delay parsing for friends, though CWG 2510 may change
+that.  */
+  if (member_p && !(friend_p && *friend_p))
+   flags |= CP_PARSER_FLAGS_DELAY_NOEXCEPT;
   decl = cp_parser_init_declarator (parser,
-   CP_PARSER_FLAGS_TYPENAME_OPTIONAL,
+   flags,
&decl_specifiers,
checks,
/*function_definition_allowed_p=*/true,
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept71.C 
b/gcc/testsuite/g++.dg/cpp0x/noexcept71.C
new file mode 100644
index 000..361d6ad7b60
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept71.C
@@ -0,0 +1,31 @@
+// PR c++/99980
+// { dg-do compile { target c++11 } }
+
+#define SA(X) static_assert(X, #X)
+
+struct S {
+  template
+  void f(T) noexcept(B);
+
+  struct N {
+template
+void f2(T) noexcept(B);
+  };
+
+  static constexpr bool B = true;
+};
+
+S s;
+SA(noexcept(s.f(10)));
+S::N n;
+SA(noexcept(n.f2(10)));
+
+struct Bad {
+  template
+  using U = void() noexcept(B); // { dg-error "not declared" }
+
+  template
+  friend void friendo() noexcept(B); // { dg-error "not declared" }
+
+  static constexpr bool B = true;
+};

base-commit: 41cc28405c74a5ec59c6725274aaedefa9ca5887
-- 
2.33.1



[Patch][V2]Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables

2021-12-16 Thread Qing Zhao via Gcc-patches
Hi,

This is the 2nd version of the patch.
The original patch is at:

https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586341.html

In addition to resolve the two issues mentioned in the original patch,
This patch also can be used as a very good workaround for the issue in PR103720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103720

And as I checked, the patch can fix all the bogus uninitialized warnings when
building kernel with -O2 + -ftrivial-auto-var-init=zero + -Wuninitialized.

So, this is a very important patch that need to be included into gcc12.

Compared to the 1st patch, the major changes are to resolve Martin’s comments on
tree-ssa-uninit.c

1.  Add some meaningful temporaries to break the long expression to make it
 Readable. And also add comments to explain the purpose of the statement;

2.  Resolve the memory leakage of the dynamically created string.

The patch has been bootstrapped and regressing tested on both x86 and aarch64, 
no issues.
Okay for commit?

thanks.

Qing

=

**Compared to the 1st version, the code change is:

 --- a/gcc/tree-ssa-uninit.c
 +++ b/gcc/tree-ssa-uninit.c
 @@ -182,9 +182,22 @@ warn_uninit (opt_code opt, tree t, tree var, const char 
*gmsgid,
@@ -798,26 +798,35 @@
if (!var && !SSA_NAME_VAR (t))
  {
gimple *def_stmt = SSA_NAME_DEF_STMT (t);
-@@ -197,9 +210,34 @@ warn_uninit (opt_code opt, tree t, tree var, const char 
*gmsgid,
+@@ -197,9 +210,43 @@ warn_uninit (opt_code opt, tree t, tree var, const char 
*gmsgid,
   && zerop (gimple_assign_rhs2 (def_stmt)))
 var = SSA_NAME_VAR (v);
 }
 +
 +  if (gimple_call_internal_p (def_stmt, IFN_DEFERRED_INIT))
 +   {
++tree lhs_var = NULL_TREE;
++tree lhs_var_name = NULL_TREE;
++const char *lhs_var_name_str = NULL;
 + /* Get the variable name from the 3rd argument of call.  */
 + var_name = gimple_call_arg (def_stmt, 2);
 + var_name = TREE_OPERAND (TREE_OPERAND (var_name, 0), 0);
 + var_name_str = TREE_STRING_POINTER (var_name);
 +
-+if (is_gimple_assign (context)
-+&& TREE_CODE (gimple_assign_lhs (context)) == VAR_DECL
-+&& DECL_NAME (gimple_assign_lhs (context))
-+&& IDENTIFIER_POINTER (DECL_NAME (gimple_assign_lhs (context
-+  if (strcmp
-+(IDENTIFIER_POINTER (DECL_NAME (gimple_assign_lhs (context))),
-+ var_name_str) == 0)
-+return;
++/* Ignore the call to .DEFERRED_INIT that define the original
++   var itself.  */
++if (is_gimple_assign (context))
++  {
++if (TREE_CODE (gimple_assign_lhs (context)) == VAR_DECL)
++  lhs_var = gimple_assign_lhs (context);
++else if (TREE_CODE (gimple_assign_lhs (context)) == SSA_NAME)
++  lhs_var = SSA_NAME_VAR (gimple_assign_lhs (context));
++  }
++if (lhs_var
++&& (lhs_var_name = DECL_NAME (lhs_var))
++&& (lhs_var_name_str = IDENTIFIER_POINTER (lhs_var_name))
++&& (strcmp (lhs_var_name_str, var_name_str) == 0))
++  return;
 +
 + /* Get the variable declaration location from the def_stmt.  */
 + var_decl_loc = gimple_location (def_stmt);
@@ -834,7 +843,7 @@
  return;

/* Avoid warning if we've already done so or if the warning has been
-@@ -207,36 +245,56 @@ warn_uninit (opt_code opt, tree t, tree var, const char 
*gmsgid,
+@@ -207,36 +254,54 @@ warn_uninit (opt_code opt, tree t, tree var, const char 
*gmsgid,
if (((warning_suppressed_p (context, OPT_Wuninitialized)
 || (gimple_assign_single_p (context)
 && get_no_uninit_warning (gimple_assign_rhs1 (context)
@@ -863,25 +872,24 @@

auto_diagnostic_group d;
 -  if (!warning_at (location, opt, gmsgid, var))
+-return;
 +  char *gmsgid_final = XNEWVEC (char, strlen (gmsgid) + 5);
 +  gmsgid_final[0] = 0;
-+  if (var)
-+strcat (gmsgid_final, "%qD ");
-+  else if (var_name)
-+strcat (gmsgid_final, "%qs ");
++  strcat (gmsgid_final, var ? "%qD " : "%qs ");
 +  strcat (gmsgid_final, gmsgid);
 +
-+  if (var && !warning_at (location, opt, gmsgid_final, var))
-+return;
-+  else if (var_name && !warning_at (location, opt, gmsgid_final, 
var_name_str))
- return;
++  if ((var && !warning_at (location, opt, gmsgid_final, var))
++  || (var_name && !warning_at (location, opt, gmsgid_final, 
var_name_str)))
++{
++  XDELETE (gmsgid_final);
++  return;
++}
++  XDELETE (gmsgid_final);

/* Avoid subsequent warnings for reads of the same variable again.  */
 -  suppress_warning (var, opt);
-+  if (var)
-+suppress_warning (var, opt);
-+  else if (repl_var)
-+suppress_warning (repl_var, opt);
++  if (var || repl_var)
++suppress_warning (var ? var : repl_var, opt);

/* Issue a note pointing to the read variable unless the warning
   is at

Re: [PATCH v4 1/6] tree-object-size: Use trees and support negative offsets

2021-12-16 Thread Jakub Jelinek via Gcc-patches
On Thu, Dec 16, 2021 at 06:11:27AM +0530, Siddhesh Poyarekar wrote:
> On 12/16/21 00:13, Jakub Jelinek wrote:
> > On Wed, Dec 15, 2021 at 10:42:29PM +0530, Siddhesh Poyarekar wrote:
> > > On 12/15/21 20:51, Jakub Jelinek wrote:
> > > > Shouldn't this also tree_int_cst_compare (old_wholeval, wholeval) ?
> > > > 
> > > 
> > > AFAICT, there is no situation where wholeval changes but val doesn't, so I
> > > believe the val check should be sufficient.  Do you think otherwise?
> > 
> > Dunno, just something that caught my eye.
> 
> How about if I add an assert like so:
> 
>   if (tree_int_cst_compare (oldval, val))
> return true;
>   else
> {
>   gcc_checking_assert (tree_int_cst_compare (old_wholeval,
>  wholeval) == 0);
>   return false;
> }

Yes, but please fix up formatting, wholeval should go below old_wholeval.
Though, perhaps it would be better to:

  if (tree_int_cst_compare (oldval, val))
return true;

  gcc_checking_assert (tree_int_cst_compare (old_wholeval, wholeval) == 0);
  return false;

Ok with that change.

Jakub



[PATCH] vect: Fix multi-vector SLP gather loads [PR103744]

2021-12-16 Thread Richard Sandiford via Gcc-patches
[Repost with address typo fixed]

This PR shows that I didn't properly test the multi-vector case when
adding support for SLP gather loads.  The patch fixes that case using
the same approach as we do for non-SLP cases: keep the scalar base
the same, but iterate through the (also multi-vector) vector offsets.
“vec_num * j + i” is already used elsewhere as a way of handling both
the multi-vector SLP case and the multi-vector non-SLP case.

Tested on aarch64-linux-gnu.  It probably falls just short of
being obvious, so: OK to install?

Thanks,
Richard


gcc/
PR tree-optimization/103744
* tree-vect-stmts.c (vectorizable_load): Handle multi-vector
SLP gather loads.

gcc/testsuite/
PR tree-optimization/103744
* gcc.dg/vect/pr103744-1.c: New test.
* gcc.dg/vect/pr103744-2.c: Likewise.
---
 gcc/testsuite/gcc.dg/vect/pr103744-1.c | 20 +
 gcc/testsuite/gcc.dg/vect/pr103744-2.c | 31 ++
 gcc/tree-vect-stmts.c  |  6 +++--
 3 files changed, 55 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr103744-1.c
 create mode 100644 gcc/testsuite/gcc.dg/vect/pr103744-2.c

diff --git a/gcc/testsuite/gcc.dg/vect/pr103744-1.c 
b/gcc/testsuite/gcc.dg/vect/pr103744-1.c
new file mode 100644
index 000..1bc81e26fe4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr103744-1.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+
+int r;
+
+void
+foo (short int *s, short int *d1, short int *d2, int z)
+{
+  int *a;
+
+  while (z < 1)
+{
+  int i;
+
+  i = *s++ - (*d1++ + *d2++);
+  r += a[i];
+  i = *s++ - (*d1++ + *d2++);
+  r += a[i];
+  ++z;
+}
+}
diff --git a/gcc/testsuite/gcc.dg/vect/pr103744-2.c 
b/gcc/testsuite/gcc.dg/vect/pr103744-2.c
new file mode 100644
index 000..52307abf246
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr103744-2.c
@@ -0,0 +1,31 @@
+/* { dg-do compile } */
+
+int
+f1 (int *restrict x, unsigned short *restrict y)
+{
+  int res = 0;
+  for (int i = 0; i < 100; i += 2)
+{
+  unsigned short i1 = y[i + 0] + 1;
+  unsigned short i2 = y[i + 1] + 2;
+  res += x[i1];
+  res += x[i2];
+}
+  return res;
+}
+
+void
+f2 (int *restrict x, unsigned short *restrict y)
+{
+  int res1 = 0;
+  int res2 = 0;
+  for (int i = 0; i < 100; i += 2)
+{
+  unsigned short i1 = y[i + 0] + 1;
+  unsigned short i2 = y[i + 1] + 2;
+  res1 += x[i1];
+  res2 += x[i2];
+}
+  x[0] = res1;
+  x[1] = res2;
+}
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 8c427174b37..720cf36caaf 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -9247,6 +9247,8 @@ vectorizable_load (vec_info *vinfo,
   group_size = vec_num = 1;
   group_gap_adj = 0;
   ref_type = reference_alias_ptr_type (DR_REF (first_dr_info->dr));
+  if (slp)
+   vec_num = SLP_TREE_NUMBER_OF_VEC_STMTS (slp_node);
 }
 
   gcc_assert (alignment_support_scheme);
@@ -9592,7 +9594,7 @@ vectorizable_load (vec_info *vinfo,
final_mask = prepare_vec_mask (loop_vinfo, mask_vectype,
   final_mask, vec_mask, gsi);
 
- if (i > 0)
+ if (i > 0 && !STMT_VINFO_GATHER_SCATTER_P (stmt_info))
dataref_ptr = bump_vector_ptr (vinfo, dataref_ptr, ptr_incr,
   gsi, stmt_info, bump);
 
@@ -9609,7 +9611,7 @@ vectorizable_load (vec_info *vinfo,
&& gs_info.ifn != IFN_LAST)
  {
if (STMT_VINFO_GATHER_SCATTER_P (stmt_info))
- vec_offset = vec_offsets[j];
+ vec_offset = vec_offsets[vec_num * j + i];
tree zero = build_zero_cst (vectype);
tree scale = size_int (gs_info.scale);
gcall *call;
-- 
2.25.1



Re: [Patch]Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables

2021-12-16 Thread Qing Zhao via Gcc-patches


> On Dec 15, 2021, at 11:33 AM, Qing Zhao via Gcc-patches 
>  wrote:
> 
> 
> 
>> On Dec 14, 2021, at 4:06 PM, Martin Sebor  wrote:
>> 
>> 
> 
> Dynamically creating the string seems quite cumbersome here, and
> it leaks the allocated block.  I wonder if it might be better to
> remove the gmsgid argument from the function and assign it to
> one of the literals based on the other arguments.
> 
> Since only one of var and var_name is used, I also wonder if
> the %qs form could be used for both to simplify the overall
> logic.  (I.e., get the IDENTIFIER_POINTER string from var and
> use it instead of %qD).
>>> Looks like that using “%qs” + get the IDENTIFIER_POINTER string from var 
>>> did not work very well for the following testing case:
>>>  1 /* PR tree-optimization/45083 */
>>>  2 /* { dg-do compile } */
>>>  3 /* { dg-options "-O2 -Wuninitialized" } */
>>>  4
>>>  5 struct S { char *a; unsigned b; unsigned c; };
>>>  6 extern int foo (const char *);
>>>  7 extern void bar (int, int);
>>>  8
>>>  9 static void
>>> 10 baz (void)
>>> 11 {
>>> 12   struct S cs[1];   /* { dg-message "was declared here" } */
>>> 13   switch (cs->b)/* { dg-warning "cs\[^\n\r\]*\\.b\[^\n\r\]*is 
>>> used uninitialized" } */
>>> 14 {
>>> 15 case 101:
>>> 16   if (foo (cs->a))  /* { dg-warning "cs\[^\n\r\]*\\.a\[^\n\r\]*may 
>>> be used uninitialized" } */
>>> 17 bar (cs->c, cs->b); /* { dg-warning 
>>> "cs\[^\n\r\]*\\.c\[^\n\r\]*may be used uninitialized" } */
>>> 18 }
>>> 19 }
>>> 20
>>> 21 void
>>> 22 test (void)
>>> 23 {
>>> 24   baz ();
>>> 25 }
>>> For the uninitialized usages at line 13, 16, 17: the IDENTIFIER_POINTER 
>>> string of var are:
>>> cs$0$b, cs$0$a ,cs$0$c
>>> However, with %qD, they are printed as cs[0].b, cs[0].a, cs[0].c
>>> But with %qs, they are printed as cs$0$b, cs$0$a ,cs$0$c.
>>> Looks like that %qD does not simplify print out the IDENTIFIER_POINTER 
>>> string directly, it specially handle it for some cases.
>>> I tried to see how %qD specially handle the strings, but didn’t get it so 
>>> far.
>>> Do you know where the %qD handle this case specially?
>> 
>> In the front end's pretty printer where it handles %D (e.g.,
>> for C in c_tree_printer in c/c-objc-common.c).  For VARs with
>> DECL_HAS_DEBUG_EXPR_P (temp) the code uses DECL_DEBUG_EXPR().
>> 
>> There's also print_generic_expr_to_str(tree) that formats a decl
>> or an expression to a dynamically allocated string (the string
>> needs to be freed).
> 
> Thanks a lot.
> This resolved the issue.

However, there is another testing case gcc.dg/uninit-40.c still had issue when 
printing out the variable names:

 24   q[0] = bar (pt + __builtin_offsetof (struct T, u.b)); /* { dg-warning 
"'t\\.u\\.b' is used uninitialized" } */

I guess that there are other details I need to copy into the routine 
“warn_uninit”. 
So, I gave up copying the details of %D to the routine “warn_uninit”, and kept 
%D for Var.  that might be better.

thanks.

Qing



> 
> Qing
>> 
>> Martin
>> 
>>> Thanks.
>>> Qing
 Both are good suggestions, I will try to update the code based on this.
 
 Thanks again.
 
 Qing



Re: [Patch 8/8, Arm, GCC] Introduce multilibs for PACBTI target feature. [Was RE: [Patch 7/7, Arm, GCC] Introduce multilibs for PACBTI target feature.]

2021-12-16 Thread Andrea Corallo via Gcc-patches
Richard Earnshaw via Gcc-patches  writes:

> On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote:
>> 
>>> -Original Message-
>>> From: Gcc-patches >> bounces+belagod=gcc.gnu@gcc.gnu.org> On Behalf Of Tejas Belagod via
>>> Gcc-patches
>>> Sent: Friday, October 8, 2021 1:19 PM
>>> To: gcc-patches@gcc.gnu.org
>>> Subject: [Patch 7/7, Arm, GCC] Introduce multilibs for PACBTI target 
>>> feature.
>>>
>>> Hi,
>>>
>>> This patch adds a multilib for pacbti target feature.
>>>
>>> Tested on arm-none-eabi. OK for trunk?
>>>
>>> 2021-10-04  Tejas Belagod  
>>>
>>> gcc/ChangeLog:
>>>
>>> * config/arm/t-rmprofile: Add multilib rules for +pacbti.
>> This patch adds a multilib for pacbti target feature.
>> 2021-10-04  Tejas Belagod  
>> gcc/ChangeLog:
>>  * config/arm/t-rmprofile: Add multilib rules for +pacbti.
>> Tested the following configurations, OK for trunk?
>> -mthumb/-march=armv8.1-m.main+pacbti/-mfloat-abi=soft
>> -marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp
>> mcmodel=small and tiny
>> aarch64-none-linux-gnu native test and bootstrap
>> Thanks,
>> Tejas.
>> 
>
> I can't decide whether this is too much, or too little.  But it
> doesn't feel right as it is.
>
> Ideally we don't want yet another multilib.  It would be better to
> have one of the existing multilib variants made pac/bti safe.

Right, which one do you think we want to pick?

Thanks

  Andrea


[patch] Fix libfortran/101255, wrong IOSTAT value for FLUSH

2021-12-16 Thread FX via Gcc-patches
Hi,

Bug reported by Tobias at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101255
Trivial fix, adding a testcase.

Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to commit?

FX




pr98507.patch
Description: Binary data


Re: [Patch 9/9, GCC, Arm] Implement arm Function target attribute 'branch-protection'.

2021-12-16 Thread Andrea Corallo via Gcc-patches
Tejas Belagod via Gcc-patches  writes:

> Hi,
>
> This patch is part of the series of PACBTI-M patches posted earlier 
> https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582773.html
>
> This change adds the target function attribute 'branch-protection'.  The
> options that it can take are the same the command-line option
> 'mbranch-protection'.  The function attribute options override the command-
> line options for the function scope.
>
> Regression tested for arm-none-eabi. OK for trunk?
>
> 2021-11-11  Tejas Belagod  
>
> gcc/ChangeLog:
>   * config/arm/arm.c (arm_valid_target_attribute_rec): Add ARM function
>   attribute 'branch-protection' and parse its options.
>   * doc/extend.texi: Document ARM Function attribute 'branch-protection'.
>
> gcc/testsuite/
>   * gcc.target/arm/acle/pacbti-m-predef-7.c: New test.
>
> Thanks,
> Tejas.

[...]

Ping

  Andrea


[PATCH] libstdc++: Add %j, %U, %w, %W time_get support, fix %y, %Y, %C, %p [PR77760]

2021-12-16 Thread Jakub Jelinek via Gcc-patches
Hi!

glibc strptime passes around some state, what fields in struct tm have been
set and what needs to be finalized through possibly recursive calls, and
at the end performs various finalizations, like applying %p so that it
works for both %I %p and %p %I orders, or applying century so that both
%C %y and %y %C works, or computation of missing fields from others
(e.g. from %Y and %j one can compute tm_mon, tm_mday and tm_wday,
from %Y %U %w, %Y %W %w, %Y %U %a, or %Y %W %w one can compute
tm_mon, tm_mday, tm_yday or e.g. from %Y %m %d one can compute tm_wday
and tm_yday.

As the finalization is quite large and doesn't need to be a template
(doesn't depend on any iterators or char types), I've put it into libstdc++,
and left some padding in the state struct, so that perhaps in the future we
can track some more state without changing ABI.

Unfortunately, there is an ugly problem that the standard mandates that
get method calls the do_get virtual method and I don't see how we can
cary on any state in between those calls (even if we did an ABI change
for the facets, the methods are const, so that I think multiple threads
could use the same time_get objects and we couldn't store state in there).

There is a hack for that for GCC (seems to work with ICC too, doesn't work
with clang++) if the do_get method isn't overriden we can pass the state
around.

For both do_get_year and per IRC discussions also for %y, the behavior is
if 1-2 digits are parsed, the year is treated according to POSIX 2008 %y
rules (0-68 is 2000-2068, 69-99 is 1969-1999), if 3-4 digits are parsed,
it is treated as %Y.

Tested on x86_64-linux, ok for trunk if it passes full bootstrap/regtest?

2021-12-16  Jakub Jelinek  

PR libstdc++/77760
* include/bits/locale_facets_nonio.h (__time_get_state): New struct.
(time_get::_M_extract_via_format): Declare new method with
__time_get_state& as an extra argument.
* include/bits/locale_facets_nonio.tcc (_M_extract_via_format): Add
__state argument, set various fields in it while parsing.  Handle %j,
%U, %w and %W, fix up handling of %y, %Y and %C, don't adjust tm_hour
for %p immediately.  Add a wrapper around the method without the
__state argument for backwards compatibility.
(_M_extract_num): Remove all __len == 4 special cases.
(time_get::do_get_time, time_get::do_get_date, time_get::do_get): Zero
initialize __state, pass it to _M_extract_via_format and finalize it
at the end.
(do_get_year): For 1-2 digit parsed years, map 0-68 to 2000-2068,
69-99 to 1969-1999.  For 3-4 digit parsed years use that as year.
(get): If do_get isn't overloaded from the locale_facets_nonio.tcc
version, don't call do_get but call _M_extract_via_format instead to
pass around state.
* config/abi/pre/gnu.ver (GLIBCXX_3.4.30): Export _M_extract_via_format
with extra __time_get_state and __time_get_state::_M_finalize_state.
* src/c++98/locale_facets.cc (is_leap, day_of_the_week,
day_of_the_year): New functions in anon namespace.
(mon_yday): New var in anon namespace.
(__time_get_state::_M_finalize_state): Define.
* testsuite/22_locale/time_get/get/char/4.cc: New test.
* testsuite/22_locale/time_get/get/wchar_t/4.cc: New test.
* testsuite/22_locale/time_get/get_year/char/1.cc (test01): Parse 197
as year 197AD instead of error.
* testsuite/22_locale/time_get/get_year/char/5.cc (test01): Parse 1 as
year 2001 instead of error.
* testsuite/22_locale/time_get/get_year/char/6.cc: New test.
* testsuite/22_locale/time_get/get_year/wchar_t/1.cc (test01): Parse
197 as year 197AD instead of error.
* testsuite/22_locale/time_get/get_year/wchar_t/5.cc (test01): Parse
1 as year 2001 instead of error.
* testsuite/22_locale/time_get/get_year/wchar_t/6.cc: New test.

--- libstdc++-v3/include/bits/locale_facets_nonio.h.jj  2021-12-10 
22:17:54.541591942 +0100
+++ libstdc++-v3/include/bits/locale_facets_nonio.h 2021-12-16 
11:57:43.180762240 +0100
@@ -355,6 +355,30 @@ namespace std _GLIBCXX_VISIBILITY(defaul
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
+  struct __time_get_state
+  {
+// Finalize state.
+void
+_M_finalize_state(tm* __tm);
+
+unsigned int __have_I : 1;
+unsigned int __have_wday : 1;
+unsigned int __have_yday : 1;
+unsigned int __have_mon : 1;
+unsigned int __have_mday : 1;
+unsigned int __have_uweek : 1;
+unsigned int __have_wweek : 1;
+unsigned int __have_century : 1;
+unsigned int __is_pm : 1;
+unsigned int __want_century : 1;
+unsigned int __want_xday : 1;
+unsigned int __pad1 : 5;
+unsigned int __week_no : 6;
+unsigned int __pad2 : 10;
+int __century;
+int __pad3;
+  };
+
 _GLIBCXX_BEGIN_NAMESPACE_CXX11
 
   /**
@@ -756,6 +780,14 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   _

[PATCH] opts: do not do sanity check when an error is seen

2021-12-16 Thread Martin Liška

Do not check global options modification when an error is seen in parsing
of options (pragmas or attributes).

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR target/103709

gcc/c-family/ChangeLog:

* c-pragma.c (handle_pragma_pop_options): Do not check
global options modification when an error is seen in parsing
of options (pragmas or attributes).
---
 gcc/c-family/c-pragma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/c-family/c-pragma.c b/gcc/c-family/c-pragma.c
index c4ed4205820..0772c34342a 100644
--- a/gcc/c-family/c-pragma.c
+++ b/gcc/c-family/c-pragma.c
@@ -1132,7 +1132,7 @@ handle_pragma_pop_options (cpp_reader *ARG_UNUSED(dummy))
  p->optimize_binary);
   optimization_current_node = p->optimize_binary;
 }
-  if (flag_checking)
+  if (flag_checking && !seen_error ())
 {
   cl_optimization_compare (p->saved_global_options, &global_options);
   free (p->saved_global_options);
--
2.34.1



[patch] Fix libfortran/98507, handling of timezone near year boundaries

2021-12-16 Thread FX via Gcc-patches
Hi,

DATE_AND_TIME can return incorrect values for non-UTC timezones, near the new 
year, when the local time and UTC time are in different years. 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98507

Attached patch fixes the issue by correcting the logic to account for that 
wrapping of “day of the year” around new year. I include a testcase, which 
checks the sanity of values returned by DATE_AND_TIME. Since the bug only 
occurs for a few hours every year, and depends on local timezone, I could not 
think of a better (systematic) test.

I also want to propose (it’s not directly needed to fix the bug) that we switch 
our time routines to rely on clock_gettime() instead of gettimeofday(), when 
available. This is in line with POSIX.1-2008, which marks gettimeofday() as 
obsolete, recommending the use of 
clock_gettime() instead.

Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to commit?

FX




pr98507.patch
Description: Binary data


[GCC-10 PATCH] aarch64: enable Ampere-1 CPU

2021-12-16 Thread Philipp Tomsich
This adds support and a basic tuning model for the Ampere Computing
"Ampere-1" CPU.

The Ampere-1 implements the ARMv8.6 architecture in A64 mode and is
modelled as a 4-wide issue (as with all modern micro-architectures,
the chosen issue rate is a compromise between the maximum dispatch
rate and the maximum rate of uops issued to the scheduler).

This adds the -mcpu=ampere1 command-line option and the relevant cost
information/tuning tables for the Ampere-1.

gcc/ChangeLog:

* config/aarch64/aarch64-cores.def (AARCH64_CORE): New Ampere-1
core.
* config/aarch64/aarch64-tune.md: Regenerate.
* config/aarch64/aarch64-cost-tables.h: Add extra costs for
Ampere-1.
* config/aarch64/aarch64.c: Add tuning structures for Ampere-1.
* doc/invoke.texi: Add documentation for Ampere-1 core.

(cherry picked from commit 67b0d47e20e655c0dd53a76ea88aab60fafb2059)

---
This is a backport from master and only affects the AArch64 backend.
A similar change is already backported to GCC-11.

OK for GCC-10?

 gcc/config/aarch64/aarch64-cores.def |   3 +-
 gcc/config/aarch64/aarch64-cost-tables.h | 103 +++
 gcc/config/aarch64/aarch64-tune.md   |   2 +-
 gcc/config/aarch64/aarch64.c |  59 +
 gcc/doc/invoke.texi  |   2 +-
 5 files changed, 166 insertions(+), 3 deletions(-)

diff --git a/gcc/config/aarch64/aarch64-cores.def 
b/gcc/config/aarch64/aarch64-cores.def
index fc60e2ae1ac..3c858160cef 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -68,7 +68,8 @@ AARCH64_CORE("octeontx83",octeontxt83,   thunderx,  8A,  
AARCH64_FL_FOR_ARCH
 AARCH64_CORE("thunderxt81",   thunderxt81,   thunderx,  8A,  
AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  0x43, 
0x0a2, -1)
 AARCH64_CORE("thunderxt83",   thunderxt83,   thunderx,  8A,  
AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  0x43, 
0x0a3, -1)
 
-/* Ampere Computing cores. */
+/* Ampere Computing ('\xC0') cores. */
+AARCH64_CORE("ampere1", ampere1, cortexa57, 8_6A, AARCH64_FL_FOR_ARCH8_6, 
ampere1, 0xC0, 0xac3, -1)
 /* Do not swap around "emag" and "xgene1",
this order is required to handle variant correctly. */
 AARCH64_CORE("emag",emag,  xgene1,8A,  AARCH64_FL_FOR_ARCH8 | 
AARCH64_FL_CRC | AARCH64_FL_CRYPTO, emag, 0x50, 0x000, 3)
diff --git a/gcc/config/aarch64/aarch64-cost-tables.h 
b/gcc/config/aarch64/aarch64-cost-tables.h
index c6805717f6e..9f9627b864e 100644
--- a/gcc/config/aarch64/aarch64-cost-tables.h
+++ b/gcc/config/aarch64/aarch64-cost-tables.h
@@ -644,4 +644,107 @@ const struct cpu_cost_table a64fx_extra_costs =
   }
 };
 
+const struct cpu_cost_table ampere1_extra_costs =
+{
+  /* ALU */
+  {
+0, /* arith.  */
+0, /* logical.  */
+0, /* shift.  */
+COSTS_N_INSNS (1), /* shift_reg.  */
+0, /* arith_shift.  */
+COSTS_N_INSNS (1), /* arith_shift_reg.  */
+0, /* log_shift.  */
+COSTS_N_INSNS (1), /* log_shift_reg.  */
+0, /* extend.  */
+COSTS_N_INSNS (1), /* extend_arith.  */
+0, /* bfi.  */
+0, /* bfx.  */
+0, /* clz.  */
+0, /* rev.  */
+0, /* non_exec.  */
+true   /* non_exec_costs_exec.  */
+  },
+  {
+/* MULT SImode */
+{
+  COSTS_N_INSNS (3),   /* simple.  */
+  COSTS_N_INSNS (3),   /* flag_setting.  */
+  COSTS_N_INSNS (3),   /* extend.  */
+  COSTS_N_INSNS (4),   /* add.  */
+  COSTS_N_INSNS (4),   /* extend_add.  */
+  COSTS_N_INSNS (18)   /* idiv.  */
+},
+/* MULT DImode */
+{
+  COSTS_N_INSNS (3),   /* simple.  */
+  0,   /* flag_setting (N/A).  */
+  COSTS_N_INSNS (3),   /* extend.  */
+  COSTS_N_INSNS (4),   /* add.  */
+  COSTS_N_INSNS (4),   /* extend_add.  */
+  COSTS_N_INSNS (34)   /* idiv.  */
+}
+  },
+  /* LD/ST */
+  {
+COSTS_N_INSNS (4), /* load.  */
+COSTS_N_INSNS (4), /* load_sign_extend.  */
+0, /* ldrd (n/a).  */
+0, /* ldm_1st.  */
+0, /* ldm_regs_per_insn_1st.  */
+0, /* ldm_regs_per_insn_subsequent.  */
+COSTS_N_INSNS (5), /* loadf.  */
+COSTS_N_INSNS (5), /* loadd.  */
+COSTS_N_INSNS (5), /* load_unaligned.  */
+0, /* store.  */
+0, /* strd.  */
+0, /* stm_1st.  */
+0, /* stm_regs_per_insn_1st.  */
+0, /* stm_regs_per_insn_subsequent.  */
+COSTS_N_INSNS (2), /* storef.  */
+COSTS_N_INSNS (2), /* stored.  

[PATCH 40/40] openacc: Adjust testsuite to new "kernels" handling

2021-12-16 Thread Frederik Harwath

Adjust the testsuite to changed expectations with the new
Graphite-based "kernels" handling.

libgomp/ChangeLog:

* testsuite/libgomp.oacc-c++/privatized-ref-2.C: Adjust.
* testsuite/libgomp.oacc-c++/privatized-ref-3.C: Adjust.
* testsuite/libgomp.oacc-c-c++-common/acc_prof-kernels-1.c: Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose-ice-1.c:
Adjust.
* testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c: Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-local-worker-1.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-local-worker-2.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-local-worker-3.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-local-worker-4.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-local-worker-5.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-gang-1.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-gang-2.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-gang-3.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-gang-4.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-gang-5.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-gang-6.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-vector-1.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-vector-2.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-worker-1.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-worker-2.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-worker-3.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-worker-4.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-worker-5.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-worker-6.c:
Adjust.
* 
testsuite/libgomp.oacc-c-c++-common/kernels-private-vars-loop-worker-7.c:
Adjust.
* testsuite/libgomp.oacc-c-c++-common/loop-auto-1.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/pr84955-1.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/pr85381-2.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/pr85381-3.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/pr85381-4.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/pr85486-2.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/pr85486-3.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/pr85486.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/routine-nohost-1.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/vector-length-128-1.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/vector-length-128-2.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/vector-length-128-3.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/vector-length-128-4.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/vector-length-128-5.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/vector-length-128-6.c: Adjust.
* testsuite/libgomp.oacc-c-c++-common/vector-length-128-7.c: Adjust.
* testsuite/libgomp.oacc-fortran/if-1.f90: Adjust.
* testsuite/libgomp.oacc-fortran/kernels-acc-loop-reduction-2.f90:
Adjust.
* testsuite/libgomp.oacc-fortran/kernels-private-vars-loop-gang-1.f90:
Adjust.
* testsuite/libgomp.oacc-fortran/kernels-private-vars-loop-gang-2.f90:
Adjust.
* testsuite/libgomp.oacc-fortran/kernels-private-vars-loop-gang-3.f90:
Adjust.
* testsuite/libgomp.oacc-fortran/kernels-private-vars-loop-gang-6.f90:
Adjust.
* testsuite/libgomp.oacc-fortran/kernels-private-vars-loop-vector-1.f90:
Adjust.
* testsuite/libgomp.oacc-fortran/kernels-private-vars-loop-vector-2.f90:
Adjust.
* testsuite/libgomp.oacc-fortran/kernels-private-vars-loop-worker-1.f90:
Adjust.
* testsuite/libgomp.oacc-fortran/kernels-private-vars-loop-worker-2.f90:
Adjust.
* testsuite/libgomp.oacc-fortran/kernels-private-vars-loop-worker-3.f90:
Adjust.
* testsuite/libgomp.oacc-fortran/kernels-private-vars-loop-worker-4.f90:
Adjust.
* testsuite/libgomp.oacc-fortran/kernels-private-vars-loop-worker-5.f90:
Adjust.
* testsuite/libgomp.oacc-fortran/kernels-private-

Re: GCC 11 backports

2021-12-16 Thread Martin Liška

On 11/8/21 13:26, Martin Liška wrote:

On 11/5/21 17:08, Martin Liška wrote:

On 8/23/21 10:54, Martin Liška wrote:

On 8/16/21 13:13, Martin Liška wrote:

I'm going to apply the following 3 tested patches.

Martin


One more patch I've just tested.

Martin


And one more backport.

Martin


One more tested patch.

Martin


And one more tested patch.

MartinFrom d4e305e4498039b921070418069a68648188b196 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 13 Dec 2021 15:34:30 +0100
Subject: [PATCH] i386: Fix emissing of __builtin_cpu_supports.

	PR target/103661

gcc/ChangeLog:

	* config/i386/i386-builtins.c (fold_builtin_cpu): Compare to 0
	as API expects that non-zero values are returned (do that
	it mask == 31).
	For "avx512vbmi2" argument, we return now 1 << 31, which is a
	negative integer value.

(cherry picked from commit 127c7178d5ec502d95862fd823537cbca1a0cb99)
---
 gcc/config/i386/i386-builtins.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/config/i386/i386-builtins.c b/gcc/config/i386/i386-builtins.c
index 128bd39816c..59575aea795 100644
--- a/gcc/config/i386/i386-builtins.c
+++ b/gcc/config/i386/i386-builtins.c
@@ -2236,7 +2236,11 @@ fold_builtin_cpu (tree fndecl, tree *args)
   /* Return __cpu_model.__cpu_features[0] & field_val  */
   final = build2 (BIT_AND_EXPR, unsigned_type_node, array_elt,
 		  build_int_cstu (unsigned_type_node, field_val));
-  return build1 (CONVERT_EXPR, integer_type_node, final);
+  if (isa_names_table[i].feature == (INT_TYPE_SIZE - 1))
+	return build2 (NE_EXPR, integer_type_node, final,
+		   build_int_cst (unsigned_type_node, 0));
+  else
+	return build1 (CONVERT_EXPR, integer_type_node, final);
 }
   gcc_unreachable ();
 }
-- 
2.34.1



Re: [PATCH 1/3] loop-invariant: Don't move cold bb instructions to preheader in RTL

2021-12-16 Thread Jan Hubicka via Gcc-patches
>  
> OK. Comments like?
> 
> /* Don't move insn of cold BB out of loop to preheader to reduce calculations
>and register live range in hot loop with cold BB.  */

Looks good.
> 
> 
> And maybe some dump log will help tracking in xxx.c.271r.loop2_invariant.
> 
> --- a/gcc/loop-invariant.c
> +++ b/gcc/loop-invariant.c
> @@ -1190,7 +1190,12 @@ find_invariants_bb (class loop *loop, basic_block bb, 
> bool always_reached,
>basic_block preheader = loop_preheader_edge (loop)->src;
> 
>if (preheader->count > bb->count)
> -return;
> +{
> +  if (dump_file)
> +   fprintf (dump_file, "Don't move invariant from bb: %d in loop %d\n",
> +bb->index, loop->num);
> +  return;
> +}

This is also a good idea - testcases are quite important for this typo
of stuff.
> > 
> > Thinking about this more, you want to test:
> >   if (!always_executed && preheader->count > bb->count)
> > return;
> > This will rule out some profile misupates.
> > 
> > Also the code updating always_reached is worng:
> >   if (always_reached
> >   && CALL_P (insn)
> >   && (RTL_LOOPING_CONST_OR_PURE_CALL_P (insn)
> >   || ! RTL_CONST_OR_PURE_CALL_P (insn)))
> >   always_reached = false;
> > It misses the case where statement can trhow external exception or
> > volatile asms that can also terminate execution.
> > 
> > I bit worry on how often the test will have false positives with guessed
> > profile where earlier loop optimizations reduced trip count below
> > realistic estimate.
> 
> Sorry I don't understand why always_executed and always_reached matters here?
> the test is based on BB before the FOR_BB_INSNS loop...

always_executed is useful here to avoid the situation where bb->count or
preheader->count is wrong and it would disable wanted transformation.

always_executed is just a bug I noticed while looking at the code.  I
will produce testcase for bugzilla.

Honza


Re: [PATCH 2/3] Fix incorrect loop exit edge probability [PR103270]

2021-12-16 Thread Jan Hubicka via Gcc-patches
> > 
> > 
> > ./contrib/analyze_brprob.py ~/workspace/tests/spec2017/dump_file_all
> > HEURISTICS   BRANCHES  (REL)  BR. HITRATE   
> >  HITRATE   COVERAGE COVERAGE  (REL)  predict.def  (REL) HOT 
> > branches (>10%)
> > noreturn call   1   0.0%  100.00%   
> > 50.00% /  50.00%  2 2.00   0.0% 100%:1
> > Fortran zero-sized array3   0.0%   66.67%   
> > 41.71% /  60.50%362   362.00   0.0% 100%:3
> > loop iv compare16   0.0%   93.75%   
> > 98.26% /  98.76% 279847  279.85k   0.0% 93%:4
> > __builtin_expect   35   0.0%   97.14%   
> > 78.09% /  78.35%   17079558   17.08M   0.0%
> > loop guard with recursion  45   0.1%   86.67%   
> > 85.13% /  85.14% 67224244126.72G   1.3% 74%:4
> > extra loop exit80   0.1%   58.75%   
> > 81.49% /  89.21%  438470261  438.47M   0.1% 86%:3
> > guess loop iv compare 235   0.3%   80.85%   
> > 52.83% /  73.97%  148558247  148.56M   0.0% 47%:3
> > negative return   241   0.3%   71.37%   
> > 25.33% /  92.61%  250402383  250.40M   0.0% 69%:2
> > loop exit with recursion  315   0.4%   74.60%   
> > 85.07% /  85.71% 94031368589.40G   1.8% 59%:4
> > const return  320   0.4%   51.88%   
> > 90.45% /  95.63%  925341727  925.34M   0.2% 76%:5
> > indirect call 377   0.5%   51.46%   
> > 84.72% /  91.14% 21337728482.13G   0.4% 69%:1
> > polymorphic call  410   0.5%   44.15%   
> > 31.26% /  79.37% 32726882443.27G   0.6% 53%:2
> > recursive call506   0.7%   39.53%   
> > 44.97% /  83.92% 12110368061.21G   0.2% 10%:1
> > goto  618   0.8%   64.24%   
> > 65.37% /  83.57%  702446178  702.45M   0.1% 20%:1
> > null return   800   1.1%   64.62%   
> > 56.59% /  77.70%  603952067  603.95M   0.1% 28%:2
> > continue  956   1.3%   63.70%   
> > 65.65% /  79.97% 37803037993.78G   0.7% 52%:3
> > loop guard   1177   1.6%   56.33%   
> > 42.54% /  80.32% 73736014577.37G   1.4% 50%:2
> > opcode values positive (on trees)2020   2.7%   62.38%   
> > 64.16% /  84.44%31695571761   31.70G   6.0% 21%:2
> > loop exit3293   4.4%   76.19%   
> > 87.18% /  88.35%50377138963   50.38G   9.6% 18%:1
> > loop iterations  4761   6.3%   99.98%   
> > 84.27% /  84.27%73463634555   73.46G  13.9%
> > pointer (on trees)   8076  10.7%   56.23%   
> > 69.36% /  83.15%1232201   12.32G   2.3%
> > call11396  15.1%   64.14%   
> > 74.13% /  89.82%25197949198   25.20G   4.8% 34%:1
> > opcode values nonequal (on trees)   12237  16.3%   70.70%   
> > 70.86% /  83.54%36638772333   36.64G   6.9%
> > guessed loop iterations 16760  22.3%   99.78%   
> > 91.49% /  91.49%   162952747918  162.95G  30.9%
> > 
> > HEURISTICS   BRANCHES  (REL)  BR. HITRATE   
> >  HITRATE   COVERAGE COVERAGE  (REL)  predict.def  (REL) HOT 
> > branches (>10%)
> > no prediction   12730  16.9%   39.29%   
> > 33.32% /  79.93%   121106031835  121.11G  23.0%
> > first match 25261  33.6%   92.17%   
> > 88.33% /  88.98%   296652487962  296.65G  56.3%
> > DS theory   28333  37.7%   63.03%   
> > 72.05% /  85.00%   109563734005  109.56G  20.8%
> > combined75232 100.0%   73.17%   
> > 72.32% /  86.08%   527351738575  527.35G 100.0%
> > 
> > Loop count: 37870
> >   avg. # of iter: 8444.77
> >   median # of iter: 7.00
> >   avg. (1% cutoff) # of iter: 174.68
> >   avg. (5% cutoff) # of iter: 55.14
> >   avg. (10% cutoff) # of iter: 35.21
> >   avg. (20% cutoff) # of iter: 26.23
> >   avg. (30% cutoff) # of iter: 21.70
> 
> This is the output data collected without the patch, as can be seen, no 
> difference on "extra loop exit".
> But this issue should be fixed.
> 
> 
> ./contrib/

[PATCH] pragma: respect pragma in lambda functions

2021-12-16 Thread Martin Liška

In g:01ad8c54fdca we started supporting target pragma changes
that are primarily caused by optimization option. The same can happen
in the opposite way and we need to check for changes both
in optimization_current_node and target_option_current_node.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR c++/103696

gcc/ChangeLog:

* attribs.c (decl_attributes): Check if
target_option_current_node is changed.

gcc/testsuite/ChangeLog:

* g++.target/i386/pr103696.C: New test.
---
 gcc/attribs.c|  3 ++-
 gcc/testsuite/g++.target/i386/pr103696.C | 25 
 2 files changed, 27 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.target/i386/pr103696.C

diff --git a/gcc/attribs.c b/gcc/attribs.c
index 01a9ed66485..29703e75fba 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -605,7 +605,8 @@ decl_attributes (tree *node, tree attributes, int flags,
 }
 
   if (TREE_CODE (*node) == FUNCTION_DECL

-  && optimization_current_node != optimization_default_node
+  && (optimization_current_node != optimization_default_node
+ || target_option_current_node != target_option_default_node)
   && !DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node))
 {
   DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node) = optimization_current_node;
diff --git a/gcc/testsuite/g++.target/i386/pr103696.C 
b/gcc/testsuite/g++.target/i386/pr103696.C
new file mode 100644
index 000..de7d5c68be9
--- /dev/null
+++ b/gcc/testsuite/g++.target/i386/pr103696.C
@@ -0,0 +1,25 @@
+// PR c++/103696
+// { dg-options "-O2 -std=c++14 -fdump-tree-optimized" }
+
+int global_var;
+
+void fn() {
+}
+
+#pragma GCC optimize("finite-math-only")
+#pragma GCC target("sse3")
+
+void fn2() {
+}
+
+void fn3() {
+}
+
+int solve() {
+auto nested = []() {
+return global_var;
+};
+return nested();
+}
+
+/* { dg-final { scan-tree-dump-not "lambda" "optimized" } } */
--
2.34.1



RE: [PATCH][GCC] aarch64: fix: ls64 tests fail on aarch64_be [PR103729]

2021-12-16 Thread Przemyslaw Wirkus via Gcc-patches



> -Original Message-
> From: Richard Sandiford 
> Sent: 16 December 2021 10:46
> To: Przemyslaw Wirkus 
> Cc: gcc-patches@gcc.gnu.org; christophe.l...@linaro.org; Richard Earnshaw
> ; Kyrylo Tkachov ;
> Marcus Shawcroft 
> Subject: Re: [PATCH][GCC] aarch64: fix: ls64 tests fail on aarch64_be 
> [PR103729]
> 
> Przemyslaw Wirkus  writes:
> > Hi,
> >
> > This patch is sorting issue with LS64 intrinsics tests failing with
> > AArch64_be targets.
> >
> > Regtested on aarch64_be_elf and aarch64_elf, no issues.
> >
> > OK to install?
> >
> > gcc/ChangeLog:
> >
> > PR target/PR103729
> > * config/aarch64/aarch64-simd.md (aarch64_movv8di): Allow big
> endian
> > targets to move V8DI.
> 
> OK, thanks.

Thank you.

commit 0a68862e782847752be0ea2b2a987278cdbefc9e

Przemek

> Richard
> 
> > diff --git a/gcc/config/aarch64/aarch64-simd.md
> > b/gcc/config/aarch64/aarch64-simd.md
> > index
> >
> 9ebf795a624f0183e049d0db7a71ba2d17dd..f95a7e1d91c97c9e981d75e71
> f0b
> > 49c02ef748ba 100644
> > --- a/gcc/config/aarch64/aarch64-simd.md
> > +++ b/gcc/config/aarch64/aarch64-simd.md
> > @@ -7265,9 +7265,8 @@ (define_insn "*aarch64_mov"
> >  (define_insn "*aarch64_movv8di"
> >[(set (match_operand:V8DI 0 "nonimmediate_operand" "=r,m,r")
> > (match_operand:V8DI 1 "general_operand" " r,r,m"))]
> > -  "!BYTES_BIG_ENDIAN
> > -   && (register_operand (operands[0], V8DImode)
> > -   || register_operand (operands[1], V8DImode))"
> > +  "(register_operand (operands[0], V8DImode)
> > +|| register_operand (operands[1], V8DImode))"
> >"#"
> >[(set_attr "type" "multiple,multiple,multiple")
> > (set_attr "length" "32,16,16")]


Re: [PATCH][GCC] aarch64: fix: ls64 tests fail on aarch64_be [PR103729]

2021-12-16 Thread Richard Sandiford via Gcc-patches
Przemyslaw Wirkus  writes:
> Hi,
>
> This patch is sorting issue with LS64 intrinsics tests failing with
> AArch64_be targets.
>
> Regtested on aarch64_be_elf and aarch64_elf, no issues.
>
> OK to install?
>
> gcc/ChangeLog:
>
>   PR target/PR103729
>   * config/aarch64/aarch64-simd.md (aarch64_movv8di): Allow big endian
>   targets to move V8DI.

OK, thanks.

Richard

> diff --git a/gcc/config/aarch64/aarch64-simd.md 
> b/gcc/config/aarch64/aarch64-simd.md
> index 
> 9ebf795a624f0183e049d0db7a71ba2d17dd..f95a7e1d91c97c9e981d75e71f0b49c02ef748ba
>  100644
> --- a/gcc/config/aarch64/aarch64-simd.md
> +++ b/gcc/config/aarch64/aarch64-simd.md
> @@ -7265,9 +7265,8 @@ (define_insn "*aarch64_mov"
>  (define_insn "*aarch64_movv8di"
>[(set (match_operand:V8DI 0 "nonimmediate_operand" "=r,m,r")
>   (match_operand:V8DI 1 "general_operand" " r,r,m"))]
> -  "!BYTES_BIG_ENDIAN
> -   && (register_operand (operands[0], V8DImode)
> -   || register_operand (operands[1], V8DImode))"
> +  "(register_operand (operands[0], V8DImode)
> +|| register_operand (operands[1], V8DImode))"
>"#"
>[(set_attr "type" "multiple,multiple,multiple")
> (set_attr "length" "32,16,16")]


[PATCH] libiberty: support digits in cpp mangled clone names

2021-12-16 Thread lsix--- via Gcc-patches
From: Lancelot SIX 

Currently libiberty fails to demangle the name of cloned functions if
the clone-type-identifier contains numbers.

This can be observed with the following example:

$ cat > ex.cc 

[PATCH][GCC] aarch64: fix: ls64 tests fail on aarch64_be [PR103729]

2021-12-16 Thread Przemyslaw Wirkus via Gcc-patches
Hi,

This patch is sorting issue with LS64 intrinsics tests failing with
AArch64_be targets.

Regtested on aarch64_be_elf and aarch64_elf, no issues.

OK to install?

gcc/ChangeLog:

PR target/PR103729
* config/aarch64/aarch64-simd.md (aarch64_movv8di): Allow big endian
targets to move V8DI.


rb15153.patch
Description: rb15153.patch


Re: [Patch] For -foffload= suggest also 'disable' and 'default' [PR103644]

2021-12-16 Thread Jakub Jelinek via Gcc-patches
On Thu, Dec 16, 2021 at 10:53:20AM +0100, Tobias Burnus wrote:
> On 16.12.21 10:24, Jakub Jelinek wrote:
> > Neither default nor disable are valid offload targets, so I think we need
> > to reword the note. valid ‘-foffload=’ arguments are:
> > or so?
> 
> Granted. For the second line, I concur – I am not quite
> sure about the first line, i.e.
>   gcc: error: GCC is not configured to support ‘nvptx’ as offload target
> is nicer than
>   gcc: error: GCC is not configured to support ‘nvptx’ as ‘-foffload=’ 
> argument
> while for disabled, the second version is better for misspelled arguments 
> like 'disabled'.
> 
> I have now used the second version:
> 
> gcc: error: GCC is not configured to support ‘disabled’ as ‘-foffload=’ 
> argument
> gcc: note: valid ‘-foffload=’ arguments are: default disable; did you mean 
> ‘disable’?
> 
> gcc: error: GCC is not configured to support ‘x’ as ‘-foffload=’ argument
> gcc: note: valid ‘-foffload=’ arguments are: default disable
> 
> Tobias
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955

> For -foffload= suggest also 'disable' and 'default' [PR103644]
> 
> gcc/ChangeLog:
> 
>   PR driver/103644
>   * gcc.c (check_offload_target_name): Add 'default' and 'disable'
>   to the candidate list.

Ok, thanks.

> diff --git a/gcc/gcc.c b/gcc/gcc.c
> index 694c2573109..b75b50b87b2 100644
> --- a/gcc/gcc.c
> +++ b/gcc/gcc.c
> @@ -4017,26 +4017,25 @@ check_offload_target_name (const char *target, 
> ptrdiff_t len)
>memcpy (cand, OFFLOAD_TARGETS, olen);
>for (c = strtok (cand, ","); c; c = strtok (NULL, ","))
>   candidates.safe_push (c);
> +  candidates.safe_push ("default");
> +  candidates.safe_push ("disable");
>  
>char *target2 = XALLOCAVEC (char, len + 1);
>memcpy (target2, target, len);
>target2[len] = '\0';
>  
> -  error ("GCC is not configured to support %qs as offload target", 
> target2);
> +  error ("GCC is not configured to support %qs as %<-foffload=%> 
> argument",
> +  target2);
>  
> -  if (candidates.is_empty ())
> - inform (UNKNOWN_LOCATION, "no offloading targets configured");
> +  char *s;
> +  const char *hint = candidates_list_and_hint (target2, s, candidates);
> +  if (hint)
> + inform (UNKNOWN_LOCATION,
> + "valid %<-foffload=%> arguments are: %s; "
> + "did you mean %qs?", s, hint);
>else
> - {
> -   char *s;
> -   const char *hint = candidates_list_and_hint (target2, s, candidates);
> -   if (hint)
> - inform (UNKNOWN_LOCATION,
> - "valid offload targets are: %s; did you mean %qs?", s, 
> hint);
> -   else
> - inform (UNKNOWN_LOCATION, "valid offload targets are: %s", s);
> -   XDELETEVEC (s);
> - }
> + inform (UNKNOWN_LOCATION, "valid %<-foffload=%> arguments are: %s", s);
> +  XDELETEVEC (s);
>return false;
>  }
>return true;


Jakub



Re: [Patch] For -foffload= suggest also 'disable' and 'default' [PR103644]

2021-12-16 Thread Tobias Burnus

On 16.12.21 10:24, Jakub Jelinek wrote:

Neither default nor disable are valid offload targets, so I think we need
to reword the note. valid ‘-foffload=’ arguments are:
or so?


Granted. For the second line, I concur – I am not quite
sure about the first line, i.e.
  gcc: error: GCC is not configured to support ‘nvptx’ as offload target
is nicer than
  gcc: error: GCC is not configured to support ‘nvptx’ as ‘-foffload=’ argument
while for disabled, the second version is better for misspelled arguments like 
'disabled'.

I have now used the second version:

gcc: error: GCC is not configured to support ‘disabled’ as ‘-foffload=’ argument
gcc: note: valid ‘-foffload=’ arguments are: default disable; did you mean 
‘disable’?

gcc: error: GCC is not configured to support ‘x’ as ‘-foffload=’ argument
gcc: note: valid ‘-foffload=’ arguments are: default disable

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
For -foffload= suggest also 'disable' and 'default' [PR103644]

gcc/ChangeLog:

	PR driver/103644
	* gcc.c (check_offload_target_name): Add 'default' and 'disable'
	to the candidate list.

 gcc/gcc.c | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/gcc/gcc.c b/gcc/gcc.c
index 694c2573109..b75b50b87b2 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -4017,26 +4017,25 @@ check_offload_target_name (const char *target, ptrdiff_t len)
   memcpy (cand, OFFLOAD_TARGETS, olen);
   for (c = strtok (cand, ","); c; c = strtok (NULL, ","))
 	candidates.safe_push (c);
+  candidates.safe_push ("default");
+  candidates.safe_push ("disable");
 
   char *target2 = XALLOCAVEC (char, len + 1);
   memcpy (target2, target, len);
   target2[len] = '\0';
 
-  error ("GCC is not configured to support %qs as offload target", target2);
+  error ("GCC is not configured to support %qs as %<-foffload=%> argument",
+	 target2);
 
-  if (candidates.is_empty ())
-	inform (UNKNOWN_LOCATION, "no offloading targets configured");
+  char *s;
+  const char *hint = candidates_list_and_hint (target2, s, candidates);
+  if (hint)
+	inform (UNKNOWN_LOCATION,
+		"valid %<-foffload=%> arguments are: %s; "
+		"did you mean %qs?", s, hint);
   else
-	{
-	  char *s;
-	  const char *hint = candidates_list_and_hint (target2, s, candidates);
-	  if (hint)
-	inform (UNKNOWN_LOCATION,
-		"valid offload targets are: %s; did you mean %qs?", s, hint);
-	  else
-	inform (UNKNOWN_LOCATION, "valid offload targets are: %s", s);
-	  XDELETEVEC (s);
-	}
+	inform (UNKNOWN_LOCATION, "valid %<-foffload=%> arguments are: %s", s);
+  XDELETEVEC (s);
   return false;
 }
   return true;


Re: [Patch] For -foffload= suggest also 'disable' and 'default' [PR103644]

2021-12-16 Thread Jakub Jelinek via Gcc-patches
On Thu, Dec 16, 2021 at 10:12:24AM +0100, Tobias Burnus wrote:
> I did run into this when misspelling 'disable':
> 
> Currently (with one offload target configured)
> 
> $ gcc -foffload=disabled
> gcc: error: GCC is not configured to support 'disabled' as offload target
> gcc: note: valid offload targets are: amdgcn-amdhsa
> 
> or (without offload support)
> 
> $ gcc -foffload=disabled
> gcc: error: GCC is not configured to support ‘disabled’ as offload target
> gcc: note: no offloading targets configured
> 
> 
> With the patch:
> 
> $ gcc -foffload=disabled
> gcc: error: GCC is not configured to support 'disabled' as offload target
> gcc: note: valid offload targets are: nvptx-none default disable; did you 
> mean 'disable'?
> 
> or
> 
> $ gcc -foffload=disabled
> gcc: error: GCC is not configured to support ‘disabled’ as offload target
> gcc: note: valid offload targets are: default disable; did you mean ‘disable’?
> 
> or without hint
> 
> $ gcc -foffload=x
> gcc: error: GCC is not configured to support ‘x’ as offload target
> gcc: note: valid offload targets are: default disable

Neither default nor disable are valid offload targets, so I think we need
to reword the note. valid ‘-foffload=’ arguments are:
or so?

Jakub



[Patch] For -foffload= suggest also 'disable' and 'default' [PR103644]

2021-12-16 Thread Tobias Burnus

I did run into this when misspelling 'disable':

Currently (with one offload target configured)

$ gcc -foffload=disabled
gcc: error: GCC is not configured to support 'disabled' as offload target
gcc: note: valid offload targets are: amdgcn-amdhsa

or (without offload support)

$ gcc -foffload=disabled
gcc: error: GCC is not configured to support ‘disabled’ as offload target
gcc: note: no offloading targets configured


With the patch:

$ gcc -foffload=disabled
gcc: error: GCC is not configured to support 'disabled' as offload target
gcc: note: valid offload targets are: nvptx-none default disable; did you mean 
'disable'?

or

$ gcc -foffload=disabled
gcc: error: GCC is not configured to support ‘disabled’ as offload target
gcc: note: valid offload targets are: default disable; did you mean ‘disable’?

or without hint

$ gcc -foffload=x
gcc: error: GCC is not configured to support ‘x’ as offload target
gcc: note: valid offload targets are: default disable


OK for mainline?

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
For -foffload= suggest also 'disable' and 'default' [PR103644]

gcc/ChangeLog:

	PR driver/103644
	* gcc.c (check_offload_target_name): Add 'default' and 'disable'
	to the candidate list.

diff --git a/gcc/gcc.c b/gcc/gcc.c
index 694c2573109..7eaa7c9d8dc 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -4017,6 +4017,8 @@ check_offload_target_name (const char *target, ptrdiff_t len)
   memcpy (cand, OFFLOAD_TARGETS, olen);
   for (c = strtok (cand, ","); c; c = strtok (NULL, ","))
 	candidates.safe_push (c);
+  candidates.safe_push ("default");
+  candidates.safe_push ("disable");
 
   char *target2 = XALLOCAVEC (char, len + 1);
   memcpy (target2, target, len);
@@ -4024,19 +4026,14 @@ check_offload_target_name (const char *target, ptrdiff_t len)
 
   error ("GCC is not configured to support %qs as offload target", target2);
 
-  if (candidates.is_empty ())
-	inform (UNKNOWN_LOCATION, "no offloading targets configured");
+  char *s;
+  const char *hint = candidates_list_and_hint (target2, s, candidates);
+  if (hint)
+	inform (UNKNOWN_LOCATION,
+		"valid offload targets are: %s; did you mean %qs?", s, hint);
   else
-	{
-	  char *s;
-	  const char *hint = candidates_list_and_hint (target2, s, candidates);
-	  if (hint)
-	inform (UNKNOWN_LOCATION,
-		"valid offload targets are: %s; did you mean %qs?", s, hint);
-	  else
-	inform (UNKNOWN_LOCATION, "valid offload targets are: %s", s);
-	  XDELETEVEC (s);
-	}
+	inform (UNKNOWN_LOCATION, "valid offload targets are: %s", s);
+  XDELETEVEC (s);
   return false;
 }
   return true;


Re: [PATCH] [i386] Add option -mvect-compare-costs

2021-12-16 Thread Hongtao Liu via Gcc-patches
On Thu, Dec 16, 2021 at 5:00 PM Richard Sandiford via Gcc-patches
 wrote:
>
> Obviously I'm not in a position to comment on the target bits, but:
>
> liuhongt via Gcc-patches  writes:
> > Also with corresponding target attribute, option default disabled.
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > Ok for trunk?
> >
> > gcc/ChangeLog:
> >
> >   * config/i386/i386-options.c (ix86_target_string): Handle
> >   -mvect-compare-costs.
> >   (ix86_valid_target_attribute_inner_p): Support target attribute
> >   vect-compare-costs.
> >   * config/i386/i386.c (ix86_autovectorize_vector_modes): Return
> >   1 when TARGET_X86_VECT_COMPARE_COSTS.
> >   * config/i386/i386.opt: Add option -mvect-compare-costs.
> >   * doc/invoke.texi: Document -mvect-compare-costs.
> > ---
> >  gcc/config/i386/i386-options.c | 7 ++-
> >  gcc/config/i386/i386.c | 2 +-
> >  gcc/config/i386/i386.opt   | 5 +
> >  gcc/doc/invoke.texi| 7 ++-
> >  4 files changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
> > index 53bd55a12e3..53794b13fc5 100644
> > --- a/gcc/config/i386/i386-options.c
> > +++ b/gcc/config/i386/i386-options.c
> > @@ -406,7 +406,8 @@ ix86_target_string (HOST_WIDE_INT isa, HOST_WIDE_INT 
> > isa2,
> >/* Additional flag options.  */
> >static struct ix86_target_opts flag2_opts[] =
> >{
> > -{ "-mgeneral-regs-only", OPTION_MASK_GENERAL_REGS_ONLY }
> > +{ "-mgeneral-regs-only", OPTION_MASK_GENERAL_REGS_ONLY },
> > +{ "-mvect-compare-costs",
> > OPTION_MASK_X86_VECT_COMPARE_COSTS }
> >};
> >
> >const char *opts[ARRAY_SIZE (isa_opts) + ARRAY_SIZE (isa2_opts)
> > @@ -,6 +1112,10 @@ ix86_valid_target_attribute_inner_p (tree fndecl, 
> > tree args, char *p_strings[],
> >   OPT_mgeneral_regs_only,
> >   OPTION_MASK_GENERAL_REGS_ONLY),
> >
> > +IX86_ATTR_IX86_YES ("vect-compare-costs",
> > + OPT_mvect_compare_costs,
> > + OPTION_MASK_X86_VECT_COMPARE_COSTS),
> > +
> >  IX86_ATTR_YES ("relax-cmpxchg-loop",
> >  OPT_mrelax_cmpxchg_loop,
> >  MASK_RELAX_CMPXCHG_LOOP),
> > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> > index 9f4ed34ffd5..8d3fc3be1b9 100644
> > --- a/gcc/config/i386/i386.c
> > +++ b/gcc/config/i386/i386.c
> > @@ -22836,7 +22836,7 @@ ix86_autovectorize_vector_modes (vector_modes 
> > *modes, bool all)
> >if (TARGET_SSE2)
> >  modes->safe_push (V4QImode);
> >
> > -  return 0;
> > +  return TARGET_X86_VECT_COMPARE_COSTS ? 1 : 0;
>
> as far as the interface goes, it'd be better to use VECT_COMPARE_COSTS
> instead of 1 here.
>
Thanks, will change.
> Thanks,
> Richard
>
> >  }
> >
> >  /* Implemenation of targetm.vectorize.get_mask_mode.  */
> > diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
> > index e1af3e417b0..80c7a073d07 100644
> > --- a/gcc/config/i386/i386.opt
> > +++ b/gcc/config/i386/i386.opt
> > @@ -1206,3 +1206,8 @@ Support MWAIT and MONITOR built-in functions and code 
> > generation.
> >  mavx512fp16
> >  Target Mask(ISA2_AVX512FP16) Var(ix86_isa_flags2) Save
> >  Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, AVX512F 
> > and AVX512FP16 built-in functions and code generation.
> > +
> > +mvect-compare-costs
> > +Target Mask(X86_VECT_COMPARE_COSTS) Var(ix86_target_flags) Save
> > +Tells the loop vectorizer to try all the provided vector lengths and pick 
> > the
> > +one with the lowest cost.
> > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > index 80c36b9abe0..fa2f63af65f 100644
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -1428,7 +1428,7 @@ See RS/6000 and PowerPC Options.
> >  -malign-data=@var{type}  -mstack-protector-guard=@var{guard} @gol
> >  -mstack-protector-guard-reg=@var{reg} @gol
> >  -mstack-protector-guard-offset=@var{offset} @gol
> > --mstack-protector-guard-symbol=@var{symbol} @gol
> > +-mstack-protector-guard-symbol=@var{symbol} -mvect-compare-costs@gol
> >  -mgeneral-regs-only  -mcall-ms2sysv-xlogues -mrelax-cmpxchg-loop @gol
> >  -mindirect-branch=@var{choice}  -mfunction-return=@var{choice} @gol
> >  -mindirect-branch-register -mharden-sls=@var{choice} @gol
> > @@ -32440,6 +32440,11 @@ Generate code that uses only the general-purpose 
> > registers.  This
> >  prevents the compiler from using floating-point, vector, mask and bound
> >  registers.
> >
> > +@item -mvect-compare-costs
> > +@opindex mcompare-vect-costs
> > +Tells the loop vectorizer to try all the vector lengths and pick the one
> > +with the lowest cost.
> > +
> >  @item -mrelax-cmpxchg-loop
> >  @opindex mrelax-cmpxchg-loop
> >  Relax cmpxchg loop by emitting an early load and compare before cmpxchg,



-- 
BR,
Hongtao


Re: [PATCH] [i386] Add option -mvect-compare-costs

2021-12-16 Thread Richard Sandiford via Gcc-patches
Obviously I'm not in a position to comment on the target bits, but:

liuhongt via Gcc-patches  writes:
> Also with corresponding target attribute, option default disabled.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> gcc/ChangeLog:
>
>   * config/i386/i386-options.c (ix86_target_string): Handle
>   -mvect-compare-costs.
>   (ix86_valid_target_attribute_inner_p): Support target attribute
>   vect-compare-costs.
>   * config/i386/i386.c (ix86_autovectorize_vector_modes): Return
>   1 when TARGET_X86_VECT_COMPARE_COSTS.
>   * config/i386/i386.opt: Add option -mvect-compare-costs.
>   * doc/invoke.texi: Document -mvect-compare-costs.
> ---
>  gcc/config/i386/i386-options.c | 7 ++-
>  gcc/config/i386/i386.c | 2 +-
>  gcc/config/i386/i386.opt   | 5 +
>  gcc/doc/invoke.texi| 7 ++-
>  4 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/config/i386/i386-options.c b/gcc/config/i386/i386-options.c
> index 53bd55a12e3..53794b13fc5 100644
> --- a/gcc/config/i386/i386-options.c
> +++ b/gcc/config/i386/i386-options.c
> @@ -406,7 +406,8 @@ ix86_target_string (HOST_WIDE_INT isa, HOST_WIDE_INT isa2,
>/* Additional flag options.  */
>static struct ix86_target_opts flag2_opts[] =
>{
> -{ "-mgeneral-regs-only", OPTION_MASK_GENERAL_REGS_ONLY }
> +{ "-mgeneral-regs-only", OPTION_MASK_GENERAL_REGS_ONLY },
> +{ "-mvect-compare-costs",
> OPTION_MASK_X86_VECT_COMPARE_COSTS }
>};
>  
>const char *opts[ARRAY_SIZE (isa_opts) + ARRAY_SIZE (isa2_opts)
> @@ -,6 +1112,10 @@ ix86_valid_target_attribute_inner_p (tree fndecl, tree 
> args, char *p_strings[],
>   OPT_mgeneral_regs_only,
>   OPTION_MASK_GENERAL_REGS_ONLY),
>  
> +IX86_ATTR_IX86_YES ("vect-compare-costs",
> + OPT_mvect_compare_costs,
> + OPTION_MASK_X86_VECT_COMPARE_COSTS),
> +
>  IX86_ATTR_YES ("relax-cmpxchg-loop",
>  OPT_mrelax_cmpxchg_loop,
>  MASK_RELAX_CMPXCHG_LOOP),
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 9f4ed34ffd5..8d3fc3be1b9 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -22836,7 +22836,7 @@ ix86_autovectorize_vector_modes (vector_modes *modes, 
> bool all)
>if (TARGET_SSE2)
>  modes->safe_push (V4QImode);
>  
> -  return 0;
> +  return TARGET_X86_VECT_COMPARE_COSTS ? 1 : 0;

as far as the interface goes, it'd be better to use VECT_COMPARE_COSTS
instead of 1 here.

Thanks,
Richard

>  }
>  
>  /* Implemenation of targetm.vectorize.get_mask_mode.  */
> diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
> index e1af3e417b0..80c7a073d07 100644
> --- a/gcc/config/i386/i386.opt
> +++ b/gcc/config/i386/i386.opt
> @@ -1206,3 +1206,8 @@ Support MWAIT and MONITOR built-in functions and code 
> generation.
>  mavx512fp16
>  Target Mask(ISA2_AVX512FP16) Var(ix86_isa_flags2) Save
>  Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, AVX512F and 
> AVX512FP16 built-in functions and code generation.
> +
> +mvect-compare-costs
> +Target Mask(X86_VECT_COMPARE_COSTS) Var(ix86_target_flags) Save
> +Tells the loop vectorizer to try all the provided vector lengths and pick the
> +one with the lowest cost.
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 80c36b9abe0..fa2f63af65f 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -1428,7 +1428,7 @@ See RS/6000 and PowerPC Options.
>  -malign-data=@var{type}  -mstack-protector-guard=@var{guard} @gol
>  -mstack-protector-guard-reg=@var{reg} @gol
>  -mstack-protector-guard-offset=@var{offset} @gol
> --mstack-protector-guard-symbol=@var{symbol} @gol
> +-mstack-protector-guard-symbol=@var{symbol} -mvect-compare-costs@gol
>  -mgeneral-regs-only  -mcall-ms2sysv-xlogues -mrelax-cmpxchg-loop @gol
>  -mindirect-branch=@var{choice}  -mfunction-return=@var{choice} @gol
>  -mindirect-branch-register -mharden-sls=@var{choice} @gol
> @@ -32440,6 +32440,11 @@ Generate code that uses only the general-purpose 
> registers.  This
>  prevents the compiler from using floating-point, vector, mask and bound
>  registers.
>  
> +@item -mvect-compare-costs
> +@opindex mcompare-vect-costs
> +Tells the loop vectorizer to try all the vector lengths and pick the one
> +with the lowest cost.
> +
>  @item -mrelax-cmpxchg-loop
>  @opindex mrelax-cmpxchg-loop
>  Relax cmpxchg loop by emitting an early load and compare before cmpxchg,