Re: [PATCH] libgccjit: Fix float vector comparison

[Antoni Boucher via Gcc-patches]

I'm posting the patch again so that you can double-check that I wrote
the DCO for the co-author correctly.
Does that look good?
Thanks.

On Thu, 2022-12-01 at 11:57 -0500, David Malcolm wrote:
> On Thu, 2022-12-01 at 10:33 -0500, Antoni Boucher wrote:
> > On Thu, 2022-12-01 at 10:25 -0500, David Malcolm wrote:
> > > On Thu, 2022-12-01 at 10:01 -0500, Antoni Boucher wrote:
> > > > Thanks, David.
> > > > Since we're not in phase 1 anymore, do we need an approval
> > > > before
> > > > I
> > > > merge like last year or can I merge immediately?
> > > 
> > > I think it counts as a bug fix and thus you can go ahead and
> > > merge
> > > (assuming you've done the usual testing).
> > > 
> > > > I also have many other patches (all in jit) that I need to
> > > > prepare
> > > > and
> > > > post to this mailing list.
> > > > What do you think?
> > > 
> > > Given that you're one of the main users of libgccjit I think
> > > there's
> > > a
> > > case for stretching the deadlines a bit here.
> > > 
> > > Do you have a repo I can look at?
> > 
> > Yes! The commits are in my fork:
> > https://github.com/antoyo/gcc
> > 
> > The only big one is the one adding support for target-dependent
> > builtins:
> > https://github.com/antoyo/gcc/commit/6d4313d4c02dd878f43917c978f299f5119330f0
> > 
> > Regarding this one, there's the issue that since we record the
> > builtins
> > on the first context run, we only have access to the builtins from
> > the
> > second run.
> > Do you have any idea how to fix this?
> > Or do you consider this is acceptable?
> 
> This is implemented behind the new
> gcc_jit_context_get_target_builtin_function entrypoint, right?
> 
> If so, perhaps that recording::context::get_target_builtin_function
> could detect if it's the first time it's been called on this context,
> and if so make a playback::context to do the detection?  That way it
> would be transparent to the user, and work first time.
> 
> 
> I see you have patches to add function and variable attributes; I
> wonder if this would be cleaner internally if there was a
> recording::attribute class, rather than the std::pair currently in
> use
> (some attributes have int arguments rather than string, others have
> multiple args).
> 
> I also wondered if a "gcc_jit_attribute" type could be exposed to the
> user, e.g.:
> 
>   attr1 = gcc_jit_context_new_attribute (ctxt, "noreturn");
>   attr2 = gcc_jit_context_new_attribute_with_string (ctxt, "alias",
> "__foo");
>   gcc_jit_function_add_attribute (ctxt, attr1);
>   gcc_jit_function_add_attribute (ctxt, attr2);
> 
> or somesuch?  But I think the API you currently have is OK.
> 
> 
> > 
> > I also have a WIP branch which adds support for try/catch:
> > https://github.com/antoyo/gcc/commit/6219339fcacb079431596a0bc6cf8d430a1bd5a1
> > I'm not sure if this one is going to be ready soon or not.
> 
> I see that the new entrypoints have e.g.:
> 
> /* Add a try/catch statement.
>    This is equivalent to this C++ code:
>  try {
>     try_block
>  }
>  catch {
>     catch_block
>  }
> */
> 
> void
> gcc_jit_block_add_try_catch (gcc_jit_block *block,
>  gcc_jit_location *loc,
>  gcc_jit_block *try_block,
>  gcc_jit_block *catch_block);
> 
> but I'm not sure how this is meant to interact with the CFG-like
> model
> used by the rest of the gcc_jit_block_* API.  What happens at the end
> of the blocks?  Does the generated code use the C++ ABI for
> exception-
> handling?
> 
> Dave
> 
> > 
> > Thanks.
> > 
> > > 
> > > Dave
> > > 
> > > 
> > > > 
> > > > On Thu, 2022-12-01 at 09:28 -0500, David Malcolm wrote:
> > > > > On Sun, 2022-11-20 at 14:03 -0500, Antoni Boucher via Jit
> > > > > wrote:
> > > > > > Hi.
> > > > > > This fixes bug 107770.
> > > > > > Thanks for the review.
> > > > > 
> > > > > Thanks, the patch looks good to me.
> > > > > 
> > > > > Dave
> > > > > 
> > > > 
> > > 
> > 
> 

From c28749d9a4a7535f7f561127e0f02a0635fb4ae7 Mon Sep 17 00:00:00 2001
From: Antoni Boucher 
Date: Sun, 20 Nov 2022 10:22:53 -0500
Subject: [PATCH] libgccjit: Fix float vector comparison

Fix float vector comparison and add comparison tests didn't include float and
vectors.

gcc/testsuite:
	PR jit/107770
	* jit.dg/harness.h: Add new macro to to perform vector
	comparisons
	* jit.dg/test-expressions.c: Extend comparison tests to add float
	types and vectors

gcc/jit:
	PR jit/107770
	* jit-playback.cc: Fix vector float comparison
	* jit-playback.h: Update comparison function signature
	* jit-recording.cc: Update call for "new_comparison" function
	* jit-recording.h: Fix vector float comparison

Co-authored-by: Guillaume Gomez 
Signed-off-by: Guillaume Gomez 
---
 gcc/jit/jit-playback.cc |  27 ++-
 gcc/jit/jit-playback.h  |   2 +-
 gcc/jit/jit-recording.cc|   3 +-
 gcc/jit/jit-recording.h |  18 +-
 gcc/testsuite/jit.dg/harness.h  |  15 ++
 

[PATCH v3] c++: Reject UDLs in certain contexts [PR105300]

[Marek Polacek via Gcc-patches]

On Fri, Nov 18, 2022 at 08:39:10PM -0500, Jason Merrill wrote:
> On 11/18/22 18:52, Marek Polacek wrote:
> > +/* Parse a string literal or user defined string literal.
> > +
> > +   user-defined-string-literal :
> > + string-literal ud-suffix
> > +
> > +   Parameters as for cp_parser_string_literal.  If LOOKUP_UDLIT, perform
> > +   a lookup for a suitable template function.  */
> > +
> > +static inline cp_expr
> > +cp_parser_userdef_string_literal (cp_parser *parser, bool translate,
> > + bool wide_ok, bool lookup_udlit = true)
> 
> I think this function doesn't need the translate and wide_ok parms, they can
> always be true.

I've dropped the wide_ok one, but not the other, because...
 
> > +{
> > +  return cp_parser_string_literal_common (parser, translate, wide_ok,
> > + /*udl_ok=*/true, lookup_udlit);
> > +}
> > +
> >   /* Look up a literal operator with the name and the exact arguments.  */
> >   static tree
> > @@ -4913,7 +4955,7 @@ cp_parser_userdef_numeric_literal (cp_parser *parser)
> >  as arguments.  */
> >   static tree
> > -cp_parser_userdef_string_literal (tree literal)
> > +finish_userdef_string_literal (tree literal)
> >   {
> > tree suffix_id = USERDEF_LITERAL_SUFFIX_ID (literal);
> > tree name = cp_literal_operator_id (IDENTIFIER_POINTER (suffix_id));
> > @@ -5652,10 +5694,10 @@ cp_parser_primary_expression (cp_parser *parser,
> >   case CPP_UTF8STRING_USERDEF:
> > /* ??? Should wide strings be allowed when 
> > parser->translate_strings_p
> >  is false (i.e. in attributes)?  If not, we can kill the third
> > -argument to cp_parser_string_literal.  */
> 
> I think the answer to this old question is no: if we have an
> encoding-prefix, we should be translating.

...I don't actually know how to resolve this.  wide_ok is always true here.
Should that change?  Or rather, should translate be false for CPP_STRING only?

> > -  return (cp_parser_string_literal (parser,
> > -   parser->translate_strings_p,
> > -   true)
> > +argument to cp_parser_{,userdef}string_literal.  */
> > +  return (cp_parser_userdef_string_literal (parser,
> > +   parser->translate_strings_p,
> > +   /*wide_ok=*/true)
> 
> For CPP_*STRING* without _USERDEF, we should still call
> cp_parser_string_literal.

It looks like we always have to call cp_parser_userdef_string_literal
otherwise this would be reejcted:

  std::string concat01 = "Hello, " "World!"_www;

Because first we see a CPP_STRING but the subsequent UDL shouldn't
be rejected.

So here's an updated version which drops the always-true parameter but
doesn't resolve the old question.

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

-- >8 --
In this PR, we are crashing because we've encountered a UDL where a
string-literal is expected.  This patch makes the parser reject string
and character UDLs in all places where the grammar requires a
string-literal and not a user-defined-string-literal.

I've introduced two new wrappers; the existing cp_parser_string_literal
was renamed to cp_parser_string_literal_common and should not be called
directly.  finish_userdef_string_literal is renamed from
cp_parser_userdef_string_literal.

PR c++/105300

gcc/c-family/ChangeLog:

* c-pragma.cc (handle_pragma_message): Warn for CPP_STRING_USERDEF.

gcc/cp/ChangeLog:

* parser.cc: Remove unnecessary forward declarations.
(cp_parser_string_literal): New wrapper.
(cp_parser_string_literal_common): Renamed from
cp_parser_string_literal.  Add a bool parameter.  Give an error when
UDLs are not permitted.
(cp_parser_userdef_string_literal): New wrapper.
(finish_userdef_string_literal): Renamed from
cp_parser_userdef_string_literal.
(cp_parser_primary_expression): Call cp_parser_userdef_string_literal
instead of cp_parser_string_literal.
(cp_parser_linkage_specification): Move a variable declaration closer
to its first use.
(cp_parser_static_assert): Likewise.
(cp_parser_operator): Call cp_parser_userdef_string_literal instead of
cp_parser_string_literal.
(cp_parser_asm_definition): Move a variable declaration closer to its
first use.
(cp_parser_asm_specification_opt): Move variable declarations closer to
their first use.
(cp_parser_asm_operand_list): Likewise.
(cp_parser_asm_clobber_list): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/udlit-error1.C: New test.
---
 gcc/c-family/c-pragma.cc  |   3 +
 gcc/cp/parser.cc  | 128 ++
 gcc/testsuite/g++.dg/cpp0x/udlit-error1.C |  21 
 3 files changed, 109 insertions(+), 43 deletions(-)
 create mode 100644 

Re: [PATCH] Fortran: intrinsic MERGE shall use all its arguments [PR107874]

[Harald Anlauf via Gcc-patches]

Dear all,

I've committed an obvious fix for the testcase to avoid recursive I/O,
as it did cause a hang on some systems:

https://gcc.gnu.org/g:36a4ee406b95ae24a59b8b3f8ebe29af6fd5261e

Confirmed by Jerry that this resolves his issue.
See also attached.

Thanks,
Harald

Am 29.11.22 um 09:08 schrieb Paul Richard Thomas via Gcc-patches:

Hi Harald,

It looks good to me.

Thanks to you and Steve for the patch.

Paul


On Mon, 28 Nov 2022 at 20:05, Harald Anlauf via Fortran 
wrote:


Dear all,

as reported, the Fortran standard requires all actual argument
expressions to be evaluated (e.g. F2018:15.5.3).

There were two cases for intrinsic MERGE where we failed to do so:

- non-constant mask; Steve provided the patch

- constant scalar mask; we need to be careful to simplify only if
   the argument on the "other" path is known to be constant so that
   it does not have side-effects and can be immediately removed.

The latter change needed a correction of a sub-test of testcase
merge_init_expr_2.f90, which should not have been simplified
the way the original author assumed.  I decided to modify the
test in such way that simplification is valid and provides
the expect pattern.

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

Thanks,
Harald




From 36a4ee406b95ae24a59b8b3f8ebe29af6fd5261e Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Fri, 2 Dec 2022 22:30:16 +0100
Subject: [PATCH] Fortran: intrinsic MERGE shall use all its arguments
 [PR107874]

gcc/testsuite/ChangeLog:

	PR fortran/107874
	* gfortran.dg/merge_1.f90: Avoid recursive I/O.
---
 gcc/testsuite/gfortran.dg/merge_1.f90 | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/gfortran.dg/merge_1.f90 b/gcc/testsuite/gfortran.dg/merge_1.f90
index abbc2276b1c..437b13a8d3f 100644
--- a/gcc/testsuite/gfortran.dg/merge_1.f90
+++ b/gcc/testsuite/gfortran.dg/merge_1.f90
@@ -7,32 +7,40 @@ program testmerge9
   integer :: i
   logical :: x(2) = (/.true., .false./)
   logical :: called(2)
+  logical :: y
 
   ! At run-time all arguments shall be evaluated
   do i = 1,2
  called = .false.
- print *, merge (tstuff(), fstuff(), x(i))
+ y = merge (tstuff(), fstuff(), x(i))
+ print *, y
  if (any (.not. called)) stop 1
   end do
 
   ! Compile-time simplification shall not drop non-constant args
   called = .false.
-  print *, merge (tstuff(),fstuff(),.true.)
+  y = merge (tstuff(),fstuff(),.true.)
+  print *, y
   if (any (.not. called)) stop 2
   called = .false.
-  print *, merge (tstuff(),fstuff(),.false.)
+  y = merge (tstuff(),fstuff(),.false.)
+  print *, y
   if (any (.not. called)) stop 3
   called = .false.
-  print *, merge (tstuff(),.false.,.true.)
+  y = merge (tstuff(),.false.,.true.)
+  print *, y
   if (any (called .neqv. [.true.,.false.])) stop 4
   called = .false.
-  print *, merge (tstuff(),.false.,.false.)
+  y = merge (tstuff(),.false.,.false.)
+  print *, y
   if (any (called .neqv. [.true.,.false.])) stop 5
   called = .false.
-  print *, merge (.true.,fstuff(),.true.)
+  y = merge (.true.,fstuff(),.true.)
+  print *, y
   if (any (called .neqv. [.false.,.true.])) stop 6
   called = .false.
-  print *, merge (.true.,fstuff(),.false.)
+  y = merge (.true.,fstuff(),.false.)
+  print *, y
   if (any (called .neqv. [.false.,.true.])) stop 7
 contains
   logical function tstuff()
-- 
2.35.3

[committed] analyzer: introduce struct event_loc_info

[David Malcolm via Gcc-patches]

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4472-ge24fe1283ca1c4.

gcc/analyzer/ChangeLog:
* analyzer.h (struct event_loc_info): New forward decl.
* bounds-checking.cc: Use event_loc_info throughout to bundle the
loc, fndecl, depth triples.
* call-info.cc: Likewise.
* checker-event.cc: Likewise.
* checker-event.h (struct event_loc_info): New decl.  Use it
throughout to bundle the loc, fndecl, depth triples.
* checker-path.cc: Likewise.
* checker-path.h: Likewise.
* diagnostic-manager.cc: Likewise.
* engine.cc: Likewise.
* infinite-recursion.cc: Likewise.
* pending-diagnostic.cc: Likewise.
* pending-diagnostic.h: Likewise.
* region-model.cc: Likewise.
* sm-signal.cc: Likewise.
* varargs.cc: Likewise.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/analyzer.h|   1 +
 gcc/analyzer/bounds-checking.cc|  12 ++--
 gcc/analyzer/call-info.cc  |  15 +++--
 gcc/analyzer/checker-event.cc  |  55 +++
 gcc/analyzer/checker-event.h   | 104 +
 gcc/analyzer/checker-path.cc   |   7 +-
 gcc/analyzer/checker-path.h|   3 +-
 gcc/analyzer/diagnostic-manager.cc |  85 ---
 gcc/analyzer/engine.cc |  63 +
 gcc/analyzer/infinite-recursion.cc |   7 +-
 gcc/analyzer/pending-diagnostic.cc |  28 
 gcc/analyzer/pending-diagnostic.h  |   3 +-
 gcc/analyzer/region-model.cc   |   6 +-
 gcc/analyzer/sm-signal.cc  |   2 +-
 gcc/analyzer/varargs.cc|  17 +++--
 15 files changed, 211 insertions(+), 197 deletions(-)

diff --git a/gcc/analyzer/analyzer.h b/gcc/analyzer/analyzer.h
index e0fdbad61a7..a2d363f1249 100644
--- a/gcc/analyzer/analyzer.h
+++ b/gcc/analyzer/analyzer.h
@@ -92,6 +92,7 @@ class bounded_ranges_manager;
 
 class pending_diagnostic;
 class pending_note;
+struct event_loc_info;
 class state_change_event;
 class checker_path;
 class extrinsic_state;
diff --git a/gcc/analyzer/bounds-checking.cc b/gcc/analyzer/bounds-checking.cc
index 17f183fea21..4b43c43acf5 100644
--- a/gcc/analyzer/bounds-checking.cc
+++ b/gcc/analyzer/bounds-checking.cc
@@ -68,16 +68,14 @@ public:
 
   void add_region_creation_events (const region *,
   tree capacity,
-  location_t loc,
-  tree fndecl, int depth,
+  const event_loc_info _info,
   checker_path _path) override
   {
 /* The memory space is described in the diagnostic message itself,
so we don't need an event for that.  */
 if (capacity)
   emission_path.add_event
-   (make_unique (capacity,
- loc, fndecl, depth));
+   (make_unique (capacity, loc_info));
   }
 
 protected:
@@ -165,14 +163,12 @@ public:
 
   void add_region_creation_events (const region *,
   tree,
-  location_t loc,
-  tree fndecl, int depth,
+  const event_loc_info _info,
   checker_path _path) final override
   {
 if (m_byte_bound && TREE_CODE (m_byte_bound) == INTEGER_CST)
   emission_path.add_event
-   (make_unique (m_byte_bound,
- loc, fndecl, depth));
+   (make_unique (m_byte_bound, loc_info));
   }
 
 protected:
diff --git a/gcc/analyzer/call-info.cc b/gcc/analyzer/call-info.cc
index 7a1c4edfcae..44a66be075a 100644
--- a/gcc/analyzer/call-info.cc
+++ b/gcc/analyzer/call-info.cc
@@ -94,10 +94,10 @@ call_info::add_events_to_path (checker_path *emission_path,
   class call_event : public custom_event
   {
   public:
-call_event (location_t loc, tree fndecl, int depth,
+call_event (const event_loc_info _info,
const call_info *call_info)
-  : custom_event (loc, fndecl, depth),
-   m_call_info (call_info)
+: custom_event (loc_info),
+  m_call_info (call_info)
 {}
 
 label_text get_desc (bool can_colorize) const final override
@@ -114,10 +114,11 @@ call_info::add_events_to_path (checker_path 
*emission_path,
   tree caller_fndecl = src_point.get_fndecl ();
   const int stack_depth = src_point.get_stack_depth ();
 
-  emission_path->add_event (make_unique (get_call_stmt 
()->location,
-caller_fndecl,
-stack_depth,
-this));
+  emission_path->add_event
+(make_unique (event_loc_info (get_call_stmt ()->location,
+ caller_fndecl,
+ stack_depth),
+   

[committed] analyzer: fixes to region creation messages [PR107851]

[David Malcolm via Gcc-patches]

In r13-2573-gc81b60b8c6ff3d I split up the analyzer's region-creation
events to describe the memory space and capacity of the region as two
separate events to avoid combinatorial explosion of message wordings.

However I didn't take into account r13-1405-ge6c3bb379f515b which
added a pending_diagnostic::describe_region_creation_event vfunc which
could change the wording of region creation events.

Hence for:

#include 
#include 

void test ()
{
  int32_t *ptr = malloc (1);
  free (ptr);
}

trunk currently emits:

  Compiler Explorer (x86_64 trunk): https://godbolt.org/z/e3Td7c9s5:

: In function 'test':
:6:18: warning: allocated buffer size is not a multiple of the 
pointee's size [CWE-131] [-Wanalyzer-allocation-size]
6 |   int32_t *ptr = malloc (1);
  |  ^~
  'test': events 1-3
|
|6 |   int32_t *ptr = malloc (1);
|  |  ^~
|  |  |
|  |  (1) allocated 1 bytes here
|  |  (2) allocated 1 bytes here
|  |  (3) assigned to 'int32_t *' {aka 'int *'} here; 
'sizeof (int32_t {aka int})' is '4'
|

where events (1) and (2) are different region_creation_events that have
had their wording overridden (also, with a "1 bytes" issue).

This patch reorganizes region creation events so that each
pending_diagnostic instead creates the events that is appropriate for it,
and the events have responsibility for their own wording.

With this patch, the above emits:

: In function 'test':
:6:18: warning: allocated buffer size is not a multiple of the 
pointee's size [CWE-131] [-Wanalyzer-allocation-size]
6 |   int32_t *ptr = malloc (1);
  |  ^~
  'test': events 1-2
|
|6 |   int32_t *ptr = malloc (1);
|  |  ^~
|  |  |
|  |  (1) allocated 1 byte here
|  |  (2) assigned to 'int32_t *' {aka 'int *'} here; 
'sizeof (int32_t {aka int})' is '4'
|

fixing the duplicate event, and fixing the singular/plural issue.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4471-gf5758fe5b430ef.

gcc/analyzer/ChangeLog:
PR analyzer/107851
* analyzer.cc (make_label_text_n): Convert param "n" from int to
unsigned HOST_WIDE_INT.
* analyzer.h (make_label_text_n): Likewise for decl.
* bounds-checking.cc: Include "analyzer/checker-event.h" and
"analyzer/checker-path.h".
(out_of_bounds::add_region_creation_events): New.
(concrete_past_the_end::describe_region_creation_event): Replace
with...
(concrete_past_the_end::add_region_creation_events): ...this.
(symbolic_past_the_end::describe_region_creation_event): Delete.
* checker-event.cc (region_creation_event::region_creation_event):
Update for dropping all member data.
(region_creation_event::get_desc): Delete, splitting out into
region_creation_event_memory_space::get_desc,
region_creation_event_capacity::get_desc, and
region_creation_event_debug::get_desc.
(region_creation_event_memory_space::get_desc): New.
(region_creation_event_capacity::get_desc): New.
(region_creation_event_allocation_size::get_desc): New.
(region_creation_event_debug::get_desc): New.
* checker-event.h: Include "analyzer/program-state.h".
(enum rce_kind): Delete.
(class region_creation_event): Drop all member data.
(region_creation_event::region_creation_event): Make protected.
(region_creation_event::get_desc): Delete.
(class region_creation_event_memory_space): New.
(class region_creation_event_capacity): New.
(class region_creation_event_allocation_size): New.
(class region_creation_event_debug): New.
* checker-path.cc (checker_path::add_region_creation_events): Add
"pd" param.  Call pending_diangnostic::add_region_creation_events.
Update for conversion of RCE_DEBUG to region_creation_event_debug.
* checker-path.h (checker_path::add_region_creation_events): Add
"pd" param.
* diagnostic-manager.cc (diagnostic_manager::build_emission_path):
Pass pending_diagnostic to
emission_path::add_region_creation_events.
(diagnostic_manager::build_emission_path): Pass path_builder to
add_event_on_final_node.
(diagnostic_manager::add_event_on_final_node): Add "pb" param.
Pass pending_diagnostic to
emission_path::add_region_creation_events.
(diagnostic_manager::add_events_for_eedge): Pass
pending_diagnostic to emission_path::add_region_creation_events.
* diagnostic-manager.h
(diagnostic_manager::add_event_on_final_node): Add "pb" param.
* pending-diagnostic.cc

[PATCH] coroutines: Do not promote temporaries that will be elided.

[Iain Sandoe via Gcc-patches]

Thanks to Adrian for working on this and producing the revised test-cases.

This has been tested on x86_64-darwin21 with our testsuite, cppcoro and
a patched version of folly (that enables the experimental coroutines tests)
without regresssion (actually a handful of progressions on folly, plus the
fixes to our suite).

I am not sure how best to backport this; I think we want it at least on 12
and preferably earlier, but the TARGET_EXPR_ELIDING_P flag is not available
there, perhaps we can construct some local function in coroutines.cc that
emulates it? (or maybe the TARGET_EXPR_ELIDING_P and associated fixes is
suitable for backport?)

thanks
Iain

-- *< --

We usually need to 'promote' (i.e. save to the coroutine frame) any temporary
variable that is in a target expression that must persist across an await
expression.  However, if the TE is just used as a direct initializer for
another object it will be elided - and we should not promote it since that
would lead to a DTOR call for something that is never constructed.

Since we now have a mechanism to tell if TEs will be elided, use that.

Although the PRs referenced initially appear to be different issues, they all
stem from this.

Co-Authored-By: Adrian Perl 
Signed-off-by: Iain Sandoe 

PR c++/100611
PR c++/101367
PR c++/101976
PR c++/99576

gcc/cp/ChangeLog:

* coroutines.cc (find_interesting_subtree): Do not promote temporaries
that are only used as direct initializers for some other object.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr100611.C: New test.
* g++.dg/coroutines/pr101367.C: New test.
* g++.dg/coroutines/pr101976.C: New test.
* g++.dg/coroutines/pr99576_1.C: New test.
* g++.dg/coroutines/pr99576_2.C: New test.
---
 gcc/cp/coroutines.cc|   1 +
 gcc/testsuite/g++.dg/coroutines/pr100611.C  |  94 +++
 gcc/testsuite/g++.dg/coroutines/pr101367.C  |  72 
 gcc/testsuite/g++.dg/coroutines/pr101976.C  |  78 
 gcc/testsuite/g++.dg/coroutines/pr99576_1.C | 124 
 gcc/testsuite/g++.dg/coroutines/pr99576_2.C |  72 
 6 files changed, 441 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr100611.C
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr101367.C
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr101976.C
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr99576_1.C
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr99576_2.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 01a3e831ee5..3f23317a315 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -2685,6 +2685,7 @@ find_interesting_subtree (tree *expr_p, int *dosub, void 
*d)
}
 }
   else if (tmp_target_expr_p (expr)
+  && !TARGET_EXPR_ELIDING_P (expr)
   && !p->temps_used->contains (expr))
 {
   p->entry = expr_p;
diff --git a/gcc/testsuite/g++.dg/coroutines/pr100611.C 
b/gcc/testsuite/g++.dg/coroutines/pr100611.C
new file mode 100644
index 000..14edf4870a1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/pr100611.C
@@ -0,0 +1,94 @@
+// { dg-do run }
+/*
+  Test that instances created in capture clauses within co_await statements do 
not
+  get 'promoted'. This would lead to the members destructor getting called more
+  than once.
+
+  Correct output should look like:
+  Foo(23) 0xf042d8
+  Foo(const& 23) 0xf042ec
+  ~Foo(23) 0xf042ec
+  After co_await
+  ~Foo(23) 0xf042d8
+*/
+#include 
+#include 
+
+static unsigned int struct_Foo_destructor_counter = 0;
+static bool lambda_was_executed = false;
+
+class Task {
+public:
+  struct promise_type {
+Task get_return_object() {
+  return {std::coroutine_handle::from_promise(*this)};
+}
+
+std::suspend_never initial_suspend() { return {}; }
+std::suspend_always final_suspend() noexcept { return {}; }
+void unhandled_exception() {}
+void return_void() {}
+  };
+
+  ~Task() {
+if (handle_) {
+  handle_.destroy();
+}
+  }
+
+  bool await_ready() { return false; }
+  bool await_suspend(std::coroutine_handle<>) { return false; }
+  bool await_resume() { return false; }
+
+private:
+  Task(std::coroutine_handle handle) : handle_(handle) {}
+
+  std::coroutine_handle handle_;
+};
+
+class Foo {
+public:
+  Foo(int id) : id_(id) {
+std::cout << "Foo(" << id_ << ") " << (void*)this << std::endl;
+  }
+
+  Foo(Foo const& other) : id_(other.id_) {
+std::cout << "Foo(const& " << id_ << ") " << (void*)this << std::endl;
+  }
+
+  Foo(Foo&& other) : id_(other.id_) {
+std::cout << "Foo(&& " << id_ << ") " << (void*)this << std::endl;
+  }
+
+  ~Foo() {
+std::cout << "~Foo(" << id_ << ") " << (void*)this << std::endl;
+struct_Foo_destructor_counter++;
+
+if (struct_Foo_destructor_counter > 2){
+  std::cout << "Foo was destroyed more than two times!\n";
+  __builtin_abort();
+}
+}
+
+private:
+  int id_;

Re: [PATCH v3] c++: P2448 - Relaxing some constexpr restrictions [PR106649]

[Jason Merrill via Gcc-patches]

On 12/2/22 14:48, Marek Polacek wrote:

On Fri, Nov 18, 2022 at 09:26:26PM -0500, Jason Merrill wrote:

On 11/16/22 15:27, Jason Merrill wrote:

On 11/16/22 11:06, Marek Polacek wrote:

On Wed, Nov 16, 2022 at 08:41:53AM -0500, Jason Merrill wrote:

On 11/15/22 19:30, Marek Polacek wrote:

@@ -996,19 +1040,26 @@ register_constexpr_fundef (const
constexpr_fundef )
  **slot = value;
    }
-/* FUN is a non-constexpr function called in a context that requires a
-   constant expression.  If it comes from a constexpr
template, explain why
-   the instantiation isn't constexpr.  */
+/* FUN is a non-constexpr (or, with -Wno-invalid-constexpr,
a constexpr
+   function called in a context that requires a constant expression).
+   If it comes from a constexpr template, explain why the
instantiation
+   isn't constexpr.  */


The "if it comes from a constexpr template" wording has needed
an update for
a while now.


Probably ever since r178519.  I've added "Otherwise, explain why the
function
cannot be used in a constexpr context."  Is that acceptable?

--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp23/constexpr-nonlit15.C
@@ -0,0 +1,43 @@
+// PR c++/106649
+// P2448 - Relaxing some constexpr restrictions
+// { dg-do compile { target c++23 } }
+// { dg-options "-Winvalid-constexpr" }
+// A copy/move assignment operator for a class X that is defaulted and
+// not defined as deleted is implicitly defined when it is odr-used,
+// when it is needed for constant evaluation, or when it is explicitly
+// defaulted after its first declaration.
+// The implicitly-defined copy/move assignment operator is constexpr.
+
+struct S {
+  constexpr S() {}
+  S& operator=(const S&) = default; // #1
+  S& operator=(S&&) = default; // #2
+};
+
+struct U {
+  constexpr U& operator=(const U&) = default;
+  constexpr U& operator=(U&&) = default;
+};
+
+/* FIXME: If we only declare #1 and #2, and default them here:
+
+   S& S::operator=(const S&) = default;
+   S& S::operator=(S&&) = default;
+
+then they aren't constexpr.  This sounds like a bug:
+.  */


As I commented on the PR, I don't think this is actually a bug, so let's
omit this FIXME.


I'm glad I didn't really attempt to "fix" it (the inform message is
flawed
and should be improved).  Thanks for taking a look.

Here's a version with the two comments updated.

Ok?


OK.


Since this patch I'm seeing these failures:

FAIL: g++.dg/cpp0x/constexpr-ex1.C  -std=c++23 -fimplicit-constexpr  at line
91 (test for errors, line 89)
FAIL: g++.dg/cpp23/constexpr-nonlit10.C  -std=gnu++23 -fimplicit-constexpr
(test for warnings, line 14)
FAIL: g++.dg/cpp23/constexpr-nonlit10.C  -std=gnu++23 -fimplicit-constexpr
(test for warnings, line 20)
FAIL: g++.dg/cpp23/constexpr-nonlit11.C  -std=gnu++23 -fimplicit-constexpr
(test for warnings, line 28)
FAIL: g++.dg/cpp23/constexpr-nonlit11.C  -std=gnu++23 -fimplicit-constexpr
(test for warnings, line 31)
FAIL: g++.dg/cpp2a/spaceship-eq3.C  -std=c++23 -fimplicit-constexpr (test
for excess errors)


Ah, sorry.  The following patch fixes those fails.

Ok?


OK, thanks.


-- >8 --
Some of the new tests were failing with -fimplicit-constexpr.  This
patch adjusts the expected diagnostic.  Tested with

GXX_TESTSUITE_STDS=98,11,14,17,20,23 make check-c++ 
RUNTESTFLAGS="--target_board=unix\{,-fimplicit-constexpr\} 
dg.exp=spaceship-eq3.C"

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-ex1.C: Adjust dg-error.
* g++.dg/cpp23/constexpr-nonlit10.C: Adjust dg-warning.
* g++.dg/cpp23/constexpr-nonlit11.C: Likewise.
* g++.dg/cpp2a/spaceship-eq3.C: Add dg-error.
---
  gcc/testsuite/g++.dg/cpp0x/constexpr-ex1.C  | 6 +++---
  gcc/testsuite/g++.dg/cpp23/constexpr-nonlit10.C | 4 ++--
  gcc/testsuite/g++.dg/cpp23/constexpr-nonlit11.C | 4 ++--
  gcc/testsuite/g++.dg/cpp2a/spaceship-eq3.C  | 1 +
  4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-ex1.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-ex1.C
index 48281a47784..383d38a42d4 100644
--- a/gcc/testsuite/g++.dg/cpp0x/constexpr-ex1.C
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-ex1.C
@@ -87,8 +87,8 @@ struct resource {
}
  };
  constexpr resource f(resource d)
-{ return d; }  // { dg-error "non-.constexpr." "" { target { { ! 
implicit_constexpr } && c++20_down } } }
-// { dg-error "non-.constexpr." "" { target c++23 } .-2 }
-constexpr resource d = f(9);   // { dg-message ".constexpr." "" { target { ! 
implicit_constexpr } } }
+{ return d; }  // { dg-error "non-.constexpr." "" { target { { { ! 
implicit_constexpr } && c++20_down } || c++11_only } } }
+// { dg-error "non-.constexpr." "" { target { c++23 && { ! implicit_constexpr 
} } } .-2 }
+constexpr resource d = f(9);   // { dg-message ".constexpr." "" { target { { ! 
implicit_constexpr } || c++11_only } } }
  
  // 4.4 floating-point constant expressions

diff --git a/gcc/testsuite/g++.dg/cpp23/constexpr-nonlit10.C 

Re: [PATCH 2/5] c++: Set the locus of the function result decl

[Bernhard Reutner-Fischer via Gcc-patches]

On 2 December 2022 20:30:56 CET, Jason Merrill  wrote:

>Here's what I'm applying:

I meant to play with it during the weekend,
looks good, many thanks for taking care of this!
cheers,

Re: [PATCH v3] c++: P2448 - Relaxing some constexpr restrictions [PR106649]

[Marek Polacek via Gcc-patches]

On Fri, Nov 18, 2022 at 09:26:26PM -0500, Jason Merrill wrote:
> On 11/16/22 15:27, Jason Merrill wrote:
> > On 11/16/22 11:06, Marek Polacek wrote:
> > > On Wed, Nov 16, 2022 at 08:41:53AM -0500, Jason Merrill wrote:
> > > > On 11/15/22 19:30, Marek Polacek wrote:
> > > > > @@ -996,19 +1040,26 @@ register_constexpr_fundef (const
> > > > > constexpr_fundef )
> > > > >  **slot = value;
> > > > >    }
> > > > > -/* FUN is a non-constexpr function called in a context that requires 
> > > > > a
> > > > > -   constant expression.  If it comes from a constexpr
> > > > > template, explain why
> > > > > -   the instantiation isn't constexpr.  */
> > > > > +/* FUN is a non-constexpr (or, with -Wno-invalid-constexpr,
> > > > > a constexpr
> > > > > +   function called in a context that requires a constant expression).
> > > > > +   If it comes from a constexpr template, explain why the
> > > > > instantiation
> > > > > +   isn't constexpr.  */
> > > > 
> > > > The "if it comes from a constexpr template" wording has needed
> > > > an update for
> > > > a while now.
> > > 
> > > Probably ever since r178519.  I've added "Otherwise, explain why the
> > > function
> > > cannot be used in a constexpr context."  Is that acceptable?
> > > > > --- /dev/null
> > > > > +++ b/gcc/testsuite/g++.dg/cpp23/constexpr-nonlit15.C
> > > > > @@ -0,0 +1,43 @@
> > > > > +// PR c++/106649
> > > > > +// P2448 - Relaxing some constexpr restrictions
> > > > > +// { dg-do compile { target c++23 } }
> > > > > +// { dg-options "-Winvalid-constexpr" }
> > > > > +// A copy/move assignment operator for a class X that is defaulted 
> > > > > and
> > > > > +// not defined as deleted is implicitly defined when it is odr-used,
> > > > > +// when it is needed for constant evaluation, or when it is 
> > > > > explicitly
> > > > > +// defaulted after its first declaration.
> > > > > +// The implicitly-defined copy/move assignment operator is constexpr.
> > > > > +
> > > > > +struct S {
> > > > > +  constexpr S() {}
> > > > > +  S& operator=(const S&) = default; // #1
> > > > > +  S& operator=(S&&) = default; // #2
> > > > > +};
> > > > > +
> > > > > +struct U {
> > > > > +  constexpr U& operator=(const U&) = default;
> > > > > +  constexpr U& operator=(U&&) = default;
> > > > > +};
> > > > > +
> > > > > +/* FIXME: If we only declare #1 and #2, and default them here:
> > > > > +
> > > > > +   S& S::operator=(const S&) = default;
> > > > > +   S& S::operator=(S&&) = default;
> > > > > +
> > > > > +then they aren't constexpr.  This sounds like a bug:
> > > > > +.  */
> > > > 
> > > > As I commented on the PR, I don't think this is actually a bug, so let's
> > > > omit this FIXME.
> > > 
> > > I'm glad I didn't really attempt to "fix" it (the inform message is
> > > flawed
> > > and should be improved).  Thanks for taking a look.
> > > 
> > > Here's a version with the two comments updated.
> > > 
> > > Ok?
> > 
> > OK.
> 
> Since this patch I'm seeing these failures:
> 
> FAIL: g++.dg/cpp0x/constexpr-ex1.C  -std=c++23 -fimplicit-constexpr  at line
> 91 (test for errors, line 89)
> FAIL: g++.dg/cpp23/constexpr-nonlit10.C  -std=gnu++23 -fimplicit-constexpr
> (test for warnings, line 14)
> FAIL: g++.dg/cpp23/constexpr-nonlit10.C  -std=gnu++23 -fimplicit-constexpr
> (test for warnings, line 20)
> FAIL: g++.dg/cpp23/constexpr-nonlit11.C  -std=gnu++23 -fimplicit-constexpr
> (test for warnings, line 28)
> FAIL: g++.dg/cpp23/constexpr-nonlit11.C  -std=gnu++23 -fimplicit-constexpr
> (test for warnings, line 31)
> FAIL: g++.dg/cpp2a/spaceship-eq3.C  -std=c++23 -fimplicit-constexpr (test
> for excess errors)

Ah, sorry.  The following patch fixes those fails.

Ok?

-- >8 --
Some of the new tests were failing with -fimplicit-constexpr.  This
patch adjusts the expected diagnostic.  Tested with

GXX_TESTSUITE_STDS=98,11,14,17,20,23 make check-c++ 
RUNTESTFLAGS="--target_board=unix\{,-fimplicit-constexpr\} 
dg.exp=spaceship-eq3.C"

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-ex1.C: Adjust dg-error.
* g++.dg/cpp23/constexpr-nonlit10.C: Adjust dg-warning.
* g++.dg/cpp23/constexpr-nonlit11.C: Likewise.
* g++.dg/cpp2a/spaceship-eq3.C: Add dg-error.
---
 gcc/testsuite/g++.dg/cpp0x/constexpr-ex1.C  | 6 +++---
 gcc/testsuite/g++.dg/cpp23/constexpr-nonlit10.C | 4 ++--
 gcc/testsuite/g++.dg/cpp23/constexpr-nonlit11.C | 4 ++--
 gcc/testsuite/g++.dg/cpp2a/spaceship-eq3.C  | 1 +
 4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-ex1.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-ex1.C
index 48281a47784..383d38a42d4 100644
--- a/gcc/testsuite/g++.dg/cpp0x/constexpr-ex1.C
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-ex1.C
@@ -87,8 +87,8 @@ struct resource {
   }
 };
 constexpr resource f(resource d)
-{ return d; }  // { dg-error "non-.constexpr." "" { target { { 
! implicit_constexpr } && c++20_down } } }
-// { dg-error "non-.constexpr." "" { target 

[PATCH] c++: unexpanded pack in requires-expr parm list [PR107417]

[Patrick Palka via Gcc-patches]

Here find_parameter_packs_r isn't recognizing the unexpanded pack T
inside the requires-expr's parameter list ultimately because
cp_walk_trees avoids walking the parameters, for good reason: in

  requires (Ts... ts) { }

walking 'ts' would trigger a false positive in the unexpanded pack
checker since it's, well, an unexpanded pack.  But we might as well walk
the TREE_TYPE of each parameter still, which for_each_template_parm_r
already does.

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

PR c++/107417

gcc/cp/ChangeLog:

* pt.cc (for_each_template_parm_r) : Move
walking of the TREE_TYPE of each parameter to ...
* tree.cc (cp_walk_subtrees) : ... here.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-requires33.C: New test.
---
 gcc/cp/pt.cc  | 15 --
 gcc/cp/tree.cc| 20 ++-
 .../g++.dg/cpp2a/concepts-requires33.C| 11 ++
 3 files changed, 22 insertions(+), 24 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-requires33.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index bc8ea06ceae..80110da2d8a 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -10573,21 +10573,6 @@ for_each_template_parm_r (tree *tp, int 
*walk_subtrees, void *d)
return error_mark_node;
   break;
 
-case REQUIRES_EXPR:
-  {
-   if (!fn)
- return error_mark_node;
-
-   /* Recursively walk the type of each constraint variable.  */
-   tree p = TREE_OPERAND (t, 0);
-   while (p)
- {
-   WALK_SUBTREE (TREE_TYPE (p));
-   p = TREE_CHAIN (p);
- }
-  }
-  break;
-
 default:
   break;
 }
diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
index 04a055d9d77..e9b6921df6a 100644
--- a/gcc/cp/tree.cc
+++ b/gcc/cp/tree.cc
@@ -5603,15 +5603,17 @@ cp_walk_subtrees (tree *tp, int *walk_subtrees_p, 
walk_tree_fn func,
   break;
  
 case REQUIRES_EXPR:
-  // Only recurse through the nested expression. Do not
-  // walk the parameter list. Doing so causes false
-  // positives in the pack expansion checker since the
-  // requires parameters are introduced as pack expansions.
-  ++cp_unevaluated_operand;
-  result = cp_walk_tree (_EXPR_REQS (*tp), func, data, pset);
-  --cp_unevaluated_operand;
-  *walk_subtrees_p = 0;
-  break;
+  {
+   cp_unevaluated u;
+   for (tree parm = REQUIRES_EXPR_PARMS (*tp); parm; parm = DECL_CHAIN 
(parm))
+ /* Walk the types of each parameter, but not the parameter itself.
+Doing so would cause false positives in the unexpanded parameter
+pack checker since a introduced parameter pack is bare.  */
+ WALK_SUBTREE (TREE_TYPE (parm));
+   WALK_SUBTREE (REQUIRES_EXPR_REQS (*tp));
+   *walk_subtrees_p = 0;
+   break;
+  }
 
 case DECL_EXPR:
   /* User variables should be mentioned in BIND_EXPR_VARS
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-requires33.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-requires33.C
new file mode 100644
index 000..d07ae6dee7b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-requires33.C
@@ -0,0 +1,11 @@
+// PR c++/107417
+// { dg-do compile { target c++20 } }
+
+template
+requires (requires (T x) { true; } && ...)
+void f();
+
+int main() {
+  f();
+  f(); // { dg-error "no match" }
+}
-- 
2.39.0.rc0.49.g083e01275b

Re: [PATCH] c++: substituting CONST_DECL_USING_P enumerator [PR103081]

[Jason Merrill via Gcc-patches]

On 12/2/22 14:01, Patrick Palka wrote:

We implement using enum at class scope by injecting clones of the enum's
CONST_DECLs as fields of the class, for which CONST_DECL_USING_P is
true, so that qualified lookup naturally finds the enumerators.
Substitution into such a CONST_DECL currently ICEs however, because we
assume the DECL_CONTEXT is always the ENUMERAL_TYPE (which has TYPE_VALUES)
but in this case it's the RECORD_TYPE of the class scope (which has
TYPE_FIELDS).

Since these CONST_DECLs appear to always be non-dependent, this patch
fixes this by shortcutting substitution for CONST_DECLs which have a
non-dependent scope.  This subsumes the existing (and seemingly dead)
DECL_NAMESPACE_SCOPE_P early exit test and also benefits substitution
into ordinary non-dependent CONST_DECLs.

Bootstrapped and regtested on x86_64-pc-linu-xgnu, does this look OK for
trunk/12?


OK.


PR c++/103081

gcc/cp/ChangeLog:

* pt.cc (tsubst_copy) : Generalize
early exit test for namespace-scope decls to check dependence of
the enclosing scope instead.  Remove dead args early exit test.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/using-enum-10.C: New test.
* g++.dg/cpp2a/using-enum-10a.C: New test.
---
  gcc/cp/pt.cc|  7 +--
  gcc/testsuite/g++.dg/cpp2a/using-enum-10.C  | 16 
  gcc/testsuite/g++.dg/cpp2a/using-enum-10a.C | 18 ++
  3 files changed, 35 insertions(+), 6 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/using-enum-10.C
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/using-enum-10a.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 31691618d1b..bc8ea06ceae 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -17066,13 +17066,8 @@ tsubst_copy (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
  
  	if (DECL_TEMPLATE_PARM_P (t))

  return tsubst_copy (DECL_INITIAL (t), args, complain, in_decl);
-   /* There is no need to substitute into namespace-scope
-  enumerators.  */
-   if (DECL_NAMESPACE_SCOPE_P (t))
+   if (!uses_template_parms (DECL_CONTEXT (t)))
  return t;
-   /* If ARGS is NULL, then T is known to be non-dependent.  */
-   if (args == NULL_TREE)
- return scalar_constant_value (t);
  
  	/* Unfortunately, we cannot just call lookup_name here.

   Consider:
diff --git a/gcc/testsuite/g++.dg/cpp2a/using-enum-10.C 
b/gcc/testsuite/g++.dg/cpp2a/using-enum-10.C
new file mode 100644
index 000..98fe0644729
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/using-enum-10.C
@@ -0,0 +1,16 @@
+// PR c++/103081
+// { dg-do compile { target c++20 } }
+
+enum class Pig { OINK };
+
+struct Hog {
+  using enum Pig;
+  Hog(Pig) { }
+};
+
+template
+void pen() {
+  Hog(Hog::OINK);
+}
+
+template void pen<0>();
diff --git a/gcc/testsuite/g++.dg/cpp2a/using-enum-10a.C 
b/gcc/testsuite/g++.dg/cpp2a/using-enum-10a.C
new file mode 100644
index 000..43688e69b19
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/using-enum-10a.C
@@ -0,0 +1,18 @@
+// A version of using-enum-10.C where Hog is a template.
+// PR c++/103081
+// { dg-do compile { target c++20 } }
+
+enum class Pig { OINK };
+
+template
+struct Hog {
+  using enum Pig;
+  Hog(Pig) { OINK; }
+};
+
+template
+void pen() {
+  Hog(Hog::OINK);
+}
+
+template void pen<0>();

Re: [PATCH 2/5] c++: Set the locus of the function result decl

[Jason Merrill via Gcc-patches]

On 11/23/22 10:28, Jason Merrill wrote:

On 11/22/22 15:25, Jason Merrill wrote:

On 11/20/22 12:06, Bernhard Reutner-Fischer wrote:

Hi Jason!

The "meh" of result-decl-plugin-test-2.C should likely be omitted,
grokdeclarator would need some changes to add richloc hints and we 
would not

be able to make a reliable guess what to remove precisely.
C.f. /* Check all other uses of type modifiers.  */
Furthermore it is unrelated to DECL_RESULT so not of direct interest
here. The other tests in test-2.C, f() and huh() should work though.

I don't know if it's acceptable to change ipa-pure-const to make the
missing noreturn warning more precise and emit a fixit-hint. At least it
would be a real test for the DECL_RESULT and would spare us the plugin.


The main problem I see with that change is that the syntax of the 
fixit might be wrong for non-C-family front-ends.


Here's a version of the patch that fixes template/method handling, and 
adjusts -Waggregate-return as well:


Actually, that broke some of the spaceship tests, fixed by this version:


Here's what I'm applying:
From d19aa6af6634b1e97f38431ad091f3b3f12baf2f Mon Sep 17 00:00:00 2001
From: Bernhard Reutner-Fischer 
Date: Sun, 20 Nov 2022 18:06:04 +0100
Subject: [PATCH] c++: Set the locus of the function result decl
To: gcc-patches@gcc.gnu.org

gcc/cp/ChangeLog:

	* decl.cc (grokdeclarator): Build RESULT_DECL.
	(start_preparsed_function): Copy location from template.
	* semantics.cc (apply_deduced_return_type): Handle
	arg != current_function_decl.
	* method.cc (implicitly_declare_fn): Use it.

gcc/ChangeLog:

	* function.cc (init_function_start): Use DECL_RESULT location
	for -Waggregate-return warning.

gcc/testsuite/ChangeLog:

	* g++.dg/diagnostic/return-type-loc1.C: New test.

Co-authored-by: Jason Merrill 
---
 gcc/cp/decl.cc| 25 +--
 gcc/cp/method.cc  |  2 +-
 gcc/cp/semantics.cc   | 15 ++-
 gcc/function.cc   |  3 ++-
 .../g++.dg/diagnostic/return-type-loc1.C  | 20 +++
 5 files changed, 53 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/diagnostic/return-type-loc1.C

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 238e72f90da..508156309d9 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -14772,6 +14772,19 @@ grokdeclarator (const cp_declarator *declarator,
 	else if (constinit_p)
 	  DECL_DECLARED_CONSTINIT_P (decl) = true;
   }
+else if (TREE_CODE (decl) == FUNCTION_DECL)
+  {
+	/* If we saw a return type, record its location.  */
+	location_t loc = declspecs->locations[ds_type_spec];
+	if (loc != UNKNOWN_LOCATION)
+	  {
+	tree restype = TREE_TYPE (TREE_TYPE (decl));
+	tree resdecl = build_decl (loc, RESULT_DECL, 0, restype);
+	DECL_ARTIFICIAL (resdecl) = 1;
+	DECL_IGNORED_P (resdecl) = 1;
+	DECL_RESULT (decl) = resdecl;
+	  }
+  }
 
 /* Record constancy and volatility on the DECL itself .  There's
no need to do this when processing a template; we'll do this
@@ -17326,9 +17339,17 @@ start_preparsed_function (tree decl1, tree attrs, int flags)
 
   if (DECL_RESULT (decl1) == NULL_TREE)
 {
-  tree resdecl;
+  /* In a template instantiation, copy the return type location.  When
+	 parsing, the location will be set in grokdeclarator.  */
+  location_t loc = input_location;
+  if (DECL_TEMPLATE_INSTANTIATION (decl1))
+	{
+	  tree tmpl = template_for_substitution (decl1);
+	  if (tree res = DECL_RESULT (DECL_TEMPLATE_RESULT (tmpl)))
+	loc = DECL_SOURCE_LOCATION (res);
+	}
 
-  resdecl = build_decl (input_location, RESULT_DECL, 0, restype);
+  tree resdecl = build_decl (loc, RESULT_DECL, 0, restype);
   DECL_ARTIFICIAL (resdecl) = 1;
   DECL_IGNORED_P (resdecl) = 1;
   DECL_RESULT (decl1) = resdecl;
diff --git a/gcc/cp/method.cc b/gcc/cp/method.cc
index 1e962b6e3b1..7b4d5a59823 100644
--- a/gcc/cp/method.cc
+++ b/gcc/cp/method.cc
@@ -3079,7 +3079,7 @@ implicitly_declare_fn (special_function_kind kind, tree type,
 {
   fn = copy_operator_fn (pattern_fn, EQ_EXPR);
   DECL_ARTIFICIAL (fn) = 1;
-  TREE_TYPE (fn) = change_return_type (boolean_type_node, TREE_TYPE (fn));
+  apply_deduced_return_type (fn, boolean_type_node);
   return fn;
 }
 
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 9401b35a789..ab52e56d6c1 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12325,24 +12325,23 @@ apply_deduced_return_type (tree fco, tree return_type)
   /* We already have a DECL_RESULT from start_preparsed_function.
  Now we need to redo the work it and allocate_struct_function
  did to reflect the new type.  */
-  gcc_assert (current_function_decl == fco);
-  result = build_decl (input_location, RESULT_DECL, NULL_TREE,
+  result = build_decl (DECL_SOURCE_LOCATION (result), RESULT_DECL, NULL_TREE,
 		   TYPE_MAIN_VARIANT 

[PATCH trunk] [PR104308] [analyzer] handle memmove like memcpy

[David Malcolm via Gcc-patches]

On Fri, 2022-12-02 at 06:45 -0300, Alexandre Oliva wrote:
> Hello, David,
> 
> I'd written this patch for gcc-12, but you've worked too much on the
> analyzer ;-) for it to apply in the trunk.  I wonder if there's any
> use
> you can make of it, or of the observations in it, or whether you'd
> prefer me to try to port it.
> 
> I've regstrapped it on x86_64-linux-gnu, and also tested with crosses
> to
> riscv64-elf and arm-eabi, but with gcc-12 only, so I'm hesitant to
> ask
> whether it's ok to install.  Trunk still fails to issue the warning
> for
> memmove on riscv64-elf.
> 
> 
> The testcase expects analyzer warnings for memmove just like for
> memcpy.  We get them when memmove is open-coded, but not when it
> remains a call.
> 
> The analyzer has code to handle memcpy calls, whose logic can be
> trivially reused for memmove, but we don't get the expected warnings
> and notes for memmove on riscv64-*-elf.  They wouldn't be issued for
> memcpy either, if it wasn't open-coded.
> 
> I've managed to find out how to get the warning for the
> remaining-call
> variants, but not to get the note issued for the point of creation of
> the uninitialized buffer, so this patch also adds an xfail for the
> note on riscv*-*-*.

Hi Alex,

There are various functions that the analyzer "knows" about, but in
gcc 12 and earlier, the logic for handling them was rather messy with
lots of inconsistencies and places for bugs to hide.

In trunk, I've tidied this up by adding a
  class known_function
so that the handling for "foo" that was:
  region_model::impl_call_foo
becomes a
  class kf_foo : public known_function
subclass instead, which has responsibility for determining the
outcome(s) of a particular call.  Instances get registered into a
known_function_manager, which has responsibility for identifying which
known_function instance is relevant at the call site.

This makes the logic simpler and more consistent.

I had a go at porting your patch to trunk; here's the result.
I added explicit testing of memmove, which I like to do any time I add
a new known_function registration.

Only lightly tested so far, on x86_64-pc-linux-gnu.

Does this do what you wanted?

Ultimately I want to add a warning for memcpy of overlapping regions, of
course.

Thanks
Dave

gcc/analyzer/ChangeLog:
* region-model-impl-calls.cc (class kf_memcpy): Rename to...
(class kf_memcpy_memmove): ...this.
(kf_memcpy::impl_call_pre): Rename to...
(kf_memcpy_memmove::impl_call_pre): ...this, and check the src for
poison.
(register_known_functions): Update for above renaming, and
register BUILT_IN_MEMMOVE and BUILT_IN_MEMMOVE_CHK.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/memmove-1.c: New test, based on memcpy-1.c
* gcc.dg/analyzer/pr104308.c (test_memmove_within_uninit):
Expect creation point note to be missing on riscv*-*-*.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/region-model-impl-calls.cc   |  18 ++-
 gcc/testsuite/gcc.dg/analyzer/memmove-1.c | 168 ++
 gcc/testsuite/gcc.dg/analyzer/pr104308.c  |   2 +-
 3 files changed, 181 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/memmove-1.c

diff --git a/gcc/analyzer/region-model-impl-calls.cc 
b/gcc/analyzer/region-model-impl-calls.cc
index 8ba644c33cd..103aed58138 100644
--- a/gcc/analyzer/region-model-impl-calls.cc
+++ b/gcc/analyzer/region-model-impl-calls.cc
@@ -772,10 +772,12 @@ kf_malloc::impl_call_pre (const call_details ) const
 }
 }
 
-/* Handler for "memcpy" and "__builtin_memcpy".  */
-// TODO: complain about overlapping src and dest.
+/* Handler for "memcpy" and "__builtin_memcpy",
+   "memmove", and "__builtin_memmove".  */
+/* TODO: complain about overlapping src and dest for the memcpy
+   variants.  */
 
-class kf_memcpy : public known_function
+class kf_memcpy_memmove : public known_function
 {
 public:
   bool matches_call_types_p (const call_details ) const final override
@@ -789,7 +791,7 @@ public:
 };
 
 void
-kf_memcpy::impl_call_pre (const call_details ) const
+kf_memcpy_memmove::impl_call_pre (const call_details ) const
 {
   const svalue *dest_ptr_sval = cd.get_arg_svalue (0);
   const svalue *src_ptr_sval = cd.get_arg_svalue (1);
@@ -811,6 +813,8 @@ kf_memcpy::impl_call_pre (const call_details ) const
 = mgr->get_sized_region (dest_reg, NULL_TREE, num_bytes_sval);
   const svalue *src_contents_sval
 = model->get_store_value (sized_src_reg, cd.get_ctxt ());
+  model->check_for_poison (src_contents_sval, cd.get_arg_tree (1),
+  cd.get_ctxt ());
   model->set_value (sized_dest_reg, src_contents_sval, cd.get_ctxt ());
 }
 
@@ -1505,8 +1509,10 @@ register_known_functions (known_function_manager )
 kfm.add (BUILT_IN_EXPECT_WITH_PROBABILITY, make_unique ());
 kfm.add (BUILT_IN_FREE, make_unique ());
 kfm.add (BUILT_IN_MALLOC, make_unique ());
-kfm.add (BUILT_IN_MEMCPY, make_unique ());
-kfm.add 

[PATCH] c++: substituting CONST_DECL_USING_P enumerator [PR103081]

[Patrick Palka via Gcc-patches]

We implement using enum at class scope by injecting clones of the enum's
CONST_DECLs as fields of the class, for which CONST_DECL_USING_P is
true, so that qualified lookup naturally finds the enumerators.
Substitution into such a CONST_DECL currently ICEs however, because we
assume the DECL_CONTEXT is always the ENUMERAL_TYPE (which has TYPE_VALUES)
but in this case it's the RECORD_TYPE of the class scope (which has
TYPE_FIELDS).

Since these CONST_DECLs appear to always be non-dependent, this patch
fixes this by shortcutting substitution for CONST_DECLs which have a
non-dependent scope.  This subsumes the existing (and seemingly dead)
DECL_NAMESPACE_SCOPE_P early exit test and also benefits substitution
into ordinary non-dependent CONST_DECLs.

Bootstrapped and regtested on x86_64-pc-linu-xgnu, does this look OK for
trunk/12?

PR c++/103081

gcc/cp/ChangeLog:

* pt.cc (tsubst_copy) : Generalize
early exit test for namespace-scope decls to check dependence of
the enclosing scope instead.  Remove dead args early exit test.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/using-enum-10.C: New test.
* g++.dg/cpp2a/using-enum-10a.C: New test.
---
 gcc/cp/pt.cc|  7 +--
 gcc/testsuite/g++.dg/cpp2a/using-enum-10.C  | 16 
 gcc/testsuite/g++.dg/cpp2a/using-enum-10a.C | 18 ++
 3 files changed, 35 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/using-enum-10.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/using-enum-10a.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 31691618d1b..bc8ea06ceae 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -17066,13 +17066,8 @@ tsubst_copy (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
 
if (DECL_TEMPLATE_PARM_P (t))
  return tsubst_copy (DECL_INITIAL (t), args, complain, in_decl);
-   /* There is no need to substitute into namespace-scope
-  enumerators.  */
-   if (DECL_NAMESPACE_SCOPE_P (t))
+   if (!uses_template_parms (DECL_CONTEXT (t)))
  return t;
-   /* If ARGS is NULL, then T is known to be non-dependent.  */
-   if (args == NULL_TREE)
- return scalar_constant_value (t);
 
/* Unfortunately, we cannot just call lookup_name here.
   Consider:
diff --git a/gcc/testsuite/g++.dg/cpp2a/using-enum-10.C 
b/gcc/testsuite/g++.dg/cpp2a/using-enum-10.C
new file mode 100644
index 000..98fe0644729
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/using-enum-10.C
@@ -0,0 +1,16 @@
+// PR c++/103081
+// { dg-do compile { target c++20 } }
+
+enum class Pig { OINK };
+
+struct Hog {
+  using enum Pig;
+  Hog(Pig) { }
+};
+
+template
+void pen() {
+  Hog(Hog::OINK);
+}
+
+template void pen<0>();
diff --git a/gcc/testsuite/g++.dg/cpp2a/using-enum-10a.C 
b/gcc/testsuite/g++.dg/cpp2a/using-enum-10a.C
new file mode 100644
index 000..43688e69b19
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/using-enum-10a.C
@@ -0,0 +1,18 @@
+// A version of using-enum-10.C where Hog is a template.
+// PR c++/103081
+// { dg-do compile { target c++20 } }
+
+enum class Pig { OINK };
+
+template
+struct Hog {
+  using enum Pig;
+  Hog(Pig) { OINK; }
+};
+
+template
+void pen() {
+  Hog(Hog::OINK);
+}
+
+template void pen<0>();
-- 
2.39.0.rc0.49.g083e01275b

Ping #3: [PATCH 3/3] Update float 128-bit conversions, PR target/107299.

[Michael Meissner via Gcc-patches]

Ping for patches submitted on November 1st.  These 3 patches are needed to be
able to build GCC for PowerPC target systems where long double is configured to
be IEEE 128-bit, such as Fedora 36.

This is the 3rd of 3 patches.

| Date: Tue, 1 Nov 2022 22:44:01 -0400
| Subject: [PATCH 3/3] Update float 128-bit conversions, PR target/107299.
| Message-ID: 
| https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604837.html

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

Ping #3: [PATCH 2/3] Make __float128 use the _Float128 type, PR target/107299

[Michael Meissner via Gcc-patches]

Ping for patches submitted on November 1st.  These 3 patches are needed to be
able to build GCC for PowerPC target systems where long double is configured to
be IEEE 128-bit, such as Fedora 36.

This is for the 2nd of 3 patches.

| Date: Tue, 1 Nov 2022 22:42:30 -0400
| Subject: [PATCH 2/3] Make __float128 use the _Float128 type, PR target/107299
| Message-ID: 
| https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604836.html

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

Ping #3: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR target/107299

[Michael Meissner via Gcc-patches]

Ping for patches submitted on November 1st.  These 3 patches are needed to be
able to build GCC for PowerPC target systems where long double is configured to
be IEEE 128-bit, such as Fedora 36.

This is the first patch of 3 patches.

| Date: Tue, 1 Nov 2022 22:40:43 -0400
| Subject: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR 
target/107299
| Message-ID: 
| https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604835.html

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

[PATCH 1/2] select .rodata for const volatile variables.

[Cupertino Miranda via Gcc-patches]

Changed target code to select .rodata section for 'const volatile'
defined variables.
This change is in the context of the bugzilla #170181.

gcc/ChangeLog:

v850.c(v850_select_section): Changed function.
---
 gcc/config/v850/v850.cc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/config/v850/v850.cc b/gcc/config/v850/v850.cc
index c7d432990ab..e66893fede4 100644
--- a/gcc/config/v850/v850.cc
+++ b/gcc/config/v850/v850.cc
@@ -2865,7 +2865,6 @@ v850_select_section (tree exp,
 {
   int is_const;
   if (!TREE_READONLY (exp)
- || TREE_SIDE_EFFECTS (exp)
  || !DECL_INITIAL (exp)
  || (DECL_INITIAL (exp) != error_mark_node
  && !TREE_CONSTANT (DECL_INITIAL (exp
-- 
2.30.2

[PATCH 2/2] Corrected pr25521.c target matching.

[Cupertino Miranda via Gcc-patches]

This commit is a follow up of bugzilla #107181.

The commit /a0aafbc/ changed the default implementation of the
SELECT_SECTION hook in order to match clang/llvm behaviour w.r.t the
placement of `const volatile' objects.

However, the following targets use target-specific selection functions
and they choke on the testcase pr25521.c:

 *rx - target sets its const variables as '.section C,"a",@progbits'.

 *powerpc - its 32bit version is eager to allocate globals in .sdata
sections.

Normally, one can expect for the variable to be allocated in .srodata,
however, in case of powerpc-*-* or powerpc64-*-* (with -m32)
'targetm.have_srodata_section == false' and the code in
categorize_decl_for_section(varasm.cc), forces it to allocate in .sdata.

  /* If the target uses small data sections, select it.  */
  else if (targetm.in_small_data_p (decl))
{
  if (ret == SECCAT_BSS)
ret = SECCAT_SBSS;
  else if targetm.have_srodata_section && ret == SECCAT_RODATA)
ret = SECCAT_SRODATA;
  else
ret = SECCAT_SDATA;
}

LLVM compiler does not generate .sdata symbols at all, having different code
generation even for non const volatile symbols.
Targets that for acceptable reasons could not match the LLVM generated code
were marked as XFAIL.

gcc/testsuite/ChangeLog:

* lib/target-supports.exp: Added
  check_effective_target_const_volatile_readonly_section.
* gcc.dg/pr25521.c: Added XFAIL.
---
 gcc/testsuite/gcc.dg/pr25521.c|  3 +--
 gcc/testsuite/lib/target-supports.exp | 12 
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/pr25521.c b/gcc/testsuite/gcc.dg/pr25521.c
index 63363a03b9f..597a2fc25d8 100644
--- a/gcc/testsuite/gcc.dg/pr25521.c
+++ b/gcc/testsuite/gcc.dg/pr25521.c
@@ -6,5 +6,4 @@
 
 const volatile int foo = 30;
 
-
-/* { dg-final { scan-assembler "\\.s\?rodata" } } */
+/* { dg-final { scan-assembler-symbol-section {^_?foo$} {^\.(const|s?rodata)} 
{ xfail { ! const_volatile_readonly_section } } } } */
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 2a058c67c53..631d4593447 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -12196,3 +12196,15 @@ proc check_is_prog_name_available { prog } {
 
 return 1
 }
+
+# returns 1 if target does selects a readonly section for const volatile 
variables.
+proc check_effective_target_const_volatile_readonly_section { } {
+
+if { [istarget rx*-*-*]
+ || [istarget powerpc-*-*]
+ || [istarget rs6000*-*-*]
+ || [check-flags { "" { powerpc64-*-* } { -m32 } }] } {
+   return 0
+}
+  return 1
+}
-- 
2.30.2

[PATCH] `const volatile' sections selection - bugzilla #107181

[Cupertino Miranda via Gcc-patches]

Hi everyone,

Recently I looked over the issue reported in bugzilla #107181, related
to commit `a0aafbc'.

The commit changes the object section for `const volatile' objects.
However it does it only for the targets using the default section
selection hook.
The included patches addresses all the architectures that define a custom
section select by verifying its result against pr25521.c test.

>From all architectures verified only powerpc and v850 seem to be having
a non-default behaviour and required changes.

- v850_select_section was changed to follow the behaviour the default
  select_section hook.
- powerpc only has issues in 32bit, since the compiler is eager to
  allocate the simple const volatile object in small data section, 
  which does not appear to have a readonly counter-part support.
  Please find more details in the patch commit message.

Looking forward to your review.

Best regards,
Cupertino Miranda

Re: [PATCH] Fix a few incorrect accesses.

[Andrew MacLeod via Gcc-patches]

On 12/2/22 09:52, Richard Biener wrote:

On Fri, Dec 2, 2022 at 3:13 PM Andrew MacLeod via Gcc-patches
 wrote:

This consists of 3 changes which stronger type checking has indicated
are non-compliant with the type field.

I doubt they are super important because there has not been a trap
triggered by them, and they have been in the source base since sometime
before 2017.  However, we should probably fix them.

I also notice that those are all uses of VOID_TYPE_P, which
coincidentally does not check if its a type node being checked:

 /* Nonzero if this type is the (possibly qualified) void type.  */
 #define VOID_TYPE_P(NODE) (TREE_CODE (NODE) == VOID_TYPE)

So I guess it wouldn't trap anyway, just silently never trigger.

Bootstraps on x86_64-pc-linux-gnu with no regressions.  OK for trunk?

LGTM.


Pushed as commit 76dd48f8956b5e17adf0ae1cd1ed3d804a005470

Andrew

Re: [PATCH][OG12] amdgcn: Support AMD-specific 'isa' and 'arch' traits in OpenMP context selectors

[Kwok Cheung Yeung]

So this is the OG12-specific part (including metadirective and dynamic 
context selectors) of the previous patch.


Once https://gcc.gnu.org/r13-4446-ge41b243302e996 is backported, is it 
OK for OG12?


Looks good to me, thanks!

Kwok

Re: [PATCH] [OpenMP] GC unused SIMD clones

[Jakub Jelinek via Gcc-patches]

On Thu, Nov 24, 2022 at 07:13:38PM -0700, Sandra Loosemore wrote:
> This patch is a followup to my not-yet-reviewed patch
> 
> [PATCH v4] OpenMP: Generate SIMD clones for functions with "declare target"
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606218.html
> 
> In comments on a previous iteration of that patch, I was asked to do
> something to delete unused SIMD clones to avoid code bloat; this is it.
> 
> I've implemented something like a simple mark-and-sweep algorithm. Clones
> that are used are marked at the point where the call is generated in the
> vectorizer.  The loop that iterates over functions to apply the passes after
> IPA is modified to defer processing of unmarked clones, and anything left
> over is deleted.
> 
> OK to commit this along with the above-linked patch?

I think you want Honza to review this.

Jakub

Re: [PATCH] c++: explicit spec of constrained member tmpl [PR107522]

[Jason Merrill via Gcc-patches]

On 12/2/22 09:30, Patrick Palka wrote:

On Thu, 1 Dec 2022, Jason Merrill wrote:


On 12/1/22 14:51, Patrick Palka wrote:

On Thu, 1 Dec 2022, Jason Merrill wrote:


On 12/1/22 11:37, Patrick Palka wrote:

When defining a explicit specialization of a constrained member template
(of a class template) such as f and g in the below testcase, the
DECL_TEMPLATE_PARMS of the corresponding TEMPLATE_DECL are partially
instantiated, whereas its associated constraints are carried over
from the original template and thus are in terms of the original
DECL_TEMPLATE_PARMS.


But why are they carried over?  We wrote a specification of the
constraints in
terms of the template parameters of the specialization, why are we
throwing
that away?


Using the partially instantiated constraints would require adding a
special case to satisfaction since during satisfaction we currently
always use the full set of template arguments (relative to the most
general template).


But not for partial specializations, right?  It seems natural to handle this
explicit instantiation the way we handle partial specializations, as both have
their constraints written in terms of their template parameters.


True, but what about the general rule that we don't partially instantiate
constraints outside of declaration matching?  Checking satisfaction of
partially instantiated constraints here can introduce hard errors during
normalization, e.g.

   template
   concept C1 = __same_as(T, void);

   template
   concept C2 = C1;

   template
   concept D = (N == 42);

   template
   struct A {
 template
 static void f() requires C2 || D;
   };

   template<>
   template
   void A::f() requires C2 || D { }

   int main() {
 A::f<42>();
   }

Normalization of the the partially instantiated constraints will give a
hard error due to 'int::type' being ill-formed, whereas the uninstantiated
constraints are fine.


Hmm, interesting point, but in this example that happens because the 
specialization is nonsensical: we wouldn't be normalizing the 
partially-instantiated constraints so much as the ones that the user 
explicitly wrote, so a hard error seems justified.



For satisfaction of the partially instantiated
constraints, we'd instead have to use the template arguments relative to
the explicit specialization, e.g. {42} instead of {{int},{42}} for
A::f<42>.  Not sure if that would be preferable, but it seems
doable.




So during normalization for such an explicit
specialization we need to consider the (parameters of) the most general
template, since that's what the constraints are in terms of and since we
always use the full set of template arguments during satisfaction.

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

PR c++/107522

gcc/cp/ChangeLog:

* constraint.cc (get_normalized_constraints_from_decl): Use the
most general template for an explicit specialization of a
member template.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-explicit-spec7.C: New test.
---
gcc/cp/constraint.cc  | 18 ---
.../g++.dg/cpp2a/concepts-explicit-spec7.C| 31
+++
2 files changed, 44 insertions(+), 5 deletions(-)
create mode 100644
gcc/testsuite/g++.dg/cpp2a/concepts-explicit-spec7.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index ab0f66b3d7e..f1df84c2a1c 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -973,11 +973,19 @@ get_normalized_constraints_from_decl (tree d, bool
diag = false)
 accepting the latter causes the template parameter level of U
 to be reduced in a way that makes it overly difficult substitute
 concrete arguments (i.e., eventually {int, int} during
satisfaction.
*/
-  if (tmpl)
-  {
-if (DECL_LANG_SPECIFIC(tmpl) && !DECL_TEMPLATE_SPECIALIZATION
(tmpl))
-  tmpl = most_general_template (tmpl);
-  }
+  if (tmpl && DECL_LANG_SPECIFIC (tmpl)
+  && (!DECL_TEMPLATE_SPECIALIZATION (tmpl)
+ /* DECL_TEMPLATE_SPECIALIZATION means we're dealing with either a
+partial specialization or an explicit specialization of a member
+template.  In the former case all is well: the constraints are in
+terms in TMPL's parameters.  But in the latter case TMPL's
+parameters are partially instantiated whereas its constraints
+aren't, so we need to consider (the parameters of) the most
+general template.  The following test distinguishes between a
+partial specialization and such an explicit specialization.  */
+ || (TMPL_PARMS_DEPTH (DECL_TEMPLATE_PARMS (tmpl))
+ < TMPL_ARGS_DEPTH (DECL_TI_ARGS (tmpl)
+tmpl = most_general_template (tmpl);
d = tmpl ? tmpl : decl;
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-explicit-spec7.C
b/gcc/testsuite/g++.dg/cpp2a/concepts-explicit-spec7.C
new file mode 100644
index 

[PATCH RFA(tree)] c++: source position of lambda captures [PR84471]

[Jason Merrill via Gcc-patches]

Tested x86_64-pc-linux-gnu, OK for trunk?

-- 8< --

If the DECL_VALUE_EXPR of a VAR_DECL has EXPR_LOCATION set, then any use of
that variable looks like it has that location, which leads to the debugger
jumping back and forth for both lambdas and structured bindings.

Rather than fix all the uses, it seems simplest to remove any EXPR_LOCATION
when setting DECL_VALUE_EXPR.  So the cp/ hunks aren't necessary, but it
seems cleaner not to work to add a location that will immediately get
stripped.

PR c++/84471
PR c++/107504

gcc/cp/ChangeLog:

* coroutines.cc (transform_local_var_uses): Don't
specify a location for DECL_VALUE_EXPR.
* decl.cc (cp_finish_decomp): Likewise.

gcc/ChangeLog:

* tree.cc (decl_value_expr_insert): Clear EXPR_LOCATION.

gcc/testsuite/ChangeLog:

* g++.dg/tree-ssa/value-expr1.C: New test.
* g++.dg/tree-ssa/value-expr2.C: New test.
* g++.dg/analyzer/pr93212.C: Move warning.
---
 gcc/cp/coroutines.cc|  4 ++--
 gcc/cp/decl.cc  | 12 +++---
 gcc/testsuite/g++.dg/analyzer/pr93212.C |  4 ++--
 gcc/testsuite/g++.dg/tree-ssa/value-expr1.C | 16 +
 gcc/testsuite/g++.dg/tree-ssa/value-expr2.C | 26 +
 gcc/tree.cc |  3 +++
 6 files changed, 52 insertions(+), 13 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/tree-ssa/value-expr1.C
 create mode 100644 gcc/testsuite/g++.dg/tree-ssa/value-expr2.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 01a3e831ee5..a72bd6bbef0 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -2047,8 +2047,8 @@ transform_local_var_uses (tree *stmt, int *do_subtree, 
void *d)
= lookup_member (lvd->coro_frame_type, local_var.field_id,
 /*protect=*/1, /*want_type=*/0,
 tf_warning_or_error);
- tree fld_idx = build3_loc (lvd->loc, COMPONENT_REF, TREE_TYPE (lvar),
-lvd->actor_frame, fld_ref, NULL_TREE);
+ tree fld_idx = build3 (COMPONENT_REF, TREE_TYPE (lvar),
+lvd->actor_frame, fld_ref, NULL_TREE);
  local_var.field_idx = fld_idx;
  SET_DECL_VALUE_EXPR (lvar, fld_idx);
  DECL_HAS_VALUE_EXPR_P (lvar) = true;
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 7af0b05d5f8..59e21581503 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -9133,9 +9133,7 @@ cp_finish_decomp (tree decl, tree first, unsigned int 
count)
  if (processing_template_decl)
continue;
  tree t = unshare_expr (dexp);
- t = build4_loc (DECL_SOURCE_LOCATION (v[i]), ARRAY_REF,
- eltype, t, size_int (i), NULL_TREE,
- NULL_TREE);
+ t = build4 (ARRAY_REF, eltype, t, size_int (i), NULL_TREE, NULL_TREE);
  SET_DECL_VALUE_EXPR (v[i], t);
  DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
}
@@ -9154,9 +9152,7 @@ cp_finish_decomp (tree decl, tree first, unsigned int 
count)
  if (processing_template_decl)
continue;
  tree t = unshare_expr (dexp);
- t = build1_loc (DECL_SOURCE_LOCATION (v[i]),
- i ? IMAGPART_EXPR : REALPART_EXPR, eltype,
- t);
+ t = build1 (i ? IMAGPART_EXPR : REALPART_EXPR, eltype, t);
  SET_DECL_VALUE_EXPR (v[i], t);
  DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
}
@@ -9180,9 +9176,7 @@ cp_finish_decomp (tree decl, tree first, unsigned int 
count)
  tree t = unshare_expr (dexp);
  convert_vector_to_array_for_subscript (DECL_SOURCE_LOCATION (v[i]),
 , size_int (i));
- t = build4_loc (DECL_SOURCE_LOCATION (v[i]), ARRAY_REF,
- eltype, t, size_int (i), NULL_TREE,
- NULL_TREE);
+ t = build4 (ARRAY_REF, eltype, t, size_int (i), NULL_TREE, NULL_TREE);
  SET_DECL_VALUE_EXPR (v[i], t);
  DECL_HAS_VALUE_EXPR_P (v[i]) = 1;
}
diff --git a/gcc/testsuite/g++.dg/analyzer/pr93212.C 
b/gcc/testsuite/g++.dg/analyzer/pr93212.C
index 41507e2b837..1029e8d547b 100644
--- a/gcc/testsuite/g++.dg/analyzer/pr93212.C
+++ b/gcc/testsuite/g++.dg/analyzer/pr93212.C
@@ -4,8 +4,8 @@
 auto lol()
 {
 int aha = 3;
-return [] { // { dg-warning "dereferencing pointer '.*' to within 
stale stack frame" }
-return aha;
+return [] {
+return aha; // { dg-warning "dereferencing pointer '.*' to within 
stale stack frame" }
 };
 /* TODO: may be worth special-casing the reporting of dangling
references from lambdas, to highlight the declaration, and maybe fix
diff --git a/gcc/testsuite/g++.dg/tree-ssa/value-expr1.C 
b/gcc/testsuite/g++.dg/tree-ssa/value-expr1.C
new file mode 100644
index 000..946ccc3bd97
--- /dev/null
+++ 

Re: [PATCH] Fix a few incorrect accesses.

[Richard Biener via Gcc-patches]

On Fri, Dec 2, 2022 at 3:13 PM Andrew MacLeod via Gcc-patches
 wrote:
>
> This consists of 3 changes which stronger type checking has indicated
> are non-compliant with the type field.
>
> I doubt they are super important because there has not been a trap
> triggered by them, and they have been in the source base since sometime
> before 2017.  However, we should probably fix them.
>
> I also notice that those are all uses of VOID_TYPE_P, which
> coincidentally does not check if its a type node being checked:
>
> /* Nonzero if this type is the (possibly qualified) void type.  */
> #define VOID_TYPE_P(NODE) (TREE_CODE (NODE) == VOID_TYPE)
>
> So I guess it wouldn't trap anyway, just silently never trigger.
>
> Bootstraps on x86_64-pc-linux-gnu with no regressions.  OK for trunk?

LGTM.

> Andrew

Re: [V2][PATCH 1/1] Add a new warning option -Wstrict-flex-arrays.

[Qing Zhao via Gcc-patches]

> On Dec 2, 2022, at 2:20 AM, Richard Biener  wrote:
> 
> On Fri, 2 Dec 2022, Richard Biener wrote:
> 
>> On Thu, 1 Dec 2022, Siddhesh Poyarekar wrote:
>> 
>>> On 2022-12-01 11:42, Kees Cook wrote:
 On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
> '-Wstrict-flex-arrays'
>  Warn about inproper usages of flexible array members according to
>  the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
>  the trailing array field of a structure if it's available,
>  otherwise according to the LEVEL of the option
>  '-fstrict-flex-arrays=LEVEL'.
> 
>  This option is effective only when LEVEL is bigger than 0.
>  Otherwise, it will be ignored with a warning.
> 
>  when LEVEL=1, warnings will be issued for a trailing array
>  reference of a structure that have 2 or more elements if the
>  trailing array is referenced as a flexible array member.
> 
>  when LEVEL=2, in addition to LEVEL=1, additional warnings will be
>  issued for a trailing one-element array reference of a structure if
>  the array is referenced as a flexible array member.
> 
>  when LEVEL=3, in addition to LEVEL=2, additional warnings will be
>  issued for a trailing zero-length array reference of a structure if
>  the array is referenced as a flexible array member.
> 
> At the same time, -Warray-bounds is updated:
 
 Why is there both -Wstrict-flex-arrays and -Warray-bounds? I thought
 only the latter was going to exist?
>> 
>> Sorry for appearantly not being clear - I was requesting 
>> -Wstrict-flex-arrays to be dropped and instead adjusting -Warray-bounds
>> to adhere to -fstrict-flex-arrays in both =1 and =2 where then =2
>> would only add the intermediate pointer results verification.
>> 
>> I think that's reasonable if documented since the default behavior
>> with -Wall will not change then unless the -fstrict-flex-arrays
>> default is altered.
> 
> Btw, your patch seems to implement the above plus adds 
> -Wstrict-flex-arrays.  It seems it could be split into two, doing
> the -Warray-bounds adjustment as first and the -Wstrict-flex-arrays 
> addition as second.

Yes, implementation should be very easy to be adjusted to drop the new 
-Wstrict-flex-arrays option.
But I still feel the new -Wstrict-flex-arrays option is good to add.

Qing
>  We do all seem to agree on the first so it's easy
> to go forward with that?
> 
> Thanks,
> Richard.

Re: [V2][PATCH 1/1] Add a new warning option -Wstrict-flex-arrays.

[Qing Zhao via Gcc-patches]

> On Dec 2, 2022, at 2:16 AM, Richard Biener  wrote:
> 
> On Thu, 1 Dec 2022, Siddhesh Poyarekar wrote:
> 
>> On 2022-12-01 11:42, Kees Cook wrote:
>>> On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
 '-Wstrict-flex-arrays'
  Warn about inproper usages of flexible array members according to
  the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
  the trailing array field of a structure if it's available,
  otherwise according to the LEVEL of the option
  '-fstrict-flex-arrays=LEVEL'.
 
  This option is effective only when LEVEL is bigger than 0.
  Otherwise, it will be ignored with a warning.
 
  when LEVEL=1, warnings will be issued for a trailing array
  reference of a structure that have 2 or more elements if the
  trailing array is referenced as a flexible array member.
 
  when LEVEL=2, in addition to LEVEL=1, additional warnings will be
  issued for a trailing one-element array reference of a structure if
  the array is referenced as a flexible array member.
 
  when LEVEL=3, in addition to LEVEL=2, additional warnings will be
  issued for a trailing zero-length array reference of a structure if
  the array is referenced as a flexible array member.
 
 At the same time, -Warray-bounds is updated:
>>> 
>>> Why is there both -Wstrict-flex-arrays and -Warray-bounds? I thought
>>> only the latter was going to exist?
> 
> Sorry for appearantly not being clear - I was requesting 
> -Wstrict-flex-arrays to be dropped and instead adjusting -Warray-bounds
> to adhere to -fstrict-flex-arrays in both =1 and =2 where then =2
> would only add the intermediate pointer results verification.

So, you suggested to drop the new option -Wstrict-flex-arrays?
How about the new warnings on the misuse of flex arrays? Shall we drop them too?
Or we issue such new warnings with  -Warray-bounds + -fstrict-flex-arrays=N?

I still think that the new -Wstrict-flex-arrays to only issue the misuse of 
flex arrays is necessary to add.
Otherwise, such warning messages will be buried among a lot of out-of-bounds 
warnings.
> 
> I think that's reasonable if documented since the default behavior
> with -Wall will not change then unless the -fstrict-flex-arrays
> default is altered.
Yes, the default behavior for -Wall, or  -Warray-bounds are not changed.

Qing
> 
>> Oh my understanding of the consensus was to move flex array related diagnosis
>> from -Warray-bounds to -Wstring-flex-arrays as Qing has done. If only the
>> former exists then instead of removing the flex array related statement in 
>> the
>> documentation as Richard suggested, we need to enhance it to say that
>> behaviour of -Warray-bounds will depend on -fstrict-flex-arrays.
>> 
>> -Warray-bounds does diagnosis beyond just flexible arrays, in case that's the
>> confusion.
> 
> Richard.
> 
> -- 
> Richard Biener 
> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
> Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
> HRB 36809 (AG Nuernberg)

[PATCH] tree-optimization/107833 - invariant motion of uninit uses

[Richard Biener via Gcc-patches]

The following fixes a wrong-code bug caused by loop invariant motion
hoisting an expression using an uninitialized value outside of its
controlling condition causing IVOPTs to use that to rewrite a defined
value.  PR107839 is a similar case involving a bogus uninit diagnostic.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

OK?

Thanks,
Richard.

PR tree-optimization/107833
PR tree-optimization/107839
* cfghooks.cc: Include tree.h.
* tree-ssa-loop-im.cc (movement_possibility): Wrap and
make stmts using any ssa_name_maybe_undef_p operand
to preserve execution.
(loop_invariant_motion_in_fun): Call mark_ssa_maybe_undefs
to init maybe-undefined status.
* tree-ssa-loop-ivopts.cc (ssa_name_maybe_undef_p,
ssa_name_set_maybe_undef, ssa_name_any_use_dominates_bb_p,
mark_ssa_maybe_undefs): Move ...
* tree-ssa.cc: ... here.
* tree-ssa.h (ssa_name_any_use_dominates_bb_p,
mark_ssa_maybe_undefs): Declare.
(ssa_name_maybe_undef_p, ssa_name_set_maybe_undef): Define.

* gcc.dg/torture/pr107833.c: New testcase.
* gcc.dg/uninit-pr107839.c: Likewise.
---
 gcc/cfghooks.cc |   1 +
 gcc/testsuite/gcc.dg/torture/pr107833.c |  33 +++
 gcc/testsuite/gcc.dg/uninit-pr107839.c  |  13 +++
 gcc/tree-ssa-loop-im.cc |  22 -
 gcc/tree-ssa-loop-ivopts.cc | 111 
 gcc/tree-ssa.cc |  93 
 gcc/tree-ssa.h  |  25 ++
 7 files changed, 186 insertions(+), 112 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr107833.c
 create mode 100644 gcc/testsuite/gcc.dg/uninit-pr107839.c

diff --git a/gcc/cfghooks.cc b/gcc/cfghooks.cc
index 29ded570734..f8fa13c1d69 100644
--- a/gcc/cfghooks.cc
+++ b/gcc/cfghooks.cc
@@ -29,6 +29,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "diagnostic-core.h"
 #include "dumpfile.h"
 #include "cfganal.h"
+#include "tree.h"
 #include "tree-ssa.h"
 #include "cfgloop.h"
 #include "sreal.h"
diff --git a/gcc/testsuite/gcc.dg/torture/pr107833.c 
b/gcc/testsuite/gcc.dg/torture/pr107833.c
new file mode 100644
index 000..0edf7c328ba
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr107833.c
@@ -0,0 +1,33 @@
+/* { dg-do run } */
+
+int a, b[1] = { 0 }, c, *d = b, e, *f, g;
+
+__attribute__((noipa)) int
+foo (const char *x)
+{
+  (void) x;
+  return 0;
+}
+
+int
+main ()
+{
+  for (int h = 0; a < 2; a++)
+{
+  int i;
+  for (g = 0; g < 2; g++)
+   if (a < h)
+ {
+   e = i % 2;
+   c = *f;
+ }
+  for (h = 0; h < 3; h++)
+   {
+ if (d)
+   break;
+ i--;
+ foo ("0");
+   }
+}
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/uninit-pr107839.c 
b/gcc/testsuite/gcc.dg/uninit-pr107839.c
new file mode 100644
index 000..c2edcfaee22
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/uninit-pr107839.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -Wuninitialized" } */
+
+int f (int);
+void g (int c)
+{
+  int v;
+  if (c)
+v = f(0);
+  while (1)
+if (c)
+  f(v + v); /* { dg-bogus "uninitialized" } */ 
+}
diff --git a/gcc/tree-ssa-loop-im.cc b/gcc/tree-ssa-loop-im.cc
index 2119d4072d3..b752e46340b 100644
--- a/gcc/tree-ssa-loop-im.cc
+++ b/gcc/tree-ssa-loop-im.cc
@@ -46,6 +46,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "alias.h"
 #include "builtins.h"
 #include "tree-dfa.h"
+#include "tree-ssa.h"
 #include "dbgcnt.h"
 
 /* TODO:  Support for predicated code motion.  I.e.
@@ -332,7 +333,7 @@ enum move_pos
Otherwise return MOVE_IMPOSSIBLE.  */
 
 enum move_pos
-movement_possibility (gimple *stmt)
+static movement_possibility_1 (gimple *stmt)
 {
   tree lhs;
   enum move_pos ret = MOVE_POSSIBLE;
@@ -422,6 +423,23 @@ movement_possibility (gimple *stmt)
   return ret;
 }
 
+enum move_pos
+static movement_possibility (gimple *stmt)
+{
+  enum move_pos pos = movement_possibility_1 (stmt);
+  if (pos == MOVE_POSSIBLE)
+{
+  use_operand_p use_p;
+  ssa_op_iter ssa_iter;
+  FOR_EACH_PHI_OR_STMT_USE (use_p, stmt, ssa_iter, SSA_OP_USE)
+   if (TREE_CODE (USE_FROM_PTR (use_p)) == SSA_NAME
+   && ssa_name_maybe_undef_p (USE_FROM_PTR (use_p)))
+ return MOVE_PRESERVE_EXECUTION;
+}
+  return pos;
+}
+
+
 /* Compare the profile count inequality of bb and loop's preheader, it is
three-state as stated in profile-count.h, FALSE is returned if inequality
cannot be decided.  */
@@ -3532,6 +3550,8 @@ loop_invariant_motion_in_fun (function *fun, bool 
store_motion)
 
   tree_ssa_lim_initialize (store_motion);
 
+  mark_ssa_maybe_undefs ();
+
   /* Gathers information about memory accesses in the loops.  */
   analyze_memory_references (store_motion);
 
diff --git a/gcc/tree-ssa-loop-ivopts.cc b/gcc/tree-ssa-loop-ivopts.cc
index 

Re: [PATCH] c++: explicit spec of constrained member tmpl [PR107522]

[Patrick Palka via Gcc-patches]

On Thu, 1 Dec 2022, Jason Merrill wrote:

> On 12/1/22 14:51, Patrick Palka wrote:
> > On Thu, 1 Dec 2022, Jason Merrill wrote:
> > 
> > > On 12/1/22 11:37, Patrick Palka wrote:
> > > > When defining a explicit specialization of a constrained member template
> > > > (of a class template) such as f and g in the below testcase, the
> > > > DECL_TEMPLATE_PARMS of the corresponding TEMPLATE_DECL are partially
> > > > instantiated, whereas its associated constraints are carried over
> > > > from the original template and thus are in terms of the original
> > > > DECL_TEMPLATE_PARMS.
> > > 
> > > But why are they carried over?  We wrote a specification of the
> > > constraints in
> > > terms of the template parameters of the specialization, why are we
> > > throwing
> > > that away?
> > 
> > Using the partially instantiated constraints would require adding a
> > special case to satisfaction since during satisfaction we currently
> > always use the full set of template arguments (relative to the most
> > general template).
> 
> But not for partial specializations, right?  It seems natural to handle this
> explicit instantiation the way we handle partial specializations, as both have
> their constraints written in terms of their template parameters.

True, but what about the general rule that we don't partially instantiate
constraints outside of declaration matching?  Checking satisfaction of
partially instantiated constraints here can introduce hard errors during
normalization, e.g.

  template
  concept C1 = __same_as(T, void);

  template
  concept C2 = C1;

  template
  concept D = (N == 42);

  template
  struct A {
template
static void f() requires C2 || D;
  };

  template<>
  template
  void A::f() requires C2 || D { }

  int main() {
A::f<42>();
  }

Normalization of the the partially instantiated constraints will give a
hard error due to 'int::type' being ill-formed, whereas the uninstantiated
constraints are fine.

> 
> > For satisfaction of the partially instantiated
> > constraints, we'd instead have to use the template arguments relative to
> > the explicit specialization, e.g. {42} instead of {{int},{42}} for
> > A::f<42>.  Not sure if that would be preferable, but it seems
> > doable.
> > 
> > > 
> > > > So during normalization for such an explicit
> > > > specialization we need to consider the (parameters of) the most general
> > > > template, since that's what the constraints are in terms of and since we
> > > > always use the full set of template arguments during satisfaction.
> > > > 
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > > > trunk and perhaps 12?
> > > > 
> > > > PR c++/107522
> > > > 
> > > > gcc/cp/ChangeLog:
> > > > 
> > > > * constraint.cc (get_normalized_constraints_from_decl): Use the
> > > > most general template for an explicit specialization of a
> > > > member template.
> > > > 
> > > > gcc/testsuite/ChangeLog:
> > > > 
> > > > * g++.dg/cpp2a/concepts-explicit-spec7.C: New test.
> > > > ---
> > > >gcc/cp/constraint.cc  | 18 ---
> > > >.../g++.dg/cpp2a/concepts-explicit-spec7.C| 31
> > > > +++
> > > >2 files changed, 44 insertions(+), 5 deletions(-)
> > > >create mode 100644
> > > > gcc/testsuite/g++.dg/cpp2a/concepts-explicit-spec7.C
> > > > 
> > > > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> > > > index ab0f66b3d7e..f1df84c2a1c 100644
> > > > --- a/gcc/cp/constraint.cc
> > > > +++ b/gcc/cp/constraint.cc
> > > > @@ -973,11 +973,19 @@ get_normalized_constraints_from_decl (tree d, bool
> > > > diag = false)
> > > > accepting the latter causes the template parameter level of U
> > > > to be reduced in a way that makes it overly difficult substitute
> > > > concrete arguments (i.e., eventually {int, int} during
> > > > satisfaction.
> > > > */
> > > > -  if (tmpl)
> > > > -  {
> > > > -if (DECL_LANG_SPECIFIC(tmpl) && !DECL_TEMPLATE_SPECIALIZATION
> > > > (tmpl))
> > > > -  tmpl = most_general_template (tmpl);
> > > > -  }
> > > > +  if (tmpl && DECL_LANG_SPECIFIC (tmpl)
> > > > +  && (!DECL_TEMPLATE_SPECIALIZATION (tmpl)
> > > > + /* DECL_TEMPLATE_SPECIALIZATION means we're dealing with 
> > > > either a
> > > > +partial specialization or an explicit specialization of a 
> > > > member
> > > > +template.  In the former case all is well: the constraints 
> > > > are in
> > > > +terms in TMPL's parameters.  But in the latter case TMPL's
> > > > +parameters are partially instantiated whereas its 
> > > > constraints
> > > > +aren't, so we need to consider (the parameters of) the most
> > > > +general template.  The following test distinguishes 
> > > > between a
> > > > +partial specialization and such an explicit 
> > > > specialization.  */
> > > > + || (TMPL_PARMS_DEPTH 

Re: [PATCH] libgccjit: Fix float vector comparison

[Antoni Boucher via Gcc-patches]

On Thu, 2022-12-01 at 11:57 -0500, David Malcolm wrote:
> On Thu, 2022-12-01 at 10:33 -0500, Antoni Boucher wrote:
> > On Thu, 2022-12-01 at 10:25 -0500, David Malcolm wrote:
> > > On Thu, 2022-12-01 at 10:01 -0500, Antoni Boucher wrote:
> > > > Thanks, David.
> > > > Since we're not in phase 1 anymore, do we need an approval
> > > > before
> > > > I
> > > > merge like last year or can I merge immediately?
> > > 
> > > I think it counts as a bug fix and thus you can go ahead and
> > > merge
> > > (assuming you've done the usual testing).
> > > 
> > > > I also have many other patches (all in jit) that I need to
> > > > prepare
> > > > and
> > > > post to this mailing list.
> > > > What do you think?
> > > 
> > > Given that you're one of the main users of libgccjit I think
> > > there's
> > > a
> > > case for stretching the deadlines a bit here.
> > > 
> > > Do you have a repo I can look at?
> > 
> > Yes! The commits are in my fork:
> > https://github.com/antoyo/gcc
> > 
> > The only big one is the one adding support for target-dependent
> > builtins:
> > https://github.com/antoyo/gcc/commit/6d4313d4c02dd878f43917c978f299f5119330f0
> > 
> > Regarding this one, there's the issue that since we record the
> > builtins
> > on the first context run, we only have access to the builtins from
> > the
> > second run.
> > Do you have any idea how to fix this?
> > Or do you consider this is acceptable?
> 
> This is implemented behind the new
> gcc_jit_context_get_target_builtin_function entrypoint, right?

Yes.

> 
> If so, perhaps that recording::context::get_target_builtin_function
> could detect if it's the first time it's been called on this context,
> and if so make a playback::context to do the detection?  That way it
> would be transparent to the user, and work first time.

Oh, the issue is actually with the type reflection API and also the
type checking of function calls, so it's in the recording phase.
While I could think of a workaround for the type checking (e.g. delayed
type checking at the playback phase), I could not think of any better
solution for the type reflection.

> 
> 
> I see you have patches to add function and variable attributes; I
> wonder if this would be cleaner internally if there was a
> recording::attribute class, rather than the std::pair currently in
> use
> (some attributes have int arguments rather than string, others have
> multiple args).
> 
> I also wondered if a "gcc_jit_attribute" type could be exposed to the
> user, e.g.:
> 
>   attr1 = gcc_jit_context_new_attribute (ctxt, "noreturn");
>   attr2 = gcc_jit_context_new_attribute_with_string (ctxt, "alias",
> "__foo");
>   gcc_jit_function_add_attribute (ctxt, attr1);
>   gcc_jit_function_add_attribute (ctxt, attr2);
> 
> or somesuch?  But I think the API you currently have is OK.

Thanks for the suggestion; I'll look into that.

> 
> 
> > 
> > I also have a WIP branch which adds support for try/catch:
> > https://github.com/antoyo/gcc/commit/6219339fcacb079431596a0bc6cf8d430a1bd5a1
> > I'm not sure if this one is going to be ready soon or not.
> 
> I see that the new entrypoints have e.g.:
> 
> /* Add a try/catch statement.
>    This is equivalent to this C++ code:
>  try {
>     try_block
>  }
>  catch {
>     catch_block
>  }
> */
> 
> void
> gcc_jit_block_add_try_catch (gcc_jit_block *block,
>  gcc_jit_location *loc,
>  gcc_jit_block *try_block,
>  gcc_jit_block *catch_block);
> 
> but I'm not sure how this is meant to interact with the CFG-like
> model
> used by the rest of the gcc_jit_block_* API.  What happens at the end
> of the blocks?  Does the generated code use the C++ ABI for
> exception-
> handling?

Currently, it requires the try and catch blocks to be terminated, but
also require the block containing the try/catch to be terminated.
That doesn't make sense.
Would it be OK if it doesn't require the try and catch blocks to be
terminated?

For the ABI, I'm not sure it's necessarily tied to C++, but I might be
wrong. From what I understand, GCC will use the dwarf-2 exception
handling model if it's available or the sjlj otherwise (perhaps that
can be configured).
And the user can change the personality function via the API I added.

Thanks for your feedback.

> 
> Dave
> 
> > 
> > Thanks.
> > 
> > > 
> > > Dave
> > > 
> > > 
> > > > 
> > > > On Thu, 2022-12-01 at 09:28 -0500, David Malcolm wrote:
> > > > > On Sun, 2022-11-20 at 14:03 -0500, Antoni Boucher via Jit
> > > > > wrote:
> > > > > > Hi.
> > > > > > This fixes bug 107770.
> > > > > > Thanks for the review.
> > > > > 
> > > > > Thanks, the patch looks good to me.
> > > > > 
> > > > > Dave
> > > > > 
> > > > 
> > > 
> > 
> 

[PATCH] Fix a few incorrect accesses.

[Andrew MacLeod via Gcc-patches]

This consists of 3 changes which stronger type checking has indicated 
are non-compliant with the type field.


I doubt they are super important because there has not been a trap 
triggered by them, and they have been in the source base since sometime 
before 2017.  However, we should probably fix them.


I also notice that those are all uses of VOID_TYPE_P, which 
coincidentally does not check if its a type node being checked:


   /* Nonzero if this type is the (possibly qualified) void type.  */
   #define VOID_TYPE_P(NODE) (TREE_CODE (NODE) == VOID_TYPE)

So I guess it wouldn't trap anyway, just silently never trigger.

Bootstraps on x86_64-pc-linux-gnu with no regressions.  OK for trunk?

Andrew
From d1003e853d1813105eef6e441578e5bea9de8d03 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod 
Date: Tue, 29 Nov 2022 13:07:28 -0500
Subject: [PATCH] Fix a few incorrect accesses.

This consists of 3 changes which stronger type checking has indicated
are incorrect.

	gcc/
	* fold-const.cc (fold_unary_loc): Check TREE_TYPE of node.
	(tree_invalid_nonnegative_warnv_p): Likewise.

	gcc/c-family/
	* c-attribs.cc (handle_deprecated_attribute): Use type when
	using TYPE_NAME.
---
 gcc/c-family/c-attribs.cc | 2 +-
 gcc/fold-const.cc | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index 07bca68e9b9..b36dd97802b 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -4240,7 +4240,7 @@ handle_deprecated_attribute (tree *node, tree name,
   if (type && TYPE_NAME (type))
 	{
 	  if (TREE_CODE (TYPE_NAME (type)) == IDENTIFIER_NODE)
-	what = TYPE_NAME (*node);
+	what = TYPE_NAME (type);
 	  else if (TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
 		   && DECL_NAME (TYPE_NAME (type)))
 	what = DECL_NAME (TYPE_NAME (type));
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 114258fa182..e80be8049e1 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -9369,8 +9369,8 @@ fold_unary_loc (location_t loc, enum tree_code code, tree type, tree op0)
 	  && TREE_CODE (tem) == COND_EXPR
 	  && TREE_CODE (TREE_OPERAND (tem, 1)) == code
 	  && TREE_CODE (TREE_OPERAND (tem, 2)) == code
-	  && ! VOID_TYPE_P (TREE_OPERAND (tem, 1))
-	  && ! VOID_TYPE_P (TREE_OPERAND (tem, 2))
+	  && ! VOID_TYPE_P (TREE_TYPE (TREE_OPERAND (tem, 1)))
+	  && ! VOID_TYPE_P (TREE_TYPE (TREE_OPERAND (tem, 2)))
 	  && (TREE_TYPE (TREE_OPERAND (TREE_OPERAND (tem, 1), 0))
 		  == TREE_TYPE (TREE_OPERAND (TREE_OPERAND (tem, 2), 0)))
 	  && (! (INTEGRAL_TYPE_P (TREE_TYPE (tem))
@@ -15002,7 +15002,7 @@ tree_invalid_nonnegative_warnv_p (tree t, bool *strict_overflow_p, int depth)
 
 	/* If the initializer is non-void, then it's a normal expression
 	   that will be assigned to the slot.  */
-	if (!VOID_TYPE_P (t))
+	if (!VOID_TYPE_P (TREE_TYPE (t)))
 	  return RECURSE (t);
 
 	/* Otherwise, the initializer sets the slot in some way.  One common
-- 
2.38.1

nvptx: Support global constructors/destructors via 'collect2'

[Thomas Schwinge]

Hi!

On 2022-12-01T22:13:38+0100, I wrote:
> I'm working on support for global constructors/destructors with
> GCC/nvptx

See "nvptx: Support global constructors/destructors via 'collect2'"
attached; OK to push?  (... with 'gcc/doc/install.texi' accordingly
updated once 
"'nm'" and newlib

"nvptx: Implement '_exit' instead of 'exit'" have been merged; any
comments to those?)

Per my quick scanning of 'gcc/config.gcc' history, for more than two
decades, there was a clear trend to remove 'use_collect2=yes'
configurations; now finally a new one is being added -- making sure we're
not slowly dispensing with the need for the early 1990s piece of work
that 'gcc/collect2*' is...  ;'-P


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 ba5f6471d39e684fb740523651138a90a1b63cf9 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sun, 13 Nov 2022 14:19:30 +0100
Subject: [PATCH] nvptx: Support global constructors/destructors via 'collect2'

The function attributes 'constructor', 'destructor', and 'init_priority' now
work, as do the C++ features making use of this.  Test cases with effective
target 'global_constructor' and 'init_priority' now generally work, and
'check-gcc-c++' test results greatly improve; no more "sorry, unimplemented:
global constructors not supported on this target".

This depends on  "'nm'"
generally, and for global destructors support: newlib

"nvptx: Implement '_exit' instead of 'exit'".

	gcc/
	* collect2.cc (write_c_file_glob): Allow for
	'COLLECT2_MAIN_REFERENCE' override.
	* config.gcc : Set 'use_collect2=yes'.
	* config/nvptx/nvptx.h: Adjust.
	gcc/testsuite/
	* gcc.dg/no_profile_instrument_function-attr-1.c: GCC/nvptx is
	'NO_DOT_IN_LABEL' but not 'NO_DOLLAR_IN_LABEL', so '$' may apper
	in identifiers.
	* lib/target-supports.exp
	(check_effective_target_global_constructor): Enable for nvptx.
	libgcc/
	* config.host : Add 'crtbegin.o',
	'crtend.o' to 'extra_parts'.
	* config/nvptx/crt0.c: Invoke '__do_global_ctors',
	'__do_global_dtors'.
	* config/nvptx/crtstuff.c: New.
	* config/nvptx/t-nvptx: Adjust.
---
 gcc/collect2.cc   |  4 ++
 gcc/config.gcc|  1 +
 gcc/config/nvptx/nvptx.h  | 35 ++-
 .../no_profile_instrument_function-attr-1.c   |  2 +-
 gcc/testsuite/lib/target-supports.exp |  3 +-
 libgcc/config.host|  2 +-
 libgcc/config/nvptx/crt0.c|  5 ++
 libgcc/config/nvptx/crtstuff.c| 58 +++
 libgcc/config/nvptx/t-nvptx   | 15 -
 9 files changed, 118 insertions(+), 7 deletions(-)
 create mode 100644 libgcc/config/nvptx/crtstuff.c

diff --git a/gcc/collect2.cc b/gcc/collect2.cc
index d81c7f28f16..945a9ff86dd 100644
--- a/gcc/collect2.cc
+++ b/gcc/collect2.cc
@@ -2238,8 +2238,12 @@ write_c_file_glob (FILE *stream, const char *name ATTRIBUTE_UNUSED)
 fprintf (stream, "\tdereg_frame,\n");
   fprintf (stream, "\t0\n};\n\n");
 
+# ifdef COLLECT2_MAIN_REFERENCE
+  fprintf (stream, "%s\n\n", COLLECT2_MAIN_REFERENCE);
+# else
   fprintf (stream, "extern entry_pt %s;\n", NAME__MAIN);
   fprintf (stream, "entry_pt *__main_reference = %s;\n\n", NAME__MAIN);
+# endif
 }
 #endif /* ! LD_INIT_SWITCH */
 
diff --git a/gcc/config.gcc b/gcc/config.gcc
index b5eda046033..9b27efd5f51 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2783,6 +2783,7 @@ nvptx-*)
 	tm_file="${tm_file} newlib-stdint.h"
 	use_gcc_stdint=wrap
 	tmake_file="nvptx/t-nvptx"
+	use_collect2=yes
 	if test x$enable_as_accelerator = xyes; then
 		extra_programs="${extra_programs} mkoffload\$(exeext)"
 		tm_file="${tm_file} nvptx/offload.h"
diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index b1cbe5d417b..bc1021a8031 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -35,7 +35,39 @@
'../../gcc.cc:asm_options', 'HAVE_GNU_AS'.  */
 #define ASM_SPEC "%{v}"
 
-#define STARTFILE_SPEC "%{mmainkernel:crt0.o%s}"
+#define STARTFILE_SPEC \
+  STARTFILE_SPEC_MMAINKERNEL \
+  " " STARTFILE_SPEC_CDTOR
+
+#define ENDFILE_SPEC \
+  ENDFILE_SPEC_CDTOR
+
+#define STARTFILE_SPEC_MMAINKERNEL "%{mmainkernel:crt0.o%s}"
+
+/* Support for global constructors/destructors is implemented via
+   'collect2' and the following helpers.  */
+
+#define STARTFILE_SPEC_CDTOR "crtbegin.o%s"
+
+#define ENDFILE_SPEC_CDTOR "crtend.o%s"
+
+/* nvptx does its own wrapping of 'main'
+   (see 'libgcc/config/nvptx/crt0.c:__main').  */

[committed] [PR106462] LRA: Check hard reg availability of pseudo and its subreg for pseudo reload

[Vladimir Makarov via Gcc-patches]

The following patch solves

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

The patch was successfully bootstrapped and tested on x86-64.
commit 70596a0fb2a2ec072e1e97e37616e05041dfa4e5
Author: Vladimir N. Makarov 
Date:   Fri Dec 2 08:18:04 2022 -0500

LRA: Check hard reg availability of pseudo and its subreg for pseudo reload

Do not reload subreg pseudo if there are hard regs for subreg mode
but there are no hard regs for pseudo mode.

PR target/106462

gcc/ChangeLog:

* lra-constraints.cc (curr_insn_transform): Check available hard
regs for pseudo and its subreg to decide what to reload.

gcc/testsuite/ChangeLog:

* gcc.target/mips/pr106462.c: New test.

diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
index d92ab76908c..02b5ab4a316 100644
--- a/gcc/lra-constraints.cc
+++ b/gcc/lra-constraints.cc
@@ -4582,7 +4582,18 @@ curr_insn_transform (bool check_only_p)
 		  || (partial_subreg_p (mode, GET_MODE (reg))
 			  && known_le (GET_MODE_SIZE (GET_MODE (reg)),
    UNITS_PER_WORD)
-			  && WORD_REGISTER_OPERATIONS)))
+			  && WORD_REGISTER_OPERATIONS))
+		  /* Avoid the situation when there are no available hard regs
+		 for the pseudo mode but there are ones for the subreg
+		 mode: */
+		  && !(goal_alt[i] != NO_REGS
+		   && REGNO (reg) >= FIRST_PSEUDO_REGISTER
+		   && (prohibited_class_reg_set_mode_p
+			   (goal_alt[i], reg_class_contents[goal_alt[i]],
+			GET_MODE (reg)))
+		   && !(prohibited_class_reg_set_mode_p
+			(goal_alt[i], reg_class_contents[goal_alt[i]],
+			 mode
 		{
 		  /* An OP_INOUT is required when reloading a subreg of a
 		 mode wider than a word to ensure that data beyond the
diff --git a/gcc/testsuite/gcc.target/mips/pr106462.c b/gcc/testsuite/gcc.target/mips/pr106462.c
new file mode 100644
index 000..c9105409524
--- /dev/null
+++ b/gcc/testsuite/gcc.target/mips/pr106462.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-mabi=64 -msingle-float" } */
+
+extern void bar (float x, short y);
+
+void foo (int argc)
+{
+short c = argc * 2;
+float a = (float)(short)c, b = 9.5;
+
+bar (b/a, c);
+}

[PATCH 9/9] nvptx: Re-enable 'gcc.misc-tests/options.exp'

[Thomas Schwinge]

..., just conditionalize its profiling test (as done elsewhere).

gcc/testsuite/
* gcc.misc-tests/options.exp: Re-enable for nvptx.
---
 gcc/testsuite/gcc.misc-tests/options.exp | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/gcc.misc-tests/options.exp 
b/gcc/testsuite/gcc.misc-tests/options.exp
index c939aef1f4bc..a055786ea0c1 100644
--- a/gcc/testsuite/gcc.misc-tests/options.exp
+++ b/gcc/testsuite/gcc.misc-tests/options.exp
@@ -21,12 +21,6 @@

 load_lib gcc-defs.exp

-# disable for non-profile targets explitly, rather than
-# rely on check-effective target.  We're explicitly trying to check
-# profiling works, and if it doesn't check-effective-target will
-# simply skip the tests, rather than have this test shout at us.
-if [ istarget "nvptx-*-*" ] { return 0 }
-
 # These tests don't run runtest_file_p consistently if it
 # doesn't return the same values, so disable parallelization
 # of this *.exp file.  The first parallel runtest to reach
@@ -73,7 +67,9 @@ proc check_for_all_options {language gcc_options 
compiler_pattern as_pattern ld_
 pass $test
 }

-check_for_all_options c {--coverage} {-fprofile-arcs -ftest-coverage} {} 
{-lgcov}
+if { [check_profiling_available "-fprofile-arcs"] } {
+check_for_all_options c {--coverage} {-fprofile-arcs -ftest-coverage} {} 
{-lgcov}
+}

 proc get_dump_flags {} {
 set res [list]
--
2.35.1

-
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

[PATCH 6/9] nvptx: Re-enable all variants of 'c-c++-common/torture/complex-sign-mixed-add.c', 'c-c++-common/torture/complex-sign-mixed-sub.c'

[Thomas Schwinge]

PASS with:

$ ptxas --version
ptxas: NVIDIA (R) Ptx optimizing assembler
Copyright (c) 2005-2018 NVIDIA Corporation
Built on Sun_Sep__9_21:06:46_CDT_2018
Cuda compilation tools, release 10.0, V10.0.145

..., and execution with 'Driver Version: 361.93.02'.

gcc/testsuite/
* c-c++-common/torture/complex-sign-mixed-add.c: Re-enable all
variants for nvptx.
* c-c++-common/torture/complex-sign-mixed-sub.c: Likewise.
---
 gcc/testsuite/c-c++-common/torture/complex-sign-mixed-add.c | 1 -
 gcc/testsuite/c-c++-common/torture/complex-sign-mixed-sub.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/torture/complex-sign-mixed-add.c 
b/gcc/testsuite/c-c++-common/torture/complex-sign-mixed-add.c
index a209161e1578..d1e20912ae14 100644
--- a/gcc/testsuite/c-c++-common/torture/complex-sign-mixed-add.c
+++ b/gcc/testsuite/c-c++-common/torture/complex-sign-mixed-add.c
@@ -2,7 +2,6 @@
addition.  */
 /* { dg-do run } */
 /* { dg-options "-std=gnu99" { target c } } */
-/* { dg-skip-if "ptx can elide zero additions" { "nvptx-*-*" } { "-O0" } { "" 
} } */

 #include "complex-sign.h"

diff --git a/gcc/testsuite/c-c++-common/torture/complex-sign-mixed-sub.c 
b/gcc/testsuite/c-c++-common/torture/complex-sign-mixed-sub.c
index 02ab4db247cb..739500d2f8be 100644
--- a/gcc/testsuite/c-c++-common/torture/complex-sign-mixed-sub.c
+++ b/gcc/testsuite/c-c++-common/torture/complex-sign-mixed-sub.c
@@ -2,7 +2,6 @@
subtraction.  */
 /* { dg-do run } */
 /* { dg-options "-std=gnu99" { target c } } */
-/* { dg-skip-if "ptx can elide zero additions" { "nvptx-*-*" } { "-O0" } { "" 
} } */

 #include "complex-sign.h"

--
2.35.1

-
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

[PATCH 5/9] nvptx: Re-enable 'gcc.dg/special/weak-2.c'

[Thomas Schwinge]

PASSes with:

$ ptxas --version
ptxas: NVIDIA (R) Ptx optimizing assembler
Copyright (c) 2005-2018 NVIDIA Corporation
Built on Sun_Sep__9_21:06:46_CDT_2018
Cuda compilation tools, release 10.0, V10.0.145

..., and execution with 'Driver Version: 361.93.02'.

gcc/testsuite/
* gcc.dg/special/weak-2.c: Re-enable for nvptx.
---
 gcc/testsuite/gcc.dg/special/weak-2.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/special/weak-2.c 
b/gcc/testsuite/gcc.dg/special/weak-2.c
index b8133e2d7d95..b93a8ef9a529 100644
--- a/gcc/testsuite/gcc.dg/special/weak-2.c
+++ b/gcc/testsuite/gcc.dg/special/weak-2.c
@@ -2,10 +2,6 @@
 /* { dg-require-weak "" } */
 /* { dg-additional-sources "weak-2a.c weak-2b.c" } */

-/* NVPTX's implementation of weak is broken when a strong symbol is in
-   a later object file than the weak definition.   */
-/* { dg-skip-if "" { "nvptx-*-*" } } */
-
 #include 

 extern int foo(void);
--
2.35.1

-
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

[PATCH 8/9] nvptx: Re-enable "Stack alignment causes use of alloca" test cases

[Thomas Schwinge]

Generally PASS with:

$ ptxas --version
ptxas: NVIDIA (R) Ptx optimizing assembler
Copyright (c) 2005-2018 NVIDIA Corporation
Built on Sun_Sep__9_21:06:46_CDT_2018
Cuda compilation tools, release 10.0, V10.0.145

..., and execution with 'Driver Version: 361.93.02'.

The exceptions are 'gcc.dg/torture/stackalign/pr16660-2.c',
'gcc.dg/torture/stackalign/pr16660-3.c', where a few variants get XFAILed due
to:

nvptx-as: ptxas terminated with signal 11 [Segmentation fault], core dumped

gcc/testsuite/
* gcc.dg/torture/stackalign/global-1.c: Re-enable for nvptx.
* gcc.dg/torture/stackalign/inline-1.c: Likewise.
* gcc.dg/torture/stackalign/nested-1.c: Likewise.
* gcc.dg/torture/stackalign/nested-2.c: Likewise.
* gcc.dg/torture/stackalign/nested-4.c: Likewise.
* gcc.dg/torture/stackalign/pr16660-1.c: Likewise.
* gcc.dg/torture/stackalign/pr16660-2.c: Likewise.
* gcc.dg/torture/stackalign/pr16660-3.c: Likewise.
* gcc.dg/torture/stackalign/ret-struct-1.c: Likewise.
* gcc.dg/torture/stackalign/struct-1.c: Likewise.
---
 gcc/testsuite/gcc.dg/torture/stackalign/global-1.c | 1 -
 gcc/testsuite/gcc.dg/torture/stackalign/inline-1.c | 1 -
 gcc/testsuite/gcc.dg/torture/stackalign/nested-1.c | 1 -
 gcc/testsuite/gcc.dg/torture/stackalign/nested-2.c | 1 -
 gcc/testsuite/gcc.dg/torture/stackalign/nested-4.c | 2 +-
 gcc/testsuite/gcc.dg/torture/stackalign/pr16660-1.c| 1 -
 gcc/testsuite/gcc.dg/torture/stackalign/pr16660-2.c| 2 +-
 gcc/testsuite/gcc.dg/torture/stackalign/pr16660-3.c| 2 +-
 gcc/testsuite/gcc.dg/torture/stackalign/ret-struct-1.c | 1 -
 gcc/testsuite/gcc.dg/torture/stackalign/struct-1.c | 1 -
 10 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/torture/stackalign/global-1.c 
b/gcc/testsuite/gcc.dg/torture/stackalign/global-1.c
index 66bec64a0f58..a7cbfa74d165 100644
--- a/gcc/testsuite/gcc.dg/torture/stackalign/global-1.c
+++ b/gcc/testsuite/gcc.dg/torture/stackalign/global-1.c
@@ -1,6 +1,5 @@
 /* { dg-do run } */
 /* { dg-skip-if "Stack alignment is too small" { hppa*-*-hpux* } } */
-/* { dg-skip-if "Stack alignment causes use of alloca" { nvptx-*-* } } */

 #include "check.h"

diff --git a/gcc/testsuite/gcc.dg/torture/stackalign/inline-1.c 
b/gcc/testsuite/gcc.dg/torture/stackalign/inline-1.c
index 912581e9ca84..6aed4398cb19 100644
--- a/gcc/testsuite/gcc.dg/torture/stackalign/inline-1.c
+++ b/gcc/testsuite/gcc.dg/torture/stackalign/inline-1.c
@@ -1,6 +1,5 @@
 /* { dg-do run } */
 /* { dg-skip-if "Stack alignment is too small" { hppa*-*-hpux* } } */
-/* { dg-skip-if "Stack alignment causes use of alloca" { nvptx-*-* } } */

 #include "check.h"

diff --git a/gcc/testsuite/gcc.dg/torture/stackalign/nested-1.c 
b/gcc/testsuite/gcc.dg/torture/stackalign/nested-1.c
index ae9047e783d9..25343757c9ce 100644
--- a/gcc/testsuite/gcc.dg/torture/stackalign/nested-1.c
+++ b/gcc/testsuite/gcc.dg/torture/stackalign/nested-1.c
@@ -1,6 +1,5 @@
 /* { dg-do run } */
 /* { dg-skip-if "Stack alignment is too small" { hppa*-*-hpux* } } */
-/* { dg-skip-if "Stack alignment causes use of alloca" { nvptx-*-* } } */

 #include "check.h"

diff --git a/gcc/testsuite/gcc.dg/torture/stackalign/nested-2.c 
b/gcc/testsuite/gcc.dg/torture/stackalign/nested-2.c
index d083d6695b11..397a34fb661f 100644
--- a/gcc/testsuite/gcc.dg/torture/stackalign/nested-2.c
+++ b/gcc/testsuite/gcc.dg/torture/stackalign/nested-2.c
@@ -1,6 +1,5 @@
 /* { dg-do run } */
 /* { dg-skip-if "Stack alignment is too small" { hppa*-*-hpux* } } */
-/* { dg-skip-if "Stack alignment causes use of alloca" { nvptx-*-* } } */

 #include "check.h"

diff --git a/gcc/testsuite/gcc.dg/torture/stackalign/nested-4.c 
b/gcc/testsuite/gcc.dg/torture/stackalign/nested-4.c
index a46104b9df0a..4d18ba9ad397 100644
--- a/gcc/testsuite/gcc.dg/torture/stackalign/nested-4.c
+++ b/gcc/testsuite/gcc.dg/torture/stackalign/nested-4.c
@@ -1,6 +1,6 @@
 /* { dg-do run } */
 /* { dg-skip-if "Stack alignment is too small" { hppa*-*-hpux* } } */
-/* { dg-skip-if "Stack alignment causes use of alloca" { nvptx-*-* } } */
+/* { dg-require-effective-target nonlocal_goto } */

 #include "check.h"

diff --git a/gcc/testsuite/gcc.dg/torture/stackalign/pr16660-1.c 
b/gcc/testsuite/gcc.dg/torture/stackalign/pr16660-1.c
index 459b3df26964..3818e5c32cd6 100644
--- a/gcc/testsuite/gcc.dg/torture/stackalign/pr16660-1.c
+++ b/gcc/testsuite/gcc.dg/torture/stackalign/pr16660-1.c
@@ -1,6 +1,5 @@
 /* { dg-do run } */
 /* { dg-skip-if "Stack alignment is too small" { hppa*-*-hpux* } } */
-/* { dg-skip-if "Stack alignment causes use of alloca" { nvptx-*-* } } */

 #include "check.h"

diff --git a/gcc/testsuite/gcc.dg/torture/stackalign/pr16660-2.c 
b/gcc/testsuite/gcc.dg/torture/stackalign/pr16660-2.c
index 2aaff4001091..db0763bbd33d 100644
--- a/gcc/testsuite/gcc.dg/torture/stackalign/pr16660-2.c
+++ 

[PATCH 4/9] nvptx: Re-enable all variants of 'gcc.c-torture/execute/20020529-1.c'

[Thomas Schwinge]

Generally PASSes with:

$ ptxas --version
ptxas: NVIDIA (R) Ptx optimizing assembler
Copyright (c) 2005-2018 NVIDIA Corporation
Built on Sun_Sep__9_21:06:46_CDT_2018
Cuda compilation tools, release 10.0, V10.0.145

..., and execution with 'Driver Version: 361.93.02'.

Only the '-O1' execution test FAILs (pre-existing; to be analyzed later):

nvptx-run: error getting kernel result: an illegal memory access was 
encountered (CUDA_ERROR_ILLEGAL_ADDRESS, 700)

gcc/testsuite/
* gcc.c-torture/execute/20020529-1.c: Re-enable all variants for
nvptx.
---
 gcc/testsuite/gcc.c-torture/execute/20020529-1.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/gcc/testsuite/gcc.c-torture/execute/20020529-1.c 
b/gcc/testsuite/gcc.c-torture/execute/20020529-1.c
index 160a716ba5bf..d1b93c76fdf4 100644
--- a/gcc/testsuite/gcc.c-torture/execute/20020529-1.c
+++ b/gcc/testsuite/gcc.c-torture/execute/20020529-1.c
@@ -12,10 +12,6 @@
forced a splitter through the output pattern "#", but there was no
matching splitter.  */

-/* The ptx assembler appears to clobber 'b' inside foo during the f1 call.
-   Reported to nvidia 2016-05-18.  */
-/* { dg-skip-if "PTX assembler bug" { nvptx-*-* } { "-O0" } { "" } } */
-
 struct xx
  {
int a;
--
2.35.1

-
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

[PATCH 3/9] nvptx: Re-enable test cases by removing effective target 'freestanding'

[Thomas Schwinge]

After 2014's commit 157e859ffe3b5d43db1e19475711c1a3d21ab57a "remove picochip",
the effective target 'freestanding' (later) was only ever used for nvptx.
However, the relevant I/O library functions have long been implemented in nvptx
newlib, and otherwise, the more specific effective target 'fileio' (as added in
commit r10-7943-g3685c5adf5c0b30268cb8f95c89e4c4a3240ae6f
"introduce target fileio and require it in tests that use tmpnam") may be used,
and already is used in the relevant test cases.  Therefore, I suggest
"removing effective target 'freestanding'" instead of letting it linger unused,
and thus unmaintained.

These test cases generally PASS, just a few need to get XFAILed; see
,
and then supposedly
 for
description of the non-standard PTX 'vprintf' return value:

> Unlike the C-standard 'printf()', which returns the number of characters
> printed, CUDA's 'printf()' returns the number of arguments parsed. If no
> arguments follow the format string, 0 is returned. If the format string is
> NULL, -1 is returned. If an internal error occurs, -2 is returned.

(I've tried a few variants to confirm that PTX 'vprintf' -- which supposedly is
underlying the CUDA 'printf' -- is what's implementing this behavior.)
Probably, we ought to fix that up in nvptx newlib.

gcc/doc/
* sourcebuild.texi (Effective-Target Keywords): Remove
'freestanding'.
gcc/testsuite/
* gcc.c-torture/execute/builtins/fprintf.x: Remove.
* gcc.c-torture/execute/builtins/fputs.x: Likewise.
* gcc.c-torture/execute/complex-6.c: Don't gate on 'freestanding'.
* gcc.c-torture/execute/fprintf-1.c: Likewise.
* gcc.c-torture/execute/fprintf-2.c: Likewise.
* gcc.c-torture/execute/fprintf-chk-1.c: Likewise.
* gcc.c-torture/execute/gofast.c: Likewise.
* gcc.c-torture/execute/pr34456.c: Likewise.
* gcc.c-torture/execute/printf-1.c: Likewise.
* gcc.c-torture/execute/printf-2.c: Likewise.
* gcc.c-torture/execute/printf-chk-1.c: Likewise.
* gcc.c-torture/execute/user-printf.c: Likewise.
* gcc.c-torture/execute/vfprintf-1.c: Likewise.
* gcc.c-torture/execute/vfprintf-chk-1.c: Likewise.
* gcc.c-torture/execute/vprintf-1.c: Likewise.
* gcc.c-torture/execute/vprintf-chk-1.c: Likewise.
* gcc.dg/pr27531-1.c: Likewise.
* gcc.dg/pr44606.c: Likewise.
* lib/target-supports.exp (check_effective_target_freestanding):
Remove.
---
 gcc/doc/sourcebuild.texi   |  5 -
 gcc/testsuite/gcc.c-torture/execute/builtins/fprintf.x |  7 ---
 gcc/testsuite/gcc.c-torture/execute/builtins/fputs.x   |  7 ---
 gcc/testsuite/gcc.c-torture/execute/complex-6.c|  2 --
 gcc/testsuite/gcc.c-torture/execute/fprintf-1.c|  2 --
 gcc/testsuite/gcc.c-torture/execute/fprintf-2.c|  3 +--
 gcc/testsuite/gcc.c-torture/execute/fprintf-chk-1.c|  2 --
 gcc/testsuite/gcc.c-torture/execute/gofast.c   |  2 --
 gcc/testsuite/gcc.c-torture/execute/pr34456.c  |  2 --
 gcc/testsuite/gcc.c-torture/execute/printf-1.c |  2 +-
 gcc/testsuite/gcc.c-torture/execute/printf-2.c |  3 +--
 gcc/testsuite/gcc.c-torture/execute/printf-chk-1.c |  2 +-
 gcc/testsuite/gcc.c-torture/execute/user-printf.c  |  3 +--
 gcc/testsuite/gcc.c-torture/execute/vfprintf-1.c   |  2 --
 gcc/testsuite/gcc.c-torture/execute/vfprintf-chk-1.c   |  2 --
 gcc/testsuite/gcc.c-torture/execute/vprintf-1.c|  2 +-
 gcc/testsuite/gcc.c-torture/execute/vprintf-chk-1.c|  2 +-
 gcc/testsuite/gcc.dg/pr27531-1.c   |  1 -
 gcc/testsuite/gcc.dg/pr44606.c |  1 -
 gcc/testsuite/lib/target-supports.exp  | 10 --
 20 files changed, 7 insertions(+), 55 deletions(-)
 delete mode 100644 gcc/testsuite/gcc.c-torture/execute/builtins/fprintf.x
 delete mode 100644 gcc/testsuite/gcc.c-torture/execute/builtins/fputs.x

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index fc488964480f..cfdd5cfe1a6f 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2623,11 +2623,6 @@ Target offers such file I/O library functions as 
@code{fopen},
 requirement for the presence of the functions in the library; even if
 they fail at runtime, the requirement is still regarded as satisfied.

-@item freestanding
-Target is @samp{freestanding} as defined in section 4 of the C99 standard.
-Effectively, it is a target which supports no extra headers or libraries
-other than what is considered essential.
-
 @item gettimeofday
 Target supports @code{gettimeofday}.

diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf.x 
b/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf.x
deleted file mode 100644
index 

[PATCH 7/9] nvptx: Re-enable 'gcc.dg/torture/c99-contract-1.c'

[Thomas Schwinge]

Generally PASSes with:

$ ptxas --version
ptxas: NVIDIA (R) Ptx optimizing assembler
Copyright (c) 2005-2018 NVIDIA Corporation
Built on Sun_Sep__9_21:06:46_CDT_2018
Cuda compilation tools, release 10.0, V10.0.145

..., and execution with 'Driver Version: 361.93.02', at least for the '-O0'
execution test.  Optimized execution tests XFAILed, to be analyzed later.

gcc/testsuite/
* gcc.dg/torture/c99-contract-1.c: Re-enable for nvptx.
---
 gcc/testsuite/gcc.dg/torture/c99-contract-1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/torture/c99-contract-1.c 
b/gcc/testsuite/gcc.dg/torture/c99-contract-1.c
index 392666f3dd58..749005e797c5 100644
--- a/gcc/testsuite/gcc.dg/torture/c99-contract-1.c
+++ b/gcc/testsuite/gcc.dg/torture/c99-contract-1.c
@@ -2,7 +2,7 @@
expressions.  */
 /* { dg-do run } */
 /* { dg-options "-std=c99 -pedantic-errors" } */
-/* { dg-skip-if "ptx only loosely follows IEEE" { "nvptx-*-*" } } */
+/* { dg-xfail-run-if {only loosely follows IEEE} { nvptx-*-* && __OPTIMIZE__ } 
} */

 extern void abort (void);
 extern void exit (int);
--
2.35.1

-
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

[PATCH 1/9] nvptx: Re-enable 'gcc.c-torture/compile/20080721-1.c'

[Thomas Schwinge]

PASSes with:

$ ptxas --version
ptxas: NVIDIA (R) Ptx optimizing assembler
Copyright (c) 2005-2018 NVIDIA Corporation
Built on Sun_Sep__9_21:06:46_CDT_2018
Cuda compilation tools, release 10.0, V10.0.145

gcc/testsuite/
* gcc.c-torture/compile/20080721-1.c: Re-enable for nvptx.
---
 gcc/testsuite/gcc.c-torture/compile/20080721-1.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/testsuite/gcc.c-torture/compile/20080721-1.c 
b/gcc/testsuite/gcc.c-torture/compile/20080721-1.c
index 6c928f55ca10..35ef352bc6da 100644
--- a/gcc/testsuite/gcc.c-torture/compile/20080721-1.c
+++ b/gcc/testsuite/gcc.c-torture/compile/20080721-1.c
@@ -1,4 +1,3 @@
-/* { dg-skip-if "can't read function data" { nvptx-*-* } } */
 void foo(void);
 void bar(void);

--
2.35.1

-
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

[PATCH 2/9] nvptx: Re-enable "ptxas times out" test cases

[Thomas Schwinge]

These are all quick to compile and generally PASS with:

$ ptxas --version
ptxas: NVIDIA (R) Ptx optimizing assembler
Copyright (c) 2005-2018 NVIDIA Corporation
Built on Sun_Sep__9_21:06:46_CDT_2018
Cuda compilation tools, release 10.0, V10.0.145

(Tested 'gcc.c-torture/compile/920501-4.c' with 'dg-require-stack-size' defused
as per "nvptx: stack size limits are relevant for execution only".)

Only 'gcc.c-torture/compile/limits-fndefn.c' now generally FAILs (but not due
to "ptxas times out"), with:

ptxas limits-fndefn.o, line 8; fatal   : Parsing error near '.visible': 
syntax error
ptxas fatal   : Ptx assembly aborted due to errors
nvptx-as: ptxas returned 255 exit status

Work around that by '-Wa,--no-verify'; to be analyzed further, later on.

gcc/testsuite/
* gcc.c-torture/compile/920501-4.c: Re-enable nvptx
"ptxas times out" variants.
* gcc.c-torture/compile/921011-1.c: Likewise.
* gcc.c-torture/compile/limits-fndefn.c: Likewise.
* gcc.c-torture/compile/pr34334.c: Likewise.
* gcc.c-torture/compile/pr37056.c: Likewise.
* gcc.c-torture/compile/pr39423-1.c: Likewise.
* gcc.c-torture/compile/pr49049.c: Likewise.
* gcc.c-torture/compile/pr59417.c: Likewise.
---
 gcc/testsuite/gcc.c-torture/compile/920501-4.c  | 1 -
 gcc/testsuite/gcc.c-torture/compile/921011-1.c  | 2 --
 gcc/testsuite/gcc.c-torture/compile/limits-fndefn.c | 6 +-
 gcc/testsuite/gcc.c-torture/compile/pr34334.c   | 1 -
 gcc/testsuite/gcc.c-torture/compile/pr37056.c   | 1 -
 gcc/testsuite/gcc.c-torture/compile/pr39423-1.c | 1 -
 gcc/testsuite/gcc.c-torture/compile/pr49049.c   | 2 --
 gcc/testsuite/gcc.c-torture/compile/pr59417.c   | 1 -
 8 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/gcc/testsuite/gcc.c-torture/compile/920501-4.c 
b/gcc/testsuite/gcc.c-torture/compile/920501-4.c
index 2ef54b5d35d4..e165e7fc5f3e 100644
--- a/gcc/testsuite/gcc.c-torture/compile/920501-4.c
+++ b/gcc/testsuite/gcc.c-torture/compile/920501-4.c
@@ -1,5 +1,4 @@
 /* { dg-do assemble } */
-/* { dg-skip-if "ptxas times out" { nvptx-*-* } { "-O1" } { "" } } */
 /* { dg-skip-if "Array too big" { "pdp11-*-*" } { "-mint32" } } */
 /* { dg-require-stack-size "8196*4" } */

diff --git a/gcc/testsuite/gcc.c-torture/compile/921011-1.c 
b/gcc/testsuite/gcc.c-torture/compile/921011-1.c
index 5955b4c527dc..6cc707dc74c6 100644
--- a/gcc/testsuite/gcc.c-torture/compile/921011-1.c
+++ b/gcc/testsuite/gcc.c-torture/compile/921011-1.c
@@ -1,5 +1,3 @@
-/* { dg-skip-if "ptxas times out" { nvptx-*-* } { "-O1" } { "" } } */
-
 void
 fun (nb)
  int nb;
diff --git a/gcc/testsuite/gcc.c-torture/compile/limits-fndefn.c 
b/gcc/testsuite/gcc.c-torture/compile/limits-fndefn.c
index 532047354938..66addcccfb1e 100644
--- a/gcc/testsuite/gcc.c-torture/compile/limits-fndefn.c
+++ b/gcc/testsuite/gcc.c-torture/compile/limits-fndefn.c
@@ -1,6 +1,10 @@
 /* { dg-skip-if "too complex for avr" { avr-*-* } } */
-/* { dg-skip-if "ptxas times out" { nvptx-*-* } } */
 /* { dg-skip-if "no chance for bpf" { bpf-*-* } } */
+/* { dg-additional-options -Wa,--no-verify { target nvptx-*-* } }
+   ptxas limits-fndefn.o, line 8; fatal   : Parsing error near '.visible': 
syntax error
+   ptxas fatal   : Ptx assembly aborted due to errors
+   nvptx-as: ptxas returned 255 exit status
+*/
 /* { dg-timeout-factor 4.0 } */
 #define LIM1(x) x##0, x##1, x##2, x##3, x##4, x##5, x##6, x##7, x##8, x##9,
 #define LIM2(x) LIM1(x##0) LIM1(x##1) LIM1(x##2) LIM1(x##3) LIM1(x##4) \
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr34334.c 
b/gcc/testsuite/gcc.c-torture/compile/pr34334.c
index 5fa60a356049..30bb782626f8 100644
--- a/gcc/testsuite/gcc.c-torture/compile/pr34334.c
+++ b/gcc/testsuite/gcc.c-torture/compile/pr34334.c
@@ -1,4 +1,3 @@
-/* { dg-skip-if "ptxas times out" { nvptx-*-* } { "*" } { "-O0" } } */
 __extension__ typedef __SIZE_TYPE__ size_t;
 __extension__ typedef long long int __quad_t;
 __extension__ typedef unsigned int __mode_t;
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr37056.c 
b/gcc/testsuite/gcc.c-torture/compile/pr37056.c
index e709fdc1ffb2..f9285e2c7843 100644
--- a/gcc/testsuite/gcc.c-torture/compile/pr37056.c
+++ b/gcc/testsuite/gcc.c-torture/compile/pr37056.c
@@ -1,4 +1,3 @@
-/* { dg-skip-if "ptxas times out" { nvptx-*-* } { "-O2" "-Os" } { "" } } */
 extern void abort (void);

 static union {
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr39423-1.c 
b/gcc/testsuite/gcc.c-torture/compile/pr39423-1.c
index c604738b9cb6..34ebb66381a1 100644
--- a/gcc/testsuite/gcc.c-torture/compile/pr39423-1.c
+++ b/gcc/testsuite/gcc.c-torture/compile/pr39423-1.c
@@ -1,5 +1,4 @@
 /* PR target/39423 */
-/* { dg-skip-if "ptxas times out" { nvptx-*-* } { "-O2" } { "" } } */

 int
 foo (const char *name, int nmlen, char *flags)
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr49049.c 
b/gcc/testsuite/gcc.c-torture/compile/pr49049.c
index 

nvptx: Re-enable a number of test cases

[Thomas Schwinge]

Hi!

I'm proposing to re-enable a number of test cases for nvptx.  OK to push?


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

[PATCH (pushed)] gcc: regenerate configure

[Martin Liška]

gcc/ChangeLog:

* configure: Regenerate.
---
 gcc/configure | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/configure b/gcc/configure
index 74bf1c63e47..6af7dbd06b0 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -19712,7 +19712,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19714 "configure"
+#line 19715 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -19818,7 +19818,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 19820 "configure"
+#line 19821 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
-- 
2.38.1

[PATCH] ipa: silent -Wodr notes with -w

[Martin Liška]

If -w is used, warn_odr properly sets *warned = false and
so it should be preserved when calling warn_types_mismatch.

Noticed that during a LTO reduction where I used -w.

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

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

* ipa-devirt.cc (odr_types_equivalent_p): Respect *warned
value if set.
---
 gcc/ipa-devirt.cc | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/ipa-devirt.cc b/gcc/ipa-devirt.cc
index 265d07bb354..bcdc50c5bd7 100644
--- a/gcc/ipa-devirt.cc
+++ b/gcc/ipa-devirt.cc
@@ -1300,7 +1300,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
  warn_odr (t1, t2, NULL, NULL, warn, warned,
G_("it is defined as a pointer to different type "
   "in another translation unit"));
- if (warn && warned)
+ if (warn && (warned == NULL || *warned))
warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2),
 loc1, loc2);
  return false;
@@ -1315,7 +1315,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
  warn_odr (t1, t2, NULL, NULL, warn, warned,
G_("a different type is defined "
   "in another translation unit"));
- if (warn && warned)
+ if (warn && (warned == NULL || *warned))
warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
  return false;
}
@@ -1333,7 +1333,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
warn_odr (t1, t2, NULL, NULL, warn, warned,
  G_("a different type is defined in another "
 "translation unit"));
-   if (warn && warned)
+   if (warn && (warned == NULL || *warned))
  warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
  }
gcc_assert (TYPE_STRING_FLAG (t1) == TYPE_STRING_FLAG (t2));
@@ -1375,7 +1375,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
  warn_odr (t1, t2, NULL, NULL, warn, warned,
G_("has different return value "
   "in another translation unit"));
- if (warn && warned)
+ if (warn && (warned == NULL || *warned))
warn_types_mismatch (TREE_TYPE (t1), TREE_TYPE (t2), loc1, loc2);
  return false;
}
@@ -1398,7 +1398,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
  warn_odr (t1, t2, NULL, NULL, warn, warned,
G_("has different parameters in another "
   "translation unit"));
- if (warn && warned)
+ if (warn && (warned == NULL || *warned))
warn_types_mismatch (TREE_VALUE (parms1),
 TREE_VALUE (parms2), loc1, loc2);
  return false;
@@ -1484,7 +1484,7 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool 
*warned,
warn_odr (t1, t2, f1, f2, warn, warned,
  G_("a field of same name but different type "
 "is defined in another translation unit"));
-   if (warn && warned)
+   if (warn && (warned == NULL || *warned))
  warn_types_mismatch (TREE_TYPE (f1), TREE_TYPE (f2), 
loc1, loc2);
return false;
  }
-- 
2.38.1

Re: [committed][nvptx] Use .alias directive for mptx >= 6.3

[Thomas Schwinge]

Hi Tom!

(My following analysis and WIP patch is from a few months ago, but I
thought I'd send it now, in case you've got any comments, and to avoid
potential duplicate work.)


On 2022-03-22T14:41:46+0100, Tom de Vries via Gcc-patches 
 wrote:
> Starting with ptx isa version 6.3, a ptx directive .alias is available.
> Use this directive to support symbol aliases, as far as possible.
>
> The alias support is off by default.  It can be turned on using a switch
> -malias.
>
> Furthermore, for pre-sm_75, it's not effective unless the ptx version is
> bumped to 6.3 or higher using -mptx (given that the default for pre-sm_75 is
> 6.0).
>
> The alias support has the following limitations.
> [...]

> This patch causes a regression:
> ...
> -PASS: gcc.dg/pr60797.c  (test for errors, line 4)
> +FAIL: gcc.dg/pr60797.c  (test for errors, line 4)
> ...
> The test-case is skipped for effective target alias, and both without and with
> this patch the nvptx target is considered to not support it, so the test-case 
> is
> executed.  The test-case expects an error message along the lines of "alias
> definitions not supported in this configuration", but instead we run into:
> ...
> gcc.dg/pr60797.c:4:12: error: foo aliased to undefined symbol
> ...
> This is probably due to the fact that the nvptx backend now defines macros
> ASM_OUTPUT_DEF and ASM_OUTPUT_DEF_FROM_DECLS, so from the point of view of the
> common part of the compiler, aliases are supported.

Testing this with the new '-malias' flag not active (default), I'm seeing
a number of more regressions:

[...]: error: alias definitions not supported in this configuration

[-PASS:-]{+FAIL:+} gcc.dg/pr56727-1.c (test for excess errors)

PASS: gcc.dg/pr84739.c  (test for warnings, line 6)
PASS: gcc.dg/pr84739.c  (test for warnings, line 21)
[-PASS:-]{+FAIL:+} gcc.dg/pr84739.c (test for excess errors)

[-PASS:-]{+FAIL:+} gcc.dg/ipa/pr81520.c (test for excess errors)

..., and then, in particular, a ton of regressions in GCC/C++ testing
('check-gcc-c++') due to approximately 4 new
"error: alias definitions not supported in this configuration"
diagnostics.  Whoops...  (I suppose you've not tested that at all?)

If the new '-malias' flag is not active, we have to maintain (restore)
the previous state of other macros, as I'm demonstrating in the attached
"[WIP] nvptx 'TARGET_USE_LOCAL_THUNK_ALIAS_P', 'TARGET_SUPPORTS_ALIASES'".
This completely addresses in particular the 'check-gcc-c++' regressions,
and does not cause any changes if the new '-malias' flag in fact is
active (as when testing with '-mptx=6.3 -malias', for example).

However, this further regresses the 'gcc.dg/pr56727-1.c' and
'gcc.dg/ipa/pr81520.c' test cases mentioned above:

during IPA pass: whole-program
[...]: internal compiler error: in function_and_variable_visibility, at 
ipa-visibility.cc:647

{+FAIL: gcc.dg/pr56727-1.c (internal compiler error: in 
function_and_variable_visibility, at ipa-visibility.cc:647)+}
FAIL: gcc.dg/pr56727-1.c (test for excess errors)

{+FAIL: gcc.dg/ipa/pr81520.c (internal compiler error: in 
function_and_variable_visibility, at ipa-visibility.cc:647)+}
FAIL: gcc.dg/ipa/pr81520.c (test for excess errors)

Such ICEs we're not yet currently seeing elsewhere; this remains to be
analyzed -- after all, these test cases PASSed originally.

And, obviously, the patch needs some "copy editing".


Grüße
 Thomas


> [nvptx] Use .alias directive for mptx >= 6.3
>
> gcc/ChangeLog:
>
> 2022-03-18  Tom de Vries  
>
>   PR target/104957
>   * config/nvptx/nvptx-protos.h (nvptx_asm_output_def_from_decls): 
> Declare.
>   * config/nvptx/nvptx.cc (write_fn_proto_1): Don't add function marker
>   for alias.
>   (SET_ASM_OP, NVPTX_ASM_OUTPUT_DEF): New macro def.
>   (nvptx_asm_output_def_from_decls): New function.
>   * config/nvptx/nvptx.h (ASM_OUTPUT_DEF): New macro def, define to
>   gcc_unreachable ().
>   (ASM_OUTPUT_DEF_FROM_DECLS): New macro def, define to
>   nvptx_asm_output_def_from_decls.
>   * config/nvptx/nvptx.opt (malias): New opt.
>
> gcc/testsuite/ChangeLog:
>
> 2022-03-18  Tom de Vries  
>
>   PR target/104957
>   * gcc.target/nvptx/alias-1.c: New test.
>   * gcc.target/nvptx/alias-2.c: New test.
>   * gcc.target/nvptx/alias-3.c: New test.
>   * gcc.target/nvptx/alias-4.c: New test.
>   * gcc.target/nvptx/nvptx.exp
>   (check_effective_target_runtime_ptx_isa_version_6_3): New proc.
>
> ---
>  gcc/config/nvptx/nvptx-protos.h  |  1 +
>  gcc/config/nvptx/nvptx.cc| 74 
> +++-
>  gcc/config/nvptx/nvptx.h | 17 
>  gcc/config/nvptx/nvptx.opt   |  3 ++
>  gcc/testsuite/gcc.target/nvptx/alias-1.c | 27 
>  gcc/testsuite/gcc.target/nvptx/alias-2.c | 13 ++
>  gcc/testsuite/gcc.target/nvptx/alias-3.c | 29 +
>  gcc/testsuite/gcc.target/nvptx/alias-4.c | 12 

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Zopolis0 via Gcc-patches]

Ok, well following that logic it should work to just remove the
void_list_node definition that java uses, as per 8ff2a92. However, it
doesn't, so clearly java does something else to the end_params_node
definition that it shouldn't be, or something similar. I'll have a
look.

Re: [PATCH] i386: fix assert (__builtin_cpu_supports ("x86-64") >= 0)

[Uros Bizjak via Gcc-patches]

On Fri, Dec 2, 2022 at 10:46 AM Martin Liška  wrote:
>
> PING^1
>
> On 11/25/22 13:57, Martin Liška wrote:
> > Similar story as PR103661, we again return a negative number
> > for __builtin_cpu_supports:
> >
> > Documentation says:
> >
> > int __builtin_cpu_supports(const char *feature)
> > This function returns a positive integer if the run-time CPU supports 
> > feature and returns 0 otherwise.
> > while we return -2147483648.
> >
> > Moreover, I noticed "x86-64" is not a valid option for __builtin_cpu_is,
> > but for __builtin_cpu_supports.
> >
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >
> > Ready to be installed?
> > Thanks,
> > Martin
> >
> > PR target/107551
> >
> > gcc/ChangeLog:
> >
> >   * config/i386/i386-builtins.cc (fold_builtin_cpu): Use same path
> >   as for PR103661.
> >   * doc/extend.texi: Fix "x86-64" use.
> >
> > gcc/testsuite/ChangeLog:
> >
> >   * gcc.target/i386/builtin_target.c: Add more checks.

I'm not quite familiar with this part of the compiler, but if Jakub is
OK with the patch, consider it rubber-stamped OK.

Thanks,
Uros.

> > ---
> >  gcc/config/i386/i386-builtins.cc  | 25 ---
> >  gcc/doc/extend.texi   | 22 
> >  .../gcc.target/i386/builtin_target.c  |  5 
> >  3 files changed, 26 insertions(+), 26 deletions(-)
> >
> > diff --git a/gcc/config/i386/i386-builtins.cc 
> > b/gcc/config/i386/i386-builtins.cc
> > index eacdf072244..c57c1380298 100644
> > --- a/gcc/config/i386/i386-builtins.cc
> > +++ b/gcc/config/i386/i386-builtins.cc
> > @@ -2181,18 +2181,14 @@ fold_builtin_cpu (tree fndecl, tree *args)
> > varpool_node::add (ix86_cpu_features2_var);
> >   }
> >
> > +   /* Skip __cpu_features[0].  */
> > feature -= INT_TYPE_SIZE;
> > -   field_val = 1U << (feature % INT_TYPE_SIZE);
> > tree index = size_int (feature / INT_TYPE_SIZE);
> > +   feature = feature % INT_TYPE_SIZE;
> > array_elt = build4 (ARRAY_REF, unsigned_type_node,
> > ix86_cpu_features2_var,
> > index, NULL_TREE, NULL_TREE);
> > /* Return __cpu_features2[index] & field_val  */
> > -   final = build2 (BIT_AND_EXPR, unsigned_type_node,
> > -   array_elt,
> > -   build_int_cstu (unsigned_type_node,
> > -   field_val));
> > -   return build1 (NOP_EXPR, integer_type_node, final);
> >   }
> >else
> >   {
> > @@ -2209,16 +2205,17 @@ fold_builtin_cpu (tree fndecl, tree *args)
> > array_elt = build4 (ARRAY_REF, unsigned_type_node, ref,
> > integer_zero_node, NULL_TREE, NULL_TREE);
> >
> > -   field_val = (1U << feature);
> > /* Return __cpu_model.__cpu_features[0] & field_val  */
> > -   final = build2 (BIT_AND_EXPR, unsigned_type_node, array_elt,
> > -   build_int_cstu (unsigned_type_node, field_val));
> > -   if (feature == (INT_TYPE_SIZE - 1))
> > - return build2 (NE_EXPR, integer_type_node, final,
> > -build_int_cst (unsigned_type_node, 0));
> > -   else
> > - return build1 (NOP_EXPR, integer_type_node, final);
> >   }
> > +
> > +  field_val = (1U << feature);
> > +  final = build2 (BIT_AND_EXPR, unsigned_type_node, array_elt,
> > +   build_int_cstu (unsigned_type_node, field_val));
> > +  if (feature == (INT_TYPE_SIZE - 1))
> > + return build2 (NE_EXPR, integer_type_node, final,
> > +build_int_cst (unsigned_type_node, 0));
> > +  else
> > + return build1 (NOP_EXPR, integer_type_node, final);
> >  }
> >gcc_unreachable ();
> >  }
> > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> > index b1dd39e64b8..d3812fa55b0 100644
> > --- a/gcc/doc/extend.texi
> > +++ b/gcc/doc/extend.texi
> > @@ -21897,18 +21897,6 @@ AMD Family 19h Zen version 3.
> >
> >  @item znver4
> >  AMD Family 19h Zen version 4.
> > -
> > -@item x86-64
> > -Baseline x86-64 microarchitecture level (as defined in x86-64 psABI).
> > -
> > -@item x86-64-v2
> > -x86-64-v2 microarchitecture level.
> > -
> > -@item x86-64-v3
> > -x86-64-v3 microarchitecture level.
> > -
> > -@item x86-64-v4
> > -x86-64-v4 microarchitecture level.
> >  @end table
> >
> >  Here is an example:
> > @@ -22002,6 +21990,16 @@ VPCLMULQDQ instructions.
> >  AVX512VNNI instructions.
> >  @item avx512bitalg
> >  AVX512BITALG instructions.
> > +@item x86-64
> > +Baseline x86-64 microarchitecture level (as defined in x86-64 psABI).
> > +@item x86-64-v2
> > +x86-64-v2 microarchitecture level.
> > +@item x86-64-v3
> > +x86-64-v3 microarchitecture level.
> > +@item x86-64-v4
> > +x86-64-v4 microarchitecture level.
> > +
> > +
> >  @end table
> >
> >  Here is an example:
> > diff --git a/gcc/testsuite/gcc.target/i386/builtin_target.c 
> > 

Re: [PATCH] i386: Save/restore recog_data in ix86_vector_duplicate_value [PR106577]

[Uros Bizjak via Gcc-patches]

On Fri, Dec 2, 2022 at 10:39 AM Jakub Jelinek  wrote:
>
> Hi!
>
> On Tue, Aug 16, 2022 at 09:14:06AM +0100, Richard Sandiford via Gcc-patches 
> wrote:
> > IMO the correct low-effort fix is to save and restore recog_data
> > in ix86_vector_duplicate_value.  It's a relatively big copy,
> > but the current code is pretty wasteful anyway (allocating at
> > least a new SET and INSN for every query).  Compared to the
> > overhead of doing that, a copy to and from the stack shouldn't
> > be too bad.
>
> The following patch does that.
> It isn't the first spot in the compiler that does that, not even the first
> spot in the i386 backend.
> In i386-expand.cc beyond these 2 recog_memoized calls there is one in
> expand_vselect, but I think it is unlikely we'd run into these issues trying
> to expand new permutations from splitters.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2022-12-02  Jakub Jelinek  
>
> PR target/106577
> * config/i386/i386-expand.cc (ix86_vector_duplicate_value): 
> Save/restore
> recog_data around recog_memoized calls.
>
> * gcc.target/i386/pr106577.c: New test.

OK.

Thanks,
Uros.

>
> --- gcc/config/i386/i386-expand.cc.jj   2022-12-01 09:29:15.233466321 +0100
> +++ gcc/config/i386/i386-expand.cc  2022-12-01 14:05:55.901157211 +0100
> @@ -15187,6 +15187,10 @@ ix86_vector_duplicate_value (machine_mod
>bool ok;
>rtx_insn *insn;
>rtx dup;
> +  /* Save/restore recog_data in case this is called from splitters
> + or other routines where recog_data needs to stay valid across
> + force_reg.  See PR106577.  */
> +  recog_data_d recog_data_save = recog_data;
>
>/* First attempt to recognize VAL as-is.  */
>dup = gen_vec_duplicate (mode, val);
> @@ -15212,6 +15216,7 @@ ix86_vector_duplicate_value (machine_mod
>ok = recog_memoized (insn) >= 0;
>gcc_assert (ok);
>  }
> +  recog_data = recog_data_save;
>return true;
>  }
>
> --- gcc/testsuite/gcc.target/i386/pr106577.c.jj 2022-12-01 14:13:03.973872383 
> +0100
> +++ gcc/testsuite/gcc.target/i386/pr106577.c2022-12-01 14:13:03.973872383 
> +0100
> @@ -0,0 +1,10 @@
> +/* PR target/106577 */
> +/* { dg-do compile { target int128 } } */
> +/* { dg-options "-O2 -mavx" } */
> +
> +int i;
> +void
> +foo (void)
> +{
> +  i ^= !(((unsigned __int128)0xf0f0f0f0f0f0f0f0 << 64 | 0xf0f0f0f0f0f0f0f0) 
> & i);
> +}
>
>
> Jakub
>

Re: [PATCH] i386: fix assert (__builtin_cpu_supports ("x86-64") >= 0)

[Martin Liška]

PING^1

On 11/25/22 13:57, Martin Liška wrote:
> Similar story as PR103661, we again return a negative number
> for __builtin_cpu_supports:
> 
> Documentation says:
> 
> int __builtin_cpu_supports(const char *feature)
> This function returns a positive integer if the run-time CPU supports feature 
> and returns 0 otherwise.
> while we return -2147483648.
> 
> Moreover, I noticed "x86-64" is not a valid option for __builtin_cpu_is,
> but for __builtin_cpu_supports.
> 
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> 
> Ready to be installed?
> Thanks,
> Martin
> 
> PR target/107551
> 
> gcc/ChangeLog:
> 
>   * config/i386/i386-builtins.cc (fold_builtin_cpu): Use same path
>   as for PR103661.
>   * doc/extend.texi: Fix "x86-64" use.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/i386/builtin_target.c: Add more checks.
> ---
>  gcc/config/i386/i386-builtins.cc  | 25 ---
>  gcc/doc/extend.texi   | 22 
>  .../gcc.target/i386/builtin_target.c  |  5 
>  3 files changed, 26 insertions(+), 26 deletions(-)
> 
> diff --git a/gcc/config/i386/i386-builtins.cc 
> b/gcc/config/i386/i386-builtins.cc
> index eacdf072244..c57c1380298 100644
> --- a/gcc/config/i386/i386-builtins.cc
> +++ b/gcc/config/i386/i386-builtins.cc
> @@ -2181,18 +2181,14 @@ fold_builtin_cpu (tree fndecl, tree *args)
> varpool_node::add (ix86_cpu_features2_var);
>   }
>  
> +   /* Skip __cpu_features[0].  */
> feature -= INT_TYPE_SIZE;
> -   field_val = 1U << (feature % INT_TYPE_SIZE);
> tree index = size_int (feature / INT_TYPE_SIZE);
> +   feature = feature % INT_TYPE_SIZE;
> array_elt = build4 (ARRAY_REF, unsigned_type_node,
> ix86_cpu_features2_var,
> index, NULL_TREE, NULL_TREE);
> /* Return __cpu_features2[index] & field_val  */
> -   final = build2 (BIT_AND_EXPR, unsigned_type_node,
> -   array_elt,
> -   build_int_cstu (unsigned_type_node,
> -   field_val));
> -   return build1 (NOP_EXPR, integer_type_node, final);
>   }
>else
>   {
> @@ -2209,16 +2205,17 @@ fold_builtin_cpu (tree fndecl, tree *args)
> array_elt = build4 (ARRAY_REF, unsigned_type_node, ref,
> integer_zero_node, NULL_TREE, NULL_TREE);
>  
> -   field_val = (1U << feature);
> /* Return __cpu_model.__cpu_features[0] & field_val  */
> -   final = build2 (BIT_AND_EXPR, unsigned_type_node, array_elt,
> -   build_int_cstu (unsigned_type_node, field_val));
> -   if (feature == (INT_TYPE_SIZE - 1))
> - return build2 (NE_EXPR, integer_type_node, final,
> -build_int_cst (unsigned_type_node, 0));
> -   else
> - return build1 (NOP_EXPR, integer_type_node, final);
>   }
> +
> +  field_val = (1U << feature);
> +  final = build2 (BIT_AND_EXPR, unsigned_type_node, array_elt,
> +   build_int_cstu (unsigned_type_node, field_val));
> +  if (feature == (INT_TYPE_SIZE - 1))
> + return build2 (NE_EXPR, integer_type_node, final,
> +build_int_cst (unsigned_type_node, 0));
> +  else
> + return build1 (NOP_EXPR, integer_type_node, final);
>  }
>gcc_unreachable ();
>  }
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index b1dd39e64b8..d3812fa55b0 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -21897,18 +21897,6 @@ AMD Family 19h Zen version 3.
>  
>  @item znver4
>  AMD Family 19h Zen version 4.
> -
> -@item x86-64
> -Baseline x86-64 microarchitecture level (as defined in x86-64 psABI).
> -
> -@item x86-64-v2
> -x86-64-v2 microarchitecture level.
> -
> -@item x86-64-v3
> -x86-64-v3 microarchitecture level.
> -
> -@item x86-64-v4
> -x86-64-v4 microarchitecture level.
>  @end table
>  
>  Here is an example:
> @@ -22002,6 +21990,16 @@ VPCLMULQDQ instructions.
>  AVX512VNNI instructions.
>  @item avx512bitalg
>  AVX512BITALG instructions.
> +@item x86-64
> +Baseline x86-64 microarchitecture level (as defined in x86-64 psABI).
> +@item x86-64-v2
> +x86-64-v2 microarchitecture level.
> +@item x86-64-v3
> +x86-64-v3 microarchitecture level.
> +@item x86-64-v4
> +x86-64-v4 microarchitecture level.
> +
> +
>  @end table
>  
>  Here is an example:
> diff --git a/gcc/testsuite/gcc.target/i386/builtin_target.c 
> b/gcc/testsuite/gcc.target/i386/builtin_target.c
> index 3e7505a8c3a..fff643c13b0 100644
> --- a/gcc/testsuite/gcc.target/i386/builtin_target.c
> +++ b/gcc/testsuite/gcc.target/i386/builtin_target.c
> @@ -95,6 +95,11 @@ quick_check ()
>  
>assert (__builtin_cpu_supports ("avx512vpopcntdq") >= 0);
>  
> +  assert (__builtin_cpu_supports ("x86-64") >= 0);
> +  assert (__builtin_cpu_supports ("x86-64-v2") >= 0);
> +  assert 

[PATCH gcc-12] [PR104308] [analyzer] handle memmove like memcpy

[Alexandre Oliva via Gcc-patches]

Hello, David,

I'd written this patch for gcc-12, but you've worked too much on the
analyzer ;-) for it to apply in the trunk.  I wonder if there's any use
you can make of it, or of the observations in it, or whether you'd
prefer me to try to port it.

I've regstrapped it on x86_64-linux-gnu, and also tested with crosses to
riscv64-elf and arm-eabi, but with gcc-12 only, so I'm hesitant to ask
whether it's ok to install.  Trunk still fails to issue the warning for
memmove on riscv64-elf.


The testcase expects analyzer warnings for memmove just like for
memcpy.  We get them when memmove is open-coded, but not when it
remains a call.

The analyzer has code to handle memcpy calls, whose logic can be
trivially reused for memmove, but we don't get the expected warnings
and notes for memmove on riscv64-*-elf.  They wouldn't be issued for
memcpy either, if it wasn't open-coded.

I've managed to find out how to get the warning for the remaining-call
variants, but not to get the note issued for the point of creation of
the uninitialized buffer, so this patch also adds an xfail for the
note on riscv*-*-*.


for  gcc/analyzer/ChangeLog

* region-model.cc (region_model::on_call_pre): Handle memmove
and memmove_chk like memcpy.
* region-model-impl-calls.cc (region_model::impl_call_memcpy):
Check for poison in the src region.

for  gcc/testsuite/ChangeLog

* gcc.dg/analyzer/pr104308.c (test_memmove_within_uninit):
Expect creation point note to be missing on riscv*-*-*.

Change-Id: I66a856fa8e60f264a347dfd105e01c5a027d8f62
TN: VB12-006
---
 gcc/analyzer/region-model-impl-calls.cc  |1 +
 gcc/analyzer/region-model.cc |4 
 gcc/testsuite/gcc.dg/analyzer/pr104308.c |2 +-
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/analyzer/region-model-impl-calls.cc 
b/gcc/analyzer/region-model-impl-calls.cc
index 621e7002ffb38..21b10e4b477db 100644
--- a/gcc/analyzer/region-model-impl-calls.cc
+++ b/gcc/analyzer/region-model-impl-calls.cc
@@ -521,6 +521,7 @@ region_model::impl_call_memcpy (const call_details )
 = m_mgr->get_sized_region (dest_reg, NULL_TREE, num_bytes_sval);
   const svalue *src_contents_sval
 = get_store_value (sized_src_reg, cd.get_ctxt ());
+  check_for_poison (src_contents_sval, cd.get_arg_tree (1), cd.get_ctxt ());
   set_value (sized_dest_reg, src_contents_sval, cd.get_ctxt ());
 }
 
diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index 23837a173460e..e0e95ae514576 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -1421,6 +1421,10 @@ region_model::on_call_pre (const gcall *call, 
region_model_context *ctxt,
  case BUILT_IN_MALLOC:
impl_call_malloc (cd);
return false;
+ case BUILT_IN_MEMMOVE:
+ case BUILT_IN_MEMMOVE_CHK:
+   /* We can use impl_call_memcpy until overlap checking is
+  added to it.  */
  case BUILT_IN_MEMCPY:
  case BUILT_IN_MEMCPY_CHK:
impl_call_memcpy (cd);
diff --git a/gcc/testsuite/gcc.dg/analyzer/pr104308.c 
b/gcc/testsuite/gcc.dg/analyzer/pr104308.c
index a3a0cbb731776..e6a2c8821bf54 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pr104308.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pr104308.c
@@ -6,7 +6,7 @@
 
 int test_memmove_within_uninit (void)
 {
-  char s[5]; /* { dg-message "region created on stack here" } */
+  char s[5]; /* { dg-message "region created on stack here" "" { xfail 
riscv*-*-* } } */
   memmove(s, s + 1, 2); /* { dg-warning "use of uninitialized value" } */
   return 0;
 }

-- 
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 

[PATCH] i386: Save/restore recog_data in ix86_vector_duplicate_value [PR106577]

[Jakub Jelinek via Gcc-patches]

Hi!

On Tue, Aug 16, 2022 at 09:14:06AM +0100, Richard Sandiford via Gcc-patches 
wrote:
> IMO the correct low-effort fix is to save and restore recog_data
> in ix86_vector_duplicate_value.  It's a relatively big copy,
> but the current code is pretty wasteful anyway (allocating at
> least a new SET and INSN for every query).  Compared to the
> overhead of doing that, a copy to and from the stack shouldn't
> be too bad.

The following patch does that.
It isn't the first spot in the compiler that does that, not even the first
spot in the i386 backend.
In i386-expand.cc beyond these 2 recog_memoized calls there is one in
expand_vselect, but I think it is unlikely we'd run into these issues trying
to expand new permutations from splitters.

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

2022-12-02  Jakub Jelinek  

PR target/106577
* config/i386/i386-expand.cc (ix86_vector_duplicate_value): Save/restore
recog_data around recog_memoized calls.

* gcc.target/i386/pr106577.c: New test.

--- gcc/config/i386/i386-expand.cc.jj   2022-12-01 09:29:15.233466321 +0100
+++ gcc/config/i386/i386-expand.cc  2022-12-01 14:05:55.901157211 +0100
@@ -15187,6 +15187,10 @@ ix86_vector_duplicate_value (machine_mod
   bool ok;
   rtx_insn *insn;
   rtx dup;
+  /* Save/restore recog_data in case this is called from splitters
+ or other routines where recog_data needs to stay valid across
+ force_reg.  See PR106577.  */
+  recog_data_d recog_data_save = recog_data;
 
   /* First attempt to recognize VAL as-is.  */
   dup = gen_vec_duplicate (mode, val);
@@ -15212,6 +15216,7 @@ ix86_vector_duplicate_value (machine_mod
   ok = recog_memoized (insn) >= 0;
   gcc_assert (ok);
 }
+  recog_data = recog_data_save;
   return true;
 }
 
--- gcc/testsuite/gcc.target/i386/pr106577.c.jj 2022-12-01 14:13:03.973872383 
+0100
+++ gcc/testsuite/gcc.target/i386/pr106577.c2022-12-01 14:13:03.973872383 
+0100
@@ -0,0 +1,10 @@
+/* PR target/106577 */
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O2 -mavx" } */
+
+int i;
+void
+foo (void)
+{
+  i ^= !(((unsigned __int128)0xf0f0f0f0f0f0f0f0 << 64 | 0xf0f0f0f0f0f0f0f0) & 
i);
+}


Jakub

Re: [PATCH] [testsuite] [riscv] skip ssa-sink-18.c

[Kito Cheng via Gcc-patches]

OK, thanks!

On Fri, Dec 2, 2022 at 5:24 PM Alexandre Oliva via Gcc-patches
 wrote:
>
>
> On riscv64, despite being lp64, we choose two IV candidates as on arm,
> which prevents some of the expected sinking.  Add an xfail for it.
>
> Regstraped on x86_64-linux-gnu, also tested with crosses to riscv64-elf
> and arm-eabi.  Ok to install?
>
>
> for  gcc/testsuite/ChangeLog
>
> * gcc.dg/tree-ssa/ssa-sink-18.c: xfail sink2 on riscv64.
> ---
>  gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c |7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c
> index 421c78eba50f8..9ac0fc6e4de55 100644
> --- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c
> @@ -207,6 +207,9 @@ compute_on_bytes (uint8_t *in_data, int in_len, uint8_t 
> *out_data, int out_len)
>  from bb 31 to bb 33"
>  When -m32, Power and X86 will sink 3 instructions, but arm ilp32 couldn't
>  sink due to ivopts chooses two IV candidates instead of one, which is
> -expected, so this case is restricted to lp64 only so far.  */
> +expected, so this case is restricted to lp64 only so far.  This different
> +ivopts choice affects riscv64 as well, probably because it also lacks
> +base+index addressing modes, so the ip[len] address computation can't be
> +made from the IV computation above.  */
>
> - /* { dg-final { scan-tree-dump-times "Sunk statements: 4" 1 "sink2" { 
> target lp64 } } } */
> + /* { dg-final { scan-tree-dump-times "Sunk statements: 4" 1 "sink2" { 
> target lp64 xfail { riscv64-*-* } } } } */
>
> --
> 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] [riscv] uninit-pred-9_b bogus warning

[Kito Cheng via Gcc-patches]

OK, thanks :)

On Fri, Dec 2, 2022 at 5:21 PM Alexandre Oliva via Gcc-patches
 wrote:
>
>
> Like other platforms, riscv hits the uninitialized warning because the
> optimizations don't eliminate the nonviable path that would enable it
> to be omitted.
>
> Regstraped on x86_64-linux-gnu, also tested with crosses to riscv64-elf
> and arm-eabi.  Ok to install?
>
>
> for  gcc/testsuite/ChangeLog
>
> * gcc.dg/uninit-pred-9_b.c: Add riscv*-*-* to the xfail list
> for the bogus warning.
> ---
>  gcc/testsuite/gcc.dg/uninit-pred-9_b.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.dg/uninit-pred-9_b.c 
> b/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
> index 53c4a5399eaa3..c8f427b12c0ab 100644
> --- a/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
> +++ b/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
> @@ -17,7 +17,7 @@ int foo (int n, int l, int m, int r)
>
>if (l > 100)
>  if ( (n <= 9) &&  (m < 100)  && (r < 19) )
> -  blah(v); /* { dg-bogus "uninitialized" "bogus warning" { xfail 
> powerpc64*-*-* cris-*-* } } */
> +  blah(v); /* { dg-bogus "uninitialized" "bogus warning" { xfail 
> powerpc64*-*-* cris-*-* riscv*-*-* } } */
>
>if ( (n <= 8) &&  (m < 99)  && (r < 19) )
>blah(v); /* { dg-bogus "uninitialized" "pr101674" { xfail mmix-*-* } } 
> */
> --
> 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 

[PATCH] [arm] xfail fp-uint64-convert-double tests

[Alexandre Oliva via Gcc-patches]

The FP emulation on ARM doesn't take rounding modes into account.  The
tests require hard_float, but that only tests for calls when adding
doubles.  There are arm targets that support hardware adds, but that
emulate conversions.

Regstraped on x86_64-linux-gnu, also tested with crosses to riscv64-elf
and arm-eabi.  Ok to install?

PS: I've pondered changing hard_float instead, but decided that could
impact other tests that rely on its current behavior.  Then I considered
adding a variant of hard_float that tested for conversions, but thought
that it was overkill.


for  gcc/testsuite/ChangeLog

* gcc.dg/torture/fp-uint64-convert-double-1.c: Expect fail on
arm-*-eabi*.
* gcc.dg/torture/fp-uint64-convert-double-2.c: Likewise.
---
 .../gcc.dg/torture/fp-uint64-convert-double-1.c|2 +-
 .../gcc.dg/torture/fp-uint64-convert-double-2.c|2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/torture/fp-uint64-convert-double-1.c 
b/gcc/testsuite/gcc.dg/torture/fp-uint64-convert-double-1.c
index 0c7bf003e93ed..61cfa96374631 100644
--- a/gcc/testsuite/gcc.dg/torture/fp-uint64-convert-double-1.c
+++ b/gcc/testsuite/gcc.dg/torture/fp-uint64-convert-double-1.c
@@ -1,5 +1,5 @@
 /* PR84407 */
-/* { dg-do run } */
+/* { dg-do run { xfail { arm-*-eabi* } } } */
 /* { dg-require-effective-target fenv } */
 /* { dg-require-effective-target hard_float } */
 /* { dg-additional-options "-frounding-math -fexcess-precision=standard" } */
diff --git a/gcc/testsuite/gcc.dg/torture/fp-uint64-convert-double-2.c 
b/gcc/testsuite/gcc.dg/torture/fp-uint64-convert-double-2.c
index ac24b351a46d6..b32b28a329580 100644
--- a/gcc/testsuite/gcc.dg/torture/fp-uint64-convert-double-2.c
+++ b/gcc/testsuite/gcc.dg/torture/fp-uint64-convert-double-2.c
@@ -1,5 +1,5 @@
 /* PR84407 */
-/* { dg-do run } */
+/* { dg-do run { xfail { arm-*-eabi* } } } */
 /* { dg-require-effective-target fenv } */
 /* { dg-require-effective-target hard_float } */
 /* { dg-additional-options "-frounding-math" } */

-- 
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 

[PATCH] [PR40457] [arm] expand SI-aligned movdi into pair of movsi

[Alexandre Oliva via Gcc-patches]

When expanding a misaligned DImode move, emit aligned SImode moves if
the parts are sufficiently aligned.  This enables neighboring stores
to be peephole-combined into stm, as expected by the PR40457 testcase,
even after SLP vectorizes the originally aligned SImode stores into a
misaligned DImode store.

Regstraped on x86_64-linux-gnu, also tested with crosses to riscv64-elf
and arm-eabi (tms570).  Ok to install?


for  gcc/ChangeLog

PR target/40457
* config/arm/arm.md (movmisaligndi): Prefer aligned SImode
moves.
---
 gcc/config/arm/arm.md |   12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 69bf343fb0ed6..a9eb0299aa761 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -12783,8 +12783,16 @@ (define_expand "movmisaligndi"
   rtx hi_op0 = gen_highpart_mode (SImode, DImode, operands[0]);
   rtx hi_op1 = gen_highpart_mode (SImode, DImode, operands[1]);
 
-  emit_insn (gen_movmisalignsi (lo_op0, lo_op1));
-  emit_insn (gen_movmisalignsi (hi_op0, hi_op1));
+  if (aligned_operand (lo_op0, SImode) && aligned_operand (lo_op1, SImode))
+{
+  emit_move_insn (lo_op0, lo_op1);
+  emit_move_insn (hi_op0, hi_op1);
+}
+  else
+{
+  emit_insn (gen_movmisalignsi (lo_op0, lo_op1));
+  emit_insn (gen_movmisalignsi (hi_op0, hi_op1));
+}
   DONE;
 })
 

-- 
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 

[PATCH] [PR42093] [arm] [thumb2] disable tree-dce for test

[Alexandre Oliva via Gcc-patches]

CD-DCE introduces blocks to share common PHI nodes, which replaces a
backwards branch that used to prevent the thumb2 jump table shortening
that PR42093 tested for.  In order to keep on testing that the
backward branch prevents the jumptable shortening, disable tree-dce.

Regstraped on x86_64-linux-gnu, also tested with crosses to riscv64-elf
and arm-eabi.  Ok to install?


for  gcc/testsuite/ChangeLog

PR target/42093
* gcc.target/arm/pr42093.c: Disable tree-dce.
---
 gcc/testsuite/gcc.target/arm/pr42093.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/arm/pr42093.c 
b/gcc/testsuite/gcc.target/arm/pr42093.c
index 7ba2f933eef81..69b1470607c7f 100644
--- a/gcc/testsuite/gcc.target/arm/pr42093.c
+++ b/gcc/testsuite/gcc.target/arm/pr42093.c
@@ -1,4 +1,4 @@
-/* { dg-options "-mthumb -O2 -fno-reorder-blocks" }  */
+/* { dg-options "-mthumb -O2 -fno-reorder-blocks -fno-tree-dce" }  */
 /* { dg-require-effective-target arm_thumb2_ok } */
 /* { dg-final { scan-assembler-not "tbb" } } */
 /* { dg-final { scan-assembler-not "tbh" } } */

-- 
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 

[PATCH] [testsuite] [arm/aarch64] -fno-short-enums for auto-init-[12].c

[Alexandre Oliva via Gcc-patches]

On arm-eabi, and possibly on other platforms, -fshort-enums is enabled
by default, which breaks some tests' expectations as to enum sizes
with DEFERRED_INIT.  Disable short enums so that the expectations are
met.

Regstraped on x86_64-linux-gnu, also tested with crosses to riscv64-elf
and arm-eabi.  Ok to install?


for  gcc/testsuite/ChangeLog

* c-c++-common/auto-init-1.c: Add -fno-short-enums.
* c-c++-common/auto-init-2.c: Likewise.
* gcc.dg/debug/btf/btf-enum-1.c: Likewise.
---
 gcc/testsuite/c-c++-common/auto-init-1.c|2 +-
 gcc/testsuite/c-c++-common/auto-init-2.c|2 +-
 gcc/testsuite/gcc.dg/debug/btf/btf-enum-1.c |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/auto-init-1.c 
b/gcc/testsuite/c-c++-common/auto-init-1.c
index df04358728bab..3e6a4984eea22 100644
--- a/gcc/testsuite/c-c++-common/auto-init-1.c
+++ b/gcc/testsuite/c-c++-common/auto-init-1.c
@@ -1,6 +1,6 @@
 /* Verify zero initialization for integer and pointer type automatic 
variables.  */
 /* { dg-do compile { target { ilp32 || lp64 } } } */
-/* { dg-options "-ftrivial-auto-var-init=zero -fdump-tree-gimple" } */
+/* { dg-options "-ftrivial-auto-var-init=zero -fno-short-enums 
-fdump-tree-gimple" } */
 
 #ifndef __cplusplus
 # define bool _Bool
diff --git a/gcc/testsuite/c-c++-common/auto-init-2.c 
b/gcc/testsuite/c-c++-common/auto-init-2.c
index 6ac63bb1ddac1..d356e508b836f 100644
--- a/gcc/testsuite/c-c++-common/auto-init-2.c
+++ b/gcc/testsuite/c-c++-common/auto-init-2.c
@@ -1,6 +1,6 @@
 /* Verify pattern initialization for integer and pointer type automatic 
variables.  */
 /* { dg-do compile { target { ilp32 || lp64 } } } */
-/* { dg-options "-ftrivial-auto-var-init=pattern -fdump-tree-gimple" } */
+/* { dg-options "-ftrivial-auto-var-init=pattern -fno-short-enums 
-fdump-tree-gimple" } */
 
 #ifndef __cplusplus
 # define bool _Bool
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-enum-1.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-enum-1.c
index 7e940529f1b6d..2887cb1c5f244 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-enum-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-enum-1.c
@@ -1,7 +1,7 @@
 /* Test BTF generation for enums.  */
 
 /* { dg-do compile } */
-/* { dg-options "-O0 -gbtf -dA" } */
+/* { dg-options "-O0 -gbtf -fno-short-enums -dA" } */
 
 /* { dg-final { scan-assembler-times "\[\t \]0x604\[\t 
\]+\[^\n\]*btt_info" 1 } } */
 /* { dg-final { scan-assembler-times "\[\t \]0x8603\[\t 
\]+\[^\n\]*btt_info" 1 } } */


-- 
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 

[PATCH] [testsuite] [riscv] skip ssa-sink-18.c

[Alexandre Oliva via Gcc-patches]

On riscv64, despite being lp64, we choose two IV candidates as on arm,
which prevents some of the expected sinking.  Add an xfail for it.

Regstraped on x86_64-linux-gnu, also tested with crosses to riscv64-elf
and arm-eabi.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.dg/tree-ssa/ssa-sink-18.c: xfail sink2 on riscv64.
---
 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c
index 421c78eba50f8..9ac0fc6e4de55 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-18.c
@@ -207,6 +207,9 @@ compute_on_bytes (uint8_t *in_data, int in_len, uint8_t 
*out_data, int out_len)
 from bb 31 to bb 33"
 When -m32, Power and X86 will sink 3 instructions, but arm ilp32 couldn't
 sink due to ivopts chooses two IV candidates instead of one, which is
-expected, so this case is restricted to lp64 only so far.  */
+expected, so this case is restricted to lp64 only so far.  This different
+ivopts choice affects riscv64 as well, probably because it also lacks
+base+index addressing modes, so the ip[len] address computation can't be
+made from the IV computation above.  */
 
- /* { dg-final { scan-tree-dump-times "Sunk statements: 4" 1 "sink2" { target 
lp64 } } } */
+ /* { dg-final { scan-tree-dump-times "Sunk statements: 4" 1 "sink2" { target 
lp64 xfail { riscv64-*-* } } } } */

-- 
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 

[PATCH] [testsuite] [riscv] uninit-pred-9_b bogus warning

[Alexandre Oliva via Gcc-patches]

Like other platforms, riscv hits the uninitialized warning because the
optimizations don't eliminate the nonviable path that would enable it
to be omitted.

Regstraped on x86_64-linux-gnu, also tested with crosses to riscv64-elf
and arm-eabi.  Ok to install?


for  gcc/testsuite/ChangeLog

* gcc.dg/uninit-pred-9_b.c: Add riscv*-*-* to the xfail list
for the bogus warning.
---
 gcc/testsuite/gcc.dg/uninit-pred-9_b.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/uninit-pred-9_b.c 
b/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
index 53c4a5399eaa3..c8f427b12c0ab 100644
--- a/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
+++ b/gcc/testsuite/gcc.dg/uninit-pred-9_b.c
@@ -17,7 +17,7 @@ int foo (int n, int l, int m, int r)
 
   if (l > 100)
 if ( (n <= 9) &&  (m < 100)  && (r < 19) )
-  blah(v); /* { dg-bogus "uninitialized" "bogus warning" { xfail 
powerpc64*-*-* cris-*-* } } */
+  blah(v); /* { dg-bogus "uninitialized" "bogus warning" { xfail 
powerpc64*-*-* cris-*-* riscv*-*-* } } */
 
   if ( (n <= 8) &&  (m < 99)  && (r < 19) )
   blah(v); /* { dg-bogus "uninitialized" "pr101674" { xfail mmix-*-* } } */
-- 
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 2/3]rs6000: NFC use sext_hwi to replace ((v&0xf..f)^0x80..0) - 0x80..0

[Kewen.Lin via Gcc-patches]

on 2022/12/1 20:16, guojiufu wrote:
> On 2022-12-01 15:10, Jiufu Guo via Gcc-patches wrote:
>> Hi Kewen,
>>
>> 在 12/1/22 2:11 PM, Kewen.Lin 写道:
>>> on 2022/12/1 13:35, Jiufu Guo wrote:
 Hi Kewen,

 Thanks for your quick and insight review!

 在 12/1/22 1:17 PM, Kewen.Lin 写道:
> Hi Jeff,
>
> on 2022/12/1 09:36, Jiufu Guo wrote:
>> Hi,
>>
>> This patch just uses sext_hwi to replace the expression like:
>> ((value & 0xf..f) ^ 0x80..0) - 0x80..0 for rs6000.cc and rs6000.md.
>>
>> Bootstrap & regtest pass on ppc64{,le}.
>> Is this ok for trunk?
>
> You didn't say it clearly but I guessed you have grepped in the whole
> config/rs6000 directory, right?  I noticed there are still two places
> using this kind of expression in function constant_generates_xxspltiw,
> but I assumed it's intentional as their types are not HOST_WIDE_INT.
>
> gcc/config/rs6000/rs6000.cc:  short sign_h_word = ((h_word & 0x) 
> ^ 0x8000) - 0x8000;
> gcc/config/rs6000/rs6000.cc:  int sign_word = ((word & 0x) ^ 
> 0x8000) - 0x8000;
>
> If so, could you state it clearly in commit log like "with type
> signed/unsigned HOST_WIDE_INT" or similar?
>
 Good question!

 And as you said sext_hwi is more for "signed/unsigned HOST_WIDE_INT".
 For these two places, it seems sext_hwi is not needed actually!
 And I did see why these expressions are used, may be just an assignment
 is ok.
>>>
>>> ah, I see.  I agree using the assignment is quite enough.  Could you
>>> please also simplify them together?  Since they are with the form
>>> "((value & 0xf..f) ^ 0x80..0) - 0x80..0" too, and can be refactored
>>> in a better way.  Thanks!
>>
>> Sure, I believe just "short sign_h_word = vsx_const->half_words[0];"
>> should be correct :-), and included in the updated patch.
>>
>> Updated patch is attached,  bootstrap is on going.
> 

on 2022/12/1 15:10, Jiufu Guo wrote:
> From 8aa8e1234b6ec34473434951a3a6177253aac770 Mon Sep 17 00:00:00 2001
> From: Jiufu Guo 
> Date: Wed, 30 Nov 2022 13:13:37 +0800
> Subject: [PATCH 2/2]rs6000: update ((v&0xf..f)^0x80..0) - 0x80..0 with code: 
> like sext_hwi
> 

May be shorter with "rs6000: Update sign extension computation with sext_hwi"?

> This patch just replaces the expression like: 
> ((value & 0xf..f) ^ 0x80..0) - 0x80..0 to better code(e.g. sext_hwi) for
> rs6000.cc, rs6000.md and predicates.md (files under rs6000/).


> Bootstrap and regtest pass on ppc64{,le}.
> 

Thanks for updating and testing, this patch is OK.

BR,
Kewen

Re: [PATCH v2] match.pd: rewrite select to branchless expression

[Richard Biener via Gcc-patches]

On Thu, Dec 1, 2022 at 7:57 PM Michael Collison  wrote:
>
> Richard,
>
> Can you submit this patch for me while I sort out git write access?

Done.  I had to apply the patch manually - in future please make sure
to send patches that can be applied with git am.

Thanks,
Richard.

> On 11/18/22 07:57, Richard Biener wrote:
> > On Fri, Nov 11, 2022 at 3:28 AM Michael Collison  
> > wrote:
> >> This patches transforms ((x & 0x1) == 0) ? y : z  y -into
> >> (-(typeof(y))(x & 0x1) & z)  y, where op is a '^' or a '|'. It also
> >> transforms (cond (and (x , 0x1) != 0), (z op y), y ) into (-(and (x ,
> >> 0x1)) & z ) op y.
> >>
> >> Matching this patterns allows GCC to generate branchless code for one of
> >> the functions in coremark.
> >>
> >> Bootstrapped and tested on x86 and RISC-V. Okay?
> > OK.
> >
> > Thanks,
> > Richard.
> >
> >> Michael.
> >>
> >> 2022-11-10  Michael Collison  
> >>
> >>   * match.pd ((x & 0x1) == 0) ? y : z  y
> >>   -> (-(typeof(y))(x & 0x1) & z)  y.
> >>
> >> 2022-11-10  Michael Collison 
> >>
> >>   * gcc.dg/tree-ssa/branchless-cond.c: New test.
> >>
> >> ---
> >>
> >> Changes in v2:
> >>
> >> - Rewrite comment to use C syntax
> >>
> >> - Guard against 1-bit types
> >>
> >> - Simplify pattern by using zero_one_valued_p
> >>
> >>gcc/match.pd  | 24 +
> >>.../gcc.dg/tree-ssa/branchless-cond.c | 26 +++
> >>2 files changed, 50 insertions(+)
> >>create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/branchless-cond.c
> >>
> >> diff --git a/gcc/match.pd b/gcc/match.pd
> >> index 194ba8f5188..258531e9046 100644
> >> --- a/gcc/match.pd
> >> +++ b/gcc/match.pd
> >> @@ -3486,6 +3486,30 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> >>  (cond (le @0 integer_zerop@1) (negate@2 @0) integer_zerop@1)
> >>  (max @2 @1))
> >>
> >> +/* ((x & 0x1) == 0) ? y : z  y -> (-(typeof(y))(x & 0x1) & z)  y 
> >> */
> >> +(for op (bit_xor bit_ior)
> >> + (simplify
> >> +  (cond (eq zero_one_valued_p@0
> >> +integer_zerop)
> >> +@1
> >> +(op:c @2 @1))
> >> +  (if (INTEGRAL_TYPE_P (type)
> >> +   && TYPE_PRECISION (type) > 1
> >> +   && (INTEGRAL_TYPE_P (TREE_TYPE (@0
> >> +   (op (bit_and (negate (convert:type @0)) @2) @1
> >> +
> >> +/* ((x & 0x1) == 0) ? z  y : y -> (-(typeof(y))(x & 0x1) & z)  y 
> >> */
> >> +(for op (bit_xor bit_ior)
> >> + (simplify
> >> +  (cond (ne zero_one_valued_p@0
> >> +integer_zerop)
> >> +   (op:c @2 @1)
> >> +@1)
> >> +  (if (INTEGRAL_TYPE_P (type)
> >> +   && TYPE_PRECISION (type) > 1
> >> +   && (INTEGRAL_TYPE_P (TREE_TYPE (@0
> >> +   (op (bit_and (negate (convert:type @0)) @2) @1
> >> +
> >>/* Simplifications of shift and rotates.  */
> >>
> >>(for rotate (lrotate rrotate)
> >> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/branchless-cond.c 
> >> b/gcc/testsuite/gcc.dg/tree-ssa/branchless-cond.c
> >> new file mode 100644
> >> index 000..68087ae6568
> >> --- /dev/null
> >> +++ b/gcc/testsuite/gcc.dg/tree-ssa/branchless-cond.c
> >> @@ -0,0 +1,26 @@
> >> +/* { dg-do compile } */
> >> +/* { dg-options "-O2 -fdump-tree-optimized" } */
> >> +
> >> +int f1(unsigned int x, unsigned int y, unsigned int z)
> >> +{
> >> +  return ((x & 1) == 0) ? y : z ^ y;
> >> +}
> >> +
> >> +int f2(unsigned int x, unsigned int y, unsigned int z)
> >> +{
> >> +  return ((x & 1) != 0) ? z ^ y : y;
> >> +}
> >> +
> >> +int f3(unsigned int x, unsigned int y, unsigned int z)
> >> +{
> >> +  return ((x & 1) == 0) ? y : z | y;
> >> +}
> >> +
> >> +int f4(unsigned int x, unsigned int y, unsigned int z)
> >> +{
> >> +  return ((x & 1) != 0) ? z | y : y;
> >> +}
> >> +
> >> +/* { dg-final { scan-tree-dump-times " -" 4 "optimized" } } */
> >> +/* { dg-final { scan-tree-dump-times " & " 8 "optimized" } } */
> >> +/* { dg-final { scan-tree-dump-not "if" "optimized" } } */
> >> --
> >> 2.34.1
> >>