[Bug other/98375] [meta bug] GCC 12 pending patches

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Andrew Pinski  ---
Stage1 is over so closing as fixed.

[Bug middle-end/98525] potential error in expand_call_inline error handling

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

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

--- Comment #1 from Andrew Pinski  ---
  successfully_inlined = expand_call_inline (bb, stmt, id, to_purge);
  maybe_remove_unused_call_args (cfun, stmt);
  /* This used to return true even though we do fail to inline in
 some cases.  See PR98525.  */
  goto egress;


Since it is not so obvious from reading the code and even reading this bug
report (but it was clear from the mailing list), the suggestion was to add an
assert that successfully_inlined was true and the failures in comment #0 happen
when the assert is added in the above code.

[Bug middle-end/98548] missing warning on strcmp with a nonstring member

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to fail||11.2.0
  Known to work||12.0

--- Comment #1 from Andrew Pinski  ---
Looks fixed on the trunk:
: In function 'f':
:11:15: warning: '__builtin_strcmp' argument 1 declared attribute
'nonstring' is smaller than the specified bound 8 [-Wstringop-overread]
   11 |   return 0 == __builtin_strcmp (a.a, a.b);   // warning (good)
  |   ^~~
:4:8: note: argument 'a' declared here
4 |   char a[4] __attribute__ ((nonstring));
  |^
: In function 'g':
:16:15: warning: '__builtin_strcmp' argument 1 declared attribute
'nonstring' is smaller than the specified bound 8 [-Wstringop-overread]
   16 |   return 0 == __builtin_strcmp (p->a, p->b);   // missing warning
  |   ^
:4:8: note: argument 'a' declared here
4 |   char a[4] __attribute__ ((nonstring));
  |^

[Bug tree-optimization/69289] Compiling without --profile-generate causes longer execution time (-O3)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work||11.2.0, 12.0
  Component|middle-end  |tree-optimization
  Known to fail||7.1.0, 8.1.0

--- Comment #6 from Andrew Pinski  ---
Looks to be fixed in GCC 11.2.0 and GCC 12+.
That is the memset is detected and transformed.

[Bug c++/89870] C++ suggest header for abort()

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Depends on||101052
 Status|NEW |RESOLVED
   Target Milestone|--- |12.0

--- Comment #4 from Andrew Pinski  ---
Since r12-1435-g93bfadf3a1db (PR101052):


: In function 'int main()':
:4:5: error: 'abort' was not declared in this scope
4 | abort();
  | ^
:1:1: note: 'abort' is defined in header ''; did you forget to
'#include '?
  +++ |+#include 
1 | 


So fixed.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101052
[Bug 101052] Suggest stdlib.h when exit(1) is called

[Bug c++/89055] wrong location with macros

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|wrong location with |wrong location with macros
   |predefined macros   |

--- Comment #2 from Andrew Pinski  ---
In this case it is just the macro in general, not really the predefined one
that makes a difference:
#define S_MAX (18446744073709551615UL)
char a[~0LU << 1];
char b0[S_MAX << 1];
char b[__SIZE_MAX__ << 1];

 CUT 
:2:13: error: size '18446744073709551614' of array 'a' exceeds maximum
object size '9223372036854775807'
2 | char a[~0LU << 1];
  |~^~~~
:3:15: error: size '18446744073709551614' of array 'b0' exceeds maximum
object size '9223372036854775807'
3 | char b0[S_MAX << 1];
  |   ^
:4:21: error: size '18446744073709551614' of array 'b' exceeds maximum
object size '9223372036854775807'
4 | char b[__SIZE_MAX__ << 1];
  | ^

[Bug c++/103659] Declared function template can be deleted later

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Dup of bug 90703.

The only reason I knew there was a dup is because I just saw it today when I
was going through the C++ bug reports. So I was not doing any magical memory
since it was only from today.

[Bug c++/90703] `=delete` accepted on a second declaration of the same function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||fchelnokov at gmail dot com

--- Comment #2 from Andrew Pinski  ---
*** Bug 103659 has been marked as a duplicate of this bug. ***

[Bug c++/103659] Declared function template can be deleted later

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 90703.

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

[Bug c++/103659] New: Declared function template can be deleted later

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 103659
   Summary: Declared function template can be deleted later
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This code
```
template
int foo(T);

template int foo(int);

template
int foo(T) = delete;
```
is currently accepted by GCC, but it must not by at least two reasons:
* explicit instantiation of undefined function;
* deletion of already declared function.

Demo: https://gcc.godbolt.org/z/EW8fvba5f

[Bug c++/87429] Strange overload resolution with decltype in template function

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=85493
 Blocks||54366
  Known to work||11.1.0
  Known to fail||10.3.0

--- Comment #2 from Andrew Pinski  ---
Seems fixed in GCC 11+.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54366
[Bug 54366] [meta-bug] decltype issues

[Bug c++/85493] decltype can use deleted constructor and deleted template function in template function

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||10.1.0, 10.3.0, 7.2.0
  Known to work||11.1.0, 12.0
   Keywords||needs-bisection
 Blocks||54366

--- Comment #3 from Andrew Pinski  ---
The testcase in comment #0 seems to be fixed in GCC 11+.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54366
[Bug 54366] [meta-bug] decltype issues

[Bug c++/86697] decltype for lambda capture gives wrong type

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2021-12-11

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

Re: [PR100843] store by mult pieces: punt on max_len < min_len

[Alexandre Oliva via Gcc-patches]

On Dec 10, 2021, Jeff Law  wrote:

> The patch is clearly safe.  My question is should we have caught this
> earlier in the call chain?

Callers will call try_store_by_multiple_pieces if set_storage_via_setmem
fails.  setmem doesn't necessarily need min and max len to do its job,
so if we were to modify callers, it would be just guarding the calls of
try_store_by_multiple_pieces with max_len >= min_len: 3 callers in 2
files, which didn't seem appealing to me.

-- 
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++/81202] Concept parsing error for default template arguments

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

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

--- Comment #2 from Andrew Pinski  ---
Full testcase:
#include 
#include 

template constexpr bool
IsPtrC=std::is_pointer_v&&(std::is_same_v
||std::is_same_v>);
template concept  IsPtrC2=IsPtrC;
template using TEST=int;
int main(int argc,char*argv[]){
  TEST> i;//OK
  TEST> j;//error: parse error in template argument list
  TEST> k;//OK
  TEST<(IsPtrC2)> l;//OK
}


With -std=c++20 the above code works (as expected) but with -std=c++17
-fconcepts it fails (with GCC 10+).

I will let a C++ maintainer to decide if it should work with -std=c++17
-fconcepts or not.

The error message is:
: In function 'int main(int, char**)':
:10:19: error: type/value mismatch at argument 1 in template parameter
list for 'template using TEST = int'
   10 |   TEST> j;//error: parse error in template argument list
  |   ^~
:10:19: note:   expected a constant of type 'bool', got 'auto [requires
IsPtrC2<, int>]'
Compiler returned: 1

[Bug c++/103534] [12 regression] Spurious -Wstringop-overflow warning with std::string concatencation

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:2e8067041d1d69da02bd7578f58abc11eb35a04b

commit r12-5906-g2e8067041d1d69da02bd7578f58abc11eb35a04b
Author: Jason Merrill 
Date:   Fri Dec 10 11:21:50 2021 -0500

libstdc++: check length in string append [PR103534]

In the testcase for 103534 we get a warning about append leading to memcpy
of a very large number of bytes overflowing the buffer.  This turns out to
be because we weren't calling _M_check_length for string append.  Rather
than do that directly, let's go through the public pointer append that
calls
it.

PR c++/103534

libstdc++-v3/ChangeLog:

* include/bits/basic_string.h (append (basic_string)): Call pointer
append instead of _M_append directly.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wstringop-overflow-8.C: New test.

[Bug c++/91622] Compiler internal error DJGPP GCC

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
No attachment provided in over 2 years so closing as invalid.

[Bug c++/67491] [meta-bug] concepts issues

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 68858, which changed state.

Bug 68858 Summary: Cannot use fold expression in requirements with two 
parameters packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68858

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug c++/68858] Cannot use fold expression in requirements with two parameters packs

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #3 from Andrew Pinski  ---
Fixed so closing.

[Bug c++/61726] Ambiguous overload resolution with inherited op()s

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||12944

--- Comment #3 from Andrew Pinski  ---
ICC and GCC rejects this code while clang and MSVC accept it.

If we change it to a normal function rather than an operator, then all 4
compilers reject it as ambiguous.  Are operators handled differently here for
namelookup?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944
[Bug 12944] [meta-bug] C++ name-lookup problems

[Bug c++/78722] noexcept and function pointers

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Andrew Pinski  ---
Fixed in GCC 7 by r7-4383-g51dc660315ef83d.

[Bug analyzer/101962] Analyzer NULL false positive with pointer manipulation

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from David Malcolm  ---
Backported to gcc 11 by the above commit.  I don't plan to backport to gcc 10;
marking this as resolved.

[Bug jit/103562] Jitted code produces incorrect result when returning 3-member struct from internal function

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-11 branch has been updated by David Malcolm
:

https://gcc.gnu.org/g:1250dcee74985eaeacae3b85e5ec78937225d322

commit r11-9375-g1250dcee74985eaeacae3b85e5ec78937225d322
Author: David Malcolm 
Date:   Fri Dec 10 09:28:48 2021 -0500

jit: set DECL_CONTEXT of RESULT_DECL [PR103562]

libgccjit was failing to set the DECL_CONTEXT of function RESULT_DECLs,
leading to them failing to be properly handled by the inlining machinery.
Fixed thusly.

gcc/jit/ChangeLog:
PR jit/103562
* jit-playback.c (gcc::jit::playback::context::new_function): Set
DECL_CONTEXT of the result_decl.

gcc/testsuite/ChangeLog:
PR jit/103562
* jit.dg/all-non-failing-tests.h: Add comment about...
* jit.dg/test-pr103562.c: New test.

Signed-off-by: David Malcolm 

[Bug analyzer/101962] Analyzer NULL false positive with pointer manipulation

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by David Malcolm
:

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

commit r11-9374-gde0656f98640a57cd9dfdb090264afaa06ba46cc
Author: David Malcolm 
Date:   Mon Aug 23 14:07:39 2021 -0400

analyzer: assume that POINTER_PLUS_EXPR of non-NULL is non-NULL [PR101962]

Backported from commit r12-3094-ge82e0f149b0aba660896ea9aa12c442c07a16d12,
dropping the expected "use of uninitialized value" warning from
pr101962.c

gcc/analyzer/ChangeLog:
PR analyzer/101962
* region-model.cc (region_model::eval_condition_without_cm):
Refactor comparison against zero, adding a check for
POINTER_PLUS_EXPR of non-NULL.

gcc/testsuite/ChangeLog:
PR analyzer/101962
* gcc.dg/analyzer/data-model-23.c: New test.
* gcc.dg/analyzer/pr101962.c: New test.

Signed-off-by: David Malcolm 

[Bug middle-end/103614] Modulo equality optimization

[getchar_gnu at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from getchar_gnu at hotmail dot com ---
Not sure if related, but something like x%13==8 && x>17 && x<146 can also
reduce some code

[Bug c++/96207] GCC accepts "delete" function definition inside a class member function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-12-11

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

[Bug c++/86430] ambiguous overload?

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to fail||10.1.0, 10.3.0
  Known to work||11.1.0, 12.0

--- Comment #2 from Andrew Pinski  ---
Seems fixed in GCC 11+.

[Bug c++/90529] suggest struct or class

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2019-05-20 00:00:00 |2021-12-10
   Severity|normal  |enhancement

[Bug c++/70077] noexcept, inheriting constructors and the invalid use of an incomplete type that is actually complete

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #6 from Andrew Pinski  ---
Seems to be fixed for GCC 10.

[Bug c++/82171] Cant use std::declval in concept testing map operator[]

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.1.0
  Known to work||11.2.0, 12.0
   Keywords||ice-on-valid-code

--- Comment #5 from Andrew Pinski  ---
Starting with GCC 10.1.0, GCC would ICE also.  The ICE was resolved in GCC
11.2.0 and on the trunk and GCC starts to accept the code at that point.

[Bug c++/89367] Constexpr expression is not constexpr in template, but is constexpr in non-template.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Very similar to PR 94716.

The original code in comment #0 might be solved by
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586553.html (when it
gets approved/applied).

(In reply to Frank Secilia from comment #4)
> Created attachment 45743 [details]
> alternative repro case using pointers to method

There is another bug recording pointer to method function comparisons too.

[Bug c++/97077] Missed loop unrolling with range for over initializer list

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2020-09-17 00:00:00 |2021-12-10

--- Comment #3 from Andrew Pinski  ---
Maybe we need to realize the induction variable __for_begin is constant memory
so the read from it will be optimized away. That might help.

[Bug c++/87680] Small program produces 160 meg .o file

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Also very similar to PR 92385.

[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread

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

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

--- Comment #13 from Martin Sebor  ---
The warning for the test case in comment #12 isn't directly related to ranges:
it's issued simply because the invalid statement is in the IL and not
eliminated by DCE (the secret functions don't let it).  Similar warnings have
been issued in equivalent situations for constants propagated through inlining.
 Here's one for -Wnonnull (issued since GCC 7):

char *sink;

__attribute__ ((noinline, noipa)) int
null_safe_strlen (const char *p) { return p ?__builtin_strlen (p) : 0; }

static inline void copy (const char *p)
{
  int N = null_safe_strlen (p);
  if (N) /* disabling this branch prevents the warning */
__builtin_memcpy (sink, p, N);
  else
*sink = 0;
}

void f()
{
  copy (0); // bogus warning
}

In function ‘copy’,
inlined from ‘f’ at z.c:17:3:
z.c:10:5: warning: argument 2 null where non-null expected [-Wnonnull]
   10 | __builtin_memcpy (sink, p, N);
  | ^
z.c:10:5: note: in a call to built-in function ‘__builtin_memcpy’

All GCC warnings trigger on invalid statements in the IL, regardless of whether
the statements are in reality reachable.  This includes all warnings that
consider data flow like -Wnonnull, -Warray-bounds, and -Wformat-overflow among
many others.  Ranges just let them find more invalid statements than constants
alone would.  This is also the most basic reason why the -Wstringop- warnings
are issued for the test case in comment #0 or in or PR 103332.

Two changes are behind the spate of recent bug reports about these warnings for
std::string: 1) in GCC 11 we enabled a subset of warnings for code inlined from
system headers, and 2) in GCC 12 thanks to Ranger the range info has become
more accurate and tighter (larger lower bounds and smaller upper bounds).

Before Jonathan suppressed the warnings in r12-5874 in libstdc++, Andrew
MacLeod suggested temporarily (for GCC 12) disabling the context-sensitive
Ranger info and going back to global ranges, until we have a better way of
dealing with the increased accuracy.  That would reduce the number of false
positives but it would also correspondingly increase false negatives, and so
defeat one of the main reasons for Ranger: better quality warnings.  It might
still be a compromise to consider if the problem turns out to be sufficiently
severe and if we can think of a way of to handle the ranges better in the
future.  But with the libstdc++ suppression I'm not convinced the problem is
severe enough anymore.  And I also can't think of a solution that would let us
re-enable Ranger for warnings in the future.  Nothing I've tried so far has
showed much promise, and neither seems anything anyone has suggested.

Independently, I have been thinking about adding -Wmaybe- forms of some of
these warnings analogous to -Wmaybe-uninitialized (or corresponding levels), to
diagnose conditional problems as in:

  char a[4], b[8];

  void f (int i)
  {
__builtin_memset (i ? a : b, 0, 7);   // okay for b, overflow for a: thus
"may overflow a"
  }

but I have not been considering disabling the existing warnings (or removing it
from -Wall) and issuing them only under the new option or some new level.  That
would in my mind be a drastic step back.

[Bug inline-asm/98096] Inconsistent operand numbering for asm goto with in-out operands

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Nick Desaulniers from comment #5)
> Was it ever consider that the behavior should be changed, rather than
> documented?

Seems like changing an already documented and released feature seems wrong. Gcc
11 was released back in April. Clang never documented this feature as far as I
can tell. Plus it would be very inconsistent with the way the inout feature was
handled without asm goto. That is all input constraints are grouped together,
having the asm goto label in between the inputs seems wrong.

[Bug inline-asm/98096] Inconsistent operand numbering for asm goto with in-out operands

[ndesaulniers at google dot com via Gcc-bugs]

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

--- Comment #5 from Nick Desaulniers  ---
While the changes to gcc/stmt.c and the second asm goto statement in
gcc/testsuite/gcc.c-torture/compile/pr98096.c in
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=72d78655a91bb2f89ac4432cfd6374380d6f9987
LGTM (they fix an actual bug with symbolic references), the changes to
gcc/doc/extend.texi and the first asm goto statement in
gcc/testsuite/gcc.c-torture/compile/pr98096.c seemed to have conflated the
label bug with documenting curious behavior.

Was it ever consider that the behavior should be changed, rather than
documented?

[PATCH] configure: Account CXXFLAGS in gcc-plugin.m4.

[Iain Sandoe via Gcc-patches]

While doing tests of the PCH changes, I noticed that all the
plugin tests were being omitted from m32 Darwin under some
permutations of flags.  It turned out to be a broken config
test - it was not removing -mdynamic-no-pic properly.

We now use a C++ compiler so that we need to process CXXFLAGS
as well as CFLAGS in the gcc-plugin config fragment.

Tested on i686, x86_64-darwin, x86_64, powerpc64le-linux
OK for master?
backports?

Signed-off-by: Iain Sandoe 

config/ChangeLog:

* gcc-plugin.m4: Save and process CXXFLAGS.

gcc/ChangeLog:

* configure: Regenerate.

libcc1/ChangeLog:

* configure: Regenerate.
---
 config/gcc-plugin.m4 | 5 +
 gcc/configure| 5 +
 libcc1/configure | 5 +
 3 files changed, 15 insertions(+)

diff --git a/config/gcc-plugin.m4 b/config/gcc-plugin.m4
index 8f278719118..7ee342fe5fe 100644
--- a/config/gcc-plugin.m4
+++ b/config/gcc-plugin.m4
@@ -91,14 +91,18 @@ AC_DEFUN([GCC_ENABLE_PLUGINS],
  # Check that we can build shared objects with -fPIC -shared
  saved_LDFLAGS="$LDFLAGS"
  saved_CFLAGS="$CFLAGS"
+ saved_CXXFLAGS="$CXXFLAGS"
  case "${host}" in
*-*-darwin*)
 CFLAGS=`echo $CFLAGS | sed s/-mdynamic-no-pic//g`
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS=`echo $CXXFLAGS | sed s/-mdynamic-no-pic//g`
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -shared -undefined dynamic_lookup"
;;
*)
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -fPIC -shared"
;;
  esac
@@ -113,6 +117,7 @@ AC_DEFUN([GCC_ENABLE_PLUGINS],
  fi
  LDFLAGS="$saved_LDFLAGS"
  CFLAGS="$saved_CFLAGS"
+ CXXFLAGS="$saved_CXXFLAGS"
 
  # If plugin support had been requested but not available, fail.
  if test x"$enable_plugin" = x"no" ; then
diff --git a/gcc/configure b/gcc/configure
index de20e5d2629..5470987b62f 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -32038,14 +32038,18 @@ fi
  # Check that we can build shared objects with -fPIC -shared
  saved_LDFLAGS="$LDFLAGS"
  saved_CFLAGS="$CFLAGS"
+ saved_CXXFLAGS="$CXXFLAGS"
  case "${host}" in
*-*-darwin*)
 CFLAGS=`echo $CFLAGS | sed s/-mdynamic-no-pic//g`
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS=`echo $CXXFLAGS | sed s/-mdynamic-no-pic//g`
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -shared -undefined dynamic_lookup"
;;
*)
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -fPIC -shared"
;;
  esac
@@ -32077,6 +32081,7 @@ rm -f core conftest.err conftest.$ac_objext \
  fi
  LDFLAGS="$saved_LDFLAGS"
  CFLAGS="$saved_CFLAGS"
+ CXXFLAGS="$saved_CXXFLAGS"
 
  # If plugin support had been requested but not available, fail.
  if test x"$enable_plugin" = x"no" ; then
diff --git a/libcc1/configure b/libcc1/configure
index b198b0b9074..01cfb2806da 100755
--- a/libcc1/configure
+++ b/libcc1/configure
@@ -15141,14 +15141,18 @@ fi
  # Check that we can build shared objects with -fPIC -shared
  saved_LDFLAGS="$LDFLAGS"
  saved_CFLAGS="$CFLAGS"
+ saved_CXXFLAGS="$CXXFLAGS"
  case "${host}" in
*-*-darwin*)
 CFLAGS=`echo $CFLAGS | sed s/-mdynamic-no-pic//g`
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS=`echo $CXXFLAGS | sed s/-mdynamic-no-pic//g`
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -shared -undefined dynamic_lookup"
;;
*)
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -fPIC -shared"
;;
  esac
@@ -15180,6 +15184,7 @@ rm -f core conftest.err conftest.$ac_objext \
  fi
  LDFLAGS="$saved_LDFLAGS"
  CFLAGS="$saved_CFLAGS"
+ CXXFLAGS="$saved_CXXFLAGS"
 
  # If plugin support had been requested but not available, fail.
  if test x"$enable_plugin" = x"no" ; then
-- 
2.24.3 (Apple Git-128)

[pushed] libgcc, Darwin: Update darwin10 unwinder shim dependencies.

[Iain Sandoe via Gcc-patches]

We include libgcc_tm.h to provide a prototype for this shim
so add that to the make dependencies.

tested on x86_64-darwin, pushed to master, thanks
Iain

Signed-off-by: Iain Sandoe 

libgcc/ChangeLog:

* config/t-darwin: Add libgcc_tm.h to the dependencies
for darwin10-unwind-find-enc-func.
---
 libgcc/config/t-darwin | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/config/t-darwin b/libgcc/config/t-darwin
index a855ecfd526..299d26c2c96 100644
--- a/libgcc/config/t-darwin
+++ b/libgcc/config/t-darwin
@@ -25,7 +25,7 @@ libemutls_w.a: emutls_s.o
$(RANLIB_FOR_TARGET) $@
 
 # Patch to __Unwind_Find_Enclosing_Function for Darwin10.
-d10-uwfef.o: $(srcdir)/config/darwin10-unwind-find-enc-func.c
+d10-uwfef.o: $(srcdir)/config/darwin10-unwind-find-enc-func.c libgcc_tm.h
$(crt_compile) -mmacosx-version-min=10.6 -c $<
 
 # Using this crt as a library means that it will not be added to an exe
-- 
2.24.3 (Apple Git-128)

[Bug jit/103562] Jitted code produces incorrect result when returning 3-member struct from internal function

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

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

--- Comment #7 from David Malcolm  ---
Should be fixed by the above commit on trunk for gcc 12.

Probably should backport this; keeping this open until that's done.

[committed] jit: set DECL_CONTEXT of RESULT_DECL [PR103562]

[David Malcolm via Gcc-patches]

libgccjit was failing to set the DECL_CONTEXT of function RESULT_DECLs,
leading to them failing to be properly handled by the inlining machinery.
Fixed thusly.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-5903-ga2f4b4b76cdd0a4150e82e69fae4a70c54b523d2.

gcc/jit/ChangeLog:
PR jit/103562
* jit-playback.c (gcc::jit::playback::context::new_function): Set
DECL_CONTEXT of the result_decl.

gcc/testsuite/ChangeLog:
PR jit/103562
* jit.dg/all-non-failing-tests.h: Add comment about...
* jit.dg/test-pr103562.c: New test.

Signed-off-by: David Malcolm 
---
 gcc/jit/jit-playback.c   |  1 +
 gcc/testsuite/jit.dg/all-non-failing-tests.h |  3 +
 gcc/testsuite/jit.dg/test-pr103562.c | 62 
 3 files changed, 66 insertions(+)
 create mode 100644 gcc/testsuite/jit.dg/test-pr103562.c

diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index b9c05864900..a9f52cbd0ef 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -473,6 +473,7 @@ new_function (location *loc,
   DECL_ARTIFICIAL (resdecl) = 1;
   DECL_IGNORED_P (resdecl) = 1;
   DECL_RESULT (fndecl) = resdecl;
+  DECL_CONTEXT (resdecl) = fndecl;
 
   if (builtin_id)
 {
diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h 
b/gcc/testsuite/jit.dg/all-non-failing-tests.h
index a7fddf96db8..3663f726a99 100644
--- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
+++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
@@ -230,6 +230,9 @@
 #undef create_code
 #undef verify_code
 
+/* test-pr103562.c: We don't add this one, since it touches
+   the optimization level of the context as a whole.  */
+
 /* test-pr66700-observing-write-through-ptr.c */
 #define create_code create_code_pr66700_observing_write_through_ptr
 #define verify_code verify_code_pr66700_observing_write_through_ptr
diff --git a/gcc/testsuite/jit.dg/test-pr103562.c 
b/gcc/testsuite/jit.dg/test-pr103562.c
new file mode 100644
index 000..de361b96bd1
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-pr103562.c
@@ -0,0 +1,62 @@
+#include 
+#include "harness.h"
+
+struct my_struct { long a; long b; long c; };
+
+void create_code (gcc_jit_context *ctxt, void *user_data)
+{
+   /* Create the equivalent of:
+   struct my_struct { long a; long b; long c; };
+   static struct my_struct deref(struct my_struct *ptr) { return 
*ptr; } 
+   long get_a(struct my_struct *s) { return deref(s).a; }
+  and compile it at -O1.  */
+   gcc_jit_context_set_int_option(ctxt, 
GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL, 1);
+
+   gcc_jit_type *long_type = gcc_jit_context_get_type(ctxt, 
GCC_JIT_TYPE_LONG);
+   gcc_jit_field* fields[3] = {
+   gcc_jit_context_new_field(ctxt, NULL, long_type, "a"),
+   gcc_jit_context_new_field(ctxt, NULL, long_type, "b"),
+   gcc_jit_context_new_field(ctxt, NULL, long_type, "c"),
+   };
+   gcc_jit_struct *my_struct =
+   gcc_jit_context_new_struct_type(ctxt, NULL, "my_struct", 3, 
fields);
+   gcc_jit_type *my_struct_type = gcc_jit_struct_as_type(my_struct);
+   gcc_jit_type *my_struct_ptr_type = 
gcc_jit_type_get_pointer(my_struct_type);
+
+   /* struct my_struct deref(struct my_struct *ptr) { return *ptr; } */
+   gcc_jit_param *param_deref =
+   gcc_jit_context_new_param(ctxt, NULL, my_struct_ptr_type, 
"ptr");
+   gcc_jit_function *func_deref = gcc_jit_context_new_function(
+   ctxt, NULL, GCC_JIT_FUNCTION_INTERNAL,
+   my_struct_type, "deref",
+   1, _deref,
+   0);
+   gcc_jit_block *blockDeref = gcc_jit_function_new_block(func_deref, 
NULL);
+   gcc_jit_block_end_with_return(
+   blockDeref, NULL,
+   
gcc_jit_lvalue_as_rvalue(gcc_jit_rvalue_dereference(gcc_jit_param_as_rvalue(param_deref),
 NULL)));
+
+   /* long get_a(struct my_struct *s) { return deref(s).a; } */
+   gcc_jit_param *param_get_a = gcc_jit_context_new_param(ctxt, NULL, 
my_struct_ptr_type, "s");
+   gcc_jit_function *func_get_a = gcc_jit_context_new_function(
+   ctxt, NULL, GCC_JIT_FUNCTION_EXPORTED,
+   long_type, "get_a",
+   1, _get_a,
+   0);
+   gcc_jit_block *block_get_a = gcc_jit_function_new_block(func_get_a, 
NULL);
+   gcc_jit_rvalue *argsForDeref[1] = 
{gcc_jit_param_as_rvalue(param_get_a)};
+   gcc_jit_rvalue *callDeref = gcc_jit_context_new_call(ctxt, NULL, 
func_deref, 1, argsForDeref);
+   gcc_jit_block_end_with_return(
+   block_get_a, NULL,
+   gcc_jit_rvalue_access_field(callDeref, NULL, fields[0]));
+}
+
+void
+verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
+{
+  typedef long(*fn_type) (struct my_struct*);
+  fn_type get_a = (fn_type) gcc_jit_result_get_code(result, "get_a");
+
+  struct my_struct s = {1, 2, 3};
+  

[Bug jit/103562] Jitted code produces incorrect result when returning 3-member struct from internal function

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

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

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

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

commit r12-5903-ga2f4b4b76cdd0a4150e82e69fae4a70c54b523d2
Author: David Malcolm 
Date:   Fri Dec 10 09:28:48 2021 -0500

jit: set DECL_CONTEXT of RESULT_DECL [PR103562]

libgccjit was failing to set the DECL_CONTEXT of function RESULT_DECLs,
leading to them failing to be properly handled by the inlining machinery.
Fixed thusly.

gcc/jit/ChangeLog:
PR jit/103562
* jit-playback.c (gcc::jit::playback::context::new_function): Set
DECL_CONTEXT of the result_decl.

gcc/testsuite/ChangeLog:
PR jit/103562
* jit.dg/all-non-failing-tests.h: Add comment about...
* jit.dg/test-pr103562.c: New test.

Signed-off-by: David Malcolm 

testsuite: Be more informative for ICEs

[Thomas Schwinge]

Hi!

OK to push the attached "testsuite: Be more informative for ICEs"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From 5ffc2cfc9c6ec6ed0937311377118efd648f0297 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 10 Dec 2021 19:08:26 +0100
Subject: [PATCH] testsuite: Be more informative for ICEs

For example, for the two (FAIL, XFAIL)
'gcc/testsuite/lib/gcc-dg.exp:gcc-dg-test-1' cases:

-FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (internal compiler error)
+FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (internal compiler error: tree check: expected var_decl or function_decl or field_decl or type_decl or concept_decl or template_decl, have namespace_decl in get_merge_kind, at cp/module.cc:10072)

-FAIL: gfortran.dg/gomp/clauses-1.f90   -O  (internal compiler error)
+FAIL: gfortran.dg/gomp/clauses-1.f90   -O  (internal compiler error: Segmentation fault)

-XFAIL: c-c++-common/goacc/kernels-decompose-ice-1.c (internal compiler error)
+XFAIL: c-c++-common/goacc/kernels-decompose-ice-1.c (internal compiler error: in lower_omp_target, at omp-low.c:13147)

-XFAIL: g++.dg/cpp1z/constexpr-lambda26.C  -std=c++17 (internal compiler error)
+XFAIL: g++.dg/cpp1z/constexpr-lambda26.C  -std=c++17 (internal compiler error: in cxx_eval_constant_expression, at cp/constexpr.c:6954)

That allows for more easily spotting when during development you're trading one
ICE for another.

	gcc/testsuite/
	* lib/fortran-torture.exp (fortran-torture-compile)
	(fortran-torture-execute): Be more informative for ICEs.
	* lib/gcc-defs.exp (${tool}_check_compile): Likewise.
	* lib/gcc-dg.exp (gcc-dg-test-1): Likewise.
	* lib/go-torture.exp (go-torture-compile, go-torture-execute):
	Likewise.
---
 gcc/testsuite/lib/fortran-torture.exp | 8 
 gcc/testsuite/lib/gcc-defs.exp| 4 ++--
 gcc/testsuite/lib/gcc-dg.exp  | 6 +++---
 gcc/testsuite/lib/go-torture.exp  | 8 
 4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/gcc/testsuite/lib/fortran-torture.exp b/gcc/testsuite/lib/fortran-torture.exp
index d6759aa0b4b..11d73d9f1f7 100644
--- a/gcc/testsuite/lib/fortran-torture.exp
+++ b/gcc/testsuite/lib/fortran-torture.exp
@@ -138,8 +138,8 @@ proc fortran-torture-compile { src option } {
 	return
 }
 
-if [string match "*internal compiler error*" $comp_output] then {
-	gfortran_fail $testcase "$option (internal compiler error)"
+if [regexp -line -- "internal compiler error.*" $comp_output ice] then {
+	gfortran_fail $testcase "$option ($ice)"
 	catch { remote_file build delete $output }
 	return
 }
@@ -263,8 +263,8 @@ proc fortran-torture-execute { src } {
 	continue
 	}
 
-	if [string match "*internal compiler error*" $comp_output] then {
-	gfortran_fail $testcase "$option (internal compiler error)"
+	if [regexp -line -- "internal compiler error.*" $comp_output ice] then {
+	gfortran_fail $testcase "$option ($ice)"
 	catch { remote_file build delete $executable }
 	continue
 	}
diff --git a/gcc/testsuite/lib/gcc-defs.exp b/gcc/testsuite/lib/gcc-defs.exp
index d17308d0f86..66df4e1c6aa 100644
--- a/gcc/testsuite/lib/gcc-defs.exp
+++ b/gcc/testsuite/lib/gcc-defs.exp
@@ -38,8 +38,8 @@ proc ${tool}_check_compile {testcase option objname gcc_output} {
 	return 0
 }
 
-if [string match "*internal compiler error*" $gcc_output] then {
-	${tool}_fail $testcase "$option (internal compiler error)"
+if [regexp -line -- "internal compiler error.*" $gcc_output ice] then {
+	${tool}_fail $testcase "$option ($ice)"
 	return 0
 }
 
diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 78a6c3651ef..464059608b8 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -315,13 +315,13 @@ proc gcc-dg-test-1 { target_compile prog do_what extra_tool_flags } {
 # to avoid a second failure for excess errors.
 # "Error reporting routines re-entered" ICE says "Internal" rather than
 # "internal", so match that too.
-if [string match {*[Ii]nternal compiler error*} $comp_output] {
+if [regexp -line -- {[Ii]nternal compiler error.*} $comp_output ice] {
 	upvar 2 name name
 	if { $expect_ice == 0 } {
-	  fail "$name (internal compiler error)"
+	  fail "$name ($ice)"
 	} else {
 	  # We expected an ICE and we got it.
-	  xfail "$name (internal compiler error)"
+	  xfail "$name ($ice)"
 	  # Prune the ICE from the output.
 	  set comp_output [prune_ices $comp_output]
 	}
diff --git a/gcc/testsuite/lib/go-torture.exp b/gcc/testsuite/lib/go-torture.exp
index 28247a1902d..adeae36f916 100644
--- a/gcc/testsuite/lib/go-torture.exp
+++ b/gcc/testsuite/lib/go-torture.exp
@@ -88,8 +88,8 @@ proc go-torture-compile { src option } {
 	return
 

gcc-10-20211210 is now available

[GCC Administrator via Gcc]

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

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision 45cbfabe01878c3efd8b24f3fef06baf48983308

You'll find:

 gcc-10-20211210.tar.xz   Complete GCC

  SHA256=4a5de40362d73a0022d897f4260dac929568e5c64ad6f6138dec016b09fa821c
  SHA1=c16f4e5be3fb242d0d60c4a169817f15f7379e57

Diffs from 10-20211203 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
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: [PR100518] store by mult pieces: keep addr in Pmode

[Jeff Law via Gcc-patches]

On 12/9/2021 3:18 PM, Alexandre Oliva via Gcc-patches wrote:

The conversion of a MEM address to ptr_mode in
try_store_by_multiple_pieces was misguided: copy_addr_to_reg expects
Pmode for addresses.

Regstrapped on x86_64-linux-gnu, testcase verified with a cross to
aarch64.  Ok to install?


for  gcc/ChangeLog

PR target/100518
* builtins.c (try_store_by_multiple_pieces): Drop address
conversion to ptr_mode.

for  gcc/testsuite/ChangeLog

PR target/100518
* gcc.target/aarch64/pr100518.c: New.

OK
jeff

Re: [PR100843] store by mult pieces: punt on max_len < min_len

[Jeff Law via Gcc-patches]

On 12/9/2021 3:16 PM, Alexandre Oliva via Gcc-patches wrote:

The testcase confuses the code that detects min and max len for the
memset, so max_len ends up less than min_len.  That shouldn't be
possible, but the testcase requires us to handle this case.

The store-by-mult-pieces algorithm actually relies on min and max
lengths, so if we find them to be inconsistent, the best we can do is
punting.

Regstrapped on x86_64-linux-gnu.  Ok to install?


for  gcc/ChangeLog

PR middle-end/100843
* builtins.c (try_store_by_multiple_pieces): Fail if min_len
is greater than max_len.

for  gcc/testsuite/ChangeLog

PR middle-end/100843
* gcc.dg/pr100843.c: New.
The patch is clearly safe.  My question is should we have caught this 
earlier in the call chain?  If so, I'd prefer to fix it there and leave 
the gcc_unreachable in place to catch other bogus cases that may get 
into try_store_by_multiple_pieces.



Jeff

[PATCH] c++: Allow constexpr decltype(auto) [PR102229]

[Marek Polacek via Gcc-patches]

My r11-2202 was trying to enforce [dcl.type.auto.deduct]/4, which says
"If the placeholder-type-specifier is of the form type-constraint[opt]
decltype(auto), T shall be the placeholder alone."  But this made us
reject 'constexpr decltype(auto)', which, after clarification from CWG,
should be valid.  [dcl.type.auto.deduct]/4 is supposed to be a syntactic
constraint, not semantic, so it's OK that the constexpr marks the object
as const.

As a consequence, checking TYPE_QUALS in do_auto_deduction is too late,
and we have a FIXME there anyway.  So in this patch I'm attempting to
detect 'const decltype(auto)' earlier.  If I'm going to use TYPE_QUALS,
it needs to happen before we mark the object as const due to constexpr,
that is, before grokdeclarator's

  /* A `constexpr' specifier used in an object declaration declares
 the object as `const'.  */
  if (constexpr_p && innermost_code != cdk_function)
...

Constrained decltype(auto) was a little problem, hence the TYPENAME
check.  But in a typename context you can't use decltype(auto) anyway,
I think.

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

PR c++/102229

gcc/cp/ChangeLog:

* decl.c (check_decltype_auto): New.
(grokdeclarator): Call it.
* pt.c (do_auto_deduction): Don't check decltype(auto) here.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/decltype-auto5.C: New test.
---
 gcc/cp/decl.c   | 58 ++---
 gcc/cp/pt.c | 13 -
 gcc/testsuite/g++.dg/cpp1y/decltype-auto5.C | 35 +
 3 files changed, 74 insertions(+), 32 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/decltype-auto5.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 56f80775ca0..196eac287eb 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -11354,6 +11354,33 @@ name_unnamed_type (tree type, tree decl)
   gcc_assert (!TYPE_UNNAMED_P (type));
 }
 
+/* Check that decltype(auto) was well-formed: only plain decltype(auto)
+   is allowed.  TYPE might contain a decltype(auto).  Returns true if
+   there was a problem, false otherwise.  */
+
+static bool
+check_decltype_auto (location_t loc, tree type)
+{
+  if (tree a = type_uses_auto (type))
+{
+  if (AUTO_IS_DECLTYPE (a))
+   {
+ if (a != type)
+   {
+ error_at (loc, "%qT as type rather than plain "
+   "%", type);
+ return true;
+   }
+ else if (TYPE_QUALS (type) != TYPE_UNQUALIFIED)
+   {
+ error_at (loc, "% cannot be cv-qualified");
+ return true;
+   }
+   }
+}
+  return false;
+}
+
 /* Given declspecs and a declarator (abstract or otherwise), determine
the name and type of the object declared and construct a DECL node
for it.
@@ -12702,25 +12729,9 @@ grokdeclarator (const cp_declarator *declarator,
  "allowed");
return error_mark_node;
  }
-   /* Only plain decltype(auto) is allowed.  */
-   if (tree a = type_uses_auto (type))
- {
-   if (AUTO_IS_DECLTYPE (a))
- {
-   if (a != type)
- {
-   error_at (typespec_loc, "%qT as type rather than "
- "plain %", type);
-   return error_mark_node;
- }
-   else if (TYPE_QUALS (type) != TYPE_UNQUALIFIED)
- {
-   error_at (typespec_loc, "% cannot be "
- "cv-qualified");
-   return error_mark_node;
- }
- }
- }
+
+   if (check_decltype_auto (typespec_loc, type))
+ return error_mark_node;
 
if (ctype == NULL_TREE
&& decl_context == FIELD
@@ -13080,6 +13091,15 @@ grokdeclarator (const cp_declarator *declarator,
 
   id_loc = declarator ? declarator->id_loc : input_location;
 
+  if (innermost_code != cdk_function
+/* Don't check this if it can be the artifical decltype(auto)
+   we created when building a constraint in a compound-requirement:
+   that the type-constraint is plain is going to be checked in
+   cp_parser_compound_requirement.  */
+  && decl_context != TYPENAME
+  && check_decltype_auto (id_loc, type))
+return error_mark_node;
+
   /* A `constexpr' specifier used in an object declaration declares
  the object as `const'.  */
   if (constexpr_p && innermost_code != cdk_function)
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 9834baf34db..6d5da17b9d0 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -29912,19 +29912,6 @@ do_auto_deduction (tree type, tree init, tree 
auto_node,
return error_mark_node;
   targs = make_tree_vec (1);
   TREE_VEC_ELT (targs, 0) = deduced;
-  /* FIXME: These errors ought to be diagnosed at 

[Bug c++/79493] Bad diagnostic when referring to inner type that does not exist

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work||12.0

--- Comment #2 from Andrew Pinski  ---
This seems to be fixed on the trunk:
:3:10: error: 'A::nonexistent' has not been declared
3 |   void f(A::nonexistent param);
  |  ^
:4:11: error: 'A::nonexistent' has not been declared
4 |   void* g(A::nonexistent param);
  |   ^

[Bug c++/88493] Inconsistent error messages for unknown types

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
   Last reconfirmed||2021-12-10

--- Comment #1 from Andrew Pinski  ---
Confirmed, it looks like constructors don't get the same treatment as normal
method functions when it comes to undefined types.

[Bug c++/88118] GCC keeps unnecessary calls to new

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> Fixed in GCC 10 by r10-2105-gcb50701ec2c7a (I found a slight missed
> optimization but I will file that as a seperate issue).

The slight missed optimization is due to main being marked as called only once
so it is not really a missed one so I am not going to file it.

[Bug c++/88118] GCC keeps unnecessary calls to new

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
  Known to fail||8.1.0, 9.1.0
   Target Milestone|--- |10.0

--- Comment #7 from Andrew Pinski  ---
Fixed in GCC 10 by r10-2105-gcb50701ec2c7a (I found a slight missed
optimization but I will file that as a seperate issue).

[Bug tree-optimization/102958] std::u8string suboptimal compared to std::string, triggers warnings

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

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

--- Comment #5 from Jason Merrill  ---
Let's focus on the missed-optimization issues in this PR, and address the
broader diagnostic issues in PR 103483.

[Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102958

--- Comment #12 from Jason Merrill  ---
(In reply to Martin Sebor from comment #3)
> GCC 11 doesn't warn because it's unable to determine the range of the last
> memcpy() argument.  Thanks to the Ranger improvements GCC 12 is able to do
> better.  In some cases this should improve the S/N ratio of the middle end
> diagnostics that depend on ranges.  Unfortunately, in others like this one
> where other optimizations are disabled it can make things worse.

It seems to me that if we don't warn when we have no information about the
range of the argument, we also shouldn't warn when we have only path-dependent
information about the range of the argument.

The testcase in comment #0 is definitely dubious for using an unbounded int d
to index into a bounded array, so let's consider a more reasonable C testcase
derived from PR102958 for which there is no missed-optimization issue.

char *sink;

/* Definitions unavailable to optimization.  */
int secret_strlen (const char *p);
void secret_memcpy (char *, const char *, int);

inline void copy(const char *p)
{
  int L = secret_strlen (p);  
  if (L < 16) /* disabling this branch prevents the warning */
secret_memcpy (sink, p, L);
  else
__builtin_memcpy (sink, p, L);
}

void f()
{
  copy ("12"); // bogus warning
}

At the __builtin_memcpy we have a constant string "12" and an unknown length L,
and we try to copy L bytes of the constant string into a buffer.  We do this in
different ways depending on whether L is less than 16; on the latter path we
__builtin_memcpy L bytes from the constant string into the buffer.

And so -Wstringop-overread warns that we're reading 16 or more bytes from a
3-byte string.

But we still have no basis for concluding that L is actually >= 16, we don't
know its value at all.  That this path is only taken for L >= 16 doesn't tell
us whether it's actually possible that L >= 16; we can't assume that just
because we don't know the value of len, it could therefore have any value, and
so all branches are reachable for a specific string argument.

We're able to propagate one constant value, and warning because an unknown
value might be incompatible with the known value.  And with the recent changes
we're able to do more of this asymmetric constant propagation.

Perhaps it would be useful to have an optional mode for these (and other)
warnings that does assume that all branches are reachable, but it can't be the
default. -Wmaybe-stringop-overread?  -Wstringop-overread=maybe?

My testcase above has given a false positive since GCC 8.

I'm nervous about people adding __builtin_unreachables to suppress these
warnings; forced assumptions can be big foot-guns.

[Bug c++/88118] GCC keeps unnecessary calls to new

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   See Also||https://bugs.llvm.org/show_
   ||bug.cgi?id=39731

[Bug c++/38172] warn_unused_result does not work with structs not containing a copy constructor

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

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

--- Comment #16 from Andrew Pinski  ---
(In reply to Martin Liška from comment #15)
> Can the bug be marked as resolved?

Not exactly with an empty struct we warn twice.
That is take:
struct MyClass{};
typedef struct MyClass MyClass;
MyClass Bar2( void ) __attribute__((warn_unused_result));
void Foo( void )
{
Bar2(); // warns twice
}


But the following only warns once:
struct MyClass{int t;};
typedef struct MyClass MyClass;
MyClass Bar2( void ) __attribute__((warn_unused_result));
void Foo( void )
{
Bar2();
}



The warning twice started with GCC 7.

[Bug fortran/103606] [9/10/11/12 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13297 since r9-3324-g2b03b800d866d345

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2021-December/057155.html

[PATCH] PR fortran/103606 - [9/10/11/12 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13297

[Harald Anlauf via Gcc-patches]

Dear all,

when accessing CLASS components we need to ensure that the
corresponding class container has already been built.
Invalid code, e.g. the testcase in PR103606, may otherwise
generate segfaults due to invalid reads.

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

Thanks,
Harald

From 6e41e4391a54337bd32560be2b72e11ceba37b3a Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Fri, 10 Dec 2021 22:41:24 +0100
Subject: [PATCH] Fortran: fix checking of elemental functions of type CLASS

gcc/fortran/ChangeLog:

	PR fortran/103606
	* resolve.c (resolve_fl_procedure): Do not access CLASS components
	before class container has been built.

gcc/testsuite/ChangeLog:

	PR fortran/103606
	* gfortran.dg/pr103606.f90: New test.
---
 gcc/fortran/resolve.c  |  3 ++-
 gcc/testsuite/gfortran.dg/pr103606.f90 | 12 
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr103606.f90

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 0ed31970f8b..bff1b35446f 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -13294,7 +13294,8 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)

   /* An elemental function is required to return a scalar 12.7.1  */
   if (sym->attr.elemental && sym->attr.function
-  && (sym->as || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->as)))
+  && (sym->as || (sym->ts.type == BT_CLASS && sym->attr.class_ok
+		  && CLASS_DATA (sym)->as)))
 {
   gfc_error ("ELEMENTAL function %qs at %L must have a scalar "
 		 "result", sym->name, >declared_at);
diff --git a/gcc/testsuite/gfortran.dg/pr103606.f90 b/gcc/testsuite/gfortran.dg/pr103606.f90
new file mode 100644
index 000..43283184e89
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103606.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! PR fortran/103606 -  ICE in resolve_fl_procedure
+! Contributed by G.Steinmetz
+
+program p
+  type t
+  end type
+contains
+  elemental function f() result(z) ! { dg-error "CLASS variable" }
+class(t) :: z
+  end
+end
--
2.26.2

[Bug analyzer/103658] missing -Wanalyzer-use-of-uninitialized-value at -O1 and below for an array access

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

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

--- Comment #1 from Martin Sebor  ---
Actually, what I was really after is trying to see if the analyzer would print
the conditionals involved in the subscript expressions.  But in the simple test
case in comment #0 there are no conditionals.  They are here:

int f (int i, int j)
{
  int a[3];
  a[0] = 1;
  a[1] = 2;

  if (i < 1 || 3 < i) i = 1;
  if (j < 1 || 5 < j) j = 1;
  return a[i + j];
}

but it doesn't print them even at -O2 when it does warn:

z.c: In function ‘f’:
z.c:9:11: warning: use of uninitialized value ‘a[]’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
9 |   return a[i + j];
  |  ~^~~
  ‘f’: event 1
|
|9 |   return a[i + j];
|  |  ~^~~
|  |   |
|  |   (1) use of uninitialized value ‘a[]’ here
|

[Bug c++/58950] Missing "statement has no effect"

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

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

--- Comment #26 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #25)
> (In reply to Marc Glisse from comment #6)
> > For:
> > 
> > void f(){
> >   int i = 2;
> >   (i+i);
> > }
> 
> This case is fixed on the trunk:
> 
> : In function 'void f1()':
> :9:5: warning: statement has no effect [-Wunused-value]
> 9 |   (i+i);
>   |   ~~^~~

I think it was fixed via r12-1804-g65870e75616ee4359d1c13b99 .

[Bug c++/58950] Missing "statement has no effect"

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #25 from Andrew Pinski  ---
(In reply to Marc Glisse from comment #6)
> For:
> 
> void f(){
>   int i = 2;
>   (i+i);
> }

This case is fixed on the trunk:

: In function 'void f1()':
:9:5: warning: statement has no effect [-Wunused-value]
9 |   (i+i);
  |   ~~^~~

Re: [PATCH] Replace gnu::unique_ptr with std::unique_ptr

[Jonathan Wakely via Gcc-patches]

On 10/12/21 21:20 +, Jonathan Wakely wrote:

Ping


Oh sorry, Jakub already replied to this (after I mentioned it on IRC)
and approved it. 


Un-ping!



On 09/11/21 17:51 +, Jonathan Wakely wrote:

Now that GCC is compiled as C++11 there is no need to keep the C++03
implementation of gnu::unique_ptr.

This removes the unique-ptr.h header and replaces it with  in
system.h, and changes the INCLUDE_UNIQUE_PTR macro to INCLUDE_MEMORY.
Uses of gnu::unique_ptr and gnu::move can be replaced with
std::unique_ptr and std::move. There are no uses of unique_xmalloc_ptr
or xmalloc_deleter in GCC.


Bootstrapped and tested on powerpc64le-linux. OK for trunk?



gcc/analyzer/ChangeLog:

* engine.cc: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.

gcc/c-family/ChangeLog:

* known-headers.cc: Define INCLUDE_MEMORY instead of
INCLUDE_UNIQUE_PTR.
* name-hint.h: Likewise.
(class name_hint): Use std::unique_ptr instead of gnu::unique_ptr.

gcc/c/ChangeLog:

* c-decl.c: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.
* c-parser.c: Likewise.

gcc/cp/ChangeLog:

* error.c: Define INCLUDE_MEMORY instead of
INCLUDE_UNIQUE_PTR.
* lex.c: Likewise.
* name-lookup.c: Likewise.
(class namespace_limit_reached): Use std::unique_ptr instead of
gnu::unique_ptr.
(suggest_alternatives_for): Use std::move instead of gnu::move.
(suggest_alternatives_in_other_namespaces): Likewise.
* parser.c: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.

gcc/ChangeLog:

* Makefile.in: Remove unique-ptr-tests.o.
* selftest-run-tests.c (selftest::run_tests): Remove
unique_ptr_tests_cc_tests.
* selftest.h (unique_ptr_tests_cc_tests): Remove.
* system.h: Check INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR
and include  instead of "unique-ptr.h".
* unique-ptr-tests.cc: Removed.

include/ChangeLog:

* unique-ptr.h: Removed.
---
gcc/Makefile.in   |   1 -
gcc/analyzer/engine.cc|   2 +-
gcc/c-family/known-headers.cc |   2 +-
gcc/c-family/name-hint.h  |  12 +-
gcc/c/c-decl.c|   2 +-
gcc/c/c-parser.c  |   2 +-
gcc/cp/error.c|   2 +-
gcc/cp/lex.c  |   2 +-
gcc/cp/name-lookup.c  |  10 +-
gcc/cp/parser.c   |   2 +-
gcc/selftest-run-tests.c  |   1 -
gcc/selftest.h|   1 -
gcc/system.h  |   8 +-
gcc/unique-ptr-tests.cc   | 236 
include/unique-ptr.h  | 405 --
15 files changed, 21 insertions(+), 667 deletions(-)
delete mode 100644 gcc/unique-ptr-tests.cc
delete mode 100644 include/unique-ptr.h

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 571e9c28e29..1e8e4449ffb 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1693,7 +1693,6 @@ OBJS = \
tree.o \
tristate.o \
typed-splay-tree.o \
-   unique-ptr-tests.o \
valtrack.o \
value-pointer-equiv.o \
value-query.o \
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index f21f8e5b78a..1312741bb47 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -19,7 +19,7 @@ along with GCC; see the file COPYING3.  If not see
.  */

#include "config.h"
-#define INCLUDE_UNIQUE_PTR
+#define INCLUDE_MEMORY
#include "system.h"
#include "coretypes.h"
#include "tree.h"
diff --git a/gcc/c-family/known-headers.cc b/gcc/c-family/known-headers.cc
index a3912468a8d..572cca177fa 100644
--- a/gcc/c-family/known-headers.cc
+++ b/gcc/c-family/known-headers.cc
@@ -18,7 +18,7 @@ along with GCC; see the file COPYING3.  If not see
.  */

#include "config.h"
-#define INCLUDE_UNIQUE_PTR
+#define INCLUDE_MEMORY
#include "system.h"
#include "coretypes.h"
#include "c-family/c-common.h"
diff --git a/gcc/c-family/name-hint.h b/gcc/c-family/name-hint.h
index ea433243ba4..3141552ea59 100644
--- a/gcc/c-family/name-hint.h
+++ b/gcc/c-family/name-hint.h
@@ -20,12 +20,12 @@ along with GCC; see the file COPYING3.  If not see
#ifndef GCC_NAME_HINT_H
#define GCC_NAME_HINT_H

-/* This header uses gnu::unique_ptr, but unique-ptr.h can't be directly
+/* This header uses std::unique_ptr, but  can't be directly
  included due to issues with macros.  Hence it must be included from
-   system.h by defining INCLUDE_UNIQUE_PTR in any source file using it.  */
+   system.h by defining INCLUDE_MEMORY in any source file using it.  */

-#ifndef GNU_UNIQUE_PTR_H
-# error "You must define INCLUDE_UNIQUE_PTR before including system.h to use 
name-hint.h"
+#ifndef INCLUDE_MEMORY
+# error "You must define INCLUDE_MEMORY before including system.h to use 
name-hint.h"
#endif

enum lookup_name_fuzzy_kind {
@@ -106,7 +106,7 @@ public:

 /* Take ownership of this name_hint's deferred_diagnostic, for use
in chaining up deferred diagnostics.  

[Bug analyzer/103658] New: missing -Wanalyzer-use-of-uninitialized-value at -O1 and below for an array access

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

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

Bug ID: 103658
   Summary: missing -Wanalyzer-use-of-uninitialized-value at -O1
and below for an array access
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

I came across this while comparing the middle end -Wuninitialized with 
-Wanalyzer-use-of-uninitialized-value.  They both trigger at -O2.  At -O1, only
-Wuninitialized triggers, even though the IL looks the same between the two
levels (as far as I can tell).

$ cat z.c && gcc -O1 -S -Wall -fdump-tree-uninit=/dev/stdout -fanalyzer z.c
int f (int i, int j)
{
  int a[3];
  a[0] = 1;
  a[1] = 2;

  if (i < 1) i = 1;
  if (j < 1) j = 1;
  return a[i + j];
}

;; Function f (f, funcdef_no=0, decl_uid=1979, cgraph_uid=1, symbol_order=0)

z.c: In function ‘f’:
z.c:9:11: warning: ‘a’ is used uninitialized [-Wuninitialized]
9 |   return a[i + j];
  |  ~^~~
z.c:3:7: note: ‘a’ declared here
3 |   int a[3];
  |   ^
int f (int i, int j)
{
  int a[3];
  int _1;
  int _6;
  int _8;
  int _9;

   [local count: 1073741824]:
  _8 = MAX_EXPR ;
  _6 = MAX_EXPR ;
  _1 = _6 + _8;
  _9 = a[_1];
  a ={v} {CLOBBER};
  return _9;

}

[Bug c++/86870] Declaration disambiguation is too greedy

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

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

--- Comment #2 from Andrew Pinski  ---
GCC, clang, MSVC and ICC all reject it.

Re: [PATCH] pch: Small cleanup

[Jeff Law via Gcc-patches]

On 12/10/2021 5:56 AM, Jakub Jelinek wrote:

On Thu, Dec 09, 2021 at 05:59:54PM +0100, Jakub Jelinek via Gcc-patches wrote:

/tmp/6140018_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/aarch64/aarch64-sve-builtins.cc:3920:0:
./gt-aarch64-sve-builtins.h: In function 'void
gt_pch_p_19registered_function(void*, void*, gt_pointer_operator, void*)':
./gt-aarch64-sve-builtins.h:86:44: error: no matching function for call to
'gt_pch_nx(aarch64_sve::function_instance*, void (*&)(void*, void*, void*),
void*&)'
  gt_pch_nx (&((*x).instance), op, cookie);

Fixed thusly, compile tested on x86_64-linux, committed to trunk.

Here is a small cleanup.  IMHO we should use gt_pointer_operator instead of
specifying manually void (*) (void *, void *) or
void (*) (void *, void *, void *) so that next time we want to change it,
we don't have to trace all the spots.  I was afraid it wouldn't work due to
header dependencies, but it works well.  gengtype generated files also
use gt_pointer_operator.

Ok for trunk (tested on x86_64-linux and cross to aarch64-linux)?

2021-12-10  Jakub Jelinek  

* machmode.h (gt_pch_nx): Use gt_pointer_operator as type of second
argument instead of equivalent void (*) (void *, void *, void *).
* poly-int.h (gt_pch_nx): Likewise.
* wide-int.h (gt_pch_nx): Likewise.
* config/aarch64/aarch64-sve-builtins.cc (gt_pch_nx): Likewise.

OK
jeff

Re: [PATCH] Replace gnu::unique_ptr with std::unique_ptr

[Jonathan Wakely via Gcc-patches]

Ping

On 09/11/21 17:51 +, Jonathan Wakely wrote:

Now that GCC is compiled as C++11 there is no need to keep the C++03
implementation of gnu::unique_ptr.

This removes the unique-ptr.h header and replaces it with  in
system.h, and changes the INCLUDE_UNIQUE_PTR macro to INCLUDE_MEMORY.
Uses of gnu::unique_ptr and gnu::move can be replaced with
std::unique_ptr and std::move. There are no uses of unique_xmalloc_ptr
or xmalloc_deleter in GCC.


Bootstrapped and tested on powerpc64le-linux. OK for trunk?



gcc/analyzer/ChangeLog:

* engine.cc: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.

gcc/c-family/ChangeLog:

* known-headers.cc: Define INCLUDE_MEMORY instead of
INCLUDE_UNIQUE_PTR.
* name-hint.h: Likewise.
(class name_hint): Use std::unique_ptr instead of gnu::unique_ptr.

gcc/c/ChangeLog:

* c-decl.c: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.
* c-parser.c: Likewise.

gcc/cp/ChangeLog:

* error.c: Define INCLUDE_MEMORY instead of
INCLUDE_UNIQUE_PTR.
* lex.c: Likewise.
* name-lookup.c: Likewise.
(class namespace_limit_reached): Use std::unique_ptr instead of
gnu::unique_ptr.
(suggest_alternatives_for): Use std::move instead of gnu::move.
(suggest_alternatives_in_other_namespaces): Likewise.
* parser.c: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.

gcc/ChangeLog:

* Makefile.in: Remove unique-ptr-tests.o.
* selftest-run-tests.c (selftest::run_tests): Remove
unique_ptr_tests_cc_tests.
* selftest.h (unique_ptr_tests_cc_tests): Remove.
* system.h: Check INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR
and include  instead of "unique-ptr.h".
* unique-ptr-tests.cc: Removed.

include/ChangeLog:

* unique-ptr.h: Removed.
---
gcc/Makefile.in   |   1 -
gcc/analyzer/engine.cc|   2 +-
gcc/c-family/known-headers.cc |   2 +-
gcc/c-family/name-hint.h  |  12 +-
gcc/c/c-decl.c|   2 +-
gcc/c/c-parser.c  |   2 +-
gcc/cp/error.c|   2 +-
gcc/cp/lex.c  |   2 +-
gcc/cp/name-lookup.c  |  10 +-
gcc/cp/parser.c   |   2 +-
gcc/selftest-run-tests.c  |   1 -
gcc/selftest.h|   1 -
gcc/system.h  |   8 +-
gcc/unique-ptr-tests.cc   | 236 
include/unique-ptr.h  | 405 --
15 files changed, 21 insertions(+), 667 deletions(-)
delete mode 100644 gcc/unique-ptr-tests.cc
delete mode 100644 include/unique-ptr.h

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 571e9c28e29..1e8e4449ffb 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1693,7 +1693,6 @@ OBJS = \
tree.o \
tristate.o \
typed-splay-tree.o \
-   unique-ptr-tests.o \
valtrack.o \
value-pointer-equiv.o \
value-query.o \
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index f21f8e5b78a..1312741bb47 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -19,7 +19,7 @@ along with GCC; see the file COPYING3.  If not see
.  */

#include "config.h"
-#define INCLUDE_UNIQUE_PTR
+#define INCLUDE_MEMORY
#include "system.h"
#include "coretypes.h"
#include "tree.h"
diff --git a/gcc/c-family/known-headers.cc b/gcc/c-family/known-headers.cc
index a3912468a8d..572cca177fa 100644
--- a/gcc/c-family/known-headers.cc
+++ b/gcc/c-family/known-headers.cc
@@ -18,7 +18,7 @@ along with GCC; see the file COPYING3.  If not see
.  */

#include "config.h"
-#define INCLUDE_UNIQUE_PTR
+#define INCLUDE_MEMORY
#include "system.h"
#include "coretypes.h"
#include "c-family/c-common.h"
diff --git a/gcc/c-family/name-hint.h b/gcc/c-family/name-hint.h
index ea433243ba4..3141552ea59 100644
--- a/gcc/c-family/name-hint.h
+++ b/gcc/c-family/name-hint.h
@@ -20,12 +20,12 @@ along with GCC; see the file COPYING3.  If not see
#ifndef GCC_NAME_HINT_H
#define GCC_NAME_HINT_H

-/* This header uses gnu::unique_ptr, but unique-ptr.h can't be directly
+/* This header uses std::unique_ptr, but  can't be directly
   included due to issues with macros.  Hence it must be included from
-   system.h by defining INCLUDE_UNIQUE_PTR in any source file using it.  */
+   system.h by defining INCLUDE_MEMORY in any source file using it.  */

-#ifndef GNU_UNIQUE_PTR_H
-# error "You must define INCLUDE_UNIQUE_PTR before including system.h to use 
name-hint.h"
+#ifndef INCLUDE_MEMORY
+# error "You must define INCLUDE_MEMORY before including system.h to use 
name-hint.h"
#endif

enum lookup_name_fuzzy_kind {
@@ -106,7 +106,7 @@ public:

  /* Take ownership of this name_hint's deferred_diagnostic, for use
 in chaining up deferred diagnostics.  */
-  gnu::unique_ptr take_deferred () { return move 
(m_deferred); }
+  std::unique_ptr take_deferred () { return move 
(m_deferred); }

  /* Call 

[Bug ipa/103601] [12 Regression] ICE in insert_kill, at ipa-modref-tree.c:84 since r12-5244-g64f3e71c302b4a13

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Roger Sayle  ---
This should now be fixed on mainline.

[Bug fortran/103606] [9/10/11/12 Regression] ICE in resolve_fl_procedure, at fortran/resolve.c:13297 since r9-3324-g2b03b800d866d345

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Tentative semi-obvious patch:

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 0ed31970f8b..bff1b35446f 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -13294,7 +13294,8 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)

   /* An elemental function is required to return a scalar 12.7.1  */
   if (sym->attr.elemental && sym->attr.function
-  && (sym->as || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->as)))
+  && (sym->as || (sym->ts.type == BT_CLASS && sym->attr.class_ok
+ && CLASS_DATA (sym)->as)))
 {
   gfc_error ("ELEMENTAL function %qs at %L must have a scalar "
 "result", sym->name, >declared_at);

[Bug c++/92053] Compilation fails or succeeds depending on the optimization flags

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Last reconfirmed|2021-07-27 00:00:00 |2021-12-10

--- Comment #5 from Andrew Pinski  ---
On the trunk, we accept it no matter what optimization level now.

Re: [PATCH] gengtype: remove "tree_exp" special attribute

[Jeff Law via Gcc-patches]

On 12/10/2021 8:41 AM, Patrick Palka via Gcc-patches wrote:

The function comment for adjust_field_tree_exp says this special case
is for handling trees whose operands may contain pointers to RTL instead
of to trees.  But ever since r0-59671, which fixed/removed the last two
tree codes for which this was possible (GOTO_SUBROUTINE_EXPR and
WITH_CLEANUP_EXPR), this special attribute is largely a no-op.

This patch removes it and instead just annotates struct tree_exp
with the "length" attribute directly.  Not sure it makes a difference,
but I use %h instead of %0 in the "length" attribute to be consistent
with other structures' "length" attributes within tree-core.h.

This changes the code generated for TS_EXP handling in gt-cp-tree.h from:

   case TS_EXP:
 gt_ggc_m_9tree_node ((*x).generic.exp.typed.type);
 switch ((int) (TREE_CODE ((tree) &(*x
   {
   default:
{
  size_t i3;
  size_t l3 = (size_t)(TREE_OPERAND_LENGTH ((tree) &(*x)));
  for (i3 = 0; i3 != l3; i3++) {
gt_ggc_m_9tree_node ((*x).generic.exp.operands[i3]);
  }
}
break;
   }
 break;

to:

   case TS_EXP:
 {
   size_t l3 = (size_t)(TREE_OPERAND_LENGTH ((tree)&((*x).generic.exp)));
   gt_ggc_m_9tree_node ((*x).generic.exp.typed.type);
   {
size_t i3;
for (i3 = 0; i3 != l3; i3++) {
  gt_ggc_m_9tree_node ((*x).generic.exp.operands[i3]);
}
   }
 }

which seems equivalent and simpler.

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

gcc/ChangeLog:

* gengtype.c (adjust_field_tree_exp): Remove.
(adjust_field_type): Don't handle the "tree_exp" special attribute.
* tree-core.h (struct tree_exp): Replace special and desc
attributes with length.

Should this wait until stage1 reopens?  It doesn't seem like a bugfix.

jeff

[Bug c++/78217] Duplicate decls handling with auto

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||lebedev.ri at gmail dot com

--- Comment #5 from Andrew Pinski  ---
*** Bug 85932 has been marked as a duplicate of this bug. ***

[Bug c++/85932] GCC incorrectly rejects mismatch of types, instead of retrying after type deduction.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 78217.

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

[Bug target/103623] [12 Regression] error: unable to generate reloads (ICE in curr_insn_transform, at lra-constraints.c:4132), or error: insn does not satisfy its constraints (ICE in extract_constrain

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

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

Peter Bergner  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-12-10
 Status|UNCONFIRMED |ASSIGNED

--- Comment #4 from Peter Bergner  ---
This is confirmed.

[Bug c/103645] Gimplifier does not remove empty struct stores in a few cases

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-12-10
 Ever confirmed|0   |1

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

[Bug objc/103639] [11/12 Regression] switch case with break in fast enumeration loop generates wrong code

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
 CC||pinskia at gcc dot gnu.org

[Bug target/103657] GCC can no longer catch EH on x86_64-w64-mingw32 hosted 64 bits

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
https://sourceware.org/bugzilla/show_bug.cgi?id=28682

[Bug tree-optimization/103647] constant array comparison not always folded

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-12-10
   Severity|normal  |enhancement
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
So in fab GCC creates:
  a = "ac";
  b = "ab";
  _8 = MEM  [(char * {ref-all})];
  _9 = MEM  [(char * {ref-all})];
  _10 = _8 != _9;

And:
  a = "ab";
  b = "abc";
  _8 = MEM  [(char * {ref-all})];
  _9 = MEM  [(char * {ref-all})];
  _10 = _8 != _9;

But we don't have a FRE/DOM to optimize those MEM_REFs.

Confirmed.

[Bug tree-optimization/103647] constant array comparison not always folded

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

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

--- Comment #1 from Andrew Pinski  ---
well f should be optimized to return true while g should be optimized to return
false.

[Bug fortran/103610] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.c:193

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:3459ef2e9f9cd4d3ed64c9bc44282534a24987b8

commit r11-9372-g3459ef2e9f9cd4d3ed64c9bc44282534a24987b8
Author: Harald Anlauf 
Date:   Tue Dec 7 23:06:41 2021 +0100

Fortran: dimensions of an array have to be non-negative

gcc/fortran/ChangeLog:

PR fortran/103610
* array.c (spec_dimen_size): Fix simplification of SHAPE:
dimensions must be non-negative.

gcc/testsuite/ChangeLog:

PR fortran/103610
* gfortran.dg/shape_11.f90: New test.

(cherry picked from commit 5f7cdea34e118776d0ccd2ff3dda0f5acab18a94)

[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.4
  Known to work||10.3.1, 11.2.1

[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||andre.schackier at gmail dot 
com

--- Comment #18 from Andrew Pinski  ---
*** Bug 103651 has been marked as a duplicate of this bug. ***

[Bug gcov-profile/103651] Using "#Line 0" in a function with "-coverage" crashes the compiler

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 100788.

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

[Bug fortran/103607] [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from anlauf at gcc dot gnu.org ---
Fixed on all affected open branches.  Closing.

Thanks for the report!

[Bug target/103657] GCC can no longer catch EH on x86_64-w64-mingw32 hosted 64 bits

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #2 from cqwrteur  ---
D:\hg\fast_io\tests\0017.error>g++ -o error error.cc -Ofast -std=c++2b -s
-march=native -I../../include -lntdll -fuse-ld=lld

D:\hg\fast_io\tests\0017.error>error
errc:no_such_file_or_directory


clang++ -o error error.cc -Ofast -std=c++2b -s  -march=native -I../../include
-lntdll

D:\hg\fast_io\tests\0017.error>error



Looks like it is GNU ld linker's issue. Need to report there probably.

[Bug c++/103657] GCC can no longer catch EH on x86_64-w64-mingw32 hosted 64 bits

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
D:\hg\fast_io\tests\0017.error>g++ -o error error.cc -Ofast -std=c++2b -s -flto
-march=native -I../../include -lntdll

D:\hg\fast_io\tests\0017.error>error

D:\hg\fast_io\tests\0017.error>clang++ -o error error.cc -Ofast -std=c++2b -s
-flto -march=native -I../../include -lntdll -fuse-ld=lld

D:\hg\fast_io\tests\0017.error>error
Hello EH

[Bug c++/103657] New: GCC can no longer throw EH on x86_64-w64-mingw32 hosted 64 bits

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 103657
   Summary: GCC can no longer throw EH on x86_64-w64-mingw32
hosted 64 bits
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

#include

int main()
try
{
throw 0;
}
catch(...)
{
puts("Hello EH\n");
return 1;
}


GCC cannot catch EH on windows anymore.

while clang and g++ -m32 all work

[Bug target/103656] make install-strip -j cannot find x86_64-w64-mingw32-strip for canadian compilation

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
rm -rf
/home/cqwrteur/canadian/x86_64-w64-mingw32/libexec/gcc/x86_64-w64-mingw32/12.0.0/install-tools
rm: cannot remove
'/home/cqwrteur/canadian/x86_64-w64-mingw32/libexec/gcc/x86_64-w64-mingw32/12.0.0/install-tools/fixincl.exe':
Permission denied

[Bug target/103656] New: make install-strip -j cannot find x86_64-w64-mingw32-strip for canadian compilation

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 103656
   Summary: make install-strip -j cannot find
x86_64-w64-mingw32-strip for canadian compilation
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

test -z 'x86_64-w64-mingw32-strip' || x86_64-w64-mingw32-strip
/home/cqwrteur/canadian/x86_64-w64-mingw32/libexec/gcc/x86_64-w64-mingw32/12.0.0/install-tools/fixincl.exe
/bin/bash: x86_64-w64-mingw32-strip: command not found
make[1]: *** [Makefile:191: install-strip] Error 127
make[1]: Leaving directory
'/home/cqwrteur/myhome/gcc_build/canadian/x86_64-w64-mingw32/gcc/fixincludes'
make: *** [Makefile:4005: install-strip-fixincludes] Error 2
make: *** Waiting for unfinished jobs

Re: [PATCH] vect: Add bias parameter for partial vectorization

[Richard Sandiford via Gcc-patches]

Robin Dapp  writes:
> Hi Kewen, Richard,
>
> thanks for the comments, I addressed them in the attached v4.

Sorry again for the slow review.  I only have some very minor
comments left:

> Bootstrap and regtest are good as before.
>
> Regards
>  Robin
>
> diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
> index bf033e31c1c..dc2756f83e9 100644
> --- a/gcc/config/rs6000/vsx.md
> +++ b/gcc/config/rs6000/vsx.md
> @@ -5637,7 +5637,8 @@
>  (define_expand "len_load_v16qi"
>[(match_operand:V16QI 0 "vlogical_operand")
> (match_operand:V16QI 1 "memory_operand")
> -   (match_operand:QI 2 "gpc_reg_operand")]
> +   (match_operand:QI 2 "gpc_reg_operand")
> +   (match_operand:QI 3 "zero_constant")]
>"TARGET_P9_VECTOR && TARGET_64BIT"
>  {
>rtx mem = XEXP (operands[1], 0);
> @@ -5651,6 +5652,7 @@
>[(match_operand:V16QI 0 "memory_operand")
> (match_operand:V16QI 1 "vlogical_operand")
> (match_operand:QI 2 "gpc_reg_operand")
> +   (match_operand:QI 3 "zero_constant")
>]
>"TARGET_P9_VECTOR && TARGET_64BIT"
>  {
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index 2b41cb7fb7b..8df61f578bd 100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -5213,7 +5213,10 @@ which must be a vector mode.  Operand 2 has whichever 
> integer mode the
>  target prefers.  If operand 2 exceeds the number of elements in mode
>  @var{m}, the behavior is undefined.  If the target prefers the length
>  to be measured in bytes rather than elements, it should only implement
> -this pattern for vectors of @code{QI} elements.
> +this pattern for vectors of @code{QI} elements.  Operand 3 specifies
> +a bias predicate that determines whether a length of zero is permitted
> +or not.  If permitted, the predicate should only allow a zero immediate,
> +otherwise it should only allow an immediate value of -1.

I think it would be better to fold this into the existing documentation
a bit more:

--
Load (operand 2 - operand 3) elements from vector memory operand 1 into
vector register operand 0, setting the other elements of operand 0 to
undefined values.  Operands 0 and 1 have mode @var{m}, which must be a
vector mode.  Operand 2 has whichever integer mode the target prefers.
Operand 3 conceptually has mode @code{QI}.

Operand 2 can be a variable or a constant amount.  Operand 3 specifies
a constant bias: it is either a constant 0 or a constant -1.  The predicate
on operand 3 must only accept the bias values that the target actually
supports.  GCC handles a bias of 0 more efficiently than a bias of -1.

If (operand 2 - operand 3) exceeds the number of elements in mode @var{m},
the behavior is undefined.

If the target prefers the length to be measured in bytes rather than
elements, it should only implement this pattern for vectors of @code{QI}
elements.
--

> @@ -5226,7 +5229,10 @@ a vector mode.  Operand 2 has whichever integer mode 
> the target prefers.
>  If operand 2 exceeds the number of elements in mode @var{m}, the behavior
>  is undefined.  If the target prefers the length to be measured in bytes
>  rather than elements, it should only implement this pattern for vectors
> -of @code{QI} elements.
> +of @code{QI} elements.  Operand 3 specifies a bias predicate that
> +determines whether a length of zero is permitted or not.  If permitted,
> +the predicate should only allow a zero constant, otherwise it should
> +only allow an immediate value of -1.
>  
>  This pattern is not allowed to @code{FAIL}.

Similarly here I think we should say:

--
Store (operand 2 - operand 3) vector elements from vector register
operand 1 into memory operand 0, leaving the other elements of operand 0
unchanged.  Operands 0 and 1 have mode @var{m}, which must be a vector mode.
Operand 2 has whichever integer mode the target prefers.  Operand 3
conceptually has mode @code{QI}.

Operand 2 can be a variable or a constant amount.  Operand 3 specifies
a constant bias: it is either a constant 0 or a constant -1.  The predicate
on operand 3 must only accept the bias values that the target actually
supports.  GCC handles a bias of 0 more efficiently than a bias of -1.

If (operand 2 - operand 3) exceeds the number of elements in mode @var{m},
the behavior is undefined.

If the target prefers the length to be measured in bytes rather than
elements, it should only implement this pattern for vectors of @code{QI}
elements.
--

> diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> index 8312d08aab2..d45f080c06f 100644
> --- a/gcc/internal-fn.c
> +++ b/gcc/internal-fn.c
> @@ -2696,9 +2696,9 @@ expand_call_mem_ref (tree type, gcall *stmt, int index)
>  static void
>  expand_partial_load_optab_fn (internal_fn, gcall *stmt, convert_optab optab)
>  {

[PATCH] c++: processing_template_decl vs template depth [PR103408]

[Patrick Palka via Gcc-patches]

We use processing_template_decl in two slightly different ways: as
a flag to signal that we're dealing with templated trees, and its
magnitude is also used as a proxy for the current syntactic template
depth.  This overloaded meaning of p_t_d is conceptually confusing and
leads to bugs that we end up working around in an ad-hoc fashion.

This patch replaces all uses of processing_template_decl that care about
its magnitude to instead look at the depth of current_template_parms
via a new current_template_depth macro.  This allows us to eliminate 3
workarounds in the concepts code: two about non-templated
requires-expressions (in constraint.cc) and one about lambdas inside
constraints (in cp_parser_requires_clause_expression etc).

The replacement was mostly mechanical.  There were two gotchas:

  * In synthesize_implicit_template_parm, when introducing a new template
parameter list for an abbreviated function template, we need to add a
new level of current_template_parms before calling
process_template_parm since this function now looks at
current_template_depth to determine the level of the new parameter.

  * In instantiate_class_template_1 when instantiating a template
friend, we need to set current_template_parms instead of
processing_template_decl so that the friend_depth computation in
make_friend_class remains correct.

Bootstrpped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?  Also tested on cmcstl2 and rangev3.

PR c++/103408

gcc/cp/ChangeLog:

* constraint.cc (type_deducible_p): Remove workaround for
non-templated requires-expressions.
(normalize_placeholder_type_constraints): Likewise.
* cp-tree.h (current_template_depth): Define.
* decl.c (start_decl): Inspect current_template_depth instead of
the magnitude of processing_template_decl.
(grokfndecl): Likewise.
(grokvardecl): Likewise.
(grokdeclarator): Likewise.
* friend.c (make_friend_class): Likewise.
(do_friend): Likewise.
* parser.c (cp_parser_requires_clause_expression): Remove
workaround for lambdas inside constraints.
(cp_parser_constraint_expression): Likewise.
(cp_parser_requires_expression): Likewise.
(synthesize_implicit_template_parm): Add to current_template_parms
before calling process_template_parm.
* pt.c (inline_needs_template_parms): Inspect
current_template_depth instead of the magnitude of
processing_template_decl.
(push_inline_template_parms_recursive): Likewise.
(maybe_begin_member_template_processing): Likewise.
(begin_template_parm_list): Likewise.
(process_template_parm): Likewise.
(end_template_parm_list): Likewise.
(add_inherited_template_parms): Likewise.
(instantiate_class_template_1): Rename
adjust_processing_template_decl to adjust_template_depth.  Set
current_template_parms instead of processing_template_decl when
adjust_template_depth.
(make_auto_1): Inspect current_template_depth instead of the
magnitude of processing_template_decl.
(splice_late_return_type): Likewise.
* semantics.c (fixup_template_type): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/concepts/diagnostic18.C: Expect a "constraints on a
non-templated function" error.
* g++.dg/cpp23/auto-fncast10.C: New test.
---
 gcc/cp/constraint.cc | 16 --
 gcc/cp/cp-tree.h |  2 +
 gcc/cp/decl.c| 10 ++--
 gcc/cp/friend.c  |  4 +-
 gcc/cp/parser.c  | 28 --
 gcc/cp/pt.c  | 54 +++-
 gcc/cp/semantics.c   |  2 +-
 gcc/testsuite/g++.dg/concepts/diagnostic18.C |  2 +-
 gcc/testsuite/g++.dg/cpp23/auto-fncast10.C   | 19 +++
 9 files changed, 70 insertions(+), 67 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp23/auto-fncast10.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 2896efdd7f2..566f4e38fac 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -2016,14 +2016,6 @@ type_deducible_p (tree expr, tree type, tree 
placeholder, tree args,
  references are preserved in the result.  */
   expr = force_paren_expr_uneval (expr);
 
-  /* When args is NULL, we're evaluating a non-templated requires expression,
- but even those are parsed under processing_template_decl == 1, and so the
- placeholder 'auto' inside this return-type-requirement has level 2.  In
- order to have all parms and arguments match up for satisfaction, we need
- to pass an empty level of OUTER_TARGS in this case.  */
-  if (!args)
-args = make_tree_vec (0);
-
   tree deduced_type = do_auto_deduction (type, expr, placeholder,
 

Re: [PATCH] jit: Add support for global rvalue initialization and ctors

[Marc Nieper-Wißkirchen via Gcc-patches]

 Hi,

I would favor adding support for this kind of initialization to libgccjit.

Does it also support the libgccjit equivalent of the following C module,
which contains forward references in the struct initializers?

struct bar bar;
struct foo foo;

struct foo
{
  struct bar *b;
};

struct bar
{
  struct foo *f;
};

struct bar bar = {.f = };
struct foo foo = {.b = };

Thanks,

Marc

Am Mo., 29. Nov. 2021 um 21:04 Uhr schrieb Petter Tomner via Jit <
j...@gcc.gnu.org>:

> Hi!
>
> I have wrapped up the patch than adds support for initialization of global
> variables
> with rvalues aswell as rvalue constructors for structs, arrays and unions.
>
> New entrypoints are:
>
> gcc_jit_global_set_initializer_rvalue
>
> Which sets the initial value of a global to a rvalue.
>
> And:
>
> gcc_jit_context_new_array_constructor
> gcc_jit_context_new_struct_constructor
> gcc_jit_context_new_union_constructor
>
> Those three makes a constructor with a rvalue that e.g. can be assigned to
> a local or returned
> from a function, or most importantly used to set the initial value of
> global variables
> with gcc_jit_global_set_initializer_rvalue.
>
> If no fields are specified for a struct or union to the constructors,
> definition order is assumed.
>
> There can be gaps in the fields specified to the struct constructor, but
> they need to be in order.
>
> For pointer arithmetic to work with setting DECL_INITIAL, alot of folding
> is added.
>
> make check-jit runs fine on gnu-linux-x64 Debian.
>
> Regards,

Re: [PATCH] Replace gnu::unique_ptr with std::unique_ptr

[Jakub Jelinek via Gcc-patches]

On Tue, Nov 09, 2021 at 05:51:27PM +, Jonathan Wakely via Gcc-patches wrote:
> Now that GCC is compiled as C++11 there is no need to keep the C++03
> implementation of gnu::unique_ptr.
> 
> This removes the unique-ptr.h header and replaces it with  in
> system.h, and changes the INCLUDE_UNIQUE_PTR macro to INCLUDE_MEMORY.
> Uses of gnu::unique_ptr and gnu::move can be replaced with
> std::unique_ptr and std::move. There are no uses of unique_xmalloc_ptr
> or xmalloc_deleter in GCC.
> 
> 
> Bootstrapped and tested on powerpc64le-linux. OK for trunk?
> 
> 
> 
> gcc/analyzer/ChangeLog:
> 
>   * engine.cc: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.
> 
> gcc/c-family/ChangeLog:
> 
>   * known-headers.cc: Define INCLUDE_MEMORY instead of
>   INCLUDE_UNIQUE_PTR.
>   * name-hint.h: Likewise.
>   (class name_hint): Use std::unique_ptr instead of gnu::unique_ptr.
> 
> gcc/c/ChangeLog:
> 
>   * c-decl.c: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.
>   * c-parser.c: Likewise.
> 
> gcc/cp/ChangeLog:
> 
>   * error.c: Define INCLUDE_MEMORY instead of
>   INCLUDE_UNIQUE_PTR.
>   * lex.c: Likewise.
>   * name-lookup.c: Likewise.
>   (class namespace_limit_reached): Use std::unique_ptr instead of
>   gnu::unique_ptr.
>   (suggest_alternatives_for): Use std::move instead of gnu::move.
>   (suggest_alternatives_in_other_namespaces): Likewise.
>   * parser.c: Define INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR.
> 
> gcc/ChangeLog:
> 
>   * Makefile.in: Remove unique-ptr-tests.o.
>   * selftest-run-tests.c (selftest::run_tests): Remove
>   unique_ptr_tests_cc_tests.
>   * selftest.h (unique_ptr_tests_cc_tests): Remove.
>   * system.h: Check INCLUDE_MEMORY instead of INCLUDE_UNIQUE_PTR
>   and include  instead of "unique-ptr.h".
>   * unique-ptr-tests.cc: Removed.
> 
> include/ChangeLog:
> 
>   * unique-ptr.h: Removed.

LGTM.

Jakub

Re: pr103523: Check for PLUS/MINUS support

[Richard Sandiford via Gcc-patches]

Joel Hutton  writes:
> ok for backport to 11?

Yes, thanks.

Richard

[Bug fortran/103607] [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:8b1dae4d33285643c5f51d828aa6f31ffbfc33b7

commit r9-9863-g8b1dae4d33285643c5f51d828aa6f31ffbfc33b7
Author: Harald Anlauf 
Date:   Tue Dec 7 21:34:31 2021 +0100

Fortran: perform array subscript checks only for valid INTEGER bounds

gcc/fortran/ChangeLog:

PR fortran/103607
* frontend-passes.c (do_subscript): Ensure that array bounds are
of type INTEGER before performing checks on array subscripts.

gcc/testsuite/ChangeLog:

PR fortran/103607
* gfortran.dg/pr103607.f90: New test.

(cherry picked from commit 9eec77c0df9e5c67454a2e8f83246104458ba4f0)

[Bug fortran/103607] [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:45cbfabe01878c3efd8b24f3fef06baf48983308

commit r10-10330-g45cbfabe01878c3efd8b24f3fef06baf48983308
Author: Harald Anlauf 
Date:   Tue Dec 7 21:34:31 2021 +0100

Fortran: perform array subscript checks only for valid INTEGER bounds

gcc/fortran/ChangeLog:

PR fortran/103607
* frontend-passes.c (do_subscript): Ensure that array bounds are
of type INTEGER before performing checks on array subscripts.

gcc/testsuite/ChangeLog:

PR fortran/103607
* gfortran.dg/pr103607.f90: New test.

(cherry picked from commit 9eec77c0df9e5c67454a2e8f83246104458ba4f0)

[PATCH] Leverage sysroot for VxWorks

[Olivier Hainque via Gcc-patches]

Hello,

The build of a VxWorks toolchain relies a lot on system headers
and VxWorks has a few very specific features that require special
processing. For example, different sets of headers for the kernel
vs the rtp modes, which the compiler knows about by way of -mrtp
on the command line.

If we manage to avoid the need for fixincludes on recent versions
of VxWorks (>= 7), we still need to handle at least VxWorks 6.9 at
this stage.

We sort of get away with locating the correct headers at
run-time thanks to environment variables and various tests for
-mrtp in cpp specs, but getting fixincludes to work for old
configurations has always been tricky and getting a toolchain
to build with c++/libstdc++ support gets trickier with every
move to a more recent release.

sysroot_headers_suffix_spec is a pretty powerful device to help
address such issues, and this patch introduces changes that let
us get advantage of it.

The general idea is to leverage the assumption that compilations
occur with --sysroot=$VSB_DIR on vx7 or --sysroot=$WIND_BASE/target
prior to that.

For the toolchains we build, this is achieved with a few
configure options like:

  --with-sysroot
  --with-build-sysroot=${WIND_BASE}/target
  --with-specs=%{!sysroot=*:--sysroot=%:getenv(WIND_BASE /target)}

This allows simplifying the libgcc compilation flags control
and we take the opportunity to merge t-vxworks7 into t-vxworks as
the two files were differing only on the libgcc2 flags part.

This also makes sure that we don't set inhibit_libc true
during the build, which is sane since the build really relies a
lot on system headers.

Preliminary tests showed that a build from mainline sources
now actually fail if the build configuration somehow gets to
inhibit_libc=true.

I have had very good results with this for several ports on a
gcc-11 branch, for both VxWorks 6.9 and two variants of 7.2,
for both kernel and rtp modes, including with shared libs on
two targets for 7.2 (powerpc64 and x86_64).

I was also able to get a successful build of c, c++
and libstdc++ on mainline for VxWorks 6.9, with a few fixincludes
adjustments as expected.

This touches only VxWorks related items and, all in all, I
believe this robustifies the family of ports and helps avoid
build failure with mainline sources so remains applicable
to the current stage. 

Olivier

---

2021-12-09  Olivier Hainque  

gcc/
* config/t-vxworks: Clear NATIVE_SYSTEM_HEADER_DIR.
* config/vxworks.h (SYSROOT_HEADERS_SUFFIX_SPEC): Define, for
VxWorks 7 and earlier.
(VXWORKS_ADDITIONAL_CPP_SPEC): Simplify accordingly.
(STARTFILE_PREFIX_SPEC): Adjust accordingly.
* config/rs6000/vxworks.h (STARTFILE_PREFIX_SPEC): Adjust.

libgcc/
* config/t-vxworks (LIBGCC2_INCLUDES): Simplify and handle
both VxWorks7 and earlier.
* config/t-vxworks7: Remove.
* config.host: Remove special case for vxworks7.



0001-Leverage-sysroot-for-VxWorks.patch
Description: Binary data

Re: [PATCH] #undef isblank before def or decl in libstdc++ headers

[Jonathan Wakely via Gcc-patches]

On Fri, 10 Dec 2021 at 17:07, Olivier Hainque via Libstdc++
 wrote:
>
> Hello,
>
> The attached patch helps fix a build failure of libstdc++
> on some variants of VxWorks where the system headers expose
> an "isblank" macro.
>
> I understand this kind of thing normally is handled through
> fixincludes, however fixincludes on VxWorks is very tricky and
> we already have
>
>   libstdc++-v3/include/c_global/cctype:#undef isblank
>   libstdc++-v3/include/tr1/cctype:#undef isblank
>
> so the suggestion here is to simply do the same in a couple
> more places.

Both of those places already include  so I think we should just do this:

--- a/libstdc++-v3/include/c_global/cctype
+++ b/libstdc++-v3/include/c_global/cctype
@@ -78,10 +78,10 @@ namespace std

#if __cplusplus >= 201103L

-#ifdef _GLIBCXX_USE_C99_CTYPE_TR1
-
#undef isblank

+#ifdef _GLIBCXX_USE_C99_CTYPE_TR1
+
namespace std
{
  using ::isblank;

I'm curious why _GLIBCXX_USE_C99_CTYPE_TR1 is not defined if VxWorks
has isblank, the configure check is:

  # Check for the existence of  functions.
  AC_CACHE_CHECK([for ISO C99 support to TR1 in ],
  glibcxx_cv_c99_ctype_tr1, [
  AC_TRY_COMPILE([#include ],
 [int ch;
  int ret;
  ret = isblank(ch);
 ],[glibcxx_cv_c99_ctype_tr1=yes],
   [glibcxx_cv_c99_ctype_tr1=no])
  ])
  if test x"$glibcxx_cv_c99_ctype_tr1" = x"yes"; then
AC_DEFINE(_GLIBCXX_USE_C99_CTYPE_TR1, 1,
  [Define if C99 functions in  should be imported in
   in namespace std::tr1.])
  fi

In any case, undef'ing it unconditionally in  should work, and
avoids having to do it in multiple places (we still need it in
 because that is used in C++98 code, whereas the other
definitions of functions called "isblank" were added for C++11).

[Bug libstdc++/103655] New: "x" does not exist on windows and dos

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 103655
   Summary: "x" does not exist on windows and dos
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

In today's patch.

https://github.com/gcc-mirror/gcc/commit/a219139e986a4200a9105d7c1fa63735d2945994

std::ios::noreplace uses "x". However, that is not correctly supported by
msvcrt and dos djgpp.

The correct way is to directly use CreateFileW (on windows NT) or NtCreateFile
and CreateFileA on windows 9x. Then call _open_osfhandle to create an fd then
call _wfdopen(on windows NT) or _fdopen(on windows 9x) on Windows

Create an NT handle with NtCreateFile (You also need RtlNtStatusToDosError and
RtlDosPathNameToNtPathName_U_WithStatus or RtlDosPathNameToNtPathName_U).

https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_hosted/platforms/nt.h#L67

Or create a win32 handle with CreateFileA (on Windows 9x) and CreateFileW (on
Windows NT)

https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_hosted/platforms/win32.h#L201

Use win32 or nt handle to call _open_osfhandle to create a POSIX fd.

https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_hosted/platforms/posix.h#L58

https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_hosted/platforms/posix.h#L961

Then use _wfdopen on Windows NT and _fdopen on Windows 9x to open a FILE*

https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_legacy_impl/c/impl.h#L29

Then construct a std::filebuf with FILE*

https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_legacy_impl/filebuf/filebuf_file.h#L60


On DOS. You need __dos_creat,__dos_creatnew,__dos_open
https://github.com/tearosccebe/fast_io/blob/6081ae18b34820c3c69b81628f520f5fafcfb815/include/fast_io_hosted/platforms/posix.h#L1063


So libstdc++ using fdopen to open FILE* with fd is incorrect. On windows NT
kernel, we MUST use _wfdopen since _fdopen involves locale, which is not
thread-safe.

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

[Jonathan Wakely via Gcc-patches]

On Fri, 10 Dec 2021 at 17:17, Jakub Jelinek wrote:
>
> On Fri, Dec 10, 2021 at 10:11:04AM -0700, Martin Sebor via Gcc-patches wrote:
> > On 12/10/21 9:41 AM, Jakub Jelinek wrote:
> > > On Fri, Dec 10, 2021 at 09:35:50AM -0700, Martin Sebor via Gcc-patches 
> > > wrote:
> > > > The above was just a quick proof of concept experiment.  You're
> > > > of course right that the final solution can't be so crude(*).
> > > > But if the required functions are always_inline (I think member
> > > > functions defined in the body of the class implicitly are
> > >
> > > They are not, and can't be, nothing says that such member functions
> > > can't use constructs that make it uninlinable (with always_inline
> > > that would be an error), or are way too large that inlining is not
> > > desirable, etc.  They are just implicitly inline.
> >
> > The functions we're talking about are the trivial max_size()
> > members of std::string and allocator traits.  They just return
> > a constant.
> >
> > But I see I was wrong, even member functions have to be explicitly
> > declared always_inline to be guaranteed to be inlined even at -O0.
> > I don't think that should be an issue for the trivial max_size()
> > (at least not for the std::string specialization).
>
> Note, if those functions are declared constexpr, without -fno-inline
> (default at -O0), then cp_fold will try to evaluate such calls to constant
> expressions already, effectively "inlining" them.

Every member function of std::string is constexpr in C++20, but not
before. But we could add constexpr to internal _M_xxx functions if
that benefits optimization.

For std::basic_string::max_size() it has to call another function
provided by the allocator, but for the std::string (i.e.
std::basic_string, allocator>)
specialization we know what the allocator is going to tell us.

--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -1071,7 +1071,12 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
  _GLIBCXX20_CONSTEXPR
  size_type
  max_size() const _GLIBCXX_NOEXCEPT
-  { return (_Alloc_traits::max_size(_M_get_allocator()) - 1) / 2; }
+  {
+   if _GLIBCXX17_CONSTEXPR (__are_same>)
+ return size_t(-1) / 2;
+   else
+ return (_Alloc_traits::max_size(_M_get_allocator()) - 1) / 2;
+  }

  /**
   *  @brief  Resizes the %string to the specified number of characters.

[Bug jit/103562] Jitted code produces incorrect result when returning 3-member struct from internal function

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #5 from David Malcolm  ---
Thanks for filing this bug, and for the investigation.

After a couple of hours debugging, I think I've found the discrepancy between
cc1 and libgccjit, and have a candidate fix.

When tree-inline.c:remap_gimple_stmt is called to remap the stmt:
= *ptr_2(D);
cc1 returns:
   D.1989 = *ptr_2(D);
whereas libgccjit returns this (copy):
= *ptr_2(D);

Putting a breakpoint on remap_gimple_op_r and singlestepping (in both cc1 and
libgccjit, side by side) shows the discrepancy happens in
tree-inline.c:remap_gimple_op_r here:

   1036   else if (auto_var_in_fn_p (*tp, fn))

For cc1:

   (gdb) p auto_var_in_fn_p (*tp, fn)
   $28 = true

whereas for libgccjit:

   (gdb) p auto_var_in_fn_p (*tp, fn)
   $19 = false

and so libgccjit erroneously skips the remapping of locals vars and labels.

This turns out to be because the RESULT_DECL has a non-NULL DECL_CONTEXT in
cc1, set here by the C frontend:

(gdb) bt
#0  finish_function (end_loc=248384) at ../../src/gcc/c/c-decl.c:10271
#1  0x009db5f7 in c_parser_declaration_or_fndef (parser=0x77ffbbd0,
fndef_ok=true, static_assert_ok=true, empty_ok=true, nested=false, 
start_attr_ok=true, objc_foreach_object_declaration=0x0,
omp_declare_simd_clauses=0x0, have_attrs=false, attrs=, 
oacc_routine_data=0x0, fallthru_attr_p=0x0) at
../../src/gcc/c/c-parser.c:2563
#2  0x009d9925 in c_parser_external_declaration (parser=0x77ffbbd0)
at ../../src/gcc/c/c-parser.c:1779
#3  0x009d941d in c_parser_translation_unit (parser=0x77ffbbd0) at
../../src/gcc/c/c-parser.c:1652
#4  0x00a21267 in c_parse_file () at ../../src/gcc/c/c-parser.c:23280
#5  0x00abd0ab in c_common_parse_file () at
../../src/gcc/c-family/c-opts.c:1238
#6  0x010cab1a in compile_file () at ../../src/gcc/toplev.c:452
#7  0x0093eb7a in do_compile (no_backend=false) at
../../src/gcc/toplev.c:2156
#8  toplev::main (this=0x7fffde1a, argc=, argv=) at ../../src/gcc/toplev.c:2308
#9  0x0270339d in main (argc=24, argv=0x7fffdf28) at
../../src/gcc/main.c:39
(gdb) list
10266 /* Must mark the RESULT_DECL as being in this function.  */
10267   
10268 if (DECL_RESULT (fndecl) && DECL_RESULT (fndecl) != error_mark_node)
10269   DECL_CONTEXT (DECL_RESULT (fndecl)) = fndecl;

whereas the RESULT_DECL has NULL for its DECL_CONTEXT.


On trying this patch:

--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -473,6 +473,7 @@ new_function (location *loc,
   DECL_ARTIFICIAL (resdecl) = 1;
   DECL_IGNORED_P (resdecl) = 1;
   DECL_RESULT (fndecl) = resdecl;
+  DECL_CONTEXT (resdecl) = fndecl;

   if (builtin_id)
 {

then remap_gimple_stmt in libgccjit correctly remaps the stmt to:

(gdb) call debug ($21)
D.88 = *ptr_2(D);

and I correctly get this output from the libgccjit testcase:

get_a() is 1

i.e. the above patch seems to fix it.

I'm running some more thorough tests.

Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

[Jonathan Wakely via Gcc-patches]

On Fri, 10 Dec 2021 at 16:35, Martin Sebor  wrote:
>
> On 12/10/21 3:12 AM, Jonathan Wakely wrote:
> > On Fri, 10 Dec 2021 at 01:50, Martin Sebor via Libstdc++
> >  wrote:
> >>
> >> On 12/9/21 5:38 PM, Martin Sebor wrote:
> >>> On 12/9/21 4:24 PM, Jonathan Wakely via Gcc-patches wrote:
>  These warnings are triggered by perfectly valid code using std::string.
>  They're particularly bad when --enable-fully-dynamic-string is used,
>  because even std::string().begin() will give a warning.
> 
>  Use pragmas to stop the troublesome warnings for copies done by
>  std::char_traits.
> >>>
> >>> I'm still experimenting with some of the approaches we discussed
> >>> last week, but based on my findings so far this was going to be
> >>> my suggestion at lest for now, until or unless the problem turns
> >>> out to affect more code than just std::string.
> >>
> >> Just minutes after I wrote this I tried following the clue
> >> in the note printed for the test case from PR 103534 with
> >> an enhancement I'm experimenting with:
> >>
> >> /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:426:56:
> >> warning: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’
> >> specified size between 18446744073709551600 and 18446744073709551615
> >> exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
> >> 426 | return static_cast(__builtin_memcpy(__s1,
> >> __s2, __n));
> >> |
> >> ^
> >> /build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:426:56:
> >> note: when
> >> ‘(.std::__cxx11::basic_string::_M_string_length >
> >> 18446744073709551599)’
> >>
> >> and adding an assert to string::size():
> >>
> >> constexpr
> >> size_type
> >> size() const noexcept
> >> {
> >>   if (_M_string_length >= -1LU >> 1)
> >
> > I think that will be wrong for 64-bit Windows, where long is 32-bit,
> > but the string's max size is closer to -1LLU >> 2, and we don't want
> > to just use -1LLU because that's wrong for 32-bit targets.
> >
> > Technically the max size is (N - 1)/2 where N is the allocator's max
> > size, which is PTRDIFF_MAX for std::allocator, SIZE_MAX for allocators
> > that use the default value from std::allocator_traits, or some other
> > value that the allocator defines. And the value is reduced
> > appropriately if sizeof(char_type) > 1.
> >
> > But if we call this->max_size() which calls _Alloc_traits::max_size()
> > which potentially calls allocator_type::max_size(), will the compiler
> > actually make those calls to mark the path unreachable, or will it
> > just ignore the unreachable if it can't fold all those calls at
> > compile time?
>
> The above was just a quick proof of concept experiment.  You're
> of course right that the final solution can't be so crude(*).
> But if the required functions are always_inline (I think member
> functions defined in the body of the class implicitly are) then

They're implicitly inline, but not implicitly always_inline.

> I'd expect them to be folded at compile time at all optimization
> levels.  That's what makes -Winvalid-memory-order work in C++
> even at -O0 in the patch I posted earlier this week.
>
> If I still remember my C++-library-fu, even though the standard
> requires containers to call max_size() etc., since std::string
> is (or can be) an explicit specialization, there shouldn't be
> a way for a conforming program to find out if it does, so it
> could take shortcuts.  That makes me wonder if it could even
> call malloc instead of operator new to get around the problem
> with the operator's replaceability.

std::string is required to use std::allocator and users can't
specialize that to observe its allocations, but it does require:

The storage for the array is obtained by calling ::operator new
(17.6.3), but it is unspecified when or how often this function is
called.

Users can certainly observe whether std::string *never* calls their
replaced operator new (and if they've replaced it specifically to
ensure allocations use their own source, and not malloc, they wouldn't
be happy).

[pushed] c++: Add test for C++23 auto(x)

[Marek Polacek via Gcc-patches]

I was curious if our auto(x) works in contexts like bit-field width
and similar.  It appears that it does.  Might be worth adding a test
for it.

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

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/auto-fncast10.C: New test.
---
 gcc/testsuite/g++.dg/cpp23/auto-fncast10.C | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp23/auto-fncast10.C

diff --git a/gcc/testsuite/g++.dg/cpp23/auto-fncast10.C 
b/gcc/testsuite/g++.dg/cpp23/auto-fncast10.C
new file mode 100644
index 000..29c779b2cb4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp23/auto-fncast10.C
@@ -0,0 +1,18 @@
+// { dg-do compile { target c++23 } }
+
+struct S {
+  int i1 : auto(12);
+  int i2 : auto{12};
+  static constexpr auto x = auto(12);
+  static constexpr auto y = auto{12};
+};
+
+struct R {
+  int i;
+};
+
+static constexpr R r1 = { auto(23) };
+static constexpr R r2 = { auto{23} };
+enum E { X = auto(12), Y = auto{1u} };
+static_assert (auto(true));
+static_assert (auto{true});

base-commit: 982a2c9b7866558039df61b0596caad57c94c8c4
-- 
2.33.1