[Bug c++/106179] [13 Regression] Rejected code since r13-1390-g07ac550393d00fca

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

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

--- Comment #5 from Jason Merrill  ---
*** Bug 106178 has been marked as a duplicate of this bug. ***

[Bug c++/106178] [13 Regression] Rejected code with "is private within this context" since r13-1390-g07ac550393d00fca

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jason Merrill  ---
Dup, fixed.  Note that there's no reason to use a template-id when naming a
destructor, just the name is enough.

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

[Bug c++/105626] -Wformat should accept u8"" strings

[drepper.fsp+rhbz at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Ulrich Drepper  ---
(In reply to Marek Polacek from comment #5)
> Fixed for GCC 13.  I could probably backport to GCC 12, if desirable.

Thanks.  And I certainly would appreciate a backport since this is an annoying
warning in some of my projects.

[Bug c++/106179] [13 Regression] Rejected code since r13-1390-g07ac550393d00fca

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/106024] [11/12/13 Regression] ICE on missing template keyword in template method call in pack expansion

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

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

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

https://gcc.gnu.org/g:656c0212909bc91b1025aa12774d981adb531b4c

commit r13-1516-g656c0212909bc91b1025aa12774d981adb531b4c
Author: Jason Merrill 
Date:   Tue Jul 5 17:05:47 2022 -0400

c++: dependent conversion operator lookup [PR106179]

This testcase demonstrates that my assumption that we would only be
interested in a class template lookup if the template-id is followed by ::
was wrong.

PR c++/106179
PR c++/106024

gcc/cp/ChangeLog:

* parser.cc (cp_parser_lookup_name): Remove :: requirement
for using unqualified lookup result.

gcc/testsuite/ChangeLog:

* g++.dg/template/operator16.C: New test.

[Bug c++/106179] [13 Regression] Rejected code since r13-1390-g07ac550393d00fca

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

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

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

https://gcc.gnu.org/g:656c0212909bc91b1025aa12774d981adb531b4c

commit r13-1516-g656c0212909bc91b1025aa12774d981adb531b4c
Author: Jason Merrill 
Date:   Tue Jul 5 17:05:47 2022 -0400

c++: dependent conversion operator lookup [PR106179]

This testcase demonstrates that my assumption that we would only be
interested in a class template lookup if the template-id is followed by ::
was wrong.

PR c++/106179
PR c++/106024

gcc/cp/ChangeLog:

* parser.cc (cp_parser_lookup_name): Remove :: requirement
for using unqualified lookup result.

gcc/testsuite/ChangeLog:

* g++.dg/template/operator16.C: New test.

[Bug c++/106211] New: Rejects valid with function template with non-deduced parameters from deduced parameters of another function template

[davidfromonline at gmail dot com via Gcc-bugs]

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

Bug ID: 106211
   Summary: Rejects valid with function template with non-deduced
parameters from deduced parameters of another function
template
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: davidfromonline at gmail dot com
  Target Milestone: ---

The following valid translation unit

```
template
concept any = true;

void f() {
[](Ts...) {
return [](any auto..., auto) {};
}(0)(0, 0);
}
```

is rejected by gcc with the error message:

```
: In function 'void f()':
:7:13: error: no match for call to '(f()) (int, int)'
5 | [](Ts...) {
  | ~~~
6 | return [](any auto..., auto) {};
  | 
7 | }(0)(0, 0);
  | ^~
:6:24: note: candidate: 'template 
requires (... && any) f()'
6 | return [](any auto..., auto) {};
  |^
:6:24: note:   template argument deduction/substitution failed:
:7:13: note:   candidate expects 1 argument, 2 provided
5 | [](Ts...) {
  | ~~~
6 | return [](any auto..., auto) {};
  | 
7 | }(0)(0, 0);
  | ^~
Compiler returned: 1
```

See it live: https://godbolt.org/z/c7zxWEbxM

[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found

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

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

--- Comment #37 from Andrew Pinski  ---
(In reply to Vincent Lefèvre from comment #36)
> An alternative solution: for programs that are known to potentially fail due
> to built libraries and LD_LIBRARY_PATH, GCC could define wrappers that clean
> up LD_LIBRARY_PATH before executing the real program.

That should not be too hard to do as GCC already does that while building for
as and sometimes ld, see gcc/exec-tool.in. It is mostly for while building
binutils and GCC together (which is supported still).

[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #36 from Vincent Lefèvre  ---
An alternative solution: for programs that are known to potentially fail due to
built libraries and LD_LIBRARY_PATH, GCC could define wrappers that clean up
LD_LIBRARY_PATH before executing the real program.

[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #35 from Vincent Lefèvre  ---
And since the title of this bug was changed to mention that this is related to
the GNU gold linker, there is a runpath bug in this linker that might affect
libtool (perhaps causing it to use LD_LIBRARY_PATH?):

  https://sourceware.org/bugzilla/show_bug.cgi?id=13764

(I reported it in 2012, with Jonathan Nieder's patch to fix it, but after 10
years, there is still no reaction from the developers!)

So you may want to try this patch to see if this solves the issue.

[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found

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

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

--- Comment #34 from Andrew Pinski  ---
(In reply to Vincent Lefèvre from comment #33)
> (In reply to Andrew Pinski from comment #32)
> > The runpath won't work because the libraries are installed yet.
> 
> This is what libtool does for GNU MPFR, and this works fine. For instance,
> when building test programs, I can see:
> 
>   -Wl,-rpath -Wl,/home/vinc17/software/mpfr/src/.libs
> 
> so that it doesn't need to change LD_LIBRARY_PATH. (The test programs don't
> need to be installed, so that using the path to the build directory will not
> yield any issue, but AFAIK, if need be, libtool supports relinking of
> programs to be installed.)

Relinking is a no go really for GCC as far as I know. Especially when you might
build as one user and install as another (root); relinking causes so many
issues in the past too.

[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #33 from Vincent Lefèvre  ---
(In reply to Andrew Pinski from comment #32)
> The runpath won't work because the libraries are installed yet.

This is what libtool does for GNU MPFR, and this works fine. For instance, when
building test programs, I can see:

  -Wl,-rpath -Wl,/home/vinc17/software/mpfr/src/.libs

so that it doesn't need to change LD_LIBRARY_PATH. (The test programs don't
need to be installed, so that using the path to the build directory will not
yield any issue, but AFAIK, if need be, libtool supports relinking of programs
to be installed.)

[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

--- Comment #32 from Andrew Pinski  ---
(In reply to Vincent Lefèvre from comment #21)
> But perhaps that instead, a run path should be used
> together with --disable-new-dtags (so that it overrides the user's
> LD_LIBRARY_PATH).

The runpath won't work because the libraries are installed yet.

This is whole forward vs backward compatibility issue really.

libstdc++ is backwards compatible but not forwards compatible. Note Ada
front-end has already a similar issue too.

I don't see a way of fixing this without breaking everything.

[Bug target/106180] [13 Regression] ICE in extract_insn, at recog.cc:2791 since r13-1418-g73f942c08deef3

[haochen.jiang at intel dot com via Gcc-bugs]

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

--- Comment #4 from Haochen Jiang  ---
Created attachment 53261
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53261=edit
This patch aims to handle memory issue when unpacking in cvtps2pd

I am trying to solve this ICE problem with this patch in this case and
regtested on x86_64-pc-linux-gnu.
I believe that  this is logically correct. Although it seems a little bit
complicated than previous pattern.
BTW, I plan to fix all that pattern if this patch is ok.

[Bug libstdc++/97936] [11/12 Regression] 30_threads/latch/3.cc hangs

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

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

Thomas Rodgers  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #20 from Thomas Rodgers  ---
Solaris uses the non-futex wait/notify path. There has been a recent PR opened
indicating a likely algorithmic issue with the non-futex implementation.

See - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106183

I am going to re-open this issue while I investigate the new report.

[Bug target/106165] incorrect result when using inlined asm implementation of floor() on i686

[xeioexception at gmail dot com via Gcc-bugs]

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

--- Comment #5 from xeioex  ---
My question is more practical. For example while `-fexcess-precision=standard`
fixes the problem in GCC. But, I am left with the same problem regarding other
compilers. At least am looking for a way to detect excessive precision as soon
as possible (during configure time).

Tried to use FLT_EVAL_METHOD

t.c
```
#include 
#include 
#include 
#include 

int main(){
  printf("%d\n", (int) FLT_EVAL_METHOD);
}
```

1) gcc -o t t.c && ./t
2

2) gcc -fexcess-precision=standard -o t t.c && ./t
2


How am I expected to use FLT_EVAL_METHOD correctly?

[Bug target/106165] incorrect result when using inlined asm implementation of floor() on i686

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to xeioex from comment #3)
> Is there a portable (across platforms and compilers) to ensure that double
> values are always 64 bits?

It is still 64bit storage on i686, just uses the excessive precission while
doing calculations.
You should read "What Every Computer Scientist Should Know About Floating-Point
Arithmetic": https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf about
this and all.

[Bug target/106165] incorrect result when using inlined asm implementation of floor() on i686

[xeioexception at gmail dot com via Gcc-bugs]

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

--- Comment #3 from xeioex  ---
Is there a portable (across platforms and compilers) to ensure that double
values are always 64 bits?

Re: Possible gcc bug

[Marek Polacek via Gcc-bugs]

On Wed, Jul 06, 2022 at 10:15:51AM +1000, Norman wrote:
> Hi all,
> 
> Consider this bit of code:
> 
> unsigned int d=1,e=2,f;
> 
>     if((d-e) < 0)
>     {
>     f=d-e;
>     printf("f=%i",f);
>     }
> 
> gcc  -Wall -DLinux -D_FILE_OFFSET_BITS=64 -c scroll.c
> 
> gcc compiles this without a whimper.
> 
> However the expression (d-e) < 0 always evaluates to false (0). gcc type
> casts (d-e) as unsigned.

You need to include -Wextra to get the warning.

Marek

Possible gcc bug

[Norman]

Hi all,

Consider this bit of code:

unsigned int d=1,e=2,f;

    if((d-e) < 0)
    {
    f=d-e;
    printf("f=%i",f);
    }

gcc  -Wall -DLinux -D_FILE_OFFSET_BITS=64 -c scroll.c

gcc compiles this without a whimper.

However the expression (d-e) < 0 always evaluates to false (0). gcc type 
casts (d-e) as unsigned.


Also the assignment f=d-e; probably should not be allowed.

I would have expected  warnings from gcc at least.

For your consideration,

Regards,

Norman Davis

[Bug libstdc++/106183] std::atomic::wait might fail to be unblocked by notify_one/all on platforms without platform_wait()

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

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

Thomas Rodgers  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-07-06
 Status|UNCONFIRMED |ASSIGNED

[Bug tree-optimization/106199] [12 Regression] incorrect warning: memcpy writing 1 or more bytes into a region of size 0 overflows the destination with std::vector::insert

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|incorrect memcpy writing 1  |[12 Regression] incorrect
   |or more bytes into a region |warning: memcpy writing 1
   |of size 0 overflows the |or more bytes into a region
   |destination with|of size 0 overflows the
   |std::vector::insert .   |destination with
   ||std::vector::insert
   Target Milestone|--- |12.2

[Bug tree-optimization/106199] incorrect memcpy writing 1 or more bytes into a region of size 0 overflows the destination with std::vector::insert .

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization
Summary|vector::insert optimization |incorrect memcpy writing 1
   |is broken with gcc-12   |or more bytes into a region
   ||of size 0 overflows the
   ||destination with
   ||std::vector::insert .

--- Comment #4 from Andrew Pinski  ---
/opt/compiler-explorer/gcc-trunk-20220705/include/c++/13.0.0/bits/stl_algobase.h:431:30:
error: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' writing
1 or more bytes into a region of size 0 overflows the destination
[-Werror=stringop-overflow=]

[Bug rtl-optimization/106210] [10/11/12/13 Regression] missing shrink wrap for simple case

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #2 from Andrew Pinski  ---
Note the following is still shink wrapped on x86_64 but is not on aarch64 (the
only difference is using double instead of int) and it broke in GCC 6 for
aarch64 just as the int case:


double f(double );

double advance(double dz)
{
int dz1;
if (dz > 0)
return (dz + dz) * dz;
else
return dz * f(dz);
}

[Bug rtl-optimization/106210] [10/11/12/13 Regression] missing shrink wrap for simple case

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|missing shrink wrap for |[10/11/12/13 Regression]
   |simple case |missing shrink wrap for
   ||simple case
  Known to fail||9.1.0
  Known to work||5.4.0
   Target Milestone|--- |10.5

--- Comment #1 from Andrew Pinski  ---
This is interesting because for aarch64 the shrink wrapping started to fail in
GCC 6 while for x86_64, the shrink wrapping started to fail in GCC 9 (most
likely due to r265398).

[Bug rtl-optimization/106210] New: missing shrink wrap for simple case

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

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

Bug ID: 106210
   Summary: missing shrink wrap for simple case
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*-* x86_64-*-*

Take:
```
int f(int);

int advance(int dz)
{
int dz1;
if (dz > 0)
return (dz + dz) * dz;
else
return dz * f(dz);
}
```
I would have expected this to be shrink wrapped but it is not.

[Bug tree-optimization/106200] Shrink-wrapping opportunity releated to function call

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 53260
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53260=edit
full testcase

[Bug c++/105626] -Wformat should accept u8"" strings

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed for GCC 13.  I could probably backport to GCC 12, if desirable.

[Bug c++/105626] -Wformat should accept u8"" strings

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

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:543828e79bfa63ef26b11a2c9ea81fd7905f33aa

commit r13-1511-g543828e79bfa63ef26b11a2c9ea81fd7905f33aa
Author: Marek Polacek 
Date:   Tue Jul 5 14:22:26 2022 -0400

c-family: Prevent -Wformat warnings with u8 strings [PR105626]

The  thread
seems to have concluded that -Wformat shouldn't warn about

  printf((const char*) u8"test %d\n", 1);

saying "format string is not an array of type 'char'".  This code
is not an aliasing violation, and there are no I/O functions for u8
strings, so the const char * cast is OK and shouldn't be disregarded.

PR c++/105626

gcc/c-family/ChangeLog:

* c-format.cc (check_format_arg): Don't emit -Wformat warnings with
u8 strings.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wformat-char8_t-1.C: New test.

[Bug c++/106179] [13 Regression] Rejected code since r13-1390-g07ac550393d00fca

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
The P1787 scope/lookup overhaul clarified that Mat_ in .operator Mat_ is looked
up in the same way as a name mentioned immediately after the ., and since
commaInitializer has dependent type _Tp, we don't know whether "Mat_" is
supposed to name a member type of _Tp or the Mat_ in the enclosing scope, so we
don't know if it's a template.  Except that it has to be a type, so it has to
be a template.  So yes, it should work.

As should this:

template  struct Mat {
  Mat();
};

//template  struct Mat_;  
template  Mat<_Tp>::Mat() {
  auto commaInitializer = _Tp().operator Mat_<_Tp>();
}

struct A
{
  template  struct Mat_ { };
  template  operator Mat_();
};

Mat m;

[Bug fortran/106049] ICE in gfc_simplify_pack, at fortran/simplify.cc:6481

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-July/057990.html

[Bug fortran/106049] ICE in gfc_simplify_pack, at fortran/simplify.cc:6481

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> Maybe there is a better solution.

Here's an alternative, probably more general approach that modifies
is_constant_array_expr: when the array size - as implied by the shape -
is larger than zero, but the constructor is empty, then something went
wrong, and we return false:

diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index ab59fbca622..fb725994653 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -233,6 +233,18 @@ is_constant_array_expr (gfc_expr *e)
   if (e->expr_type != EXPR_ARRAY || !gfc_is_constant_expr (e))
 return false;

+  /* A non-zero-sized constant array shall have a non-empty constructor.  */
+  if (e->rank > 0 && e->shape != NULL && e->value.constructor == NULL)
+{
+  mpz_init_set_ui (size, 1);
+  for (int j = 0; j < e->rank; j++)
+   mpz_mul (size, size, e->shape[j]);
+  bool not_size0 = (mpz_cmp_si (size, 0) != 0);
+  mpz_clear (size);
+  if (not_size0)
+   return false;
+}
+
   for (c = gfc_constructor_first (e->value.constructor);
c; c = gfc_constructor_next (c))
 if (c->expr->expr_type != EXPR_CONSTANT

This seems to regtest OK.

[Bug analyzer/106204] False positive from -Wanalyzer-use-of-uninitialized-value with -ftrivial-auto-var-init=zero

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from David Malcolm  ---
I'm testing a fix.

[Bug analyzer/106181] [13 Regression] ICE in capacity_compatible_with_type, at analyzer/region-model.cc:2909

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

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

--- Comment #2 from Tim Lange  ---
Posted a fix to the mailing list here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597871.html

[Bug fortran/106209] ICE in add_init_expr_to_sym, at fortran/decl.cc:2132

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-07-05
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||kargl at gcc dot gnu.org
   Priority|P3  |P4

--- Comment #1 from kargl at gcc dot gnu.org ---
Instead of an assert(), simply return false to give gfortran a chance to emit
an error.

% gfcx -c a.f90
a.f90:3:4:

3 |integer, parameter :: b(*) = a
  |1
Error: Unclassifiable statement at (1)
a.f90:2:29:

2 |integer, parameter :: a(:) = 0
  | 1
Error: Parameter array 'a' at (1) cannot be automatic or of deferred shape

diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index bd586e75008..cec178fc80b 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2129,7 +2129,9 @@ add_init_expr_to_sym (const char *name, gfc_expr **initp,
locus *var_locus)
  /* The shape may be NULL for EXPR_ARRAY, set it.  */
  if (init->shape == NULL)
{
- gcc_assert (init->expr_type == EXPR_ARRAY);
+ if (init->expr_type != EXPR_ARRAY)
+   return false;
+
  init->shape = gfc_get_shape (1);
  if (!gfc_array_size (init, >shape[0]))
  gfc_internal_error ("gfc_array_size failed");

[Bug c++/106202] internal compiler error: in move_fn_p, at cp/decl.cc:14907

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-07-05
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Confirmed:

/usr/include/c++/12/concepts:304:17: internal compiler error: in move_fn_p, at
cp/decl.cc:15025
  304 |   { __t <  __u } -> __boolean_testable;
  | ^
0xc3cd2a move_fn_p(tree_node const*)
/home/mpolacek/src/gcc/gcc/cp/decl.cc:15025
0xb1c640 perfect_candidate_p
/home/mpolacek/src/gcc/gcc/cp/call.cc:6029
0xb1cf68 add_candidates
/home/mpolacek/src/gcc/gcc/cp/call.cc:6219
0xb1d309 add_operator_candidates
/home/mpolacek/src/gcc/gcc/cp/call.cc:6370
0xb1d93b add_operator_candidates
/home/mpolacek/src/gcc/gcc/cp/call.cc:6470
0xb1de58 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
/home/mpolacek/src/gcc/gcc/cp/call.cc:6593
0xf1f882 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
/home/mpolacek/src/gcc/gcc/cp/typeck.cc:4565
0xe59db9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:20468
0xe56178 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:19626
0xba9f00 tsubst_valid_expression_requirement
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:1924
0xbaa4fe tsubst_compound_requirement
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:2051
0xbaaa64 tsubst_requirement
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:2159
0xbab026 tsubst_requires_expr
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:2282
0xbab113 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:2301
0xe5f8fb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:21522
0xe56178 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:19626
0xbad2dd satisfy_atom
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:2954
0xbad6ee satisfy_constraint_r
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:3020
0xbac267 satisfy_conjunction
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:2720
0xbad684 satisfy_constraint_r
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:3016

[Bug c++/106205] ICE: canonical types differ for identical types 'int()' and 'int()'

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-05
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug analyzer/106206] [12/13 Regression] ICE: canonical types differ for identical types 'int(...)' and 'int(...)'

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c++ |analyzer
   Priority|P3  |P2
 Ever confirmed|0   |1
   Target Milestone|--- |12.2
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2022-07-05
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

--- Comment #1 from Marek Polacek  ---
Confirmed.

Started with r12-1931-ge61ffa201403e3:

commit e61ffa201403e3814a43b176883e176716b1492f
Author: David Malcolm 
Date:   Wed Jun 30 09:39:04 2021 -0400

analyzer: eliminate enum binding_key [PR95006]

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test

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

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #14 from John David Anglin  ---
Yes.

[Bug c++/106207] [11/12/13 Regression] ICE in apply_fixit, at edit-context.cc:769

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

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
  Component|c   |c++
   Target Milestone|--- |11.4
 Ever confirmed|0   |1
   Last reconfirmed||2022-07-05
 CC||mpolacek at gcc dot gnu.org
   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Marek Polacek  ---
Started with my r11-4756-g5b2003105b35f8.  Probably a latent issue though.

[Bug fortran/106209] New: ICE in add_init_expr_to_sym, at fortran/decl.cc:2132

[gscfq--- via Gcc-bugs]

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

Bug ID: 106209
   Summary: ICE in add_init_expr_to_sym, at fortran/decl.cc:2132
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   integer, parameter :: a(:) = 0
   integer, parameter :: b(*) = a
end


$ cat z2.f90
program p
   integer, parameter :: a(:) = 0
   integer, parameter :: b(*) = [a]
end


$ gfortran-13-20220703 -c z1.f90
f951: internal compiler error: in add_init_expr_to_sym, at fortran/decl.cc:2132
0x6e225e add_init_expr_to_sym
../../gcc/fortran/decl.cc:2132
0x6ebe06 variable_decl
../../gcc/fortran/decl.cc:3120
0x6ebe06 gfc_match_data_decl()
../../gcc/fortran/decl.cc:6319
0x757723 match_word
../../gcc/fortran/parse.cc:67
0x757723 decode_statement
../../gcc/fortran/parse.cc:378
0x75916a next_free
../../gcc/fortran/parse.cc:1397
0x75916a next_statement
../../gcc/fortran/parse.cc:1629
0x75a6fb parse_spec
../../gcc/fortran/parse.cc:4168
0x75d89c parse_progunit
../../gcc/fortran/parse.cc:6210
0x75ef61 gfc_parse_file()
../../gcc/fortran/parse.cc:6755
0x7acb3f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug fortran/106208] New: [12/13 Regression] ICE in branch_prob, at profile.cc:1459

[gscfq--- via Gcc-bugs]

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

Bug ID: 106208
   Summary: [12/13 Regression] ICE in branch_prob, at
profile.cc:1459
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 2024 and 20211121,
with file gfortran.dg/coarray/registering_1.f90 :
(gcc configured with --enable-checking=yes)


$ gfortran-13-20220703 -c registering_1.f90 -ftest-coverage -fcoarray=lib
during IPA pass: profile
registering_1.f90:11:4:

   11 | use m
  |^
internal compiler error: in branch_prob, at profile.cc:1459
0xdca3c3 branch_prob(bool)
../../gcc/profile.cc:1459
0xf8f060 tree_profiling
../../gcc/tree-profile.cc:782
0xf8f060 execute
../../gcc/tree-profile.cc:888

[Bug c/106207] New: [11/12/13 Regression] ICE in apply_fixit, at edit-context.cc:769

[gscfq--- via Gcc-bugs]

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

Bug ID: 106207
   Summary: [11/12/13 Regression] ICE in apply_fixit, at
edit-context.cc:769
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r11 between 20201018 and 20201108,
and file gcc.dg/tree-ssa/pr77644.c :


$ g++-13-20220703 -c pr77644.c -ftrack-macro-expansion=0
-fdiagnostics-generate-patch
pr77644.c: In function 'int f_f1(float, float)':
pr77644.c:22:1: warning: empty parentheses were disambiguated as a function
declaration [-Wvexing-parse]
   22 | GEN_FOO(float, f)
  | ^~~
pr77644.c:22:1: note: remove parentheses to default-initialize a variable
   22 | GEN_FOO(float, f)
  | ^~~
  | ---
pr77644.c:22:1: note: or replace parentheses with braces to value-initialize a
variable
pr77644.c: In function 'int f_f2(float, float)':
pr77644.c:22:1: warning: empty parentheses were disambiguated as a function
declaration [-Wvexing-parse]
pr77644.c:22:1: note: remove parentheses to default-initialize a variable
   22 | GEN_FOO(float, f)
  | ^~~
  | ---

pr77644.c:22:1: internal compiler error: in apply_fixit, at edit-context.cc:769
0x1b6c4f0 edited_line::apply_fixit(int, int, char const*, int)
../../gcc/edit-context.cc:769
0x1b6d306 edit_context::add_fixits(rich_location*)
../../gcc/edit-context.cc:232
0x1b60344 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.cc:1580
0x1b6069a diagnostic_impl
../../gcc/diagnostic.cc:1712
0x1b61f89 inform(rich_location*, char const*, ...)
../../gcc/diagnostic.cc:1804
0x7ddf27 warn_about_ambiguous_parse
../../gcc/cp/parser.cc:22338
0x81e50a cp_parser_init_declarator
../../gcc/cp/parser.cc:22618
0x7fbb82 cp_parser_simple_declaration
../../gcc/cp/parser.cc:15336
0x7fd429 cp_parser_declaration_statement
../../gcc/cp/parser.cc:14417
0x7fda0b cp_parser_statement
../../gcc/cp/parser.cc:12494
0x7fe9d4 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12906
0x7fea8f cp_parser_compound_statement
../../gcc/cp/parser.cc:12858
0x81d5e8 cp_parser_function_body
../../gcc/cp/parser.cc:25205
0x81d5e8 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.cc:25256
0x81daa6 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:31404
0x81ec29 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.cc:31321
0x81ec29 cp_parser_init_declarator
../../gcc/cp/parser.cc:22658
0x7fbb82 cp_parser_simple_declaration
../../gcc/cp/parser.cc:15336
0x824958 cp_parser_declaration
../../gcc/cp/parser.cc:15022
0x825232 cp_parser_translation_unit
../../gcc/cp/parser.cc:5018

[Bug c++/106206] New: [12/13 Regression] ICE: canonical types differ for identical types 'int(...)' and 'int(...)'

[gscfq--- via Gcc-bugs]

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

Bug ID: 106206
   Summary: [12/13 Regression] ICE: canonical types differ for
identical types 'int(...)' and 'int(...)'
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210627 and 20210704, with file g++.dg/abi/covariant3.C :
(gcc configured with --enable-checking=yes)


$ gcc-11 -c covariant3.C -O2 -fprofile-arcs -fanalyzer
$
$ gcc-13-20220703 -c covariant3.C -O2 -fprofile-arcs -fanalyzer
during IPA pass: analyzer
cc1plus: internal compiler error: canonical types differ for identical types
'int(...)' and 'int(...)'
0xa4d28c comptypes(tree_node*, tree_node*, int)
../../gcc/cp/typeck.cc:1560
0xa4c0a4 structural_comptypes
../../gcc/cp/typeck.cc:1463
0xa4d240 comptypes(tree_node*, tree_node*, int)
../../gcc/cp/typeck.cc:1553
0xa4c0a4 structural_comptypes
../../gcc/cp/typeck.cc:1463
0xa4d240 comptypes(tree_node*, tree_node*, int)
../../gcc/cp/typeck.cc:1553
0x7c8fe8 cxx_types_compatible_p(tree_node*, tree_node*)
../../gcc/cp/cp-objcp-common.cc:126
0xaf3842 c_fold_indirect_ref_for_warn
../../gcc/c-family/c-pretty-print.cc:1834
0xaf3b65 c_fold_indirect_ref_for_warn
../../gcc/c-family/c-pretty-print.cc:1902
0xaf3b65 c_fold_indirect_ref_for_warn
../../gcc/c-family/c-pretty-print.cc:1902
0xaf4e8c print_mem_ref
../../gcc/c-family/c-pretty-print.cc:1964
0x8491cc expr_to_string(tree_node*)
../../gcc/cp/error.cc:3289
0x849b8c cp_printer
../../gcc/cp/error.cc:4458
0x2179080 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.cc:1475
0x151db3a ana::evdesc::event_desc::formatted_print(char const*, ...) const
../../gcc/analyzer/pending-diagnostic.cc:114
0x20e3b96 ana::warning_event::get_desc(bool) const
../../gcc/analyzer/checker-path.cc:1136
0x20e35a2 ana::checker_event::prepare_for_emission(ana::checker_path*,
ana::pending_diagnostic*, diagnostic_event_id_t)
../../gcc/analyzer/checker-path.cc:237
0x2103d48 ana::checker_path::prepare_for_emission(ana::pending_diagnostic*)
../../gcc/analyzer/checker-path.h:652
0x2103d48 ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&)
../../gcc/analyzer/diagnostic-manager.cc:1396
0x2104861 ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
../../gcc/analyzer/diagnostic-manager.cc:1296
0x2104861 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
../../gcc/analyzer/diagnostic-manager.cc:1348

[Bug c++/106205] New: ICE: canonical types differ for identical types 'int()' and 'int()'

[gscfq--- via Gcc-bugs]

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

Bug ID: 106205
   Summary: ICE: canonical types differ for identical types
'int()' and 'int()'
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 (with -std=c++11) :
(gcc configured with --enable-checking=yes)


$ cat z1.cc
template a b() { return a(); };
struct t
{
  void f() { for (t c : b); };
};


$ gcc-13-20220703 -c z1.cc
z1.cc:1:29: error: parameter packs not expanded with '...':
1 | template a b() { return a(); };
  | ^
z1.cc:1:29: note: 'a'
z1.cc: In function 'int b()':
z1.cc:1:40: error: parameter packs not expanded with '...':
1 | template a b() { return a(); };
  |^~~
z1.cc:1:40: note: 'a'
z1.cc: In member function 'void t::f()':
z1.cc:4:25: internal compiler error: canonical types differ for identical types
'int()' and 'int()'
4 |   void f() { for (t c : b); };
  | ^
0xa4d28c comptypes(tree_node*, tree_node*, int)
../../gcc/cp/typeck.cc:1560
0x751425 resolve_address_of_overloaded_function
../../gcc/cp/class.cc:8547
0x7473d6 reference_binding
../../gcc/cp/call.cc:1722
0x747bc2 initialize_reference(tree_node*, tree_node*, int, int)
../../gcc/cp/call.cc:13073
0x7eafb6 grok_reference_init
../../gcc/cp/decl.cc:6017
0x7eafb6 check_initializer
../../gcc/cp/decl.cc:7312
0x8199c6 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.cc:8443
0x9066e9 cp_convert_range_for(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int, bool, unsigned short)
../../gcc/cp/parser.cc:13876
0x90f462 cp_parser_range_for
../../gcc/cp/parser.cc:13676
0x94d42e cp_parser_for
../../gcc/cp/parser.cc:13533
0x94d42e cp_parser_iteration_statement
../../gcc/cp/parser.cc:14162
0x920f14 cp_parser_statement
../../gcc/cp/parser.cc:12337
0x922364 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12906
0x922447 cp_parser_compound_statement
../../gcc/cp/parser.cc:12858
0x949fc0 cp_parser_function_body
../../gcc/cp/parser.cc:25205
0x949fc0 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.cc:25256
0x94a63a cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:31404
0x94a9e8 cp_parser_late_parsing_for_member
../../gcc/cp/parser.cc:32371
0x91bf12 cp_parser_class_specifier
../../gcc/cp/parser.cc:26326
0x91d4fc cp_parser_type_specifier
../../gcc/cp/parser.cc:19411

[Bug c++/99310] [11/12/13 Regression] ICE: canonical types differ for identical types 'void (A::)(void*)' and 'void (A::)(void*)'

[gscfq--- via Gcc-bugs]

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

--- Comment #5 from G. Steinmetz  ---

ICE is reproducible with e.g. -march=nano-x2 or -march=nano-x4
(gcc configured with --enable-checking=yes)

$ gcc-13-20220703 -c pr39060.C -march=nano-x2
...
pr39060.C:19:15: internal compiler error: canonical types differ for identical
types 'void (A::)(void*)' and 'void (A::)(void*)'
   19 | A::A (void* i=) {}  // { dg-error "primary-expression|argument" }
  |   ^
0xa4d28c comptypes(tree_node*, tree_node*, int)
../../gcc/cp/typeck.cc:1560
0x7fa24c duplicate_decls(tree_node*, tree_node*, bool, bool)
../../gcc/cp/decl.cc:2470
0x6bc66f grokfndecl
../../gcc/cp/decl.cc:10580
...

[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found

[aros at gmx dot com via Gcc-bugs]

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

--- Comment #31 from Artem S. Tashkinov  ---
And one final tidbit, `make LD=ld.bfd install prefix=/tmp/GCC-11.3` fails:

make[3]: Entering directory '/tmp/OBJDIR/libcc1'
make[3]: Nothing to be done for 'install-exec-am'.
 /usr/bin/mkdir -p '/tmp/GCC-11.3/lib/../lib64'
 /bin/sh ./libtool   --mode=install /usr/bin/install -c   libcc1.la
'/tmp/GCC-11.3/lib/../lib64'
libtool: install: error: cannot install `libcc1.la' to a directory not ending
in /opt/gcc/lib/../lib64
make[3]: *** [Makefile:496: install-cc1libLTLIBRARIES] Error 1
make[3]: Leaving directory '/tmp/OBJDIR/libcc1'
make[2]: *** [Makefile:690: install-am] Error 2
make[2]: Leaving directory '/tmp/OBJDIR/libcc1'
make[1]: *** [Makefile:15937: install-libcc1] Error 2
make[1]: Leaving directory '/tmp/OBJDIR'
make: *** [Makefile:2483: install] Error 2

[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found

[aros at gmx dot com via Gcc-bugs]

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

--- Comment #30 from Artem S. Tashkinov  ---
I'm not sure why certain headers file in the resulting build have changed:

diff -urN gcc/lib/gcc/x86_64-pc-linux-gnu/11/include/omp.h
gcc.123/lib/gcc/x86_64-pc-linux-gnu/11/include/omp.h
--- gcc/lib/gcc/x86_64-pc-linux-gnu/11/include/omp.h2022-07-05 18:10:45 UTC
+++ gcc.gold/lib/gcc/x86_64-pc-linux-gnu/11/include/omp.h   2022-05-22
10:48:25 UTC
@@ -46,8 +46,8 @@

 typedef struct
 {
-  unsigned char _x[12] 
-__attribute__((__aligned__(4)));
+  unsigned char _x[16] 
+__attribute__((__aligned__(8)));
 } omp_nest_lock_t;
 #endif

diff -urN gcc/lib/gcc/x86_64-pc-linux-gnu/11/plugin/include/auto-host.h
gcc.123/lib/gcc/x86_64-pc-linux-gnu/11/plugin/include/auto-host.h
--- gcc/lib/gcc/x86_64-pc-linux-gnu/11/plugin/include/auto-host.h  
2022-07-05 18:10:46 UTC
+++ gcc.gold/lib/gcc/x86_64-pc-linux-gnu/11/plugin/include/auto-host.h 
2022-05-22 10:48:13 UTC
@@ -1662,7 +1662,7 @@

 /* Define if your linker supports -z bndplt */
 #ifndef USED_FOR_TARGET
-#define HAVE_LD_BNDPLT_SUPPORT 1
+/* #undef HAVE_LD_BNDPLT_SUPPORT */
 #endif


@@ -1687,7 +1687,7 @@

 /* Define to the level of your linker's compressed debug section support. */
 #ifndef USED_FOR_TARGET
-#define HAVE_LD_COMPRESS_DEBUG 3
+#define HAVE_LD_COMPRESS_DEBUG 2
 #endif


@@ -1765,7 +1765,7 @@

 /* Define if your linker supports --push-state/--pop-state */
 #ifndef USED_FOR_TARGET
-#define HAVE_LD_PUSHPOPSTATE_SUPPORT 1
+/* #undef HAVE_LD_PUSHPOPSTATE_SUPPORT */
 #endif


@@ -2326,7 +2326,7 @@

 /* Specify plugin linker */
 #ifndef USED_FOR_TARGET
-#define PLUGIN_LD_SUFFIX "ld.bfd"
+#define PLUGIN_LD_SUFFIX "ld"
 #endif

[Bug analyzer/105888] RFE: -fanalyzer should complain when an on-stack address escapes/outlives the function

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

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

--- Comment #3 from Tim Lange  ---
(In reply to Tim Lange from comment #2)
> I do have a fast prototype of this feature, but polishing that would require
> PR105888 first. I plan to work on other checkers and get more familiar with
> the code first, and then tackling PR105888 and hence this PR.

I obviously meant PR106203 :)

[Bug analyzer/105888] RFE: -fanalyzer should complain when an on-stack address escapes/outlives the function

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

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

Tim Lange  changed:

   What|Removed |Added

 CC||tlange at gcc dot gnu.org

--- Comment #2 from Tim Lange  ---
I do have a fast prototype of this feature, but polishing that would require
PR105888 first. I plan to work on other checkers and get more familiar with the
code first, and then tackling PR105888 and hence this PR.

[Bug analyzer/106204] False positive from -Wanalyzer-use-of-uninitialized-value with -ftrivial-auto-var-init=zero

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-07-05
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Affects trunk and GCC 12 branch.

https://godbolt.org/z/P1x4fMr1E

[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found

[aros at gmx dot com via Gcc-bugs]

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

Artem S. Tashkinov  changed:

   What|Removed |Added

Summary|Cannot build GCC 11.3 on|GCC 11.3 doesn't build with
   |Fedora 36   |the GNU gold linker
   ||(version 2.37-27.fc36)
   ||1.16: libstdc++.so.6:
   ||version `GLIBCXX_3.4.30'
   ||not found

--- Comment #29 from Artem S. Tashkinov  ---
OK, it all works this way:

make LD=ld.bfd

GCC 11.3 build system is incompatible with the GNU gold linker. I've changed
the bug report title to reflect this.

Please, fix it for 11.4 or at least leave a note on your website.

[Bug analyzer/106204] New: False positive from -Wanalyzer-use-of-uninitialized-value with -ftrivial-auto-var-init=zero

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

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

Bug ID: 106204
   Summary: False positive from
-Wanalyzer-use-of-uninitialized-value with
-ftrivial-auto-var-init=zero
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

I'm seeing a lot of false positives from -Wanalyzer-use-of-uninitialized-value
when building the upstream Linux kernel.

Seems to be a bad interaction with -ftrivial-auto-var-init=zero; minimal
reproducer:

$ cat ../../src/hooks.c
int foo(unsigned *len);
int test()
{
 unsigned len;
 int rc;

 rc = foo();
 if (!rc)
  rc = len;
 return rc;
}

$ ./xgcc -B. ../../src/hooks.c -ftrivial-auto-var-init=zero -fanalyzer -S 
../../src/hooks.c: In function ‘test’:
../../src/hooks.c:4:11: warning: use of uninitialized value ‘’
[CWE-457] [-Wanalyzer-use-of-uninitialized-value]
4 |  unsigned len;
  |   ^~~
  ‘test’: event 1
|
|4 |  unsigned len;
|  |   ^~~
|  |   |
|  |   (1) use of uninitialized value ‘’ here
|

where the uninit is being reported on the assignment to "len = _1;" here:

  _1 = .DEFERRED_INIT (4, 2, &"len"[0]);
  len = _1;

[Bug analyzer/106203] New: Allow to emit diagnostics at return edges for the exit point as well as the call site

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

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

Bug ID: 106203
   Summary: Allow to emit diagnostics at return edges for the exit
point as well as the call site
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: tlange at gcc dot gnu.org
  Target Milestone: ---

Currently, the region_model_context at return edges, created inside
program_state::on_edge, neither holds a stmt nor a stmt_finder and thus,
warnings at return edges are rejected by impl_region_model_context::warn.

PR105900 has 2 XFAILs inside allocation-size-(1|2).c because the call to
set_value (lhs, ) happens at a return edge. Similarly, PR105888
also needs to emit a warning at a return edge, but for the callee's exit point.

David already expressed ideas on how to solve this:
- have two contexts for pop_frame: one in the old frame, the other in
the new frame (for the caller)
- generalize stmt_finder, so it can also update the supernode to use
- rework pop_frame (I've had to do this before, I've run into issues
like this before).

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

[aros at gmx dot com via Gcc-bugs]

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

--- Comment #28 from Artem S. Tashkinov  ---
(In reply to Jonathan Wakely from comment #27)
> (In reply to Artem S. Tashkinov from comment #25)
> > Can you please try with the script I posted in comment #4?
> 
> That works fine on F35 and F36.

I've just tried again, the result is the same. I have 100% standard Fedora 36
(sans a few custom environment variables defined - see below, nothing GCC
related) with all the updates installed.

The below commands are all run under the root user (not sudo, an actual login
under root).

# md5sum gcc-11.3.0.tar.xz 
4ee3e8c4c99e7b3444eb79f00f5f7a7e  gcc-11.3.0.tar.xz

# ld --version
GNU gold (version 2.37-27.fc36) 1.16

# gcc --version
gcc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1)

# ./build.sh
... skipped ...
libtool: compile:  /tmp/OBJDIR/./gcc/xgcc -shared-libgcc -B/tmp/OBJDIR/./gcc
-nostdinc++ -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/x86_64-pc-linux-gnu/bin/ -B/opt/gcc/x86_64-pc-linux-gnu/lib/
-isystem /opt/gcc/x86_64-pc-linux-gnu/include -isystem
/opt/gcc/x86_64-pc-linux-gnu/sys-include -fno-checking -m32
-I/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/include
-I/tmp/gcc-11.3.0/libstdc++-v3/libsupc++ -std=gnu++98 -fPIC -DPIC
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=compatibility.lo -g -O2 -pipe -mtune=generic -D_GNU_SOURCE -m32
-fcf-protection -mshstk -c
/tmp/gcc-11.3.0/libstdc++-v3/src/c++98/compatibility.cc -o compatibility.o
>/dev/null 2>&1
/bin/sh ../libtool --tag CXX   --mode=link /tmp/OBJDIR/./gcc/xgcc
-shared-libgcc -B/tmp/OBJDIR/./gcc -nostdinc++
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/x86_64-pc-linux-gnu/bin/ -B/opt/gcc/x86_64-pc-linux-gnu/lib/
-isystem /opt/gcc/x86_64-pc-linux-gnu/include -isystem
/opt/gcc/x86_64-pc-linux-gnu/sys-include -fno-checking  -m32  -Wl,-O1
-Wl,-z,relro -Wl,--gc-sections  -std=gnu++98 -fPIC -DPIC
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=libstdc++.la  '-m32' -o libstdc++.la -version-info 6:29:0
-Wl,--version-script=libstdc++-symbols.ver -lm  -rpath /opt/gcc/lib/../lib
compatibility.lo compatibility-debug_list.lo compatibility-debug_list-2.lo 
compatibility-c++0x.lo compatibility-atomic-c++0x.lo
compatibility-thread-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo 
 ../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la
../src/c++11/libc++11convenience.la ../src/c++17/libc++17convenience.la
../src/c++20/libc++20convenience.la 
libtool: link: /tmp/OBJDIR/./gcc/xgcc -shared-libgcc -B/tmp/OBJDIR/./gcc
-nostdinc++ -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/x86_64-pc-linux-gnu/bin/ -B/opt/gcc/x86_64-pc-linux-gnu/lib/
-isystem /opt/gcc/x86_64-pc-linux-gnu/include -isystem
/opt/gcc/x86_64-pc-linux-gnu/sys-include -fno-checking  -m32  -fPIC -DPIC
-D_GLIBCXX_SHARED -shared -nostdlib /lib/../lib/crti.o
/tmp/OBJDIR/./gcc/32/crtbeginS.o  .libs/compatibility.o
.libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o
.libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o
.libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o
.libs/compatibility-condvar.o  -Wl,--whole-archive
../libsupc++/.libs/libsupc++convenience.a
../src/c++98/.libs/libc++98convenience.a
../src/c++11/.libs/libc++11convenience.a
../src/c++17/.libs/libc++17convenience.a
../src/c++20/.libs/libc++20convenience.a -Wl,--no-whole-archive 
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src
-L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs -lm
-L/tmp/OBJDIR/./gcc/32 -L/lib/../lib -L/usr/lib/../lib -L/tmp/OBJDIR/./gcc -lc
-lgcc_s /tmp/OBJDIR/./gcc/32/crtendS.o /lib/../lib/crtn.o  -m32 -Wl,-O1 -Wl,-z
-Wl,relro -Wl,--gc-sections -m32 -Wl,--version-script=libstdc++-symbols.ver  
-Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.29
/usr/bin/ld:
/tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version
`GLIBCXX_3.4.30' not found (required by /usr/bin/ld)
collect2: error: ld returned 1 exit status
make[10]: *** [Makefile:732: libstdc++.la] Error 1
make[10]: Leaving directory
'/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src'
make[9]: *** [Makefile:765: all-recursive] Error 1
make[9]: Leaving directory

[Bug target/105854] ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints: sse2_lshrv1ti3)

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:02e2e15ec4b610c0f5c73e1db424b1bbc65dd39a

commit r13-1508-g02e2e15ec4b610c0f5c73e1db424b1bbc65dd39a
Author: Roger Sayle 
Date:   Tue Jul 5 18:00:00 2022 +0100

UNSPEC_PALIGNR optimizations and clean-ups on x86.

This patch is a follow-up to Hongtao's fix for PR target/105854.  That
fix is perfectly correct, but the thing that caught my eye was why is
the compiler generating a shift by zero at all.  Digging deeper it
turns out that we can easily optimize __builtin_ia32_palignr for
alignments of 0 and 64 respectively, which may be simplified to moves
of the highpart and lowpart respectively.

After adding optimizations to simplify the 64-bit DImode palignr, I
started to add the corresponding optimizations for vpalignr (i.e.
128-bit).  The first oddity is that sse.md uses TImode and a special
SSESCALARMODE iterator, rather than V1TImode, and indeed the comment
above SSESCALARMODE hints that this should be "dropped in favor of
VIMAX_AVX2_AVX512BW".  Hence this patch includes the migration of
_palignr to use VIMAX_AVX2_AVX512BW, basically
using V1TImode instead of TImode for 128-bit palignr.

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-,32},
with no new failures.  Ok for mainline?

2022-07-05  Roger Sayle  
Hongtao Liu  

gcc/ChangeLog
* config/i386/i386-builtin.def (__builtin_ia32_palignr128): Change
CODE_FOR_ssse3_palignrti to CODE_FOR_ssse3_palignrv1ti.
* config/i386/i386-expand.cc (expand_vec_perm_palignr): Use
V1TImode
and gen_ssse3_palignv1ti instead of TImode.
* config/i386/sse.md (SSESCALARMODE): Delete.
(define_mode_attr ssse3_avx2): Handle V1TImode instead of TImode.
(_palignr): Use VIMAX_AVX2_AVX512BW as a mode
iterator instead of SSESCALARMODE.
(ssse3_palignrdi): Optimize cases where operands[3] is 0 or 64,
using a single move instruction (if required).

gcc/testsuite/ChangeLog
* gcc.target/i386/ssse3-palignr-2.c: New test case.

[Bug rtl-optimization/96692] Failure to optimize xor+or+xor to andnot+xor

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

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

commit r13-1507-gd458c53a6f37c8c49aa854d12e6867b4d914555f
Author: Roger Sayle 
Date:   Tue Jul 5 17:55:53 2022 +0100

PR rtl-optimization/96692: ((A|B)^C)^A using andn with -mbmi on x86.

This patch addresses PR rtl-optimization/96692 on x86_64, by providing
a set of combine splitters to convert the three operation ((A|B)^C)^D
into a two operation sequence using andn when either A or B is the same
register as C or D.  This is essentially a reassociation problem that's
only a win if the target supports an and-not instruction (as with -mbmi).

Hence for the new test case:

int f(int a, int b, int c)
{
return (a ^ b) ^ (a | c);
}

GCC on x86_64-pc-linux-gnu wth -O2 -mbmi would previously generate:

xorl%edi, %esi
orl %edx, %edi
movl%esi, %eax
xorl%edi, %eax
ret

but with this patch now generates:

andn%edx, %edi, %eax
xorl%esi, %eax
ret

2022-07-05  Roger Sayle  
Uroš Bizjak  

gcc/ChangeLog
PR rtl-optimization/96692
* config/i386/i386.md (define_split): Split ((A | B) ^ C) ^ D
as (X & ~Y) ^ Z on target BMI when either C or D is A or B.

gcc/testsuite/ChangeLog
PR rtl-optimization/96692
* gcc.target/i386/bmi-andn-4.c: New test case.

[Bug c++/106202] New: internal compiler error: in move_fn_p, at cp/decl.cc:14907

[h2+bugs at fsfe dot org via Gcc-bugs]

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

Bug ID: 106202
   Summary: internal compiler error: in move_fn_p, at
cp/decl.cc:14907
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: h2+bugs at fsfe dot org
  Target Milestone: ---

Created attachment 53259
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53259=edit
backtrace

ICE when using generated comparison operators. 

Ubuntu 22.04
g++ (Ubuntu 11.2.0-19ubuntu1) 11.2.0
g++-12 (Ubuntu 12-20220319-1ubuntu1) 12.0.1 20220319 (experimental) [master
r12-7719-g8ca61ad148f]

[Bug middle-end/106199] vector::insert optimization is broken with gcc-12

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|libstdc++   |middle-end

--- Comment #3 from Jonathan Wakely  ---
No, optimization is not broken. It's a bogus warning, that's all.

[Bug c++/105626] -Wformat should accept u8"" strings

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-05
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #3 from Marek Polacek  ---
Sure, I'll post the patch and we'll see what happens.

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

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

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

--- Comment #27 from Jonathan Wakely  ---
(In reply to Artem S. Tashkinov from comment #25)
> Can you please try with the script I posted in comment #4?

That works fine on F35 and F36.

[Bug c++/94894] Premature instantiation of conversion function template during overload resolution

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||redi at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-07-05

--- Comment #1 from Jonathan Wakely  ---
>From PR libstdc++/106201:

struct foo
{
  template
foo(const T&) { }
};

struct bar { };

struct baz
{
  template baz(const T&) { }
};

void f(foo&);
void f(baz);

int main()
{
  bar b;
  f(b);
}

G++ goes into infinite recursion, Clang, EDG and MSVC accept it.

That was reduced from one using concepts:

namespace effing
{
  template
concept effable = requires (T& t) { f(t); };

  template 
requires effable || true
  void eff(T&&) { }
}

struct path {
  template path(const T&) { }
};

void f(path&);

struct iterator { };

int main()
{
  iterator i;
  effing::eff(i);
}

[Bug libstdc++/106201] filesystem::directory_iterator is a borrowable range?

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Depends on||94894

--- Comment #4 from Jonathan Wakely  ---
It looks like this is PR c++/94894 but we'll need a workaround in the library
for now.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94894
[Bug 94894] Premature instantiation of conversion function template during
overload resolution

[Bug tree-optimization/106186] [13 regression] Recent change causing target regressions for uninitialized objects

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

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

--- Comment #9 from Aldy Hernandez  ---
(In reply to Jeffrey A. Law from comment #8)
> Just glad it's fixed.  I hope my bisection didn't waste too much of anyone's
> time.

Heh, not mine.  It was unlikely it was the nonzero bit patch as that just
provides core infrastructure that still isn't used.  I suppose I could've
messed something else in the intersect/union code, but I assumed it wasn't that
patch.  Not to say, it couldn't be some other part of ranger in another patch
:).

Anywhoo...thanks to Richard for fixing this.

[Bug tree-optimization/106186] [13 regression] Recent change causing target regressions for uninitialized objects

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

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

--- Comment #8 from Jeffrey A. Law  ---
Just glad it's fixed.  I hope my bisection didn't waste too much of anyone's
time.

[Bug libstdc++/106201] filesystem::directory_iterator is a borrowable range?

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

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

--- Comment #3 from Jonathan Wakely  ---
Reduced to not use concepts:

struct foo
{
  template
foo(const T&) { }
};

struct bar { };

struct baz
{
  template baz(const T&) { }
};

void f(foo&);
void f(baz, ...);

int main()
{
  bar b;
  f(b);
}

G++ goes into infinite recursion, Clang, EDG and MSVC accept it.

[Bug libstdc++/106201] filesystem::directory_iterator is a borrowable range?

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> The third one fails but not because of anything to do with borrowable
> ranges. The problem is that the filesystem::swap(path&, path&) overload is
> found by ADL and considered by overload resolution when checking whether
> counted_iterator is swappable. Overload
> resolution checks whether the iterator can be converted to a path, which
> causes constraint recursion.

The full explanation is that views::take creates a view whose iterator is
counted_iterator and the constraints for
ranges::for_each check that that iterator is copyable, movable, and swappable.
That fails with libstdc++:

#include 
#include 
using I = std::counted_iterator;
static_assert( std::swappable );

The swappable concept finds filesystem::swap(path&, path&) via ADL. Overload
resolution checks if counted_iterator can be
converted to path, which considers the path constructors, which checks if
counted_iterator is an iterator, which uses std::iterator_traits, which depends
on the iterator being copyable, which depends on it being swappable, and we're
recursing.

However, I *think* there's a compiler bug here. We should not be considering
constructors of path to see if we can get a path& lvalue. That would never
work, constructing a path would give us an rvalue. Clang compiles the example
when using libstdc++ headers.

Clang and EDG both compile this, but G++ doesn't:

namespace effing
{
  template
concept effable = requires (T& t) { f(t); };

  template 
requires effable || true
  void eff(T&&) { }
}

struct path {
  template path(const T&) { }
};

void f(path&);

struct iterator { };

int main()
{
  iterator i;
  effing::eff(i);
}

conv.C: In substitution of 'template  requires  effable
path::path(const T&) [with T = iterator]':
conv.C:4:42:   recursively required by substitution of 'template 
requires  effable path::path(const T&) [with T = iterator]'
conv.C:4:42:   required by substitution of 'template  requires
(effable) || true void effing::eff(T&&) [with T = iterator&]'
conv.C:22:14:   required from here
conv.C:4:13:   required for the satisfaction of 'effable' [with T =
iterator]
conv.C:4:23:   in requirements with 'T& t' [with T = iterator]
conv.C:4:23: error: satisfaction of atomic constraint 'requires(T& t) {f(t);}
[with T = T]' depends on itself
4 | concept effable = requires (T& t) { f(t); };
  |   ^

[Bug libstdc++/106201] filesystem::directory_iterator is a borrowable range?

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2022-07-05
   Keywords||rejects-valid
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Patrick Welche from comment #0)
> Oh: https://cplusplus.github.io/LWG/issue3480
> But: it says "could be fixed ... (as libstdc++ currently does anyway)"
> Issue looks resolved?

That ensures that directory iterators are ranges, which is what your second
for_each call depends on.

The third one fails but not because of anything to do with borrowable ranges.
The problem is that the filesystem::swap(path&, path&) overload is found by ADL
and considered by overload resolution when checking whether
counted_iterator is swappable. Overload
resolution checks whether the iterator can be converted to a path, which causes
constraint recursion.

The following change fixes this by removing filesystem::swap(path&, path&) from
the ADL result set:

--- a/libstdc++-v3/include/bits/fs_path.h
+++ b/libstdc++-v3/include/bits/fs_path.h
@@ -591,6 +591,8 @@ namespace __detail
   return __result;
 }

+friend void swap(path& __lhs, path& __rhs) noexcept { __lhs.swap(__rhs); }
+
   private:
 enum class _Type : unsigned char {
   _Multi = 0, _Root_name, _Root_dir, _Filename
@@ -732,8 +734,6 @@ namespace __detail
   /// @{
   /// @relates std::filesystem::path

-  inline void swap(path& __lhs, path& __rhs) noexcept { __lhs.swap(__rhs); }
-
   size_t hash_value(const path& __p) noexcept;

   /// @}

[Bug tree-optimization/106198] [13 Regression] 25_algorithms/find_end/constrained.cc ICEs in check_loop_closed_ssa_def

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug tree-optimization/106198] [13 Regression] 25_algorithms/find_end/constrained.cc ICEs in check_loop_closed_ssa_def

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:07dd0f7ba27d1fe9f0ce5b049ac5735dc5d361ad

commit r13-1505-g07dd0f7ba27d1fe9f0ce5b049ac5735dc5d361ad
Author: Richard Biener 
Date:   Tue Jul 5 14:14:49 2022 +0200

tree-optimization/106198 - CFG cleanup vs LC SSA

This is another case like PR106182 where for the 2nd testcase in
the bug there are no removed or discovered loops but still changing
loop exits invalidates LC SSA and it is not enough to just scan for
uses in the blocks that changed loop depth.  One might argue that
if we'd include former exit destinations we'd pick up the original
LC SSA use but for virtuals on block merging we'd have propagated
those out (while for regular uses we insert copies).  CFG cleanup
can also be entered with loops needing fixup so any heuristics
based on loop structure are bound to fail.

PR tree-optimization/106198
* tree-cfgcleanup.cc (repair_loop_structures): Always do a
full LC SSA rewrite but only if any blocks changed loop
depth.

* gcc.dg/pr106198.c: New testcase.

[Bug libstdc++/106201] New: filesystem::directory_iterator is a borrowable range?

[prlw1 at cam dot ac.uk via Gcc-bugs]

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

Bug ID: 106201
   Summary: filesystem::directory_iterator is a borrowable range?
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prlw1 at cam dot ac.uk
  Target Milestone: ---

In the following:

#include 
#include 
#include 
#include 

int main()
{
auto print = [](const auto& x) {std::cout << x << '\n';} ;

std::ranges::for_each(
std::views::iota(1) | std::views::take(5),
print
);

std::ranges::for_each(
std::filesystem::directory_iterator("/"),
print
);

std::ranges::for_each(
std::filesystem::directory_iterator("/") | std::views::take(3),
print
);  
}

the first two for_each clauses compile and execute correctly, even with g++
10.3.0.

Is my expectation that the third clause is valid incorrect?

(I just tried with today's head, g++ (GCC) 13.0.0 20220705 (experimental) and
it failed to compile.)

Oh: https://cplusplus.github.io/LWG/issue3480
But: it says "could be fixed ... (as libstdc++ currently does anyway)"
Issue looks resolved?
Thoughts?

[Bug rtl-optimization/106200] Shrink-wrapping opportunity releated to function call

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement
  Component|c   |rtl-optimization

[Bug c/106200] New: Shrink-wrapping opportunity releated to function call

[zhongyunde at huawei dot com via Gcc-bugs]

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

Bug ID: 106200
   Summary: Shrink-wrapping opportunity releated to function call
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

case:https://godbolt.org/z/sc5rTzaeb
```
double advance(double dt, double dx, double dy, double dz)
{
double dSquared = dx * dx + dy * dy + dz * dz;
double mag = dt / (dSquared * std::sqrt(dSquared));

return mag;
}
```

we can the llvm Shrink-wrapping, so the spill only in the branch where *call
sqrt*, so there is no spill if goto the branch where use the *insn fsqrt*.

[Bug c/12245] [10/11/12/13 regression] Uses lots of memory when compiling large initialized arrays

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

Carlos Galvez  changed:

   What|Removed |Added

 CC||carlosgalvezp at gmail dot com

--- Comment #82 from Carlos Galvez  ---
Hi,

This bug is still present in GCC 11.3.0. My use case is using large
std::arrays. NOTE: the problem immediately goes away if the arrays are not
initialized, but naturally we want to always initialize our variables to
prevent accessing uninitialized data:

-std::array data{};
+std::array data;

[Bug tree-optimization/106192] [11/12/13 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.cc:3522

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

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

--- Comment #3 from Michael Matz  ---
(In reply to Michael Matz from comment #2)
> see why it should be.  If GIMP_SIMD_LANE has properties that make this
> transformation invalid I would argue that those properties are correctly

"are _not_" I meant to say, of course.

> represented.

[Bug c++/105956] [13 Regression] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||byteslice at airmail dot cc

--- Comment #9 from Patrick Palka  ---
*** Bug 106152 has been marked as a duplicate of this bug. ***

[Bug c++/106152] New ICE compiling template expressions since r13-1045-gcb7fd1ea85feea7e

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Patrick Palka  ---
dup

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

[Bug tree-optimization/106192] [11/12/13 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.cc:3522

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

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

--- Comment #2 from Michael Matz  ---
Unroll-and-jam simply unrolls the outer loop and merged all resulting
inner-loop bodies.  In this situation we have (before unroll-and-jam):

outerloop(i_1) {
  _12 = i_1 <= 59
  innerloop(i_1, j by 1) {
.GOMP_SIMD_LANE (simduid.6_16(D), 0, _12);
... uninteresting things (j) ...
  }
}

Unroll-and-jam then simply does (that's the unrolling):

outerloop(i by 2) {
  _12 = i_1 <= 59
  innerloop(i_1, j by 1) {
.GOMP_SIMD_LANE (simduid.6_16(D), 0, _12);
... uninteresting things (i, j) ...
  }
  i_2 = i_1 + 1
  _15 = i_2 <= 59
  innerloop(i_2, j by 1) {
.GOMP_SIMD_LANE (simduid.6_16(D), 0, _15);
... uninteresting things (i + 1, j) ...
  }
}

and then fuses the two inner loops, which means that the instructions between
them (the original pre-header of the inner loop) become replicated inside
the new inner loop body (here, the loop-invariant condition):

outerloop(i by 2) {
  _12 = i_1 <= 59
  innerloop(i_1, j by 1) {
.GOMP_SIMD_LANE (simduid.6_16(D), 0, _12);
... uninteresting things (i, j) ...
i_2 = i_1 + 1
_15 = i_2 <= 59
.GOMP_SIMD_LANE (simduid.6_16(D), 0, _15);
... uninteresting things (i + 1, j) ...
  }
}

There is nothing which somehow would indicate that this is invalid, and I can't
see why it should be.  If GIMP_SIMD_LANE has properties that make this
transformation invalid I would argue that those properties are correctly
represented.  One could of course hack bb_prevents_fusion_p or
unroll_jam_possible_p to avoid this situation, but that would seem like a
bad hack, as random other CFG transformation might introduce similar things:
namely a GOMP_SIMD_LANE statement that's fed by an unhoisted loop-invariant
condition.

So, I'd argue the assert is too eager.

[Bug target/106180] [13 Regression] ICE in extract_insn, at recog.cc:2791 since r13-1418-g73f942c08deef3

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

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

--- Comment #3 from Jakub Jelinek  ---
That doesn't really matter, many instructions just use the g, q etc. modifiers
so that the correct Intel syntax is written, the RTL can have larger MEM just
fine, the only thing that is wrong is e.g. if the expander has V2SF operand to
widen it  to V4SF using a subreg.  But if you match an instruction that had
V4SF operand, the fact that you actually just read 8 bytes from it rather than
16 isn't that bad.  Especially for the unpacks which are paired, one hi and one
lo which together read the whole memory anyway.

[Bug tree-optimization/106186] [13 regression] Recent change causing target regressions for uninitialized objects

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Fixed.

[Bug tree-optimization/106186] [13 regression] Recent change causing target regressions for uninitialized objects

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-1503-gc3d2600cfb476e576fd27f3f29f49e968e86774d
Author: Richard Biener 
Date:   Tue Jul 5 11:38:52 2022 +0200

tree-optimization/106186 - propagate out virtual LC PHI nodes properly

The code to remove LC PHI nodes in clean_up_loop_closed_phi does not handle
virtual operands because may_propagate_copy generally returns false
for them.  The following copies the merge_blocks variant for
dealing with them.

This fixes a missed jump threading in gcc.dg/auto-init-uninit-4.c
which manifests in bogus uninit diagnostics.

PR tree-optimization/106186
* tree-ssa-propagate.cc (clean_up_loop_closed_phi):
Properly handle virtual PHI nodes.

[Bug tree-optimization/106198] [13 Regression] 25_algorithms/find_end/constrained.cc ICEs in check_loop_closed_ssa_def

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

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

--- Comment #3 from Richard Biener  ---
OK, that one is really the same as PR106182 but the fix there no longer works
(we don't remove a loop during fixup).

[Bug target/105928] [AArch64] 64-bit constants with same high/low halves can use ADD lsl 32 (-Os at least)

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||rsandifo at gcc dot gnu.org
   Last reconfirmed||2022-07-05
 Status|UNCONFIRMED |NEW

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Confirmed.

[Bug c++/98056] coroutines: ICE tree check: expected record_type or union_type or qual_union_type, have array_type since r11-2183-g0f66b8486cea8668

[charles at yubo dot live via Gcc-bugs]

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

--- Comment #20 from charles-yubo  ---
As seen in godbolt, https://godbolt.org/z/qKGdPv94r , it exists in 11.3 and
12.1 with new following message :
 error: array used as initializer

[Bug tree-optimization/106198] [13 Regression] 25_algorithms/find_end/constrained.cc ICEs in check_loop_closed_ssa_def

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Zhendong Su  changed:

   What|Removed |Added

 CC||zhendong.su at inf dot ethz.ch

--- Comment #2 from Zhendong Su  ---
Here is one:

[564] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers
--enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220705 (experimental) [master r13-1500-g510ac273a78] (GCC)
[565] %
[565] % gcctk -O3 small.c
during GIMPLE pass: unswitch
small.c: In function ‘main’:
small.c:5:5: internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.cc:717
5 | int main() {
  | ^~~~
0x76e5ab check_loop_closed_ssa_def
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:717
0x10572b4 check_loop_closed_ssa_bb
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:731
0x1058556 verify_loop_closed_ssa(bool, loop*)
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:767
0x1058556 verify_loop_closed_ssa(bool, loop*)
../../gcc-trunk/gcc/tree-ssa-loop-manip.cc:751
0xde6ac4 execute_function_todo
../../gcc-trunk/gcc/passes.cc:2109
0xde6f0b execute_todo
../../gcc-trunk/gcc/passes.cc:2145
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[566] %
[566] % cat small.c
int printf(const char *, ...);
long a;
int b;
volatile int c;
int main() {
  long e = a;
  int f = a;
 L:
  if (b > 0) {
printf("0");
goto L;
  }
  if (f) {
printf("%ld", (long)b);
goto L;
  }
  e >= b && c;
  return 0;
}

[Bug tree-optimization/106198] [13 Regression] 25_algorithms/find_end/constrained.cc ICEs in check_loop_closed_ssa_def

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

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

--- Comment #1 from Richard Biener  ---
reducing is slow but progressing, eventually fuzzers will find a simpler
duplicate as well ...

[Bug middle-end/106196] [13 Regression] vect_do_peeling ICE since g:3769ad4ccea9589b3f7edaef901cb542aa10f49a

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug middle-end/106196] [13 Regression] vect_do_peeling ICE since g:3769ad4ccea9589b3f7edaef901cb542aa10f49a

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-1502-g1a6e0d8252a71c61d4dc616044fb25b5ac2cfffb
Author: Richard Biener 
Date:   Tue Jul 5 10:43:42 2022 +0200

tree-optimization/106196 - properly update virtual SSA for vector stores

The following properly handles aggregate returns of the const marked
STORE_LANES internal function to update virtual SSA form on-the-fly
rather than relying on a costly virtual SSA rewrite.

PR tree-optimization/106196
* tree-vect-stmts.cc (vect_finish_stmt_generation): Properly
handle aggregate returns of calls for VDEF updates.

* gcc.dg/torture/pr106196.c: New testcase.

[Bug c++/106199] vector::insert optimization is broken with gcc-12

[hewillk at gmail dot com via Gcc-bugs]

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

康桓瑋  changed:

   What|Removed |Added

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

--- Comment #2 from 康桓瑋  ---
This may not be the dup of PR100366.

[Bug c++/106199] vector::insert optimization is broken with gcc-12

[hewillk at gmail dot com via Gcc-bugs]

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

康桓瑋  changed:

   What|Removed |Added

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

--- Comment #1 from 康桓瑋  ---
dup of PR100366

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

[Bug tree-optimization/100366] [11/12/13 Regression] spurious warning - std::vector::clear followed by std::vector::insert(vec.end(), ...) with -O2

[hewillk at gmail dot com via Gcc-bugs]

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

康桓瑋  changed:

   What|Removed |Added

 CC||hewillk at gmail dot com

--- Comment #13 from 康桓瑋  ---
*** Bug 106199 has been marked as a duplicate of this bug. ***

[Bug c++/106199] New: vector::insert optimization is broken with gcc-12

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 106199
   Summary: vector::insert optimization is broken with gcc-12
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

Example from
https://stackoverflow.com/questions/72867072/why-g12-vector-insert-optimization-breaks-code

#include 
#include 

std::vector s_to_bytes() {
  std::vector res;
  std::array s{};
  res.insert(res.begin(), s.begin(), s.end());
  return res;
}

https://godbolt.org/z/4YrzTso9o

[Bug tree-optimization/106157] [13 Regression] ICE verify_ssa failed since r13-1268-g8c99e307b20c502e

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

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

--- Comment #2 from Richard Biener  ---
the reduction probably ended up removing the initialization as that's not
needed to reproduce the ICE

[Bug d/106139] d: aggregate value used where floating point was expected

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #6 from Iain Buclaw  ---
Fix committed, and backported.

[Bug d/106139] d: aggregate value used where floating point was expected

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

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

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

https://gcc.gnu.org/g:0b909ae026e5aaf2ce42ef5c33128dbc06d29803

commit r10-10885-g0b909ae026e5aaf2ce42ef5c33128dbc06d29803
Author: Iain Buclaw 
Date:   Wed Jun 29 21:52:39 2022 +0200

d: Fix error: aggregate value used where floating point was expected

Casting from vector to static array is permitted, and the frontend
generates a reinterpret cast, but casting back the other way resulted in
an error.  This has been fixed to be properly handled in the code
generation pass of VectorExp, and the conversion for lvalue and rvalue
handling done in convert_expr and convert_for_rvalue respectively.

PR d/106139

gcc/d/ChangeLog:

* d-convert.cc (convert_expr): Handle casting from array to vector.
(convert_for_rvalue): Rewrite vector to array casts of the same
element type into a constructor.
(convert_for_assignment): Return calling convert_for_rvalue.
* dmd/expressionsem.c (ExpressionSemanticVisitor::visit): Run
semantic
on vector expression after lowering.
* expr.cc (ExprVisitor::visit (VectorExp *)): Handle generating a
vector expression from a static array.

gcc/testsuite/ChangeLog:

* gdc.dg/pr106139a.d: New test.
* gdc.dg/pr106139b.d: New test.
* gdc.dg/pr106139c.d: New test.
* gdc.dg/pr106139d.d: New test.
* gdc.test/fail_compilation/ice20264.d: New test.

(cherry picked from commit 488759b7ea16972c4dfbb62926cd71996b1f77a7)

[Bug tree-optimization/106186] [13 regression] Recent change causing target regressions for uninitialized objects

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
There's some extra CFG bits because of virtual operands on trunk:

   [local count: 39370534]:
  # .MEM_13 = PHI <.MEM_6(5)>
  goto ; [100.00%]

   [local count: 357913944]:
  # .MEM_12 = PHI <.MEM_6(4)>
:

   [local count: 397284478]:
  # .MEM_14 = PHI <.MEM_12(9), .MEM_13(6)>
:

the loop-end propagation of LC SSA PHIs doesn't work for those - I'm going to
fix that which also seems to fix the missed jump threading.

[Bug tree-optimization/106186] [13 regression] Recent change causing target regressions for uninitialized objects

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*

--- Comment #4 from Richard Biener  ---
Btw, also seen on x86_64-linux.

[Bug tree-optimization/106186] [13 regression] Recent change causing target regressions for uninitialized objects

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-07-05
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
On the gcc 12 branch we optimize the use of rprio away in DSE5 (which just
collects unused SSA names).  The DOM3 pass via its EVRP use optimizes the
if (rprio != 1) check there which is what no longer happens on trunk.

So it's likely indeed ranger related.

[Bug tree-optimization/106157] [13 Regression] ICE verify_ssa failed since r13-1268-g8c99e307b20c502e

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

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

--- Comment #1 from Aldy Hernandez  ---
Silly question...

In the lto1 that ICEs, we have the following in
a.ltrans0.ltrans.094t.fixup_cfg3 (i.e. before DOM even comes into the picture):

  // Local variable
  struct VideoFrame videoFrame;
...
...
...
   [local count: 1073741824]:
  _5 = MEM[(struct VideoThumbnailer *)this_1(D)].m_MaintainAspectRatio;
  _6 = (int) _5;
  _7 = MEM[(struct VideoThumbnailer *)this_1(D)].m_ThumbnailSize;
  _12 = [(struct VideoFrame &)].frameData;
  __pos_13 = MEM[(struct vector *) + 8B].D.4741._M_impl._M_start;
  _14 = MEM[(struct vector *) + 8B].D.4741._M_impl._M_finish;
  if (__pos_13 != _14)
goto ; [70.00%]
  else
goto ; [30.00%]

Aren't we reading from videoFrame before it's set?

[Bug tree-optimization/106198] [13 Regression] 25_algorithms/find_end/constrained.cc ICEs in check_loop_closed_ssa_def

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-07-05
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED