[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure

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

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

--- Comment #16 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #15)
> We totally missed the jump threading of 3->5->7 path and the 4->5->8 path.

  FAIL: path through PHI in bb8 (incoming bb:6) crosses loop

But but, it does not exactly cross the loop as 5 (6) is not part of the loop
but rather just 8.

[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure

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

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

--- Comment #15 from Andrew Pinski  ---
So the major difference comes from mark_stack_region_used.
We have a missing jump thread in ethread.

Before the patch, ethread was able to jump thread all the way through:
  if (_13 != 0)
goto ; [5.50%]
  else
goto ; [94.50%]

   :
  # _22 = PHI <0(2)>
  goto ; [INV]

   :
  # _18 = PHI <1(2)>
  _15 = upper_bound.coeffs[0];
  goto ; [100.00%]

   :

But after we get:

   :
  _13 = upper_bound.coeffs[1];
  if (_13 != 0)
goto ; [5.50%]
  else
goto ; [94.50%]

   :
  # _22 = PHI <0(2)>
  goto ; [100.00%]

   :
  # _9 = PHI <1(2)>
  _15 = upper_bound.coeffs[0];

   :
  # _16 = PHI <0(3), 1(4)>
  # const_upper_20 = PHI 
  if (_16 != 0)
goto ; [INV]
  else
goto ; [INV]

We totally missed the jump threading of 3->5->7 path and the 4->5->8 path.

Aldy,
  Can you look into why there is a missing jump threading there?

[Bug middle-end/102566] [i386] GCC should emit LOCK BTS for simple bit-test-and-set operations with std::atomic

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #28 from Hongtao.liu  ---
Can be optimize

int gomp_futex_wake = FUTEX_WAKE | FUTEX_PRIVATE_FLAG;
int gomp_futex_wait = FUTEX_WAIT | FUTEX_PRIVATE_FLAG;

void
gomp_mutex_lock_slow (gomp_mutex_t *mutex, int oldval)
{
  /* First loop spins a while.  */
  while (oldval == 1)
{
  if (do_spin (mutex, 1))
{
  /* Spin timeout, nothing changed.  Set waiting flag.  */
  oldval = __atomic_exchange_n (mutex, -1, MEMMODEL_ACQUIRE);
  if (oldval == 0)
return;
  futex_wait (mutex, -1);
  break;
}
  else
{
  /* Something changed.  If now unlocked, we're good to go.  */
  oldval = 0;
  if (__atomic_compare_exchange_n (mutex, , 1, false,
   MEMMODEL_ACQUIRE, MEMMODEL_RELAXED))
return;
}
}

  /* Second loop waits until mutex is unlocked.  We always exit this
 loop with wait flag set, so next unlock will awaken a thread.  */
  while ((oldval = __atomic_exchange_n (mutex, -1, MEMMODEL_ACQUIRE)))
do_wait (mutex, -1);
}

with _atomic_fetch_or/and/xor ?

[Bug fortran/100910] Bind(c): errors handling long double complex

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||sandra at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from sandra at gcc dot gnu.org ---
This is fixed now.  There is adequate test coverage in the c-interop testsuite;
typecodes-array-longdouble.f90 and typecodes-scalar-longdouble.f90.

[Bug fortran/100915] Bind(c): failure handling C_FUNPTR

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||sandra at gcc dot gnu.org

--- Comment #5 from sandra at gcc dot gnu.org ---
Marking this as fixed now.

[Bug fortran/100911] Bind(c): failure handling C_PTR

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
 CC||sandra at gcc dot gnu.org

--- Comment #5 from sandra at gcc dot gnu.org ---
Fixed now, closing.

[Bug fortran/100914] Bind(c): errors handling complex

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from sandra at gcc dot gnu.org ---
I think it's safe to close this issue now.  The testcase is in and still passes
after Tobias's changes.

[Bug libstdc++/102882] [AIX] 23_containers 96088 testsuite failures

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

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-22

--- Comment #3 from David Edelsohn  ---
The patch for unordered_set fixes that testcase.

[Bug c++/102508] ICE on coroutine when awaiting inside a statement expression (in transform_local_var_uses, at cp/coroutines.cc:2102)

[kacper.slominski72 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Kacper Słomiński  ---
Was about to report this myself; here is a minimal test case that reproduces
this issue without using any external libraries. It causes a slightly different
ICE in gimplify_expr in gimplify.c:14879 for GCC 11.2, but with small tweaks
you can get the one in transform_local_var_uses as well:

#include 

struct coro {
bool await_ready() { return true; }
void await_suspend(std::coroutine_handle<>) { }
int await_resume() { return 0; }

struct promise_type {
coro get_return_object() {
return {};
}

std::suspend_never initial_suspend() {
return {};
}

std::suspend_never final_suspend() noexcept {
return {};
}

template 
void return_value(T &&) {}

void unhandled_exception() {}
};
};

coro fn() { co_return 1; };

coro foo() {
({
auto ex = co_await fn();
co_return ex;
});
co_return 0;
}

[Bug fortran/100916] Bind(c): CFI_type_other unimplemented.

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #5 from sandra at gcc dot gnu.org ---
Jose's test case for this issue is still failing.

[Bug fortran/100907] Bind(c): failure handling wide character

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #9 from sandra at gcc dot gnu.org ---
Jose's test case for this issue is still failing.

[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #51649|0   |1
is obsolete||

--- Comment #14 from Andrew Pinski  ---
Created attachment 51650
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51650=edit
Little more reduced

So FRE is able to figure out for the following:
  # _20 = PHI <0(2), 1(3)>
  # const_upper_26 = PHI 

  # _30 = PHI <0(12), 1(13)>
  # const_upper_33 = PHI 

That _30 is the same as _20 but not _26 is the same as _33 even though it does
figure out that _19 and _29 are the same as _10. If it is able to figure that
out, then things would just work.

Richi,
  I assume FRE does not Value number default SSA names (non-parm) the same
which is why this is happening is that correct?

[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #51648|0   |1
is obsolete||

--- Comment #13 from Andrew Pinski  ---
Created attachment 51649
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51649=edit
Reduced testcase

Reduced testcast attached, 68 lines. Which should be easier to figure out what
is going on.

[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure

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

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

--- Comment #12 from Andrew Pinski  ---
So this is definitely a bad interaction between complete unrolling where we
had:
for (unsigned int i = 1; i < 2; i++)
  if (this->coeffs[1] != 0)
 return false;

And jump threading.

I am still reducing the testcase but at least I figured out this part of it.

[Bug libffi/102874] [12 regression] src/x86/win64.S doesn't assemble with Solaris as

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #4 from H.J. Lu  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> > --- Comment #2 from H.J. Lu  ---
> > Does libffi 3.4.2 work on Solaris?  If yes, why doesn't it work in gcc?
> 
> It does when gcc is configured with gas, but doesn't when configured
> with /bin/as.
> 
> > If no, please fix the upstream and backport the fix.
> 
> Done: https://github.com/libffi/libffi/issues/665.
> 
> Depending on how this goes upstream, we may need a local fix: leaving
> gcc master broken on Solaris/x86 isn't an option!

The goal is to fix libffi in both upstream and GCC.  Please do

1. Create a pull request to fix libffi upstream.
2. Submit the proposed fix to GCC.
3. After the proposed is checked into GCC, add it to libffi/LOCAL_PATCHES
so that we keep it in GCC until it is fixed in upstream and synced.

If libffi upstream is fixed before the proposed fix is checked into GCC,
you can cherry-pick the fix from libffi upstream without touching
libffi/LOCAL_PATCHES.

[Bug fortran/101337] gfortran doesn't diagnose all operands with constraint violations

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

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

--- Comment #1 from sandra at gcc dot gnu.org ---
This is likely a "won't fix" bug, but I'll leave it open for now.  The test
cases (now committed) are still XFAILed.

[Bug fortran/101334] gfortran fails to enforce C838 on disallowed uses of assumed-rank variable names + bogus errors

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from sandra at gcc dot gnu.org ---
This has been fixed.

[Bug fortran/54753] assumed-rank dummies: Reject assumed-size actuals in in some cases (C535c; in F2018: C839)

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from sandra at gcc dot gnu.org ---
This has been fixed except for the problem with deallocation/initialization of
assumed-rank arrays now being tracked separately in PR102641.

[Bug libffi/102874] [12 regression] src/x86/win64.S doesn't assemble with Solaris as

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from H.J. Lu  ---
> Does libffi 3.4.2 work on Solaris?  If yes, why doesn't it work in gcc?

It does when gcc is configured with gas, but doesn't when configured
with /bin/as.

> If no, please fix the upstream and backport the fix.

Done: https://github.com/libffi/libffi/issues/665.

Depending on how this goes upstream, we may need a local fix: leaving
gcc master broken on Solaris/x86 isn't an option!

[Bug fortran/101333] gfortran fails to enforce C711 on assumed-type actual arguments

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from sandra at gcc dot gnu.org ---
This has been fixed.

[Bug fortran/101320] Bind(C): Missing diagnostic for constraint C1557 on allocatable/pointer arguments

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from sandra at gcc dot gnu.org ---
This has been fixed.

[Bug fortran/101319] Missing diagnostic for argument with type parameters for assumed-type dummy

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from sandra at gcc dot gnu.org ---
This has been fixed.

[Bug tree-optimization/102888] New: missing case for combining / and % into one operation

[vanyacpp at gmail dot com via Gcc-bugs]

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

Bug ID: 102888
   Summary: missing case for combining / and % into one operation
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

Normally GCC combines a/b and a%b into one operation when they are computed in
the same basic-block. The example below has two functions. For one GCC is able
to combine the operations and for other not (presumably because of complicated
control-flow). I believe the two functions are functionally equivalent. 

unsigned long long reduce(unsigned long long a, unsigned long long b)
{
while ((a % b) == 0)
a /= b;

return a;
}

unsigned long long reduce_opt(unsigned long long a, unsigned long long b)
{
for (;;)
{
unsigned long long quot = a / b;
unsigned long long rem = a % b;
if (rem != 0)
break;
a = quot;
}

return a;
}

reduce.L3:
mov rax, r8
xor edx, edx
div rsi
xor edx, edx
mov r8, rax
div rsi
testrdx, rdx
je  .L3

reduce_opt.L8:
xor edx, edx
mov r8, rax
div rsi
testrdx, rdx
je  .L8

https://godbolt.org/z/9dqs8avE5

It would be great if GCC generated the same code for both of these functions.

[Bug c++/96517] ICE in is_this_parameter when accessing constexpr method of a field inside coroutine lambda (with optimization)

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

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||lcw at fb dot com

--- Comment #1 from Iain Sandoe  ---
*** Bug 102878 has been marked as a duplicate of this bug. ***

[Bug c++/102878] Internal compiler error with coroutine calling constexpr function

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Sandoe  ---
actually, I posted a patch for this today ...

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

[Bug middle-end/102887] wrong warning location with macro expansion

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   Last reconfirmed||2021-10-21
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 Blocks||24639


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug middle-end/102887] New: wrong warning location with macro expansion

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

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

Bug ID: 102887
   Summary: wrong warning location with macro expansion
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As noted here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582316.html
in a -Wuninitialized warning for the use of a variable in the expansion of a
macro the warning points to the macro definition and not to the point of its
expansion as in other warnings such as -Warray-bounds.  The test case below
shows the difference.  Pointing also to the point of the macro's expansion is
important in large functions.

$ cat t.C && gcc -O2 -S -Wall -Wextra t.C
#define X(x) x ? x + 1 : 2   // warning here (not helpful)

int f (int i, int j)
{
  int x; // note here (good)
  if (i < 0)
x = i + 1;
  if (j < 0)
return X (x);
  return -1;
}

#define A(i) a[i]// note here (good)
extern int a[4]; // note here (good)

int g (int i)
{
  if (i < 0)
return A (7);// warning here (helpful)
  return -1;
}
t.C: In function ‘int f(int, int)’:
t.C:1:16: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
1 | #define X(x) x ? x + 1 : 2   // warning here (not helpful)
  |^
t.C:5:7: note: ‘x’ was declared here
5 |   int x; // note here (good)
  |   ^
t.C: In function ‘int g(int)’:
t.C:13:17: warning: array subscript 7 is above array bounds of ‘int [4]’
[-Warray-bounds]
   13 | #define A(i) a[i]// note here (good)
  |  ~~~^
t.C:19:12: note: in expansion of macro ‘A’
   19 | return A (7);// warning here (helpful)
  |^
t.C:14:12: note: while referencing ‘a’
   14 | extern int a[4]; // note here (good)
  |^

[Bug tree-optimization/102879] [12 Regression] Dead Code Elimination Regression at -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure

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

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

--- Comment #11 from Andrew Pinski  ---
Good news I can reproduce the warning with the preprocessed source on a native
x86_64-linux-gnu trunk GCC.

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

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

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

--- Comment #7 from Jason Merrill  ---
But yes, the implicit constexpr patch I've been working on would likely improve
this as well.

[Bug target/98667] gcc generates endbr32 invalid opcode on -march=i486

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

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

--- Comment #19 from CVS Commits  ---
The releases/gcc-9 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:5ed78f8bd84eb696579d928c816bc840664829b2

commit r9-9792-g5ed78f8bd84eb696579d928c816bc840664829b2
Author: H.J. Lu 
Date:   Thu Oct 21 09:45:14 2021 -0700

x86: Document -fcf-protection requires i686 or newer

PR target/98667
* doc/invoke.texi: Document -fcf-protection requires i686 or
new.

(cherry picked from commit 1373066a46d8d47abd97e46a005aef3b3dbfe94a)

[Bug target/98667] gcc generates endbr32 invalid opcode on -march=i486

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

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

--- Comment #18 from CVS Commits  ---
The releases/gcc-10 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:523dc71f5cb858da18e1f648269746dab519b445

commit r10-10228-g523dc71f5cb858da18e1f648269746dab519b445
Author: H.J. Lu 
Date:   Thu Oct 21 09:45:14 2021 -0700

x86: Document -fcf-protection requires i686 or newer

PR target/98667
* doc/invoke.texi: Document -fcf-protection requires i686 or
new.

(cherry picked from commit 1373066a46d8d47abd97e46a005aef3b3dbfe94a)

[Bug target/98667] gcc generates endbr32 invalid opcode on -march=i486

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

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

--- Comment #17 from CVS Commits  ---
The releases/gcc-11 branch has been updated by H.J. Lu :

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

commit r11-9179-ge74336df42fa36244d576dd155d7e2e2c42bc3a0
Author: H.J. Lu 
Date:   Thu Oct 21 09:45:14 2021 -0700

x86: Document -fcf-protection requires i686 or newer

PR target/98667
* doc/invoke.texi: Document -fcf-protection requires i686 or
new.

(cherry picked from commit 1373066a46d8d47abd97e46a005aef3b3dbfe94a)

[Bug c/102875] __builtin_strncpy output may be truncated copying bytes from a string of length

[johnnymarler at gmail dot com via Gcc-bugs]

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

Jonathan Marler  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Marler  ---
I confirmed this is fixed in 10.3.0.

[Bug target/98667] gcc generates endbr32 invalid opcode on -march=i486

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:1373066a46d8d47abd97e46a005aef3b3dbfe94a

commit r12-4619-g1373066a46d8d47abd97e46a005aef3b3dbfe94a
Author: H.J. Lu 
Date:   Thu Oct 21 09:45:14 2021 -0700

x86: Document -fcf-protection requires i686 or newer

PR target/98667
* doc/invoke.texi: Document -fcf-protection requires i686 or
new.

[Bug fortran/101304] Bind(C): CONTIGUOUS attribute not handled correctly in Fortran routines called from C with discontiguous argument

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from sandra at gcc dot gnu.org ---
Although it wasn't explicitly tagged with this issue, Tobias's recent big patch
to re-implement CFI <-> C descriptor conversions (commit
64f9623765da3306b0ab6a47997dc5d62c2ea261) fixed the testcases mentioned here
and removed the XFAILs on them, so I am marking this fixed.

[Bug rtl-optimization/102840] [12 Regression] gcc.target/i386/pr22076.c by r12-4475

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #6 from Uroš Bizjak  ---
Fixed.

[Bug rtl-optimization/102840] [12 Regression] gcc.target/i386/pr22076.c by r12-4475

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:6aceeb3fb64b0e82fc3301026669062797ec01a5

commit r12-4618-g6aceeb3fb64b0e82fc3301026669062797ec01a5
Author: Uros Bizjak 
Date:   Thu Oct 21 20:57:38 2021 +0200

testsuite: Adjust pr22076.c to avoid compile-time optimization [PR102840]

2021-10-21  Uroš Bizjak  

PR testsuite/102840

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr22076.c: Adjust to avoid compile time
optimization.

[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure

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

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

--- Comment #10 from Andrew Pinski  ---
Hmm, somehow unroll messes up the relationship ...

[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure

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

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

--- Comment #9 from Andrew Pinski  ---
So in uninit1 we have:
  if (_6691 != 0)
goto ; [5.50%]
  else
goto ; [94.50%]

   [local count: 17344687]:
  goto ; [100.00%]

   [local count: 298013267]:

   [local count: 315357954]:
  # const_upper_3854 = PHI <_6687(87), 18446744073709551615(287)>
  # _870 = PHI <1(87), 0(287)>
(lots of stuff)

  if (_6691 != 0)
goto ; [5.50%]
  else
goto ; [94.50%]

   [local count: 298013268]:
  goto ; [100.00%]

   [local count: 17344687]:

   [local count: 315357954]:
  # const_upper_3931 = PHI 
  if (_870 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 157678977]:
  if (const_upper_3931 > _6695)
goto ; [89.00%]
  else
goto ; [11.00%]

But _870 is _6691 == 0 but that relationship is totally missed and there is
full on jump threading miss in the above IR.

[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)

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

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

--- Comment #21 from sandra at gcc dot gnu.org ---
Tobias, did your big patch fully fix this issue so that we can close it?

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

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

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

--- Comment #6 from Jason Merrill  ---
It's not clear to me that this optimization should use the constexpr machinery;
as I commented on bug 4131.  If optimization turns the initialization of a
static variable into a simple matter of storing a constant value, it should go
one step further and turn that constant value into a constant initializer.

[Bug bootstrap/102681] [12 Regression] AArch64 bootstrap failure

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

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

--- Comment #8 from Andrew Pinski  ---
Created attachment 51648
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51648=edit
preprocessed source

unreduced preprocessed source which fails still as of r12-4600.
 -fno-PIE -c   -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common

[Bug fortran/94022] Array slices of assumed-size arrays

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

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

Bug 94070 Summary: Assumed-rank arrays – bounds mishandled, 
SIZE/SHAPE/UBOUND/LBOUND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070

   What|Removed |Added

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

[Bug fortran/94070] Assumed-rank arrays – bounds mishandled, SIZE/SHAPE/UBOUND/LBOUND

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

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #13 from sandra at gcc dot gnu.org ---
I believe this issue is fixed now.  The original test case at the top of the
issue has been committed (now named assumed_rank_22), and my last commit added
a set of tests for the thing that was still triggering the ICE plus some more
for bind(c).

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

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

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

--- Comment #12 from Vladimir Makarov  ---
The patch just hid the bug.  I believe the bug is still present on the trunk
too.

The insn in question is

(insn 26 64 109 3 (parallel [
(set (reg:SI 134 [ _12 ])
(plus:SI (mult:SI (reg:SI 117 [ _8 ])
(reg:SI 128))
(reg:SI 138)))
(set (reg:SI 135 [ _12+4 ])
(plus:SI (truncate:SI (lshiftrt:DI (plus:DI (mult:DI
(zero_extend:DI (reg:SI 117 [ _8 ]))
(zero_extend:DI (reg:SI 128)))
(zero_extend:DI (reg:SI 138)))
(const_int 32 [0x20])))
(reg:SI 138)))
]) "a.cpp":15:32 70 {umlal}
 (expr_list:REG_DEAD (reg:SI 138)
(expr_list:REG_DEAD (reg:SI 128)
(nil

And its definition is 

(define_insn "mlal"
  [(set (match_operand:SI 0 "s_register_operand" "=r,")
(plus:SI
 (mult:SI
  (match_operand:SI 4 "s_register_operand" "%r,r")
  (match_operand:SI 5 "s_register_operand" "r,r"))
 (match_operand:SI 1 "s_register_operand" "0,0")))
   (set (match_operand:SI 2 "s_register_operand" "=r,")
(plus:SI
 (truncate:SI
  (lshiftrt:DI
   (plus:DI
(mult:DI (SE:DI (match_dup 4)) (SE:DI (match_dup 5)))
(zero_extend:DI (match_dup 1)))
   (const_int 32)))
 (match_operand:SI 3 "s_register_operand" "2,2")))]
  "TARGET_32BIT"
  "mlal%?\\t%0, %2, %4, %5"
  [(set_attr "type" "umlal")
   (set_attr "predicable" "yes")
   (set_attr "arch" "v6,nov6")]

After couple of LRA constraints and assignment sub-passes, the two output
operands get the same hard reg.  And this results in cse abort in post-reload
pass.

The issue is that reload pseudos for pseudos 134 and 135 get the same value as
they both are matched with different occurrences of pseudo 138 in the insn.

The bug is in a very sensitive LRA code area and fixing it will take some time.
 But I hope I'll have a fix at the end of next week.

[Bug testsuite/102886] New: [12 regression] gcc.dg/tree-ssa/sra-18.c fails starting with r12-4607

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

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

Bug ID: 102886
   Summary: [12 regression] gcc.dg/tree-ssa/sra-18.c fails
starting with r12-4607
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:701ee067807b80957c65bd7ff94b6099a27181de, r12-4607

make  -k check-gcc RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/sra-18.c"
FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra "Removing load: a =
\\*.?L.?C.?.?.?0;" 1
FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra "SR[.$][0-9_]+ =
\\*.?L.?C.?.?.?0\\.b\\[0\\]\\.f\\[0\\]\\.x" 1
FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra "SR[.$][0-9_]+ =
\\*.?L.?C.?.?.?0\\.b\\[0\\]\\.f\\[1\\]\\.x" 1
FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra "SR[.$][0-9_]+ =
\\*.?L.?C.?.?.?0\\.b\\[1\\]\\.f\\[0\\]\\.x" 1
FAIL: gcc.dg/tree-ssa/sra-18.c scan-tree-dump-times esra "SR[.$][0-9_]+ =
\\*.?L.?C.?.?.?0\\.b\\[1\\]\\.f\\[1\\]\\.x" 1
# of expected passes2
# of unexpected failures5


commit 701ee067807b80957c65bd7ff94b6099a27181de (HEAD, refs/bisect/bad)
Author: Martin Jambor 
Date:   Thu Oct 21 14:26:45 2021 +0200

sra: Fix corner case of total scalarization with virtual inheritance (PR
102505)

[Bug testsuite/102859] [OpenMP] Missing testsuite coverage for Fortran task reductions

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-21

--- Comment #1 from Dominique d'Humieres  ---
Please do not import PR88707 unless it is fixed.

[Bug fortran/102885] New: [12 Regression] ICE when compiling gfortran.dg/bind_c_char_10.f90 with -flto

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Bug ID: 102885
   Summary: [12 Regression] ICE when compiling
gfortran.dg/bind_c_char_10.f90 with -flto
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: burnus at gcc dot gnu.org, hubicka at gcc dot gnu.org,
iains at gcc dot gnu.org, sandra at gcc dot gnu.org
  Target Milestone: ---

The test gfortran.dg/bind_c_char_10.f90 ICE when compiled with -flto:

lto1: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: gfc returned 1 exit status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.

Reduced test:

module m
  use iso_c_binding, only: c_char
  implicit none (type, external)

contains

! Assumed-shape array, nonallocatable/nonpointer

subroutine ar3 (xn, n) bind(C)
  integer :: n
  character(len=n) :: xn(..)
  if (size(xn) /= 6) stop
  if (len(xn) /= 5) stop  
  select rank(xn)
rank(1)
  xn = ['FDGhf', &
'hdrhg', &
'fDgFl', &
'DFHs3', &
'4a54G', &
'hSs6k']
  rank default
stop
  end select
end

end

program main
  use m
  implicit none (type, external)
  character(kind=c_char, len=5) :: str5a6(6)

  ! assumed rank - with array descriptor

  str5a6 = ['DDGhf', &
'hdrh$', &
'fDGSl', &
'DFHs3', &
'43grG', &
'hFG$k']
  call ar3 (str5a6, 5)

end

All the other tests compile with -flto.

[Bug c++/102854] [OpenMP] Bogus "initializer expression refers to iteration variable" when using templates

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

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 51647
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51647=edit
gcc12-pr102854-wip.patch

WIP patch.  Clearly still more work is needed, apparently pointer iterators
in non-rectangular loops are rejected, like:
void
foo ()
{
  int a[1024];
  int *p, *q;
  #pragma omp parallel for collapse(2)
  for (p = [0]; p < [512]; p++)
for (q = p + 64; q < p + 128; q++)
  ;
}
and enabling it result in ICEs during omp-expand.c.  Furthermore, for both
pointer and random access iterator non-rect loops, I should verify we only
allow the var-outer, var-outer + a2, a2 + var-outer and var-outer - a2 forms
and no others and test code generation.

[Bug c++/102884] Incorrect compile error with id-expression in requires clause before member initializer

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||rejects-valid
   Last reconfirmed||2021-10-21

[Bug libstdc++/102882] [AIX] 23_containers 96088 testsuite failures

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

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

--- Comment #2 from Jonathan Wakely  ---
Created attachment 51646
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51646=edit
Change test to not use std::string

This patch changes the testcase to use a custom instantiation of
std::basic_string, so it doesn't use the explicit instantiation definitions in
the library. Does this make the patched test PASS?

But avoiding using std::string in our own testsuite is a major pain, we should
just make it so it works.

[Bug c/102867] [12 Regression] Waddress complaint in readelf.c

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
The warning for macros was most likely inadvertently enabled in the change for
pr102103.  In hindsight, I'm guessing it's what triggered the instance in Glibc
(since fixed):
https://sourceware.org/pipermail/libc-alpha/2021-September/131241.html
and I think it might have also been what prompted the change below (I meant to
follow up there but got busy with other things):
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580786.html

I have a follow-on patch out for review for pr33925.  I'll look into the macro
suppression at the same time, although I'm not too keen on that idea in general
if it can be easily avoided in user code (e.g., inlining).  I'd rather get away
from it if it's not too painful.

The poor format of the expression in the warning is an independent issue worth
addressing separately.

[Bug target/98667] gcc generates endbr32 invalid opcode on -march=i486

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

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

--- Comment #15 from Martin Liška  ---
(In reply to H.J. Lu from comment #14)
> (In reply to Martin Liška from comment #13)
> > @H.J. Can you please document that one needs at least i686 CPU for the
> > functionality?
> 
> Like this?
> 
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index c66a25fcd69..71992b8c597 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -15542,7 +15542,8 @@ which functions and calls should be skipped from
> instrumentation
>  (@pxref{Function Attributes}).
>  
>  Currently the x86 GNU/Linux target provides an implementation based
> -on Intel Control-flow Enforcement Technology (CET).
> +on Intel Control-flow Enforcement Technology (CET) which works for
> +i686 processor or newer.
>  
>  @item -fstack-protector
>  @opindex fstack-protector

Yes, please.

[Bug c++/102884] New: Incorrect compile error with id-expression in requires clause before member initializer

[galston at stellarscience dot com via Gcc-bugs]

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

Bug ID: 102884
   Summary: Incorrect compile error with id-expression in requires
clause before member initializer
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: galston at stellarscience dot com
  Target Milestone: ---

Created attachment 51645
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51645=edit
.ii file produced by g++ command

This compiles in MSVC and clang, but gives a compile error in gcc:

constexpr bool kExpression{ true };

struct Foo {

  template< typename T >
  Foo(T ) requires kExpression : x{0} {}

  int x;
};

int main() {
  [[maybe_unused]] Foo foo{1};
}

It will compile if parentheses are put around kExpression. Since kExpression is
an id-expression, and an id-expression is a primary expression, I think this
should be allowed as is in a requires clause (see Requires clause section here
https://en.cppreference.com/w/cpp/language/constraints). It appears to be the
member initializer that it is choking on; it will compile if the ": x{0}" part
is removed.

Thank you!

Output from gcc:

> g++ -v -save-temps -Wall -Werror -std=c++20 -c requires-clause-bug.cpp
Using built-in specs.
COLLECT_GCC=g++
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-11.2.1-20210728/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20210728 (Red Hat 11.2.1-1) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Werror' '-std=c++20' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/11/cc1plus -E -quiet -v -D_GNU_SOURCE
requires-clause-bug.cpp -mtune=generic -march=x86-64 -std=c++20 -Wall -Werror
-fpch-preprocess -o requires-clause-bug.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/11/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/11/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11

/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/x86_64-redhat-linux
 /usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/backward
 /usr/lib/gcc/x86_64-redhat-linux/11/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Werror' '-std=c++20' '-c'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/11/cc1plus -fpreprocessed
requires-clause-bug.ii -quiet -dumpbase requires-clause-bug.cpp -dumpbase-ext
.cpp -mtune=generic -march=x86-64 -Wall -Werror -std=c++20 -version -o
requires-clause-bug.s
GNU C++20 (GCC) version 11.2.1 20210728 (Red Hat 11.2.1-1)
(x86_64-redhat-linux)
compiled by GNU C version 11.2.1 20210728 (Red Hat 11.2.1-1), GMP
version 6.2.0, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version
isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++20 (GCC) version 11.2.1 20210728 (Red Hat 11.2.1-1)
(x86_64-redhat-linux)
compiled by GNU C version 11.2.1 20210728 (Red Hat 11.2.1-1), GMP
version 6.2.0, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version
isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: ee1a2f208dd48c6a5d24bdcd31126e66
requires-clause-bug.cpp:7:32: error: found ‘:’ in nested-name-specifier,
expected ‘::’
7 |   Foo(T ) requires kExpression : x{0} {}
  |^
  |::
requires-clause-bug.cpp:7:20: error: ‘kExpression’ is not a class, namespace,
or enumeration
7 |   Foo(T ) requires kExpression : x{0} {}
  |^~~
requires-clause-bug.cpp:7:39: error: expected unqualified-id before ‘{’ token
7 |   Foo(T ) requires kExpression : x{0} {}
  |   ^
requires-clause-bug.cpp: In constructor ‘Foo::Foo(T) requires 

[Bug libstdc++/102882] [AIX] 23_containers 96088 testsuite failures

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to David Edelsohn from comment #0)
> Does this testcase require overriding operator new[] in the library itself,
> not only the testcase?

Yes, I think so. The allocations done by the std::string objects will be done
by the explicit instantiations of std::string inside the library.

Maybe the real solution is to stop explicitly instantiating class templates in
the library. If std::string was instantiated in the tests then all the
allocations would be done in the tests, and the 'operator new' replacement
would work.

That seems like it would remove a whole class of problems where the allocations
and deallocations might happen in different binary objects. The downside would
be slower compilation, because every object file would re-instantiate the same
templates. Avoiding that cost is the purpose of the explicit instantiations,
but if they cause incorrect behaviour, maybe the cost is worth it.

[Bug libstdc++/102358] niter_base and miter_base overloaded for move_iterator missing constexpr

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:5f7976f65b45c457b57bfc2c55ec845771e0d3c2

commit r12-4617-g5f7976f65b45c457b57bfc2c55ec845771e0d3c2
Author: Patrick Palka 
Date:   Thu Oct 21 12:13:35 2021 -0400

libstdc++: missing constexpr for __[nm]iter_base [PR102358]

PR libstdc++/102358

libstdc++-v3/ChangeLog:

* include/bits/stl_iterator.h (__niter_base): Make constexpr
for C++20.
(__miter_base): Likewise.
* testsuite/25_algorithms/move/constexpr.cc: New test.

[Bug middle-end/102764] [12 Regression] -fcompare-debug failure (length) at -O3

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #10 from Eric Botcazou  ---
.

[Bug middle-end/102764] [12 Regression] -fcompare-debug failure (length) at -O3

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:9262ae450d6a57837c58645c2ee66365bbe08338

commit r12-4616-g9262ae450d6a57837c58645c2ee66365bbe08338
Author: Eric Botcazou 
Date:   Thu Oct 21 17:57:55 2021 +0200

Fix again PR middle-end/102764

gcc/
PR middle-end/102764
* cfgexpand.c (expand_gimple_basic_block): Robustify latest change.

[Bug target/98667] gcc generates endbr32 invalid opcode on -march=i486

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #14 from H.J. Lu  ---
(In reply to Martin Liška from comment #13)
> @H.J. Can you please document that one needs at least i686 CPU for the
> functionality?

Like this?

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index c66a25fcd69..71992b8c597 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15542,7 +15542,8 @@ which functions and calls should be skipped from
instrumentation
 (@pxref{Function Attributes}).

 Currently the x86 GNU/Linux target provides an implementation based
-on Intel Control-flow Enforcement Technology (CET).
+on Intel Control-flow Enforcement Technology (CET) which works for
+i686 processor or newer.

 @item -fstack-protector
 @opindex fstack-protector

[Bug c++/102883] New: Calling co_yield with initializer list containing shared_ptr causes internal compiler error

[brad.nemanich at amd dot com via Gcc-bugs]

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

Bug ID: 102883
   Summary: Calling co_yield with initializer list containing
shared_ptr causes internal compiler error
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brad.nemanich at amd dot com
  Target Milestone: ---

When calling co_yield on an intializer_list that contains a shared_ptr, gcc
10.3 is failing with `internal compiler error: in build_special_member_call, at
cp/call.c:9787`.

Below is a short example that causes the error.

```
#include 
#include 

template 
class Generator
{
public:
struct promise_type
{
Generator get_return_object();
void return_void() noexcept { }
void unhandled_exception() noexcept;
static std::suspend_always initial_suspend() noexcept { return {}; }
static std::suspend_always   final_suspend() noexcept { return {}; }
std::suspend_always yield_value(T v) noexcept;
};
};

struct MyStruct
{
MyStruct(std::initializer_list> dst);
};


Generator add(std::shared_ptr dest)
{
//MyStruct tmp({dest});
//co_yield tmp;
co_yield MyStruct({dest});
}
```

[Bug target/102847] [12 regression] r12-4504 breaks powerpc64 build on power 7

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

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

--- Comment #11 from seurer at gcc dot gnu.org ---
The build is indeed once again working on power 7.  Thanks!

[Bug target/98667] gcc generates endbr32 invalid opcode on -march=i486

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #13 from Martin Liška  ---
@H.J. Can you please document that one needs at least i686 CPU for the
functionality?

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Note, for comdat variables (inline vars, variable templates) we need to be
careful, see PR99456 ABI discussions whether it is ok to change whether
something is initialized dynamically or statically.
When the function isn't constexpr though, trying to evaluate it as
non-manifestly constant evaluated expression will fail though, so we'd need
some even less pedantic constant expression evaluation mode that would handle
inline non-constexpr functions as if they were constexpr.

[Bug libstdc++/102882] New: [AIX] 23_containers 96088 testsuite failures

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

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

Bug ID: 102882
   Summary: [AIX] 23_containers 96088 testsuite failures
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

The 96088 testcases are failing on AIX.

Does this testcase require overriding operator new[] in the library itself, not
only the testcase? The default build options for libstdc++ on AIX do not permit
operator overloading. Maybe it requires XFAIL on AIX.

/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/23_containers/unordered_set/960
88.cc:42: void test01(): Assertion '__gnu_test::counter::count() == 3' failed.
operator new is called 
operator new is called 
FAIL: 23_containers/unordered_set/96088.cc execution test

/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/23_containers/unordered_map/960
88.cc:42: void test01(): Assertion '__gnu_test::counter::count() == 3' failed.
operator new is called 
operator new is called 
FAIL: 23_containers/unordered_map/96088.cc execution test

/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/23_containers/unordered_multima
p/96088.cc:43: void test01(): Assertion '__gnu_test::counter::count() == 3'
fail
ed.
operator new is called 
operator new is called 
FAIL: 23_containers/unordered_multimap/96088.cc execution test

/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/23_containers/unordered_multise
t/96088.cc:43: void test01(): Assertion '__gnu_test::counter::count() == 3'
fail
ed.
operator new is called 
operator new is called 
FAIL: 23_containers/unordered_multiset/96088.cc execution test

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

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

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

Patrick Palka  changed:

   What|Removed |Added

 Depends on||4131
 CC||ppalka at gcc dot gnu.org

--- Comment #4 from Patrick Palka  ---
The example in comment #3 is basically PR4131 I think.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
[Bug 4131] The C++ compiler doesn't place a const class object to ".rodata"
section with non trivial constructor

[Bug tree-optimization/102879] [12 Regression] Dead Code Elimination Regression at -O3

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #2 from Andrew Macleod  ---
(In reply to Aldy Hernandez from comment #1)
>
> 
> So, presumably _62 == 0 cannot be true.  If _62 == 0, then
> 
> 0 = _30 >> _6;
> 
> But that cannot happen because _30 is 2 if you follow the series of copies
> from the "c" global.
> 
> There is no way 0 = 2 >> x can ever be true.
> 
> There's probably a couple things missing here.  Maybe
> operator_rshift::op1_range needs to be taught that ~[0,0] = x >> y implies x
> is non-zero.  But also, we can't see through the load from the c=2 global. 
> Shouldn't that c=2 have been propagated by someone at this point?  (VRP1?)


well, that depends on _6.  0 = _30 >> 32 is always true. 
now, we do happen to know that _6 is [0,1], so if we did manage to determine
that _30 is [2,2], then the we will fold [2,2] >> [0,1] into [1,2] and then
everything should fall into place as we know we can never take that breanch.

That means our core issue is
  c.2_28 = c;
  _29 = (char) c.2_28;
  _30 = (int) _29;
  if (_29 >= 0)

that we don't propagate the 2 into the c.2_28.   we are limited to a range of
[1,127] because of that.

[Bug c++/102881] gcc totally broken when trailing return type combine with decltype lambda

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #1 from 康桓瑋  ---
(In reply to 康桓瑋 from comment #0)
> template
> using R = decltype([] { return 0; }());
> 
> template 
> auto you_can_see_me() -> R {
>   return {};
> }
> 
> int main() {
>   you_can_see_me<0>();
> }
> 
> GCC rejects with:
> 
> :10:3: error: 'you_can_see_me' was not declared in this scope
>10 |   you_can_see_me<0>();
>   |   ^
> 
> https://godbolt.org/z/7WEsjjscT

Even broken when there is no trailing return type:

#include 

template
struct O {};

template
using R = decltype([] { return O{}; }());

template 
constexpr R get_variant() { return {}; }

static_assert(std::same_as, O>);
auto x = get_variant<0>();
static_assert(!std::same_as>);
static_assert(std::same_as);

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

[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init

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

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

--- Comment #11 from Jakub Jelinek  ---
Ah, I see, there is still the team->work_shares array where the whole team
structure in which it is present is allocated with gomp_malloc.
So, either we need to drop the aligned (64) attribute regardless of
GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC, or make sure that if
GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC we use gomp_aligned_alloc instead of
gomp_malloc for team_malloc, or combination of both (GCN has its own separate
team_malloc, so perhaps get rid of aligned attribute on GCN too).

[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init

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

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

--- Comment #10 from Rainer Orth  ---
Created attachment 51644
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51644=edit
32-bit i386-pc-solaris2.11 loop_ull.[is]

[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #8 from Jakub Jelinek  ---
> Ok, so, first question, is GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC defined in your
> case?

It is since all of HAVE_ALIGNED_ALLOC, HAVE_POSIX_MEMALIGN, and
HAVE_MEMALIGN are defined in config.h.

> Can be seen e.g. from objdump -dr alloc.o and seeing if gomp_aligned_free is
> just a (tail?) call to free without anything else or if it performs
>   if (ptr)
> free (((void **) ptr)[-1]);

It's the former: just a call to free.

> Or perhaps attach preprocessed loop-ull.i and loop-ull.s.

Doing so just in case...

[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init

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

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

--- Comment #8 from Jakub Jelinek  ---
Ok, so, first question, is GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC defined in your
case?
Can be seen e.g. from objdump -dr alloc.o and seeing if gomp_aligned_free is
just a (tail?) call to free without anything else or if it performs
  if (ptr)
free (((void **) ptr)[-1]);
Or perhaps attach preprocessed loop-ull.i and loop-ull.s.

[Bug tree-optimization/102879] [12 Regression] Dead Code Elimination Regression at -O3

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #1 from Aldy Hernandez  ---
We should've elided the call to foo() in the 8->3 edge.  This is the IL in
vrp-thread1 dump:

int main ()
{
  int h;
  int g;
  int _3;
  _Bool _5;
  int _6;
  char iftmp.4_11;
  int _12;
  int _19;
  int _21;
  char iftmp.4_22;
  int d.0_25;
  _Bool _26;
  int _27;
  int c.2_28;
  char _29;
  int _30;
  int _42;
  char iftmp.4_43;
  int _48;
  int _50;
  _Bool _53;
  int _56;
  int _59;
  char iftmp.4_60;
  int _62;

   [local count: 134197598]:
  c = 2;
  goto ; [100.00%]

   [local count: 88583700]:
  foo ();

   [local count: 268435457]:
  g_18 = g_10 + 1;

   [local count: 402633054]:
  # g_10 = PHI <0(2), g_18(4)>
  if (g_10 != 2)
goto ; [66.67%]
  else
goto ; [33.33%]

   [local count: 268435456]:
  d.0_25 = d;
  _26 = d.0_25 == 0;
  _27 = (int) _26;
  c.2_28 = c;
  _29 = (char) c.2_28;
  _30 = (int) _29;
  if (_29 >= 0)
goto ; [59.00%]
  else
goto ; [41.00%]

   [local count: 110058536]:
  # iftmp.4_11 = PHI <_29(6)>
  _12 = (int) iftmp.4_11;
  d = _12;
  _48 = (int) _29;
  d = _48;
  _19 = (int) _29;
  d = _19;
  goto ; [100.00%]

   [local count: 158376920]:
  _42 = _30 >> _27;
  iftmp.4_43 = (char) _42;
  _50 = _42;
  d = _50;
  _53 = _50 == 0;
  _56 = (int) _53;
  _21 = _30 >> _56;
  iftmp.4_22 = (char) _21;
  _3 = _21;
  d = _3;
  _5 = _3 == 0;
  _6 = (int) _5;
  _59 = _30 >> _6;
  iftmp.4_60 = (char) _59;
  _62 = _59;
  d = _62;
  if (_62 == 0)
goto ; [66.33%]
  else
goto ; [33.67%]

   [local count: 134197598]:
  return 0;

}

So, presumably _62 == 0 cannot be true.  If _62 == 0, then

0 = _30 >> _6;

But that cannot happen because _30 is 2 if you follow the series of copies from
the "c" global.

There is no way 0 = 2 >> x can ever be true.

There's probably a couple things missing here.  Maybe
operator_rshift::op1_range needs to be taught that ~[0,0] = x >> y implies x is
non-zero.  But also, we can't see through the load from the c=2 global. 
Shouldn't that c=2 have been propagated by someone at this point?  (VRP1?)

[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
>> --- Comment #5 from Jakub Jelinek  ---
>> Does the committed patch fix the issue on Solaris?
>
> I'll see after tonight's bootstrap.  The original one attached to the PR
> fixed only a few of the failures:
>
> -FAIL: libgomp.c/../libgomp.c-c++-common/for-1.c execution test
>
> -FAIL: libgomp.c/../libgomp.c-c++-common/for-2.c execution test
>
> -FAIL: libgomp.c/../libgomp.c-c++-common/for-7.c execution test
> -FAIL: libgomp.c/../libgomp.c-c++-common/for-8.c execution test

The committed version is the same: quite a number of the previous
failures remain.

E.g. even with OMP_NUM_THREADS=8, for-3.c starts a large number of
threads (200+), then hangs under gdb, but if I let it run directly, it
SEGVs again and the core dump shows the same unaligned access (with dbx,
gdb cannot interpret the core dump):

t@198 (l@198) terminated by signal SEGV (no mapping at the fault address)
0xfe5d7fb8: gomp_loop_ull_guided_start+0x01a8:  movaps   %xmm0,0x0010(%esi)
(dbx) print $esi 
$esi = 134981864

[Bug c++/102881] New: gcc totally broken when trailing return type combine with decltype lambda

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 102881
   Summary: gcc totally broken when trailing return type combine
with decltype lambda
   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: ---

template
using R = decltype([] { return 0; }());

template 
auto you_can_see_me() -> R {
  return {};
}

int main() {
  you_can_see_me<0>();
}

GCC rejects with:

:10:3: error: 'you_can_see_me' was not declared in this scope
   10 |   you_can_see_me<0>();
  |   ^

https://godbolt.org/z/7WEsjjscT

[Bug tree-optimization/102880] [12 Regression] Dead Code Elimination Regression at -O3

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-21
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Thanks for the report. Please CC authors of the revision that you bisected to.

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

[redbeard0531 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Mathias Stearn  ---
> Why not just make the function constexpr though?

That isn't always possible. Sometimes the initializer may call a third-party
function that is inline, but not yet marked constexpr (it may need to support
older language versions where it couldn't be constexpr). Other times the
initializer may call a function that is out of line (so can't be constexpr at
all), but defined in the same TU. MSVC and clang handle this somewhat more
realistic example nicely, gcc doesn't: https://godbolt.org/z/jYKx8359T

The original example using chrono was just something that when reading I
thought "any optimizer worth its salt should be able to do this even without
explicit constexpr annotation". I was disappointed to learn that gcc couldn't,
so I filed a bug in the hope that it can be improved.

[Bug tree-optimization/102880] New: [12 Regression] Dead Code Elimination Regression at -O3

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

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

Bug ID: 102880
   Summary: [12 Regression] Dead Code Elimination Regression at
-O3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

cat test.c
void foo(void);

static int b, c, d, e, f, ah;
static short g, ai, am, aq, as;
static char an, at, av, ax, ay;
static char a(char h, char i) { return i == 0 || h && i == 1 ? 0 : h % i; }
static void ae(int h) {
  if (a(b, h))
foo();

}
int main() {
  ae(1);
  ay = a(0, ay);
  ax = a(g, aq);
  at = a(0, as);
  av = a(c, 1);
  an = a(am, f);
  int al = e || ((a(1, ah) && b) & d) == 2;
  ai = al;
}

11.2.0 at -O3 can eliminate the call to foo but trunk at -O3 cannot:

gcc-11 -O3 -S test.c -o /dev/stdout
...
main:
.LFB2:
.cfi_startproc
movb$0, ay(%rip)
xorl%eax, %eax
ret
.cfi_endproc

gcc-11 -O3 -S test.c -o /dev/stdout
...
a.part.0:
.LFB3:
.cfi_startproc
testb   %dil, %dil
je  .L5
xorl%eax, %eax
cmpb$1, %sil
jne .L5
ret
.L5:
movsbl  %dil, %eax
movsbl  %sil, %esi
cltd
idivl   %esi
movl%edx, %eax
ret
.cfi_endproc
...
main:
.LFB2:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
xorl%edi, %edi
movl$1, %esi
calla.part.0
testb   %al, %al
jne .L18
.L9:
movzbl  ay(%rip), %eax
testb   %al, %al
je  .L10
movsbl  %al, %esi
xorl%edi, %edi
calla.part.0
.L10:
movb%al, ay(%rip)
xorl%eax, %eax
addq$8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.L18:
.cfi_restore_state
callfoo
jmp .L9
.cfi_endproc


gcc-trunk -v   
Using built-in specs.
Target: x86_64-pc-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211021 (experimental) (GCC)

Started with
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b58dc0b803057c0e6032e0d9bd92cd834f72c75c

[Bug debug/102585] [12 Regression] ICE in final_scan_insn_1, at final.c:2629 since r12-4038-g6de9f0c13b27c343

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Fixed now.

[Bug middle-end/102766] [12 Regression][nvptx] internal compiler error: in df_insn_delete, at df-scan.c:949

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Liška  ---
Should be fixed now.

[Bug middle-end/102766] [12 Regression][nvptx] internal compiler error: in df_insn_delete, at df-scan.c:949

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r12-4608-gb4702276615ff8d43bc910e7a54fdd850ad8d461
Author: Martin Liska 
Date:   Thu Oct 14 14:57:18 2021 +0200

options: Fix variable tracking option processing.

PR debug/102585
PR bootstrap/102766

gcc/ChangeLog:

* opts.c (finish_options): Process flag_var_tracking* options
here as they can be adjusted by optimize attribute.
Process also flag_syntax_only and flag_gtoggle.
* toplev.c (process_options): Remove it here.
* common.opt: Make debug_nonbind_markers_p as PerFunction
attribute as it depends on optimization level.

gcc/testsuite/ChangeLog:

* gcc.dg/pr102585.c: New test.

[Bug debug/102585] [12 Regression] ICE in final_scan_insn_1, at final.c:2629 since r12-4038-g6de9f0c13b27c343

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r12-4608-gb4702276615ff8d43bc910e7a54fdd850ad8d461
Author: Martin Liska 
Date:   Thu Oct 14 14:57:18 2021 +0200

options: Fix variable tracking option processing.

PR debug/102585
PR bootstrap/102766

gcc/ChangeLog:

* opts.c (finish_options): Process flag_var_tracking* options
here as they can be adjusted by optimize attribute.
Process also flag_syntax_only and flag_gtoggle.
* toplev.c (process_options): Remove it here.
* common.opt: Make debug_nonbind_markers_p as PerFunction
attribute as it depends on optimization level.

gcc/testsuite/ChangeLog:

* gcc.dg/pr102585.c: New test.

[Bug tree-optimization/102879] [12 Regression] Dead Code Elimination Regression at -O3

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-21
 CC||aldyh at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

[Bug c++/102878] Internal compiler error with coroutine calling constexpr function

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||10.3.1, 11.2.1, 12.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
 CC||iains at gcc dot gnu.org
   Last reconfirmed||2021-10-21

--- Comment #1 from Richard Biener  ---
Confirmed on trunk as well.

[Bug middle-end/102877] missed optimization: memcpy produces lots more asm than otherwise

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c++ |middle-end
 Ever confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed||2021-10-21

--- Comment #1 from Richard Biener  ---
Confirmed.  With memcpy we expand from

  MEM  [(unsigned char *)] = { 0, 0 };
  MEM  [(char * {ref-all}) + 2B] = MEM  [(char * {ref-all})];
  value.0_1 = value;
  _2 = __builtin_bswap64 (value.0_1); [tail call]
  value ={v} {CLOBBER};
  return _2;

thus we expand 'value' on the stack.  Without memcpy we manage to do

  MEM  [(unsigned char *)] = 0;
  _19 = MEM  [(unsigned char *)];
  MEM  [(unsigned char *) + 2B] = _19;
  _21 = MEM  [(unsigned char *) + 2B];
  MEM  [(unsigned char *) + 4B] = _21;
  value.0_7 = value;
  _8 = __builtin_bswap64 (value.0_7); [tail call]

which also expands 'value' to the stack but is appearantly nicer to later
passes which means the way we expand the aggregate copy of type char[6]
is highly sub-optimal (we do 6 byte loads & stores).

[Bug tree-optimization/102505] [10/11/12 Regression] ICE in verify_sra_access_forest with 16 byte aligned field and virtual inheritance since r10-6321-g636e80eea24b780f

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:701ee067807b80957c65bd7ff94b6099a27181de

commit r12-4607-g701ee067807b80957c65bd7ff94b6099a27181de
Author: Martin Jambor 
Date:   Thu Oct 21 14:26:45 2021 +0200

sra: Fix corner case of total scalarization with virtual inheritance (PR
102505)

PR 102505 is a situation where of SRA takes its initial top-level
access size from a get_ref_base_and_extent called on a COMPONENT_REF,
and thus derived frm the FIELD_DECL, which however does not include a
virtual base.  Total scalarization then goes on traversing the type,
which however has virtual base past the non-virtual bits, tricking SRA
to create sub-accesses outside of the supposedly encompassing
accesses, which in turn triggers the verifier within the pass.

The patch below fixes that by failing total scalarization when this
situation is detected.

gcc/ChangeLog:

2021-10-20  Martin Jambor  

PR tree-optimization/102505
* tree-sra.c (totally_scalarize_subtree): Check that the
encountered field fits within the acces we would like to put it
in.

gcc/testsuite/ChangeLog:

2021-10-20  Martin Jambor  

PR tree-optimization/102505
* g++.dg/torture/pr102505.C: New test.

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
Version|unknown |11.2.0

--- Comment #2 from Richard Biener  ---
It's known that other compilers try to consteval things that are not in const
context, esp. for initializers.  We should think of doing the same (IIRC I saw
patches from Jason flowing by treating inline functions as constexpr
opportunistically).

[Bug tree-optimization/102879] New: [12 Regression] Dead Code Elimination Regression at -O3

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

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

Bug ID: 102879
   Summary: [12 Regression] Dead Code Elimination Regression at
-O3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

cat test.c
void foo(void);

static int b, c, d;
static char a(char e, int f) { return e < 0 ? e : e >> f; }

int main() {
  c = 2;
  for (int g = 0; g < 2; g++) {
for (int h = 0; h < 3; h++)
  d = a(c, d == b);
if (!d)
  foo();
  }
}


11.2.0 at -O3 can eliminate the call to foo but trunk at -O3 cannot:


gcc-11 -O3 -S test.c -o /dev/stdout
...
main:
.LFB1:
.cfi_startproc
movl$2, c(%rip)
xorl%eax, %eax
movl$2, d(%rip)
ret
.cfi_endproc

gcc-trunk test.c -S -O3 -o /dev/stdout
...
main:
.LFB1:
.cfi_startproc
movl$2, %edx
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movld(%rip), %ecx
movl$2, %ebx
movl$2, c(%rip)
movsbl  %dl, %eax
testb   %dl, %dl
js  .L9
.L4:
testl   %ecx, %ecx
movl%eax, %edx
sete%cl
sarl%cl, %edx
testl   %edx, %edx
movl%eax, %edx
sete%cl
sarl%cl, %edx
testl   %edx, %edx
sete%cl
sarl%cl, %eax
movl%eax, d(%rip)
testl   %eax, %eax
jne .L5
callfoo
.L5:
cmpl$1, %ebx
je  .L3
.L10:
movlc(%rip), %edx
movld(%rip), %ecx
movl$1, %ebx
movsbl  %dl, %eax
testb   %dl, %dl
jns .L4
.L9:
movl%eax, d(%rip)
cmpl$1, %ebx
jne .L10
.L3:
xorl%eax, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc


gcc-trunk -v   
Using built-in specs.
Target: x86_64-pc-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211021 (experimental) (GCC)

Started with
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2e96b5f14e4025691b57d2301d71aa6092ed44bc

[Bug c/102875] __builtin_strncpy output may be truncated copying bytes from a string of length

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||10.3.0, 11.2.0, 9.4.1
   Last reconfirmed||2021-10-21
   Keywords||diagnostic

--- Comment #1 from Richard Biener  ---
Confirmed with the branch head, but you need -O2 -Wall to reproduce.  It seems
fixed in GCC 10 and GCC 11.

[Bug c++/102878] New: Internal compiler error with coroutine calling constexpr function

[lcw at fb dot com via Gcc-bugs]

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

Bug ID: 102878
   Summary: Internal compiler error with coroutine calling
constexpr function
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lcw at fb dot com
  Target Milestone: ---

Created attachment 51643
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51643=edit
Preprocessed sources

Here is the full command I'm running, with its complete output:

$ g++-10 -v -save-temps -O2 repro.cc -std=c++20 -fcoroutines
Using built-in specs.
COLLECT_GCC=g++-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
10.3.0-1ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-S4I5Pr/gcc-10-10.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-S4I5Pr/gcc-10-10.3.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1~20.04)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-std=c++2a' '-fcoroutines'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/10/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE repro.cc -mtune=generic -march=x86-64 -std=c++2a
-fcoroutines -O2 -fpch-preprocess -fasynchronous-unwind-tables
-fstack-protector-strong -Wformat -Wformat-security -fstack-clash-protection
-fcf-protection -o repro.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/10"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/10/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /public/apps/NCCL/2.8.3-1/include
 /usr/include/c++/10
 /usr/include/x86_64-linux-gnu/c++/10
 /usr/include/c++/10/backward
 /usr/lib/gcc/x86_64-linux-gnu/10/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-std=c++2a' '-fcoroutines'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/10/cc1plus -fpreprocessed repro.ii -quiet
-dumpbase repro.cc -mtune=generic -march=x86-64 -auxbase repro -O2 -std=c++2a
-version -fcoroutines -fasynchronous-unwind-tables -fstack-protector-strong
-Wformat -Wformat-security -fstack-clash-protection -fcf-protection -o repro.s
GNU C++17 (Ubuntu 10.3.0-1ubuntu1~20.04) version 10.3.0 (x86_64-linux-gnu)
compiled by GNU C version 10.3.0, GMP version 6.2.0, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (Ubuntu 10.3.0-1ubuntu1~20.04) version 10.3.0 (x86_64-linux-gnu)
compiled by GNU C version 10.3.0, GMP version 6.2.0, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 169ee3a1708a329c07eaf03cc8dfbe6c
repro.cc: In function ‘void
MyClass::doSth()_ZZN7MyClass5doSthEvENKUlvE_clEv.actor(MyClass::doSth()_ZZN7MyClass5doSthEvENKUlvE_clEv.frame*)’:
repro.cc:42:3: internal compiler error: in is_this_parameter, at
cp/semantics.c:10206
   42 |   }();
  |   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



The original C++ repro:

#include 

class Task : public std::suspend_never {
 private:
  class Promise {
   public:
Task get_return_object() {
  return Task();
}

std::suspend_never initial_suspend() {
  return 

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Last reconfirmed||2021-10-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
Why not just make the function constexpr though?

[Bug rtl-optimization/102842] [10 Regression] ICE in cselib_record_set at -O2 or greater

[herrtimson at yahoo dot de via Gcc-bugs]

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

tt_1  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #11 from tt_1  ---
(In reply to Martin Liška from comment #10)
> > Hint: its not an option to upgrade to gcc-11.2.0, since the cross compile
> > bootstrap is fundamentally broken by missing fenv header in the gcc-11
> > branch. Mixing up host and target compiler versions is nothing to desire,
> > its a place where there will be dragons.
> 
> Oh, is it something we can help with? Is it a problem of the compiler?

the fenv bug is not new and was reported via #100017, there is already a
discussion with two possible solutions. The title is a bit misleading, I hit it
when I bootstrap a rootfs with all libs and headers for the armv7 target. 

it seems that the fix for my gcc-10 bug was a stray commit without any bug
report, so I don't know who and where to ask for a proper backport. Gentoo's
gcc maintainer trofi (Sergey Trofimov) has resigned, to my great misfortune, so
I'm kind of lost with the process. Can we at least reopen? The bug is def not
fixed in the gcc-10 branch.

[Bug c++/102877] New: missed optimization: memcpy produces lots more asm than otherwise

[jengelh at inai dot de via Gcc-bugs]

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

Bug ID: 102877
   Summary: missed optimization: memcpy produces lots more asm
than otherwise
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
  Target Milestone: ---

Input (C++)
===
struct GLOBCNT { unsigned char ab[6]; };
unsigned long long gc_to_num(GLOBCNT gc)
{
unsigned long long value;
auto v = reinterpret_cast();
v[0] = 0;
v[1] = 0;
#ifdef WITH_MEMCPY
__builtin_memcpy(v + 2, gc.ab, 6);
#else
v[2] = gc.ab[0]; v[3] = gc.ab[1]; v[4] = gc.ab[2];
v[5] = gc.ab[3]; v[6] = gc.ab[4]; v[7] = gc.ab[5];
#endif
if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__)
value = __builtin_bswap64(value);
return value;
}

I hope this is UB-free.


Observed behavior
=
The use of memcpy/__builtin_memcpy produces a function with 28
instructions/0x5c bytes long.

► g++ -O2 -c t3.cpp -Wall -DWITH_MEMCPY -v
Target: x86_64-suse-linux
gcc version 11.2.1 20210816 [revision 056e324ce46a7924b5cf10f61010cf9dd2ca10e9]
(SUSE Linux)

► objdump -Mintel -d t3.o
 <_Z9gc_to_num7GLOBCNT>:
   0:   89 f8   moveax,edi
   2:   89 f9   movecx,edi
   4:   89 fa   movedx,edi
   6:   44 0f b6 c7 movzx  r8d,dil
   a:   c1 e9 10shrecx,0x10
   d:   0f b6 f4movzx  esi,ah
  ...
  5c:   c3  ret


Expected behavior
=
► g++ -O2 -c t3.cpp -Wall -UWITH_MEMCPY
► objdump -Mintel -d t3.o
 <_Z9gc_to_num7GLOBCNT>:
   0:   0f b7 c7movzx  eax,di
   3:   48 c1 ef 10 shrrdi,0x10
   7:   48 c1 e7 20 shlrdi,0x20
   b:   48 c1 e0 10 shlrax,0x10
   f:   48 09 f8or rax,rdi
  12:   48 0f c8bswap  rax
  15:   c3  ret


Other notes
===
In a twist, clang 13.0.0 produces the short version for memcpy (even shorter
than gcc), and produces a long version for non-memcpy case (even longer than
gcc).

► clang++ -O2 -c t3.cpp -Wall -DWITH_MEMCPY; objdump -Mintel -d t3.o
 <_Z9gc_to_num7GLOBCNT>:
   0:   48 89 f8movrax,rdi
   3:   48 c1 e0 10 shlrax,0x10
   7:   48 0f c8bswap  rax
   a:   c3  ret

► clang++ -O2 -c t3.cpp -Wall -UWITH_MEMCPY; objdump -Mintel -d t3.o
 <_Z9gc_to_num7GLOBCNT>:
   0:   48 89 f8movrax,rdi
   3:   48 b9 ff ff ff ff ffmovabs rcx,0x
   a:   ff 00 00 
 ...
  6c:   c3  ret

[Bug middle-end/102766] [12 Regression][nvptx] internal compiler error: in df_insn_delete, at df-scan.c:949

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

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

--- Comment #7 from Tobias Burnus  ---
Cross ref – Martin's patch (current iteration) for this PR and PR102585 is at
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582103.html

[Bug libstdc++/102358] niter_base and miter_base overloaded for move_iterator missing constexpr

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/102876] New: GCC fails to use constant initialization even when it knows the value to initialize

[redbeard0531 at gmail dot com via Gcc-bugs]

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

Bug ID: 102876
   Summary: GCC fails to use constant initialization even when it
knows the value to initialize
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

See: https://godbolt.org/z/KnKv9j8b9

#include 
using namespace std::literals;
/*not constexpr*/ inline std::chrono::sys_days compute_days() {
return 1776y/7/4;
}
std::chrono::sys_days BURN_IN_TO_BINARY = compute_days();

Clang and MSVC both correctly burn BURN_IN_TO_BINARY into the binary image with
the correct value. Even with -O3, gcc zero-initializes it then uses a dynamic
initializer to complete the initialization. Both are valid implementation
strategies according to https://eel.is/c++draft/basic.start.static#3, however,
I think the strategy used by clang and MSVC is clearly superior QoI here.

[Bug libffi/102874] [12 regression] src/x86/win64.S doesn't assemble with Solaris as

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #2 from H.J. Lu  ---
Does libffi 3.4.2 work on Solaris?  If yes, why doesn't it work in gcc?
If no, please fix the upstream and backport the fix.

[Bug c/102875] New: __builtin_strncpy output may be truncated copying bytes from a string of length

[johnnymarler at gmail dot com via Gcc-bugs]

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

Bug ID: 102875
   Summary: __builtin_strncpy output may be truncated copying
bytes from a string of length
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johnnymarler at gmail dot com
  Target Milestone: ---

GCC Version: 9.2.0
System: NixOS

$ gcc -v
Using built-in specs.
COLLECT_GCC=/nix/store/b3zsk4ihlpiimv3vff86bb5bxghgdzb9-gcc-9.2.0/bin/gcc
COLLECT_LTO_WRAPPER=/nix/store/b3zsk4ihlpiimv3vff86bb5bxghgdzb9-gcc-9.2.0/libexec/gcc/x86_64-unknown-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: 
Thread model: posix
gcc version 9.2.0 (GCC) 

How to reproduce:

wtf.c
--
#include 

// value of 2 works???
//#define COPY_COUNT 2
// values >3 don't work
#define COPY_COUNT 3

typedef struct {
  // NOTE: these padding values don't fix it
  //int something_to_pad_between_elements_1;
  char array[100];
  //int something_to_pad_between_elements_2;
} StringBuf;

int main()
{
  StringBuf a[COPY_COUNT];
  StringBuf b[COPY_COUNT];

  for (unsigned i = 0; i < COPY_COUNT; i++) {
strncpy(a[i].array, b[i].array, 100);
  }
}
--

$ gcc -Wall wtf.c
In file included from
/nix/store/fwpn2f7a4iqszyydw7ag61zlnp6xk5d3-glibc-2.30-dev/include/string.h:494,
 from wtf.c:1:
In function ‘strncpy’,
inlined from ‘main’ at wtf.c:21:5:
/nix/store/fwpn2f7a4iqszyydw7ag61zlnp6xk5d3-glibc-2.30-dev/include/bits/string_fortified.h:106:10:
warning: ‘__builtin_strncpy’ output may be truncated copying 100 bytes from a
string of length 299 [-Wstringop-truncation]
  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos
(__dest));
  |  ^~


Expected Results:

This example is expected to compile with no issues.

Actual Results:

The compiler erroneously warns about a truncated strcpy when no such truncation
occurs.

[Bug target/102847] [12 regression] r12-4504 breaks powerpc64 build on power 7

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

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

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

https://gcc.gnu.org/g:8516963942b0a8f06fa8f5ebd7c37f9edea151ac

commit r12-4604-g8516963942b0a8f06fa8f5ebd7c37f9edea151ac
Author: Richard Biener 
Date:   Thu Oct 21 12:10:20 2021 +0200

tree-optimization/102847 - adjust VMAT_INVARIANT load costing

This adds the missing scalar load cost in the prologue.

2021-10-21  Richard Biener  

PR tree-optimization/102847
* tree-vect-stmts.c (vect_model_load_cost): Add the scalar
load cost in the prologue for VMAT_INVARIANT.

[Bug tree-optimization/102505] [10/11/12 Regression] ICE in verify_sra_access_forest with 16 byte aligned field and virtual inheritance since r10-6321-g636e80eea24b780f

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

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

--- Comment #5 from Martin Jambor  ---
I proposed a patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582249.html