[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #17 from Martin Uecker  ---
Am Freitag, dem 03.03.2023 um 23:18 + schrieb isanbard at gmail dot com:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
> 
> --- Comment #16 from Bill Wendling  ---
> (In reply to Martin Uecker from comment #15)
> > Am Freitag, dem 03.03.2023 um 20:27 + schrieb isanbard at gmail dot com:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
> > > 
> > > --- Comment #14 from Bill Wendling  ---
> > > (In reply to Martin Uecker from comment #9)
> > > > > > Considering that the GNU extensions is rarely used, one could 
> > > > > > consider
> > > > > > redefining the meaning of
> > > > > > 
> > > > > > int n = 1;
> > > > > > struct {
> > > > > >   int n;
> > > > > >   char buf[n];
> > > > > > };
> > > > > > 
> > > > > > so that the 'n' refers to the member. Or we add a new syntax 
> > > > > > similar to
> > > > > > designators (which intuitively makes sense to me).
> > > > > designator might be better IMO.
> > > > > 
> > > > > a question here is:
> > > > > 
> > > > > for the following nested structure: 
> > > > > 
> > > > > struct object {
> > > > > ...
> > > > > char items;
> > > > > ...
> > > > > struct inner {
> > > > > ...
> > > > > int flex[];
> > > > > };
> > > > > } *ptr;
> > > > > 
> > > > > what kind of syntax is good to represent the upper bound of "flex" in 
> > > > > the inner
> > > > > struct with "items" in the outer structure? any suggestion?
> > > > 
> > > > I would disallow it. At least at first. It also raises some
> > > > questions: For example, one could form a pointer to the inner
> > > > struct, and then it is not clear how 'items' could be accessed
> > > > anymore.
> > > > 
> > > 
> > > That would be limiting its use in the Linux kernel. It seems that there 
> > > are
> > > ways to refer to struct members already using something like "offsetof":
> > > 
> > > struct object {
> > > ...
> > > char items;
> > > ...
> > > struct inner {
> > > ...
> > > int flex[] __attribute__((__element_count__(offsetof(struct 
> > > object,
> > > items;
> > > };
> > > } *ptr;
> > 
> > This seems to be something completely different. offsetof
> > computes the offset from the type given in its argument.
> > But it would not access the value of the member of the
> > enclosing struct. But it would not work in your example,
> > because the struct object is incomplete at this point.
> > 
> > So no, you can not use offsetof to reference a member
> > of an enclosing struct.
> > 
> "offsetof(struct foo, count)" is a fancy wrapper for "((struct foo
> *)0)->count", which is resolved during sema, where it does have the full
> structure definition. For instance, this compiles in C++:
> 
> struct a {
> int count;
> int y = ((struct a *)0)->count;
> } x;
> 
> void foo(struct a *);

This is not the case in C: https://godbolt.org/z/P7M6cdnoa

But even we make it resolve the name, which we
have to do for all proposals, it is something  different.

If offsetof it would resolve the count of a different
struct of the same *type* (here a non-existent one at 
address zero). Here we need a self reference to the
same *object*.

...


> > But I am not saying we shouldn't have the attribute first.
> > 
> I personally prefer using an attribute than the suggestion to use some other
> syntax, like:
> 
> struct foo {
> int fam[.count];
> };
> 
> It becomes less intuitive what's going on here. And might conflict with VLA's
> in structures.

The syntax with the dot would make it not conflict.  But I need
this for this use case

struct foo {
  int count;
  int (*buf)[.count];
};

so that ARRAY_SIZE(*foo->buf) works correctly and also accesses
to foo->buf are bounds checkked.  So it would make sense to 
solve to treat flexible array members in the same way.

But I agree that we should simply add the attribute now also
because it makes it possible to use it for existing code bases.

> > > It also has the benefit of
> > > allowing one to reference a variable not in the structure:
> > > 
> > > const int items;
> > > struct object {
> > > ...
> > > char items;
> > > ...
> > > struct inner {
> > > ...
> > > int flex[] __attribute__((__element_count__(items))); /* 
> > > References
> > > global "items" */
> > > };
> > > } *ptr;
> > 
> > Whether you allow this or not has nothing to do with the syntax.
> > 
> > The question is what semantics you attach to this and this is
> > also a question in your example. 
> > 
> > If you define
> > 
> > struct inner* a = ...
> > 
> > What does it say for  a->flex  ?
> > 
> I need to point out that I used "offsetof" only as an example. It's possible 
> to
> create something more robust which will carry along type information, etc.,
> which the current offsetof macro throws away. I should have made that clear.
> 
> The sanitizers that see 

Re: [wwwdocs] document modula-2 in gcc-13/changes.html (and index.html)

[Gerald Pfeifer]

Hi Gaius,

apologies, I thought you had pushed the updated patch and only now 
realized it's not in yet.

Please look into the few bits below and then go ahead and push.

On Mon, 6 Feb 2023, Gaius Mulley wrote:
>   * htdocs/frontends.html: An update to say the front end is now in
>   the development trunk.

Here we'd usually simply say

  * frontends: The Modula-2 front end is now on the 
  development trunk.

skiping "An update to say", or at least "An update to" and the "htdocs/" 
port (and adding which front end).

>   * htdocs/gcc-13/changes.html: A description of which dialects are
>   supported and the user level front end changes so far.

  * gcc-13: Note which Modula-2 dialects are...

>   * htdocs/index.html: Proposed news entry.

  * index: Announce Modula-2 inclusion 

(or something like that).

>   * htdocs/onlinedocs/index.html: PDF, PS and HTML documentation
>   links.
  * onlinedocs: Add links to Modula-2 documentation


> +The compiler is operational with GCC 10, GCC 11 GCC 12 (on
   
...GCC 11, and GCC 12...

> +GNU/Linux x86 systems).  The front end is now in the GCC development
> +trunk (GCC 13).  The front end is mostly written in Modula-2 and it
>  includes a bootstrap tool which translates Modula-2 into C/C++.

How about "It is mostly written in Modula-2 and includes..." to avoid
repetition of "the front end"?


Thank you,
Gerald

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

[bugreporter66 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from bugreporter66 at gmail dot com ---
Thanks, I will try to find out and be more specific where exactly it leaks.
It was my first attempt at reducing the code that would fit into 1MB
attachment.

Checked g++ 10.4 today, it works as it should.
11.3 and 12.1 were tested to show the issue so far.

Re: [PATCH] Always define `WIN32_LEAN_AND_MEAN` before

[Xi Ruoyao via Gcc-patches]

On Sat, 2023-01-07 at 06:52 +, Jonathan Yong via Gcc-patches wrote:
> On 1/6/23 18:10, Jakub Jelinek wrote:
> > On Sat, Jan 07, 2023 at 02:01:05AM +0800, LIU Hao via Gcc-patches
> > wrote:
> > > libgomp/
> > > 
> > > PR middle-end/108300
> > > * config/mingw32/proc.c: Define `WIN32_LEAN_AND_MEAN`
> > > before
> > > .
> > 
> > This change is ok for trunk.
> > 
> > Jakub
> > 
> 
> Pushed to master branch, thanks LH.

The patch touches libgo (w/o mentioning it in the ChangeLog).  I guess
you need to contribute the libgo part into the upstream Go runtime or
the change will be undone when Ian merges libgo next time.

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

[Bug target/109004] [10/11/12/13 Regression] wrong code for -O2 (any above -O0) with g++ 11.3 for POWER9 (cross-compiler on x86_64 host)

[bugreporter66 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from bugreporter66 at gmail dot com ---
Checked g++ 10.4 today, it works as it should.
11.3 and 12.1 were tested to show the issue so far.

The command line for building:
powerpc64le-linux-gnu-g++ -O2 -static test.cpp -o test_p64

Re: [PATCH][stage1] Remove conditionals around free()

[Jerry D via Gcc-patches]

On 3/3/23 3:32 PM, Iain Sandoe wrote:




On 3 Mar 2023, at 23:11, Bernhard Reutner-Fischer via Fortran 
 wrote:

On 2 March 2023 02:23:10 CET, Jerry D  wrote:

On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:

On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran 
wrote:

  libgfortran/caf/single.c |6 ++
  libgfortran/io/async.c   |6 ++
  libgfortran/io/format.c  |3 +--
  libgfortran/io/transfer.c|6 ++
  libgfortran/io/unix.c|3 +--


The Fortran ones are OK.



The only question I have: Is free posix compliant on all platforms?

For example ming64 or mac?


OSX / macOS are [certified] Posix compliant - but to unix03 (and might be 
missing features declared as optional at that revision, or features from later 
Posix versions).

In the case of free() man says:
"The free() function deallocates the memory allocation pointed to by ptr. If 
ptr is a NULL pointer, no operation is performed.”

Iain



  It seems sometimes we run into things like this once in a while.


I think we have the -liberty to cater even for non compliant systems either 
way, if you please excuse the pun. That's not an excuse on POSIX systems, imho.



I am certainly not a C++ expert but it seems to me this all begs for 
automatic finalization where one would not have to invoke free at all. 
I suspect the gfortran frontend is not designed for such things.





Otherwise I have no issue at all.  It is a lot cleaner.

Jerry

[Bug c++/109018] decltype of dependent expressions lookup should be done only when doing template function definition

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from qingzhe huang  ---
I agree "Note g can be still found after the declaration via argument dependent
lookup."

Can we view this issue from a different angle? The real work of parsing should
be started at "template function definition". So, if the "template function
declaration" is invalid because of "scope" of "g", then the "valid" definition
DOES NOT belong to the "invalid" declaration. i.e. There are tons of invalid
declaration are discarded as they are not required for template function
instantiation.

[GSOC] Looking for small patch/project to work on

[Rishi Raj via Gcc]

Hi everyone,

My name is Rishi Raj, and I am a third-year undergraduate studying Computer
Science and Engineering at the Indian Institute of Technology Kharagpur in
India. I wish to participate in this year's GSOC with GCC.

My progress so far:

   1. Successfully built the GCC from source using the installing gcc
   guide. (I will run the test suite today.)
   2. Read about different configuration options during installations and
   also went through the gcc-newbies-guide, which was an exciting read and
   provided an overview of how to proceed in gcc-contribution. I want to
   extend my appreciation to David for this.

After reading about the suggested projects described on GCC's GSOC page, I
found "Bypass assembler when generating LTO object files" and "C++:
Implement compiler built-in traits for the standard library traits"
interesting. Currently, I am examining the preliminary patch
https://gcc.gnu.org/ml/gcc/2014-09/msg00340.html for the first project. I
can work on a small project/patch after this in a day or two. I would
greatly appreciate your suggestions for the same.

I have taken compiler theory and laboratory courses as a part of my
institute curriculum. In the laboratory, we designed a tiny-c compiler (a
subset of GCC). In theory, I learned about different phases of
compilations, various optimization techniques, etc.

Please find my course website link for a detailed overview:
https://cse.iitkgp.ac.in/~bivasm/compiler2022.html#Lecture

This course was the starting point of my interest in compiler development,
and I want to take it further by making meaningful contributions to GCC. I
hope to make some significant contributions to GCC this summer and in the
future. I would appreciate any suggestions on taking on a small
patch/project or delving deeper into the projects I am interested in
pursuing.


Best regards,

Rishi Raj

Re: [PATCH 01/07] RISC-V: Add auto-vectorization support

[Kito Cheng via Gcc-patches]

Hi Michael Collison:

It's REALLY NOT OK that you didn't mention RiVAI and Ju-Zhe in either
changelog or add he as co-author,
apparently you HAVE references and even copy his code from
https://github.com/riscv-collab/riscv-gcc/tree/riscv-gcc-rvv-next

Re: [PATCH v5] c++: -Wdangling-reference with reference wrapper [PR107532]

[Jason Merrill via Gcc-patches]

On 3/3/23 12:50, Marek Polacek wrote:

On Fri, Mar 03, 2023 at 11:25:06AM -0500, Jason Merrill wrote:

On 3/2/23 16:24, Marek Polacek wrote:

On Wed, Mar 01, 2023 at 04:53:23PM -0500, Jason Merrill wrote:

@@ -13791,12 +13830,39 @@ std_pair_ref_ref_p (tree t)
 const int& y = (f(1), 42); // NULL_TREE
 const int& z = f(f(1)); // f(f(1))
-   EXPR is the initializer.  */
+   EXPR is the initializer.  If ARG_P is true, we're processing an argument
+   to a function; the point is to distinguish between, for example,
+
+ Ref::inner (_EXPR )
+
+   where we shouldn't warn, and
+
+ Ref::inner (_EXPR )>)
+
+   where we should warn (Ref is a reference_like_class_p so we see through
+   it.  */
static tree
-do_warn_dangling_reference (tree expr)
+do_warn_dangling_reference (tree expr, bool arg_p)
{
  STRIP_NOPS (expr);
+  if (TREE_CODE (expr) == ADDR_EXPR)
+expr = TREE_OPERAND (expr, 0);


I think if we move this here, we also need to check that expr before
STRIP_NOPS had REFERENCE_TYPE.  OK with that change.


Sorry but I don't think I can do that.  There can be CONVERT_EXPRs
that need to be stripped, whether arg_p or !arg_p.  For example, we can get
(const int *) f ((const int &) _EXPR >)
for
const int& r5 = (42, f(10));


I meant that we only want to strip ADDR_EXPR if 'expr' at the start of the
function had REFERENCE_TYPE, corresponding to


 /* Check that this argument initializes a reference, except
for
the argument initializing the object of a member function.  */
 if (!DECL_NONSTATIC_MEMBER_FUNCTION_P (fndecl)
 && !TYPE_REF_P (TREE_TYPE (arg)))
   continue;


above the code for stripping an ADDR_EXPR from an argument that your patch
removes.


I see.


If the original expr is a pointer rather than a reference, we don't want to
complain about it pointing to a temporary.


Ug, I can't make it work.  When we recurse, I can no longer check
fndecl.  How about just moving the stripping back where it was?


Sure.


-- >8 --
Here, -Wdangling-reference triggers where it probably shouldn't, causing
some grief.  The code in question uses a reference wrapper with a member
function returning a reference to a subobject of a non-temporary object:

   const Plane & meta = fm.planes().inner();

I've tried a few approaches, e.g., checking that the member function's
return type is the same as the type of the enclosing class (which is
the case for member functions returning *this), but that then breaks
Wdangling-reference4.C with std::optional.

This patch adjusts do_warn_dangling_reference so that we look through
reference wrapper classes (meaning, has a reference member and a
constructor taking the same reference type, or is std::reference_wrapper
or std::ranges::ref_view) and don't warn for them, supposing that the
member function returns a reference to a non-temporary object.

PR c++/107532

gcc/cp/ChangeLog:

* call.cc (reference_like_class_p): New.
(do_warn_dangling_reference): Add new bool parameter.  See through
reference_like_class_p.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wdangling-reference8.C: New test.
* g++.dg/warn/Wdangling-reference9.C: New test.
---
  gcc/cp/call.cc| 92 ---
  .../g++.dg/warn/Wdangling-reference8.C| 77 
  .../g++.dg/warn/Wdangling-reference9.C| 21 +
  3 files changed, 176 insertions(+), 14 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/warn/Wdangling-reference8.C
  create mode 100644 gcc/testsuite/g++.dg/warn/Wdangling-reference9.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 048b2b052f8..62536573633 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -13779,6 +13779,45 @@ std_pair_ref_ref_p (tree t)
return true;
  }
  
+/* Return true if a class CTYPE is either std::reference_wrapper or

+   std::ref_view, or a reference wrapper class.  We consider a class
+   a reference wrapper class if it has a reference member and a
+   constructor taking the same reference type.  */
+
+static bool
+reference_like_class_p (tree ctype)
+{
+  tree tdecl = TYPE_NAME (TYPE_MAIN_VARIANT (ctype));
+  if (decl_in_std_namespace_p (tdecl))
+{
+  tree name = DECL_NAME (tdecl);
+  return (name
+ && (id_equal (name, "reference_wrapper")
+ || id_equal (name, "ref_view")));
+}
+  for (tree fields = TYPE_FIELDS (ctype);
+   fields;
+   fields = DECL_CHAIN (fields))
+{
+  if (TREE_CODE (fields) != FIELD_DECL || DECL_ARTIFICIAL (fields))
+   continue;
+  tree type = TREE_TYPE (fields);
+  if (!TYPE_REF_P (type))
+   continue;
+  /* OK, the field is a reference member.  Do we have a constructor
+taking its type?  */
+  for (tree fn : ovl_range (CLASSTYPE_CONSTRUCTORS (ctype)))
+   {
+ tree args = FUNCTION_FIRST_USER_PARMTYPE (fn);
+ if (args
+ && same_type_p 

[Bug c++/109018] decltype of dependent expressions lookup should be done only when doing template function definition

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #5 from Andrew Pinski  ---
Note g can be still found after the declaration via argument dependent lookup.
Just int is a base type so it does not have a namespace associated with it.

[Bug c++/109018] decltype of dependent expressions lookup should be done only when doing template function definition

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

qingzhe huang  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED
 CC||nickhuang99 at hotmail dot com

--- Comment #4 from qingzhe huang  ---
Thank you for your detailed explanation and really appreciate it.
My only pleading argument is that the root cause of error is from GCC cannot
find correct prototype in "template declaration" which is __NOT__ mandatory for
template definition. 
For example, if I commented out the invalid template function declaration, the
parser works without issue. (https://www.godbolt.org/z/1qnTnrE1Y). So, my
argument is that GCC report error due to something which is not always
necessary. Why cannot parser postpone reporting when actually template
definition starts? Even there is not declaration, definition has all
information to work.


This will pass compilation if template declaration is commented:

// template
// decltype(g(T())) h(); // decltype(g(T())) is a dependent type

int g(int);

template
decltype(g(T())) h()
{  // redeclaration of h() uses earlier lookup
return g(T()); // although the lookup here does find g(int)
}

int i = h(); // template argument substitution fails; g(int)
  // was not in scope at the first declaration of h()

M

[Tammi Pierce via Gcc]

W I’maI hope w
S

Ping: [PATCH 1/2] testsuite: Provide means to regexp in multiline patterns

[Hans-Peter Nilsson via Gcc-patches]

Ping...

> From: Hans-Peter Nilsson 
> Date: Fri, 24 Feb 2023 20:16:03 +0100
> 
> Ok to commit?
> -- >8 --
> Those multi-line-patterns are literal.  Sometimes a regexp
> needs to be matched.  This is a start: just three elements
> are supported: "(" ")" and the compound ")?" (and on second
> thought, it can be argued that "(...)" alone is not useful).
> Note that Tcl "string map" is documented to have the desired
> effect: a once-over but no re-recognitions of previously
> replaced mapped elements.  Also, drop a doubled "containing".
> 
> testsuite:
>   * lib/multiline.exp (_build_multiline_regex): Map
>   "{re:" to "(", ":re}" to ")" and ":re?}" to ")?".
> ---
>  gcc/testsuite/lib/multiline.exp | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/testsuite/lib/multiline.exp b/gcc/testsuite/lib/multiline.exp
> index 5eccf2bbebc1..f746bc3a618e 100644
> --- a/gcc/testsuite/lib/multiline.exp
> +++ b/gcc/testsuite/lib/multiline.exp
> @@ -297,7 +297,7 @@ proc _get_lines { filename first_line last_line } {
>  
>  # Convert $multiline from a list of strings to a multiline regex
>  # We need to support matching arbitrary followup text on each line,
> -# to deal with comments containing containing DejaGnu directives.
> +# to deal with comments containing DejaGnu directives.
>  
>  proc _build_multiline_regex { multiline index } {
>  verbose "_build_multiline_regex: $multiline $index" 4
> @@ -307,7 +307,10 @@ proc _build_multiline_regex { multiline index } {
>   verbose "  line: $line" 4
>  
>   # We need to escape "^" and other regexp metacharacters.
> - set line [string map {"^" "\\^"
> + set line [string map {"\{re:" "("
> +   ":re?\}" ")?"
> +   ":re\}" ")"
> +   "^" "\\^"
> "(" "\\("
> ")" "\\)"
> "[" "\\["
> -- 
> 2.30.2
> 

☝ Buildbot (Sourceware): gccrust - retry lost connection update (retry) (master)

[builder--- via Gcc-rust]

A retry build has been detected on builder gccrust-gentoo-sparc while building 
gccrust.

Full details are available at:
https://builder.sourceware.org/buildbot/#builders/241/builds/323

Build state: retry lost connection update (retry)
Revision: (unknown)
Worker: gentoo-sparc
Build Reason: (unknown)
Blamelist: A. Wilcox , Abdul Rafey 
, Alan Modra , Aldy Hernandez 
, Alex Coplan , Alexander Monakov 
, Alexandre Oliva , Alexandre Oliva 
, Allan McRae , Andre Simoes Dias Vieira 
, Andre Vehreschild , Andre 
Vieira , Andrea Corallo 
, Andreas Krebbel , Andreas 
Schwab , Andreas Schwab , Andrew 
Carlotti , Andrew Carlotti , 
Andrew MacLeod , Andrew Pinski , 
Andrew Pinski , Andrew Stubbs , 
Antoni Boucher , Ard Biesheuvel , Arjun 
Shankar , Arnaud Charlet , Arsen 
Arsenovic , Arsen Arsenović , ArshErgon 
, Artem Klimov , Arthur Cohen 
, Avinash Sonawane , Benno Evers 
, Bernd Kuhls , Bernhard 
Reutner-Fischer , Bernhard Reutner-Fischer 
, Bill Schmidt , Bill Seurer 
, Björn Schäpers , Bob Duff 
, Boris Yakobowski , Bruce Korb 
, Bruno Haible , Cedric Landet 
, Cesar Philippidis , 
Charles-François Natali , Chenghua Xu 
, Chenghua Xu , Christoph 
Müllner , Christophe Lyon 
, Christophe Lyon , 
Chung-Ju Wu , Chung-Lin Tang , 
Claire Dross , Claudiu Zissulescu , 
Claudiu Zissulescu , Clément Chigot , 
Clément Chigot , CohenArthur , 
Cui,Lili , Cupertino Miranda 
, Dan Li , Daniel 
Mercier , Dave , David Edelsohn 
, David Faust , David Malcolm 
, David Seifert , Detlef Vollmann 
, Dimitar Dimitrov , Dimitrij Mijoski 
, Dimitrije Milosevic , 
Dimitrije Milošević , Dmitriy Anisimkov 
, Dongsheng Song , Doug Rupp 
, Ed Catmur , Ed Schonberg 
, Ed Smith-Rowland , Eric 
Biggers , Eric Botcazou , Eric 
Botcazou , Eric Gallager , 
Etienne Servais , Eugene Rozenfeld , 
Faisal Abbas <90.abbasfai...@gmail.com>, Faisal Abbas 
, Fedor Rybin , Fei Gao 
, Flavio Cruz , Florian Weimer 
, Francois-Xavier Coudert , 
Francois-Xavier Coudert , François Dumont 
, Frederik Harwath , Fritz 
Reese , Frolov Daniil , GCC 
Administrator , Gaius Mulley , Gary 
Dismukes , Georg-Johann Lay , Gerald 
Pfeifer , Ghjuvan Lacambre , Giuliano 
Belinassi , Guillermo E. Martinez 
, H.J. Lu , Hafiz Abid 
Qadeer , Hans-Peter Nilsson , Haochen 
Gui , Haochen Jiang , Harald 
Anlauf , Hongyu Wang , Hu, Lin1 
, Iain Buclaw , Iain Sandoe 
, Ian Lance Taylor , Ilya Leoshkevich 
, Immad Mir , Immad Mir 
, Indu Bhagat , Iskander 
Shakirzyanov , Jakob Hasse 
<0xja...@users.noreply.github.com>, Jakub Dupak , Jakub 
Jelinek , Jan Beulich , Jan Hubicka 
, Jan-Benedict Glaw , Jason Merrill 
, Javier Miranda , Jeff Chapman II 
, Jeff Law , Jeff Law 
, Jerry DeLisle , Jia-Wei Chen 
, Jia-wei Chen , Jiawei 
, Jin Ma , Jinyang He 
, Jiufu Guo , Joao Azevedo 
, Joel Brobecker , Joel Holdsworth 
, Joel Phillips , Joel 
Teichroeb , Joffrey Huguet , Johannes 
Kanig , Johannes Kliemann , John David 
Anglin , Jonathan Wakely , Jonathan 
Yong <10wa...@gmail.com>, Jose E. Marchesi , Joseph 
Myers , Josue Nava Bello , José Rui 
Faustino de Sousa , Ju-Zhe Zhong , 
Julia Lapenko , Julian Brown 
, Julien Bortolussi , Justin 
Squirek , Jørgen Kvalsvik 
, Keef Aragon , 
Kewen Lin , Kewen.Lin , Kim Kuparinen 
, Kito Cheng , Kong 
Lingling , Kwok Cheung Yeung , 
Kyrylo Tkachov , Kévin Le Gouguec 
, LIU Hao , Lewis Hyatt 
, Liaiss Merzougue , LiaoShihua 
, Lili Cui , Liwei Xu 
, Lorenzo Salvadore , Lulu 
Cheng , Lyra , M V V S Manoj Kumar 
, MAHAD , Maciej W. Rozycki 
, Maciej W. Rozycki , Marc 
Nieper-Wißkirchen , Marc Poulhiès 
, Marc Poulhiès , Marcel Vollweiler 
, Marco Falke , Marek Polacek 
, Mark Mentovai , Mark Wielaard 
, Martin Jambor , Martin Liska 
, Martin Liška , Martin Sebor 
, Martin Uecker , Matthias Kretz 
, Max Filippov , Mayshao 
, Meghan Denny , Michael Collison 
, Michael Eager , Michael Meissner 
, Mikael Morin , Mikhail Ablakatov 
, Monk Chiang , Murray Steele 
, Nathan Sidwell , Nathaniel Shead 
, Navid Rahimi , Nick 
Clifton , Nikos Alexandris , 
Nirmal Patel , Olivier Hainque , Owen 
Avery , Palmer Dabbelt , 
Parthib <94271200+parthib...@users.noreply.github.com>, Parthib 
, Pascal Obry , Pat Haugen 
, Patrick Bernardi , Patrick 
Palka , Paul A. Clarke , Paul Thomas 
, Paul-Antoine Arras , Pekka Seppänen 
, Peter Bergner , Petter Tomner 
, Philip Herron , Philip Herron 
, Philipp Fent , Philipp Tomsich 
, Pierre-Emmanuel Patry 
, Pierre-Marie de Rodat 
, Piotr Trojanek , Prajwal S N 
, Prathamesh Kulkarni 
, Przemyslaw Wirkus 
, Qian Jianhua , Qian Jianhua 
, Qing Zhao , Quentin Ochem 
, Raiki Tamura , Rainer Orth 
, Rainer Orth , Ramana 
Radhakrishnan , Ramana Radhakrishnan 
, Raoni Fassina Firmino , 
Raphael Moreira Zinsly , Rasmus Villemoes 
, Rasmus Villemoes , 
Richard Ball , Richard Biener , 
Richard Earnshaw , Richard Henderson , 
Richard Purdie , Richard Sandiford 
, Rimvydas Jasinskas , Robin 
Dapp , Roger Sayle , Romain 
Beguet , Ronan Desplanques , 
SainiAditya1 , Sam Feifer 
, Sam James , Samuel Thibault 
, Sandra Loosemore , Scott 
Snyder , 

Re: Patch ping

[Joseph Myers]

On Wed, 1 Mar 2023, Jakub Jelinek via Gcc-patches wrote:

> Hi!
> 
> I'd like to ping a few pending patches:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607534.html
>   - PR107846 - P1 - c-family: Account for integral promotions of left shifts 
> for -Wshift-overflow warning

OK.

> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606973.html
>   - PR107465 - P2 - c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling

OK.

> https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607104.html
>   - PR107465 - P2 - c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR 
> handling

OK.

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

[COMMITTED] testsuite: Skip gcc.dg/ipa/pr77653.c for CRIS

[Hans-Peter Nilsson via Gcc-patches]

CRIS defines DATA_ALIGNMENT such that alignment can be
applied differently to different data of the same type, when
"references to it must bind to the current definition"
(varasm.cc:align_variable).  Here, it means that more
alignment is then applied to g, but not f, so the test-case
fails because another message is emitted than the expected:
a same-alignment test dominates the not-discardable test,
and we get "Not unifying; original and alias have
incompatible alignments" rather than "Not unifying; alias
cannot be created; target is discardable".  Because this
DATA_ALIGNMENT behavior for CRIS depends on target options,
and this test is already artificial by the use of -fcommon,
better skip it.

* gcc.dg/ipa/pr77653.c: Skip for cris-*-*.
---
 gcc/testsuite/gcc.dg/ipa/pr77653.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.dg/ipa/pr77653.c 
b/gcc/testsuite/gcc.dg/ipa/pr77653.c
index 2fddb7eab548..16df3fff6a41 100644
--- a/gcc/testsuite/gcc.dg/ipa/pr77653.c
+++ b/gcc/testsuite/gcc.dg/ipa/pr77653.c
@@ -1,5 +1,6 @@
 /* { dg-require-alias "" } */
 /* { dg-options "-O2 -fcommon -fdump-ipa-icf-details"  } */
+/* { dg-skip-if "Can align g more than f" { cris-*-* } } */
 
 int a, b, c, d, e, h, i, j, k, l;
 const int f;
-- 
2.30.2

[COMMITTED] testsuite: Skip gcc.dg/ifcvt-4.c for CRIS

[Hans-Peter Nilsson via Gcc-patches]

CRIS has no conditional execution and no conditional moves.

* gcc.dg/ifcvt-4.c: Add cris-*-* to skip list.
---
 gcc/testsuite/gcc.dg/ifcvt-4.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.dg/ifcvt-4.c b/gcc/testsuite/gcc.dg/ifcvt-4.c
index 46245f0d0698..8b2583d00e92 100644
--- a/gcc/testsuite/gcc.dg/ifcvt-4.c
+++ b/gcc/testsuite/gcc.dg/ifcvt-4.c
@@ -2,7 +2,7 @@
 /* { dg-additional-options "-misel" { target { powerpc*-*-* } } } */
 /* { dg-additional-options "-march=z196" { target { s390x-*-* } } } */
 /* { dg-additional-options "-mtune-ctrl=^one_if_conv_insn" { target { i?86-*-* 
x86_64-*-* } } } */
-/* { dg-skip-if "Multiple set if-conversion not guaranteed on all subtargets" 
{ "arm*-*-* avr-*-* hppa*64*-*-* visium-*-*" riscv*-*-* msp430-*-* nios2-*-* 
pru-*-* } }  */
+/* { dg-skip-if "Multiple set if-conversion not guaranteed on all subtargets" 
{ "arm*-*-* avr-*-* cris-*-* hppa*64*-*-* visium-*-*" riscv*-*-* msp430-*-* 
nios2-*-* pru-*-* } }  */
 /* { dg-skip-if "" { "s390x-*-*" } { "-m31" } }  */
 
 typedef int word __attribute__((mode(word)));
-- 
2.30.2

[COMMITTED] testsuite: Fix various scan-assembler identifiers not handling _-prefix

[Hans-Peter Nilsson via Gcc-patches]

Committed as obvious.
-- >8 --
* g++.dg/cpp0x/pr84497.C: Handle USER_LABEL_PREFIX == "_" on
scan-assembler identifiers.
* gcc.dg/debug/btf/btf-enum64-1.c, gcc.dg/ipa/symver1.c: Ditto.
---
 gcc/testsuite/g++.dg/cpp0x/pr84497.C  | 6 +++---
 gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c | 6 +++---
 gcc/testsuite/gcc.dg/ipa/symver1.c| 4 ++--
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/g++.dg/cpp0x/pr84497.C 
b/gcc/testsuite/g++.dg/cpp0x/pr84497.C
index 7eb1aee474e3..be5a9d359ec5 100644
--- a/gcc/testsuite/g++.dg/cpp0x/pr84497.C
+++ b/gcc/testsuite/g++.dg/cpp0x/pr84497.C
@@ -34,6 +34,6 @@ extern thread_local Container container_obj;
 int main() { return !(_obj && _obj && _obj);}
 #endif
 
-// { dg-final { scan-assembler ".weak\[ \t\]*_ZTH8base_obj" } }
-// { dg-final { scan-assembler ".weak\[ \t\]*_ZTH11derived_obj" } }
-// { dg-final { scan-assembler ".weak\[ \t\]*_ZTH13container_obj" } }
+// { dg-final { scan-assembler ".weak\[ \t\]*_?_ZTH8base_obj" } }
+// { dg-final { scan-assembler ".weak\[ \t\]*_?_ZTH11derived_obj" } }
+// { dg-final { scan-assembler ".weak\[ \t\]*_?_ZTH13container_obj" } }
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c 
b/gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c
index e443d4c8c00f..5d1487c1183a 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-enum64-1.c
@@ -3,9 +3,9 @@
 /* { dg-do compile } */
 /* { dg-options "-O0 -gbtf -dA" } */
 
-/* { dg-final { scan-assembler-times "\[\t \].size\[\t \]myenum1,\[\t \]8" 1 } 
} */
-/* { dg-final { scan-assembler-times "\[\t \].size\[\t \]myenum2,\[\t \]8" 1 } 
} */
-/* { dg-final { scan-assembler-times "\[\t \].size\[\t \]myenum3,\[\t \]8" 1 } 
} */
+/* { dg-final { scan-assembler-times "\[\t \].size\[\t \]_?myenum1,\[\t \]8" 1 
} } */
+/* { dg-final { scan-assembler-times "\[\t \].size\[\t \]_?myenum2,\[\t \]8" 1 
} } */
+/* { dg-final { scan-assembler-times "\[\t \].size\[\t \]_?myenum3,\[\t \]8" 1 
} } */
 /* { dg-final { scan-assembler-times "\[\t \]0x1303\[\t 
\]+\[^\n\]*btt_info" 2 } } */
 /* { dg-final { scan-assembler-times "\[\t \]0x9303\[\t 
\]+\[^\n\]*btt_info" 1 } } */
 /* { dg-final { scan-assembler-times "\[\t \]0xffaa\[\t 
\]+\[^\n\]*bte_value_lo32" 2 } } */
diff --git a/gcc/testsuite/gcc.dg/ipa/symver1.c 
b/gcc/testsuite/gcc.dg/ipa/symver1.c
index 2cd025836697..d120ed5d76b1 100644
--- a/gcc/testsuite/gcc.dg/ipa/symver1.c
+++ b/gcc/testsuite/gcc.dg/ipa/symver1.c
@@ -8,5 +8,5 @@ int foo()
   return 2;
 }
 
-/* { dg-final { scan-assembler ".symver.*foo, foo@VER_2" } } */
-/* { dg-final { scan-assembler ".symver.*foo, foo@VER_3" } } */
+/* { dg-final { scan-assembler ".symver.*foo, _?foo@VER_2" } } */
+/* { dg-final { scan-assembler ".symver.*foo, _?foo@VER_3" } } */
-- 
2.30.2

[Bug c/108982] While recompiling when even we modify any line in got its giving error

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #16 from Hans-Peter Nilsson  ---
(In reply to Andrew Pinski from comment #2)
> Third you might need to run fix includes again after doing the install.

I'm afraid that's incomprehensible to someone unfamiliar with gcc and that has
supposedly never heard of "fixincludes".

I'd phrase that as 'find and re-run the script by the name "fixincludes" (which
is installed as part of the gcc package)'.  Alternatively, un-install and
re-install gcc by the same method you installed it.  HTH.

RISC-V: Add auto-vectorization support

[juzhe.zhong]

>> This series of patches adds foundational support for RISC-V 
>> autovectorization. These patches are based on the current upstream rvv 
>> vector intrinsic support and is not a new implementation. Most of the 
>> implementation consists of adding the new vector cost model, the 
>> autovectorization patterns themselves and target hooks.
>> This implementation only provides support for integer addition and 
>> subtraction as a proof of concept.
>> As discussed on this list, if these patches are approved they will be 
>> merged into a "auto-vectorization" branch once gcc-13 branches for release.
>> There are two known issues related to crashes (assert failures) 
>> associated with tree vectorization; one of which I have sent a patch for 
>> and have received feedback. I will be sending a patch for the second 
>> issue tomorrow.

These patches have so many issues:
1. You should not arithmetic operation without supporting auto-vectorization 
load/stores.
2. RVV cost model is totally incorrect since they are just my experimental work 
without any
benchmark tuning.
3. ICE in auto-vectorization base on current upstream framework.
4. The vector-length/LMUL compile option is not ratified, we can't push the 
unratified
compile option. The compile option should be consistent with LLVM.
5. The current RVV instruction machine descriptions are not stable, you can not 
support auto-vec
base on unstable machine descriptions.
etc. so many issues.

So I totally disagree this set of pathes. These patches are coming from my 
original ugly experimental 
RVV work in RISC-V repo:
https://github.com/riscv-collab/riscv-gcc/tree/riscv-gcc-rvv-next  that I 
already abandoned (I no longer maintained). 

Currently, we (I && kito) have finished all intrinsics (except segment 
instructions) and machine descriptions,
we will keep testing and fine-tunning && fix bugs until GCC 13 release.  We 
should wait until machine descriptions
are stable to support auto-vec. So don't do any auto-vec during stage 4 in GCC 
13 plz. 

I have an elegent implementation in my downstream.
And I will start to auto-vec when GCC 14 is open.

Thanks.


juzhe.zh...@rivai.ai

[Bug tree-optimization/109011] missed optimization in presence of __builtin_ctz

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

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

--- Comment #6 from Jakub Jelinek  ---
Oh, and optabs.cc expands ctz using clz as (bitsize-1) - .CLZ(x & -x) which is
one fewer operations if andn isn't supported, on the other side is undefined at
zero (so could be used for __builtin_ctz but not for .CTZ if
CTZ_UNDEFINED_AT_ZERO is 2.

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[tstellar at redhat dot com via Gcc-bugs]

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

--- Comment #12 from Tom Stellard  ---
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=6e80a1d164d1f9 is the first bad
commit.

[Bug rtl-optimization/109019] Failure to optimize b + c -1

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

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Thomas Koenig  ---
Urgh,too late in the evening, I guess. Sorry for the noise.

[Bug rtl-optimization/109019] Failure to optimize b + c -1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
How could it?
addi3,4,-1
blr
would be return c - 1; rather than return b + c - 1;

[Bug rtl-optimization/109019] New: Failure to optimize b + c -1

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

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

Bug ID: 109019
   Summary: Failure to optimize b + c -1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Looks like a general RTL issue, I see this on POWER, RV64 and ARM64 (the
latter two on godbolt).


[tkoenig@gcc135 ~]$ cat c.c
long foo (long b, long c)
{
  return b + c - 1;
}
[tkoenig@gcc135 ~]$ gcc -O3 -S c.c
[tkoenig@gcc135 ~]$ cat c.s
.file   "c.c"
.machine power8
.abiversion 2
.section".text"
.align 2
.p2align 4,,15
.globl foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
add 3,3,4
addi 3,3,-1
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.cfi_endproc
.LFE0:
.size   foo,.-foo
.ident  "GCC: (GNU) 13.0.1 20230215 (experimental)"
.section.note.GNU-stack,"",@progbits

This should be

addi3,4,-1
ret

Re: [PATCH][stage1] Remove conditionals around free()

[Iain Sandoe]

> On 3 Mar 2023, at 23:11, Bernhard Reutner-Fischer via Fortran 
>  wrote:
> 
> On 2 March 2023 02:23:10 CET, Jerry D  wrote:
>> On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:
>>> On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via 
>>> Fortran wrote:
  libgfortran/caf/single.c |6 ++
  libgfortran/io/async.c   |6 ++
  libgfortran/io/format.c  |3 +--
  libgfortran/io/transfer.c|6 ++
  libgfortran/io/unix.c|3 +--
>>> 
>>> The Fortran ones are OK.
>>> 
>> 
>> The only question I have: Is free posix compliant on all platforms?
>> 
>> For example ming64 or mac?

OSX / macOS are [certified] Posix compliant - but to unix03 (and might be 
missing features declared as optional at that revision, or features from later 
Posix versions).

In the case of free() man says:
"The free() function deallocates the memory allocation pointed to by ptr. If 
ptr is a NULL pointer, no operation is performed.”

Iain


>>  It seems sometimes we run into things like this once in a while.
> 
> I think we have the -liberty to cater even for non compliant systems either 
> way, if you please excuse the pun. That's not an excuse on POSIX systems, 
> imho.
> 
>> 
>> Otherwise I have no issue at all.  It is a lot cleaner.
>> 
>> Jerry

[pushed] analyzer: start adding test coverage for OpenMP [PR109016]

[David Malcolm via Gcc-patches]

Successfully tested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6467-gdf0184906a7b86.

gcc/testsuite/ChangeLog:
PR analyzer/109016
* gcc.dg/analyzer/omp-parallel-for-1.c: New test.
* gcc.dg/analyzer/omp-parallel-for-get-min.c: New test.

Signed-off-by: David Malcolm 
---
 .../gcc.dg/analyzer/omp-parallel-for-1.c  | 21 
 .../analyzer/omp-parallel-for-get-min.c   | 24 +++
 2 files changed, 45 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-1.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-get-min.c

diff --git a/gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-1.c 
b/gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-1.c
new file mode 100644
index 000..dae940dac20
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-1.c
@@ -0,0 +1,21 @@
+/* { dg-additional-options "-fopenmp -Wall" } */
+
+typedef struct _Image
+{
+  int columns, rows;
+} Image;
+
+extern int get_num_threads(void);
+
+void
+test (Image* image)
+{
+  int y;
+
+#pragma omp parallel for schedule(static) \
+  num_threads(get_num_threads ())
+
+  for (y = 0; y < image->rows; y++) {
+/* [...snip...] */
+  }
+}
diff --git a/gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-get-min.c 
b/gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-get-min.c
new file mode 100644
index 000..a7e64e1a3a8
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/omp-parallel-for-get-min.c
@@ -0,0 +1,24 @@
+/* Reduced from ImageMagick-7.1.0-57's MagickCore/attribute.c: 
GetEdgeBackgroundColor */
+
+/* { dg-additional-options "-fopenmp -Wall" } */
+
+extern double get_census (void);
+
+double
+test()
+{
+  double census[4], edge_census;
+  int i;
+
+#pragma omp parallel for schedule(static)
+
+  for (i = 0; i < 4; i++) {
+census[i] = get_census ();
+  }
+  edge_census = (-1.0);
+  for (i = 0; i < 4; i++)
+if (census[i] > edge_census) { /* { dg-bogus "use of uninitialized value" 
} */
+  edge_census = census[i];
+}
+  return edge_census;
+}
-- 
2.26.3

[Bug analyzer/109016] Analyzer doesn't know about OMP builtins

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

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

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

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

commit r13-6467-gdf0184906a7b86a497c038766366904a20b5601e
Author: David Malcolm 
Date:   Fri Mar 3 18:18:51 2023 -0500

analyzer: start adding test coverage for OpenMP [PR109016]

gcc/testsuite/ChangeLog:
PR analyzer/109016
* gcc.dg/analyzer/omp-parallel-for-1.c: New test.
* gcc.dg/analyzer/omp-parallel-for-get-min.c: New test.

Signed-off-by: David Malcolm 

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

[isanbard at gmail dot com via Gcc-bugs]

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

--- Comment #16 from Bill Wendling  ---
(In reply to Martin Uecker from comment #15)
> Am Freitag, dem 03.03.2023 um 20:27 + schrieb isanbard at gmail dot com:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
> > 
> > --- Comment #14 from Bill Wendling  ---
> > (In reply to Martin Uecker from comment #9)
> > > > > Considering that the GNU extensions is rarely used, one could consider
> > > > > redefining the meaning of
> > > > > 
> > > > > int n = 1;
> > > > > struct {
> > > > >   int n;
> > > > >   char buf[n];
> > > > > };
> > > > > 
> > > > > so that the 'n' refers to the member. Or we add a new syntax similar 
> > > > > to
> > > > > designators (which intuitively makes sense to me).
> > > > designator might be better IMO.
> > > > 
> > > > a question here is:
> > > > 
> > > > for the following nested structure: 
> > > > 
> > > > struct object {
> > > > ...
> > > > char items;
> > > > ...
> > > > struct inner {
> > > > ...
> > > > int flex[];
> > > > };
> > > > } *ptr;
> > > > 
> > > > what kind of syntax is good to represent the upper bound of "flex" in 
> > > > the inner
> > > > struct with "items" in the outer structure? any suggestion?
> > > 
> > > I would disallow it. At least at first. It also raises some
> > > questions: For example, one could form a pointer to the inner
> > > struct, and then it is not clear how 'items' could be accessed
> > > anymore.
> > > 
> > 
> > That would be limiting its use in the Linux kernel. It seems that there are
> > ways to refer to struct members already using something like "offsetof":
> > 
> > struct object {
> > ...
> > char items;
> > ...
> > struct inner {
> > ...
> > int flex[] __attribute__((__element_count__(offsetof(struct object,
> > items;
> > };
> > } *ptr;
> 
> This seems to be something completely different. offsetof
> computes the offset from the type given in its argument.
> But it would not access the value of the member of the
> enclosing struct. But it would not work in your example,
> because the struct object is incomplete at this point.
> 
> So no, you can not use offsetof to reference a member
> of an enclosing struct.
> 
"offsetof(struct foo, count)" is a fancy wrapper for "((struct foo
*)0)->count", which is resolved during sema, where it does have the full
structure definition. For instance, this compiles in C++:

struct a {
int count;
int y = ((struct a *)0)->count;
} x;

void foo(struct a *);


> > 
> > The object referenced by "offsetof" would be from the containing structure 
> > (see
> > "container_of" macro in Linux).
> > 
> > It has the benefit of not needing to extend C's syntax to allow for 
> > designated
> > initializers outside of initialization lists. 
> 
> Yes, but that syntax would be intuitive which I would see
> as an advantage.
> 
Sure, but you have a similar issue to your objection above because you're
referencing members of a struct before it's completely defined. :-)

> But I am not saying we shouldn't have the attribute first.
> 
I personally prefer using an attribute than the suggestion to use some other
syntax, like:

struct foo {
int fam[.count];
};

It becomes less intuitive what's going on here. And might conflict with VLA's
in structures.

> > It also has the benefit of
> > allowing one to reference a variable not in the structure:
> > 
> > const int items;
> > struct object {
> > ...
> > char items;
> > ...
> > struct inner {
> > ...
> > int flex[] __attribute__((__element_count__(items))); /* References
> > global "items" */
> > };
> > } *ptr;
> 
> Whether you allow this or not has nothing to do with the syntax.
> 
> The question is what semantics you attach to this and this is
> also a question in your example. 
> 
> If you define
> 
> struct inner* a = ...
> 
> What does it say for  a->flex  ?
> 
I need to point out that I used "offsetof" only as an example. It's possible to
create something more robust which will carry along type information, etc.,
which the current offsetof macro throws away. I should have made that clear.

The sanitizers that see "a->flex" will try to find the correct variable. If
they can't, then they won't generate a check. In the case of it referencing a
non-field member, it'll use that if it's within scope. If it refers to a field
member of a parent container that's not within scope, it'll also not generate a
check. It's unfortunate that these checks are done as a "best effort," but it
could lead to software changes to improve security checks (like passing a
parent structure into a function rather than an inner structure.

[Bug tree-optimization/108988] gimple_fold_builtin_fputs doesn't preserve gimple_builtin_call_types_compatible_p

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

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

--- Comment #8 from David Malcolm  ---
(In reply to Jakub Jelinek from comment #6)
> Fixed.

Thanks!

[Bug c++/109018] decltype of dependent expressions lookup should be done only when doing template function definition

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> template
> decltype(g(T())) h()
> return g(T());}
Typo in my example missing {

[Bug c++/109018] decltype of dependent expressions lookup should be done only when doing template function definition

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

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

--- Comment #2 from Andrew Pinski  ---
Also from that page:

> If multiple declarations of the same template differ in the result of name 
> lookup, the first such declaration is used

That is GCC gets that part correct even while clang and MSVC does not.

Re: [PATCH][stage1] Remove conditionals around free()

[Bernhard Reutner-Fischer via Gcc-patches]

On 2 March 2023 02:23:10 CET, Jerry D  wrote:
>On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote:
>> On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via 
>> Fortran wrote:
>>>   libgfortran/caf/single.c |6 ++
>>>   libgfortran/io/async.c   |6 ++
>>>   libgfortran/io/format.c  |3 +--
>>>   libgfortran/io/transfer.c|6 ++
>>>   libgfortran/io/unix.c|3 +--
>> 
>> The Fortran ones are OK.
>> 
>
>The only question I have: Is free posix compliant on all platforms?
>
>For example ming64 or mac?  It seems sometimes we run into things like this 
>once in a while.

I think we have the -liberty to cater even for non compliant systems either 
way, if you please excuse the pun. That's not an excuse on POSIX systems, imho.

>
>Otherwise I have no issue at all.  It is a lot cleaner.
>
>Jerry

[Bug c++/109018] decltype of dependent expressions lookup should be done only when doing template function definition

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
>gives this example about dependent expression lookup issue.

Yes and it explictly it is about an invalid code example which GCC gets
correct.

The comment here:
// template argument substitution fails; g(int)
// was not in scope at the first declaration of h()

Explictly saying this code is invalid.

If you used a non-base type. ADL will find the g correctly in the substitution
of T.

E.g. this is valid:
```
struct A{};


template
decltype(g(T())) h(); 

int g(A);

template
decltype(g(T())) h()
return g(T());}

int i = h();
```

>Both clang and MSVC can solve this with no issue.
Yes and clang and MSVC has a bug then.

Re: [PATCH] wwwdocs: Document several further C++23 changes

[Gerald Pfeifer]

On Thu, 2 Mar 2023, Jakub Jelinek wrote:
> +  A new statement attribute for C++23  href="https://wg21.link/p1774r8;>P1774R8 Portable
> +  assumptions support also in C or older C++:

This reads a bit odd to me: is there a comma missing after P1774R8?
And maybe a colon before? Or something like that?

Gerald

[committed] analyzer: provide placeholder implementation of sprintf

[David Malcolm via Gcc-patches]

Previously, the analyzer lacked a known_function implementation of
sprintf, and thus would handle calls to sprintf with the "anything could
happen" fallback.

Whilst working on PR analyzer/107565 I noticed that this was preventing
a lot of genuine memory leaks from being reported for Doom; fixing
thusly.

Integration testing of the effect of the patch shows a big increase in
true positives due to the case mentioned in Doom, and one new false
positive (in pcre2), which I'm tracking as PR analyzer/109014.

Comparison:
  GOOD:  67 -> 123 (+56); 10.91% -> 18.33%
   BAD: 547 -> 548 (+1)

where the affected warnings/projects are:
 
  -Wanalyzer-malloc-leak:
GOOD:  0 -> 56 (+56);  0.00% -> 41.48%
 BAD: 79
  True positives: 0 -> 56 (+56)
(all in Doom)

  -Wanalyzer-use-of-uninitialized-value:
GOOD: 0;  0.00%
 BAD: 80 -> 81 (+1)
  False positives:
pcre2-10.42: 0 -> 1 (+1)

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

gcc/analyzer/ChangeLog:
* kf.cc (class kf_sprintf): New.
(register_known_functions): Register it.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/doom-d_main-IdentifyVersion.c: New test.
* gcc.dg/analyzer/sprintf-1.c: New test.
* gcc.dg/analyzer/sprintf-concat.c: New test.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/kf.cc|  29 ++
 .../analyzer/doom-d_main-IdentifyVersion.c| 272 ++
 gcc/testsuite/gcc.dg/analyzer/sprintf-1.c |  64 +
 .../gcc.dg/analyzer/sprintf-concat.c  |  35 +++
 4 files changed, 400 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/doom-d_main-IdentifyVersion.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/sprintf-1.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/sprintf-concat.c

diff --git a/gcc/analyzer/kf.cc b/gcc/analyzer/kf.cc
index 3a91b6bd6eb..c4485153e1b 100644
--- a/gcc/analyzer/kf.cc
+++ b/gcc/analyzer/kf.cc
@@ -778,6 +778,34 @@ kf_strchr::impl_call_post (const call_details ) const
 }
 }
 
+/* Handler for "sprintf".
+ int sprintf(char *str, const char *format, ...);
+*/
+
+class kf_sprintf : public known_function
+{
+public:
+  bool matches_call_types_p (const call_details ) const final override
+  {
+return (cd.num_args () >= 2
+   && cd.arg_is_pointer_p (0)
+   && cd.arg_is_pointer_p (1));
+  }
+
+  void impl_call_pre (const call_details ) const final override
+  {
+/* For now, merely assume that the destination buffer gets set to a
+   new svalue.  */
+region_model *model = cd.get_model ();
+region_model_context *ctxt = cd.get_ctxt ();
+const svalue *dst_ptr = cd.get_arg_svalue (0);
+const region *dst_reg
+  = model->deref_rvalue (dst_ptr, cd.get_arg_tree (0), ctxt);
+const svalue *content = cd.get_or_create_conjured_svalue (dst_reg);
+model->set_value (dst_reg, content, ctxt);
+  }
+};
+
 /* Handler for "__builtin_stack_restore".  */
 
 class kf_stack_restore : public known_function
@@ -990,6 +1018,7 @@ register_known_functions (known_function_manager )
 kfm.add (BUILT_IN_MEMSET, make_unique ());
 kfm.add (BUILT_IN_MEMSET_CHK, make_unique ());
 kfm.add (BUILT_IN_REALLOC, make_unique ());
+kfm.add (BUILT_IN_SPRINTF, make_unique ());
 kfm.add (BUILT_IN_STACK_RESTORE, make_unique ());
 kfm.add (BUILT_IN_STACK_SAVE, make_unique ());
 kfm.add (BUILT_IN_STRCHR, make_unique ());
diff --git a/gcc/testsuite/gcc.dg/analyzer/doom-d_main-IdentifyVersion.c 
b/gcc/testsuite/gcc.dg/analyzer/doom-d_main-IdentifyVersion.c
new file mode 100644
index 000..982b9b74349
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/doom-d_main-IdentifyVersion.c
@@ -0,0 +1,272 @@
+/* Reduced from Doom's d_main.c, which is under the GPLv2 or later.  */
+
+/* { dg-additional-options "-Wno-analyzer-too-complex" } */
+
+typedef __SIZE_TYPE__ size_t;
+typedef struct _IO_FILE FILE;
+
+extern int
+printf(const char* __restrict, ...);
+
+extern int
+sprintf(char* __restrict __s, const char* __restrict, ...)
+  __attribute__((__nothrow__));
+
+extern void*
+malloc(size_t __size) __attribute__((__nothrow__, __leaf__))
+__attribute__((__malloc__)) __attribute__((__alloc_size__(1)));
+extern char*
+getenv(const char* __name) __attribute__((__nothrow__, __leaf__))
+__attribute__((__nonnull__(1)));
+extern int
+access(const char* __name, int __type) __attribute__((__nothrow__, __leaf__))
+__attribute__((__nonnull__(1)));
+extern char*
+strcpy(char* __restrict __dest, const char* __restrict __src)
+  __attribute__((__nothrow__, __leaf__)) __attribute__((__nonnull__(1, 2)));
+extern size_t
+strlen(const char* __s) __attribute__((__nothrow__, __leaf__))
+__attribute__((__pure__)) __attribute__((__nonnull__(1)));
+
+typedef enum
+{
+  shareware,
+  registered,
+  commercial,
+
+  retail,
+  indetermined
+
+} GameMode_t;
+
+typedef enum
+{
+  doom,
+  doom2,
+  pack_tnt,
+  pack_plut,
+  none
+
+} 

[pushed] testsuite: remove XFAIL in gcc.dg/analyzer/pr99716-1.c [PR108988]

[David Malcolm via Gcc-patches]

Jakub's r13-6441-gdbeccab7a1f5dc fix for PR tree-optimization/108988
has fixed this failing analyzer test.

Successfully tested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-6465-gd3ef73867e3f70.

gcc/testsuite/ChangeLog:
PR tree-optimization/108988
* gcc.dg/analyzer/pr99716-1.c (test_2): Remove xfail.

Signed-off-by: David Malcolm 
---
 gcc/testsuite/gcc.dg/analyzer/pr99716-1.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/analyzer/pr99716-1.c 
b/gcc/testsuite/gcc.dg/analyzer/pr99716-1.c
index 4fae368f321..2ccdcc73a5c 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pr99716-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pr99716-1.c
@@ -27,11 +27,7 @@ test_2 (void)
 FILE *fp = fopen ("/tmp/test", "w");
 fprintf (fp, "hello");
   }
-} /* { dg-warning "leak of FILE 'fp'" "" { xfail *-*-* } } */
-/* TODO: fails on some targets due to fprintf call being optimized to
-   __builtin_fwrite with a size argument (idx 2) that fails
-   gimple_builtin_call_types_compatible_p, and thus the known_function
-   for __builtin_fwrite not being used (PR middle-end/108988).  */
+} /* { dg-warning "leak of FILE 'fp'" } */
 
 FILE *fp3;
 
-- 
2.26.3

[Bug analyzer/107565] [12 Regression] -Wanalyzer-use-of-uninitialized-value false positive with rdrand

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

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

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

https://gcc.gnu.org/g:56572a08ec4a0fc1a7802d3737cd7f7cc9089c4b

commit r13-6466-g56572a08ec4a0fc1a7802d3737cd7f7cc9089c4b
Author: David Malcolm 
Date:   Fri Mar 3 17:59:21 2023 -0500

analyzer: provide placeholder implementation of sprintf

Previously, the analyzer lacked a known_function implementation of
sprintf, and thus would handle calls to sprintf with the "anything could
happen" fallback.

Whilst working on PR analyzer/107565 I noticed that this was preventing
a lot of genuine memory leaks from being reported for Doom; fixing
thusly.

Integration testing of the effect of the patch shows a big increase in
true positives due to the case mentioned in Doom, and one new false
positive (in pcre2), which I'm tracking as PR analyzer/109014.

Comparison:
  GOOD:  67 -> 123 (+56); 10.91% -> 18.33%
   BAD: 547 -> 548 (+1)

where the affected warnings/projects are:

  -Wanalyzer-malloc-leak:
GOOD:  0 -> 56 (+56);  0.00% -> 41.48%
 BAD: 79
  True positives: 0 -> 56 (+56)
(all in Doom)

  -Wanalyzer-use-of-uninitialized-value:
GOOD: 0;  0.00%
 BAD: 80 -> 81 (+1)
  False positives:
pcre2-10.42: 0 -> 1 (+1)

gcc/analyzer/ChangeLog:
* kf.cc (class kf_sprintf): New.
(register_known_functions): Register it.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/doom-d_main-IdentifyVersion.c: New test.
* gcc.dg/analyzer/sprintf-1.c: New test.
* gcc.dg/analyzer/sprintf-concat.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/109014] -Wanalyzer-use-of-uninitialized-value seen in pcre2-10.42's pcre2test.c

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

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

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

https://gcc.gnu.org/g:56572a08ec4a0fc1a7802d3737cd7f7cc9089c4b

commit r13-6466-g56572a08ec4a0fc1a7802d3737cd7f7cc9089c4b
Author: David Malcolm 
Date:   Fri Mar 3 17:59:21 2023 -0500

analyzer: provide placeholder implementation of sprintf

Previously, the analyzer lacked a known_function implementation of
sprintf, and thus would handle calls to sprintf with the "anything could
happen" fallback.

Whilst working on PR analyzer/107565 I noticed that this was preventing
a lot of genuine memory leaks from being reported for Doom; fixing
thusly.

Integration testing of the effect of the patch shows a big increase in
true positives due to the case mentioned in Doom, and one new false
positive (in pcre2), which I'm tracking as PR analyzer/109014.

Comparison:
  GOOD:  67 -> 123 (+56); 10.91% -> 18.33%
   BAD: 547 -> 548 (+1)

where the affected warnings/projects are:

  -Wanalyzer-malloc-leak:
GOOD:  0 -> 56 (+56);  0.00% -> 41.48%
 BAD: 79
  True positives: 0 -> 56 (+56)
(all in Doom)

  -Wanalyzer-use-of-uninitialized-value:
GOOD: 0;  0.00%
 BAD: 80 -> 81 (+1)
  False positives:
pcre2-10.42: 0 -> 1 (+1)

gcc/analyzer/ChangeLog:
* kf.cc (class kf_sprintf): New.
(register_known_functions): Register it.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/doom-d_main-IdentifyVersion.c: New test.
* gcc.dg/analyzer/sprintf-1.c: New test.
* gcc.dg/analyzer/sprintf-concat.c: New test.

Signed-off-by: David Malcolm 

Re: [PATCH] wwwdocs: Document several further C++23 changes

[Gerald Pfeifer]

On Thu, 2 Mar 2023, Jakub Jelinek wrote:
> Tobias mentioned on IRC that assume attribute wasn't mentioned in
> changes.html.  The P1774R8 entry was missing for C++, so I went through
> projects/cxx-status.html#cxx23 and filled in all the missing papers
> which have been implemented newly in GCC 13, plus a small note for C family
> about assume attribute.

Nice!

There was a small markup issue -- unclosed  -- which I fixed 
thusly.

Gerald


commit ec6f12dc7c229ba1662706c14083e6f3a78e2760
Author: Gerald Pfeifer 
Date:   Fri Mar 3 23:53:21 2023 +0100

gcc-13: Properly close an 

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 839b73d0..cb6a9ec2 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -184,7 +184,7 @@ a work-in-progress.
   
   A new statement attribute for C++23 https://wg21.link/p1774r8;>P1774R8 Portable
   assumptions support also in C or older C++:
-https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html#index-assume-statement-attribute;>__attribute__((assume(EXPR)));
+  https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html#index-assume-statement-attribute;>__attribute__((assume(EXPR)));
   
 
 

[Bug c++/109018] New: decltype of dependent expressions lookup should be done only when doing template function definition

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

Bug ID: 109018
   Summary: decltype of dependent expressions  lookup should be
done only when doing template function definition
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickhuang99 at hotmail dot com
  Target Milestone: ---

In
cppreference.com(https://en.cppreference.com/w/cpp/language/function_template#Function_template_overloading)
gives this example about dependent expression lookup issue.  However, it turns
out only GCC has this parsing issue. Both clang and MSVC can solve this with no
issue.(https://www.godbolt.org/z/9anx871rr)



template
decltype(g(T())) h(); // decltype(g(T())) is a dependent type

int g(int);

template
decltype(g(T())) h()
{  // redeclaration of h() uses earlier lookup
return g(T()); // although the lookup here does find g(int)
}

int i = h(); // template argument substitution fails; g(int)
  // was not in scope at the first declaration of h()

[Bug tree-optimization/108988] gimple_fold_builtin_fputs doesn't preserve gimple_builtin_call_types_compatible_p

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

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

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

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

commit r13-6465-gd3ef73867e3f70a343ad5aa4e00b270be85fa572
Author: David Malcolm 
Date:   Fri Mar 3 17:48:04 2023 -0500

testsuite: remove XFAIL in gcc.dg/analyzer/pr99716-1.c [PR108988]

Jakub's r13-6441-gdbeccab7a1f5dc fix for PR tree-optimization/108988
has fixed this failing analyzer test.

gcc/testsuite/ChangeLog:
PR tree-optimization/108988
* gcc.dg/analyzer/pr99716-1.c (test_2): Remove xfail.

Signed-off-by: David Malcolm 

Re: [wwwdocs] Document allocator_traits::rebind_alloc assertion with GCC 13

[Gerald Pfeifer]

On Thu, 2 Mar 2023, Jonathan Wakely via Gcc-patches wrote:
> Pushed to wwwdocs.

Thank you!

> +If an allocator type AllocT

Note that HTML 5 complains about the use of  and we are using  
instead.

I just pushed the following patch addressing that. (The diff looks a bit 
bigger due to changes re line breaks.)

Gerald


commit 5a75fbda8c3c647b2ef659ffe67a031ee957abe6
Author: Gerald Pfeifer 
Date:   Fri Mar 3 23:41:36 2023 +0100

gcc-13: Use  instead of 

diff --git a/htdocs/gcc-13/porting_to.html b/htdocs/gcc-13/porting_to.html
index 953e1453..733bb254 100644
--- a/htdocs/gcc-13/porting_to.html
+++ b/htdocs/gcc-13/porting_to.html
@@ -150,8 +150,8 @@ previous behavior.
 GCC 13 now checks that allocators used with the standard library
 can be "rebound" to allocate memory for a different type,
 as required by the allocator requirements in the C++ standard.
-If an allocator type AllocT
-cannot be correctly rebound to another type AllocU,
+If an allocator type AllocT
+cannot be correctly rebound to another type AllocU,
 you will get an error like this:
 
 
@@ -161,26 +161,27 @@ you will get an error like this:
 
 
 The assertion checks that rebinding an allocator to its own value type is a
-no-op, which will be true if its rebind member is defined correctly.
+no-op, which will be true if its rebind member is defined 
correctly.
 If rebinding it to its own value type produces a different type,
 then the allocator cannot be used with the standard library.
 
 
 
-The most common cause of this error is an allocator type 
AllocT
-that derives from std::allocatorT but does not provide its own
-rebind member. When the standard library attempts to rebind the
-allocator using AllocT::rebindU it finds the
-std::allocatorT::rebindU member from the base class,
-and the result is std::allocatorU instead of
-AllocU.
+The most common cause of this error is an allocator type
+AllocT that derives from
+std::allocatorT but does not provide its own
+rebind member. When the standard library attempts to rebind the
+allocator using AllocT::rebindU it finds the
+std::allocatorT::rebindU member from the base
+class, and the result is std::allocatorU instead of
+AllocU.
 
 
 
-The solution is to provide a correct rebind member as shown below.
-A converting constructor must also be provided, so that that an
-AllocU can be constructed from an AllocT,
-and vice versa:
+The solution is to provide a correct rebind member as shown
+below.  A converting constructor must also be provided, so that that an
+AllocU can be constructed from an
+AllocT, and vice versa:
 
 
 templateclass T
@@ -197,9 +198,10 @@ class Alloc
 
 
 
-Since C++20, there is no rebind member in std::allocator,
-so deriving your own allocator types from std::allocator is simpler
-and doesn't require the derived allocator to provide its own rebind.
+Since C++20, there is no rebind member in
+std::allocator, so deriving your own allocator types from
+std::allocator is simpler and doesn't require the derived
+allocator to provide its own rebind.
 For compatibility with previous C++ standards, the member should still be
 provided. The converting constructor is still required even in C++20.
 

gcc-11-20230303 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20230303 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20230303/
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 d1f7e12b136b61ea37d96cb12d2c3956e28b9cca

You'll find:

 gcc-11-20230303.tar.xz   Complete GCC

  SHA256=20fd8b12f846ab942b60f1979b1a14b058c46b167b832c46edb78a0ada7f3738
  SHA1=ddcc704ea99e9f47152bb7066c98df5542a55cb5

Diffs from 11-20230224 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.

Re: [PATCH] Fortran: fix CLASS attribute handling [PR106856]

[Steve Kargl via Gcc-patches]

On Fri, Mar 03, 2023 at 10:24:07PM +0100, Mikael Morin wrote:
> Hello,
> 
> Le 03/03/2023 à 20:57, Steve Kargl via Fortran a écrit :
> > On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
> > > -  if (attr->class_ok)
> > > -/* Class container has already been built.  */
> > > +  /* Class container has already been built with same name.  */
> > > +  if (attr->class_ok
> > > +  && ts->u.derived->components->attr.dimension >= attr->dimension
> > > +  && ts->u.derived->components->attr.codimension >= attr->codimension
> > > +  && ts->u.derived->components->attr.class_pointer >= attr->pointer
> > > +  && ts->u.derived->components->attr.allocatable >= 
> > > attr->allocatable)
> > 
> > I suppose I'm a bit confused here.  dimension, codimension,
> > pointer and allocatable are 1-bit bitfields in the attr
> > struct.  These can have the values 0 and 1, so the above
> > conditionals are always true.
> > 
> as I understand it, they aren't if attr has attributes that aren't already
> set in the class container's first component.
> a >= b == !(a < b) and if a and b are boolean-valued, a < b == !a && b.
> Admittedly, I haven't tested the logic like Harald has.
> 

Mikael, thanks for smacking me with the clue stick.  I had to do a quick
test to see the trees.

% cc -o z a.c && ./z
a.i = 0,  b.i = 0, a.i >= b.i = 1
a.i = 1,  b.i = 0, a.i >= b.i = 1
a.i = 1,  b.i = 1, a.i >= b.i = 1
a.i = 0,  b.i = 1, a.i >= b.i = 0

I was overlooking the last case.  So, the above is an all
or nothing test.

-- 
steve

[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #14 from Eric Gallager  ---
(In reply to Sergey Fedorov from comment #13)
> Is --enable-decimal-float supported on PowerPC Darwin?? It seems that it is
> not, and DFP have been added in ISA 2.05.

I don't think it is, but I can't seem to find the issue that was open about
that at the moment, so maybe someone else should check...

[Bug target/108315] -mcpu=power10 changes ABI

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

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

--- Comment #17 from Segher Boessenkool  ---
What makes you think we need to tell the user to do something?  There is
nothing that needs to be done as far as I can see?  /confused

Re: [PATCH 2/2] Rework 128-bit complex multiply and divide.

[Segher Boessenkool]

Hi!

On Fri, Feb 03, 2023 at 12:53:05AM -0500, Michael Meissner wrote:
> This patch reworks how the complex multiply and divide built-in functions are
> done.

> I tested all 3 patchs for PR target/107299 on:

Is this part of the proposed commit message?  As Ke Wen pointed out, it
is wrong.  Most of your mail does not belong in a commit message at all,
but some probably does?  Please do this clearer with future patches.

>   * config/rs6000/rs6000.cc (create_complex_muldiv): Delete.
>   (init_float128_ieee): Delete code to switch complex multiply and divide
>   for long double.

I like this kind of patch :-)

> +/* Internal function to return the built-in function id for the complex
> +   multiply operation for a given mode.  */
> +
> +static inline built_in_function
> +complex_multiply_builtin_code (machine_mode mode)
> +{
> +  return (built_in_function) (BUILT_IN_COMPLEX_MUL_MIN + mode
> +   - MIN_MODE_COMPLEX_FLOAT);
> +}

There should be an assert that the mode is as expected
  gcc_assert (IN_RANGE (mode, MIN_MODE_COMPLEX_FLOAT, MAX_MODE_COMPLEX_FLOAT));
or such.

Using more temporaries should make this simpler as well, obviate the
need for explicit casts, and make everything fit on short lines.

> +static inline built_in_function
> +complex_divide_builtin_code (machine_mode mode)
> +{
> +  return (built_in_function) (BUILT_IN_COMPLEX_DIV_MIN + mode
> +   - MIN_MODE_COMPLEX_FLOAT);
> +}

Ditto ofc.

> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/divic3-1.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile { target { powerpc*-*-* } } } */

Leave the target clause out.

> +/* { dg-require-effective-target powerpc_p8vector_ok } */
> +/* { dg-require-effective-target longdouble128 } */
> +/* { dg-require-effective-target ppc_float128_sw } */
> +/* { dg-options "-O2 -mpower8-vector -mabi=ieeelongdouble -Wno-psabi" } */

It would be nice if you did not try to add -mpower8-vector in more
testcases :-(

Is -Wno-psabi needed here?  What is the error you get without it / on
which configurations?  Cargo-culting hiding the warnings makes you see
fewer warnings, but that is the opposite of a good idea.

> +/* { dg-final { scan-assembler "bl __divtc3" } } */

This name depends on what object format and ABI is in use (some have an
extra leading underscore, or a dot, or whatever).


Segher

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #15 from Martin Uecker  ---
Am Freitag, dem 03.03.2023 um 20:27 + schrieb isanbard at gmail dot com:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
> 
> --- Comment #14 from Bill Wendling  ---
> (In reply to Martin Uecker from comment #9)
> > > > Considering that the GNU extensions is rarely used, one could consider
> > > > redefining the meaning of
> > > > 
> > > > int n = 1;
> > > > struct {
> > > >   int n;
> > > >   char buf[n];
> > > > };
> > > > 
> > > > so that the 'n' refers to the member. Or we add a new syntax similar to
> > > > designators (which intuitively makes sense to me).
> > > designator might be better IMO.
> > > 
> > > a question here is:
> > > 
> > > for the following nested structure: 
> > > 
> > > struct object {
> > > ...
> > > char items;
> > > ...
> > > struct inner {
> > > ...
> > > int flex[];
> > > };
> > > } *ptr;
> > > 
> > > what kind of syntax is good to represent the upper bound of "flex" in the 
> > > inner
> > > struct with "items" in the outer structure? any suggestion?
> > 
> > I would disallow it. At least at first. It also raises some
> > questions: For example, one could form a pointer to the inner
> > struct, and then it is not clear how 'items' could be accessed
> > anymore.
> > 
> 
> That would be limiting its use in the Linux kernel. It seems that there are
> ways to refer to struct members already using something like "offsetof":
> 
> struct object {
> ...
> char items;
> ...
> struct inner {
> ...
> int flex[] __attribute__((__element_count__(offsetof(struct object,
> items;
> };
> } *ptr;

This seems to be something completely different. offsetof
computes the offset from the type given in its argument.
But it would not access the value of the member of the
enclosing struct. But it would not work in your example,
because the struct object is incomplete at this point.

So no, you can not use offsetof to reference a member
of an enclosing struct.

> 
> The object referenced by "offsetof" would be from the containing structure 
> (see
> "container_of" macro in Linux).
> 
> It has the benefit of not needing to extend C's syntax to allow for designated
> initializers outside of initialization lists. 

Yes, but that syntax would be intuitive which I would see
as an advantage.

But I am not saying we shouldn't have the attribute first.


> It also has the benefit of
> allowing one to reference a variable not in the structure:
> 
> const int items;
> struct object {
> ...
> char items;
> ...
> struct inner {
> ...
> int flex[] __attribute__((__element_count__(items))); /* References
> global "items" */
> };
> } *ptr;

Whether you allow this or not has nothing to do with the syntax.

The question is what semantics you attach to this and this is
also a question in your example. 

If you define

struct inner* a = ...

What does it say for  a->flex  ?


Martin










>

Re: [PATCH] Fortran: fix CLASS attribute handling [PR106856]

[Mikael Morin]

Hello,

Le 03/03/2023 à 20:57, Steve Kargl via Fortran a écrit :

On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:

-  if (attr->class_ok)
-/* Class container has already been built.  */
+  /* Class container has already been built with same name.  */
+  if (attr->class_ok
+  && ts->u.derived->components->attr.dimension >= attr->dimension
+  && ts->u.derived->components->attr.codimension >= attr->codimension
+  && ts->u.derived->components->attr.class_pointer >= attr->pointer
+  && ts->u.derived->components->attr.allocatable >= attr->allocatable)


I suppose I'm a bit confused here.  dimension, codimension,
pointer and allocatable are 1-bit bitfields in the attr
struct.  These can have the values 0 and 1, so the above
conditionals are always true.

as I understand it, they aren't if attr has attributes that aren't 
already set in the class container's first component.

a >= b == !(a < b) and if a and b are boolean-valued, a < b == !a && b.
Admittedly, I haven't tested the logic like Harald has.


The rest of the patch looks reasonable.  If Tobias has no
objections or comments, it's ok to commit once the above
is explained.



I have two comments, one about the handling of as and sym->as, which I 
quite don't understand, but I haven't had time to write something about it.

The other is about this:

+  else if (sym->ts.type == BT_CLASS
+  && sym->ts.u.derived->attr.is_class
+  && sym->old_symbol && sym->old_symbol->as == CLASS_DATA (sym)->as)
+sym->old_symbol->as = NULL;
Can this be avoided?  The management of symbol versions should not need 
any manual change.  In principle, either the modified symbols are 
committed, or (in case of error) the previous symbols are restored, but 
there shouldn't be any need for restoring a modified previous symbol.


I guess it's a matter of memory management, because 
gfc_build_class_symbol copies the AS pointer to the class descriptor, 
but I think using gfc_copy_array_spec there or adding the condition 
above to free_old_symbol would be preferable.

Re: [PATCH] Fortran: fix CLASS attribute handling [PR106856]

[Harald Anlauf via Gcc-patches]

Hi Steve,

Am 03.03.23 um 20:57 schrieb Steve Kargl via Gcc-patches:

On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:

-  if (attr->class_ok)
-/* Class container has already been built.  */
+  /* Class container has already been built with same name.  */
+  if (attr->class_ok
+  && ts->u.derived->components->attr.dimension >= attr->dimension
+  && ts->u.derived->components->attr.codimension >= attr->codimension
+  && ts->u.derived->components->attr.class_pointer >= attr->pointer
+  && ts->u.derived->components->attr.allocatable >= attr->allocatable)


I suppose I'm a bit confused here.  dimension, codimension,
pointer and allocatable are 1-bit bitfields in the attr
struct.  These can have the values 0 and 1, so the above
conditionals are always true.


thanks for looking into it.

The above part is from the original draft.  I thought I could
generate testcases that allow to exercise this part, and found
a new case that is not covered by the patch and still ICEs:

subroutine bar (x)
  class(*):: x
  dimension   :: x(:)
  allocatable :: x
end

:-(

We'll need to revisit the logic...


The rest of the patch looks reasonable.  If Tobias has no
objections or comments, it's ok to commit once the above
is explained.



Thanks,
Harald

[Bug c++/101118] coroutines: unexpected ODR warning for coroutine frame type in LTO builds

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-03-03

--- Comment #12 from Iain Sandoe  ---
Actually, comment #3 has it mostly :

here is the frame layout from the test case:

FRAME type decl
boost::asio::g::_ZN5boost4asio1gIiFviEE2abIiEENS0_9awaitableIiiEET_.Frame
   {
 void (*)(|ds|boost::asio::g::_ZN5boost4asio1gIiFviEE2abIiEENS0_9awaitableIiiEET_.Frame*)_Coro_resume_fn)(|ds|boost::asio::g::_ZN5boost4asio1gIiFviEE2abIiEENS0_9awaitableIiiEET_.Frame*)
void (*)(|ds|boost::asio::g::_ZN5boost4asio1gIiFviEE2abIiEENS0_9awaitableIiiEET_.Frame*)_Coro_destroy_fn)(|ds|boost::asio::g::_ZN5boost4asio1gIiFviEE2abIiEENS0_9awaitableIiiEET_.Frame*)
boost::asio::d::promise_type _Coro_promise
 std::__n4861::coroutine_handle_Coro_self_handle
 int ai
 short unsigned int _Coro_resume_index
 bool _Coro_frame_needs_free
 bool _Coro_initial_await_resume_called
 std::__n4861::suspend_always Is_1_1
 boost::asio::d::ae::await_transform::y Aw0_2_3
 boost::asio::g::ab::._anon_5 D.10232_2_3 
 boost::asio::d::ae::final_suspend::u Fs_1_4
  }

in the second case, 

 boost::asio::g::ab::._anon_5 D.10233_2_3

This is because I have used the DECL_UID as a convenient way to generate a
unique nane that is also very handy for debugging since it refers back to the
original function.

However, DECL_UIDs are not stable between TUs, obviously, since it depends on
how many there are before the specific case.

So .. for promotion of target expression temporaries to frame vars, one of:
 - a) we need to find a different way to name them
 - b) if it is permissible for an unnamed decl to have a DECL_VALUE_EXPR ()
perhaps the process can be adjusted to avoid naming these cases (although it
does assist in debuggability).

Re: [PATCH 1/2] PR target/107299: Fix build issue when long double is IEEE 128-bit

[Segher Boessenkool]

Hi!

On Fri, Feb 03, 2023 at 12:49:12AM -0500, Michael Meissner wrote:
> This patch updates the IEEE 128-bit types used in libgcc.
> 
> At the moment, we cannot build GCC when the target uses IEEE 128-bit long
> doubles, such as building the compiler for a native Fedora 36 system.  The
> build dies when it is trying to build the _mulkc3.c and _divkc3 modules.
> 
> This patch changes libgcc to use long double for the IEEE 128-bit base type if
> long double is IEEE 128-bit, and it uses _Float128 otherwise.  The built-in
> functions are adjusted to be the correct version based on the IEEE 128-bit 
> base
> type used.

Please make it much clearer (in the code as well as in the commit
message) that this is a workaround for problems elsewhere.  It
complicates already complicated things that should not be all that
complex in the first place :-(

It is not clear to me that this is good to have at all -- it causes new
non-trivial problems after all -- but you say it allows people to at
least bootstrap, in more cases than before.

So with comments like I said above: okay for trunk.  And not okay for
any backports.

Thanks,


Segher

Re: [libstdc++] Use __gthread_join in jthread/95989

[Alexandre Oliva via Gcc-patches]

On Mar  3, 2023, Alexandre Oliva  wrote:

> Hello, Florian,
> On Mar  3, 2023, Florian Weimer  wrote:

>> * Alexandre Oliva via Gcc-patches:
>>> +// Make sure it's not optimized out, not even with LTO.
>>> +asm ("" : : "rm" (depend));

>> If the m constraint is used, this may never emit the symbol name and
>> thus not create a reference after all.

> But that is no longer the pthread symbol itself, it's the symbol of a
> static member function with vague linkage that, because the compiler
> believes the asm statement will reference it, will still be output, and
> it's that function body that will refer to and thus pull in the symbols
> we need.

> Now, hmm, maybe with per-function sections, the compiler will emit it,
> but with section gc, the linker may drop it, so we might lose the needed
> function body.  When performing LTO with an LTO-enabled libstdc++.

Wait, no, you had me going but it's really fine.  What would be in
memory is a *pointer* to the function, so the function would still be
referenced by whatever initialized the pointer, so it wouldn't get GCed.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[Bug ipa/108871] attribute nonnull does not spot nullptr O2 and above when function inlined

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #8 from Jonny Grant  ---
Another test case.

https://godbolt.org/z/qss7jj51x


I noticed when not using -fanalyzer gcc still warns about __builtin_puts being
passed NULL. However gcc doesn't warn about my own function with attribute
nullptr.  Maybe I'm missing something.


With puts() it gives a nice warning

In function 'void f2(const char*)',
inlined from 'void f1(const char*)' at :22:7,
inlined from 'int main()' at :28:7:
:11:19: warning: argument 1 null where non-null expected [-Wnonnull]
   11 | __builtin_puts(str);
  | ~~^


// -std=c++23 -O1 -Wnonnull -Wall

// Test case that shows a difference in behavour,
// __builtin_puts generates a warning but not f1()
// Note, not using -fanalyzer

// Change this to 1 to see nonnull warning
#define USE_PUTS 0

void f2(const char * str)
{
#if USE_PUTS
__builtin_puts(str);
#else
char a = *str;
__builtin_printf("%c", a);
#endif
}

void f1(const char * const str) __attribute__ ((nonnull));
void f1(const char * const str)
{

f2(str);
}

int main()
{
const char * a = nullptr;
f1(a);
}

☝ Buildbot (Sourceware): gccrust - exception update (exception) (master)

[builder--- via Gcc-rust]

A build exception has been detected on builder gccrust-gentoo-sparc while 
building gccrust.

Full details are available at:
https://builder.sourceware.org/buildbot/#builders/241/builds/321

Build state: exception update (exception)
Revision: (unknown)
Worker: gentoo-sparc
Build Reason: (unknown)
Blamelist: A. Wilcox , Abdul Rafey 
, Alan Modra , Aldy Hernandez 
, Alex Coplan , Alexander Monakov 
, Alexandre Oliva , Alexandre Oliva 
, Allan McRae , Andre Simoes Dias Vieira 
, Andre Vehreschild , Andre 
Vieira , Andrea Corallo 
, Andreas Krebbel , Andreas 
Schwab , Andreas Schwab , Andrew 
Carlotti , Andrew Carlotti , 
Andrew MacLeod , Andrew Pinski , 
Andrew Pinski , Andrew Stubbs , 
Antoni Boucher , Ard Biesheuvel , Arjun 
Shankar , Arnaud Charlet , Arsen 
Arsenovic , Arsen Arsenović , ArshErgon 
, Artem Klimov , Arthur Cohen 
, Avinash Sonawane , Benno Evers 
, Bernd Kuhls , Bernhard 
Reutner-Fischer , Bernhard Reutner-Fischer 
, Bill Schmidt , Bill Seurer 
, Björn Schäpers , Bob Duff 
, Boris Yakobowski , Bruce Korb 
, Bruno Haible , Cedric Landet 
, Cesar Philippidis , 
Charles-François Natali , Chenghua Xu 
, Chenghua Xu , Christoph 
Müllner , Christophe Lyon 
, Christophe Lyon , 
Chung-Ju Wu , Chung-Lin Tang , 
Claire Dross , Claudiu Zissulescu , 
Claudiu Zissulescu , Clément Chigot , 
Clément Chigot , CohenArthur , 
Cui,Lili , Cupertino Miranda 
, Dan Li , Daniel 
Mercier , Dave , David Edelsohn 
, David Faust , David Malcolm 
, David Seifert , Detlef Vollmann 
, Dimitar Dimitrov , Dimitrij Mijoski 
, Dimitrije Milosevic , 
Dimitrije Milošević , Dmitriy Anisimkov 
, Dongsheng Song , Doug Rupp 
, Ed Catmur , Ed Schonberg 
, Ed Smith-Rowland , Eric 
Biggers , Eric Botcazou , Eric 
Botcazou , Eric Gallager , 
Etienne Servais , Eugene Rozenfeld , 
Faisal Abbas <90.abbasfai...@gmail.com>, Faisal Abbas 
, Fedor Rybin , Fei Gao 
, Flavio Cruz , Florian Weimer 
, Francois-Xavier Coudert , 
Francois-Xavier Coudert , François Dumont 
, Frederik Harwath , Fritz 
Reese , Frolov Daniil , GCC 
Administrator , Gaius Mulley , Gary 
Dismukes , Georg-Johann Lay , Gerald 
Pfeifer , Ghjuvan Lacambre , Giuliano 
Belinassi , Guillermo E. Martinez 
, H.J. Lu , Hafiz Abid 
Qadeer , Hans-Peter Nilsson , Haochen 
Gui , Haochen Jiang , Harald 
Anlauf , Hongyu Wang , Hu, Lin1 
, Iain Buclaw , Iain Sandoe 
, Ian Lance Taylor , Ilya Leoshkevich 
, Immad Mir , Immad Mir 
, Indu Bhagat , Iskander 
Shakirzyanov , Jakob Hasse 
<0xja...@users.noreply.github.com>, Jakub Dupak , Jakub 
Jelinek , Jan Beulich , Jan Hubicka 
, Jan-Benedict Glaw , Jason Merrill 
, Javier Miranda , Jeff Chapman II 
, Jeff Law , Jeff Law 
, Jerry DeLisle , Jia-Wei Chen 
, Jia-wei Chen , Jiawei 
, Jin Ma , Jinyang He 
, Jiufu Guo , Joao Azevedo 
, Joel Brobecker , Joel Holdsworth 
, Joel Phillips , Joel 
Teichroeb , Joffrey Huguet , Johannes 
Kanig , Johannes Kliemann , John David 
Anglin , Jonathan Wakely , Jonathan 
Yong <10wa...@gmail.com>, Jose E. Marchesi , Joseph 
Myers , Josue Nava Bello , José Rui 
Faustino de Sousa , Ju-Zhe Zhong , 
Julia Lapenko , Julian Brown 
, Julien Bortolussi , Justin 
Squirek , Jørgen Kvalsvik 
, Keef Aragon , 
Kewen Lin , Kewen.Lin , Kim Kuparinen 
, Kito Cheng , Kong 
Lingling , Kwok Cheung Yeung , 
Kyrylo Tkachov , Kévin Le Gouguec 
, LIU Hao , Lewis Hyatt 
, Liaiss Merzougue , LiaoShihua 
, Lili Cui , Liwei Xu 
, Lorenzo Salvadore , Lulu 
Cheng , Lyra , M V V S Manoj Kumar 
, MAHAD , Maciej W. Rozycki 
, Maciej W. Rozycki , Marc 
Nieper-Wißkirchen , Marc Poulhiès 
, Marc Poulhiès , Marcel Vollweiler 
, Marco Falke , Marek Polacek 
, Mark Mentovai , Mark Wielaard 
, Martin Jambor , Martin Liska 
, Martin Liška , Martin Sebor 
, Martin Uecker , Matthias Kretz 
, Max Filippov , Mayshao 
, Meghan Denny , Michael Collison 
, Michael Eager , Michael Meissner 
, Mikael Morin , Mikhail Ablakatov 
, Monk Chiang , Murray Steele 
, Nathan Sidwell , Nathaniel Shead 
, Navid Rahimi , Nick 
Clifton , Nikos Alexandris , 
Nirmal Patel , Olivier Hainque , Owen 
Avery , Palmer Dabbelt , 
Parthib <94271200+parthib...@users.noreply.github.com>, Parthib 
, Pascal Obry , Pat Haugen 
, Patrick Bernardi , Patrick 
Palka , Paul A. Clarke , Paul Thomas 
, Paul-Antoine Arras , Pekka Seppänen 
, Peter Bergner , Petter Tomner 
, Philip Herron , Philip Herron 
, Philipp Fent , Philipp Tomsich 
, Pierre-Emmanuel Patry 
, Pierre-Marie de Rodat 
, Piotr Trojanek , Prajwal S N 
, Prathamesh Kulkarni 
, Przemyslaw Wirkus 
, Qian Jianhua , Qian Jianhua 
, Qing Zhao , Quentin Ochem 
, Raiki Tamura , Rainer Orth 
, Rainer Orth , Ramana 
Radhakrishnan , Ramana Radhakrishnan 
, Raoni Fassina Firmino , 
Raphael Moreira Zinsly , Rasmus Villemoes 
, Rasmus Villemoes , 
Richard Ball , Richard Biener , 
Richard Earnshaw , Richard Henderson , 
Richard Purdie , Richard Sandiford 
, Rimvydas Jasinskas , Robin 
Dapp , Roger Sayle , Romain 
Beguet , Ronan Desplanques , 
SainiAditya1 , Sam Feifer 
, Sam James , Samuel Thibault 
, Sandra Loosemore , Scott 
Snyder , 

[Bug c++/109017] New: ICE on unexpanded pack from C++20 explicit-template-parameter lambda syntax

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

Bug ID: 109017
   Summary: ICE on unexpanded pack from C++20
explicit-template-parameter lambda syntax
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

// https://godbolt.org/z/bdT84P318
template
struct A {
static void g() {
int dummy[] = {
[](Ts... ts){
int i = Ts();
} ...
};
}
};
int main() {
A::g();
}


: In instantiation of 'static void A<  >::g()
[with  = {int}]':
:12:14:   required from here
:4:13: internal compiler error: in tsubst_pack_expansion, at
cp/pt.cc:13388
4 | int dummy[] = {
  | ^
0x247a53e internal_error(char const*, ...)
???:0
0xae95dc fancy_abort(char const*, int, char const*)
???:0
0xd09f45 instantiate_decl(tree_node*, bool, bool)
???:0
0xd362db instantiate_pending_templates(int)
???:0
0xbe4555 c_parse_final_cleanups()
???:0
0xe21948 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1


Apparently GCC fails to recognize the `class... Ts` in the angle brackets (new
syntax in C++20) as pertaining to the lambda itself, and not to the outer
scope. So when GCC sees an unexpanded `Ts` in the inner scope, GCC happily
accepts it (and then ICEs). Notice that if you change `Ts()` to `ts` in the
inner scope, GCC correctly rejects the code with the usual "parameter packs not
expanded" error. The ICE is triggered specifically by misuse of
`Ts`-from-the-new-in-C++20-syntax.

[Bug tree-optimization/109011] missed optimization in presence of __builtin_ctz

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

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

--- Comment #5 from Jakub Jelinek  ---
And to answer myself, as x86 has vplzcnt* just for 32-bit and 64-bit elts with
-mavx512cd (perhaps -mavx512vl also depending on vecsize), there is also 8-bit
and 16-bit element vector popcount (guarded by different options).
And with popcount it would be 3 instructions instead of 4, though dunno about
their latencies etc.

[Bug tree-optimization/109011] missed optimization in presence of __builtin_ctz

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

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

--- Comment #4 from Jakub Jelinek  ---
Hacker's Delight has also a variant for popcount, either .POPCOUNT ((x - 1) &
~x)
or bitsize - .POPCOUNT (x | -x), though a question is if there are any targets
which have vector popcount and don't have vector clz nor ctz for some mode.

Re: [libstdc++] Use __gthread_join in jthread/95989

[Alexandre Oliva via Gcc-patches]

Hello, Florian,

On Mar  3, 2023, Florian Weimer  wrote:

> * Alexandre Oliva via Gcc-patches:
>> +// Make sure it's not optimized out, not even with LTO.
>> +asm ("" : : "rm" (depend));

> If the m constraint is used, this may never emit the symbol name and
> thus not create a reference after all.

But that is no longer the pthread symbol itself, it's the symbol of a
static member function with vague linkage that, because the compiler
believes the asm statement will reference it, will still be output, and
it's that function body that will refer to and thus pull in the symbols
we need.

Now, hmm, maybe with per-function sections, the compiler will emit it,
but with section gc, the linker may drop it, so we might lose the needed
function body.  When performing LTO with an LTO-enabled libstdc++.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[Bug c++/108975] [10/11/12/13 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Priority|P3  |P2

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

[isanbard at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Bill Wendling  ---
(In reply to Martin Uecker from comment #9)
> > > Considering that the GNU extensions is rarely used, one could consider
> > > redefining the meaning of
> > > 
> > > int n = 1;
> > > struct {
> > >   int n;
> > >   char buf[n];
> > > };
> > > 
> > > so that the 'n' refers to the member. Or we add a new syntax similar to
> > > designators (which intuitively makes sense to me).
> > designator might be better IMO.
> > 
> > a question here is:
> > 
> > for the following nested structure: 
> > 
> > struct object {
> > ...
> > char items;
> > ...
> > struct inner {
> > ...
> > int flex[];
> > };
> > } *ptr;
> > 
> > what kind of syntax is good to represent the upper bound of "flex" in the 
> > inner
> > struct with "items" in the outer structure? any suggestion?
> 
> I would disallow it. At least at first. It also raises some
> questions: For example, one could form a pointer to the inner
> struct, and then it is not clear how 'items' could be accessed
> anymore.
> 

That would be limiting its use in the Linux kernel. It seems that there are
ways to refer to struct members already using something like "offsetof":

struct object {
...
char items;
...
struct inner {
...
int flex[] __attribute__((__element_count__(offsetof(struct object,
items;
};
} *ptr;

The object referenced by "offsetof" would be from the containing structure (see
"container_of" macro in Linux).

It has the benefit of not needing to extend C's syntax to allow for designated
initializers outside of initialization lists. It also has the benefit of
allowing one to reference a variable not in the structure:

const int items;
struct object {
...
char items;
...
struct inner {
...
int flex[] __attribute__((__element_count__(items))); /* References
global "items" */
};
} *ptr;

-bw

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2023-03-03

--- Comment #2 from Andrew Pinski  ---
The easiest way to figure out what the instruction is failing is run qemu with
gdb stub turned on and connect to it with gdb and then continue and gdb should
stop on the illegal instruction.

[Bug tree-optimization/109011] missed optimization in presence of __builtin_ctz

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Seems they are vectorizing __builtin_ctz (x) as bitsize - .CLZ ((x - 1) & ~x)
for CLZ_DEFINED_VALUE_AT_ZERO 2 with value bitsize.
Perhaps we should pattern match it in tree-vect-patterns.cc that way if clz is
vectorizable (it is with -mavx512cd) and ctz is not.

Re: [libstdc++] Use __gthread_join in jthread/95989

[Florian Weimer]

* Alexandre Oliva via Gcc-patches:

> +// Make sure it's not optimized out, not even with LTO.
> +asm ("" : : "rm" (depend));

If the m constraint is used, this may never emit the symbol name and
thus not create a reference after all.

[Bug target/108315] -mcpu=power10 changes ABI

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

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

Alexander Monakov  changed:

   What|Removed |Added

 Resolution|INVALID |---
 Status|RESOLVED|UNCONFIRMED

--- Comment #16 from Alexander Monakov  ---
Well, from the start I was suggesting that GCC documentation for -mcpu=power10
option should inform the user about the problem (regarding linker support).

Re: [PATCH] libstdc++: testsuite: async.cc early timeout

[Alexandre Oliva via Gcc-patches]

On Feb  3, 2023, Jonathan Wakely  wrote:

> This one slipped through the cracks, sorry.

Oh, nice, thanks, I'd missed the review too, for a whole month :-)

I've just found the unread message.  I'll have a happier weekend.  I did
not even recall this patch was still pending, and this very test was the
one remaining issue for which I got occasional fails on
arm-vx7r2/gcc-12, and I still hadn't started looking into it.

We may still have other fails in this test (we used to have two
different fail modes in async.cc, the other is probably yet to be
upstreamed, but it was just an xfail), but this is progress :-)

> The patch is OK for trunk now (and should still apply cleanly).

Thanks, I'm checking it in now.

>> for  libstdc++-v3/ChangeLog
>> 
>> * testsuite/30_threads/async/async.cc (test04): Initialize
>> steady_start, renamed from steady_begin, next to slow_start.
>> Increase tolerance for final wait.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: [PATCH] Fortran: fix CLASS attribute handling [PR106856]

[Steve Kargl via Gcc-patches]

On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
> -  if (attr->class_ok)
> -/* Class container has already been built.  */
> +  /* Class container has already been built with same name.  */
> +  if (attr->class_ok
> +  && ts->u.derived->components->attr.dimension >= attr->dimension
> +  && ts->u.derived->components->attr.codimension >= attr->codimension
> +  && ts->u.derived->components->attr.class_pointer >= attr->pointer
> +  && ts->u.derived->components->attr.allocatable >= attr->allocatable)

I suppose I'm a bit confused here.  dimension, codimension, 
pointer and allocatable are 1-bit bitfields in the attr
struct.  These can have the values 0 and 1, so the above
conditionals are always true.

The rest of the patch looks reasonable.  If Tobias has no 
objections or comments, it's ok to commit once the above
is explained.

-- 
Steve

Re: [libstdc++] Use __gthread_join in jthread/95989

[Alexandre Oliva via Gcc-patches]

On Mar  3, 2023, Jonathan Wakely  wrote:

> On Fri, 3 Mar 2023 at 18:12, Jonathan Wakely  wrote:

>> And those expressions aren't ever optimized away as unused?

> Oh, I missed that they're called after casting them

*nod*

> That would be UB to call them through the wrong pointer type, so the
> compiler could decide they're unreachable

Ugh, indeed.  We can drop the cast and add the required parameters if it
ever becomes an issue.  Here's what I've just installed.


link pthread_join from std::thread ctor

Like pthread_create, pthread_join may fail to be statically linked in
absent strong uses, so add to user code strong references to both when
std::thread objects are created.


for  libstdc++-v3/ChangeLog

PR libstdc++/104852
PR libstdc++/95989
PR libstdc++/52590
* include/bits/std_thread.h (thread::_M_thread_deps): New
static implicitly-inline member function.
(std::thread template ctor): Pass it to _M_start_thread.
* src/c++11/thread.cc (thread::_M_start_thread): Name depend
parameter, force it live on entry.
---
 libstdc++-v3/include/bits/std_thread.h |   24 +---
 libstdc++-v3/src/c++11/thread.cc   |   10 --
 2 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/include/bits/std_thread.h 
b/libstdc++-v3/include/bits/std_thread.h
index adbd3928ff783..e88c07fbd4f0f 100644
--- a/libstdc++-v3/include/bits/std_thread.h
+++ b/libstdc++-v3/include/bits/std_thread.h
@@ -132,6 +132,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 thread() noexcept = default;
 
 #ifdef _GLIBCXX_HAS_GTHREADS
+  private:
+// This adds to user code that creates std:thread objects (because
+// it is called by the template ctor below) strong references to
+// pthread_create and pthread_join, which ensures they are both
+// linked in even during static linking.  We can't depend on
+// gthread calls to bring them in, because those may use weak
+// references.
+static void
+_M_thread_deps_never_run() {
+#ifdef GTHR_ACTIVE_PROXY
+  reinterpret_cast(_create)();
+  reinterpret_cast(_join)();
+#endif
+}
+
+  public:
 template>>
   explicit
@@ -142,18 +158,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  "std::thread arguments must be invocable after conversion to rvalues"
  );
 
-#ifdef GTHR_ACTIVE_PROXY
-   // Create a reference to pthread_create, not just the gthr weak symbol.
-   auto __depend = reinterpret_cast(_create);
-#else
-   auto __depend = nullptr;
-#endif
using _Wrapper = _Call_wrapper<_Callable, _Args...>;
// Create a call wrapper with DECAY_COPY(__f) as its target object
// and DECAY_COPY(__args)... as its bound argument entities.
_M_start_thread(_State_ptr(new _State_impl<_Wrapper>(
  std::forward<_Callable>(__f), std::forward<_Args>(__args)...)),
-   __depend);
+   _M_thread_deps_never_run);
   }
 #endif // _GLIBCXX_HAS_GTHREADS
 
diff --git a/libstdc++-v3/src/c++11/thread.cc b/libstdc++-v3/src/c++11/thread.cc
index 2d5ffaf678e97..c91f7b02e1f3f 100644
--- a/libstdc++-v3/src/c++11/thread.cc
+++ b/libstdc++-v3/src/c++11/thread.cc
@@ -154,8 +154,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
   void
-  thread::_M_start_thread(_State_ptr state, void (*)())
+  thread::_M_start_thread(_State_ptr state, void (*depend)())
   {
+// Make sure it's not optimized out, not even with LTO.
+asm ("" : : "rm" (depend));
+
 if (!__gthread_active_p())
   {
 #if __cpp_exceptions
@@ -190,8 +193,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
   void
-  thread::_M_start_thread(__shared_base_type __b, void (*)())
+  thread::_M_start_thread(__shared_base_type __b, void (*depend)())
   {
+// Make sure it's not optimized out, not even with LTO.
+asm ("" : : "rm" (depend));
+
 auto ptr = __b.get();
 // Create a reference cycle that will be broken in the new thread.
 ptr->_M_this_ptr = std::move(__b);


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[Bug tree-optimization/109011] missed optimization in presence of __builtin_ctz

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||53947
 Target||x86_64-*-*

--- Comment #2 from Andrew Pinski  ---
>clang vectorize foo using a pattern that invokes vplzcntd


But clang does not vectorize bar :).

Note the x86_64 options were: "-O3 -march=skylake-avx512"


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/109011] missed optimization in presence of __builtin_ctz

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

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

--- Comment #1 from Andrew Pinski  ---
On aarch64, both get vectorized.

[Bug d/108763] va_arg usage in D doesn't compile

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

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #8 from ibuclaw at gcc dot gnu.org ---
Added note on the missing features page.

[committed] d: Document that TypeInfo-based va_arg is not implemented [PR108763]

[Iain Buclaw via Gcc-patches]

Hi,

GDC's run-time library doesn't implement the RTTI-based overload of
va_arg, document it on the missing features page.

Bootstrapped and regression tested, committed to mainline.

Regards,
Iain.

---
PR d/108763

gcc/d/ChangeLog:

* implement-d.texi (Missing Features): Document that TypeInfo-based
va_arg is not implemented.
---
 gcc/d/implement-d.texi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/d/implement-d.texi b/gcc/d/implement-d.texi
index 89a17916a83..039e5fbd24e 100644
--- a/gcc/d/implement-d.texi
+++ b/gcc/d/implement-d.texi
@@ -2511,4 +2511,10 @@ version (GNU)
 @}
 @end smallexample
 
+@item TypeInfo-based va_arg
+The Digital Mars D compiler implements a version of @code{core.vararg.va_arg}
+that accepts a run-time @code{TypeInfo} argument for use when the static type
+is not known.  This function is not implemented by GNU D.  It is more portable
+to use variadic template functions instead.
+
 @end table
-- 
2.37.2

[Bug d/108763] va_arg usage in D doesn't compile

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:1f83aee5864129c4147a95c1a4e35d37c7eb7e59

commit r13-6463-g1f83aee5864129c4147a95c1a4e35d37c7eb7e59
Author: Iain Buclaw 
Date:   Fri Mar 3 20:39:59 2023 +0100

d: Document that TypeInfo-based va_arg is not implemented

PR d/108763

gcc/d/ChangeLog:

* implement-d.texi (Missing Features): Document that TypeInfo-based
va_arg is not implemented.

[Bug libstdc++/104852] std::[j]thread::detach() still gives segmentation faults with glibc 2.34

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

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #9 from Alexandre Oliva  ---
Should be fixed in the trunk (targeting 13).
AFAIK it fails with 12 and 11.
I know the patch works with 12, I've tested it there.

Re: MicroBlaze symver attribute support

[Vincent Fazio via Gcc]

All

On Mon, Feb 20, 2023 at 7:35 PM Michael Eager  wrote:

> On 2/20/23 06:54, Joel Sherrill wrote:
> >
> >
> > On Mon, Feb 20, 2023 at 7:56 AM Vincent Fazio via Gcc  > > wrote:
> >
> > Michael, all,
> >
> > Regarding:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101766
> > 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102110
> > 
> >
> > If I understand correctly, since the GCC MicroBlaze targets generate
> ELF
> > images, it would seem there's no technical reason why `__attribute__
> > ((symver ...))` cannot be supported?
> >
> > The issue seems to be that the MicroBlaze targets in config.gcc do
> not
> > include elfos.h
> > https://github.com/gcc-mirror/gcc/blob/master/gcc/config.gcc#L2369
> > 
> >
> > Which defines `ASM_OUTPUT_SYMVER_DIRECTIVE`
> >
> https://github.com/gcc-mirror/gcc/blob/master/gcc/config/elfos.h#L259 <
> https://github.com/gcc-mirror/gcc/blob/master/gcc/config/elfos.h#L259>
> >
> > Which is necessary for
> > https://github.com/gcc-mirror/gcc/blob/master/gcc/varasm.cc#L6260
> > 
> >
> > Changing the targets to include elfos.h leads to a number of
> > conflicts with
> > the target specific header (config/microblaze/microblaze.h).
> >
> > Should `ASM_OUTPUT_SYMVER_DIRECTIVE` be copied into
> > config/microblaze/microblaze.h or should the MicroBlaze targets and
> > header
> > be reworked to support elfos.h?
> >
> >
> > IMO reworked to include elfos.h. During the RTEMS port, we noticed that
> > some quirks on the microblaze gcc because it isn't using elfos.h. This
> > likely
> > will mean it will be updated as a side-effect of normal GCC maintenance
> > instead of being an odd singleton which doesn't share.
> >
> >
> > I'm asking because I've seen a number of projects run into this
> > issue (xz,
> > elfutils, libfuse, libkcapi, cryptsetup).
> >
> >
> > And RTEMS.
> >
> > --joel
>
>
> Joel -- do you have a patch to add elfos.h to MicroBlaze?
>
>

I have a very crude commit here off of 11.3.0:

https://github.com/vfazio/gcc/commit/e65fea47b881b136f6753001791ebf68a4874dd6

I've tested it as a patch on Buildroot's toolchain and dropped the patch we
used to hack
around the previous lack of symver support for XZ. I was able to boot the
resultant kernel
and rootfs via qemu-system-microblaze and the symbol versions XZ expects
are included
based on discussions with the maintainer
https://github.com/tukaani-project/xz/pull/32#issuecomment-1424531920

I doubt the work is "complete" but it's a starting point.

-- 
> Michael Eager
>

[Bug target/108315] -mcpu=power10 changes ABI

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

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

--- Comment #15 from Segher Boessenkool  ---
(In reply to Alexander Monakov from comment #14)
> Are you guys really sure you want to blame the user here,

I apologise if this hasn't been a nice experience for you.

I'm not blaming anyone, least of all the user.  That is not what bugzilla is
for anyway.  The goal here is to work together on improving the compiler.

I marked the bug as RESOLVED INVALID because a) there is nothing left to be
done to resolve this PR, and b) that is because there never was anything to
be done (in GCC!) in the first place.

If this is not correct, please add some info clarifying that, and reopen the
PR?

> considering that
> all linkers, including the BFD linker, initially misinterpreted the ABI the
> same way?

It wasn't implemented correctly there either, yes.  That does not necessarily
mean the ABI was misinterpreted, but sure, that could be.  In either case
that has nothing to do with GCC.

[Bug c++/101118] coroutines: unexpected ODR warning for coroutine frame type in LTO builds

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

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

--- Comment #11 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #10)
> Hmm... maybe I am being too hasty here.
> 
> If the coroutine has a definition in a header, then the coroutine frame type
> _should_ be the same for each instance of it.  So maybe this is actually
> reporting a genuine ODR violation?

ah (I still misread) ... so the reported error is that the frame type *is* the
same (which is correct) but the field names differ (which is probably a
consequence of using static counters to produce them).  So we need a stable way
to generate the field names.

[Bug c++/101118] coroutines: unexpected ODR warning for coroutine frame type in LTO builds

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

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

--- Comment #10 from Iain Sandoe  ---
Hmm... maybe I am being too hasty here.

If the coroutine has a definition in a header, then the coroutine frame type
_should_ be the same for each instance of it.  So maybe this is actually
reporting a genuine ODR violation?

[Bug analyzer/109016] New: Analyzer doesn't know about OMP builtins

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

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

Bug ID: 109016
   Summary: Analyzer doesn't know about OMP builtins
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54581
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54581=edit
Work in progress patch

Currently the analyzer doesn't recognize omp builtins, and falls back to the
"anything could happen" handler when it sees them.

Am attaching a work-in-progress patch I tried which terminates the analysis
path if it sees one of them, on the grounds that the analyzer currently has no
knowledge of e.g. OpenMP.

Unfortunately, as-is, this regresses the integration tests (all in
ImageMagick-7.1.0-57); presumably due to spending its analysis budget on other
execution paths:

Comparison: 10.91% -> 10.77% GOOD: 67 BAD: 547 -> 555 (+8)
  -Wanalyzer-use-of-uninitialized-value: 0.00% GOOD: 0 BAD: 80 -> 87 (+7)
  -Wanalyzer-deref-before-check: 5.00% -> 4.76% GOOD: 1 BAD: 19 -> 20 (+1)

[Bug libstdc++/104852] std::[j]thread::detach() still gives segmentation faults with glibc 2.34

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:21edd841611a97442a6b95e8ec7e91ff8fd3a451

commit r13-6461-g21edd841611a97442a6b95e8ec7e91ff8fd3a451
Author: Alexandre Oliva 
Date:   Fri Mar 3 15:59:36 2023 -0300

link pthread_join from std::thread ctor

Like pthread_create, pthread_join may fail to be statically linked in
absent strong uses, so add to user code strong references to both when
std::thread objects are created.


for  libstdc++-v3/ChangeLog

PR libstdc++/104852
PR libstdc++/95989
PR libstdc++/52590
* include/bits/std_thread.h (thread::_M_thread_deps): New
static implicitly-inline member function.
(std::thread template ctor): Pass it to _M_start_thread.
* src/c++11/thread.cc (thread::_M_start_thread): Name depend
parameter, force it live on entry.

[Bug libstdc++/52590] std::thread Segmentation fault static linking

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:21edd841611a97442a6b95e8ec7e91ff8fd3a451

commit r13-6461-g21edd841611a97442a6b95e8ec7e91ff8fd3a451
Author: Alexandre Oliva 
Date:   Fri Mar 3 15:59:36 2023 -0300

link pthread_join from std::thread ctor

Like pthread_create, pthread_join may fail to be statically linked in
absent strong uses, so add to user code strong references to both when
std::thread objects are created.


for  libstdc++-v3/ChangeLog

PR libstdc++/104852
PR libstdc++/95989
PR libstdc++/52590
* include/bits/std_thread.h (thread::_M_thread_deps): New
static implicitly-inline member function.
(std::thread template ctor): Pass it to _M_start_thread.
* src/c++11/thread.cc (thread::_M_start_thread): Name depend
parameter, force it live on entry.

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

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

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

--- Comment #23 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:21edd841611a97442a6b95e8ec7e91ff8fd3a451

commit r13-6461-g21edd841611a97442a6b95e8ec7e91ff8fd3a451
Author: Alexandre Oliva 
Date:   Fri Mar 3 15:59:36 2023 -0300

link pthread_join from std::thread ctor

Like pthread_create, pthread_join may fail to be statically linked in
absent strong uses, so add to user code strong references to both when
std::thread objects are created.


for  libstdc++-v3/ChangeLog

PR libstdc++/104852
PR libstdc++/95989
PR libstdc++/52590
* include/bits/std_thread.h (thread::_M_thread_deps): New
static implicitly-inline member function.
(std::thread template ctor): Pass it to _M_start_thread.
* src/c++11/thread.cc (thread::_M_start_thread): Name depend
parameter, force it live on entry.

[Bug target/51534] Bad code gen for vcgtq_u32 NEON intrinsic

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

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

commit r13-6457-gcc9cc5a9a5fb0c16532a16b87fbd155037a7ed89
Author: Alexandre Oliva 
Date:   Fri Mar 3 15:59:21 2023 -0300

[PR51534] [arm] split out pr51534 test for softfp

The test uses arm_hard_ok and arm_softfp_ok as if they were mutually
exclusive, but they test whether the corresponding -mfloat-abi= flag
is usable, not whether it is in effect, so it is possible for both to
pass, and then the test comes out with incorrect expectations
whichever the default float-abi is.

Separate the test into hard and softfp variants, and extend the softfp
variant to accept both ARM and Thumb opcodes; it unwarrantedly assumed
the latter.


for  gcc/testsuite/ChangeLog

PR target/51534
* gcc.target/arm/pr51534.c: Split softfp variant into...
* gcc.target/arm/pr51534s.c: ... this, and support ARM too.

[Bug target/104882] [12 Regression] MVE: Wrong code at -O2 since r12-1434-g046a3beb1673bf4a61c131373b6a5e84158e92bf

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:220008eafaaed7433b1c18e394279391e885a138

commit r13-6455-g220008eafaaed7433b1c18e394279391e885a138
Author: Alexandre Oliva 
Date:   Fri Mar 3 15:59:14 2023 -0300

[PR104882] [arm] require mve hw for mve run test

The pr104882.c test is an execution test, but arm_v8_1m_mve_ok only
tests for compile-time support.  Add a requirement for mve hardware.


for  gcc/testsuite/ChangeLog

PR target/104882
* gcc.target/arm/simd/pr104882.c: Require mve hardware.

[Bug analyzer/109015] New: Analyzer doesn't know about atomic builtins

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

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

Bug ID: 109015
   Summary: Analyzer doesn't know about atomic builtins
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54580
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54580=edit
Work in progress patch

Currently the analyzer doesn't recognize atomic builtins, and falls back to the
"anything could happen" handler when it sees them.

Am attaching a work-in-progress patch which implements most of them

Re: [PATCH] cygwin: Don't try to support multilibs [PR107998]

[Jakub Jelinek via Gcc-patches]

On Wed, Feb 22, 2023 at 01:02:58PM +, Jonathan Yong wrote:
> On 2/22/23 09:25, Jakub Jelinek wrote:
> > As discussed in the PR, t-cygwin-w64 file has been introduced in 2013
> > and has one important problem, two different multilib options -m64 and -m32,
> > but MULTILIB_DIRNAMES with just one word in it.
> > Before the genmultilib sanity checking was added, my understanding is that
> > this essentially resulted in effective --disable-multilib,
> > $ gcc -print-multi-lib
> > .;
> > ;@m32
> > $ gcc -print-multi-directory
> > .
> > $ gcc -print-multi-directory -m64
> > .
> > $ gcc -print-multi-directory -m32
> > 
> > $ gcc -print-multi-os-directory
> > ../lib
> > $ gcc -print-multi-os-directory -m64
> > ../lib
> > $ gcc -print-multi-os-directory -m32
> > ../lib32
> > and because of the way e.g. config-ml.in operates
> > multidirs=
> > for i in `${CC-gcc} --print-multi-lib 2>/dev/null`; do
> >dir=`echo $i | sed -e 's/;.*$//'`
> >if [ "${dir}" = "." ]; then
> >  true
> >else
> >  if [ -z "${multidirs}" ]; then
> >multidirs="${dir}"
> >  else
> >multidirs="${multidirs} ${dir}"
> >  fi
> >fi
> > done
> > dir was . first time (and so nothing was done) and empty
> > second time, multidirs empty too, so multidirs was set to empty
> > like it would be with --disable-multilib.
> > 
> > With the added sanity checking the build fails unless --disable-multilib
> > is used in configure (dunno whether people usually configure that way
> > on cygwin).
> > 
> > > From what has been said in the PR, multilibs were not meant to be 
> > > supported
> > and e.g. cygwin headers probably aren't ready for it.
> > 
> > So the following patch just removes the file with the (incorrect) multilib
> > stuff instead of fixing it (say by setting MULTILIB_DIRNAMES to 64 32).
> > 
> > I have no way to test this though, no Windows around, can anyone please
> > test this?  I just would like to get some progress on the P1s we have...
> > 
> > 2023-02-22  Jakub Jelinek  
> > 
> > PR target/107998
> > * config.gcc (x86_64-*-cygwin*): Don't add i386/t-cygwin-w64 into
> > $tmake_file.
> > * config/i386/t-cygwin-w64: Remove.
> > 
> > --- gcc/config.gcc.jj   2023-02-18 12:38:30.803025062 +0100
> > +++ gcc/config.gcc  2023-02-21 17:07:12.143164563 +0100
> > @@ -2105,7 +2105,7 @@ x86_64-*-cygwin*)
> > need_64bit_isa=yes
> > tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h i386/cygming.h 
> > i386/cygwin.h i386/cygwin-w64.h i386/cygwin-stdint.h"
> > xm_file=i386/xm-cygwin.h
> > -   tmake_file="${tmake_file} i386/t-cygming t-slibgcc i386/t-cygwin-w64"
> > +   tmake_file="${tmake_file} i386/t-cygming t-slibgcc"
> > target_gtfiles="$target_gtfiles \$(srcdir)/config/i386/winnt.cc"
> > extra_options="${extra_options} i386/cygming.opt i386/cygwin.opt"
> > extra_objs="${extra_objs} winnt.o winnt-stubs.o"
> > --- gcc/config/i386/t-cygwin-w64.jj 2020-01-12 11:54:36.333414616 +0100
> > +++ gcc/config/i386/t-cygwin-w642023-02-21 17:06:44.121572616 +0100
> > @@ -1,3 +0,0 @@
> > -MULTILIB_OPTIONS = m64/m32
> > -MULTILIB_DIRNAMES = 64
> > -MULTILIB_OSDIRNAMES = ../lib ../lib32
> 
> Achim, mind looking at this?
> Resending due to mail client problems, hopefully not a duplicate.

NightStrike on IRC said he has tested the patch and it worked fine.

Is the patch ok for trunk then?

Jakub

[Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1

[tstellar at redhat dot com via Gcc-bugs]

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

--- Comment #11 from Tom Stellard  ---
(In reply to Jakub Jelinek from comment #10)
> I'd start with verification if it is really libgcc, so don't recompile the
> app, just try it against GCC 12.2.1 libgcc vs. 13.0.1.

I confirmed it's libgcc.  On F37, the test passes, but then if I do `dnf
upgrade --releasever 39 libgcc` the test fails.

I'll start trying to bisect.

[Bug analyzer/109014] -Wanalyzer-use-of-uninitialized-value seen in pcre2-10.42's pcre2test.c

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

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

--- Comment #1 from David Malcolm  ---
I believe the issue here is that:

* display_properties partially initializes the "found" buffer, writing a -1
terminator at the end of the initialized part at:

fv[m] = -1;

* display_properties then calls format_list_item, which tries to find the
terminator with:

 for (count = 0; ff[count] >= 0; count++) {

* -fanalyzer isn't smart enough to know that a -1 terminator has been written,
and simulates iterating past the end of the initialized region

and this is currently masked by the "sprintf" call, which in the absence of a
known_function implementation is currently assumed to potentially write to fv.

Re: [GSoC] Introduction and query on LTO object emmission project

[Jan Hubicka via Gcc]

Hello,
> Hi! I've been interested in compiler development for a while, and would love 
> to
> work with any of you as part of GSoC, or even just as a side-project on my 
> own.
> 
> I'm an 18 year-old student going into university next year with a passion for 
> all
> things open source and low level. I consider myself fluent in c, and 
> proficient
> with c++, rust, and x86 assembly, but unfamiliar with practical compiler 
> design.
> I have done some reading on the theoretical aspects of compilers, however.
> 
> While I haven't worked with the GCC community before, I have worked with the 
> linux
> community and have made several small patches there, so I am familiar with 
> both
> email-based workflows and the principles of open-source development. 
> 
> This summer, I'm looking for more experience working on larger projects, as 
> well
> as getting into real compilers.
> 
> Of particular interest to me is the project idea labelled "Bypass assembler 
> when
> generating LTO object files." I see that the project was taken last year, but
> I can find no sign of any changes committed to trunk 
> (`git shortlog --after=2022-01-01 | grep -i -E "lto|assembl(er|y)"` shows 
> nothing
> related to this project) and no sign of any needed change made in the code.
> Is this project still available?

yes, the project is available and Maritn Jambor  and me
would be happy to mentor it. Please add me and Martin to CC of any
emails on the proejt.

I think it would be good to start by looking at the original work in
progress patch (linked from the task description, an updated version is
here https://gcc.gnu.org/pipermail/gcc/2022-May/238670.html).   Overall
struture of the LTO optimization is described in paper
https://arxiv.org/abs/1010.2196

One problem is that the object files produced by libiberty/simple-object.c
(which is the low-level API used by the LTO code)
are missing some information (such as the architecture info and symbol
table) and API of the simple object will need to be extended to handle
that.  So I think getting familiar with simple-object.c and the
elf/mach/coff handlers of it would be a good initital step.  It will be
necessary to add API to specify the architecture and symbols in the
symbol table so the resulting object files are recognized by linker.

Second part would be handling of output of dwarf debug information, so
it may make sense to also take a quick look on its documentation.  The
on-disk representation is actually not too hard and it should be
possible to make a direct writer.

Jan
> 
> I'm also willing to work on other projects, ideally in the middle/backend, but
> currently I have only been experimenting with the gcc/[lto,data]-streamer* 
> files.
> If anyone has a small or medium sized project idea, please feel free to let 
> me know.
> 
> 
> I look forward to working with all of you in the future,
> 
> Peter Lafreniere
> 
> 

Re: [PATCHv4] [AARCH64] Fix PR target/103100 -mstrict-align and memset on not aligned buffers

[Andrew Pinski via Gcc-patches]

On Thu, Feb 9, 2023 at 7:54 PM Andrew Pinski via Gcc-patches
 wrote:
>
> The problem here is that aarch64_expand_setmem does not change the alignment
> for strict alignment case.
> This is version 4 of the fix, major changes from the last version is fixing
> the way store pairs are handled which allows handling of storing 2 SI mode
> at a time.
> This also adds a testcase to show a case with -mstrict-align we can do
> the store word pair stores.
>
> OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.

Ping?

>
> PR target/103100
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.cc (aarch64_gen_store_pair):
> Add support for SImode.
> (aarch64_set_one_block_and_progress_pointer):
> Add use_pair argument and rewrite and simplifying the
> code.
> (aarch64_can_use_pair_load_stores): New function.
> (aarch64_expand_setmem): Rewrite mode selection to
> better handle strict alignment and non ld/stp pair case.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/aarch64/memset-strict-align-1.c: Update test.
> Reduce the size down to 207 and make s1 global and aligned
> to 16 bytes.
> * gcc.target/aarch64/memset-strict-align-2.c: New test.
> * gcc.target/aarch64/memset-strict-align-3.c: New test.
> ---
>  gcc/config/aarch64/aarch64.cc | 136 ++
>  .../aarch64/memset-strict-align-1.c   |  19 ++-
>  .../aarch64/memset-strict-align-2.c   |  14 ++
>  .../aarch64/memset-strict-align-3.c   |  15 ++
>  4 files changed, 113 insertions(+), 71 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/memset-strict-align-2.c
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/memset-strict-align-3.c
>
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index 5c40b6ed22a..3eaf9bd608a 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -8850,6 +8850,9 @@ aarch64_gen_store_pair (machine_mode mode, rtx mem1, 
> rtx reg1, rtx mem2,
>  {
>switch (mode)
>  {
> +case E_SImode:
> +  return gen_store_pair_sw_sisi (mem1, reg1, mem2, reg2);
> +
>  case E_DImode:
>return gen_store_pair_dw_didi (mem1, reg1, mem2, reg2);
>
> @@ -24896,42 +24899,49 @@ aarch64_expand_cpymem (rtx *operands)
> SRC is a register we have created with the duplicated value to be set.  */
>  static void
>  aarch64_set_one_block_and_progress_pointer (rtx src, rtx *dst,
> -   machine_mode mode)
> +   machine_mode mode, bool use_pairs)
>  {
> +  rtx reg = src;
>/* If we are copying 128bits or 256bits, we can do that straight from
>   the SIMD register we prepared.  */
> -  if (known_eq (GET_MODE_BITSIZE (mode), 256))
> -{
> -  mode = GET_MODE (src);
> -  /* "Cast" the *dst to the correct mode.  */
> -  *dst = adjust_address (*dst, mode, 0);
> -  /* Emit the memset.  */
> -  emit_insn (aarch64_gen_store_pair (mode, *dst, src,
> -aarch64_progress_pointer (*dst), 
> src));
> -
> -  /* Move the pointers forward.  */
> -  *dst = aarch64_move_pointer (*dst, 32);
> -  return;
> -}
>if (known_eq (GET_MODE_BITSIZE (mode), 128))
> -{
> -  /* "Cast" the *dst to the correct mode.  */
> -  *dst = adjust_address (*dst, GET_MODE (src), 0);
> -  /* Emit the memset.  */
> -  emit_move_insn (*dst, src);
> -  /* Move the pointers forward.  */
> -  *dst = aarch64_move_pointer (*dst, 16);
> -  return;
> -}
> -  /* For copying less, we have to extract the right amount from src.  */
> -  rtx reg = lowpart_subreg (mode, src, GET_MODE (src));
> +mode = GET_MODE(src);
> +  else
> +/* For copying less, we have to extract the right amount from src.  */
> +reg = lowpart_subreg (mode, src, GET_MODE (src));
>
>/* "Cast" the *dst to the correct mode.  */
>*dst = adjust_address (*dst, mode, 0);
>/* Emit the memset.  */
> -  emit_move_insn (*dst, reg);
> +  if (use_pairs)
> +emit_insn (aarch64_gen_store_pair (mode, *dst, reg,
> +  aarch64_progress_pointer (*dst),
> +  reg));
> +  else
> +emit_move_insn (*dst, reg);
> +
>/* Move the pointer forward.  */
>*dst = aarch64_progress_pointer (*dst);
> +  if (use_pairs)
> +*dst = aarch64_progress_pointer (*dst);
> +}
> +
> +/* Returns true if size can be used as a store/load pair.
> +   This is a helper function for aarch64_expand_setmem and others. */
> +static bool
> +aarch64_can_use_pair_load_stores (unsigned HOST_WIDE_INT size)
> +{
> +  /* For DI and SI modes, we can use store pairs.  */
> +  if (size == GET_MODE_BITSIZE (DImode)
> +  || size == GET_MODE_BITSIZE (SImode))
> +return true;
> +  /* For TI mode, we will use store pairs only if
> + 

[Bug debug/108996] Proposal for adding DWARF call site information in GCC with -O0

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Ulrich Weigand from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > What is done on other arches?
> 
> That depends on the platform ABI.  On some arches, including x86/x86_64 and
> arm/aarch64, the ABI requires the generated code reloads the return buffer
> pointer into a defined register at function exit (either the same it was in
> on function entry, or some other ABI-defined register).  On those arches,
> GDB can at least inspect the return value at the point the function return
> happens.

aarch64 does not require that. GCC produces it yes but that is a missed
optimization, see PR 103010 which I filed against GCC for that case.

[Bug target/109007] building for POWER8 leaks into POWER9 ISA with g++ 11.3 (cross-compiler on x86_64 host)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
It would be helpful if you could tell which instruction is considered illegal
by QEMU, found in which *.o file it is and provided preprocessed source + gcc
command line how that single compilation unit has been compiled.
See https://gcc.gnu.org/bugs.html on details for what we want and don't want.

[Bug analyzer/109014] New: -Wanalyzer-use-of-uninitialized-value seen in pcre2-10.42's pcre2test.c

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

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

Bug ID: 109014
   Summary: -Wanalyzer-use-of-uninitialized-value seen in
pcre2-10.42's pcre2test.c
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54579
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54579=edit
Partially reducer reproducer

I'm about to commit a patch that provides a prototype implementation of
sprintf; this leads to a new false positive on the attached:


pcre2test.c: In function 'format_list_item':
pcre2test.c:4448:21: warning: use of uninitialized value '*ff_44(D) + _2'
[CWE-457] [-Wanalyzer-use-of-uninitialized-value]
 4448 |   for (count = 0; ff[count] >= 0; count++) {
  |   ~~^~~
  'main': events 1-12
|
| 4565 | main(int argc, char** argv)
|  | ^~~~
|  | |
|  | (1) entry to 'main'
|..
| 4579 |   while (argc > 1 && argv[op][0] == '-' && argv[op][1] != 0) {
|  |  ~~
|  | |
|  | (2) following 'true'
branch...
|  | (8) following 'true'
branch...
| 4580 | /* [...snip...] */
| 4581 | char* arg = argv[op];
|  | ~
|  | |
|  | (3) ...to here
|  | (9) ...to here
|..
| 4585 | if (strcmp(arg, "-LP") == 0) {
|  |~
|  ||
|  |(4) following 'false' branch (when the strings are
non-equal)...
|  |(10) following 'true' branch (when the strings are
equal)...
| 4586 |   display_properties(0);
|  |   ~
|  |   |
|  |   (11) ...to here
|  |   (12) calling 'display_properties' from 'main'
|..
| 4592 | if (strcmp(arg, "-8") == 0) {
|  |~~
|  |||
|  ||(5) ...to here
|  |(6) following 'true' branch (when the strings are equal)...
| 4593 |   test_mode = 8;
|  |   ~
|  | |
|  | (7) ...to here
|
+--> 'display_properties': events 13-25
   |
   | 4481 | display_properties(BOOL wantscripts)
   |  | ^~
   |  | |
   |  | (13) entry to 'display_properties'
   |..
   | 4487 |   int16_t found[256][5 + 1];
   |  |   ~
   |  |   |
   |  |   (14) region created on stack here
   |..
   | 4492 |   if (wantscripts) {
   |  |  ~
   |  |  |
   |  |  (15) following 'false' branch (when 'wantscripts ==
0')...
   |..
   | 4496 | n = ucp_Bprop_Count;
   |  | ~~~
   |  |   |
   |  |   (16) ...to here
   |..
   | 4500 |   for (size_t i = 0; i < utt_size; i++) {
   |  |  
   |  ||
   |  |(17) following 'true' branch...
   | 4501 | int k;
   | 4502 | int m = 0;
   |  | ~
   |  | |
   |  | (18) ...to here
   |..
   | 4507 | if (wantscripts) {
   |  |~
   |  ||
   |  |(19) following 'false' branch (when 'wantscripts ==
0')...
   |..
   | 4511 |   if (t->type != 13)
   |  |  
   |  |  | |
   |  |  | (20) ...to here
   |  |  (21) following 'true' branch...
   |  |  (22) ...to here
   |..
   | 4544 |   for (int k = 0; k < (n + 1) / 2; k++) {
   |  |   ~~~
   |  | |
   |  | (23) following 'true' branch...
   |..
   | 4549 | format_list_item(found[k], buff1, wantscripts);
   |  | ~~
   |  | | |
   |  | | (24) ...to here
   |  | (25) calling 'format_list_item' from
'display_properties'
   |
   +--> 'format_list_item': events 26-27
 

[gnu.org #1880318] Antoni Boucher, modified employer disclaimer

[Craig Topham via RT via Gcc]

On 2023-02-28 17:44:55, boua...@zoho.com wrote:
> Hi.
> Here is the document signed.
> Thank you.
> 
My apologies, I was unexpectedly out the last couple of days. This has been 
resolved and you are clear to contribute with the new employer disclaimer in 
place.

Thank you for your patience and I appreciate you following through.

~Craig


> On Tue, 2023-02-28 at 15:29 -0500, Craig Topham via RT wrote:
> > On 2023-02-27 10:33:46, boua...@zoho.com wrote:
> > > Hi.
> > > Any update on this?
> > > Regards.
> > > 
> > 
> > Yes. The adaptation seems fine indeed, but there a couple of small
> > issues with the text:
> > 
> > then the Free Software Foundation and the general public will be
> > permanently and irrevocably licensed solely as necessary to use,
> > distribute, and permit modifications by anyone, the contributions as
> > originally authored by Antoni Bouche in
> > these works in the Released Categories of programs they enhance,
> > withoutroyalty or limitation, the subject matter of the dominating
> > interest.
> > 
> > -- there should be a "to" after anyone and I would probably leave out
> > the comma too.
> > -- Boucher
> > -- without royalty
> > 
> > If you can get these corrected and print/sign the disclaimer we
> > should be good to go.
> > 
> > ~Craig
> > 
> > 
> > > On Tue, 2023-02-14 at 21:51 -0500, Antoni Boucher wrote:
> > > > Hi.
> > > > They change the text.
> > > > I attached the new version.
> > > > Does that look correct?
> > > > Thanks.
> > > > 
> > > > On Mon, 2023-01-30 at 16:01 -0500, Craig Topham via RT wrote:
> > > > > On 2023-01-30 09:27:02, boua...@zoho.com wrote:
> > > > > > Hi.
> > > > > > Any news on this?
> > > > > > Thanks.
> > > > > > 
> > > > > > On Tue, 2022-12-13 at 13:58 -0500, Craig Topham via RT wrote:
> > > > > > > On 2022-12-13 10:24:30, boua...@zoho.com wrote:
> > > > > > > > Hi.
> > > > > > > > Is there any progress here?
> > > > > > > 
> > > > > 
> > > > > We have made some progress. However, there is some other
> > > > > language
> > > > > that concerns us. In the second to last paragraph it reads,
> > > > > "...solely as necessary to use the contributions as originally
> > > > > authored...".
> > > > > 
> > > > > As stated, it would only cover your original contributions
> > > > > unedited.
> > > > > Therefore, versions of your contributions edited by other
> > > > > developers
> > > > > would not be covered by this disclaimer. Can you request to
> > > > > have
> > > > > this
> > > > > language changed?
> > > > > 
> > > > > Assuming this can be corrected there is no other language in
> > > > > the
> > > > > disclaimer that concerns us, so we could proceed with accepting
> > > > > this
> > > > > disclaimer.
> > > > > 
> > > > > Thank you again for working through this process.
> > > > > 
> > > > > ~Craig
> > > > > 
> > > > > 
> > > > > > > Thank you for the ping. I have no new updates at this time
> > > > > > > except
> > > > > > > that the removal of the problematic sentence allows us to
> > > > > > > look
> > > > > > > at
> > > > > > > the
> > > > > > > other language in the disclaimer. I am glad to say yours is
> > > > > > > next
> > > > > > > to
> > > > > > > be reviewed. Please feel free to ping me at any time for an
> > > > > > > update.
> > > > > > > 
> > > > > > > ~Craig
> > > > > > > 
> > > > > > > 
> > > > > > > > Regards.
> > > > > > > > 
> > > > > > > > On Thu, 2022-12-01 at 12:08 -0500, Antoni Boucher wrote:
> > > > > > > > > They're ok with removing that sentence.
> > > > > > > > > Do you have any news from the legal counsel?
> > > > > > > > > 
> > > > > > > > > On Tue, 2022-11-22 at 16:02 -0500, Craig Topham via RT
> > > > > > > > > wrote:
> > > > > > > > > > On 2022-11-22 09:52:51, boua...@zoho.com wrote:
> > > > > > > > > > > Hi.
> > > > > > > > > > > I got the answer to that question from my company:
> > > > > > > > > > > 
> > > > > > > > > > >    Since this is an FSF form, once we sign the
> > > > > > > > > > > disclaimer, it
> > > > > > > > > > > will
> > > > > > > > > > > be
> > > > > > > > > > >    binding between the parties even though there is
> > > > > > > > > > > no
> > > > > > > > > > > signature
> > > > > > > > > > > field
> > > > > > > > > > >    for FSF. The language itself would be sufficient
> > > > > > > > > > > to
> > > > > > > > > > > be
> > > > > > > > > > > binding
> > > > > > > > > > >    between the parties.
> > > > > > > > > > >    
> > > > > > > > > > 
> > > > > > > > > > Thank you for clarifying. I know we will be able to
> > > > > > > > > > work
> > > > > > > > > > through
> > > > > > > > > > this, but that sentence as written would allow
> > > > > > > > > > ServiceNow
> > > > > > > > > > to
> > > > > > > > > > violate
> > > > > > > > > > the licenses of GNU packages while preventing the FSF
> > > > > > > > > > from
> > > > > > > > > > enforcing
> > > > > > > > > > the GPL. We simply can't agree to that. I understand
> > > > > > > > > > the
> > > > > > > > > > intent
> > > > > > > > > > is
> > > > > > > > > > to
> > 

[Bug target/108315] -mcpu=power10 changes ABI

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

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

--- Comment #14 from Alexander Monakov  ---
Are you guys really sure you want to blame the user here, considering that all
linkers, including the BFD linker, initially misinterpreted the ABI the same
way?

[Bug middle-end/109006] [13 Regression] Python Exception : There is no member or method named m_vecdata. since r13-6332

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:59a576f274b9093fd4b25eb6be556b40c2424478

commit r13-6454-g59a576f274b9093fd4b25eb6be556b40c2424478
Author: Jonathan Wakely 
Date:   Fri Mar 3 16:41:29 2023 +

gcc: Fix gdbhooks.py VecPrinter for vec<> as well as vec<>* [PR109006]

gcc/ChangeLog:

PR middle-end/109006
* gdbhooks.py (VecPrinter): Handle vec as well as vec*.

Re: [libstdc++] Use __gthread_join in jthread/95989

[Jonathan Wakely via Gcc-patches]

On Fri, 3 Mar 2023 at 18:12, Jonathan Wakely  wrote:

>
>
> On Fri, 3 Mar 2023 at 17:47, Alexandre Oliva  wrote:
>
>> On Mar  3, 2023, Jonathan Wakely  wrote:
>>
>> > On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely 
>> wrote:
>> >> Jakub previously suggested doing this for PR 61841, which was a similar
>> >> problem with pthread_create:
>> >>
>> >> __asm ("" : : "r" (_create)); would not be optimized away.
>> >>
>> >>
>> >> That would avoid the multiple copies.
>>
>> Not really.  There would be multiple copies of the code that loads
>> pthread_create's address.  And we don't really need the address, a
>> single never-executed call would do.  I've explored these possibilities
>> a bit, and here's what I've come up with: a private static member
>> function that we output in units that instantiate the thread template
>> ctor, to pass its address to _M_start_thread.  Since it's never actually
>> called, we don't really need the hacks in some of the alternatives I
>> left in place, mainly for your enjoyment.
>>
>> They all work equally well, just as efficient per-instantiation at
>> runtime, a little different space and loading overheads, but the last
>> one, that is enabled, is my favorite: only PLT relocations, that we'd
>> likely get anyway, no full-address resolution, and as-short-as-possible
>> calls, enough to get a relocation with a strong reference to pull the
>> symbol in when linking, but as short as possible call sequences, because
>> of the type cast.
>>
>
> And those expressions aren't ever optimized away as unused?
>

Oh, I missed that they're called after casting them, I didn't notice the
trailing ().

That would be UB to call them through the wrong pointer type, so the
compiler could decide they're unreachable, but it seems to work for now.

Thanks!

Re: [libstdc++] Use __gthread_join in jthread/95989

[Jonathan Wakely via Gcc-patches]

On Fri, 3 Mar 2023 at 17:47, Alexandre Oliva  wrote:

> On Mar  3, 2023, Jonathan Wakely  wrote:
>
> > On Fri, 3 Mar 2023 at 09:33, Jonathan Wakely  wrote:
> >> Jakub previously suggested doing this for PR 61841, which was a similar
> >> problem with pthread_create:
> >>
> >> __asm ("" : : "r" (_create)); would not be optimized away.
> >>
> >>
> >> That would avoid the multiple copies.
>
> Not really.  There would be multiple copies of the code that loads
> pthread_create's address.  And we don't really need the address, a
> single never-executed call would do.  I've explored these possibilities
> a bit, and here's what I've come up with: a private static member
> function that we output in units that instantiate the thread template
> ctor, to pass its address to _M_start_thread.  Since it's never actually
> called, we don't really need the hacks in some of the alternatives I
> left in place, mainly for your enjoyment.
>
> They all work equally well, just as efficient per-instantiation at
> runtime, a little different space and loading overheads, but the last
> one, that is enabled, is my favorite: only PLT relocations, that we'd
> likely get anyway, no full-address resolution, and as-short-as-possible
> calls, enough to get a relocation with a strong reference to pull the
> symbol in when linking, but as short as possible call sequences, because
> of the type cast.
>

And those expressions aren't ever optimized away as unused?


>
> As a bonus, I put in (in the last minute, after my test runs) something
> to keep even LTO happy: the asm statements to prevent depend from being
> optimized out in _M_start_thread.  In non-LTO, its impact should be
> virtually zero.
>
> How does this look?  (minus the #if 0/#elif 0/.../#else)
>

Looks good, thanks for going the extra mile to check all the alternatives,
and the futureproofing it for LTO.

OK for trunk.