[Bug analyzer/107948] GCC Static Analyzer doesn't realize `0 - width <= 0` is always true when `width > 0` and `width is int` type，

[geoffreydgr at icloud dot com via Gcc-bugs]

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

--- Comment #3 from Geoffrey  ---
(In reply to CVS Commits from comment #1)
> The master branch has been updated by David Malcolm :
> 
> https://gcc.gnu.org/g:0b737090a69624dea5318c380620283f0321a92e
> 
> commit r13-4456-g0b737090a69624dea5318c380620283f0321a92e
> Author: David Malcolm 
> Date:   Thu Dec 1 21:28:55 2022 -0500
> 
> analyzer: handle comparisons against negated symbolic values [PR107948]
> 
> gcc/analyzer/ChangeLog:
> PR analyzer/107948
> * region-model-manager.cc
> (region_model_manager::maybe_fold_binop): Fold (0 - VAL) to -VAL.
> * region-model.cc (region_model::eval_condition): Handle e.g.
> "-X <= 0" as equivalent to X >= 0".
> 
> gcc/testsuite/ChangeLog:
> PR analyzer/107948
> * gcc.dg/analyzer/feasibility-pr107948.c: New test.
> 
> Signed-off-by: David Malcolm 

Thanks for your effort!

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 

[Bug c++/107953] Greater-than operator misparsed inside a lambda expression used as a template argument

[majerech.o at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Ondřej Majerech  ---
It seems that the core of PR 57 is that `A

[Bug c++/107953] Greater-than operator misparsed inside a lambda expression used as a template argument

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
I wonder if this is still an ambiguous part of the C++ grammar and all.

[Bug c++/107953] Greater-than operator misparsed inside a lambda expression used as a template argument

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
Even template defaults has issues:
template  y; }>
int t = 0;

Which is why I Pointed to PR 57.

gcc-11-20221202 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20221202 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20221202/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision 0ccdba3e5e7451b07d9858a8650478c5fb94aad1

You'll find:

 gcc-11-20221202.tar.xz   Complete GCC

  SHA256=8c09fdbb280cf95c4dabd15cf9e26648d74053a0bc65f2e8179d5e746d21da06
  SHA1=d5f396c0d23c7410f98a6cf29f359c301f8e329a

Diffs from 11-20221125 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug analyzer/107851] Issues with -Wanalyzer-allocation-size messages

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2022-12-02

--- Comment #2 from David Malcolm  ---
The above patch fixes the repeated events, but doesn't fix the repeated
diagnostics.

Keeping open to track fixing the latter; see:
  gcc/testsuite/gcc.dg/analyzer/allocation-size-multiline-2.c

[Bug fortran/107874] merge not using all its arguments

[jvdelisle at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #23 from Jerry DeLisle  ---
John,

Your original case in Comment 1 now gives:

$ gfc original.f90 
$ ./a.out 
 tstuff
 fstuff
 T
 tstuff
 fstuff
 F

So I think it is OK,  Harald's test case has function calls embedded in the
print statements within the main program and those functions have embedded
print statements themselves to the same output device which is stdout and this
is not allowed per the Fortran standard.

So the issue is only in the test case he previously committed and it is now
fixed.

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

[Bug fortran/107874] merge not using all its arguments

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #22 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r13-4473-g36a4ee406b95ae24a59b8b3f8ebe29af6fd5261e
Author: Harald Anlauf 
Date:   Fri Dec 2 22:30:16 2022 +0100

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

gcc/testsuite/ChangeLog:

PR fortran/107874
* gfortran.dg/merge_1.f90: Avoid recursive I/O.

[Bug analyzer/107851] Issues with -Wanalyzer-allocation-size messages

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:f5758fe5b430ef3447fbab947fcea32a1d995f36

commit r13-4471-gf5758fe5b430ef3447fbab947fcea32a1d995f36
Author: David Malcolm 
Date:   Fri Dec 2 16:30:51 2022 -0500

analyzer: fixes to region creation messages [PR107851]

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.

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
  

[Bug fortran/107874] merge not using all its arguments

[john.harper at vuw dot ac.nz via Gcc-bugs]

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

--- Comment #21 from john.harper at vuw dot ac.nz ---
I now have a new test case that avoids the possibility of recursive I/O
by tstuff and fstuff doing internal writes to two different character 
variables. It still reveals the merge problem. It compiles and runs with
gfortran-12 and ifort, giving different outputs.

! Must merge evaluate all 3 arguments?
program testmerge10
   implicit none
   character(7):: string(2) = ' '
   logical:: x(2) = [.true., .false.], y
   integer i
   do i = 1,2
  y = merge(tstuff(),fstuff(),x(i))
  print *,y,string
  string = ' '
   end do
contains

logical function tstuff()
 write(string(1),"(A)") ' tstuff'
 tstuff = .true.
   end function tstuff

   logical function fstuff()
 write(string(2),"(A)") ' fstuff'
 fstuff = .false.
   end function fstuff
end program testmerge10

Good luck with your bughunt!
John H

On Fri, 2 Dec 2022, anlauf at gcc dot gnu.org wrote:

> Date: Fri, 2 Dec 2022 21:05:43 +
> From: anlauf at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug fortran/107874] merge not using all its arguments
> Resent-Date: Sat, 3 Dec 2022 10:05:53 +1300 (NZDT)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
>
> --- Comment #19 from anlauf at gcc dot gnu.org ---
> (In reply to john.harper from comment #18)
>> An interesting problem! But I thought my original test case did not have
>> recursive I/O because tstuff and fstuff each print something in the
>> statement
>> y = merge(tstuff(),fstuff(),x(i))
>> but y itself is printed only in the next statement,
>> print *,y
>
> John, your original testcase in comment#0 was fine.
> I tried to extend it to check for constant as well as non-constant mask,
> and as you see I made a mistake by trying to make it smaller.  Bad idea.
>
>> Or does evaluating merge allow each of tstuff and fstuff to be evaluated
>> at the same time? I was thinking of tstuff and fstuff being evaluated
>> in succession but could there be systems in which they are evaluated
>> simultaneously?
>
> I don't recall having seen a mentioning in the standard of the order of
> evaluation of different function (or subroutine) arguments.  Do you?
>
> (Of course, if side-effects happen during that evaluation, such as I/O,
> unexpected things may happen.)
>
>> If so, whether the program is valid Fortran depends on the
>> kind of system on which it is being executed.
>
> Well, even if the print in tstuff/fstuff were a problem, one could construct
> other testcases with side-effects that might be conforming.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276

[Bug fortran/107874] merge not using all its arguments

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #20 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #19)
> I don't recall having seen a mentioning in the standard of the order of
> evaluation of different function (or subroutine) arguments.  Do you?

The closest I can find is the following in F2018:

C.5.1  Evaluation of function references (10.1.7)

(1) If more than one function reference appears in a statement, they can be
executed in any order (subject to a function result being evaluated after the
evaluation of its arguments) and their values cannot depend on the order of
execution. This lack of dependence on order of evaluation enables parallel
execution of the function references.


And:

A.2 Processor dependencies

According to this document, the following are processor dependent:
...
• the order of finalization of components of objects of derived type (7.5.6.2)
• the order of finalization when several objects are finalized as the
  consequence of a single event (7.5.6.2);

[Bug bootstrap/107950] partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
It might be the case the object files were unused in the archive so they are
not linked in the LTO front-end but now with using LTO partial linking, they
are pulled in always.

[Bug fortran/107874] merge not using all its arguments

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #19 from anlauf at gcc dot gnu.org ---
(In reply to john.harper from comment #18)
> An interesting problem! But I thought my original test case did not have 
> recursive I/O because tstuff and fstuff each print something in the 
> statement
> y = merge(tstuff(),fstuff(),x(i))
> but y itself is printed only in the next statement,
> print *,y

John, your original testcase in comment#0 was fine.
I tried to extend it to check for constant as well as non-constant mask,
and as you see I made a mistake by trying to make it smaller.  Bad idea.

> Or does evaluating merge allow each of tstuff and fstuff to be evaluated
> at the same time? I was thinking of tstuff and fstuff being evaluated
> in succession but could there be systems in which they are evaluated 
> simultaneously?

I don't recall having seen a mentioning in the standard of the order of
evaluation of different function (or subroutine) arguments.  Do you?

(Of course, if side-effects happen during that evaluation, such as I/O,
unexpected things may happen.)

> If so, whether the program is valid Fortran depends on the
> kind of system on which it is being executed.

Well, even if the print in tstuff/fstuff were a problem, one could construct
other testcases with side-effects that might be conforming.

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-02
   Keywords||diagnostic,
   ||internal-improvement
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

The following options (and maybe some in the diagnostic messages too) need to
be changed/aliased:
Wc11-c2x-compat
std=c2x

Internally the macros:
D_C2X
STD_C2X
CLK_STDC2X
CLK_GNUC2X

the language name:
c-opts.cc:  lang_hooks.name = "GNU C2X";

And a few other places.
It is early in stage 4 of GCC 13 release cycle but I will leave it up to the C
maintainers to see if they want the change for GCC 13 or wait till stage 1 of
GCC 14.

Confirmed otherwise.

[Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression

[iains at gcc dot gnu.org via Gcc-bugs]

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

Iain Sandoe  changed:

   What|Removed |Added

   Target Milestone|--- |10.5

--- Comment #15 from Iain Sandoe  ---
revised patch
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607776.html

[Bug fortran/107874] merge not using all its arguments

[john.harper at vuw dot ac.nz via Gcc-bugs]

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

--- Comment #18 from john.harper at vuw dot ac.nz ---
An interesting problem! But I thought my original test case did not have 
recursive I/O because tstuff and fstuff each print something in the 
statement
y = merge(tstuff(),fstuff(),x(i))
but y itself is printed only in the next statement,
print *,y

Or does evaluating merge allow each of tstuff and fstuff to be evaluated
at the same time? I was thinking of tstuff and fstuff being evaluated
in succession but could there be systems in which they are evaluated 
simultaneously? If so, whether the program is valid Fortran depends on the
kind of system on which it is being executed.

John Harper

On Fri, 2 Dec 2022, anlauf at gcc dot gnu.org wrote:

> Date: Fri, 2 Dec 2022 20:22:23 +
> From: anlauf at gcc dot gnu.org 
> To: John Harper 
> Subject: [Bug fortran/107874] merge not using all its arguments
> Resent-Date: Sat, 3 Dec 2022 09:22:36 +1300 (NZDT)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
>
> --- Comment #17 from anlauf at gcc dot gnu.org ---
> (In reply to Jerry DeLisle from comment #16)
>> (In reply to anlauf from comment #15)
>> --- snip ---
>>> Can you please verify?
>>
>> Yes, this fixes the test case.
>
> OK, thanks for confirming.
>
>> However if the orginal test case is valid
>> fortran we probably need to fix something else. Paul Thomas was noticing a
>> similar problem with his Finalization patches.  He was doing the
>> finalization inside trans_transfer or similar so it was blocking on a mutex
>> trying to finalize in the middle of an I/O operation.
>>
>> So in this case, my guess is the merge expression needs to be resolved
>> before the translation phase.
>
> If I interprete the tree-dump correctly, we have e.g.:
>
>  _gfortran_st_write (_parm.2);
>  {
>logical(kind=4) D.4279;
>logical(kind=4) D.4280;
>logical(kind=4) D.4281;
>logical(kind=4) D.4282;
>
>D.4279 = tstuff ();
>D.4280 = fstuff ();
>D.4281 = x[(integer(kind=8)) i + -1];
>D.4282 = D.4281 ? D.4279 : D.4280;
>_gfortran_transfer_logical_write (_parm.2, , 4);
>  }
>  _gfortran_st_write_done (_parm.2);
>
> so we start the write, then evaluate the merge(), which is tstuff()/fstuff(),
> and which does its own I/O, and then return to continue with the transfer.
>
> So this might be non-conforming code, see
>
> F2018:12.12 Restrictions on input/output statements
>
> (2) An input/output statement that is executed while another input/output
> statement is being executed is a recursive input/output statement.
> A recursive input/output statement shall not identify an external unit that
> is identified by another input/output statement being executed except that
> a child data transfer statement may identify its parent data transfer
> statement external unit.
>
> I am not sure I fully understand the last sentence in this paragraph,
> but I think the pushed testcase might be invalid and should be replaced.
>
> If you agree, I'll simply do this.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276

[Bug c++/107953] Greater-than operator misparsed inside a lambda expression used as a template argument

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=57

--- Comment #1 from Andrew Pinski  ---
I suspect this is the same issue as PR 57 .

[Bug c++/88434] [DR1835] operator< should take precedence over template argument in basic.lookup.classref

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW

--- Comment #5 from Andrew Pinski  ---
> [Accepted at the November, 2020 meeting as part of paper P1787R6 and moved to 
> DR at the February, 2021 meeting.]

[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_;

[Bug fortran/107874] merge not using all its arguments

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #16)
> (In reply to anlauf from comment #15)
> --- snip ---
> > Can you please verify?
> 
> Yes, this fixes the test case.

OK, thanks for confirming.

> However if the orginal test case is valid
> fortran we probably need to fix something else. Paul Thomas was noticing a
> similar problem with his Finalization patches.  He was doing the
> finalization inside trans_transfer or similar so it was blocking on a mutex
> trying to finalize in the middle of an I/O operation.
> 
> So in this case, my guess is the merge expression needs to be resolved
> before the translation phase.

If I interprete the tree-dump correctly, we have e.g.:

  _gfortran_st_write (_parm.2);
  {
logical(kind=4) D.4279;
logical(kind=4) D.4280;
logical(kind=4) D.4281;
logical(kind=4) D.4282;

D.4279 = tstuff ();
D.4280 = fstuff ();
D.4281 = x[(integer(kind=8)) i + -1];
D.4282 = D.4281 ? D.4279 : D.4280;
_gfortran_transfer_logical_write (_parm.2, , 4);
  }
  _gfortran_st_write_done (_parm.2);

so we start the write, then evaluate the merge(), which is tstuff()/fstuff(),
and which does its own I/O, and then return to continue with the transfer.

So this might be non-conforming code, see

F2018:12.12 Restrictions on input/output statements

(2) An input/output statement that is executed while another input/output
statement is being executed is a recursive input/output statement.
A recursive input/output statement shall not identify an external unit that
is identified by another input/output statement being executed except that
a child data transfer statement may identify its parent data transfer
statement external unit.

I am not sure I fully understand the last sentence in this paragraph,
but I think the pushed testcase might be invalid and should be replaced.

If you agree, I'll simply do this.

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 

[Bug fortran/107874] merge not using all its arguments

[jvdelisle at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Jerry DeLisle  ---
(In reply to anlauf from comment #15)
--- snip ---
> Can you please verify?

Yes, this fixes the test case.  However if the orginal test case is valid
fortran we probably need to fix something else. Paul Thomas was noticing a
similar problem with his Finalization patches.  He was doing the finalization
inside trans_transfer or similar so it was blocking on a mutex trying to
finalize in the middle of an I/O operation.

So in this case, my guess is the merge expression needs to be resolved before
the translation phase.

[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 

[Bug driver/107954] New: Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[romain.geissler at amadeus dot com via Gcc-bugs]

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

Bug ID: 107954
   Summary: Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

I raise this ticket (I agree not very important, and more a feature request
than a bug) following a similar one on C++/clang side and a remark from Aaron
Ballman:
https://github.com/llvm/llvm-project/issues/59300#issuecomment-1335623903

It seems that the future C2x standard has reached at least the feature freeze
phase and the expectations are that it will be ratified in 2023. So, it is
already the time to accept -std=c23/gnu23 as aliases of -std=c2x/gnu2x or is it
early for this ? On C++ side gcc already accepts -std=c++23 since gcc 11 as now
C++ standards seems to strictly follow the 3 years cadence.

Cheers,
Romain

[Bug bootstrap/107950] partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jonathan Wakely  ---
The vtable will only be emitted in the TU containing the key function, which is
that get_text function defined in the front end.

[Bug c++/103081] [ICE] with "using enum"

[ppalka at gcc dot gnu.org via Gcc-bugs]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org

[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 

[Bug bootstrap/107950] partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Martin Liška  ---
(In reply to Richard Biener from comment #2)
> I wonder why the linker complains?  Isn't this like
> 
> t.h
> 
> class X { foo (); bar (); baz (); };
> 
> and splitting the foo/bar/baz implementations to three TUs and then linking
> two of them partially?

I've just tried using -flto-partition=one and it hasn't helped me.

[Bug lto/107078] LTO is causing that firebird build is core dumping

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from Martin Liška  ---
> This issue is about compiler issue on linking firebird binary linked with
> LTO.

Good, so it's isql command that crashes:

make gpre
make[2]: Entering directory '/tmp/firebird-4.0.2/gen'
rm -f metadata.fdb
/tmp/firebird-4.0.2/gen/Release/firebird/bin/isql -q -i
/tmp/firebird-4.0.2/src/dbs/metadata.sql
make[2]: *** [Makefile:441: metadata.fdb] Segmentation fault (core dumped)
make[2]: *** Deleting file 'metadata.fdb'
make[2]: Leaving directory '/tmp/firebird-4.0.2/gen'
make[1]: *** [Makefile:292: master_process] Error 2

And my question is, how run it under gdb?

[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

Re: access to include path in front end

[James K. Lowden]

On Thu, 1 Dec 2022 17:14:31 + (UTC)
Michael Matz  wrote:

> > 3.  Correct the entries in the default_compilers array.  Currently I
> > have in cobol/lang-specs.h:
> > 
> > {".cob", "@cobol", 0, 0, 0},
> > {".COB", "@cobol", 0, 0, 0},
> > {".cbl", "@cobol", 0, 0, 0},
> > {".CBL", "@cobol", 0, 0, 0},
> > {"@cobol", 
> > "cobol1 %i %(cc1_options) %{!fsyntax-only:%(invoke_as)}", 
> > 0, 0, 0}, 
> 
> It misses %(cpp_unique_options) which was the reason why your -I
> arguments weren't passed to cobol1.  

If I understood you correctly, I don't need to modify gcc.cc.  I only
need to modify cobol/lang-specs.h, which I've done.  But that's
evidently not all I need to do, because it doesn't seem to work.  

The last element in the fragment in cobol/lang-specs.h is now: 

{"@cobol",
"cobol1 %i %(cc1_options) %{!fsyntax-only:%(invoke_as)} "
"%(cpp_unique_options) ",
0, 0, 0},

(using string constant concatenation).  That's the only change I made,
so far, because everything we said (AIUI) boiled down to, "just add
cpp_unique_options to your spec string".  

> You would just your new %(cobol_options), or simply '%{v} %{I*}'
> directly in addition to cc1_options.

I didn't do that.  IIUC, the 2nd element in the struct can be a string
constant or the address of a char* variable.  So, I chose a string
constant. 

Getting wiser with age, I used -### to dump the cobol1 command
line.  It appears to be consistent with observed behavior: when I run
under gdb and stop at the cobol1::main function, argc is 14, and argv
does not include the -I option. 

The -### output reports the cobol1 command line (as 14 strings,
exactly) on line 10.  In additon to what was supplied (by me, invoking
gcobol), it shows:

-quiet
-dumpdir o- -dumpbase csytst10.cbl 
-dumpbase-ext .cbl
"-main=gcc/cobol/prim/samples/CUBES/cobol/csytst10.cbl"
"-mtune=generic" 
"-march=x86-64" 
-o /tmp/ccLYrc6D.s

The -main I can explain later if it matters.  The others are magic I
don't understand and don't think matter, but I show them so you know.  

Note that I'm invoking gcobol from the build tree, using -B (among
others) to make it DTRT.  

I see the -B and -I options, and others, with their arguments, contained
in COLLECT_GCC_OPTIONS on lines 9 and 11.  I guess that represents an
environment string?  Or, anyway, a string that holds the options that
will be passed to collect2?  

The contents of COLLECT_GCC_OPTIONS appear to be a superset of the
options supplied on the cobol1 command line. 

It would seem the single change I made is less than the minimum
required, but I confess I've lost track of why anything more is
needed.  

--jkl

[Bug lto/107078] LTO is causing that firebird build is core dumping

[kloczko.tomasz at gmail dot com via Gcc-bugs]

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

--- Comment #17 from Tomasz Kłoczko  ---
> /tmp/firebird-4.0.2/gen/Release/firebird/bin/isql -q -i
> /tmp/firebird-4.0.2/src/dbs/metadata.sql
> can't format message 17:0 -- message file /usr/local/firebird/firebird.msg
> not found
> Unable to complete network request to host "localhost".
> -Failed to establish a connection.
> can't format message 17:120 -- message file /usr/local/firebird/firebird.msg
> not found

This issue has nothing to do with running firebird.
This issue is about compiler issue on linking firebird binary linked with LTO.

[Bug lto/107078] LTO is causing that firebird build is core dumping

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Martin Liška  ---
(In reply to Tomasz Kłoczko from comment #15)
> (In reply to Martin Liška from comment #14)
> > Can you please provide the exact steps on how to configure the project with
> > the corresponding options and run the crashing command? I would like to
> > attach a gdb to it.
> 
> - take fedora firebird src.rpm and unpack it
> - undomment ins spec file disable LTO
> - build package

I speak about direct use of the release tarball as I have almost no experience
with Fedora packaging system. I can configure it and build and I also see the
Segmenetation fault. However, I can't run the command manually:

/tmp/firebird-4.0.2/gen/Release/firebird/bin/isql -q -i
/tmp/firebird-4.0.2/src/dbs/metadata.sql
can't format message 17:0 -- message file /usr/local/firebird/firebird.msg not
found
Unable to complete network request to host "localhost".
-Failed to establish a connection.
can't format message 17:120 -- message file /usr/local/firebird/firebird.msg
not found

RE: Gcc - Animation Software

[Kathy Wood via Gcc]

Hi Gcc,

Can you please drop me a note if you caught the email below ?

Shall i get back with more info on this ?

Awaiting your response,

Emma

 

 

From: Kathy Wood  
Sent: Thursday, November 17, 2022 6:33 PM
To: 'Gcc' 
Subject: Gcc  - Animation Software
Importance: High

 

Hi Gcc ,

I’m emailing you to see if you would be interested in the data list of
“Animation Software” Users, Clients and Customers at discounted price?

Henceforth, we maintain a valid and updated data list of the following
technology users:

*  Adobe After Effects

*  Renderforest

*  Animaker

*  Unity

*  3ds Max Design

*  Blender

*  Powtoon

*  KeyShot

*  Moho Pro

*  CelAction2D

*  Autodesk Maya

*  Cartoon Animator 4

Ø  Clip Studio Paint, many more.

Kindly let me know if you’d like to see the more info on this ?

--
Thanks & Awaiting you’re response,
Kathy Wood | Demand Generation Expert

Please reply with an "skip" if you are not interested

 

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

[Bug fortran/107874] merge not using all its arguments

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #15 from anlauf at gcc dot gnu.org ---
Created attachment 54006
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54006=edit
Modified testcase

I found that I get a hang on my system when I specify -fopenmp.

It appears that there is a deadlock due to the evaluation of the merge
arguments during the print.  So changing the testcase as attached might
fix the problem.

Can you please verify?

[Bug tree-optimization/107828] tree-inlining would generate SSA with incorrect def stmt

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Martin Jambor  ---
I don't see any correctness issue here.  It is true that when IPA-SRA
needs to create a temporary SSA_NAME for an assignment with
VIEW_CONVERT_EXPR (that is the only statement that extra_stmts can
contain at the moment), the SSA_NAME then get's re-mapped to another
while woe could have just re-use the existing one, it is already
created within the new function.

We could use the knowledge that extra_stmts is really only this one
statement or nothing and avoid the remapping but that would be at the
expense of universality and extensibility of the interface between
tree-inline.cc and ipa-param-manipulations.cc.

Please let me know if I am missing something (and preferably with a
test-case that demonstrates the problem).

[Bug c++/107953] New: Greater-than operator misparsed inside a lambda expression used as a template argument

[majerech.o at gmail dot com via Gcc-bugs]

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

Bug ID: 107953
   Summary: Greater-than operator misparsed inside a lambda
expression used as a template argument
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: majerech.o at gmail dot com
  Target Milestone: ---

template 
void
f() { }

constexpr auto g = f<[] (int x, int y) { return x > y; }>;

This produces the following diagnostic:
: In lambda function:
:5:50: error: expected ';' before '>' token
5 | constexpr auto g = f<[] (int x, int y) { return x > y; }>;
  |  ^~
  |  ;
:5:51: error: expected primary-expression before '>' token
5 | constexpr auto g = f<[] (int x, int y) { return x > y; }>;
  |   ^
ASM generation compiler returned: 1
: In lambda function:
:5:50: error: expected ';' before '>' token
5 | constexpr auto g = f<[] (int x, int y) { return x > y; }>;
  |  ^~
  |  ;
:5:51: error: expected primary-expression before '>' token
5 | constexpr auto g = f<[] (int x, int y) { return x > y; }>;
  |   ^

Godbolt link to the above: https://godbolt.org/z/KG6d5E6ev

Changing the body to return (x > y); makes the error go away as a workaround.
So I speculate that the greater-than operator is misparsed as the end of the
template argument list.

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

[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend

[qinzhao at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> 
> Because after all those years, you don't really know if it is just glibc
> (which likely doesn't do that anymore), but many other programs in the wild.

Yes, Unfortunately that's the case. thanks.

[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
(In reply to qinzhao from comment #6)
> after reading the history, my understanding is:
> 
>  this gcc extension is added as a workaround to build glibc since glibc
> source code has such usage of flexible array members;
> 
> my question is: why not changing the glibc source code instead? then we
> don't need such workaround in GCC?

Because after all those years, you don't really know if it is just glibc (which
likely doesn't do that anymore), but many other programs in the wild.

[Bug lto/107078] LTO is causing that firebird build is core dumping

[kloczko.tomasz at gmail dot com via Gcc-bugs]

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

--- Comment #15 from Tomasz Kłoczko  ---
(In reply to Martin Liška from comment #14)
> Can you please provide the exact steps on how to configure the project with
> the corresponding options and run the crashing command? I would like to
> attach a gdb to it.

- take fedora firebird src.rpm and unpack it
- undomment ins spec file disable LTO
- build package

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

[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend

[qinzhao at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from qinzhao at gcc dot gnu.org ---
after reading the history, my understanding is:

 this gcc extension is added as a workaround to build glibc since glibc source
code has such usage of flexible array members;

my question is: why not changing the glibc source code instead? then we don't
need such workaround in GCC?

[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend

[siddhesh at gcc dot gnu.org via Gcc-bugs]

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

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

--- Comment #5 from Siddhesh Poyarekar  ---
(In reply to Andrew Pinski from comment #3)
> r0-44662-g2984fe64968ad7 added that documentation.
> PR 15749 shows that at one point there was code floating around (glibc?)
> that uses the extension (_G_iconv_t).

Yeah but it doesn't address bug 77650, which I agree that this is a duplicate
of.  Thanks for pointing out!

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

[Bug c/77650] struct with a nested flexible array followed by another member accepted

[siddhesh at gcc dot gnu.org via Gcc-bugs]

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

 CC||siddhesh at gcc dot gnu.org

--- Comment #6 from Siddhesh Poyarekar  ---
*** Bug 107951 has been marked as a duplicate of this bug. ***

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 

Re: Feature request: Warning when .c file gets #include'd

[Jonathan Wakely via Gcc]

On Fri, 2 Dec 2022 at 15:47, Marek Polacek wrote:
>
> On Fri, Dec 02, 2022 at 03:57:44PM +0100, Jiří Wolker via Gcc wrote:
> >
> > Hi,
> >
> > I've met a guy that is learning C and got stuck when the linker produced
> > a screenful of messages about that he did something define multiple
> > times. The cause of the problem was trivial:
> >
> > He did ``#include "something.c"'' in his code.
> >
> > In the past, I also did this thing multiple times and I would appreciate
> > a warning produced by the gcc when compiling C/C++ file that includes a
> > file ending in .c, .cx, .cpp or .cxx.
> >
> > What do you think about that?
> >
> > I would prefer to make this enabled when -Wextra is used.
>
> The problem is that a lot of beginners don't use -Wextra, so the
> warning wouldn't be displayed anyway.

Right. If the fact you're including a non-header file (which is
**never** done by any tutorials or example code **anywhere**) isn't
enough of a discouragement, a warning that nobody ever sees isn't
going to help.

And there are lots of ways to get the same linker errors. Defining
functions in a header file and not making them 'inline' (or 'static
inline' or whatever C99 says is the right way to do that) will produce
the same results, but your warning wouldn't help.

> > Based on my past experience with using .c files in the include
> > directive, I can think of these problems.
> >
> >   - Sometimes, I want to include a file that is definitely not a header,
> > but also it is not a stand-alone source file. I personally prefer
> > using .inc suffix, but some people possibly terminate the file names
> > with .c suffix like a source file.
> >
> > Example:  list of enum fields included from a separate file that was
> >   generated by a script
> >
> >   - In some projects, someone can deliberately want to include another
> > source file. For example, this can happen when doing unit tests and
> > you do not want to specify the source file name on the command line.
>
> Indeed, e.g. elfutils uses this a lot:
> #define LIBELFBITS 64
> #include "elf32_xlatetom.c"
>
> We use including .c in our testsuite a lot as well.

Libstdc++ does it in several places:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B11/cow-sstream-inst.cc;h=8839f4a6f75d608ec911fb99098f5e15ab71f162;hb=HEAD#l29

[Bug c++/107023] [10/11/12/13 Regression] [[gnu::stdcall]] Crashes the compiler, but __attribute__((stdcall)) and __stdcall worrks

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The ICE part with additional -g is fixed on the trunk with PR106937
r13-3202-g67efffec9436 fix.
Even just:
--- gcc/c-family/c-pretty-print.cc
+++ gcc/c-family/c-pretty-print.cc
@@ -901,7 +901,7 @@ pp_c_attributes_display (c_pretty_printer *pp, tree a)
{
  pp_separate_with (pp, ',');
}
-  pp_tree_identifier (pp, TREE_PURPOSE (a));
+  pp_tree_identifier (pp, get_attribute_name (a));
   if (TREE_VALUE (a))
pp_c_call_argument_list (pp, TREE_VALUE (a));
 }
would prevent the ICE.
I can't reproduce any
cc1plus: out of memory allocating 18446744073537494608 bytes after a total of
3219456 bytes
nor any issue without -g though.

[Bug rtl-optimization/107949] PPC: Unnecessary rlwinm after lbzx

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-02
  Component|target  |rtl-optimization
 Target|powerpc |powerpc, aarch64
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
aarch64 has the same issue (with almost the same RTL even)


(insn 6 3 7 2 (set (reg:QI 123 [ *inp_5(D) ])
(mem:QI (reg/v/f:SI 121 [ inp ]) [0 *inp_5(D)+0 S1 A8]))
"/app/example.cpp":4:17 554 {*movqi_internal}
 (nil))
(insn 7 6 8 2 (set (reg:QI 124 [ MEM[(const unsigned char *)inp_5(D) + 1B] ])
(mem:QI (plus:SI (reg/v/f:SI 121 [ inp ])
(const_int 1 [0x1])) [0 MEM[(const unsigned char *)inp_5(D) +
1B]+0 S1 A8])) "/app/example.cpp":4:17 554 {*movqi_internal}
 (expr_list:REG_DEAD (reg/v/f:SI 121 [ inp ])
(nil)))
(insn 8 7 9 2 (set (reg:SI 125)
(xor:SI (subreg:SI (reg:QI 123 [ *inp_5(D) ]) 0)
(subreg:SI (reg:QI 124 [ MEM[(const unsigned char *)inp_5(D) + 1B]
]) 0))) "/app/example.cpp":4:17 215 {*boolsi3}
 (expr_list:REG_DEAD (reg:QI 124 [ MEM[(const unsigned char *)inp_5(D) +
1B] ])
(expr_list:REG_DEAD (reg:QI 123 [ *inp_5(D) ])
(nil
(note 9 8 21 2 NOTE_INSN_DELETED)
(insn 21 9 22 2 (set (reg:SI 3 3)
(const_int 0 [0])) "/app/example.cpp":5:1 549 {*movsi_internal1}
 (nil))
(insn 22 21 17 2 (set (reg:SI 4 4 [orig:3+4 ] [3])
(zero_extend:SI (subreg:QI (reg:SI 125) 3))) "/app/example.cpp":5:1 4
{zero_extendqisi2}
 (expr_list:REG_DEAD (reg:SI 125)
(nil)))

We lose track (didn't take into account LOAD_EXTEND_OP(QImode) is ZERO_EXTEND
?) that the memory was zero extended.

[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=77650

--- Comment #4 from Andrew Pinski  ---
I think this is a duplicate of bug 77650. See there for more details.

[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
r0-44662-g2984fe64968ad7 added that documentation.
PR 15749 shows that at one point there was code floating around (glibc?) that
uses the extension (_G_iconv_t).

Re: Feature request: Warning when .c file gets #include'd

[Marek Polacek via Gcc]

On Fri, Dec 02, 2022 at 03:57:44PM +0100, Jiří Wolker via Gcc wrote:
> 
> Hi,
> 
> I've met a guy that is learning C and got stuck when the linker produced
> a screenful of messages about that he did something define multiple
> times. The cause of the problem was trivial:
> 
> He did ``#include "something.c"'' in his code.
> 
> In the past, I also did this thing multiple times and I would appreciate
> a warning produced by the gcc when compiling C/C++ file that includes a
> file ending in .c, .cx, .cpp or .cxx.
> 
> What do you think about that?
> 
> I would prefer to make this enabled when -Wextra is used.

The problem is that a lot of beginners don't use -Wextra, so the
warning wouldn't be displayed anyway.
 
> Based on my past experience with using .c files in the include
> directive, I can think of these problems.
> 
>   - Sometimes, I want to include a file that is definitely not a header,
> but also it is not a stand-alone source file. I personally prefer
> using .inc suffix, but some people possibly terminate the file names
> with .c suffix like a source file.
> 
> Example:  list of enum fields included from a separate file that was
>   generated by a script
> 
>   - In some projects, someone can deliberately want to include another
> source file. For example, this can happen when doing unit tests and
> you do not want to specify the source file name on the command line.

Indeed, e.g. elfutils uses this a lot:
#define LIBELFBITS 64
#include "elf32_xlatetom.c"

We use including .c in our testsuite a lot as well.

So I'm afraid this would get -1 from me personally, sorry.

> If you accept that, I can try to implement that. (That would be my first
> contribution to this project and I do not know gcc codebase, but it
> looks like a relatively simple change.) Do you think that it would need
> a copyright assignment?

I think it would.

Thanks,
Marek

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

[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #10)
> Looks like a general CFG optimization if we have N forwarders to a PHI with
> the same value then we can merge them to one (it's enough to have a single
> forwarder which we can use as the remaining one even).  Note that's kind-of
> a reverse
> mergephi for same values.
> 
>  PHI 
> 
> ->
> 
>  forwarder
> |
>  PHI 
> 
> CFG cleanup will then eventually elide forwarders into the added forwarder.

Are those actually forwarder blocks though?
Doesn't the GIMPLE_PREDICT statement at the start of each one of them prevent
tree_forwarder_block_p from returning true?
As a hack I've removed them manually:
FOR_EACH_BB_FN (bb, cfun)
{
gimple_stmt_iterator gsi = gsi_after_labels (bb);
if (!gsi_end_p (gsi) && gimple_code (gsi_stmt (gsi)) == GIMPLE_PREDICT)
gsi_remove (, true);
}
in pass_if_to_switch::execute before return TODO_cleanup_cfg;, but that didn't
help.

[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend

[qinzhao at gcc dot gnu.org via Gcc-bugs]

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 CC||qinzhao at gcc dot gnu.org

--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> > ./cc1 -quiet t.c -pedantic-errors
> t.c:7:6: error: invalid use of structure with flexible array member
> [-Wpedantic]
> 7 |   F2 flex;
>   |  ^~~~
> 
> so this is supposedly a GCC extension, treating [] as [0] in this context?

I found this in the gcc doc:

https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html#Zero-Length

"A structure containing a flexible array member, or a union containing such a
structure (possibly recursively), may not be a member of a structure or an
element of an array. (However, these uses are permitted by GCC as extensions.)"

Looks like this usage is permitted by GCC extensions.

However, cannot find the details in the doc on how GCC treat these usage.

[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #7)
> However, the CFG is not collapsed and thus it fails due to:
> 
> bool
> bit_test_cluster::is_beneficial (unsigned count, unsigned uniq)
> {
>   return (((uniq == 1 && count >= 3)
>  || (uniq == 2 && count >= 5)
>  || (uniq == 3 && count >= 6)));
> }
> 
> as count == 7. and so tree-switch-conversion happens. So one can mitigate
> that with:
> 1) use switch statement instead of if series
> 2) reduce -param=switch-conversion-max-branch-ratio= that will not create so
> big CSWTCH array
> 3) disable tree-switch-conversion pass

But that just means that either iftoswitch should happen earlier or switchconv
later
so that some other pass would remove the redundancies, or iftoswitch should
perform them when it optimizes something, or switchconv should not rely on the
collapsing being done already and do it itself.
In the #c9 testcase, it is cleanup_tree_cfg (TODO_update_ssa) during ccp1 pass
that optimizes it.  But cleanup_tree_cfg (0) during iftoswitch for firewall2
doesn't do that for some reason.

[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Richard Biener  ---
Looks like a general CFG optimization if we have N forwarders to a PHI with the
same value then we can merge them to one (it's enough to have a single
forwarder which we can use as the remaining one even).  Note that's kind-of a
reverse
mergephi for same values.

 PHI 

->

 forwarder
|
 PHI 

CFG cleanup will then eventually elide forwarders into the added forwarder.

[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Jakub Jelinek  ---
Indeed, comparing that to
int firewall3(const uint8_t *restrict data) {
const uint16_t dst_port = *((const uint16_t *)data + 32);

switch (dst_port) {
case 15: return 1;
case 23: return 1;
case 47: return 1;
case 45: return 1;
case 42: return 1;
case 1: return 1;
case 2: return 1;
case 3: return 1;
default: return 0;
}
}
this one is optimized correctly.
In iftoswitch dump this one is much simpler though:
  dst_port_6 = MEM[(const uint16_t *)data_4(D) + 64B];
  switch (dst_port_6)  [INV], case 1 ... 3:  [INV], case 15:
 [INV], case 23:  [INV], case 42:  [INV], case 45:  [INV],
case 47:  [INV]>

   :
:

   :
  # _3 = PHI <1(2), 0(3)>
:
  return _3;
vs.
  dst_port_5 = MEM[(const uint16_t *)data_3(D) + 64B];
  switch (dst_port_5)  [INV], case 1:  [INV], case 2: 
[INV], case 3:  [INV], case 15:  [INV], case 23:  [INV], case
42:  [INV], case 45:
  [INV], case 47:  [INV]>

   :
:
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
:
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
:
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
:
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
:
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
:
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
:
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
:
  // predicted unlikely by early return (on trees) predictor.

   :
  # _2 = PHI <1(4), 1(5), 1(3), 1(10), 1(9), 1(8), 1(7), 1(6), 0(2)>
:
  return _2;

but I guess switchconv should be able to handle both the same.

[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better

[socketpair at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Коренберг Марк  ---
Okay, but why switch-case is not handled using fast implementation using masks
(when difference between smallest and biggest integer <=64 ?

See the first function in my first message where it works as expected.

Seems, the problem is not in converting to switch-case, but missing
optimisation for switch-case case.

[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|NEW

--- Comment #7 from Martin Liška  ---
So what happens with the current master: we first convert the if-else-if series
to switch in iftoswitch pass:

  dst_port_5 = MEM[(const uint16_t *)data_3(D) + 64B];
  switch (dst_port_5)  [INV], case 1:  [INV], case 2: 
[INV], case 3:  [INV], case 15:  [INV], case 23:  [INV], case
42:  [INV], case 45:  [INV], case 47:  [INV]>

   :
:
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
:
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
:
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
:
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
:
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
:
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
:
  // predicted unlikely by early return (on trees) predictor.
  goto ; [INV]

   :
:
  // predicted unlikely by early return (on trees) predictor.

   :
  # _2 = PHI <1(4), 1(5), 1(3), 1(10), 1(9), 1(8), 1(7), 1(6), 0(2)>

then convert tree-switch-conversion which prefers bit test if possible.
However, the CFG is not collapsed and thus it fails due to:

bool
bit_test_cluster::is_beneficial (unsigned count, unsigned uniq)
{
  return (((uniq == 1 && count >= 3)
   || (uniq == 2 && count >= 5)
   || (uniq == 3 && count >= 6)));
}

as count == 7. and so tree-switch-conversion happens. So one can mitigate that
with:
1) use switch statement instead of if series
2) reduce -param=switch-conversion-max-branch-ratio= that will not create so
big CSWTCH array
3) disable tree-switch-conversion pass

[Bug bootstrap/107950] partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Richard Biener  ---
I wonder why the linker complains?  Isn't this like

t.h

class X { foo (); bar (); baz (); };

and splitting the foo/bar/baz implementations to three TUs and then linking
two of them partially?

That is, it looks like we reference the vtable but don't emit it here or
we end up with an ODR violation because somehow LTO thinks it can
privatize some of it?

[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Martin Liška  ---
> this code should not be treated as if-else-if-else-if.

Why? It's an equivalent representation as all ifs have a return statement. One
another equivalent representation is:

switch (dst_port)
{
  case 15:
  case 23:
  case 47:
  case 45:
  case 42:
  case 1:
  case 2:
  case 3:
return 1;
  default:
return 0;
}

Feature request: Warning when .c file gets #include'd

[Jiří Wolker via Gcc]

Hi,

I've met a guy that is learning C and got stuck when the linker produced
a screenful of messages about that he did something define multiple
times. The cause of the problem was trivial:

He did ``#include "something.c"'' in his code.

In the past, I also did this thing multiple times and I would appreciate
a warning produced by the gcc when compiling C/C++ file that includes a
file ending in .c, .cx, .cpp or .cxx.

What do you think about that?

I would prefer to make this enabled when -Wextra is used.

Based on my past experience with using .c files in the include
directive, I can think of these problems.

  - Sometimes, I want to include a file that is definitely not a header,
but also it is not a stand-alone source file. I personally prefer
using .inc suffix, but some people possibly terminate the file names
with .c suffix like a source file.

Example:  list of enum fields included from a separate file that was
  generated by a script

  - In some projects, someone can deliberately want to include another
source file. For example, this can happen when doing unit tests and
you do not want to specify the source file name on the command line.

If you accept that, I can try to implement that. (That would be my first
contribution to this project and I do not know gcc codebase, but it
looks like a relatively simple change.) Do you think that it would need
a copyright assignment?

Thanks,
Jiří

[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better

[socketpair at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Коренберг Марк  ---
Not only -s problem. I think -O3 in gcc 12.2 will run faster than -O3 in gcc 13
(for this case). this code should not be treated as if-else-if-else-if. gcc 12
does its job right.

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

[Bug c++/107938] [11/12/13 Regression] ICE directly returning `this` of `extern` variable in template since r11-557

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13 Regression] ICE   |[11/12/13 Regression] ICE
   |directly returning `this`   |directly returning `this`
   |of `extern` variable in |of `extern` variable in
   |template|template since r11-557
   Keywords|needs-bisection |
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This also started with r11-557-gbeb019d346b903c16b9fd349937de444b6a8b6c0

[Bug c++/107622] Missing optimization of switch-statement

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
If you use enum with fixed underlying type, then all the values of the
underlying type are valid, even with -fstrict-enums.  Otherwise
namespace std {
enum class byte : unsigned char {};
}
couldn't work properly.  Otherwise, with -fstrict-enums, enum { A, B, C } can
have
values 0, 1, 2, 3 and without -fstrict-enums all the values of the underlying
type.
See https://eel.is/c++draft/dcl.enum#8 for more details.
So, except for the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622#c4 g
case where
we should have optimized it into constant I don't see any missed optimization
here.

[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 CC||jsm28 at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
> ./cc1 -quiet t.c -pedantic-errors
t.c:7:6: error: invalid use of structure with flexible array member
[-Wpedantic]
7 |   F2 flex;
  |  ^~~~

so this is supposedly a GCC extension, treating [] as [0] in this context?

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)

[Bug tree-optimization/107946] [13 Regression] 507.cactuBSSN_r regresses by ~9% on znver3 with PGO since r13-3875-g9e11ceef165bc0

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Richard Biener  ---
The data found for other machines/flags is also rather inconclusive with ups
and downs.

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

[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Martin Liška  ---
So the optimization is enabled after r13-1184-g57424087e82db140 where we newly
convert if-else-if series to switch, that's later converted by switch
conversion pass to the array lookup.

Now the question is why the CSWITCH happens with -Os.

[Bug c++/107939] [11/12/13 Regression] Rejects use of `extern const` variable in a template since r11-557

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Keywords|needs-bisection |
Summary|[11/12/13 Regression]   |[11/12/13 Regression]
   |Rejects use of `extern  |Rejects use of `extern
   |const` variable in a|const` variable in a
   |template|template since r11-557

--- Comment #3 from Jakub Jelinek  ---
This is rejected since r11-557-gbeb019d346b903c16b9fd349937de444b6a8b6c0

[Bug c++/107622] Missing optimization of switch-statement

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #9 from Martin Liška  ---
So as was already said, -fstrict-enums is coarse-grained and can catch only a
situation like:

enum State {A, B, C};
...
void g(const State s) {
switch(s) {
...
  case 257:
o = 13;
break;


orig.C:18:7: warning: case label value exceeds maximum value for type
[-Wswitch-outside-range]
   18 |   case 257:
  |   ^~~~

[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

[Bug c++/105221] [10/11/12/13 Regression] gcc rejects true ? [](auto) noexcept {} : [](int) {} in C++17+ (works for C++14)

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
P0012R1 added what is now http://eel.is/c++draft/temp.deduct.conv#5.2 , at that
point:
``If the original A is a function pointer type, A can be "pointer to function"
even if the deduced A is "pointer to noexcept function".
If the original A is a pointer to member function type, A can be "pointer to
member of type function" even if the deduced A is "pointer to member of type
noexcept function".''
but I don't see in pt.cc anything keyed on DEDUCE_CONV that would deal with
this.

[Bug tree-optimization/107952] New: tree-object-size: inconsistent size for flexible arrays nested in structs

[siddhesh at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 107952
   Summary: tree-object-size: inconsistent size for flexible
arrays nested in structs
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: siddhesh at gcc dot gnu.org
  Target Milestone: ---

With -fstrict-flex-arrays, there is a clearer definition of what constitutes
flexible array members, controlled by the frontend.  tree-object-size however
doesn't seem to handle this well enough when the flex array is nested.  e.g.:

typedef struct {
  char pad;
  char data[8];
} F2;

typedef struct {
  unsigned pad;
  F2 flex;
} S2;

#define NULL (void *) 0

__SIZE_TYPE__
nested_flexarray (__SIZE_TYPE__ n)
{
  S2 *p = (S2 *) __builtin_malloc (n);

  return __builtin_dynamic_object_size (p->flex.data, 1);
}

__SIZE_TYPE__
nested_flexarray2 (S2 *p)
{
  return __builtin_dynamic_object_size (p->flex.data, 1);
}

The current behaviour is to treat data as a flex array and nested_flexarray
returns the size as if it were a flex array.  nested_flexarray2 however returns
the subscripted size, thinking of it as a fixed array, which should not be the
expected behaviour with -fstrict-flex-arrays=0.  Instead it should return -1
for maximum size and perhaps 8 as minimum size.

If F2 is changed to:

typedef struct {
  char pad;
  char data[0];
} F2;

the current behaviour ends up returning 0 in both cases, which is incorrect. 
Again, it should return the size as if it were a flex array in nested_flexarray
and -1 for maximum size for nested_flexarray2.

I have a patch that does this, but I need to fix up tests that currently expect
older behaviour and wanted to get some consensus before I fixed them up.

[Bug tree-optimization/107833] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #14 from Richard Biener  ---
Created attachment 54005
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54005=edit
patch for LIM

I'm testing this patch to limit invariant motion which also fixes PR107839.

[Bug sanitizer/106739] [10/11/12/13 Regression] runtime error coredump case on c++17/20 since r11-2445-g8c00059ce058ea2a

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
I also can't reproduce it.

[Bug lto/107078] LTO is causing that firebird build is core dumping

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #14 from Martin Liška  ---
Can you please provide the exact steps on how to configure the project with the
corresponding options and run the crashing command? I would like to attach a
gdb to it.

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').  */