Re: [PATCH] c++: call complete_type after performing auto deduction [PR80351]

[Jason Merrill via Gcc-patches]

On 3/29/22 02:02, Pokechu22 wrote:

On Thu, Mar 24, 2022 at 1:53 PM Jason Merrill  wrote:

Thanks!  For future reference, the patch doesn't apply easily because
gmail wrapped lines; for sending patches via gmail you'll need to use
attachments.  Or you can use another MUA, or git send-email.  This time
I fixed the wrapping by hand, but that's a pain (especially since
there's no "try again" flag to git am).


Thanks.  I was vaguely aware that gmail did something wrong, but I
thought that enabling plain-text mode was enough to work around it.
It might be useful to add that information to the contributing
webpage.  I've attached a copy of the patch here in case anyone else
wants to test it without dealing with the mangling.

Out of curiosity, do you know if this issue could have impacted
anything beyond the false warning?  I had previously determined that
ensure_literal_type_for_constexpr_object completes the type, so for
constexpr variables it wouldn't have caused any further issues, but I
discovered that regular const variables were also affected later on
(and possibly other unused variables could be affected, but non-const
ones would trigger the warning normally).


It also affects whether the variable goes into .data or .rodata.  For


#include 
const auto x = { 1, 2 };


without the change, x goes into .data; after the change it goes in .rodata.


Also, like other DCO projects, we can't normally accept pseudonymous
contributions.  But as you say in the PR, this patch is trivial enough
that I'm content to apply it myself; I want to make some adjustments anyway.


Also out of curiosity, what do you want to adjust with it?  I'd like
to know in case it's relevant for any other patch that I submit
(though there probably won't be a situation where I'm writing another
patch for a while).


I'm adding a diagnostic if the deduced type remains incomplete, not 
anything more generally relevant.



Lastly, I'd appreciate my pseudonym being credited (at least as a
co-author) in the final patch,


Yes, that was my plan.

Jason

[PATCH, V2] Optimize vec_splats of constant vec_extract for V2DI/V2DF, PR target 99293.

[Michael Meissner via Gcc-patches]

Optimize vec_splats of constant vec_extract for V2DI/V2DF, PR target 99293.

This is version 2 of the patch.  The original patch was:

| Date: Mon, 28 Mar 2022 12:26:02 -0400
| Subject: [PATCH 1/4] Optimize vec_splats of constant vec_extract for 
V2DI/V2DF, PR target 99293.
| Message-ID: 
| https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592420.html

In PR target/99293, it was pointed out that doing:

vector long long dest0, dest1, src;
/* ... */
dest0 = vec_splats (vec_extract (src, 0));
dest1 = vec_splats (vec_extract (src, 1));

would generate slower code.

It generates the following code on power8:

;; vec_splats (vec_extract (src, 0))
xxpermdi 0,34,34,3
xxpermdi 34,0,0,0

;; vec_splats (vec_extract (src, 1))
xxlor 0,34,34
xxpermdi 34,0,0,0

However on power9 and power10 it generates:

;; vec_splats (vec_extract (src, 0))
mfvsld 3,34
mtvsrdd 34,9,9

;; vec_splats (vec_extract (src, 1))
mfvsrd 9,34
mtvsrdd 34,9,9

This is due to the power9 having the mfvsrld instruction which can extract
either 64-bit element into a GPR.  While there are alternatives for both
vector registers and GPR registers, the register allocator prefers to put
DImode into GPR registers.

However in this case, it is better to have a single combiner pattern that
can generate a single xxpermdi, instead of doing 2 insnsns (the extract
and then the concat).  This is particularly true if the two operations are
move from vector register and move to vector register.  As Segher pointed
out in a previous version of the patch, the combiner already tries doing
creating a (vec_duplicate (vec_select ...)) pattern, but we didn't provide
one.

This patch reworks vsx_xxspltd_ for V2DImode and V2DFmode so that it
no longer uses an UNSPEC.  Instead it uses VEC_DUPLICATE, which the
combiner checks for.

I have built Spec 2017 with this patch installed, and the cam4_r benchmark
is the only benchmark that generated different code (3 mfvsrld/mtvsrdd
pairs of instructions were replaced with xxpermdi).

I have built bootstrap versions on the following systems and I have run
the regression tests.  There were no regressions in the runs:

Power9 little endian, --with-cpu=power9
Power10 little endian, --with-cpu=power10
Power8 big endian, --with-cpu=power8 (both 32-bit & 64-bit tests)

Can I install this into the trunk?  After a burn-in period, can I backport
and install this into GCC 11 and GCC 10 branches?

2022-03-29   Michael Meissner  

gcc/
PR target/99293
* config/rs6000/rs6000-p8swap.cc (rtx_is_swappable_p): Remove
UNSPEC_VSX_XXSPLTD case.
* config/rs6000/vsx.md (UNSPEC_VSX_XXSPLTD): Delete.
(vsx_xxspltd_): Rewrite to use VEC_DUPLICATE.

gcc/testsuite:
PR target/99293
* gcc.target/powerpc/builtins-1.c: Update insn count.
* gcc.target/powerpc/pr99293.c: New test.
---
 gcc/config/rs6000/rs6000-p8swap.cc|  1 -
 gcc/config/rs6000/vsx.md  | 19 +-
 gcc/testsuite/gcc.target/powerpc/builtins-1.c |  2 +-
 gcc/testsuite/gcc.target/powerpc/pr99293.c| 36 +++
 4 files changed, 47 insertions(+), 11 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/pr99293.c

diff --git a/gcc/config/rs6000/rs6000-p8swap.cc 
b/gcc/config/rs6000/rs6000-p8swap.cc
index d301bc3fe59..1973d9c8245 100644
--- a/gcc/config/rs6000/rs6000-p8swap.cc
+++ b/gcc/config/rs6000/rs6000-p8swap.cc
@@ -805,7 +805,6 @@ rtx_is_swappable_p (rtx op, unsigned int *special)
  case UNSPEC_VUPKLU_V4SF:
return 0;
  case UNSPEC_VSPLT_DIRECT:
- case UNSPEC_VSX_XXSPLTD:
*special = SH_SPLAT;
return 1;
  case UNSPEC_REDUC_PLUS:
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index 15bd86dfdfb..82fa4bbbfc4 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -296,7 +296,6 @@ (define_c_enum "unspec"
UNSPEC_VSX_XXPERM
 
UNSPEC_VSX_XXSPLTW
-   UNSPEC_VSX_XXSPLTD
UNSPEC_VSX_DIVSD
UNSPEC_VSX_DIVUD
UNSPEC_VSX_DIVSQ
@@ -4676,16 +4675,18 @@ (define_insn "vsx_vsplt_di"
 ;; V2DF/V2DI splat for use by vec_splat builtin
 (define_insn "vsx_xxspltd_"
   [(set (match_operand:VSX_D 0 "vsx_register_operand" "=wa")
-(unspec:VSX_D [(match_operand:VSX_D 1 "vsx_register_operand" "wa")
-  (match_operand:QI 2 "u5bit_cint_operand" "i")]
-  UNSPEC_VSX_XXSPLTD))]
+   (vec_duplicate:VSX_D
+(vec_select:
+ (match_operand:VSX_D 1 "gpc_reg_operand" "wa")
+ (parallel [(match_operand:QI 2 "const_0_to_1_operand" "i")]]
   "VECTOR_MEM_VSX_P (mode)"
 {
-  if ((BYTES_BIG_ENDIAN && INTVAL (operands[2]) == 0)
-  || (!BYTES_BIG_ENDIAN && INTVAL (operands[2]) == 1))
-return "xxpermdi %x0,%x1,%x1,0";
-  else
-return "xxpermdi %x0,%x1,%x1,3";
+  

Re: [PATCH] c-family: ICE with -Wconversion and A ?: B [PR101030]

[Jason Merrill via Gcc-patches]

On 3/29/22 16:59, Marek Polacek wrote:

On Tue, Mar 29, 2022 at 04:53:21PM -0400, Marek Polacek via Gcc-patches wrote:

This patch fixes a crash in conversion_warning on a null expression.
It is null because the testcase uses the GNU A ?: B extension.  We
could also use op0 instead of op1 in this case, but it doesn't seem
to be necessary.


A related issue: we print
warning: overflow in conversion from 'int' to 'char' changes value from '300' 
to '',''
in the test in the patch.  That's because the value is 44, it's type is char,
and the ASCII value for ',' is 44.  So I think we should convert values of char
type to int for the diagnostic.


Sure.

Re: [PATCH] c-family: ICE with -Wconversion and A ?: B [PR101030]

[Jason Merrill via Gcc-patches]

On 3/29/22 16:53, Marek Polacek wrote:

This patch fixes a crash in conversion_warning on a null expression.
It is null because the testcase uses the GNU A ?: B extension.  We
could also use op0 instead of op1 in this case, but it doesn't seem
to be necessary.


I wonder why we don't represent the extension as

SAVE_EXPR(A) ? SAVE_EXPR(A) : B

so we don't hit this sort of problem.  But the patch is OK.


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

PR c++/101030

gcc/c-family/ChangeLog:

* c-warn.cc (conversion_warning) : Don't call
conversion_warning when OP1 is null.

gcc/testsuite/ChangeLog:

* g++.dg/ext/cond5.C: New test.
---
  gcc/c-family/c-warn.cc   |  2 +-
  gcc/testsuite/g++.dg/ext/cond5.C | 13 +
  2 files changed, 14 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/ext/cond5.C

diff --git a/gcc/c-family/c-warn.cc b/gcc/c-family/c-warn.cc
index 9025fc1c20e..f24ac5d0539 100644
--- a/gcc/c-family/c-warn.cc
+++ b/gcc/c-family/c-warn.cc
@@ -1300,7 +1300,7 @@ conversion_warning (location_t loc, tree type, tree expr, 
tree result)
tree op1 = TREE_OPERAND (expr, 1);
tree op2 = TREE_OPERAND (expr, 2);
  
-	return (conversion_warning (loc, type, op1, result)

+   return ((op1 && conversion_warning (loc, type, op1, result))
|| conversion_warning (loc, type, op2, result));
}
  
diff --git a/gcc/testsuite/g++.dg/ext/cond5.C b/gcc/testsuite/g++.dg/ext/cond5.C

new file mode 100644
index 000..a92f28998f9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/cond5.C
@@ -0,0 +1,13 @@
+// PR c++/101030
+// { dg-do compile { target { c++11 } } }
+// { dg-options "-Wconversion" }
+
+template 
+struct jj {
+int ii[N ?: 1];
+char c = N ?: 1; // { dg-warning "conversion from .int. to .char. changes value 
from .300. to " }
+};
+
+int main() {
+jj<300> kk;
+}

base-commit: 69db6e7f4e1d07bf8f33e93a29139cc16c1e0a2f

Re: [PATCH] c++: ICE with aggregate assignment and DMI [PR104583]

[Jason Merrill via Gcc-patches]

On 3/25/22 18:16, Marek Polacek wrote:

The attached 93280 test no longer ICEs but looks like it was never added to the
testsuite.  The 104583 test, modified so that it closely resembles 93280, still
ICEs.

The problem is that in 104583 we have a value-init from {} (the line A a{};),
so this code in convert_like_internal

  7960 /* If we're initializing from {}, it's value-initialization.  */
  7961 if (BRACE_ENCLOSED_INITIALIZER_P (expr)
  7962 && CONSTRUCTOR_NELTS (expr) == 0
  7963 && TYPE_HAS_DEFAULT_CONSTRUCTOR (totype)
  7964 && !processing_template_decl)
  7965   {
  7966 bool direct = CONSTRUCTOR_IS_DIRECT_INIT (expr);
...
  7974 TARGET_EXPR_DIRECT_INIT_P (expr) = direct;

sets TARGET_EXPR_DIRECT_INIT_P.  This does not happen in 93280 where we
initialize from {0}.

In 104583, when gimplifying, the d = {}; line, we have

d = {.a=TARGET_EXPR >> }

where the TARGET_EXPR is the one with TARGET_EXPR_DIRECT_INIT_P set.  In
gimplify_init_ctor_preeval we do

  4724   FOR_EACH_VEC_SAFE_ELT (v, ix, ce)
  4725 gimplify_init_ctor_preeval (>value, pre_p, post_p, data);

so we gimplify the TARGET_EXPR, crashing at

  744 case TARGET_EXPR:
  745   /* A TARGET_EXPR that expresses direct-initialization should have
been
  746  elided by cp_gimplify_init_expr.  */
  747   gcc_checking_assert (!TARGET_EXPR_DIRECT_INIT_P (*expr_p));

but there is no INIT_EXPR so cp_gimplify_init_expr was never called!

Now, the fix for c++/93280

says "let's only set TARGET_EXPR_DIRECT_INIT_P when we're using the DMI in
a constructor." and the comment talks about the full initialization.  Is
is accurate to say that our TARGET_EXPR does not represent the full
initialization, because it only initializes the 'a' subobject?  If so,
then maybe get_nsdmi should clear TARGET_EXPR_DIRECT_INIT_P when in_ctor
is false.

I've compared the 93280.s and 104583.s files, they differ only in one
movl $0, so there are no extra calls and similar.

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

PR c++/93280
PR c++/104583

gcc/cp/ChangeLog:

* init.cc (get_nsdmi): Set TARGET_EXPR_DIRECT_INIT_P to in_ctor.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/nsdmi-list7.C: New test.
* g++.dg/cpp0x/nsdmi-list8.C: New test.
---
  gcc/cp/init.cc   |  8 
  gcc/testsuite/g++.dg/cpp0x/nsdmi-list7.C | 17 +
  gcc/testsuite/g++.dg/cpp0x/nsdmi-list8.C | 17 +
  3 files changed, 38 insertions(+), 4 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/nsdmi-list7.C
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/nsdmi-list8.C

diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index 08767679dd4..fd32a8bd90f 100644
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -679,10 +679,10 @@ get_nsdmi (tree member, bool in_ctor, tsubst_flags_t 
complain)
if (simple_target)
  init = TARGET_EXPR_INITIAL (init);
init = break_out_target_exprs (init, /*loc*/true);
-  if (in_ctor && init && TREE_CODE (init) == TARGET_EXPR)
-/* This expresses the full initialization, prevent perform_member_init from
-   calling another constructor (58162).  */
-TARGET_EXPR_DIRECT_INIT_P (init) = true;
+  if (init && TREE_CODE (init) == TARGET_EXPR)
+/* If this expresses the full initialization, prevent perform_member_init


Maybe "In a constructor, this expresses..." ?  The added "if" suggests a 
test that I don't see in the code.  OK with that change.



+   from calling another constructor (58162).  */
+TARGET_EXPR_DIRECT_INIT_P (init) = in_ctor;
if (simple_target && TREE_CODE (init) != CONSTRUCTOR)
  /* Now put it back so C++17 copy elision works.  */
  init = get_target_expr (init);
diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi-list7.C 
b/gcc/testsuite/g++.dg/cpp0x/nsdmi-list7.C
new file mode 100644
index 000..62b07429bec
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/nsdmi-list7.C
@@ -0,0 +1,17 @@
+// PR c++/93280
+// { dg-do compile { target c++11 } }
+
+struct A {
+  template  A(T);
+  int c;
+};
+
+struct D {
+  A a{0};
+};
+
+void g()
+{
+  D d;
+  d = {};
+}
diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi-list8.C 
b/gcc/testsuite/g++.dg/cpp0x/nsdmi-list8.C
new file mode 100644
index 000..fe73da8f98d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/nsdmi-list8.C
@@ -0,0 +1,17 @@
+// PR c++/104583
+// { dg-do compile { target c++11 } }
+
+struct A {
+  A();
+  int c;
+};
+
+struct D {
+  A a{};
+};
+
+void g()
+{
+  D d;
+  d = {};
+}

base-commit: bdd7b679e8497c07e25726f6ab6429e4c4d429c7

New Croatian PO file for 'gcc' (version 12.1-b20220213)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

(This file, 'gcc-12.1-b20220213.hr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

New Croatian PO file for 'gcc' (version 12.1-b20220213)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

(This file, 'gcc-12.1-b20220213.hr.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Re: [wwwdocs] [PATCH 0/4] Fix various typos

[Pokechu22 via Gcc-patches]

In case it's helpful, I've included copies of the patches as
attachments (as well as a single patch that is all of these changes
merged together).

--Poke

On Tue, Mar 22, 2022 at 12:50 PM Pokechu22  wrote:
>
> While working on a separate patch, I found several typos on the website.
> I have only looked within the htdocs directory, not its subdirectories.
>
> These are individual patches per file, since that seemed reasonable to me.
>
> I believe this is a small enough change that I do not need to go through
> copyright assignment or DCO certification (if I had supplied a list of
> files and line numbers, I suspect anyone else would have made the same
> patches).  I would rather remain pseudonymous.
>
> I've sent these patches using gmail's web interface since I have had
> bad experiences setting up command-line mailing.  Hopefully they have
> not been mangled by it.
>
> --Poke


0001-branch-closing-Fix-various-typos.patch
Description: Binary data


0002-codingconventions-Fix-various-typos.patch
Description: Binary data


0004-contribute-Fix-various-typos.patch
Description: Binary data


0003-codingrationale-Fix-various-typos.patch
Description: Binary data


0001-Fix-various-typos.patch
Description: Binary data

[committed] analyzer: skip constant pool in -fdump-analyzer-untracked [PR testsuite/105085]

[David Malcolm via Gcc-patches]

In r12-7809-g5f6197d7c197f9 I added -fdump-analyzer-untracked as support
for DejaGnu testing of an optimization of -fanalyzer,
PR analyzer/104954.

PR testsuite/105085 notes testsuite failures of the form:
  FAIL: gcc.dg/analyzer/untracked-1.c (test for excess errors)
  Excess errors:
  cc1: warning: track '*.LC1': yes
where these warnings are emitted on some targets where the test
causes labelled constants to be created in the constant pool.

We probably ought not to be tracking the values of such decls in the
store, given that they're meant to be constant, and I attempted various
fixes to make the "should we track this decl" logic smarter, but given
that we're in stage 4, the simplest fix seems to be for
-fdump-analyzer-untracked to skip such decls in its output, to minimize
test output differences between targets.

Manually tested the affected cases with --target=powerpc64le-linux-gnu.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-7905-gc788a0eae0a7144e6f148162512fa2e93a45a035.

gcc/analyzer/ChangeLog:
PR testsuite/105085
* region-model-manager.cc (dump_untracked_region): Skip decls in
the constant pool.

gcc/testsuite/ChangeLog:
PR testsuite/105085
* gcc.dg/analyzer/untracked-1.c: Add further test coverage.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/region-model-manager.cc|  7 ++
 gcc/testsuite/gcc.dg/analyzer/untracked-1.c | 26 +
 2 files changed, 33 insertions(+)

diff --git a/gcc/analyzer/region-model-manager.cc 
b/gcc/analyzer/region-model-manager.cc
index 5ca333a9ed6..56d60768749 100644
--- a/gcc/analyzer/region-model-manager.cc
+++ b/gcc/analyzer/region-model-manager.cc
@@ -1770,6 +1770,13 @@ dump_untracked_region (const decl_region *decl_reg)
   tree decl = decl_reg->get_decl ();
   if (TREE_CODE (decl) != VAR_DECL)
 return;
+  /* For now, don't emit the status of decls in the constant pool, to avoid
+ differences in DejaGnu test results between targets that use these vs
+ those that don't.
+ (Eventually these decls should probably be untracked and we should test
+ for that, but that's not stage 4 material).  */
+  if (DECL_IN_CONSTANT_POOL (decl))
+return;
   warning_at (DECL_SOURCE_LOCATION (decl), 0,
  "track %qD: %s",
  decl, (decl_reg->tracked_p () ? "yes" : "no"));
diff --git a/gcc/testsuite/gcc.dg/analyzer/untracked-1.c 
b/gcc/testsuite/gcc.dg/analyzer/untracked-1.c
index d07c2975670..9f3a639db5c 100644
--- a/gcc/testsuite/gcc.dg/analyzer/untracked-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/untracked-1.c
@@ -1,5 +1,7 @@
 /* { dg-additional-options "-fdump-analyzer-untracked" } */
 
+#include "analyzer-decls.h"
+
 struct st
 {
   const char *m_filename;
@@ -39,6 +41,16 @@ void test_3 (void)
   extern_fn ();
 }
 
+void test_3a (void)
+{
+  struct st s3a = { "foo.c", 42 }; /* { dg-warning "track 's3a': yes" } */
+  __analyzer_eval (s3a.m_filename[0] == 'f'); /* { dg-warning "TRUE" } */
+  __analyzer_eval (s3a.m_line == 42); /* { dg-warning "TRUE" } */
+  extern_fn ();
+  __analyzer_eval (s3a.m_filename[0] == 'f'); /* { dg-warning "UNKNOWN" } */
+  __analyzer_eval (s3a.m_line == 42); /* { dg-warning "UNKNOWN" } */
+}
+
 extern void called_by_test_4 (int *);
 
 int test_4 (void)
@@ -103,3 +115,17 @@ void test_13 (void)
 {
   extern_fn_char_ptr (__func__); /* { dg-warning "track '__func__': no" } */
 }
+
+char t14_global_unused[100]; /* { dg-warning "track 't14_global_unused': yes" 
} */
+static char t14_static_unused[100]; /* { dg-warning "track 
't14_static_unused': yes" } */
+char t14_global_used[100]; /* { dg-warning "track 't14_global_used': yes" } */
+static char t14_static_used[100]; /* { dg-warning "track 't14_static_used': 
yes" } */
+void test_14 (void)
+{
+  extern_fn_char_ptr (t14_global_unused);
+  extern_fn_char_ptr (t14_static_unused);
+  extern_fn_char_ptr (t14_global_used);
+  __analyzer_eval (t14_global_used[0] == '\0'); /* { dg-warning "UNKNOWN" } */
+  extern_fn_char_ptr (t14_static_used);
+  __analyzer_eval (t14_static_used[0] == '\0'); /* { dg-warning "UNKNOWN" } */
+}
-- 
2.26.3

[PATCH] PR fortran/104210 - [11/12 Regression] ICE in gfc_zero_size_array, at fortran/arith.cc:1685

[Harald Anlauf via Gcc-patches]

Dear all,

during error recovery on invalid declarations of functions as
coarrays we may hit multiple places with NULL pointer dereferences.
The attached patch provides a minimal and conservative solution.

Regtested on x86_64-pc-linux-gnu.  OK for mainline/11-branch?

Thanks,
Harald

From ce80d4b2ce3f35684f09bbb2f95f6edc5827224b Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Tue, 29 Mar 2022 23:33:23 +0200
Subject: [PATCH] Fortran: improve error recovery for invalid coarray function
 declarations

gcc/fortran/ChangeLog:

	PR fortran/104210
	* arith.cc (eval_intrinsic): Avoid NULL pointer dereference.
	(gfc_zero_size_array): Likewise.

gcc/testsuite/ChangeLog:

	PR fortran/104210
	* gfortran.dg/pr104210.f90: New test.
---
 gcc/fortran/arith.cc   |  9 ++---
 gcc/testsuite/gfortran.dg/pr104210.f90 | 15 +++
 2 files changed, 21 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr104210.f90

diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index 06e032e22db..d57059a375f 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -1489,6 +1489,9 @@ eval_intrinsic (gfc_intrinsic_op op,
   int unary;
   arith rc;

+  if (!op1)
+return NULL;
+
   gfc_clear_ts ();

   switch (op)
@@ -1703,11 +1706,11 @@ eval_type_intrinsic0 (gfc_intrinsic_op iop, gfc_expr *op)

 /* Return nonzero if the expression is a zero size array.  */

-static int
+static bool
 gfc_zero_size_array (gfc_expr *e)
 {
-  if (e->expr_type != EXPR_ARRAY)
-return 0;
+  if (e == NULL || e->expr_type != EXPR_ARRAY)
+return false;

   return e->value.constructor == NULL;
 }
diff --git a/gcc/testsuite/gfortran.dg/pr104210.f90 b/gcc/testsuite/gfortran.dg/pr104210.f90
new file mode 100644
index 000..182404c265b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr104210.f90
@@ -0,0 +1,15 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=single" }
+! PR fortran/104210
+! Contributed by G.Steinmetz
+
+function f()  ! { dg-error "shall not be a coarray" }
+  integer :: f[*]
+end
+program p
+  interface
+ function f() ! { dg-error "shall not be a coarray" }
+   integer :: f[*]
+ end
+  end interface
+end
--
2.34.1

Re: [PATCH v3] c++: warn on undefined casts from Base to Derived ref/ptr [PR96765]

[Jason Merrill via Gcc-patches]

On 3/27/22 08:37, Zhao Wei Liew wrote:

On Fri, 25 Mar 2022 at 05:58, Jason Merrill  wrote:



+  if (current_function_decl
+  && (DECL_CONSTRUCTOR_P (current_function_decl)
+  || DECL_DESTRUCTOR_P (current_function_decl))
+  && TREE_CODE (expr) == NOP_EXPR
+  && is_this_parameter (TREE_OPERAND (expr, 0)))


I think the resolves_to_fixed_type_p function would be useful here;
you're testing for a subset of the cases it handles.


Does the new patch look like how you intended it to? The new patch
passes all regression tests and newly added tests. However, I don't
fully understand the code for resolves_to_fixed_type_p() and
fixed_type_or_null(), except that I see that they contain logic to
return -1 when within a ctor/dtor.



+  if (TREE_CODE (expr) == NOP_EXPR
+  && resolves_to_fixed_type_p (TREE_OPERAND (expr, 0)) == -1)


Why not just pass expr itself to resolves_to_fixed_type_p?


You're right. I didn't realise that fixed_type_or_null handles the
NOP_EXPR case as part of CASE_CONVERT.


We might as well also warn if it returns >0, e.g.

struct A { } a;
struct B: A { };
auto p = static_cast(); // undefined

You should also handle reference casts.


I've made some changes in v3 to handle reference casts and the case
where resolves_to_fixed_type_p > 0. I've also slightly modified the
patch title to reflect the new changes.


Looks good, I've queued this for when GCC 13 development opens.

Thanks,
Jason

Re: [PATCH] c-family: ICE with -Wconversion and A ?: B [PR101030]

[Marek Polacek via Gcc-patches]

On Tue, Mar 29, 2022 at 04:53:21PM -0400, Marek Polacek via Gcc-patches wrote:
> This patch fixes a crash in conversion_warning on a null expression.
> It is null because the testcase uses the GNU A ?: B extension.  We
> could also use op0 instead of op1 in this case, but it doesn't seem
> to be necessary.

A related issue: we print
warning: overflow in conversion from 'int' to 'char' changes value from '300' 
to '',''
in the test in the patch.  That's because the value is 44, it's type is char,
and the ASCII value for ',' is 44.  So I think we should convert values of char
type to int for the diagnostic.

Marek

Re: [PATCH] c++: Fox template-introduction tentative parsing in class bodies clear colon_corrects_to_scope_p [PR105061]

[Jason Merrill via Gcc-patches]

On 3/29/22 04:05, Jakub Jelinek wrote:

Hi!

The concepts support (in particular template introductions from concepts TS)
broke the following testcase, valid unnamed bitfields with dependent
types (or even just typedefs) were diagnosed as typos (: instead of correct
::) in template introduction during their tentative parsing.
The following patch fixes that by not doing this : to :: correction when
member_p is true.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
release branches (so far also bootstrapped/regtested on the above targets
on 11 branch)?


OK.


2022-03-29  Jakub Jelinek  

PR c++/105061
* parser.cc (cp_parser_template_introduction): If member_p, temporarily
clear parser->colon_corrects_to_scope_p around tentative parsing of
nested name specifier.

* g++.dg/concepts/pr105061.C: New test.

--- gcc/cp/parser.cc.jj 2022-03-26 08:11:50.030217910 +0100
+++ gcc/cp/parser.cc2022-03-28 17:30:41.488053848 +0200
@@ -31417,9 +31417,15 @@ cp_parser_template_introduction (cp_pars
tree saved_scope = parser->scope;
tree saved_object_scope = parser->object_scope;
tree saved_qualifying_scope = parser->qualifying_scope;
+  bool saved_colon_corrects_to_scope_p = parser->colon_corrects_to_scope_p;
  
cp_token *start_token = cp_lexer_peek_token (parser->lexer);
  
+  /* In classes don't parse valid unnamed bitfields as invalid

+ template introductions.  */
+  if (member_p)
+parser->colon_corrects_to_scope_p = false;
+
/* Look for the optional `::' operator.  */
cp_parser_global_scope_opt (parser,
  /*current_scope_valid_p=*/false);
@@ -31440,6 +31446,7 @@ cp_parser_template_introduction (cp_pars
parser->scope = saved_scope;
parser->object_scope = saved_object_scope;
parser->qualifying_scope = saved_qualifying_scope;
+  parser->colon_corrects_to_scope_p = saved_colon_corrects_to_scope_p;
  
if (concept_name == error_mark_node

|| (seen_error () && !concept_definition_p (tmpl_decl)))
--- gcc/testsuite/g++.dg/concepts/pr105061.C.jj 2022-03-28 17:34:02.051207207 
+0200
+++ gcc/testsuite/g++.dg/concepts/pr105061.C2022-03-28 17:33:14.502882074 
+0200
@@ -0,0 +1,13 @@
+// PR c++/105061
+
+template 
+struct A { T : V, u : U; };
+template 
+struct B { unsigned : V, u : U; };
+typedef unsigned uns;
+template 
+struct C { uns : V, u : U; };
+
+A a = { 13 };
+B<5, 6> b = { 26 };
+C<8, 9> c = { 42 };

Jakub

[PATCH] c-family: ICE with -Wconversion and A ?: B [PR101030]

[Marek Polacek via Gcc-patches]

This patch fixes a crash in conversion_warning on a null expression.
It is null because the testcase uses the GNU A ?: B extension.  We
could also use op0 instead of op1 in this case, but it doesn't seem
to be necessary.

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

PR c++/101030

gcc/c-family/ChangeLog:

* c-warn.cc (conversion_warning) : Don't call
conversion_warning when OP1 is null.

gcc/testsuite/ChangeLog:

* g++.dg/ext/cond5.C: New test.
---
 gcc/c-family/c-warn.cc   |  2 +-
 gcc/testsuite/g++.dg/ext/cond5.C | 13 +
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/ext/cond5.C

diff --git a/gcc/c-family/c-warn.cc b/gcc/c-family/c-warn.cc
index 9025fc1c20e..f24ac5d0539 100644
--- a/gcc/c-family/c-warn.cc
+++ b/gcc/c-family/c-warn.cc
@@ -1300,7 +1300,7 @@ conversion_warning (location_t loc, tree type, tree expr, 
tree result)
tree op1 = TREE_OPERAND (expr, 1);
tree op2 = TREE_OPERAND (expr, 2);
 
-   return (conversion_warning (loc, type, op1, result)
+   return ((op1 && conversion_warning (loc, type, op1, result))
|| conversion_warning (loc, type, op2, result));
   }
 
diff --git a/gcc/testsuite/g++.dg/ext/cond5.C b/gcc/testsuite/g++.dg/ext/cond5.C
new file mode 100644
index 000..a92f28998f9
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/cond5.C
@@ -0,0 +1,13 @@
+// PR c++/101030
+// { dg-do compile { target { c++11 } } }
+// { dg-options "-Wconversion" }
+
+template 
+struct jj {
+int ii[N ?: 1];
+char c = N ?: 1; // { dg-warning "conversion from .int. to .char. changes 
value from .300. to " }
+};
+
+int main() {
+jj<300> kk;
+}

base-commit: 69db6e7f4e1d07bf8f33e93a29139cc16c1e0a2f
-- 
2.35.1

Re: [PATCH] c++: ICE with failed __is_constructible constraint [PR100474]

[Jason Merrill via Gcc-patches]

On 3/29/22 15:22, Patrick Palka wrote:

Here we're crashing when diagnosing a failed __is_constructible constraint
because diagnose_atomic_constraint don't know how to diagnose a trait
that diagnose_trait_expr doesn't specifically handle.  This patch fixes
this by falling through to the default case in this situation.

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


Hmm, it seems reasonable, but I think it would be better to actually 
handle all the traits.  Removing the default, I get



constraint.cc:3585:10: warning: enumeration value ‘CPTK_BASES’ not handled in 
switch [-Wswitch]
constraint.cc:3585:10: warning: enumeration value ‘CPTK_DIRECT_BASES’ not 
handled in switch [-Wswitch]
constraint.cc:3585:10: warning: enumeration value ‘CPTK_UNDERLYING_TYPE’ not 
handled in switch [-Wswitch]


These we don't need to handle.


constraint.cc:3585:10: warning: enumeration value 
‘CPTK_HAS_UNIQUE_OBJ_REPRESENTATIONS’ not handled in switch \
constraint.cc:3585:10: warning: enumeration value ‘CPTK_IS_AGGREGATE’ not 
handled in switch [-Wswitch]
constraint.cc:3585:10: warning: enumeration value 
‘CPTK_IS_TRIVIALLY_ASSIGNABLE’ not handled in switch [-Wswit\
constraint.cc:3585:10: warning: enumeration value 
‘CPTK_IS_TRIVIALLY_CONSTRUCTIBLE’ not handled in switch [-Ws\
constraint.cc:3585:10: warning: enumeration value ‘CPTK_IS_TRIVIALLY_COPYABLE’ 
not handled in switch [-Wswitch\
constraint.cc:3585:10: warning: enumeration value ‘CPTK_IS_ASSIGNABLE’ not 
handled in switch [-Wswitch]
constraint.cc:3585:10: warning: enumeration value ‘CPTK_IS_CONSTRUCTIBLE’ not 
handled in switch [-Wswitch]
constraint.cc:3585:10: warning: enumeration value ‘CPTK_IS_NOTHROW_ASSIGNABLE’ 
not handled in switch [-Wswitch\
constraint.cc:3585:10: warning: enumeration value 
‘CPTK_IS_NOTHROW_CONSTRUCTIBLE’ not handled in switch [-Wswi\


These we should.

I think we should leave off the default so that when we add more traits 
we get a warning that we need to handle them here.



PR c++/100474

gcc/cp/ChangeLog:

* constraint.cc (diagnose_trait_expr): Rename to ...
(maybe_diagnose_trait_expr): ... this.  Return a boolean
indicating whether we handled the trait.
(diagnose_atomic_constraint) : Fall through to
the default case if maybe_diagnose_trait_expr returns false.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-traits3.C: New test.
---
  gcc/cp/constraint.cc  | 16 +---
  gcc/testsuite/g++.dg/cpp2a/concepts-traits3.C | 10 ++
  2 files changed, 19 insertions(+), 7 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-traits3.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index c5a991b9e71..27b1b9bb659 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -3567,10 +3567,10 @@ get_constraint_error_location (tree t)
return input_location;
  }
  
-/* Emit a diagnostic for a failed trait.  */

+/* Maybe emit a friendlier diagnostic for the failed trait.  */
  
-static void

-diagnose_trait_expr (tree expr, tree args)
+static bool
+maybe_diagnose_trait_expr (tree expr, tree args)
  {
location_t loc = cp_expr_location (expr);
  
@@ -3655,8 +3655,9 @@ diagnose_trait_expr (tree expr, tree args)

inform (loc, "  %qT is not a union", t1);
break;
  default:
-  gcc_unreachable ();
+  return false;
  }
+  return true;
  }
  
  /* Diagnose a substitution failure in the atomic constraint T using ARGS.  */

@@ -3685,9 +3686,6 @@ diagnose_atomic_constraint (tree t, tree args, tree 
result, sat_info info)
STRIP_ANY_LOCATION_WRAPPER (expr);
switch (TREE_CODE (expr))
  {
-case TRAIT_EXPR:
-  diagnose_trait_expr (expr, args);
-  break;
  case REQUIRES_EXPR:
gcc_checking_assert (info.diagnose_unsatisfaction_p ());
/* Clear in_decl before replaying the substitution to avoid emitting
@@ -3696,6 +3694,10 @@ diagnose_atomic_constraint (tree t, tree args, tree 
result, sat_info info)
info.in_decl = NULL_TREE;
tsubst_requires_expr (expr, args, info);
break;
+case TRAIT_EXPR:
+  if (maybe_diagnose_trait_expr (expr, args))
+   break;
+  /* Fall through.  */
  default:
if (!same_type_p (TREE_TYPE (result), boolean_type_node))
error_at (loc, "constraint %qE has type %qT, not %",
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-traits3.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-traits3.C
new file mode 100644
index 000..33152242988
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-traits3.C
@@ -0,0 +1,10 @@
+// PR c++/100474
+// { dg-do compile { target c++20 } }
+
+template
+concept C = __is_constructible(T, Args...); // { dg-message "evaluated to 
'false'" }
+struct S {
+  S() = delete;
+};
+
+static_assert(C); // { dg-error "assert" }

[PATCH, committed] PR fortran/104571 - ICE in resolve_elemental_actual, at fortran/resolve.cc:2383

[Harald Anlauf via Gcc-patches]

Dear all,

I committed an obvious patch by Steve to avoid a NULL pointer dereference
on checking for invalid specification of an elemental procedure argument:

https://gcc.gnu.org/g:69db6e7f4e1d07bf8f33e93a29139cc16c1e0a2f

Regtested on x86_64-pc-linux-gnu.

Thanks,
Harald

From 69db6e7f4e1d07bf8f33e93a29139cc16c1e0a2f Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Tue, 29 Mar 2022 22:12:15 +0200
Subject: [PATCH] Fortran: avoid NULL pointer dereference checking elemental
 procedure args

gcc/fortran/ChangeLog:

	PR fortran/104571
	* resolve.cc (resolve_elemental_actual): Avoid NULL pointer
	dereference.

gcc/testsuite/ChangeLog:

	PR fortran/104571
	* gfortran.dg/pr104571.f90: New test.

Co-authored-by: Steven G. Kargl 
---
 gcc/fortran/resolve.cc |  5 +++--
 gcc/testsuite/gfortran.dg/pr104571.f90 | 12 
 2 files changed, 15 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr104571.f90

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 290767723d8..21c8797c938 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -2397,8 +2397,9 @@ resolve_elemental_actual (gfc_expr *expr, gfc_code *c)
   if (rank > 0 && esym && expr == NULL)
 for (eformal = esym->formal, arg = arg0; arg && eformal;
 	 arg = arg->next, eformal = eformal->next)
-  if ((eformal->sym->attr.intent == INTENT_OUT
-	   || eformal->sym->attr.intent == INTENT_INOUT)
+  if (eformal->sym
+	  && (eformal->sym->attr.intent == INTENT_OUT
+	  || eformal->sym->attr.intent == INTENT_INOUT)
 	  && arg->expr && arg->expr->rank == 0)
 	{
 	  gfc_error ("Actual argument at %L for INTENT(%s) dummy %qs of "
diff --git a/gcc/testsuite/gfortran.dg/pr104571.f90 b/gcc/testsuite/gfortran.dg/pr104571.f90
new file mode 100644
index 000..9a6f2d0e872
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr104571.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! { dg-options "-std=legacy" }
+! PR fortran/104571 - ICE in resolve_elemental_actual
+! Contributed by G.Steinmetz
+
+program p
+  real :: x(3)
+  call g(x) ! { dg-error "Missing alternate return" }
+contains
+  elemental subroutine g(*) ! { dg-error "Alternate return specifier" }
+  end
+end
--
2.34.1

Re: [PATCH 3/3] rs6000: Move more g++.dg powerpc tests to g++.target

[Segher Boessenkool]

Hi!

On Mon, Feb 21, 2022 at 03:17:47PM -0600, Paul A. Clarke wrote:
> gcc/testsuite
>   * g++.dg/debug/dwarf2/const2.C: Move to g++.target/powerpc.
>   * g++.dg/other/darwin-minversion-1.C: Likewise.
>   * g++.dg/eh/ppc64-sighandle-cr.C: Likewise.

This one uses
// { dg-do run { target { powerpc64*-*-linux* } } }
which is never correct: the target defaulting to 64 bit does in no way
mean that this is built as 64 bit.  There is nothing in the test that
needs 64 bit afaics?

>   * g++.dg/eh/simd-5.C: Likewise.
// { dg-do run { target { powerpc_spe && { ! *-*-vxworks* } } } }

This testcase can be deleted, there is no SPE anymore.

But that is perhaps best done deleting these tests and everything that
uses it as well at the same time :-)

>   * g++.dg/eh/simd-4.C: Move to g++.target/powerpc, adjust dg directives.
>   * g++.dg/eh/uncaught3.C: Likewise.
>   * g++.dg/other/spu2vmx-1.C: Likewise.

Those things can be done later, so: okay for trunk.  Thanks!


Segher

Re: [PATCH] Pass PKG_CONFIG_PATH down from top-level Makefile

[Simon Marchi via Gcc-patches]

Ping!

On 2022-03-15 17:26, Simon Marchi wrote:
> From: Simon Marchi 
> 
> [Sending to binutils, gdb-patches and gcc-patches, since it touches the
> top-level Makefile/configure]
> 
> I have my debuginfod library installed in a non-standard location
> (/opt/debuginfod), which requires me to set
> PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config.  If I just set it during
> configure:
> 
> $ PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config ./configure 
> --with-debuginfod
> $ make
> 
> or
> 
> $ ./configure --with-debuginfod 
> PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config
> $ make
> 
> Then PKG_CONFIG_PATH is only present (and ignored) during the top-level
> configure.  When running make (which runs gdb's and binutils'
> configure), PKG_CONFIG_PATH is not set, which results in their configure
> script not finding the library:
> 
> checking for libdebuginfod >= 0.179... no
> configure: error: "--with-debuginfod was given, but libdebuginfod is 
> missing or unusable."
> 
> Change the top-level configure/Makefile system to capture the value
> passed when configuring the top-level and pass it down to
> subdirectories (similar to CFLAGS, LDFLAGS, etc).
> 
> I don't know much about the top-level build system, so I really don't
> know if I did this correctly.  The changes are:
> 
>  - Use AC_SUBST(PKG_CONFIG_PATH) in configure.ac, so that
>@PKG_CONFIG_PATH@ gets replaced with the actual PKG_CONFIG_PATH value
>in config files (i.e. Makefile)
>  - Add a PKG_CONFIG_PATH Makefile variable in Makefile.tpl, initialized
>to @PKG_CONFIG_PATH@
>  - Add PKG_CONFIG_PATH to HOST_EXPORTS in Makefile.tpl, which are the
>variables set when running the sub-configures
> 
> I initially added PKG_CONFIG_PATH to flags_to_pass, in Makefile.def, but
> I don't think it's needed.  AFAIU, this defines the flags to pass down
> when calling "make" in subdirectories.  We only need PKG_CONFIG_PATH to
> be passed down during configure.  After that, it's captured in
> gdb/config.status, so even if a "make" causes a re-configure later
> (because gdb/configure has changed, for example), the PKG_CONFIG_PATH
> value will be remembered.
> 
> ChangeLog:
> 
>   * configure.ac: Add AC_SUBST(PKG_CONFIG_PATH).
>   * configure: Re-generate.
>   * Makefile.tpl (HOST_EXPORTS): Pass PKG_CONFIG_PATH.
>   (PKG_CONFIG_PATH): New.
>   * Makefile.in: Re-generate.
> 
> Change-Id: I91138dfca41c43b05e53e445f62e4b27882536bf
> ---
>  Makefile.in  | 3 +++
>  Makefile.tpl | 3 +++
>  configure| 2 ++
>  configure.ac | 1 +
>  4 files changed, 9 insertions(+)
> 
> diff --git a/Makefile.in b/Makefile.in
> index 3aacd2daac9c..cb39e4790d69 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -218,6 +218,7 @@ HOST_EXPORTS = \
>   OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \
>   OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \
>   OTOOL="$(OTOOL)"; export OTOOL; \
> + PKG_CONFIG_PATH="$(PKG_CONFIG_PATH)"; export PKG_CONFIG_PATH; \
>   READELF="$(READELF)"; export READELF; \
>   AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \
>   AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \
> @@ -444,6 +445,8 @@ LIBCXXFLAGS = $(CXXFLAGS) -fno-implicit-templates
>  GOCFLAGS = $(CFLAGS)
>  GDCFLAGS = $(CFLAGS)
>  
> +PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
> +
>  # Pass additional PGO and LTO compiler options to the PGO build.
>  BUILD_CFLAGS = $(PGO_BUILD_CFLAGS) $(PGO_BUILD_LTO_CFLAGS)
>  override CFLAGS += $(BUILD_CFLAGS)
> diff --git a/Makefile.tpl b/Makefile.tpl
> index 9df77788345a..88db8f44d53f 100644
> --- a/Makefile.tpl
> +++ b/Makefile.tpl
> @@ -221,6 +221,7 @@ HOST_EXPORTS = \
>   OBJCOPY="$(OBJCOPY)"; export OBJCOPY; \
>   OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \
>   OTOOL="$(OTOOL)"; export OTOOL; \
> + PKG_CONFIG_PATH="$(PKG_CONFIG_PATH)"; export PKG_CONFIG_PATH; \
>   READELF="$(READELF)"; export READELF; \
>   AR_FOR_TARGET="$(AR_FOR_TARGET)"; export AR_FOR_TARGET; \
>   AS_FOR_TARGET="$(AS_FOR_TARGET)"; export AS_FOR_TARGET; \
> @@ -447,6 +448,8 @@ LIBCXXFLAGS = $(CXXFLAGS) -fno-implicit-templates
>  GOCFLAGS = $(CFLAGS)
>  GDCFLAGS = $(CFLAGS)
>  
> +PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
> +
>  # Pass additional PGO and LTO compiler options to the PGO build.
>  BUILD_CFLAGS = $(PGO_BUILD_CFLAGS) $(PGO_BUILD_LTO_CFLAGS)
>  override CFLAGS += $(BUILD_CFLAGS)
> diff --git a/configure b/configure
> index 26935ebda249..1badcb314f8f 100755
> --- a/configure
> +++ b/configure
> @@ -618,6 +618,7 @@ CXX_FOR_TARGET
>  CC_FOR_TARGET
>  RANLIB_PLUGIN_OPTION
>  AR_PLUGIN_OPTION
> +PKG_CONFIG_PATH
>  READELF
>  OBJDUMP
>  OBJCOPY
> @@ -10310,6 +10311,7 @@ fi
>  
>  
>  
> +
>  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for -plugin option" >&5
>  $as_echo_n "checking for -plugin option... " >&6; }
>  
> diff --git a/configure.ac b/configure.ac
> index da4e41d72479..5b6e20485143 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -3465,6 +3465,7 @@ AC_SUBST(CC)
>  

Re: [PATCH 2/3] rs6000: Move g++.dg powerpc PR tests to g++.target

[Segher Boessenkool]

Hi!

On Tue, Feb 22, 2022 at 07:56:40PM -0600, Paul A. Clarke wrote:
> On Tue, Feb 22, 2022 at 06:41:45PM -0600, Segher Boessenkool wrote:
> > That said...
> > 
> > > -/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
> > > -/* { dg-skip-if "" { powerpc*-*-darwin* } } */
> > > +/* { dg-do compile { target lp64 } } */
> > > +/* { dg-skip-if "" { *-*-darwin* } } */
> > 
> > That skip-if is most likely cargo cult, and it's not clear why lp64
> > would be needed either (there is no comment what it is needed for, for
> > example).
> 
> I can't speak to darwin, nor have an easy way of testing on it.

Same here, of course.

> As for lp64, these tests fail on -m32 with:
>   cc1plus: error: '-mcmodel' not supported in this configuration
> - g++.dg/pr65240-1.C
> - g++.dg/pr65240-2.C
> - g++.dg/pr65240-3.C
> 
> '-mcmodel' is in the dg-options line for the above tests.

Yes.  That means the dg-options should be conditional (using
dg-additional-options is convenient).

Tests in *.dg should be done anywhere where that doesn't require
heroics to do.  This is true to a lesser extent elsewhere as well, and
least true in gcc.target -- but even there still true for many tests.

> The rest PASSed.  Shall I remove the 'lp64' restriction for those that PASS?

That is a separate change, so should be a separate commit.  If it is
obviously safe, please do it, yes.  Thanks!

> > > +++ b/gcc/testsuite/g++.target/powerpc/pr85657.C
> > > @@ -1,4 +1,4 @@
> > > -// { dg-do compile { target { powerpc*-*-linux* } } }
> > > +// { dg-do compile { target { *-*-linux* } } }
> > 
> > A comment here would help as well.  All of that is pre-existing of
> > course.
> 
> I'm not sure what such a comment would say. I suspect it was a testing issue
> (only tested on Linux), but I have similar limitations, so I'm also reluctant
> to enable the test for what would be untested (by me) platforms.

It is obvious what it would say: the reason why this is only tested on
Linux, of course!  :-)

I know what you are saying of course.  If it isn't obviously safe, it is
not for stage 4.  And adding more coverage to existing tests is not very
high value, not high priority at all.  The biggest advantage of it would
be that people will stop copying from such bad examples!


Segher

Re: options: Improve 'LangEnabledBy' option property diagnostics (was: r193303 - in /trunk/gcc: ChangeLog opt-function...)

[Joseph Myers]

On Tue, 29 Mar 2022, Thomas Schwinge wrote:

> I'm generally very much in favor of abstracting functionality into
> separate functions.  Here, however, there ever existed only one user of
> 'gcc/opt-functions.awk:lang_enabled_by', its interface is a bit clumsy,
> leading to (slightly) confusing diagnostics, and all handling for other
> related option properties remains in the original place, so I find that
> in fact confusing to be split out, and scattered over two files.  I thus
> propose to merge 'gcc/opt-functions.awk:lang_enabled_by' back into its
> original place, and then improve diagnostics.  OK to push the attached
> "options: Improve 'LangEnabledBy' option property diagnostics"?  In
> addition to standard testing, I've manually verified the error cases.

OK.

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

[committed] testsuite: Disable tests for C++23 that depend on std::unexpected

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.

-- >8 --

These tests depend on unexpected handlers, which are no longer declared
for C++23 mode. Adjust the target specifier so they don't run.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept06.C: Disable for C++23.

libstdc++-v3/ChangeLog:

* testsuite/18_support/exception/38732.cc: Disable for C++23.
* testsuite/18_support/headers/exception/synopsis.cc: Likewise.
* testsuite/18_support/unexpected_handler.cc: Likewise.
---
 gcc/testsuite/g++.dg/cpp0x/noexcept06.C | 2 +-
 libstdc++-v3/testsuite/18_support/exception/38732.cc| 2 ++
 libstdc++-v3/testsuite/18_support/headers/exception/synopsis.cc | 2 +-
 libstdc++-v3/testsuite/18_support/unexpected_handler.cc | 2 +-
 4 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept06.C 
b/gcc/testsuite/g++.dg/cpp0x/noexcept06.C
index ea152237d54..0183ad6d918 100644
--- a/gcc/testsuite/g++.dg/cpp0x/noexcept06.C
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept06.C
@@ -1,6 +1,6 @@
 // Test that checking of a nothrow specification uses the one on the
 // definition.
-// { dg-do run { target c++11 } }
+// { dg-do run { target { c++11 && { ! c++23 } } } }
 // { dg-options "-Wno-terminate" }
 
 #include 
diff --git a/libstdc++-v3/testsuite/18_support/exception/38732.cc 
b/libstdc++-v3/testsuite/18_support/exception/38732.cc
index 7b68921d074..a3888353a4b 100644
--- a/libstdc++-v3/testsuite/18_support/exception/38732.cc
+++ b/libstdc++-v3/testsuite/18_support/exception/38732.cc
@@ -15,6 +15,8 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
+// { dg-do run { target { c++11 && { ! c++23 } } } }
+
 #include 
 #include 
 #include "unwind.h"
diff --git a/libstdc++-v3/testsuite/18_support/headers/exception/synopsis.cc 
b/libstdc++-v3/testsuite/18_support/headers/exception/synopsis.cc
index efc0bc64c18..ceb7d1f754b 100644
--- a/libstdc++-v3/testsuite/18_support/headers/exception/synopsis.cc
+++ b/libstdc++-v3/testsuite/18_support/headers/exception/synopsis.cc
@@ -1,4 +1,4 @@
-// { dg-do compile { target c++11 } }
+// { dg-do compile { target { c++11 && { ! c++23 } } } }
 
 // Copyright (C) 2007-2022 Free Software Foundation, Inc.
 //
diff --git a/libstdc++-v3/testsuite/18_support/unexpected_handler.cc 
b/libstdc++-v3/testsuite/18_support/unexpected_handler.cc
index efd00abf879..344e7e08294 100644
--- a/libstdc++-v3/testsuite/18_support/unexpected_handler.cc
+++ b/libstdc++-v3/testsuite/18_support/unexpected_handler.cc
@@ -16,7 +16,7 @@
 // .
 
 // { dg-options "-Wno-deprecated-declarations" }
-// { dg-do run { target c++11 } }
+// { dg-do run { target { c++11 && { ! c++23 } } } }
 
 // D.11 Violating exception-specifications
 
-- 
2.34.1

[PATCH] c++: ICE with failed __is_constructible constraint [PR100474]

[Patrick Palka via Gcc-patches]

Here we're crashing when diagnosing a failed __is_constructible constraint
because diagnose_atomic_constraint don't know how to diagnose a trait
that diagnose_trait_expr doesn't specifically handle.  This patch fixes
this by falling through to the default case in this situation.

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

PR c++/100474

gcc/cp/ChangeLog:

* constraint.cc (diagnose_trait_expr): Rename to ...
(maybe_diagnose_trait_expr): ... this.  Return a boolean
indicating whether we handled the trait.
(diagnose_atomic_constraint) : Fall through to
the default case if maybe_diagnose_trait_expr returns false.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-traits3.C: New test.
---
 gcc/cp/constraint.cc  | 16 +---
 gcc/testsuite/g++.dg/cpp2a/concepts-traits3.C | 10 ++
 2 files changed, 19 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-traits3.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index c5a991b9e71..27b1b9bb659 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -3567,10 +3567,10 @@ get_constraint_error_location (tree t)
   return input_location;
 }
 
-/* Emit a diagnostic for a failed trait.  */
+/* Maybe emit a friendlier diagnostic for the failed trait.  */
 
-static void
-diagnose_trait_expr (tree expr, tree args)
+static bool
+maybe_diagnose_trait_expr (tree expr, tree args)
 {
   location_t loc = cp_expr_location (expr);
 
@@ -3655,8 +3655,9 @@ diagnose_trait_expr (tree expr, tree args)
   inform (loc, "  %qT is not a union", t1);
   break;
 default:
-  gcc_unreachable ();
+  return false;
 }
+  return true;
 }
 
 /* Diagnose a substitution failure in the atomic constraint T using ARGS.  */
@@ -3685,9 +3686,6 @@ diagnose_atomic_constraint (tree t, tree args, tree 
result, sat_info info)
   STRIP_ANY_LOCATION_WRAPPER (expr);
   switch (TREE_CODE (expr))
 {
-case TRAIT_EXPR:
-  diagnose_trait_expr (expr, args);
-  break;
 case REQUIRES_EXPR:
   gcc_checking_assert (info.diagnose_unsatisfaction_p ());
   /* Clear in_decl before replaying the substitution to avoid emitting
@@ -3696,6 +3694,10 @@ diagnose_atomic_constraint (tree t, tree args, tree 
result, sat_info info)
   info.in_decl = NULL_TREE;
   tsubst_requires_expr (expr, args, info);
   break;
+case TRAIT_EXPR:
+  if (maybe_diagnose_trait_expr (expr, args))
+   break;
+  /* Fall through.  */
 default:
   if (!same_type_p (TREE_TYPE (result), boolean_type_node))
error_at (loc, "constraint %qE has type %qT, not %",
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-traits3.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-traits3.C
new file mode 100644
index 000..33152242988
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-traits3.C
@@ -0,0 +1,10 @@
+// PR c++/100474
+// { dg-do compile { target c++20 } }
+
+template
+concept C = __is_constructible(T, Args...); // { dg-message "evaluated to 
'false'" }
+struct S {
+  S() = delete;
+};
+
+static_assert(C); // { dg-error "assert" }
-- 
2.35.1.677.gabf474a5dd

Re: options, '-Wc++[...]-extensions': Remove undefined one-argument 'LangEnabledBy' option properties (was: [PATCH] c++: Add new warning options for C++ language mismatches)

[Joseph Myers]

On Tue, 29 Mar 2022, Thomas Schwinge wrote:

> | --- gcc/c-family/c.opt
> | +++ gcc/c-family/c.opt
> | [...]
> | +Wc++11-extensions
> | +C++ ObjC++ Var(warn_cxx11_extensions) Warning LangEnabledBy(C++ ObjC++) 
> Init(1)
> | +Warn about C++11 constructs in code compiled with an older standard.
> | +
> | +[Etc.]
> 
> OK to push the attached "options, '-Wc++[...]-extensions':
> Remove undefined one-argument 'LangEnabledBy' option properties"?

OK.

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

Re: [PATCH] PR fortran/50549 - should detect different type parameters in structure constructors

[Harald Anlauf via Gcc-patches]

Hi Tobias,

Am 29.03.22 um 09:14 schrieb Tobias Burnus:

Hi Harald,

On 28.03.22 22:03, Harald Anlauf via Fortran wrote:

All current cases of printing a HOST_WIDE_INT in gcc/fortran/ use
'sprintf', and I did not find any other use of %wd/%wu.  So the
mentioned implementation is not really stressed yet... ;-)


That's all your fault ;-)


true; I'm pleading guilty for that one.


(Your commit
https://gcc.gnu.org/r12-3273-ge4cb3bb9ac11b4126ffa718287dd509a4b10a658
did remove the only user.)


I've now made good for it.  ;-)


That's only a warning. Have you tried whether it works at runtime?
My bet is that it does!


Yes, it did work, it was just the warning alerting me ...


Question: Do you build with --disable-bootstrap ? Or do you do a proper
bootstrap?


... because I did build with --disable-bootstrap to save on time for
building the compiler on my local machine, and the system's default
gcc is older.


Can you check & try again?  I don't mind getting a format warning with
GCC < GCC 12. But with GCC 12 compiled (either installed compiler or
when bootstrapping) it should compile without errors.

If you can confirm my suspicion, the patch LGTM.


I've just pushed that version as

  https://gcc.gnu.org/g:0712f356374c2cf26015cccfa3141537e42cbb12

Sorry for the noise, and thanks for the review!

Harald


Tobias

Re: options: Remove 'gcc/c-family/c.opt:Wuse-after-free' option definition record (was: [PATCH v2 1/2] add -Wuse-after-free)

[Joseph Myers]

On Tue, 29 Mar 2022, Thomas Schwinge wrote:

> | --- gcc/c-family/c.opt
> | +++ gcc/c-family/c.opt
> | [...]
> | +# Defining these options here in addition to common.opt is necessary
> | +# in order for the default -Wall setting of -Wuse-after-free=2 to take
> | +# effect.
> | +
> | +Wuse-after-free
> | +LangEnabledBy(C ObjC C++ LTO ObjC++)
> | +; in common.opt
> | +
> | +Wuse-after-free=
> | +LangEnabledBy(C ObjC C++ LTO ObjC++, Wall,2,0)
> | +; in common.opt
> | [...]
> 
> OK to push the attached "options: Remove
> 'gcc/c-family/c.opt:Wuse-after-free' option definition record"?

OK.

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

Re: options: Remove 'gcc/c-family/c.opt:Warray-bounds' option definition record (was: committed: remove redundant -Wall from -Warray-bounds (PR 82063))

[Joseph Myers]

On Tue, 29 Mar 2022, Thomas Schwinge wrote:

> | --- gcc/c-family/c.opt
> | +++ gcc/c-family/c.opt
> | [...]
> |  Warray-bounds
> | -LangEnabledBy(C ObjC C++ LTO ObjC++,Wall)
> | +LangEnabledBy(C ObjC C++ LTO ObjC++)
> |  ; in common.opt
> |
> |  Warray-bounds=
> 
> OK to push the attached "options: Remove
> 'gcc/c-family/c.opt:Warray-bounds' option definition record"?

OK.

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

[committed] c-family: Add -Wmisleading-indentation testcase [PR71637]

[Patrick Palka via Gcc-patches]

We no longer emit a bogus warning for the below testcase after
r11-3266-g4839de55e2c986.

Tested on x86_64-pc-linux-gnu, committed to trunk as obvious.

PR c++/71637

gcc/testsuite/ChangeLog:

* c-c++-common/Wmisleading-indentation-6.c: New test.
---
 .../c-c++-common/Wmisleading-indentation-6.c  | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 gcc/testsuite/c-c++-common/Wmisleading-indentation-6.c

diff --git a/gcc/testsuite/c-c++-common/Wmisleading-indentation-6.c 
b/gcc/testsuite/c-c++-common/Wmisleading-indentation-6.c
new file mode 100644
index 000..5b7dd7fd2fd
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/Wmisleading-indentation-6.c
@@ -0,0 +1,11 @@
+/* PR c++/71637  */
+/* { dg-options "-ftrack-macro-expansion=0 -Wmisleading-indentation" }  */
+
+#define m(x) ({ int y; if (x) y=0; else y=1; y; })
+
+int main()
+{
+  int x =
+m(0);
+  return x;
+}
-- 
2.35.1.677.gabf474a5dd

Re: [PATCH 4/4] Allow vsx_extract_ to use Altivec registers, PR target/99293

[Michael Meissner via Gcc-patches]

On Mon, Mar 28, 2022 at 06:59:14PM -0500, Segher Boessenkool wrote:
> On Mon, Mar 28, 2022 at 12:28:55PM -0400, Michael Meissner wrote:
> > In looking at PR target/99293, I noticed that the vsx_extract_
> > pattern for V2DImode and V2DFmode only allowed traditional floating point
> > registers, and it did not allow Altivec registers.  The original code was
> > written a few years ago when we used the old register allocator, and
> > support for scalar floating point in Altivec registers was just being
> > added to GCC.
> 
> vsx_extract_ is from 2009...  How time flies :-)
> 
> This comment is from 2016 though.  Still before LRA was default for us
> of course ;-)

The support for scalars in Altivec registers wasn't really done until the 2016
time frame.  At the time I had tried to use VSX registers for this, but I could
never get a reproducable case for the failure other one spec benchmark not
building with some flags (most likely spec 2017's 521.wrf_r or spec 2006's
481.wrf).  So I opted to just keep it limited to traditional FPR registers, and
maybe fix it some time later.

> If would have been nice if we had a testcase for this breakage, so that
> we could now be confident it really has been fixed.  But the "reload"
> here likely means "old reload", so okay.

Yes, it was the old reload.

> > PR target/99293
> 
> It has essentially nothing to do with that PR, right?  Or I just do not
> see it, always a possibility of course.

It was just that I noticed the change in looking at PR target/99293.  I did
remove the reference from the checkin commit.

> > * config/rs6000/rs6000.md (vsx_extract_): Allow destination
> > to be an Altivec register.
> 
> ... to be any VSX register.

Thanks.

> Okay for trunk with those things fixed.  Thanks!

Done.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

Re: [PATCH 1/2] arm: correctly handle zero-sized bit-fields in AAPCS [PR102024]

[Richard Earnshaw via Gcc-patches]

On 29/03/2022 17:32, Jakub Jelinek via Gcc-patches wrote:

On Tue, Mar 29, 2022 at 04:32:10PM +0100, Richard Earnshaw wrote:


On arm the AAPCS states that an HFA is determined by the 'shape' of
the object after layout has been completed, so anything that adds no
members and does not cause the layout to be modified should be ignored
for the purposes of determining which registers are used for parameter
passing.

A zero-sized bit-field falls into this category.  This was not handled
correctly for C structs and in G++-11 only handled correctly because
such fields were eliminated early by the front end.

gcc/ChangeLog:

PR target/102024
* config/arm/arm.cc (aapcs_vfp_sub_candidate): Handle zero-sized
bit-fields.  Detect cases where a warning may be needed.
(aapcs_vfp_is_call_or_return_candidate): Emit a note if
a zero-sized bit-field has caused parameter passing to change.

gcc/testsuite/ChangeLog:

PR target/102024
* gcc.target/arm/aapcs/vfp26.c: New test.
---
  gcc/config/arm/arm.cc  | 35 --
  gcc/testsuite/gcc.target/arm/aapcs/vfp26.c | 31 +++
  2 files changed, 63 insertions(+), 3 deletions(-)
  create mode 100644 gcc/testsuite/gcc.target/arm/aapcs/vfp26.c




diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index e062361b985..43b775f6918 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -6274,6 +6274,7 @@ aapcs_vfp_cum_init (CUMULATIVE_ARGS *pcum  
ATTRIBUTE_UNUSED,
a HFA or HVA.  */
  const unsigned int WARN_PSABI_EMPTY_CXX17_BASE = 1U << 0;
  const unsigned int WARN_PSABI_NO_UNIQUE_ADDRESS = 1U << 1;
+const unsigned int WARN_PSABI_ZERO_WIDTH_BITFIELD = 1U << 2;
  
  /* Walk down the type tree of TYPE counting consecutive base elements.

 If *MODEP is VOIDmode, then set it to the first valid floating point
@@ -6426,6 +6427,28 @@ aapcs_vfp_sub_candidate (const_tree type, machine_mode 
*modep,
continue;
  }
  }
+   /* A zero-width bitfield may affect layout in some
+  circumstances, but adds no members.  The determination
+  of whether or not a type is an HFA is performed after
+  layout is complete, so if the type still looks like an
+  HFA afterwards, it is still classed as one.  This is
+  potentially an ABI break for the hard-float ABI.  */
+   else if (DECL_BIT_FIELD (field)
+&& integer_zerop (DECL_SIZE (field)))
+ {
+   /* Prior to GCC-12 these fields were striped early,
+  hiding them from the back-end entirely and
+  resulting in the correct behaviour for argument
+  passing.  Simulate that old behaviour without
+  generating a warning.  */
+   if (DECL_FIELD_CXX_ZERO_WIDTH_BIT_FIELD (field))
+ continue;
+   if (warn_psabi_flags)
+ {
+   *warn_psabi_flags |= WARN_PSABI_ZERO_WIDTH_BITFIELD;
+   continue;
+ }
+ }
  
  	sub_count = aapcs_vfp_sub_candidate (TREE_TYPE (field), modep,

 warn_psabi_flags);
@@ -6538,8 +6561,10 @@ aapcs_vfp_is_call_or_return_candidate (enum arm_pcs 
pcs_variant,
  && ((alt = aapcs_vfp_sub_candidate (type, _mode, NULL))
  != ag_count))
{
- const char *url
+ const char *url10
= CHANGES_ROOT_URL "gcc-10/changes.html#empty_base";
+ const char *url12
+   = CHANGES_ROOT_URL "gcc-12/changes.html#empty_base";


This should be
= CHANGES_ROOT_URL "gcc-12/changes.html#zero_width_bitfields";
instead.

Otherwise LGTM.

Jakub



Good catch. Thanks.  Updated and pushed both patches.

R.

Re: [PATCH] gimple: Wrong -Wimplicit-fallthrough with if(1) [PR103597]

[Jakub Jelinek via Gcc-patches]

On Tue, Mar 29, 2022 at 12:13:51PM -0400, Marek Polacek wrote:
> This patch fixes a wrong -Wimplicit-fallthrough warning for
> 
> case 0:
>   if (1)  // wrong may fallthrough
>   return 0;
> case 1:
> 
> which in .gimple looks like
> 
> : // case 0
> if (1 != 0) goto ; else goto ;
> :
> D.1987 = 0;
> // predicted unlikely by early return (on trees) predictor.
> return D.1987;
> :  // dead
> : // case 1
> 
> and the warning thinks that : falls through to :.  It
> does not know that  is effectively a dead label, only reachable
> through fallthrough from previous instructions, never jumped to.  To
> that effect, Jakub introduced UNUSED_LABEL_P, which is set on such dead
> labels.
> 
> collect_fallthrough_labels has code to deal with cases like
> 
> case 2:
>   if (e != 10)
>   i++; // this may fallthru, warn
>   else
>   return 44;
> case 3:
> 
> which collects labels that may fall through.  Here it sees the "goto 
> ;"
> at the end of the then branch and so when the warning reaches
> 
> ...
> : // from if-then
> : // case 3
> 
> it knows it should warn about the possible fallthrough.  But an UNUSED_LABEL_P
> is not a label that can fallthrough like that, so it should ignore those.
> 
> However, we still want to warn about this:
> 
> case 0:
>   if (1)
>   n++; // falls through
> case 1:
> 
> so collect_fallthrough_labels needs to return the "n = n + 1;" statement, 
> rather
> than the dead label.
> 
> Co-authored-by: Jakub Jelinek 
> 
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> 
>   PR middle-end/103597
> 
> gcc/ChangeLog:
> 
>   * gimplify.cc (collect_fallthrough_labels): Don't push UNUSED_LABEL_Ps
>   into labels.  Maybe set prev to the statement preceding UNUSED_LABEL_P.
>   (gimplify_cond_expr): Set UNUSED_LABEL_P.
>   * tree.h (UNUSED_LABEL_P): New.
> 
> gcc/testsuite/ChangeLog:
> 
>   * c-c++-common/Wimplicit-fallthrough-39.c: New test.

LGTM.

Jakub

Re: [PATCH 2/2] aarch64: correctly handle zero-sized bit-fields in AAPCS64 [PR102024]

[Jakub Jelinek via Gcc-patches]

On Tue, Mar 29, 2022 at 04:32:11PM +0100, Richard Earnshaw wrote:
> 
> On aarch64 the AAPCS64 states that an HFA is determined by the 'shape' of
> the object after layout has been completed, so anything that adds no
> members and does not cause the layout to be modified should be ignored
> for the purposes of determining which registers are used for parameter
> passing.
> 
> A zero-sized bit-field falls into this category.  This was not handled
> correctly for C structs and in G++-11 only handled correctly because
> such fields were eliminated early by the front end.
> 
> gcc/ChangeLog:
> 
>   PR target/102024
>   * config/aarch64/aarch64.cc (aapcs_vfp_sub_candidate): Handle
>   zero-sized bit-fields.  Detect cases where a warning may be needed.
>   (aarch64_vfp_is_call_or_return_candidate): Emit a note if a
>   zero-sized bit-field has caused parameter passing to change.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/aarch64/aapcs64/test_28.c: New test.
> ---
>  gcc/config/aarch64/aarch64.cc | 35 +--
>  .../gcc.target/aarch64/aapcs64/test_28.c  | 28 +++
>  2 files changed, 60 insertions(+), 3 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/aapcs64/test_28.c
> 

> @@ -19711,8 +19734,10 @@ aarch64_vfp_is_call_or_return_candidate 
> (machine_mode mode,
> && ((alt = aapcs_vfp_sub_candidate (type, _mode, NULL))
> != ag_count))
>   {
> -   const char *url
> +   const char *url10
>   = CHANGES_ROOT_URL "gcc-10/changes.html#empty_base";
> +   const char *url12
> + = CHANGES_ROOT_URL "gcc-12/changes.html#empty_base";

Again, #zero_width_bitfields
Otherwise LGTM.

Jakub

Re: [PATCH 1/2] arm: correctly handle zero-sized bit-fields in AAPCS [PR102024]

[Jakub Jelinek via Gcc-patches]

On Tue, Mar 29, 2022 at 04:32:10PM +0100, Richard Earnshaw wrote:
> 
> On arm the AAPCS states that an HFA is determined by the 'shape' of
> the object after layout has been completed, so anything that adds no
> members and does not cause the layout to be modified should be ignored
> for the purposes of determining which registers are used for parameter
> passing.
> 
> A zero-sized bit-field falls into this category.  This was not handled
> correctly for C structs and in G++-11 only handled correctly because
> such fields were eliminated early by the front end.
> 
> gcc/ChangeLog:
> 
>   PR target/102024
>   * config/arm/arm.cc (aapcs_vfp_sub_candidate): Handle zero-sized
>   bit-fields.  Detect cases where a warning may be needed.
>   (aapcs_vfp_is_call_or_return_candidate): Emit a note if
>   a zero-sized bit-field has caused parameter passing to change.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR target/102024
>   * gcc.target/arm/aapcs/vfp26.c: New test.
> ---
>  gcc/config/arm/arm.cc  | 35 --
>  gcc/testsuite/gcc.target/arm/aapcs/vfp26.c | 31 +++
>  2 files changed, 63 insertions(+), 3 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/arm/aapcs/vfp26.c
> 

> diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
> index e062361b985..43b775f6918 100644
> --- a/gcc/config/arm/arm.cc
> +++ b/gcc/config/arm/arm.cc
> @@ -6274,6 +6274,7 @@ aapcs_vfp_cum_init (CUMULATIVE_ARGS *pcum  
> ATTRIBUTE_UNUSED,
>a HFA or HVA.  */
>  const unsigned int WARN_PSABI_EMPTY_CXX17_BASE = 1U << 0;
>  const unsigned int WARN_PSABI_NO_UNIQUE_ADDRESS = 1U << 1;
> +const unsigned int WARN_PSABI_ZERO_WIDTH_BITFIELD = 1U << 2;
>  
>  /* Walk down the type tree of TYPE counting consecutive base elements.
> If *MODEP is VOIDmode, then set it to the first valid floating point
> @@ -6426,6 +6427,28 @@ aapcs_vfp_sub_candidate (const_tree type, machine_mode 
> *modep,
>   continue;
> }
> }
> + /* A zero-width bitfield may affect layout in some
> +circumstances, but adds no members.  The determination
> +of whether or not a type is an HFA is performed after
> +layout is complete, so if the type still looks like an
> +HFA afterwards, it is still classed as one.  This is
> +potentially an ABI break for the hard-float ABI.  */
> + else if (DECL_BIT_FIELD (field)
> +  && integer_zerop (DECL_SIZE (field)))
> +   {
> + /* Prior to GCC-12 these fields were striped early,
> +hiding them from the back-end entirely and
> +resulting in the correct behaviour for argument
> +passing.  Simulate that old behaviour without
> +generating a warning.  */
> + if (DECL_FIELD_CXX_ZERO_WIDTH_BIT_FIELD (field))
> +   continue;
> + if (warn_psabi_flags)
> +   {
> + *warn_psabi_flags |= WARN_PSABI_ZERO_WIDTH_BITFIELD;
> + continue;
> +   }
> +   }
>  
>   sub_count = aapcs_vfp_sub_candidate (TREE_TYPE (field), modep,
>warn_psabi_flags);
> @@ -6538,8 +6561,10 @@ aapcs_vfp_is_call_or_return_candidate (enum arm_pcs 
> pcs_variant,
> && ((alt = aapcs_vfp_sub_candidate (type, _mode, NULL))
> != ag_count))
>   {
> -   const char *url
> +   const char *url10
>   = CHANGES_ROOT_URL "gcc-10/changes.html#empty_base";
> +   const char *url12
> + = CHANGES_ROOT_URL "gcc-12/changes.html#empty_base";

This should be
= CHANGES_ROOT_URL "gcc-12/changes.html#zero_width_bitfields";
instead.

Otherwise LGTM.

Jakub

[PATCH] gimple: Wrong -Wimplicit-fallthrough with if(1) [PR103597]

[Marek Polacek via Gcc-patches]

This patch fixes a wrong -Wimplicit-fallthrough warning for

case 0:
  if (1)  // wrong may fallthrough
return 0;
case 1:

which in .gimple looks like

: // case 0
if (1 != 0) goto ; else goto ;
:
D.1987 = 0;
// predicted unlikely by early return (on trees) predictor.
return D.1987;
:  // dead
: // case 1

and the warning thinks that : falls through to :.  It
does not know that  is effectively a dead label, only reachable
through fallthrough from previous instructions, never jumped to.  To
that effect, Jakub introduced UNUSED_LABEL_P, which is set on such dead
labels.

collect_fallthrough_labels has code to deal with cases like

case 2:
  if (e != 10)
i++; // this may fallthru, warn
  else
return 44;
case 3:

which collects labels that may fall through.  Here it sees the "goto ;"
at the end of the then branch and so when the warning reaches

...
: // from if-then
: // case 3

it knows it should warn about the possible fallthrough.  But an UNUSED_LABEL_P
is not a label that can fallthrough like that, so it should ignore those.

However, we still want to warn about this:

case 0:
  if (1)
n++; // falls through
case 1:

so collect_fallthrough_labels needs to return the "n = n + 1;" statement, rather
than the dead label.

Co-authored-by: Jakub Jelinek 

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

PR middle-end/103597

gcc/ChangeLog:

* gimplify.cc (collect_fallthrough_labels): Don't push UNUSED_LABEL_Ps
into labels.  Maybe set prev to the statement preceding UNUSED_LABEL_P.
(gimplify_cond_expr): Set UNUSED_LABEL_P.
* tree.h (UNUSED_LABEL_P): New.

gcc/testsuite/ChangeLog:

* c-c++-common/Wimplicit-fallthrough-39.c: New test.
---
 gcc/gimplify.cc   |  54 ++-
 .../c-c++-common/Wimplicit-fallthrough-39.c   | 140 ++
 gcc/tree.h|   6 +
 3 files changed, 194 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/Wimplicit-fallthrough-39.c

diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index f62f150fc08..2588824dce2 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -2250,9 +2250,9 @@ last_stmt_in_scope (gimple *stmt)
 }
 }
 
-/* Collect interesting labels in LABELS and return the statement preceding
-   another case label, or a user-defined label.  Store a location useful
-   to give warnings at *PREVLOC (usually the location of the returned
+/* Collect labels that may fall through into LABELS and return the statement
+   preceding another case label, or a user-defined label.  Store a location
+   useful to give warnings at *PREVLOC (usually the location of the returned
statement or of its surrounding scope).  */
 
 static gimple *
@@ -2331,8 +2331,12 @@ collect_fallthrough_labels (gimple_stmt_iterator *gsi_p,
  if (gsi_end_p (*gsi_p))
break;
 
- struct label_entry l = { false_lab, if_loc };
- labels->safe_push (l);
+ /* A dead label can't fall through.  */
+ if (!UNUSED_LABEL_P (false_lab))
+   {
+ struct label_entry l = { false_lab, if_loc };
+ labels->safe_push (l);
+   }
 
  /* Go to the last statement of the then branch.  */
  gsi_prev (gsi_p);
@@ -2359,6 +2363,17 @@ collect_fallthrough_labels (gimple_stmt_iterator *gsi_p,
  labels->safe_push (l);
}
}
+ /* This case is about
+ if (1 != 0) goto ; else goto ;
+ :
+ n = n + 1; // #1
+ :  // #2
+ :  // #3
+where #2 is UNUSED_LABEL_P and we want to warn about #1 falling
+through to #3.  So set PREV to #1.  */
+ else if (UNUSED_LABEL_P (false_lab))
+   prev = gsi_stmt (*gsi_p);
+
  /* And move back.  */
  gsi_next (gsi_p);
}
@@ -4461,9 +4476,19 @@ gimplify_cond_expr (tree *expr_p, gimple_seq *pre_p, 
fallback_t fallback)
   if (TREE_OPERAND (expr, 1) == NULL_TREE
  && !have_else_clause_p
  && TREE_OPERAND (expr, 2) != NULL_TREE)
-   label_cont = label_true;
+   {
+ /* For if (0) {} else { code; } tell -Wimplicit-fallthrough
+handling that label_cont == label_true can be only reached
+through fallthrough from { code; }.  */
+ if (integer_zerop (COND_EXPR_COND (expr)))
+   UNUSED_LABEL_P (label_true) = 1;
+ label_cont = label_true;
+   }
   else
{
+ bool then_side_effects
+   = (TREE_OPERAND (expr, 1)
+  && TREE_SIDE_EFFECTS (TREE_OPERAND (expr, 1)));
  gimplify_seq_add_stmt (, gimple_build_label (label_true));
  have_then_clause_p = gimplify_stmt (_OPERAND (expr, 1), );
  /* For if (...) { code; } else {} or
@@ -4477,6 +4502,16 @@ 

[committed] arm: temporarily disable 'local' pcs selection (PR96882)

[Richard Earnshaw via Gcc-patches]

The arm port has an optimization used during selection of the
function's ABI to permit deviation from the strict ABI when the
function does not escape the current translation unit.

Unfortunately, the ABI selection it makes can be unsafe if it changes
how a result is returned because not enough information is available
via the RETURN_IN_MEMORY hook to determine where the function gets
used.  This can result in some parts of the compiler thinking a value
is returned in memory while others think it is returned in registers.

To mitigate this, this patch temporarily disables the optimization and
falls back to using the default ABI for the translation.

gcc/ChangeLog:

PR target/96882
* config/arm/arm.cc (arm_get_pcs_model): Disable selection of
ARM_PCS_AAPCS_LOCAL.
---
 gcc/config/arm/arm.cc | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index e062361b985..26ed7f97fc6 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -6194,7 +6194,7 @@ arm_pcs_from_attribute (tree attr)
specification, DECL is the specific declartion.  DECL may be null if
the call could be indirect or if this is a library call.  */
 static enum arm_pcs
-arm_get_pcs_model (const_tree type, const_tree decl)
+arm_get_pcs_model (const_tree type, const_tree decl ATTRIBUTE_UNUSED)
 {
   bool user_convention = false;
   enum arm_pcs user_pcs = arm_pcs_default;
@@ -6228,6 +6228,14 @@ arm_get_pcs_model (const_tree type, const_tree decl)
 	return ARM_PCS_AAPCS;
   else if (user_convention)
 	return user_pcs;
+#if 0
+  /* Unfortunately, this is not safe and can lead to wrong code
+	 being generated (PR96882).  Not all calls into the back-end
+	 pass the DECL, so it is unsafe to make any PCS-changing
+	 decisions based on it.  In particular the RETURN_IN_MEMORY
+	 hook is only ever passed a TYPE.  This needs revisiting to
+	 see if there are any partial improvements that can be
+	 re-enabled.  */
   else if (decl && flag_unit_at_a_time)
 	{
 	  /* Local functions never leak outside this compilation unit,
@@ -6239,6 +6247,7 @@ arm_get_pcs_model (const_tree type, const_tree decl)
 	  if (local_info_node && local_info_node->local)
 	return ARM_PCS_AAPCS_LOCAL;
 	}
+#endif
 }
   else if (user_convention && user_pcs != arm_pcs_default)
 sorry ("PCS variant");

Re: [PING^2 PATCH 3/3] rs6000: Move more g++.dg powerpc tests to g++.target

[Paul A. Clarke via Gcc-patches]

Ping.

On Tue, Mar 08, 2022 at 01:59:47PM -0600, Paul A. Clarke via Gcc-patches wrote:
> Ping.
> 
> On Mon, Feb 21, 2022 at 03:17:47PM -0600, Paul A. Clarke via Gcc-patches 
> wrote:
> > Also adjust DejaGnu directives, as specifically requiring "powerpc*-*-*" is 
> > no
> > longer required.
> > 
> > 2021-02-21  Paul A. Clarke  
> > 
> > gcc/testsuite
> > * g++.dg/debug/dwarf2/const2.C: Move to g++.target/powerpc.
> > * g++.dg/other/darwin-minversion-1.C: Likewise.
> > * g++.dg/eh/ppc64-sighandle-cr.C: Likewise.
> > * g++.dg/eh/simd-5.C: Likewise.
> > * g++.dg/eh/simd-4.C: Move to g++.target/powerpc, adjust dg directives.
> > * g++.dg/eh/uncaught3.C: Likewise.
> > * g++.dg/other/spu2vmx-1.C: Likewise.
> > ---
> >  .../{g++.dg/debug/dwarf2 => g++.target/powerpc}/const2.C| 0
> >  .../{g++.dg/other => g++.target/powerpc}/darwin-minversion-1.C  | 0
> >  .../{g++.dg/eh => g++.target/powerpc}/ppc64-sighandle-cr.C  | 0
> >  gcc/testsuite/{g++.dg/eh => g++.target/powerpc}/simd-4.C| 2 +-
> >  gcc/testsuite/{g++.dg/eh => g++.target/powerpc}/simd-5.C| 0
> >  gcc/testsuite/{g++.dg/other => g++.target/powerpc}/spu2vmx-1.C  | 2 +-
> >  gcc/testsuite/{g++.dg/eh => g++.target/powerpc}/uncaught3.C | 2 +-
> >  7 files changed, 3 insertions(+), 3 deletions(-)
> >  rename gcc/testsuite/{g++.dg/debug/dwarf2 => g++.target/powerpc}/const2.C 
> > (100%)
> >  rename gcc/testsuite/{g++.dg/other => 
> > g++.target/powerpc}/darwin-minversion-1.C (100%)
> >  rename gcc/testsuite/{g++.dg/eh => 
> > g++.target/powerpc}/ppc64-sighandle-cr.C (100%)
> >  rename gcc/testsuite/{g++.dg/eh => g++.target/powerpc}/simd-4.C (95%)
> >  rename gcc/testsuite/{g++.dg/eh => g++.target/powerpc}/simd-5.C (100%)
> >  rename gcc/testsuite/{g++.dg/other => g++.target/powerpc}/spu2vmx-1.C (84%)
> >  rename gcc/testsuite/{g++.dg/eh => g++.target/powerpc}/uncaught3.C (96%)
> > 
> > diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/const2.C 
> > b/gcc/testsuite/g++.target/powerpc/const2.C
> > similarity index 100%
> > rename from gcc/testsuite/g++.dg/debug/dwarf2/const2.C
> > rename to gcc/testsuite/g++.target/powerpc/const2.C
> > diff --git a/gcc/testsuite/g++.dg/other/darwin-minversion-1.C 
> > b/gcc/testsuite/g++.target/powerpc/darwin-minversion-1.C
> > similarity index 100%
> > rename from gcc/testsuite/g++.dg/other/darwin-minversion-1.C
> > rename to gcc/testsuite/g++.target/powerpc/darwin-minversion-1.C
> > diff --git a/gcc/testsuite/g++.dg/eh/ppc64-sighandle-cr.C 
> > b/gcc/testsuite/g++.target/powerpc/ppc64-sighandle-cr.C
> > similarity index 100%
> > rename from gcc/testsuite/g++.dg/eh/ppc64-sighandle-cr.C
> > rename to gcc/testsuite/g++.target/powerpc/ppc64-sighandle-cr.C
> > diff --git a/gcc/testsuite/g++.dg/eh/simd-4.C 
> > b/gcc/testsuite/g++.target/powerpc/simd-4.C
> > similarity index 95%
> > rename from gcc/testsuite/g++.dg/eh/simd-4.C
> > rename to gcc/testsuite/g++.target/powerpc/simd-4.C
> > index 8c9b58bf8684..a01f19c27369 100644
> > --- a/gcc/testsuite/g++.dg/eh/simd-4.C
> > +++ b/gcc/testsuite/g++.target/powerpc/simd-4.C
> > @@ -1,4 +1,4 @@
> > -/* { dg-do run { target powerpc*-*-darwin* } } */
> > +/* { dg-do run { target *-*-darwin* } } */
> >  /* { dg-options "-fexceptions -fnon-call-exceptions -O -maltivec" } */
> >  
> >  #include 
> > diff --git a/gcc/testsuite/g++.dg/eh/simd-5.C 
> > b/gcc/testsuite/g++.target/powerpc/simd-5.C
> > similarity index 100%
> > rename from gcc/testsuite/g++.dg/eh/simd-5.C
> > rename to gcc/testsuite/g++.target/powerpc/simd-5.C
> > diff --git a/gcc/testsuite/g++.dg/other/spu2vmx-1.C 
> > b/gcc/testsuite/g++.target/powerpc/spu2vmx-1.C
> > similarity index 84%
> > rename from gcc/testsuite/g++.dg/other/spu2vmx-1.C
> > rename to gcc/testsuite/g++.target/powerpc/spu2vmx-1.C
> > index d9c8faf94592..496b46c22c95 100644
> > --- a/gcc/testsuite/g++.dg/other/spu2vmx-1.C
> > +++ b/gcc/testsuite/g++.target/powerpc/spu2vmx-1.C
> > @@ -1,4 +1,4 @@
> > -/* { dg-do compile { target powerpc*-*-* } } */
> > +/* { dg-do compile } */
> >  /* { dg-require-effective-target powerpc_spu } */
> >  /* { dg-options "-maltivec" } */
> >  
> > diff --git a/gcc/testsuite/g++.dg/eh/uncaught3.C 
> > b/gcc/testsuite/g++.target/powerpc/uncaught3.C
> > similarity index 96%
> > rename from gcc/testsuite/g++.dg/eh/uncaught3.C
> > rename to gcc/testsuite/g++.target/powerpc/uncaught3.C
> > index 1beaab3f..f891401584ec 100644
> > --- a/gcc/testsuite/g++.dg/eh/uncaught3.C
> > +++ b/gcc/testsuite/g++.target/powerpc/uncaught3.C
> > @@ -1,4 +1,4 @@
> > -// { dg-do compile { target powerpc*-*-darwin* } }
> > +// { dg-do compile { target *-*-darwin* } }
> >  // { dg-final { scan-assembler-not "__cxa_get_exception" } }
> >  // { dg-options "-mmacosx-version-min=10.4" }
> >  // { dg-additional-options "-Wno-deprecated" { target c++17 } }
> > -- 
> > 2.27.0
> > 

Re: [PING^2 PATCH 2/3] rs6000: Move g++.dg powerpc PR tests to g++.target

[Paul A. Clarke via Gcc-patches]

Ping.

On Tue, Mar 08, 2022 at 02:03:04PM -0600, Paul A. Clarke via Gcc-patches wrote:
> Gentle ping. I am grateful for the initial review, but seek closure on the
> final couple of discussion items. Thanks!
> 
> PC
> 
> On Tue, Feb 22, 2022 at 07:56:40PM -0600, Paul A. Clarke via Gcc-patches 
> wrote:
> > On Tue, Feb 22, 2022 at 06:41:45PM -0600, Segher Boessenkool wrote:
> > > On Mon, Feb 21, 2022 at 03:17:46PM -0600, Paul A. Clarke wrote:
> > > > Also adjust DejaGnu directives, as specifically requiring 
> > > > "powerpc*-*-*" is no
> > > > longer required.
> > > > 
> > > > 2021-02-21  Paul A. Clarke  
> > > > 
> > > > gcc/testsuite
> > > > * g++.dg/pr65240.h: Move to g++.target/powerpc.
> > > > * g++.dg/pr93974.C: Likewise.
> > > > * g++.dg/pr65240-1.C: Move to g++.target/powerpc, adjust dg 
> > > > directives.
> > > > * g++.dg/pr65240-2.C: Likewise.
> > > > * g++.dg/pr65240-3.C: Likewise.
> > > > * g++.dg/pr65240-4.C: Likewise.
> > > > * g++.dg/pr65242.C: Likewise.
> > > > * g++.dg/pr67211.C: Likewise.
> > > > * g++.dg/pr69667.C: Likewise.
> > > > * g++.dg/pr71294.C: Likewise.
> > > > * g++.dg/pr84264.C: Likewise.
> > > > * g++.dg/pr84279.C: Likewise.
> > > > * g++.dg/pr85657.C: Likewise.
> > > 
> > > Okay for trunk.  Thanks!
> > 
> > Thanks for the review! More below...
> > 
> > > That said...
> > > 
> > > > -/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
> > > > -/* { dg-skip-if "" { powerpc*-*-darwin* } } */
> > > > +/* { dg-do compile { target lp64 } } */
> > > > +/* { dg-skip-if "" { *-*-darwin* } } */
> > > 
> > > That skip-if is most likely cargo cult, and it's not clear why lp64
> > > would be needed either (there is no comment what it is needed for, for
> > > example).
> > 
> > I can't speak to darwin, nor have an easy way of testing on it.
> > 
> > As for lp64, these tests fail on -m32 with:
> >   cc1plus: error: '-mcmodel' not supported in this configuration
> > - g++.dg/pr65240-1.C
> > - g++.dg/pr65240-2.C
> > - g++.dg/pr65240-3.C
> > 
> > '-mcmodel' is in the dg-options line for the above tests.
> > 
> > The rest PASSed.  Shall I remove the 'lp64' restriction for those that PASS?
> > 
> > > > +++ b/gcc/testsuite/g++.target/powerpc/pr85657.C
> > > > @@ -1,4 +1,4 @@
> > > > -// { dg-do compile { target { powerpc*-*-linux* } } }
> > > > +// { dg-do compile { target { *-*-linux* } } }
> > > 
> > > A comment here would help as well.  All of that is pre-existing of
> > > course.
> > 
> > I'm not sure what such a comment would say. I suspect it was a testing issue
> > (only tested on Linux), but I have similar limitations, so I'm also 
> > reluctant
> > to enable the test for what would be untested (by me) platforms.
> > 
> > PC

[PATCH 2/2] aarch64: correctly handle zero-sized bit-fields in AAPCS64 [PR102024]

[Richard Earnshaw via Gcc-patches]

On aarch64 the AAPCS64 states that an HFA is determined by the 'shape' of
the object after layout has been completed, so anything that adds no
members and does not cause the layout to be modified should be ignored
for the purposes of determining which registers are used for parameter
passing.

A zero-sized bit-field falls into this category.  This was not handled
correctly for C structs and in G++-11 only handled correctly because
such fields were eliminated early by the front end.

gcc/ChangeLog:

PR target/102024
* config/aarch64/aarch64.cc (aapcs_vfp_sub_candidate): Handle
zero-sized bit-fields.  Detect cases where a warning may be needed.
(aarch64_vfp_is_call_or_return_candidate): Emit a note if a
zero-sized bit-field has caused parameter passing to change.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/aapcs64/test_28.c: New test.
---
 gcc/config/aarch64/aarch64.cc | 35 +--
 .../gcc.target/aarch64/aapcs64/test_28.c  | 28 +++
 2 files changed, 60 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/aarch64/aapcs64/test_28.c

diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index dbeaaf484db..296f393cf39 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -19355,6 +19355,7 @@ aarch64_member_type_forces_blk (const_tree field_or_array, machine_mode mode)
   a HFA or HVA.  */
 const unsigned int WARN_PSABI_EMPTY_CXX17_BASE = 1U << 0;
 const unsigned int WARN_PSABI_NO_UNIQUE_ADDRESS = 1U << 1;
+const unsigned int WARN_PSABI_ZERO_WIDTH_BITFIELD = 1U << 2;
 
 /* Walk down the type tree of TYPE counting consecutive base elements.
If *MODEP is VOIDmode, then set it to the first valid floating point
@@ -19511,6 +19512,28 @@ aapcs_vfp_sub_candidate (const_tree type, machine_mode *modep,
 		continue;
 		  }
 	  }
+	/* A zero-width bitfield may affect layout in some
+	   circumstances, but adds no members.  The determination
+	   of whether or not a type is an HFA is performed after
+	   layout is complete, so if the type still looks like an
+	   HFA afterwards, it is still classed as one.  This is
+	   potentially an ABI break for the hard-float ABI.  */
+	else if (DECL_BIT_FIELD (field)
+		 && integer_zerop (DECL_SIZE (field)))
+	  {
+		/* Prior to GCC-12 these fields were striped early,
+		   hiding them from the back-end entirely and
+		   resulting in the correct behaviour for argument
+		   passing.  Simulate that old behaviour without
+		   generating a warning.  */
+		if (DECL_FIELD_CXX_ZERO_WIDTH_BIT_FIELD (field))
+		  continue;
+		if (warn_psabi_flags)
+		  {
+		*warn_psabi_flags |= WARN_PSABI_ZERO_WIDTH_BITFIELD;
+		continue;
+		  }
+	  }
 
 	sub_count = aapcs_vfp_sub_candidate (TREE_TYPE (field), modep,
 		 warn_psabi_flags);
@@ -19711,8 +19734,10 @@ aarch64_vfp_is_call_or_return_candidate (machine_mode mode,
 	  && ((alt = aapcs_vfp_sub_candidate (type, _mode, NULL))
 		  != ag_count))
 	{
-	  const char *url
+	  const char *url10
 		= CHANGES_ROOT_URL "gcc-10/changes.html#empty_base";
+	  const char *url12
+		= CHANGES_ROOT_URL "gcc-12/changes.html#empty_base";
 	  gcc_assert (alt == -1);
 	  last_reported_type_uid = uid;
 	  /* Use TYPE_MAIN_VARIANT to strip any redundant const
@@ -19721,12 +19746,16 @@ aarch64_vfp_is_call_or_return_candidate (machine_mode mode,
 		inform (input_location, "parameter passing for argument of "
 			"type %qT with %<[[no_unique_address]]%> members "
 			"changed %{in GCC 10.1%}",
-			TYPE_MAIN_VARIANT (type), url);
+			TYPE_MAIN_VARIANT (type), url10);
 	  else if (warn_psabi_flags & WARN_PSABI_EMPTY_CXX17_BASE)
 		inform (input_location, "parameter passing for argument of "
 			"type %qT when C++17 is enabled changed to match "
 			"C++14 %{in GCC 10.1%}",
-			TYPE_MAIN_VARIANT (type), url);
+			TYPE_MAIN_VARIANT (type), url10);
+	  else if (warn_psabi_flags & WARN_PSABI_ZERO_WIDTH_BITFIELD)
+		inform (input_location, "parameter passing for argument of "
+			"type %qT changed %{in GCC 12.1%}",
+			TYPE_MAIN_VARIANT (type), url12);
 	}
 
 	  if (is_ha != NULL) *is_ha = true;
diff --git a/gcc/testsuite/gcc.target/aarch64/aapcs64/test_28.c b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_28.c
new file mode 100644
index 000..951057b3509
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/aapcs64/test_28.c
@@ -0,0 +1,28 @@
+/* Test AAPCS64 layout for HFA with zero-sized bit-field.  */
+
+/* { dg-do run { target aarch64*-*-* } } */
+
+#ifndef IN_FRAMEWORK
+#define VFP
+#define TESTFILE "test_28.c"
+
+/* Anonymous bitfields do not add members; if they do not change the layout
+   then the end result may still be an HFA.  */
+struct z
+{
+  float a;
+  int :0;
+  float b;
+};
+
+struct z a = { 5.0f, 6.0f };
+struct z b = { 9.0f, 10.0f };
+
+#define MYFUNCTYPE struct z
+
+#include 

[PATCH 1/2] arm: correctly handle zero-sized bit-fields in AAPCS [PR102024]

[Richard Earnshaw via Gcc-patches]

On arm the AAPCS states that an HFA is determined by the 'shape' of
the object after layout has been completed, so anything that adds no
members and does not cause the layout to be modified should be ignored
for the purposes of determining which registers are used for parameter
passing.

A zero-sized bit-field falls into this category.  This was not handled
correctly for C structs and in G++-11 only handled correctly because
such fields were eliminated early by the front end.

gcc/ChangeLog:

PR target/102024
* config/arm/arm.cc (aapcs_vfp_sub_candidate): Handle zero-sized
bit-fields.  Detect cases where a warning may be needed.
(aapcs_vfp_is_call_or_return_candidate): Emit a note if
a zero-sized bit-field has caused parameter passing to change.

gcc/testsuite/ChangeLog:

PR target/102024
* gcc.target/arm/aapcs/vfp26.c: New test.
---
 gcc/config/arm/arm.cc  | 35 --
 gcc/testsuite/gcc.target/arm/aapcs/vfp26.c | 31 +++
 2 files changed, 63 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arm/aapcs/vfp26.c

diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index e062361b985..43b775f6918 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -6274,6 +6274,7 @@ aapcs_vfp_cum_init (CUMULATIVE_ARGS *pcum  ATTRIBUTE_UNUSED,
   a HFA or HVA.  */
 const unsigned int WARN_PSABI_EMPTY_CXX17_BASE = 1U << 0;
 const unsigned int WARN_PSABI_NO_UNIQUE_ADDRESS = 1U << 1;
+const unsigned int WARN_PSABI_ZERO_WIDTH_BITFIELD = 1U << 2;
 
 /* Walk down the type tree of TYPE counting consecutive base elements.
If *MODEP is VOIDmode, then set it to the first valid floating point
@@ -6426,6 +6427,28 @@ aapcs_vfp_sub_candidate (const_tree type, machine_mode *modep,
 		continue;
 		  }
 	  }
+	/* A zero-width bitfield may affect layout in some
+	   circumstances, but adds no members.  The determination
+	   of whether or not a type is an HFA is performed after
+	   layout is complete, so if the type still looks like an
+	   HFA afterwards, it is still classed as one.  This is
+	   potentially an ABI break for the hard-float ABI.  */
+	else if (DECL_BIT_FIELD (field)
+		 && integer_zerop (DECL_SIZE (field)))
+	  {
+		/* Prior to GCC-12 these fields were striped early,
+		   hiding them from the back-end entirely and
+		   resulting in the correct behaviour for argument
+		   passing.  Simulate that old behaviour without
+		   generating a warning.  */
+		if (DECL_FIELD_CXX_ZERO_WIDTH_BIT_FIELD (field))
+		  continue;
+		if (warn_psabi_flags)
+		  {
+		*warn_psabi_flags |= WARN_PSABI_ZERO_WIDTH_BITFIELD;
+		continue;
+		  }
+	  }
 
 	sub_count = aapcs_vfp_sub_candidate (TREE_TYPE (field), modep,
 		 warn_psabi_flags);
@@ -6538,8 +6561,10 @@ aapcs_vfp_is_call_or_return_candidate (enum arm_pcs pcs_variant,
 	  && ((alt = aapcs_vfp_sub_candidate (type, _mode, NULL))
 		  != ag_count))
 	{
-	  const char *url
+	  const char *url10
 		= CHANGES_ROOT_URL "gcc-10/changes.html#empty_base";
+	  const char *url12
+		= CHANGES_ROOT_URL "gcc-12/changes.html#empty_base";
 	  gcc_assert (alt == -1);
 	  last_reported_type_uid = uid;
 	  /* Use TYPE_MAIN_VARIANT to strip any redundant const
@@ -6548,12 +6573,16 @@ aapcs_vfp_is_call_or_return_candidate (enum arm_pcs pcs_variant,
 		inform (input_location, "parameter passing for argument of "
 			"type %qT with %<[[no_unique_address]]%> members "
 			"changed %{in GCC 10.1%}",
-			TYPE_MAIN_VARIANT (type), url);
+			TYPE_MAIN_VARIANT (type), url10);
 	  else if (warn_psabi_flags & WARN_PSABI_EMPTY_CXX17_BASE)
 		inform (input_location, "parameter passing for argument of "
 			"type %qT when C++17 is enabled changed to match "
 			"C++14 %{in GCC 10.1%}",
-			TYPE_MAIN_VARIANT (type), url);
+			TYPE_MAIN_VARIANT (type), url10);
+	  else if (warn_psabi_flags & WARN_PSABI_ZERO_WIDTH_BITFIELD)
+		inform (input_location, "parameter passing for argument of "
+			"type %qT changed %{in GCC 12.1%}",
+			TYPE_MAIN_VARIANT (type), url12);
 	}
 	  *count = ag_count;
 	}
diff --git a/gcc/testsuite/gcc.target/arm/aapcs/vfp26.c b/gcc/testsuite/gcc.target/arm/aapcs/vfp26.c
new file mode 100644
index 000..9b1e8aa39d6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/aapcs/vfp26.c
@@ -0,0 +1,31 @@
+/* Test AAPCS layout (VFP variant) */
+
+/* { dg-do run { target arm_eabi } } */
+/* { dg-require-effective-target arm_hard_vfp_ok } */
+/* { dg-require-effective-target arm32 } */
+/* { dg-options "-O -mfpu=vfp -mfloat-abi=hard" } */
+
+#ifndef IN_FRAMEWORK
+#define VFP
+#define TESTFILE "vfp26.c"
+
+/* Anonymous bitfields do not add members; if they do not change the layout
+   then the end result may still be an HFA.  */
+struct z
+{
+  float a;
+  int :0;
+  float b;
+};
+
+struct z a = { 5.0f, 6.0f };
+struct z b = { 9.0f, 10.0f };
+
+#define 

Re: options: Remove 'gcc/c-family/c.opt:Wuse-after-free' option definition record (was: [PATCH v2 1/2] add -Wuse-after-free)

[Martin Sebor via Gcc-patches]

On 3/29/22 03:24, Thomas Schwinge wrote:

Hi!

On 2022-01-15T17:00:11-0700, Martin Sebor via Gcc-patches 
 wrote:

On 1/11/22 15:40, Jason Merrill wrote:

On 11/30/21 17:32, Martin Sebor via Gcc-patches wrote:

[default setting of the option]



Let's put =2 in -Wall for now.



I've adjusted [...] and pushed r12-6605 [...]


That's from commit 671a283636de75f7ed638ee6b01ed2d44361b8b6
"Add -Wuse-after-free [PR80532]":

| --- gcc/common.opt
| +++ gcc/common.opt
| [...]
| +Wuse-after-free
| +Common Var(warn_use_after_free) Warning
| +Warn for uses of pointers to deallocated strorage.
| +
| +Wuse-after-free=
| +Common Joined RejectNegative UInteger Var(warn_use_after_free) Warning 
IntegerRange(0, 3)
| +Warn for uses of pointers to deallocated strorage.
| [...]

| --- gcc/c-family/c.opt
| +++ gcc/c-family/c.opt
| [...]
| +# Defining these options here in addition to common.opt is necessary
| +# in order for the default -Wall setting of -Wuse-after-free=2 to take
| +# effect.
| +
| +Wuse-after-free
| +LangEnabledBy(C ObjC C++ LTO ObjC++)
| +; in common.opt
| +
| +Wuse-after-free=
| +LangEnabledBy(C ObjC C++ LTO ObjC++, Wall,2,0)
| +; in common.opt
| [...]

OK to push the attached "options: Remove
'gcc/c-family/c.opt:Wuse-after-free' option definition record"?


It's fine with me if it passes tests.  I remember noticing a subtle
distinction in how option aliases are sometimes treated in #pragma
GCC diagnostic but not the exact details.  I added tests to make
sure it has the expected effect without the trailing =.  See
the comment in c-c++-common/Wuse-after-free.c.

Thanks
Martin




Grüße
  Thomas


-
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

Re: [PATCH][nvptx, doc] Update misa and mptx, add march and march-map

[Tobias Burnus]

On 29.03.22 16:28, Tobias Burnus wrote:


On 29.03.22 15:39, Tom de Vries wrote:

Any comments?


I think it would be useful to have additionally some wording for the
(new in GCC 12/new since today) macros, i.e. something like:

--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -27546,6 +27546,10 @@
 strings must be lower-case.  Valid ISA strings include @samp{sm_30} and
 @samp{sm_35}.  The default ISA is sm_35.

+This option causes the preprocessor macro @code{__PTX_SM__} to be defined
+to the architecture number multiplied by ten; for instance, for
+@samp{sm_35}, it has the value @samp{350}.
+
 @item -mptx=@var{version-string}
 @opindex mptx
 Generate code for given the specified PTX version (e.g.@: @samp{7.0}).
@@ -27553,6 +27557,10 @@
 @samp{7.0}.  The default PTX version is 6.0, unless a higher minimal
 version is required for specified PTX ISA via option @option{-misa=}.

+This option causes the preprocessor macros @code{__PTX_ISA_VERSION_MAJOR__}
+and @code{__PTX_ISA_VERSION_MINOR__} to be defined; for instance,
+for @samp{3.1} the macros have the values @samp{3} and @samp{1}, respectively.
+
 @item -mmainkernel
 @opindex mmainkernel
 Link in code for a __main kernel.  This is for stand-alone instead of

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

Re: [PATCH][nvptx, doc] Update misa and mptx, add march and march-map

[Tobias Burnus]

Hi Tom,

On 29.03.22 15:39, Tom de Vries wrote:

Any comments?
+(e.g.@: @samp{sm_35}).  Valid architecture strings are @samp{sm_30},
+@samp{sm_35}, @samp{sm_53} @samp{sm_70}, @samp{sm_75} and
+@samp{sm_80}.  The default target architecture is sm_30.


Missing comma (",") between sm_53 and sm_70.

I want to note that the default is now back at sm_30;
for GCC 11 it was changed to sm_35, cf. https://gcc.gnu.org/gcc-11/changes.html
(We also need to update the wwwdocs release notes before the release, but it
can also be done after branching).


+@item -march-map=@var{architecture-string}
+@opindex march
+Select the closest available @option{-march=} value that is not more
+capable.  For instance, for @option{-march-map=sm_50} select
+@option{-march=sm_35}, and for @option{-march-map=sm_53} select
+@option{-march=sm_53}.


(Somehow, I am not completely happy with the wording, but, admittedly, I
don't have a better suggestion.)

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

[committed][nvptx] Add __PTX_ISA_VERSION_{MAJOR,MINOR}__

[Tom de Vries via Gcc-patches]

Hi,

Add preprocessor macros __PTX_ISA_VERSION_MAJOR__ and
__PTX_ISA_VERSION_MINOR__.

For the default 6.0, we have:
...
 $ echo | cc1 -E -dD - 2>&1 | grep PTX_ISA_VERSION
 #define __PTX_ISA_VERSION_MAJOR__ 6
 #define __PTX_ISA_VERSION_MINOR__ 0
...
and for 3.1, we have:
...
 $ echo | cc1 -mptx=3.1 -E -dD - 2>&1 | grep PTX_ISA_VERSION
 #define __PTX_ISA_VERSION_MAJOR__ 3
 #define __PTX_ISA_VERSION_MINOR__ 1
...

These can be used to express things like:
...
 #if __PTX_ISA_VERSION_MAJOR__ >= 4 && __PTX_ISA_VERSION_MAJOR__ >= 1
   /* Code using %dynamic_smem_size.  */
 #else
   /* Fallback code.  */
 #endif
...

Tested on nvptx.

Committed to trunk.

Thanks,
- Tom

[nvptx] Add __PTX_ISA_VERSION_{MAJOR,MINOR}__

gcc/ChangeLog:

2022-03-29  Tom de Vries  

PR target/104857
* config/nvptx/nvptx-c.cc (nvptx_cpu_cpp_builtins): Emit
__PTX_ISA_VERSION_MAJOR__ and __PTX_ISA_VERSION_MINOR__.
* config/nvptx/nvptx.cc (ptx_version_to_number): New function.
* config/nvptx/nvptx-protos.h (ptx_version_to_number): Declare.

gcc/testsuite/ChangeLog:

2022-03-29  Tom de Vries  

PR target/104857
* gcc.target/nvptx/ptx31.c: New test.
* gcc.target/nvptx/ptx60.c: New test.
* gcc.target/nvptx/ptx63.c: New test.
* gcc.target/nvptx/ptx70.c: New test.

---
 gcc/config/nvptx/nvptx-c.cc|  9 +
 gcc/config/nvptx/nvptx-protos.h|  1 +
 gcc/config/nvptx/nvptx.cc  | 22 ++
 gcc/testsuite/gcc.target/nvptx/ptx31.c | 10 ++
 gcc/testsuite/gcc.target/nvptx/ptx60.c | 10 ++
 gcc/testsuite/gcc.target/nvptx/ptx63.c | 10 ++
 gcc/testsuite/gcc.target/nvptx/ptx70.c | 10 ++
 7 files changed, 72 insertions(+)

diff --git a/gcc/config/nvptx/nvptx-c.cc b/gcc/config/nvptx/nvptx-c.cc
index 02f75625064..f060a8ab1d4 100644
--- a/gcc/config/nvptx/nvptx-c.cc
+++ b/gcc/config/nvptx/nvptx-c.cc
@@ -49,5 +49,14 @@ nvptx_cpu_cpp_builtins (void)
 #include "nvptx-sm.def"
 #undef NVPTX_SM
   cpp_define (parse_in, ptx_sm);
+
+  {
+unsigned major
+  = ptx_version_to_number ((ptx_version)ptx_version_option, true);
+unsigned minor
+  = ptx_version_to_number ((ptx_version)ptx_version_option, false);
+cpp_define_formatted (parse_in, "__PTX_ISA_VERSION_MAJOR__=%u", major);
+cpp_define_formatted (parse_in, "__PTX_ISA_VERSION_MINOR__=%u", minor);
+  }
 }
 
diff --git a/gcc/config/nvptx/nvptx-protos.h b/gcc/config/nvptx/nvptx-protos.h
index ca0a87ee4bd..dfa08ec8319 100644
--- a/gcc/config/nvptx/nvptx-protos.h
+++ b/gcc/config/nvptx/nvptx-protos.h
@@ -44,6 +44,7 @@ extern void nvptx_cpu_cpp_builtins (void);
 extern void nvptx_register_pragmas (void);
 extern unsigned int nvptx_data_alignment (const_tree, unsigned int);
 extern void nvptx_asm_output_def_from_decls (FILE *, tree, tree);
+extern unsigned int ptx_version_to_number (enum ptx_version, bool);
 
 #ifdef RTX_CODE
 extern void nvptx_expand_oacc_fork (unsigned);
diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
index 87efc23bd96..e4297e2d6c3 100644
--- a/gcc/config/nvptx/nvptx.cc
+++ b/gcc/config/nvptx/nvptx.cc
@@ -272,6 +272,28 @@ ptx_version_to_string (enum ptx_version v)
 }
 }
 
+unsigned int
+ptx_version_to_number (enum ptx_version v, bool major_p)
+{
+  switch (v)
+{
+case PTX_VERSION_3_0:
+  return major_p ? 3 : 0;
+case PTX_VERSION_3_1:
+  return major_p ? 3 : 1;
+case PTX_VERSION_4_2:
+  return major_p ? 4 : 2;
+case PTX_VERSION_6_0:
+  return major_p ? 6 : 0;
+case PTX_VERSION_6_3:
+  return major_p ? 6 : 3;
+case PTX_VERSION_7_0:
+  return major_p ? 7 : 0;
+default:
+  gcc_unreachable ();
+}
+}
+
 static const char *
 sm_version_to_string (enum ptx_isa sm)
 {
diff --git a/gcc/testsuite/gcc.target/nvptx/ptx31.c 
b/gcc/testsuite/gcc.target/nvptx/ptx31.c
new file mode 100644
index 000..46b5e1ba405
--- /dev/null
+++ b/gcc/testsuite/gcc.target/nvptx/ptx31.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-march=sm_30 -mptx=3.1" } */
+
+#if __PTX_ISA_VERSION_MAJOR__ != 3
+#error wrong value for __PTX_ISA_VERSION_MAJOR__
+#endif
+
+#if __PTX_ISA_VERSION_MINOR__ != 1
+#error wrong value for __PTX_ISA_VERSION_MINOR__
+#endif
diff --git a/gcc/testsuite/gcc.target/nvptx/ptx60.c 
b/gcc/testsuite/gcc.target/nvptx/ptx60.c
new file mode 100644
index 000..267a9c64f1e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/nvptx/ptx60.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-march=sm_30 -mptx=6.0" } */
+
+#if __PTX_ISA_VERSION_MAJOR__ != 6
+#error wrong value for __PTX_ISA_VERSION_MAJOR__
+#endif
+
+#if __PTX_ISA_VERSION_MINOR__ != 0
+#error wrong value for __PTX_ISA_VERSION_MINOR__
+#endif
diff --git a/gcc/testsuite/gcc.target/nvptx/ptx63.c 
b/gcc/testsuite/gcc.target/nvptx/ptx63.c
new file mode 100644
index 000..13d02e132ae
--- /dev/null
+++ b/gcc/testsuite/gcc.target/nvptx/ptx63.c
@@ -0,0 +1,10 @@
+/* { 

[PATCH] postscan_insn hook not called after input_asm

[Paul Iannetta via Gcc-patches]

Hi,

While working on the Kalray port of gcc, I noticed that the hook 
TARGET_ASM_FINAL_POSTSCAN_INSN is not called after emitting an instruction 
coming from a basic asm block.  Here is a patch which fixes this behavior.

The following check:
```
$ find gcc/config/ -type f -exec grep "#define TARGET_ASM_FINAL" "{}" +
gcc/config/m68k/m68k.cc:#define TARGET_ASM_FINAL_POSTSCAN_INSN 
m68k_asm_final_postscan_insn
gcc/config/avr/avr.cc:#define TARGET_ASM_FINAL_POSTSCAN_INSN 
avr_asm_final_postscan_insn
gcc/config/mips/mips.cc:#define TARGET_ASM_FINAL_POSTSCAN_INSN 
mips_final_postscan_insn
```
reveals that m68k, avr and mips are the only affected targets upstream.

Paul Iannetta 
Kalray




0001-postscan_insn-hook-not-called-after-input_asm.patch
Description: application/mbox

[PATCH] libgcc, riscv: Add restore libcalls to be used by tail calling functions

[Lewis Revill]

Currently the existing libcalls for restoring registers have the
requirement that they must be tail called by the parent function, so
that they can safely return through the restored return address
register. This does impose the restriction that the libcalls cannot be
used if there already exists a tail call at the end of the parent
function in question, and as such this patch forms part of an effort to
rectify this situation.

There already exists patches to LLVM and Compiler-RT to add the libcalls
and the capability for the compiler to generate them
(https://reviews.llvm.org/D91720 and https://reviews.llvm.org/D91719),
and the behaviour that we want to standardize across the compilers is
documented in the following pull request to the RISC-V toolchain
conventions repository:
https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/10

The libcalls added in this patch follow that documented behaviour and
are based off a suggested implementation provided by Jim Wilson in the
thread of that pull request. Similar to the existing restore libcalls,
restores are grouped according to the expected stack alignment, and the
'upper' libcalls fall through to the lower libcalls, finally ending in
return through the temporary register t1.

libgcc/

* config/riscv/restore-tail.S: Add restore libcalls compatible
with use from functions ending in tail calls.
* config/riscv/t-elf: Add file restore-tail.S.
---
 libgcc/config/riscv/restore-tail.S | 279 +
 libgcc/config/riscv/t-elf  |   1 +
 2 files changed, 280 insertions(+)
 create mode 100644 libgcc/config/riscv/restore-tail.S

diff --git a/libgcc/config/riscv/restore-tail.S
b/libgcc/config/riscv/restore-tail.S
new file mode 100644
index 000..54116beff17
--- /dev/null
+++ b/libgcc/config/riscv/restore-tail.S
@@ -0,0 +1,279 @@
+/* Tail-call compatible callee-saved register restore routines for RISC-V.
+
+   Copyright (C) 2022 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+#include "riscv-asm.h"
+
+  .text
+
+#if __riscv_xlen == 64
+
+FUNC_BEGIN (__riscv_restore_tailcall_12)
+  .cfi_startproc
+  .cfi_def_cfa_offset 112
+  .cfi_offset 27, -104
+  .cfi_offset 26, -96
+  .cfi_offset 25, -88
+  .cfi_offset 24, -80
+  .cfi_offset 23, -72
+  .cfi_offset 22, -64
+  .cfi_offset 21, -56
+  .cfi_offset 20, -48
+  .cfi_offset 19, -40
+  .cfi_offset 18, -32
+  .cfi_offset 9, -24
+  .cfi_offset 8, -16
+  .cfi_offset 1, -8
+  ld s11, 8(sp)
+  .cfi_restore 27
+  addi sp, sp, 16
+
+FUNC_BEGIN (__riscv_restore_tailcall_11)
+FUNC_BEGIN (__riscv_restore_tailcall_10)
+  .cfi_restore 27
+  .cfi_def_cfa_offset 96
+  ld s10, 0(sp)
+  .cfi_restore 26
+  ld s9, 8(sp)
+  .cfi_restore 25
+  addi sp, sp, 16
+
+FUNC_BEGIN (__riscv_restore_tailcall_9)
+FUNC_BEGIN (__riscv_restore_tailcall_8)
+  .cfi_restore 25
+  .cfi_restore 26
+  .cfi_restore 27
+  .cfi_def_cfa_offset 80
+  ld s8, 0(sp)
+  .cfi_restore 24
+  ld s7, 8(sp)
+  .cfi_restore 23
+  addi sp, sp, 16
+
+FUNC_BEGIN (__riscv_restore_tailcall_7)
+FUNC_BEGIN (__riscv_restore_tailcall_6)
+  .cfi_restore 23
+  .cfi_restore 24
+  .cfi_restore 25
+  .cfi_restore 26
+  .cfi_restore 27
+  .cfi_def_cfa_offset 64
+  ld s6, 0(sp)
+  .cfi_restore 22
+  ld s5, 8(sp)
+  .cfi_restore 21
+  addi sp, sp, 16
+
+FUNC_BEGIN (__riscv_restore_tailcall_5)
+FUNC_BEGIN (__riscv_restore_tailcall_4)
+  .cfi_restore 21
+  .cfi_restore 22
+  .cfi_restore 23
+  .cfi_restore 24
+  .cfi_restore 25
+  .cfi_restore 26
+  .cfi_restore 27
+  .cfi_def_cfa_offset 48
+  ld s4, 0(sp)
+  .cfi_restore 20
+  ld s3, 8(sp)
+  .cfi_restore 19
+  addi sp, sp, 16
+
+FUNC_BEGIN (__riscv_restore_tailcall_3)
+FUNC_BEGIN (__riscv_restore_tailcall_2)
+  .cfi_restore 19
+  .cfi_restore 20
+  .cfi_restore 21
+  .cfi_restore 22
+  .cfi_restore 23
+  .cfi_restore 24
+  .cfi_restore 25
+  .cfi_restore 26
+  .cfi_restore 27
+  .cfi_def_cfa_offset 32
+  ld s2, 0(sp)
+  .cfi_restore 18
+  ld s1, 8(sp)
+  .cfi_restore 9
+  addi sp, sp, 16
+
+FUNC_BEGIN (__riscv_restore_tailcall_1)
+FUNC_BEGIN (__riscv_restore_tailcall_0)
+  .cfi_restore 9
+  .cfi_restore 18
+  

Re: [PATCH, OpenMP 5.0] More implementation of the requires directive

[Andrew Stubbs]

On 13/01/2021 15:07, Chung-Lin Tang wrote:
We currently emit errors, but do not fatally cause exit of the program 
if those
are not met. We're still unsure if complete block-out of program 
execution is the right

thing for the user. This can be discussed later.


After the Unified Shared Memory patches are committed, this patch will 
need to be altered as attached.


I'll commit my patch to OG11 shortly.

Andrewlibgomp, nvptx: report USM supported

libgomp/ChangeLog:

* plugin/plugin-nvptx.c (GOMP_OFFLOAD_supported_features): Allow
GOMP_REQUIRES_UNIFIED_ADDRESS and GOMP_REQUIRES_UNIFIED_SHARED_MEMORY.

diff --git a/libgomp/plugin/plugin-nvptx.c b/libgomp/plugin/plugin-nvptx.c
index dd490b2ae2a..e77c6a87930 100644
--- a/libgomp/plugin/plugin-nvptx.c
+++ b/libgomp/plugin/plugin-nvptx.c
@@ -1260,11 +1260,14 @@ GOMP_OFFLOAD_fini_device (int n)
   return true;
 }
 
-/* Indicate which GOMP_REQUIRES_* features are supported, currently none.  */
+/* Indicate which GOMP_REQUIRES_* features are supported.  */
 
 bool
 GOMP_OFFLOAD_supported_features (unsigned int *mask)
 {
+  *mask &= ~(GOMP_REQUIRES_UNIFIED_ADDRESS
+ | GOMP_REQUIRES_UNIFIED_SHARED_MEMORY);
+
   return (*mask == 0);
 }
 

[PATCH][nvptx, doc] Update misa and mptx, add march and march-map

[Tom de Vries via Gcc-patches]

Hi,

Update nvptx documentation:
- Use meaningful terms: "PTX ISA target architecture" and "PTX ISA version".
- Remove invalid claim that "ISA strings must be lower-case".
- Add missing sm_xx entries.
- Fix default ISA.
- Add march, copying misa doc.
- Declare misa an march alias.
- Add march-map.
- Fix "for given the specified" typo.

Any comments?

Thanks,
- Tom

[nvptx, doc] Update misa and mptx, add march and march-map

gcc/ChangeLog:

2022-03-29  Tom de Vries  

* doc/invoke.texi (misa, mptx): Update.
(march, march-map): Add.

---
 gcc/doc/invoke.texi | 27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 554e04ecbf3a..eb2fe959e600 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -27540,18 +27540,31 @@ These options are defined for Nvidia PTX:
 Ignored, but preserved for backward compatibility.  Only 64-bit ABI is
 supported.
 
-@item -misa=@var{ISA-string}
+@item -march=@var{architecture-string}
 @opindex march
-Generate code for given the specified PTX ISA (e.g.@: @samp{sm_35}).  ISA
-strings must be lower-case.  Valid ISA strings include @samp{sm_30} and
-@samp{sm_35}.  The default ISA is sm_35.
+Generate code for the specified PTX ISA target architecture
+(e.g.@: @samp{sm_35}).  Valid architecture strings are @samp{sm_30},
+@samp{sm_35}, @samp{sm_53} @samp{sm_70}, @samp{sm_75} and
+@samp{sm_80}.  The default target architecture is sm_30.
+
+@item -misa=@var{architecture-string}
+@opindex misa
+Alias of @option{-march=}.
+
+@item -march-map=@var{architecture-string}
+@opindex march
+Select the closest available @option{-march=} value that is not more
+capable.  For instance, for @option{-march-map=sm_50} select
+@option{-march=sm_35}, and for @option{-march-map=sm_53} select
+@option{-march=sm_53}.
 
 @item -mptx=@var{version-string}
 @opindex mptx
-Generate code for given the specified PTX version (e.g.@: @samp{7.0}).
+Generate code for the specified PTX ISA version (e.g.@: @samp{7.0}).
 Valid version strings include @samp{3.1}, @samp{6.0}, @samp{6.3}, and
-@samp{7.0}.  The default PTX version is 6.0, unless a higher minimal
-version is required for specified PTX ISA via option @option{-misa=}.
+@samp{7.0}.  The default PTX version is 6.0, unless a higher version
+is required for specified PTX ISA target architecture via option
+@option{-march=}.
 
 @item -mmainkernel
 @opindex mmainkernel

Re: [PATCH] testsuite: Allow setting gpp_std_list in configuration files

[Jason Merrill via Gcc-patches]

On 3/29/22 08:43, Jonathan Wakely wrote:

Tested powerpc64le-linux, OK for trunk?


OK.


-- >8 --

This allows the gpp_std_list variable to be set in ~/.dejagnurc instead
of using the GXX_TESTSUITE_STDS environment variable.  This is
consistent with how other defaults such as tool_timeout can be set.

The environment variable can still be used to override the default.

gcc/testsuite/ChangeLog:

* lib/g++-dg.exp: Update comments.
* lib/g++.exp (gpp_std_list): Check for an existing value before
setting it to an empty list.
---
  gcc/testsuite/lib/g++-dg.exp | 7 ---
  gcc/testsuite/lib/g++.exp| 6 +-
  2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/lib/g++-dg.exp b/gcc/testsuite/lib/g++-dg.exp
index a1bc37074b5..59e8081a29d 100644
--- a/gcc/testsuite/lib/g++-dg.exp
+++ b/gcc/testsuite/lib/g++-dg.exp
@@ -27,8 +27,8 @@ proc g++-dg-prune { system text } {
  return [gcc-dg-prune $system $text]
  }
  
-# Modified dg-runtest that runs tests in both C++98 and C++11 modes

-# unless they specifically specify one or the other.
+# Modified dg-runtest that runs tests in multiple standard modes,
+# unless they specifically specify one standard.
  proc g++-dg-runtest { testcases flags default-extra-flags } {
  global runtests
  
@@ -39,7 +39,7 @@ proc g++-dg-runtest { testcases flags default-extra-flags } {

}
  
  	# If the testcase specifies a standard, use that one.

-   # If not, run it under both standards, allowing GNU extensions
+   # If not, run it under several standards, allowing GNU extensions
# if there's a dg-options line.
if ![search_for $test "-std=*++"] {
if [search_for $test "dg-options"] {
@@ -48,6 +48,7 @@ proc g++-dg-runtest { testcases flags default-extra-flags } {
set std_prefix "-std=c++"
}
  
+	# See g++.exp for the initial value of this list.

global gpp_std_list
if { [llength $gpp_std_list] > 0 } {
set std_list $gpp_std_list
diff --git a/gcc/testsuite/lib/g++.exp b/gcc/testsuite/lib/g++.exp
index 3744ebe4b44..24ef068b239 100644
--- a/gcc/testsuite/lib/g++.exp
+++ b/gcc/testsuite/lib/g++.exp
@@ -32,7 +32,11 @@ load_lib target-libpath.exp
  
  
  set gpp_compile_options ""

-set gpp_std_list { }
+# Allow gpp_std_list to be set in configuration files, e.g., ~/.dejagnurc
+if ![info exists gpp_std_list] {
+set gpp_std_list { }
+}
+# Allow gpp_std_list to be set from the environment.
  if [info exists env(GXX_TESTSUITE_STDS)] {
  set gpp_std_list [split $env(GXX_TESTSUITE_STDS) ","]
  }

[PATCH] testsuite: Allow setting gpp_std_list in configuration files

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, OK for trunk?

-- >8 --

This allows the gpp_std_list variable to be set in ~/.dejagnurc instead
of using the GXX_TESTSUITE_STDS environment variable.  This is
consistent with how other defaults such as tool_timeout can be set.

The environment variable can still be used to override the default.

gcc/testsuite/ChangeLog:

* lib/g++-dg.exp: Update comments.
* lib/g++.exp (gpp_std_list): Check for an existing value before
setting it to an empty list.
---
 gcc/testsuite/lib/g++-dg.exp | 7 ---
 gcc/testsuite/lib/g++.exp| 6 +-
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/lib/g++-dg.exp b/gcc/testsuite/lib/g++-dg.exp
index a1bc37074b5..59e8081a29d 100644
--- a/gcc/testsuite/lib/g++-dg.exp
+++ b/gcc/testsuite/lib/g++-dg.exp
@@ -27,8 +27,8 @@ proc g++-dg-prune { system text } {
 return [gcc-dg-prune $system $text]
 }
 
-# Modified dg-runtest that runs tests in both C++98 and C++11 modes
-# unless they specifically specify one or the other.
+# Modified dg-runtest that runs tests in multiple standard modes,
+# unless they specifically specify one standard.
 proc g++-dg-runtest { testcases flags default-extra-flags } {
 global runtests
 
@@ -39,7 +39,7 @@ proc g++-dg-runtest { testcases flags default-extra-flags } {
}
 
# If the testcase specifies a standard, use that one.
-   # If not, run it under both standards, allowing GNU extensions
+   # If not, run it under several standards, allowing GNU extensions
# if there's a dg-options line.
if ![search_for $test "-std=*++"] {
if [search_for $test "dg-options"] {
@@ -48,6 +48,7 @@ proc g++-dg-runtest { testcases flags default-extra-flags } {
set std_prefix "-std=c++"
}
 
+   # See g++.exp for the initial value of this list.
global gpp_std_list
if { [llength $gpp_std_list] > 0 } {
set std_list $gpp_std_list
diff --git a/gcc/testsuite/lib/g++.exp b/gcc/testsuite/lib/g++.exp
index 3744ebe4b44..24ef068b239 100644
--- a/gcc/testsuite/lib/g++.exp
+++ b/gcc/testsuite/lib/g++.exp
@@ -32,7 +32,11 @@ load_lib target-libpath.exp
 
 
 set gpp_compile_options ""
-set gpp_std_list { }
+# Allow gpp_std_list to be set in configuration files, e.g., ~/.dejagnurc
+if ![info exists gpp_std_list] {
+set gpp_std_list { }
+}
+# Allow gpp_std_list to be set from the environment.
 if [info exists env(GXX_TESTSUITE_STDS)] {
 set gpp_std_list [split $env(GXX_TESTSUITE_STDS) ","]
 }
-- 
2.34.1

[committed][nvptx] Update help text for m64

[Tom de Vries via Gcc-patches]

Hi,

In the docs we have for m64:
...
Ignored, but preserved for backward compatibility.  Only 64-bit ABI is
supported.
...

But with --target-help, we have instead:
...
$ gcc --target-help
  ...
  -m64Generate code for a 64-bit ABI.
...
which could be interpreted as meaning that generating code for a 32-bit ABI is
still possible.

Fix this by instead emitting the same text as in the docs:
...
  -m64Ignored, but preserved for backward compatibility.  Only 64-bit
  ABI is supported.
...

Tested on nvptx.

Committed to trunk.

Thanks,
- Tom

[nvptx] Update help text for m64

gcc/ChangeLog:

2022-03-29  Tom de Vries  

* config/nvptx/nvptx.opt (m64): Update help text to reflect that it
is ignored.

---
 gcc/config/nvptx/nvptx.opt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/nvptx/nvptx.opt b/gcc/config/nvptx/nvptx.opt
index 58eddeeabf4..55a10572dd1 100644
--- a/gcc/config/nvptx/nvptx.opt
+++ b/gcc/config/nvptx/nvptx.opt
@@ -25,7 +25,8 @@
 
 m64
 Target RejectNegative Mask(ABI64)
-Generate code for a 64-bit ABI.
+Ignored, but preserved for backward compatibility.  Only 64-bit ABI is
+supported.
 
 mmainkernel
 Target RejectNegative

[committed][nvptx] Add march-map

[Tom de Vries via Gcc-patches]

Hi,

Say we have an sm_50 board, and we want to run a benchmark using the highest
possible march setting.

Currently there's march=sm_30, march=sm_35, march=sm_53, but no march=sm_50.

So, we'd need to pick march=sm_35.

Likewise, for a test script that handles multiple boards, we'd need a mapping
from native board sm_xx to march, which might have to be updated with newer
gcc releases.

Add an option march-map, such that we can just specify march-map=sm_50, and
let the compiler map this to the appropriate march.

The option is implemented as a list of aliases, such that we have a somewhat
lengthy (17 lines in total):
...
$ gcc --help=target
  ...
  -march-map=sm_30Same as -misa=sm_30.
  -march-map=sm_32Same as -misa=sm_30.
  ...
  -march-map=sm_87Same as -misa=sm_80.
  -march-map=sm_90Same as -misa=sm_80.
...

This implementation was chosen in the hope that it'll be easier if
we end up with some misa multilib.

It would be nice to have the mapping list generated from an updated
nvptx-sm.def, but for now it's spelled out in nvptx.opt.

Tested on nvptx.

Committed to trunk.

Thanks,
- Tom

[nvptx] Add march-map

gcc/ChangeLog:

2022-03-29  Tom de Vries  

PR target/104714
* config/nvptx/nvptx.opt (march-map=*): Add aliases.

gcc/testsuite/ChangeLog:

2022-03-29  Tom de Vries  

PR target/104714
* gcc.target/nvptx/march-map.c: New test.

---
 gcc/config/nvptx/nvptx.opt | 51 ++
 gcc/testsuite/gcc.target/nvptx/march-map.c |  5 +++
 2 files changed, 56 insertions(+)

diff --git a/gcc/config/nvptx/nvptx.opt b/gcc/config/nvptx/nvptx.opt
index b5d0170e9e9..58eddeeabf4 100644
--- a/gcc/config/nvptx/nvptx.opt
+++ b/gcc/config/nvptx/nvptx.opt
@@ -60,6 +60,57 @@ march=
 Target RejectNegative Joined Alias(misa=)
 Alias:
 
+march-map=sm_30
+Target RejectNegative Alias(misa=,sm_30)
+
+march-map=sm_32
+Target RejectNegative Alias(misa=,sm_30)
+
+march-map=sm_35
+Target RejectNegative Alias(misa=,sm_35)
+
+march-map=sm_37
+Target RejectNegative Alias(misa=,sm_35)
+
+march-map=sm_50
+Target RejectNegative Alias(misa=,sm_35)
+
+march-map=sm_52
+Target RejectNegative Alias(misa=,sm_35)
+
+march-map=sm_53
+Target RejectNegative Alias(misa=,sm_53)
+
+march-map=sm_60
+Target RejectNegative Alias(misa=,sm_53)
+
+march-map=sm_61
+Target RejectNegative Alias(misa=,sm_53)
+
+march-map=sm_62
+Target RejectNegative Alias(misa=,sm_53)
+
+march-map=sm_70
+Target RejectNegative Alias(misa=,sm_70)
+
+march-map=sm_72
+Target RejectNegative Alias(misa=,sm_70)
+
+march-map=sm_75
+Target RejectNegative Alias(misa=,sm_75)
+
+march-map=sm_80
+Target RejectNegative Alias(misa=,sm_80)
+
+march-map=sm_86
+Target RejectNegative Alias(misa=,sm_80)
+
+march-map=sm_87
+Target RejectNegative Alias(misa=,sm_80)
+
+march-map=sm_90
+Target RejectNegative Alias(misa=,sm_80)
+
 Enum
 Name(ptx_version) Type(int)
 Known PTX ISA versions (for use with the -mptx= option):
diff --git a/gcc/testsuite/gcc.target/nvptx/march-map.c 
b/gcc/testsuite/gcc.target/nvptx/march-map.c
new file mode 100644
index 000..00838e55fc0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/nvptx/march-map.c
@@ -0,0 +1,5 @@
+/* { dg-options "-march-map=sm_50" } */
+
+#include "main.c"
+
+/* { dg-final { scan-assembler-times "\\.target\tsm_35" 1 } } */

Re: options, '-Wc++[...]-extensions': Remove undefined one-argument 'LangEnabledBy' option properties (was: [PATCH] c++: Add new warning options for C++ language mismatches)

[Jonathan Wakely via Gcc-patches]

On Tue, 29 Mar 2022 at 10:28, Thomas Schwinge wrote:
>
> Hi!
>
> On 2021-05-19T13:09:29-0400, Marek Polacek via Gcc-patches 
>  wrote:
> > On Wed, May 19, 2021 at 05:59:34PM +0100, Jonathan Wakely wrote:
> >> On 19/05/21 12:53 -0400, Marek Polacek wrote:
> >> > On Wed, May 19, 2021 at 05:39:24PM +0100, Jonathan Wakely via 
> >> > Gcc-patches wrote:
> >> > > --- a/gcc/c-family/c.opt
> >> > > +++ b/gcc/c-family/c.opt
>
> >> > > +Wc++11-extensions
> >> > > +C++ ObjC++ Var(warn_cxx11_extensions) Warning LangEnabledBy(C++ 
> >> > > ObjC++,Wall) Init(1)
> >> > > +Warn about C++11 constructs in code compiled with an older standard.
> >> > > +
> >> > > +[Etc.]
>
> >> > So these are enabled by -Wall but also turned on by default?  Let's 
> >> > choose one
> >> > and then drop either the Init(1) or the LangEnabledBy(C++ ObjC++,Wall) 
> >> > part?
> >>
> >> Ah, good point. I mostly just cargo-cult what I see in that file (is
> >> the format documented somewhere?)
> >
> > doc/options.texi I think.
>
> Correct.
>
> >> I think to preserve the current behaviour (using these constructs in
> >> an unsupported dialect warns by default) we want them to be Init(1)
> >> but not in -Wall. [...]
>
> What you pushed in commit ee336ecb2a7161bc28f6c5343d97870a8d15e177
> "c++: Add new warning options for C++ language mismatches" then had the
> new options defined as follows; specifying 'LangEnabledBy(C++ ObjC++)'
> instead of originally-posted 'LangEnabledBy(C++ ObjC++,Wall)':
>
> | --- gcc/c-family/c.opt
> | +++ gcc/c-family/c.opt
> | [...]
> | +Wc++11-extensions
> | +C++ ObjC++ Var(warn_cxx11_extensions) Warning LangEnabledBy(C++ ObjC++) 
> Init(1)
> | +Warn about C++11 constructs in code compiled with an older standard.
> | +
> | +[Etc.]
>
> OK to push the attached "options, '-Wc++[...]-extensions':
> Remove undefined one-argument 'LangEnabledBy' option properties"?

I can't approve it, but no objections from me.

[committed][nvptx] Add march alias for misa

[Tom de Vries via Gcc-patches]

Hi,

The target option misa has the following description:
...
$ gcc --target-help 2>&1 | grep misa
  -misa=  Specify the PTX ISA target architecture to use.
...

The name misa is somewhat poorly chosen.  It suggests that for a use
-misa=sm_30, sm_30 is the name of a specific Instruction Set Architecture.
Instead, sm_30 is the name of a specific target architecture in the generic
PTX Instruction Set Architecture.

Futhermore, there's mptx, which also has ISA in the description:
...
  -mptx=  Specify the PTX ISA version to use.
...

Add the more intuitive alias march for misa:
...
$ gcc --target-help 2>&1 | grep march
  -march= Alias:  Same as -misa=.
...

Tested on nvptx.

Committed to trunk.

Thanks,
- Tom

[nvptx] Add march alias for misa

gcc/ChangeLog:

2022-03-29  Tom de Vries  

* config/nvptx/nvptx.opt (march): Add alias of misa.

gcc/testsuite/ChangeLog:

2022-03-29  Tom de Vries  

* gcc.target/nvptx/main.c: New test.
* gcc.target/nvptx/march.c: New test.

---
 gcc/config/nvptx/nvptx.opt | 4 
 gcc/testsuite/gcc.target/nvptx/main.c  | 7 +++
 gcc/testsuite/gcc.target/nvptx/march.c | 5 +
 3 files changed, 16 insertions(+)

diff --git a/gcc/config/nvptx/nvptx.opt b/gcc/config/nvptx/nvptx.opt
index 1f684ed8860..b5d0170e9e9 100644
--- a/gcc/config/nvptx/nvptx.opt
+++ b/gcc/config/nvptx/nvptx.opt
@@ -56,6 +56,10 @@ misa=
 Target RejectNegative ToLower Joined Enum(ptx_isa) Var(ptx_isa_option) 
Init(PTX_ISA_SM30)
 Specify the PTX ISA target architecture to use.
 
+march=
+Target RejectNegative Joined Alias(misa=)
+Alias:
+
 Enum
 Name(ptx_version) Type(int)
 Known PTX ISA versions (for use with the -mptx= option):
diff --git a/gcc/testsuite/gcc.target/nvptx/main.c 
b/gcc/testsuite/gcc.target/nvptx/main.c
new file mode 100644
index 000..3af2b575842
--- /dev/null
+++ b/gcc/testsuite/gcc.target/nvptx/main.c
@@ -0,0 +1,7 @@
+/* { dg-do link } */
+
+int
+main (void)
+{
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.target/nvptx/march.c 
b/gcc/testsuite/gcc.target/nvptx/march.c
new file mode 100644
index 000..ec91f21c903
--- /dev/null
+++ b/gcc/testsuite/gcc.target/nvptx/march.c
@@ -0,0 +1,5 @@
+/* { dg-options "-march=sm_30"} */
+
+#include "main.c"
+
+/* { dg-final { scan-assembler-times "\\.target\tsm_30" 1 } } */

options: Improve 'LangEnabledBy' option property diagnostics (was: r193303 - in /trunk/gcc: ChangeLog opt-function...)

[Thomas Schwinge]

Hi!

Once the three 'LangEnabledBy' option property patches that I've just
posted are accepted, we may proceed here:

On 2012-11-07T18:11:02+, m...@gcc.gnu.org wrote:
> Author: manu
> Date: Wed Nov  7 18:11:01 2012
> New Revision: 193303
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=193303
> Log:
> 2012-11-07  Manuel López-Ibáñez  
>
>   * optc-gen.awk: Factor code out to...
>   * opt-functions.awk (lang_enabled_by): ... this new function.
>
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/opt-functions.awk
> trunk/gcc/optc-gen.awk

I'm generally very much in favor of abstracting functionality into
separate functions.  Here, however, there ever existed only one user of
'gcc/opt-functions.awk:lang_enabled_by', its interface is a bit clumsy,
leading to (slightly) confusing diagnostics, and all handling for other
related option properties remains in the original place, so I find that
in fact confusing to be split out, and scattered over two files.  I thus
propose to merge 'gcc/opt-functions.awk:lang_enabled_by' back into its
original place, and then improve diagnostics.  OK to push the attached
"options: Improve 'LangEnabledBy' option property diagnostics"?  In
addition to standard testing, I've manually verified the error cases.


Grüße
 Thomas


-
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
>From 08eb8eca7673d2ce13ad22fd7e8823f5864e740e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 28 Mar 2022 10:55:49 +0200
Subject: [PATCH] options: Improve 'LangEnabledBy' option property diagnostics

No changes in generated files.

	gcc/
	* opt-functions.awk (n_args): New function.
	(lang_enabled_by): Merge function into...
	* optc-gen.awk : ... sole user here.
	Improve diagnostics.
---
 gcc/opt-functions.awk | 47 +---
 gcc/optc-gen.awk  | 56 +++
 2 files changed, 62 insertions(+), 41 deletions(-)

diff --git a/gcc/opt-functions.awk b/gcc/opt-functions.awk
index 9eccf9b0409..2aee0b9f1c3 100644
--- a/gcc/opt-functions.awk
+++ b/gcc/opt-functions.awk
@@ -82,6 +82,17 @@ function opt_args_non_empty(name, flags, description)
 	return args
 }
 
+# Return the number of comma-separated element of S.
+function n_args(s)
+{
+	n = 1
+	while (s ~ ",") {
+		n++
+		sub("[^,]*, *", "", s)
+	}
+	return n
+}
+
 # Return the Nth comma-separated element of S.  Return the empty string
 # if S does not contain N elements.
 function nth_arg(n, s)
@@ -376,39 +387,3 @@ function integer_range_info(range_option, init, option, uinteger_used)
 else
 return "-1, -1"
 }
-
-# Handle LangEnabledBy(ENABLED_BY_LANGS, ENABLEDBY_NAME, ENABLEDBY_POSARG,
-# ENABLEDBY_NEGARG). This function does not return anything.
-function lang_enabled_by(enabledby_langs, enabledby_name, enabledby_posarg, enabledby_negarg)
-{
-n_enabledby_arg_langs = split(enabledby_langs, enabledby_arg_langs, " ");
-if (enabledby_posarg != "" && enabledby_negarg != "") {
-with_args = "," enabledby_posarg "," enabledby_negarg
-} else if (enabledby_posarg == "" && enabledby_negarg == "") {
-with_args = ""
-} else {
-print "#error " opts[i] " LangEnabledBy("enabledby_langs","enabledby_name", " \
-enabledby_posarg", " enabledby_negarg \
-") with three arguments, it should have either 2 or 4"
-}
-
-n_enabledby_array = split(enabledby_name, enabledby_array, " \\|\\| ");
-for (k = 1; k <= n_enabledby_array; k++) {
-enabledby_index = opt_numbers[enabledby_array[k]];
-if (enabledby_index == "") {
- print "#error " opts[i] " LangEnabledBy("enabledby_langs","enabledby_name", " \
- enabledby_posarg", " enabledby_negarg"), unknown option '" enabledby_name "'"
-} else {
-for (j = 1; j <= n_enabledby_arg_langs; j++) {
- lang_name = lang_sanitized_name(enabledby_arg_langs[j]);
- lang_index = lang_numbers[enabledby_arg_langs[j]];
- if (enables[lang_name,enabledby_array[k]] == "") {
- enabledby[lang_name,n_enabledby_lang[lang_index]] = enabledby_array[k];
- n_enabledby_lang[lang_index]++;
- }
- enables[lang_name,enabledby_array[k]] \
- = enables[lang_name,enabledby_array[k]] opts[i] with_args ";";
-}
-}
-}
-}
diff --git a/gcc/optc-gen.awk b/gcc/optc-gen.awk
index 5f7946cf49b..f2198b253ad 100644
--- a/gcc/optc-gen.awk
+++ b/gcc/optc-gen.awk
@@ -98,11 +98,57 @@ for (i = 0; i < n_opts; i++) {
 
 enabledby_arg = opt_args("LangEnabledBy", flags[i]);
 if (enabledby_arg != "") {
-enabledby_langs = nth_arg(0, enabledby_arg);
-enabledby_name = nth_arg(1, 

options, '-Wc++[...]-extensions': Remove undefined one-argument 'LangEnabledBy' option properties (was: [PATCH] c++: Add new warning options for C++ language mismatches)

[Thomas Schwinge]

Hi!

On 2021-05-19T13:09:29-0400, Marek Polacek via Gcc-patches 
 wrote:
> On Wed, May 19, 2021 at 05:59:34PM +0100, Jonathan Wakely wrote:
>> On 19/05/21 12:53 -0400, Marek Polacek wrote:
>> > On Wed, May 19, 2021 at 05:39:24PM +0100, Jonathan Wakely via Gcc-patches 
>> > wrote:
>> > > --- a/gcc/c-family/c.opt
>> > > +++ b/gcc/c-family/c.opt

>> > > +Wc++11-extensions
>> > > +C++ ObjC++ Var(warn_cxx11_extensions) Warning LangEnabledBy(C++ 
>> > > ObjC++,Wall) Init(1)
>> > > +Warn about C++11 constructs in code compiled with an older standard.
>> > > +
>> > > +[Etc.]

>> > So these are enabled by -Wall but also turned on by default?  Let's choose 
>> > one
>> > and then drop either the Init(1) or the LangEnabledBy(C++ ObjC++,Wall) 
>> > part?
>>
>> Ah, good point. I mostly just cargo-cult what I see in that file (is
>> the format documented somewhere?)
>
> doc/options.texi I think.

Correct.

>> I think to preserve the current behaviour (using these constructs in
>> an unsupported dialect warns by default) we want them to be Init(1)
>> but not in -Wall. [...]

What you pushed in commit ee336ecb2a7161bc28f6c5343d97870a8d15e177
"c++: Add new warning options for C++ language mismatches" then had the
new options defined as follows; specifying 'LangEnabledBy(C++ ObjC++)'
instead of originally-posted 'LangEnabledBy(C++ ObjC++,Wall)':

| --- gcc/c-family/c.opt
| +++ gcc/c-family/c.opt
| [...]
| +Wc++11-extensions
| +C++ ObjC++ Var(warn_cxx11_extensions) Warning LangEnabledBy(C++ ObjC++) 
Init(1)
| +Warn about C++11 constructs in code compiled with an older standard.
| +
| +[Etc.]

OK to push the attached "options, '-Wc++[...]-extensions':
Remove undefined one-argument 'LangEnabledBy' option properties"?


Grüße
 Thomas


-
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
>From 78ee403f982526e0c026719c450dc5aead84accf Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sat, 26 Mar 2022 22:21:14 +0100
Subject: [PATCH] options, '-Wc++[...]-extensions': Remove undefined
 one-argument 'LangEnabledBy' option properties

A one-argument form of the 'LangEnabledBy' option property isn't defined,
and effectively appears to be a no-op.  Removing these only changes
'build-gcc/gcc/optionlist' accordingly, but no other generated files.

Clean-up for commit ee336ecb2a7161bc28f6c5343d97870a8d15e177
"c++: Add new warning options for C++ language mismatches".

	gcc/c-family/
	* c.opt (Wc++11-extensions, Wc++14-extensions, Wc++17-extensions)
	(Wc++20-extensions, Wc++23-extensions): Remove 'LangEnabledBy'
	option properties.
---
 gcc/c-family/c.opt | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 1034a1b3946..07da40ef43b 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -459,23 +459,23 @@ C++ ObjC++ Var(warn_cxx20_compat) Warning LangEnabledBy(C++ ObjC++,Wall)
 Warn about C++ constructs whose meaning differs between ISO C++ 2017 and ISO C++ 2020.
 
 Wc++11-extensions
-C++ ObjC++ Var(warn_cxx11_extensions) Warning LangEnabledBy(C++ ObjC++) Init(1)
+C++ ObjC++ Var(warn_cxx11_extensions) Warning Init(1)
 Warn about C++11 constructs in code compiled with an older standard.
 
 Wc++14-extensions
-C++ ObjC++ Var(warn_cxx14_extensions) Warning LangEnabledBy(C++ ObjC++) Init(1)
+C++ ObjC++ Var(warn_cxx14_extensions) Warning Init(1)
 Warn about C++14 constructs in code compiled with an older standard.
 
 Wc++17-extensions
-C++ ObjC++ Var(warn_cxx17_extensions) Warning LangEnabledBy(C++ ObjC++) Init(1)
+C++ ObjC++ Var(warn_cxx17_extensions) Warning Init(1)
 Warn about C++17 constructs in code compiled with an older standard.
 
 Wc++20-extensions
-C++ ObjC++ Var(warn_cxx20_extensions) Warning LangEnabledBy(C++ ObjC++) Init(1)
+C++ ObjC++ Var(warn_cxx20_extensions) Warning Init(1)
 Warn about C++20 constructs in code compiled with an older standard.
 
 Wc++23-extensions
-C++ ObjC++ Var(warn_cxx23_extensions) Warning LangEnabledBy(C++ ObjC++) Init(1)
+C++ ObjC++ Var(warn_cxx23_extensions) Warning Init(1)
 Warn about C++23 constructs in code compiled with an older standard.
 
 Wcast-function-type
-- 
2.25.1

options: Remove 'gcc/c-family/c.opt:Wuse-after-free' option definition record (was: [PATCH v2 1/2] add -Wuse-after-free)

[Thomas Schwinge]

Hi!

On 2022-01-15T17:00:11-0700, Martin Sebor via Gcc-patches 
 wrote:
> On 1/11/22 15:40, Jason Merrill wrote:
>> On 11/30/21 17:32, Martin Sebor via Gcc-patches wrote:
>>> [default setting of the option]

>> Let's put =2 in -Wall for now.

> I've adjusted [...] and pushed r12-6605 [...]

That's from commit 671a283636de75f7ed638ee6b01ed2d44361b8b6
"Add -Wuse-after-free [PR80532]":

| --- gcc/common.opt
| +++ gcc/common.opt
| [...]
| +Wuse-after-free
| +Common Var(warn_use_after_free) Warning
| +Warn for uses of pointers to deallocated strorage.
| +
| +Wuse-after-free=
| +Common Joined RejectNegative UInteger Var(warn_use_after_free) Warning 
IntegerRange(0, 3)
| +Warn for uses of pointers to deallocated strorage.
| [...]

| --- gcc/c-family/c.opt
| +++ gcc/c-family/c.opt
| [...]
| +# Defining these options here in addition to common.opt is necessary
| +# in order for the default -Wall setting of -Wuse-after-free=2 to take
| +# effect.
| +
| +Wuse-after-free
| +LangEnabledBy(C ObjC C++ LTO ObjC++)
| +; in common.opt
| +
| +Wuse-after-free=
| +LangEnabledBy(C ObjC C++ LTO ObjC++, Wall,2,0)
| +; in common.opt
| [...]

OK to push the attached "options: Remove
'gcc/c-family/c.opt:Wuse-after-free' option definition record"?


Grüße
 Thomas


-
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
>From eda478e23a611611353d22e11727a797b9f321f9 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sat, 26 Mar 2022 22:07:54 +0100
Subject: [PATCH] options: Remove 'gcc/c-family/c.opt:Wuse-after-free' option
 definition record

A one-argument form of the 'LangEnabledBy' option property isn't defined,
and effectively appears to be a no-op.  Removing that one, the
'gcc/c-family/c.opt:Wuse-after-free' option definition record becomes
empty, and doesn't add anything over 'gcc/common.opt:Wuse-after-free', and
may thus be removed entirely.  This only changes 'build-gcc/gcc/optionlist'
accordingly, but no other generated files.

Clean-up after recent commit 671a283636de75f7ed638ee6b01ed2d44361b8b6
"Add -Wuse-after-free [PR80532]".

	gcc/c-family/
	* c.opt (Wuse-after-free): Remove.
---
 gcc/c-family/c.opt | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 3c2ec7744b0..1034a1b3946 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1373,14 +1373,10 @@ Wunused-const-variable=
 C ObjC C++ ObjC++ Joined RejectNegative UInteger Var(warn_unused_const_variable) Warning LangEnabledBy(C ObjC,Wunused-variable, 1, 0) IntegerRange(0, 2)
 Warn when a const variable is unused.
 
-; Defining these options here in addition to common.opt is necessary
+; Defining this option here in addition to common.opt is necessary
 ; in order for the default -Wall setting of -Wuse-after-free=2 to take
 ; effect.
 
-Wuse-after-free
-LangEnabledBy(C ObjC C++ LTO ObjC++)
-; in common.opt
-
 Wuse-after-free=
 LangEnabledBy(C ObjC C++ LTO ObjC++, Wall,2,0)
 ; in common.opt
-- 
2.25.1

options: Remove 'gcc/c-family/c.opt:Warray-bounds' option definition record (was: committed: remove redundant -Wall from -Warray-bounds (PR 82063))

[Thomas Schwinge]

Hi!

On 2018-07-20T15:22:23-0600, Martin Sebor  wrote:
> As the last observation in PR 82063 Jim points out that
>
>Both -Warray-bounds and -Warray-bounds= are listed in the c.opt
>file as being enabled by -Wall, but they are the same option,
>and it causes this one option to be processed twice in the
>C_handle_option_auto function in the generated options.c file.
>It gets set to the same value twice, so it does work as intended,
>but this is wasteful.
>
> I have removed the redundant -Wall from the first option and
> committed the change as obvious in r262912.

That's r262912/commit 0d7f90652080c42cddca6f9b68f6895218c70880
"PR middle-end/82063 - issues with arguments enabled by -Wall":

| --- gcc/c-family/c.opt
| +++ gcc/c-family/c.opt
| [...]
|  Warray-bounds
| -LangEnabledBy(C ObjC C++ LTO ObjC++,Wall)
| +LangEnabledBy(C ObjC C++ LTO ObjC++)
|  ; in common.opt
|
|  Warray-bounds=

OK to push the attached "options: Remove
'gcc/c-family/c.opt:Warray-bounds' option definition record"?


Grüße
 Thomas


-
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
>From 15b8d3d6265529bcab74c81b742cd4d1ef2ef37b Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Thu, 24 Mar 2022 22:17:23 +0100
Subject: [PATCH] options: Remove 'gcc/c-family/c.opt:Warray-bounds' option
 definition record

A one-argument form of the 'LangEnabledBy' option property isn't defined,
and effectively appears to be a no-op.  Removing that one, the
'gcc/c-family/c.opt:Warray-bounds' option definition record becomes empty,
and doesn't add anything over 'gcc/common.opt:Warray-bounds', and may thus
be removed entirely.  This only changes 'build-gcc/gcc/optionlist'
accordingly, but no other generated files.

Clean-up after r262912/commit 0d7f90652080c42cddca6f9b68f6895218c70880
"PR middle-end/82063 - issues with arguments enabled by -Wall".

	gcc/c-family/
	* c.opt (Warray-bounds): Remove.
---
 gcc/c-family/c.opt | 4 
 1 file changed, 4 deletions(-)

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 790d47caf0a..3c2ec7744b0 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -342,10 +342,6 @@ Wno-alloca-larger-than
 C ObjC C++ LTO ObjC++ Alias(Walloca-larger-than=,18446744073709551615EiB,none) Warning
 Disable Walloca-larger-than= warning.  Equivalent to Walloca-larger-than= or larger.
 
-Warray-bounds
-LangEnabledBy(C ObjC C++ LTO ObjC++)
-; in common.opt
-
 Warray-bounds=
 LangEnabledBy(C ObjC C++ LTO ObjC++,Wall,1,0)
 ; in common.opt
-- 
2.25.1

options: Fix 'enabledby_negargs' typo in 'LangEnabledBy' option property diagnostics (was: r193303 - in /trunk/gcc: ChangeLog opt-function...)

[Thomas Schwinge]

Hi!

On 2012-11-07T18:11:02+, m...@gcc.gnu.org wrote:
> Author: manu
> Date: Wed Nov  7 18:11:01 2012
> New Revision: 193303
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=193303
> Log:
> 2012-11-07  Manuel López-Ibáñez  
>
>   * optc-gen.awk: Factor code out to...
>   * opt-functions.awk (lang_enabled_by): ... this new function.
>
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/opt-functions.awk
> trunk/gcc/optc-gen.awk

In improving the diagnostic, this has introduced a 'enabledby_negargs'
typo:

| --- gcc/optc-gen.awk
| +++ gcc/optc-gen.awk
| [...]
| - enabledby_negarg = nth_arg(3, enabledby_arg)
| [...]
| -if (enabledby_posarg != "" && enabledby_negarg != "") {
| -with_args = "," enabledby_posarg "," enabledby_negarg
| -} else if (enabledby_posarg == "" && enabledby_negarg == "") {
| -with_args = ""
| -} else {
| -print "#error LangEnabledBy with three arguments, it should 
have either 2 or 4"
| -}
| [...]
| +lang_enabled_by(enabledby_langs, enabledby_name, enabledby_posarg, 
enabledby_negarg);
| [...]

| --- gcc/opt-functions.awk
| +++ gcc/opt-functions.awk
| [...]
| +function lang_enabled_by(enabledby_langs, enabledby_name, enabledby_posarg, 
enabledby_negarg)
| +{
| [...]
| +if (enabledby_posarg != "" && enabledby_negarg != "") {
| +with_args = "," enabledby_posarg "," enabledby_negarg
| +} else if (enabledby_posarg == "" && enabledby_negarg == "") {
| +with_args = ""
| +} else {
| +print "#error LangEnabledBy("enabledby_langs","enabledby_name", 
" \
| +enabledby_posarg", " enabledby_negargs  \
| +") with three arguments, it should have either 2 or 4"
| [...]

As obvious, pushed to master branch
commit 2788d42bdc66988449d40bf638f203a7cffc6cd9 "options: Fix
'enabledby_negargs' typo in 'LangEnabledBy' option property diagnostics",
see attached.


Grüße
 Thomas


-
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
>From 2788d42bdc66988449d40bf638f203a7cffc6cd9 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 28 Mar 2022 10:25:16 +0200
Subject: [PATCH] options: Fix 'enabledby_negargs' typo in 'LangEnabledBy'
 option property diagnostics

Originally introduced almost ten years ago in
r193303/commit 0829c7f7c5210cd1581042115cfe95c97283f44c
"optc-gen.awk: Factor code out to...".

	gcc/
	* opt-functions.awk (lang_enabled_by): Fix 'enabledby_negargs'
	typo.
---
 gcc/opt-functions.awk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/opt-functions.awk b/gcc/opt-functions.awk
index 5b0bc6634f5..9eccf9b0409 100644
--- a/gcc/opt-functions.awk
+++ b/gcc/opt-functions.awk
@@ -388,7 +388,7 @@ function lang_enabled_by(enabledby_langs, enabledby_name, enabledby_posarg, enab
 with_args = ""
 } else {
 print "#error " opts[i] " LangEnabledBy("enabledby_langs","enabledby_name", " \
-enabledby_posarg", " enabledby_negargs  \
+enabledby_posarg", " enabledby_negarg \
 ") with three arguments, it should have either 2 or 4"
 }
 
@@ -397,7 +397,7 @@ function lang_enabled_by(enabledby_langs, enabledby_name, enabledby_posarg, enab
 enabledby_index = opt_numbers[enabledby_array[k]];
 if (enabledby_index == "") {
  print "#error " opts[i] " LangEnabledBy("enabledby_langs","enabledby_name", " \
- enabledby_posarg", " enabledby_negargs"), unknown option '" enabledby_name "'"
+ enabledby_posarg", " enabledby_negarg"), unknown option '" enabledby_name "'"
 } else {
 for (j = 1; j <= n_enabledby_arg_langs; j++) {
  lang_name = lang_sanitized_name(enabledby_arg_langs[j]);
-- 
2.35.1

[committed] libstdc++: Workaround for missing 'using enum' in Clang 12

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.

-- >8 --

Once we no longer care about older compilers without this feature, we
can drop these static data members, so the names don't have to be
visible at class scope.

libstdc++-v3/ChangeLog:

* libsupc++/compare (_Strong_order) [!__cpp_using_enum]: Add
static data members for _Fp_fmt enumerators.
---
 libstdc++-v3/libsupc++/compare | 17 +
 1 file changed, 17 insertions(+)

diff --git a/libstdc++-v3/libsupc++/compare b/libstdc++-v3/libsupc++/compare
index 6e1ed53eeed..e9cf9139def 100644
--- a/libstdc++-v3/libsupc++/compare
+++ b/libstdc++-v3/libsupc++/compare
@@ -677,12 +677,25 @@ namespace std
// TODO: _Bfloat16,
   };
 
+#ifndef __cpp_using_enum
+  // XXX Remove these once 'using enum' support is ubiquitous.
+  static constexpr _Fp_fmt _Binary16 = _Fp_fmt::_Binary16;
+  static constexpr _Fp_fmt _Binary32 = _Fp_fmt::_Binary32;
+  static constexpr _Fp_fmt _Binary64 = _Fp_fmt::_Binary64;
+  static constexpr _Fp_fmt _Binary128 = _Fp_fmt::_Binary128;
+  static constexpr _Fp_fmt _X86_80bit = _Fp_fmt::_X86_80bit;
+  static constexpr _Fp_fmt _M68k_80bit = _Fp_fmt::_M68k_80bit;
+  static constexpr _Fp_fmt _Dbldbl = _Fp_fmt::_Dbldbl;
+#endif
+
   // Identify the format used by a floating-point type.
   template
static consteval _Fp_fmt
_S_fp_fmt() noexcept
{
+#ifdef __cpp_using_enum
  using enum _Fp_fmt;
+#endif
 
  // Identify these formats first, then assume anything else is IEEE.
  // N.B. ARM __fp16 alternative format can be handled as binary16.
@@ -810,7 +823,9 @@ namespace std
return __builtin_bit_cast(int16_t, __val);
  else
{
+#ifdef __cpp_using_enum
  using enum _Fp_fmt;
+#endif
  constexpr auto __fmt = _S_fp_fmt<_Tp>();
  if constexpr (__fmt == _X86_80bit || __fmt == _M68k_80bit)
{
@@ -862,7 +877,9 @@ namespace std
  if (__ix == __iy)
return strong_ordering::equal; // All bits are equal, we're done.
 
+#ifdef __cpp_using_enum
  using enum _Fp_fmt;
+#endif
  constexpr auto __fmt = _S_fp_fmt<_Tp>();
 
  if constexpr (__fmt == _Dbldbl) // double-double
-- 
2.34.1

[committed] libstdc++: Fix incorrect preprocessor conditions in

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.

-- >8 --

The conditions that guard the feature test macros in  should
match the main definitions of the macros in other headers.

This doesn't matter for GCC, because it supports all the conditions
being tested here, but it does matter for non-GCC compilers without the
relevant C++20 features.

libstdc++-v3/ChangeLog:

* include/std/version (__cpp_lib_variant): Fix conditions to
match .
(__cpp_lib_expected): Fix condition to match .
---
 libstdc++-v3/include/std/version | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 7dbac23f22d..44b8a9f88b5 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -176,7 +176,7 @@
 # define __cpp_lib_to_chars 201611L
 #endif
 #define __cpp_lib_unordered_map_try_emplace 201411L
-#if !(__cplusplus >= 202002L && __cpp_concepts >= 202002L)
+#if !(__cpp_concepts >= 202002L && __cpp_constexpr >= 201811L)
 // N.B. updated value in C++20
 # define __cpp_lib_variant 202102L
 #endif
@@ -293,7 +293,7 @@
 # endif
 #define __cpp_lib_to_address 201711L
 #define __cpp_lib_to_array 201907L
-#if __cplusplus >= 202002L && __cpp_concepts >= 202002L
+#if __cpp_concepts >= 202002L && __cpp_constexpr >= 201811L
 # define __cpp_lib_variant 202106L
 #endif
 #endif
@@ -306,7 +306,9 @@
 
 #if _GLIBCXX_HOSTED
 #define __cpp_lib_adaptor_iterator_pair_constructor 202106L
-#define __cpp_lib_expected 202202L
+#if __cpp_concepts >= 202002L
+# define __cpp_lib_expected 202202L
+#endif
 #define __cpp_lib_invoke_r 202106L
 #define __cpp_lib_ios_noreplace 202200L
 #if __cpp_lib_concepts
-- 
2.34.1

[PATCH] c++: Fox template-introduction tentative parsing in class bodies clear colon_corrects_to_scope_p [PR105061]

[Jakub Jelinek via Gcc-patches]

Hi!

The concepts support (in particular template introductions from concepts TS)
broke the following testcase, valid unnamed bitfields with dependent
types (or even just typedefs) were diagnosed as typos (: instead of correct
::) in template introduction during their tentative parsing.
The following patch fixes that by not doing this : to :: correction when
member_p is true.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
release branches (so far also bootstrapped/regtested on the above targets
on 11 branch)?

2022-03-29  Jakub Jelinek  

PR c++/105061
* parser.cc (cp_parser_template_introduction): If member_p, temporarily
clear parser->colon_corrects_to_scope_p around tentative parsing of
nested name specifier.

* g++.dg/concepts/pr105061.C: New test.

--- gcc/cp/parser.cc.jj 2022-03-26 08:11:50.030217910 +0100
+++ gcc/cp/parser.cc2022-03-28 17:30:41.488053848 +0200
@@ -31417,9 +31417,15 @@ cp_parser_template_introduction (cp_pars
   tree saved_scope = parser->scope;
   tree saved_object_scope = parser->object_scope;
   tree saved_qualifying_scope = parser->qualifying_scope;
+  bool saved_colon_corrects_to_scope_p = parser->colon_corrects_to_scope_p;
 
   cp_token *start_token = cp_lexer_peek_token (parser->lexer);
 
+  /* In classes don't parse valid unnamed bitfields as invalid
+ template introductions.  */
+  if (member_p)
+parser->colon_corrects_to_scope_p = false;
+
   /* Look for the optional `::' operator.  */
   cp_parser_global_scope_opt (parser,
  /*current_scope_valid_p=*/false);
@@ -31440,6 +31446,7 @@ cp_parser_template_introduction (cp_pars
   parser->scope = saved_scope;
   parser->object_scope = saved_object_scope;
   parser->qualifying_scope = saved_qualifying_scope;
+  parser->colon_corrects_to_scope_p = saved_colon_corrects_to_scope_p;
 
   if (concept_name == error_mark_node
   || (seen_error () && !concept_definition_p (tmpl_decl)))
--- gcc/testsuite/g++.dg/concepts/pr105061.C.jj 2022-03-28 17:34:02.051207207 
+0200
+++ gcc/testsuite/g++.dg/concepts/pr105061.C2022-03-28 17:33:14.502882074 
+0200
@@ -0,0 +1,13 @@
+// PR c++/105061
+
+template 
+struct A { T : V, u : U; };
+template 
+struct B { unsigned : V, u : U; };
+typedef unsigned uns;
+template 
+struct C { uns : V, u : U; };
+
+A a = { 13 };
+B<5, 6> b = { 26 };
+C<8, 9> c = { 42 };

Jakub

[PATCH] combine: Don't record for UNDO_MODE pointers into regno_reg_rtx array [PR104985]

[Jakub Jelinek via Gcc-patches]

Hi!

The testcase in the PR fails under valgrind on mips64 (but only Martin
can reproduce, I couldn't).
But the problem reported there is that SUBST_MODE remembers addresses
into the regno_reg_rtx array, then some splitter needs a new pseudo
and calls gen_reg_rtx, which reallocates the regno_reg_rtx array
and finally undo operation is done and dereferences the old regno_reg_rtx
entry.
The rtx values stored in regno_reg_rtx array seems to be created
by gen_reg_rtx only and since then aren't modified, all we do for it
is adjusting its fields (e.g. adjust_reg_mode that SUBST_MODE does).

So, I think it is useless to use where.r for UNDO_MODE and store
_reg_rtx[regno] in struct undo, we can store just
regno_reg_rtx[regno] (i.e. pointer to the REG itself instead of
pointer to pointer to REG) or could also store just the regno.

The following patch does the former.

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

Or there are variant patches in the PR, either a minimal version of
this patch, or one that records regno and adjusts all SUBST_MODE uses.
Also, not sure I like very much a function name in all caps, but I wanted
to preserve the users and all other SUBST and SUBST_* are also all caps.
Yet another possibility would be keep do_SUBST_MODE with the new
arguments and
#define SUBST_MODE(INTO, NEWVAL)  do_SUBST_MODE ((INTO), (NEWVAL))

2022-03-29  Jakub Jelinek  

PR rtl-optimization/104985
* combine.cc (struct undo): Add where.m member.
(do_SUBST_MODE): Rename to ...
(SUBST_MODE): ... this.  No longer a macro.  Change first argument
from rtx * into rtx, operate on INTO rather than *INTO and save
INTO into where.m.
(try_combine, undo_to_marker): For UNDO_MODE, use undo->where.m
instead of *undo->where.r.

--- gcc/combine.cc.jj   2022-02-16 14:48:23.847681860 +0100
+++ gcc/combine.cc  2022-03-28 14:37:04.708490651 +0200
@@ -382,7 +382,7 @@ struct undo
   struct undo *next;
   enum undo_kind kind;
   union { rtx r; int i; machine_mode m; struct insn_link *l; } old_contents;
-  union { rtx *r; int *i; struct insn_link **l; } where;
+  union { rtx *r; int *i; rtx m; struct insn_link **l; } where;
 };
 
 /* Record a bunch of changes to be undone, up to MAX_UNDO of them.
@@ -761,10 +761,10 @@ do_SUBST_INT (int *into, int newval)
well.  */
 
 static void
-do_SUBST_MODE (rtx *into, machine_mode newval)
+SUBST_MODE (rtx into, machine_mode newval)
 {
   struct undo *buf;
-  machine_mode oldval = GET_MODE (*into);
+  machine_mode oldval = GET_MODE (into);
 
   if (oldval == newval)
 return;
@@ -775,15 +775,13 @@ do_SUBST_MODE (rtx *into, machine_mode n
 buf = XNEW (struct undo);
 
   buf->kind = UNDO_MODE;
-  buf->where.r = into;
+  buf->where.m = into;
   buf->old_contents.m = oldval;
-  adjust_reg_mode (*into, newval);
+  adjust_reg_mode (into, newval);
 
   buf->next = undobuf.undos, undobuf.undos = buf;
 }
 
-#define SUBST_MODE(INTO, NEWVAL)  do_SUBST_MODE (&(INTO), (NEWVAL))
-
 /* Similar to SUBST, but NEWVAL is a LOG_LINKS expression.  */
 
 static void
@@ -4082,7 +4080,7 @@ try_combine (rtx_insn *i3, rtx_insn *i2,
   for (undo = undobuf.undos; undo; undo = undo->next)
if (undo->kind == UNDO_MODE)
  {
-   rtx reg = *undo->where.r;
+   rtx reg = undo->where.m;
machine_mode new_mode = GET_MODE (reg);
machine_mode old_mode = undo->old_contents.m;
 
@@ -4755,7 +4753,7 @@ undo_to_marker (void *marker)
  *undo->where.i = undo->old_contents.i;
  break;
case UNDO_MODE:
- adjust_reg_mode (*undo->where.r, undo->old_contents.m);
+ adjust_reg_mode (undo->where.m, undo->old_contents.m);
  break;
case UNDO_LINKS:
  *undo->where.l = undo->old_contents.l;

Jakub

Re: [PATCH] PR fortran/50549 - should detect different type parameters in structure constructors

[Tobias Burnus]

Hi Harald,

On 28.03.22 22:03, Harald Anlauf via Fortran wrote:

All current cases of printing a HOST_WIDE_INT in gcc/fortran/ use
'sprintf', and I did not find any other use of %wd/%wu.  So the
mentioned implementation is not really stressed yet... ;-)


That's all your fault ;-)

(Your commit
https://gcc.gnu.org/r12-3273-ge4cb3bb9ac11b4126ffa718287dd509a4b10a658
did remove the only user.)


../../gcc-trunk/gcc/fortran/resolve.cc: In function 'bool
resolve_structure_cons(gfc_expr*, int)':
../../gcc-trunk/gcc/fortran/resolve.cc:1388:43: warning: unknown
conversion type character 'w' in format [-Wformat=]
 la, lb, comp->name, >expr->where);
   ^


That's only a warning. Have you tried whether it works at runtime?
My bet is that it does!

Question: Do you build with --disable-bootstrap ? Or do you do a proper 
bootstrap?

I am asking because:
* Here, it bootstraps *without* warnings/errors (I do a full bootstrap)
* GCC is bootstrapped with -Werror, i.e. I had expected an error and not a 
warning,
  while with --disable-bootstrap, the -Werror is not used as some random
  compiler may have additional (correct or bogus) warnings.
* %wd is only supported since GCC 12.
  The supported formats + the warning is bound to the compiler version,
  i.e. an older compiler does not support newer flags and, thus, warns for
  them when compiling. (But as the support depends on the current source,
  the compile-time warning of older compilers can be ignored.)

  * * *

Can you check & try again?  I don't mind getting a format warning with
GCC < GCC 12. But with GCC 12 compiled (either installed compiler or
when bootstrapping) it should compile without errors.

If you can confirm my suspicion, the patch LGTM.

Tobias

PS: I played around a bit. And with a GCC 12 bootstrap,
I get as expected an error (not a warning) for something unsupported (%Wd)
while %wd is supported. Additionally, I see a '|' in the output.

The "|" appeared with GCC 9. Thus, I wonder whether you compile w/o
bootstrapping with GCC 8?


../gcc/fortran/resolve.cc:1386:55: error: unknown conversion type character ‘W’ 
in format [-Werror=format=]
 1386 |   gfc_error ("Unequal character lengths (%Wd/%wd) for pointer 
"
  |   ^

-
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

Re: analyzer/strndup-1.c: skip on *-*-vxworks*

[Richard Biener via Gcc-patches]

On Tue, Mar 29, 2022 at 4:24 AM Alexandre Oliva via Gcc-patches
 wrote:
>
>
> Add vxworks to the set of operating systems whose C libraries don't
> support strndup.
>
> Tested on affected systems and on x86_64-linux-gnu.  Ok to install?

OK

>
> for  gcc/testsuite/ChangeLog
>
> * gcc.dg/analyzer/strndup-1.c: Add *-*-vxworks* to no-strndup
> in libc.
> ---
>  gcc/testsuite/gcc.dg/analyzer/strndup-1.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.dg/analyzer/strndup-1.c 
> b/gcc/testsuite/gcc.dg/analyzer/strndup-1.c
> index edf494ac28448..8cf7a42bf5361 100644
> --- a/gcc/testsuite/gcc.dg/analyzer/strndup-1.c
> +++ b/gcc/testsuite/gcc.dg/analyzer/strndup-1.c
> @@ -1,4 +1,5 @@
> -/* { dg-skip-if "no strndup in libc" { *-*-darwin[789]* *-*-darwin10* 
> *-*-mingw* } } */
> +/* { dg-skip-if "no strndup in libc" { *-*-darwin[789]* *-*-darwin10* 
> *-*-mingw* *-*-vxworks* } } */
> +
>  #include 
>  #include 
>
>
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 

Re: gcc.dg/weak/typeof-2: arm may use constant pool

[Richard Biener via Gcc-patches]

On Tue, Mar 29, 2022 at 1:04 AM Alexandre Oliva via Gcc-patches
 wrote:
>
>
> Some ARM configurations, such as with -mlong-calls, load the call
> target from the constant pool, breaking the expectation of the test as
> on several other targets.
>
> Tested on an affected target.  Ok to install?

OK

>
> for  gcc/testsuite/ChangeLog
>
> * gcc.dg/weak/typeof-2.c: Add arm*-*-* to targets that may
> place the call target in a constant pool.
> ---
>  gcc/testsuite/gcc.dg/weak/typeof-2.c |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/gcc/testsuite/gcc.dg/weak/typeof-2.c 
> b/gcc/testsuite/gcc.dg/weak/typeof-2.c
> index afce17f53cb09..c6e45624810aa 100644
> --- a/gcc/testsuite/gcc.dg/weak/typeof-2.c
> +++ b/gcc/testsuite/gcc.dg/weak/typeof-2.c
> @@ -40,6 +40,8 @@ int bar3 (int x)
>  // { dg-final { if [string match {sh[elb1-9]*-*-*} $target_triplet ] 
> {return} } }
>  // Likewise for S/390 targets
>  // { dg-final { if [string match s390*-*-* $target_triplet ] {return} } }
> +// Likewise for ARM targets
> +// { dg-final { if [string match arm*-*-* $target_triplet ] {return} } }
>  // Likewise for CRIS targets.
>  // { dg-final { if [string match cris-*-* $target_triplet ] {return} } }
>  // Likewise for m68k targets.
>
>
> --
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 

Re: [PATCH] testsuite: fixup pr97521.c and pr96713.c on i686-*

[Richard Biener via Gcc-patches]

On Mon, Mar 28, 2022 at 4:46 PM Marc Poulhiès via Gcc-patches
 wrote:
>
> Marc Poulhiès  writes:
>
> > On targets that do not have MXX/SSE enabled by default, pr97521
> > and pr96713 fail because they emit warnings:
> >
> > pr97521.c:12:1: warning: MMX vector return without MMX enabled
> > changes the ABI [-Wpsabi]
> > pr97521.c:11:1: note: the ABI for passing parameters with
> > 16-byte alignment has changed in GCC 4.6
> > pr97521.c:11:1: warning: SSE vector argument without SSE enabled
> > changes the ABI [-Wpsabi]
> >
> > Add -Wno-abi to dg-options.
> >
> > Ok for master?
>
> ping ?

OK

Re: [PATCH] testsuite: Check fpic support in pr103275.c

[Richard Biener via Gcc-patches]

On Mon, Mar 28, 2022 at 4:46 PM Marc Poulhiès via Gcc-patches
 wrote:
>
> Marc Poulhiès  writes:
>
> > Test must check for effective support of fpic.
> >
> > Tested on x86_64-pc-linux-gnu{-m32,}.
> >
> > ok for master?
>
> ping?

OK

Re: [PATCH][RFC] tree-optimization/101908 - avoid STLF fails when vectorizing

[Richard Biener via Gcc-patches]

On Mon, 28 Mar 2022, Richard Sandiford wrote:

> Richard Biener  writes:
> > On Mon, 28 Mar 2022, Richard Sandiford wrote:
> >
> >> Richard Biener  writes:
> >> > Since we're now vectorizing by default at -O2 issues like PR101908
> >> > become more important where we apply basic-block vectorization to
> >> > parts of the function covering loads from function parameters passed
> >> > on the stack.  Since we have no good idea how the stack pushing
> >> > was performed but we do have a good idea that it was done recent
> >> > when at the start of the function a STLF failure is inevitable
> >> > if the argument passing code didn't use the same or larger vector
> >> > stores and also has them aligned the same way.
> >> >
> >> > Until there's a robust IPA based solution the following implements
> >> > target independent heuristics in the vectorizer to retain scalar
> >> > loads for loads from parameters likely passed in memory (I use
> >> > a BLKmode DECL_MODE check for this rather than firing up
> >> > cummulative-args).  I've restricted this also to loads from the
> >> > first "block" (that can be less than the first basic block if there's
> >> > a call for example), since that covers the testcase.
> >> >
> >> > Note that for the testcase (but not c-ray from the bugreport) there's
> >> > a x86 peephole2 that vectorizes things back, so the patch is
> >> > not effective there.
> >> >
> >> > Any comments?  I know we're also looking at x86 port specific
> >> > mitigations but the issue will hit arm and power/z as well I think.
> >> 
> >> I'm not sure this is a target-independent win.  In a loop that:
> >> 
> >>   stores 2 scalars
> >>   loads the stored scalars as a vector
> >>   adds a vector
> >>   stores a vector
> >> 
> >> (no feedback), I see a 20% regression using elementwise accesses for
> >> the load vs. using a normal vector load (measured on a Cortex-A72).
> >> With feedback the elementwise version is still slower, but obviously
> >> not by such a big factor.
> >
> > I see, so that's even without a call inbetween the scalar stores
> > and the vector load as is the case we're trying to cover.  I
> > would suspect that maybe the two elementwise accesses execute
> > too close to the two scalar stores to benefit from any forwarding
> > with the A72 micro-architecture?  Do you see a speedup when
> > performing a vector store instead of two scalar stores?
> 
> Yeah, it's faster with a vector store than with 2 scalar stores.
> 
> The difference between elementwise loads and vector loads reproduces
> with execution of the stores and the load forced further apart.
> 
> Note that (unlike x86?) the elementwise loads are still done on the
> vector side, so this is not a scalar->vector vs. scalar->scalar
> trade-off.

That's the same on x86 - scalar loads are still done on the vector
side but forwarding from the store buffer isn't possible if the
stores were scalar and the load vector.  The CPU has to wait for
the data to reach L1-D for the load to complete.  With matching
scalar/scalar or vector/vector store/load the data can forward
from the store buffers.

Richard.

Re: [PATCH] c++: call complete_type after performing auto deduction [PR80351]

[Pokechu22 via Gcc-patches]

On Thu, Mar 24, 2022 at 1:53 PM Jason Merrill  wrote:
> Thanks!  For future reference, the patch doesn't apply easily because
> gmail wrapped lines; for sending patches via gmail you'll need to use
> attachments.  Or you can use another MUA, or git send-email.  This time
> I fixed the wrapping by hand, but that's a pain (especially since
> there's no "try again" flag to git am).

Thanks.  I was vaguely aware that gmail did something wrong, but I
thought that enabling plain-text mode was enough to work around it.
It might be useful to add that information to the contributing
webpage.  I've attached a copy of the patch here in case anyone else
wants to test it without dealing with the mangling.

Out of curiosity, do you know if this issue could have impacted
anything beyond the false warning?  I had previously determined that
ensure_literal_type_for_constexpr_object completes the type, so for
constexpr variables it wouldn't have caused any further issues, but I
discovered that regular const variables were also affected later on
(and possibly other unused variables could be affected, but non-const
ones would trigger the warning normally).

> Also, like other DCO projects, we can't normally accept pseudonymous
> contributions.  But as you say in the PR, this patch is trivial enough
> that I'm content to apply it myself; I want to make some adjustments anyway.

Also out of curiosity, what do you want to adjust with it?  I'd like
to know in case it's relevant for any other patch that I submit
(though there probably won't be a situation where I'm writing another
patch for a while).

Lastly, I'd appreciate my pseudonym being credited (at least as a
co-author) in the final patch, but I get that the patch being trivial
enough that no credit is needed is why it's possible for it to be
submitted pseudonymously in the first place, so if there's a policy
that prohibits doing so that's fine.  The more important thing is that
the bug gets fixed :)

--Poke

> Currently GCC 12 development is in the regression fixes only stage, so
> I'll queue this for GCC 13.
>
> Thanks again,
> Jason
>


0001-c-call-complete_type-after-performing-auto-deduction.patch
Description: Binary data