[Bug fortran/99609] Pure Function that has a Variable with Value Attribute that is modified

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #4 from Jerry DeLisle  ---
(In reply to Scott Boyce from comment #3)
> Yeah that is the same bug request. Though it is for version 11, any chance
> of back-porting to version 9 and 10?

It has been committed to version 10.

[Bug fortran/99609] Pure Function that has a Variable with Value Attribute that is modified

[Boyce at engineer dot com via Gcc-bugs]

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

--- Comment #3 from Scott Boyce  ---
Yeah that is the same bug request. Though it is for version 11, any chance of
back-porting to version 9 and 10?

[Bug c++/97973] [9/10 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:19577 since r265609

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in
   |tsubst_copy_and_build, at   |tsubst_copy_and_build, at
   |cp/pt.c:19577 since r265609 |cp/pt.c:19577 since r265609

--- Comment #4 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/97973] [9/10/11 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:19577 since r265609

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:40465293cd780aa82dcae75dfcfb1449d8c0561e

commit r11-7709-g40465293cd780aa82dcae75dfcfb1449d8c0561e
Author: Marek Polacek 
Date:   Wed Mar 3 18:37:49 2021 -0500

c++: ICE with real-to-int conversion in template [PR97973]

In this test we are building a call in a template, but since neither
the function nor any of its arguments are dependent, we go down the
normal path in finish_call_expr.  convert_arguments sees that we're
binding a reference to int to double and therein convert_to_integer
creates a FIX_TRUNC_EXPR.  Later, we call check_function_arguments
which folds the arguments, and, in a template, fold_for_warn calls
fold_non_dependent_expr.  But tsubst_copy_and_build should not see
a FIX_TRUNC_EXPR (see the patch discussed in
)
or we crash.

So let's not create a FIX_TRUNC_EXPR in a template in the first place
and instead use IMPLICIT_CONV_EXPR.

gcc/cp/ChangeLog:

PR c++/97973
* call.c (conv_unsafe_in_template_p): New.
(convert_like): Use it.

gcc/testsuite/ChangeLog:

PR c++/97973
* g++.dg/conversion/real-to-int1.C: New test.

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

H.J. Lu  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=27590
 Resolution|--- |MOVED
 Status|NEW |RESOLVED

--- Comment #20 from H.J. Lu  ---
Moved to

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

[Bug target/99581] [11 Regression] internal compiler error: during RTL pass: final - void QTWTF::TCMalloc_PageHeap::scavengerThread() since r11-7526

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

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

--- Comment #12 from Vladimir Makarov  ---
(In reply to Vladimir Makarov from comment #11)
> Introducing a new memory constraint can take some time.
> 
> I guess we could switch off the offending code meanwhile because it is
> compiler crash vs unoptimal generated code choice.
> 
> I'll investigate how switching the code off affects GCC tests on aarhc64.

Unfortunately, switching off the code results in 480 GCC test failures on
aarhc64.

I'll work on introducing new memory constraint.  I hope to have a patch and
submit it for review on Friday.

[Bug target/99639] New: Duplicated constant in V2SI/V4SI

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

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

Bug ID: 99639
   Summary: Duplicated constant in V2SI/V4SI
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take C++ code:
void  foo(int ()[42])
{
for (unsigned i = 0; i < sizeof(arr) / sizeof(arr[0]); ++i)
arr[i] = 43;
}
 CUT 
Current we produce:
foo(int (&) [42]):
moviv0.4s, 0x2b
moviv1.2s, 0x2b
stp q0, q0, [x0]
stp q0, q0, [x0, 32]
stp q0, q0, [x0, 64]
stp q0, q0, [x0, 96]
stp q0, q0, [x0, 128]
str d1, [x0, 160]
ret
- CUT 
But d1 is the same as q0 really.  And we don't need to have it.

[Bug middle-end/99638] s132 and s281 benchmarks of TSVC on zen3 benefits from -mno-fma

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

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
Summary|s132 benchmarks of TSVC on  |s132 and s281 benchmarks of
   |zen3 benefits from -mno-fma |TSVC on zen3 benefits from
   ||-mno-fma

--- Comment #1 from Jan Hubicka  ---
s281 benchmark:

typedef float real_t;

#define iterations 100
#define LEN_1D 32000
#define LEN_2D 256
// array definitions
real_t flat_2d_array[LEN_2D*LEN_2D];

real_t x[LEN_1D];

real_t a[LEN_1D],b[LEN_1D],c[LEN_1D],d[LEN_1D],e[LEN_1D],
aa[LEN_2D][LEN_2D],bb[LEN_2D][LEN_2D],cc[LEN_2D][LEN_2D],tt[LEN_2D][LEN_2D];

int indx[LEN_1D];

real_t* __restrict__ xx;
real_t* yy;

// %2.5

void main()
{
//crossing thresholds
//index set splitting
//reverse data access

real_t x;
for (int nl = 0; nl < iterations; nl++) {
for (int i = 0; i < LEN_1D; i++) {
x = a[LEN_1D-i-1] + b[i] * c[i];
a[i] = x-(real_t)1.0;
b[i] = x;
}
dummy();
}
}


with FMA runs 18s and without 14s

[Bug middle-end/99638] New: s132 benchmarks of TSVC on zen3 benefits from -mno-fma

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

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

Bug ID: 99638
   Summary: s132 benchmarks of TSVC on zen3 benefits from -mno-fma
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

typedef float real_t;

#define iterations 100
#define LEN_1D 32000
#define LEN_2D 256
// array definitions
real_t flat_2d_array[LEN_2D*LEN_2D];

real_t x[LEN_1D];

real_t a[LEN_1D],b[LEN_1D],c[LEN_1D],d[LEN_1D],e[LEN_1D],
aa[LEN_2D][LEN_2D],bb[LEN_2D][LEN_2D],cc[LEN_2D][LEN_2D],tt[LEN_2D][LEN_2D];

int indx[LEN_1D];

real_t* __restrict__ xx;
real_t* yy;


// %2.5

void main()
{
//global data flow analysis
//loop with multiple dimension ambiguous subscripts

int m = 0;
int j = m;
int k = m+1;
for (int nl = 0; nl < 400*iterations; nl++) {
for (int i= 1; i < LEN_2D; i++) {
aa[j][i] = aa[k][i-1] + b[i] * c[1];
}
dummy();
}
}

compiled with -Ofast -march=native runs 4.4s compared to 4.2s with -Ofast
-march=native -mno-fma

[Bug c++/99637] bit_cast doesn't work with padding bits and it should

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

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

--- Comment #4 from Jonathan Wakely  ---
I think the relevant sentence is "Each bit of the value representation of the
result is equal to the corresponding bit in the object representation of from."

For one of the bits in the result, there is no corresponding bit in the object
representation of from. So the result cannot be created.

[Bug c++/99637] bit_cast doesn't work with padding bits and it should

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I'm CCing Jason and Jonathan too.

[Bug c++/99637] bit_cast doesn't work with padding bits and it should

[hanicka at hanicka dot net via Gcc-bugs]

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

--- Comment #2 from Hana Dusíková  ---
I know this is not an argument but MSVC accepts this code, meanwhile I'm asking
Richard what to do about it.

[Bug c++/99637] bit_cast doesn't work with padding bits and it should

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The result in your case doesn't have any padding bits, but the source has and
some value bits of the result need to be initialized from those padding bits.

[Bug c++/99637] New: bit_cast doesn't work with padding bits and it should

[hanicka at hanicka dot net via Gcc-bugs]

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

Bug ID: 99637
   Summary: bit_cast doesn't work with padding bits and it should
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hanicka at hanicka dot net
  Target Milestone: ---

Standard states in https://eel.is/c++draft/bit.cast#2 "Padding bits of the
result are unspecified."

Current trunk GCC (11.0.1 20210316) gives error in presence of padding bits:

https://compiler-explorer.com/z/MhKMb5

```
struct my_field
{
// change size to 64 and it will work
unsigned long long a : 63;
};

constexpr unsigned long long get_value(const auto & val) noexcept {
static_assert(sizeof(val) == sizeof(unsigned long long));

return __builtin_bit_cast(unsigned long long, val);
}

constexpr auto f = my_field{0};
constexpr auto v = get_value(f);
```

this is the error message GCC gives, but this shouldn't be a hard error

```
:14:29:   in 'constexpr' expansion of 'get_value(f)'
:10:31: error: '__builtin_bit_cast' accessing uninitialized byte at
offset 7
   10 | return __builtin_bit_cast(unsigned long long, val);
```

[Bug testsuite/99636] New: [10/11 regression] gcc.dg/strlenopt-80.c fails for 32 bits

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

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

Bug ID: 99636
   Summary: [10/11 regression] gcc.dg/strlenopt-80.c fails for 32
bits
   Product: gcc
   Version: 11.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:27c14dbc6b01d5b7238d9d6893bcddce19b7056c, r10-3920
make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
dg.exp=gcc.dg/strlenopt-80.c"
FAIL: gcc.dg/strlenopt-80.c scan-tree-dump-times optimized "failure_on_line
\\(" 0
# of expected passes1
# of unexpected failures1

32 bit fails.  This is on powerpc64 BE.  Still fails today for both trunk and
gcc 10.

see also PR92128

[Bug tree-optimization/99635] New: -Warray-bounds where -Wzero-length-bounds is expected

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

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

Bug ID: 99635
   Summary: -Warray-bounds where -Wzero-length-bounds is expected
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The store to p->da[1] is out of bounds and diagnosed as expected.  The store to
p->da[0], however, is in bounds but overlaps with p->b0i and so should be
diagnosed by -Wzero-length-bounds.

$ cat t.C && gcc -O2 -S -fdump-tree-vrp1=/dev/stdout -Wall t.C
inline void* operator new (__SIZE_TYPE__, void *p) { return p; }

struct B0 { int b0i; };
struct B1: virtual B0 { };
struct B2: virtual B0 { };
struct D: B1, B2 { int di, da[0]; };

void* f ()
{
  D *p = (D*)new char[sizeof (D) + 2 * sizeof (D::da[0])];
  p->da[0] = (char*)p->da - (char*)p;// -Wzero-length-bounds expected

  D d;
  p->da[1] = (char*) - (char*)  // -Warray-bounds (good)

  return p;
}


;; Function f (_Z1fv, funcdef_no=1, decl_uid=2404, cgraph_uid=11,
symbol_order=10)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

_6 -> { _3 }
Incremental SSA update started at block: 2
Number of blocks in CFG: 3
Number of blocks to update: 1 ( 33%)



Value ranges after VRP:

_3: void * [1B, +INF]
_6: struct D * [1B, +INF]  EQUIVALENCES: { _3 } (1 elements)


t.C: In function ‘void* f()’:
t.C:11:10: warning: array subscript 0 is outside array bounds of ‘int [0]’
[-Warray-bounds]
   11 |   p->da[0] = (char*)p->da - (char*)p;// -Wzero-length-bounds
expected
  |   ~~~^
t.C:6:28: note: while referencing ‘D::da’
6 | struct D: B1, B2 { int di, da[0]; };
  |^~
t.C:14:10: warning: array subscript 1 is outside array bounds of ‘int [0]’
[-Warray-bounds]
   14 |   p->da[1] = (char*) - (char*)  // -Warray-bounds (good)
  |   ~~~^
t.C:6:28: note: while referencing ‘D::da’
6 | struct D: B1, B2 { int di, da[0]; };
  |^~
void * f ()
{
  struct D * _3;

   [local count: 1073741824]:
  _3 = operator new [] (32);
  _3->da[0] = 20;
  _3->da[1] = 20;
  return _3;

}

[Bug middle-end/98099] ICE in gen_lowpart_common, at emit-rtl.c:1554

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

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

--- Comment #10 from Eric Botcazou  ---
> 2021-03-17  Jakub Jelinek  
> 
>   PR middle-end/98099
>   * gcc.dg/pr98099.c: Don't compile the test on pdp endian.
>   For big endian use -fsso-struct=little-endian dg-options.
> 
> --- gcc/testsuite/gcc.dg/pr98099.c.jj 2020-12-04 10:53:56.306043973 +0100
> +++ gcc/testsuite/gcc.dg/pr98099.c2021-03-17 20:05:07.714417723 +0100
> @@ -1,8 +1,9 @@
>  /* PR middle-end/98099 */
>  /* Reported by G. Steinmetz  */
>  
> -/* { dg-do compile { target dfp } } */
> -/* { dg-options "-fsso-struct=big-endian" } */
> +/* { dg-do compile { target { dfp && { be || le } } } } */
> +/* { dg-options "-fsso-struct=big-endian" { target le } } */
> +/* { dg-options "-fsso-struct=little-endian" { target be } } */
>  
>  struct S { _Decimal128 a; };

Yes, even better, thanks.

[Bug target/99620] Subtract with borrow (SBB) missed optimization

[chfast at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Paweł Bylica  ---
Can you give me introduction where and how to fix it? I have a longer list of
similar issues, so maybe it's good time to learn how to fix them myself.

FYI, clang is unifying both cases by changing `k = l > a.l` into `k = a.l <
b.l` and only having SUB_OVERFLOW match for `k = a.l < b.l` case.

[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708

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

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

--- Comment #13 from Jakub Jelinek  ---
Oops, thanks for catching that.  Made those changes and restarted testing.

[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708

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

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

--- Comment #12 from Christophe Lyon  ---
I have tests in progress too (with and without the fix), except that I have
typedef uint32x4_t i;
instead of
typedef uint32x2_t i;

and I replaced the (__builtin_neon_hi *) cast with (int16_t*)

[Bug c++/99617] gcc/cp/coroutines.cc:2807: member variables not initialised in constructor ?

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

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

--- Comment #6 from Iain Sandoe  ---
given that it blocks something else and that the fix is obvious, trivial and
confined to the coroutines implementation - my vote would be to make it.

(I do expect to touch that code if I have a chance to fix the remaining
coroutines bugs so, if not applied now, then I'll pick it up at that point).

[Bug sanitizer/99179] asan failures with -Os on x86_64-apple-darwin20

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

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

--- Comment #2 from Iain Sandoe  ---
I did some more checking on this.

1) It seems that something we produce in the unwind info for alloca is not
compatible with atos.

2) The objects all pass "dwarfdump --verify"

3) If I run the objects under lldb, breakpoints set by line number seem to work
properly.

4) If I use a recent llvm-symbolizer (ASAN_SYMBOLIZER_PATH=) the tests work.

5) the tests also work with clang / libsanitizer.

so, perhaps we have some subtle problem with the unwind information we produce
with -Os (and when there's an alloca or stack adjustment) - but I don't see
this as something I can address for GCC11 (even if it's fixable).

[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708

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

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

--- Comment #11 from Jakub Jelinek  ---
Created attachment 50415
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50415=edit
gcc11-pr99593.patch

Ok, trying to test this overnight.

[Bug middle-end/98099] ICE in gen_lowpart_common, at emit-rtl.c:1554

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
So something like following?

2021-03-17  Jakub Jelinek  

PR middle-end/98099
* gcc.dg/pr98099.c: Don't compile the test on pdp endian.
For big endian use -fsso-struct=little-endian dg-options.

--- gcc/testsuite/gcc.dg/pr98099.c.jj   2020-12-04 10:53:56.306043973 +0100
+++ gcc/testsuite/gcc.dg/pr98099.c  2021-03-17 20:05:07.714417723 +0100
@@ -1,8 +1,9 @@
 /* PR middle-end/98099 */
 /* Reported by G. Steinmetz  */

-/* { dg-do compile { target dfp } } */
-/* { dg-options "-fsso-struct=big-endian" } */
+/* { dg-do compile { target { dfp && { be || le } } } } */
+/* { dg-options "-fsso-struct=big-endian" { target le } } */
+/* { dg-options "-fsso-struct=little-endian" { target be } } */

 struct S { _Decimal128 a; };

[Bug tree-optimization/99632] missing warning accessing a trailing zero length array member of base class

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

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

--- Comment #2 from Martin Sebor  ---
The definition missing from comment #0 is:

  struct B { int n, a[0]; };

[Bug debug/99230] [11 Regression] gcc.dg/pr83527.c excess errors: '-fcompare-debug' failure (length)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 50414
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50414=edit
gcc11-pr99230.patch

Untested fix.

[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708

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

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #9)
> Comment on attachment 50412 [details]
> proposed testcase
> 
> Any reason not to replace
> __simd128_int32_t with int32x4_t ,
> __simd128_float32_t with float32x4_t and
> __simd128_uint32_t with uint32x2_t ?
> Drop the commented out __builtin_* names etc.?  Drop the (__builtin_neon_hi
> *) cast?
> Otherwise LGTM if it still FAILs without the above patch and PASSes with it,
> but the final call is Kyrill's (or other ARM maintainers').

Indeed. Let's have a consolidated patch on gcc-patches for review.

[Bug middle-end/99634] New: s2102 benchmarks of TSVC is vectorized better by icc than gcc

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

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

Bug ID: 99634
   Summary: s2102 benchmarks of TSVC is vectorized better by icc
than gcc
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

typedef float real_t;

#define iterations 10
#define LEN_1D 32000
#define LEN_2D 256
// array definitions

real_t
a[LEN_2D],d[LEN_2D],aa[LEN_2D][LEN_2D],bb[LEN_2D][LEN_2D],cc[LEN_2D][LEN_2D],tt[LEN_2D][LEN_2D];


int main(struct args_t * func_args)
{
//diagonals
//identity matrix, best results vectorize both inner and outer loops

for (int nl = 0; nl < 100*(iterations/LEN_2D); nl++) {
for (int i = 0; i < LEN_2D; i++) {
for (int j = 0; j < LEN_2D; j++) {
aa[j][i] = (real_t)0.;
}
aa[i][i] = (real_t)1.;
}
dummy();
}
   return aa[0][0];
}

is vectorized by ic as:
min:
# parameter 1: %rdi
..B1.1: # Preds ..B1.0
# Execution count [5.00e-03]
.cfi_startproc
..___tag_value_min.1:
..L2:
  #36.1
pushq %rbp  #36.1
.cfi_def_cfa_offset 16
movq  %rsp, %rbp#36.1
.cfi_def_cfa 6, 16
.cfi_offset 6, -16
andq  $-32, %rsp#36.1
movl  $aa, %edi #38.13
xorl  %esi, %esi#38.13
movl  $262144, %edx #38.13
call  _intel_fast_memset#38.13
# LOE rbx r12 r13 r14 r15
..B1.2: # Preds ..B1.1
# Execution count [1.00e+00]
vmovups   .L_2il0floatpacket.0(%rip), %ymm1 #41.24
xorl  %edx, %edx#37.9
xorl  %eax, %eax#37.9
vextractf128 $1, %ymm1, %xmm0   #41.13
# LOE rax rdx rbx r12 r13 r14 r15 xmm0 xmm1
..B1.3: # Preds ..B1.3 ..B1.2
# Execution count [2.56e+02]
vextractps $3, %xmm1, 44204+aa(%rax,%rdx,4) #41.13
lea   (%rax,%rdx,4), %rcx   #41.13
vmovss%xmm0, 45232+aa(%rax,%rdx,4)  #41.13
vextractps $1, %xmm0, 46260+aa(%rax,%rdx,4) #41.13
vextractps $2, %xmm0, 47288+aa(%rax,%rdx,4) #41.13
vextractps $3, %xmm0, 48316+aa(%rax,%rdx,4) #41.13
vmovss%xmm1, 49344+aa(%rax,%rdx,4)  #41.13
vextractps $1, %xmm1, 50372+aa(%rax,%rdx,4) #41.13
vextractps $2, %xmm1, 51400+aa(%rax,%rdx,4) #41.13
vextractps $3, %xmm1, 52428+aa(%rax,%rdx,4) #41.13
vmovss%xmm0, 53456+aa(%rax,%rdx,4)  #41.13
vextractps $1, %xmm0, 54484+aa(%rax,%rdx,4) #41.13
vextractps $2, %xmm0, 55512+aa(%rax,%rdx,4) #41.13
vextractps $3, %xmm0, 56540+aa(%rax,%rdx,4) #41.13
vmovss%xmm1, 57568+aa(%rax,%rdx,4)  #41.13
vextractps $1, %xmm1, 58596+aa(%rax,%rdx,4) #41.13
vextractps $2, %xmm1, 59624+aa(%rax,%rdx,4) #41.13
vextractps $3, %xmm1, 60652+aa(%rax,%rdx,4) #41.13
vmovss%xmm0, 61680+aa(%rax,%rdx,4)  #41.13
vextractps $1, %xmm0, 62708+aa(%rax,%rdx,4) #41.13
vextractps $2, %xmm0, 63736+aa(%rax,%rdx,4) #41.13
vextractps $3, %xmm0, 64764+aa(%rax,%rdx,4) #41.13
vmovss%xmm1, 65792+aa(%rax,%rdx,4)  #41.13
vextractps $1, %xmm1, 66820+aa(%rax,%rdx,4) #41.13
vextractps $2, %xmm1, 67848+aa(%rax,%rdx,4) #41.13
vextractps $3, %xmm1, 68876+aa(%rax,%rdx,4) #41.13
vmovss%xmm0, 69904+aa(%rax,%rdx,4)  #41.13
vextractps $1, %xmm0, 70932+aa(%rax,%rdx,4) #41.13
vextractps $2, %xmm0, 71960+aa(%rax,%rdx,4) #41.13
vextractps $3, %xmm0, 72988+aa(%rax,%rdx,4) #41.13
vmovss%xmm1, 74016+aa(%rax,%rdx,4)  #41.13
vextractps $1, %xmm1, 75044+aa(%rax,%rdx,4) #41.13
vextractps $2, %xmm1, 76072+aa(%rax,%rdx,4) #41.13
vextractps $3, %xmm1, 77100+aa(%rax,%rdx,4) 

[Bug tree-optimization/99414] s235, s2233, s275, s2275 and s233 benchmarks of TSVC is vectorized better by icc than gcc (loop interchange)

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

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|s235, s2233, s275 and s233  |s235, s2233, s275, s2275
   |benchmarks of TSVC is   |and s233 benchmarks of TSVC
   |vectorized better by icc|is vectorized better by icc
   |than gcc (loop interchange) |than gcc (loop interchange)

--- Comment #5 from Jan Hubicka  ---
s2275:
typedef float real_t;

#define iterations 10
#define LEN_1D 32000
#define LEN_2D 256
// array definitions

real_t
a[LEN_2D],b[LEN_2D],c[LEN_2D],d[LEN_2D],aa[LEN_2D][LEN_2D],bb[LEN_2D][LEN_2D],cc[LEN_2D][LEN_2D],tt[LEN_2D][LEN_2D];

int main(struct args_t * func_args)
{
//loop distribution is needed to be able to interchange

for (int nl = 0; nl < 100*(iterations/LEN_2D); nl++) {
for (int i = 0; i < LEN_2D; i++) {
for (int j = 0; j < LEN_2D; j++) {
aa[j][i] = aa[j][i] + bb[j][i] * cc[j][i];
}
a[i] = b[i] + c[i] * d[i];
}
dummy();
}
   return aa[0][0];
}

[Bug tree-optimization/99414] s235, s2233, s275 and s233 benchmarks of TSVC is vectorized better by icc than gcc (loop interchange)

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

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|s235, s2233 and s233|s235, s2233, s275 and s233
   |benchmarks of TSVC is   |benchmarks of TSVC is
   |vectorized better by icc|vectorized better by icc
   |than gcc (loop interchange) |than gcc (loop interchange)

--- Comment #4 from Jan Hubicka  ---
s275:
typedef float real_t;

#define iterations 10
#define LEN_1D 32000
#define LEN_2D 256
// array definitions

real_t
a[LEN_2D],d[LEN_2D],aa[LEN_2D][LEN_2D],bb[LEN_2D][LEN_2D],cc[LEN_2D][LEN_2D],tt[LEN_2D][LEN_2D];

int main(struct args_t * func_args)
{
//control flow
//if around inner loop, interchanging needed

for (int i = 0; i < LEN_2D; i++) 
aa[0][i]=1;

for (int nl = 0; nl < 10*(iterations/LEN_2D); nl++) {
for (int i = 0; i < LEN_2D; i++) {
if (aa[0][i] > (real_t)0.) {
for (int j = 1; j < LEN_2D; j++) {
aa[j][i] = aa[j-1][i] + bb[j][i] * cc[j][i];
}
}
}
dummy();
}
   return aa[0][0];
}

[Bug tree-optimization/99414] s235, s2233 and s233 benchmarks of TSVC is vectorized better by icc than gcc (loop interchange)

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

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|s235 and s233 benchmarks of |s235, s2233 and s233
   |TSVC is vectorized better   |benchmarks of TSVC is
   |by icc than gcc (loop   |vectorized better by icc
   |interchange)|than gcc (loop interchange)

--- Comment #3 from Jan Hubicka  ---
this one is 7s with gcc and 0.4s with icc.

typedef float real_t;

#define iterations 10
#define LEN_1D 32000
#define LEN_2D 256
// array definitions

real_t
aa[LEN_2D][LEN_2D],bb[LEN_2D][LEN_2D],cc[LEN_2D][LEN_2D],tt[LEN_2D][LEN_2D];

int main(struct args_t * func_args)
{
//loop interchange
//interchanging with one of two inner loops

for (int nl = 0; nl < 100*(iterations/LEN_2D); nl++) {
for (int i = 1; i < LEN_2D; i++) {
for (int j = 1; j < LEN_2D; j++) {
aa[j][i] = aa[j-1][i] + cc[j][i];
}
for (int j = 1; j < LEN_2D; j++) {
bb[i][j] = bb[i-1][j] + cc[i][j];
}
}
dummy();
}

   return aa[0][0];
}

[Bug tree-optimization/99414] s235 and s233 benchmarks of TSVC is vectorized better by icc than gcc (loop interchange)

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

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|s235 benchmark of TSVC is   |s235 and s233 benchmarks of
   |vectorized better by icc|TSVC is vectorized better
   |than gcc (loop interchange) |by icc than gcc (loop
   ||interchange)

--- Comment #2 from Jan Hubicka  ---
another testcase

typedef float real_t;

#define iterations 10
#define LEN_1D 32000
#define LEN_2D 256
// array definitions

real_t
aa[LEN_2D][LEN_2D],bb[LEN_2D][LEN_2D],cc[LEN_2D][LEN_2D],tt[LEN_2D][LEN_2D];

int main(struct args_t * func_args)
{
//loop interchange
//interchanging with one of two inner loops

for (int nl = 0; nl < 100*(iterations/LEN_2D); nl++) {
for (int i = 1; i < LEN_2D; i++) {
for (int j = 1; j < LEN_2D; j++) {
aa[j][i] = aa[j-1][i] + cc[j][i];
}
for (int j = 1; j < LEN_2D; j++) {
bb[j][i] = bb[j][i-1] + cc[j][i];
}
}
dummy();
}

   return aa[0][0];
}

[Bug middle-end/99633] New: s1113 benchmark of TSVC is unrolled by icc and not by gcc and runs faster on znver3

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

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

Bug ID: 99633
   Summary: s1113 benchmark of TSVC is unrolled by icc and not by
gcc and runs faster on znver3
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

typedef float real_t;

#define iterations 10
#define LEN_1D 32000
#define LEN_2D 256
// array definitions

real_t a[LEN_1D],b[LEN_1D],c[LEN_1D],d[LEN_1D],e[LEN_1D];

int main(struct args_t * func_args)
{

//linear dependence testing
//one iteration dependency on a(LEN_1D/2) but still vectorizable

//initialise_arrays(__func__);
//gettimeofday(_args->t1, NULL);

for (int nl = 0; nl < 2*iterations; nl++) {
for (int i = 0; i < LEN_1D; i++) {
a[i] = a[LEN_1D/2] + b[i];
}
//dummy(a, b, c, d, e, aa, bb, cc, 0.);
}

return a[10];
}

Is unrolled twice by icc and runs 1.5s instead of 2.6s when built with gcc.
-funroll-loops fixes the issue, but it suggests we may want to unroll by
default on zver3

[Bug target/99581] [11 Regression] internal compiler error: during RTL pass: final - void QTWTF::TCMalloc_PageHeap::scavengerThread() since r11-7526

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

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

--- Comment #11 from Vladimir Makarov  ---
Introducing a new memory constraint can take some time.

I guess we could switch off the offending code meanwhile because it is compiler
crash vs unoptimal generated code choice.

I'll investigate how switching the code off affects GCC tests on aarhc64.

[Bug target/99581] [11 Regression] internal compiler error: during RTL pass: final - void QTWTF::TCMalloc_PageHeap::scavengerThread() since r11-7526

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

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

--- Comment #10 from Vladimir Makarov  ---
(In reply to Segher Boessenkool from comment #7)

> The addition of those extra args makes clear that the function is no
> longer just testing if it is a valid address.  It should be renamed.
> 

I don't like it too.  When I first look at the patch I though it is a recursive
call.  For active C++ programmer function overloading is not the problem but
imho it is better to rename the function/

[Bug tree-optimization/99632] missing warning accessing a trailing zero length array member of base class

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

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

--- Comment #1 from Andrew Pinski  ---
The code is chopped off and does not declare the struct B.

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #19 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #18)
> Just tried the #c14 testcase with GCC 4.7.2 (ok, not -gdwarf-5, just -g3) and
> with
> GNU ld version 2.22.52.0.1-10.fc17 20120131
> and it works fine.
> So it is the linker that regressed here.

Can you please attach both corresponding object files and the assembly file?

[Bug target/99581] [11 Regression] internal compiler error: during RTL pass: final - void QTWTF::TCMalloc_PageHeap::scavengerThread() since r11-7526

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

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

--- Comment #9 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #8)
> Rather than a target hook, isn't it a property of a particular constraint?
> This constraint implies "m", this one doesn't?
> Make the implies "m" behavior the default one and add some syntax in the
> *.md files to declare constraints that have the new behavior?
> Kind like define_memory_constraint vs. define_special_memory_constraint
> difference.

Yes, I think it is better solution.  I guess aarch64 might have the same
problem as in this PR.  We should have different treatment of memory
constraints even for one target.

[Bug rtl-optimization/99627] ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347 with -fprofile-use -fselective-scheduling -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -O3 -fno-strict-

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

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

--- Comment #4 from Martin Liška  ---
Created attachment 50413
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50413=edit
Reduced .gcda file

[Bug rtl-optimization/99627] ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347 with -fprofile-use -fselective-scheduling -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -O3 -fno-strict-

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-17
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Martin Liška  ---
Confirmed.

[Bug tree-optimization/99632] New: missing warning accessing a trailing zero length array member of base class

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

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

Bug ID: 99632
   Summary: missing warning accessing a trailing zero length array
member of base class
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

-Warray-bounds triggers for the invalid access in f() and g() but not in h(). 
All three should be diagnosed.  In addition, the warning in g() should be on
the line with the access.

$ cat t.C && gcc -O2 -S -Wall t.C
struct D: B { int j; };

void f (D *p, int i)
{
  p->a[i] = 0; // -Warray-bounds (good)
}

void g (D *p, int i)
{
  int *q = >a[i];   //-Warray-bounds (should be on next line)
  *q = 0; 
}

void h (D *p, int i)
{
  int *q = p->a;
  q[i] = 0;// missing warning
}


t.C: In function ‘void f(D*, int)’:
t.C:6:9: warning: array subscript i is outside array bounds of ‘int [0]’
[-Warray-bounds]
6 |   p->a[i] = 0; // -Warray-bounds (good)
  |   ~~^
t.C:1:19: note: while referencing ‘B::a’
1 | struct B { int n, a[0]; };
  |   ^
t.C: In function ‘void g(D*, int)’:
t.C:11:19: warning: array subscript i is outside array bounds of ‘int [0]’
[-Warray-bounds]
   11 |   int *q = >a[i];   //-Warray-bounds (should be on next line)
  | ~~^
t.C:1:19: note: while referencing ‘B::a’
1 | struct B { int n, a[0]; };
  |   ^

[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated

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

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

--- Comment #16 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #15)
> > LGTM.  It's by Paul.  He simply needs to get the testcase's dg-foo right...
> > ;-)
> 
> Now I'm confused. So you consider the fix ok? Will it then be committed?

The fix was basically OKed on the fortran ML by Tobias, he only wondered
if there should be a runtime test.  One could simply change the line

! { dg-do compile }

to

! { dg-do run }

before committing.  Still confused?

[Bug c++/99631] New: decltype of non-type template-parameter shouldn't be const

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 99631
   Summary: decltype of non-type template-parameter shouldn't be
const
   Product: gcc
   Version: 11.0
   URL: https://godbolt.org/z/4YY5r3
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/4YY5r3.
```C++
#include
templateconstexpr bool is_const=std::is_const_v;
struct A{};
static_assert(!is_const);
```
```
:4:15: error: static assertion failed
4 | static_assert(!is_const);
  |   ^~
Compiler returned: 1
```
See https://bugs.llvm.org/show_bug.cgi?id=49609#c1 for an explanation.

[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708

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

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

--- Comment #9 from Jakub Jelinek  ---
Comment on attachment 50412
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50412
proposed testcase

Any reason not to replace
__simd128_int32_t with int32x4_t ,
__simd128_float32_t with float32x4_t and
__simd128_uint32_t with uint32x2_t ?
Drop the commented out __builtin_* names etc.?  Drop the (__builtin_neon_hi *)
cast?
Otherwise LGTM if it still FAILs without the above patch and PASSes with it,
but the final call is Kyrill's (or other ARM maintainers').

[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708

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

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to Christophe Lyon from comment #7)
> Created attachment 50412 [details]
> proposed testcase
> 
> Here is a proposal for a testcase derived from the initial description:
> - added relevant dg-* directives
> - replaced builtin calls with intrinsics
> 
> Jakub, Kyrill, is that OK with you?

Thanks, that looks ok except:
+typedef __simd128_int32_t g;
+typedef __simd128_float32_t h;
+typedef __simd128_uint32_t i;

Can we replace them with the right ACLE types as well?

[Bug target/99593] [11 Regression] arm Neon ICE when compiling firefox (skia) since r11-6708

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

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

--- Comment #7 from Christophe Lyon  ---
Created attachment 50412
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50412=edit
proposed testcase

Here is a proposal for a testcase derived from the initial description:
- added relevant dg-* directives
- replaced builtin calls with intrinsics

Jakub, Kyrill, is that OK with you?

[Bug middle-end/99630] missing -Warray-bounds accessing a trailing array of a virtual base class

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

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

--- Comment #1 from Martin Sebor  ---
It might be worth warning for any out of bounds access to trailing members of
polymorphic classes, regardless of whether the type of the complete enclosing
object is known (and known to be derived virtually).

[Bug middle-end/99630] New: missing -Warray-bounds accessing a trailing array of a virtual base class

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

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

Bug ID: 99630
   Summary: missing -Warray-bounds accessing a trailing array of a
virtual base class
   Product: gcc
   Version: 11.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: ---

GCC issues -Warray-bounds for the out of bounds access to an object with an
ordinary base class in f() but not for the same out of bounds access to an
object with a virtual base class in g().  Both access should be diagnosed.

The problem is that trailing_array() calls array_at_struct_end_p() which
returns true for trailing array members without considering the type of the
enclosing object.

$ cat u.C && gcc -O2 -S -Wall -fdump-tree-vrp1=/dev/stdout u.C
struct A1
{
  virtual ~A1 ();
  int a1a[1];
};

struct A2
{
  virtual ~A2 ();
  int a2a[1];
};

struct B1: A1 { };
struct B2: A2 { };
struct D1: B1, B2 { };

void f (D1 *p)
{
  extern D1 d1;
  p->a1a[0] = (char*)d1.a1a - (char*)
  p->a1a[1] = (char*)d1.a2a - (char*)   // -Warray-bounds (good)
}

struct V1: virtual A1 { };
struct V2: virtual A2 { };

struct D2: V1, V2 { };

void f (D2 *p)
{
  extern D2 d2;
  p->a1a[0] = (char*)d2.a1a - (char*)
  p->a1a[1] = (char*)d2.a2a - (char*)   // missing -Warray-bounds
}

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

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

p_5 -> { p_2(D) }
Incremental SSA update started at block: 2
Number of blocks in CFG: 3
Number of blocks to update: 1 ( 33%)



Value ranges after VRP:

p_2(D): struct D1 * VARYING
p_5: struct D1 * [1B, +INF]  EQUIVALENCES: { p_2(D) } (1 elements)


u.C: In function ‘void f(D1*)’:
u.C:21:11: warning: array subscript 1 is above array bounds of ‘int [1]’
[-Warray-bounds]
   21 |   p->a1a[1] = (char*)d1.a2a - (char*)   // -Warray-bounds (good)
  |   ^
u.C:4:7: note: while referencing ‘A1::a1a’
4 |   int a1a[1];
  |   ^~~
void f (struct D1 * p)
{
   [local count: 1073741824]:
  p_2(D)->D.2450.D.2409.a1a[0] = 8;
  p_2(D)->D.2450.D.2409.a1a[1] = 24;
  return;

}



;; Function f (_Z1fP2D2, funcdef_no=1, decl_uid=2566, cgraph_uid=2,
symbol_order=1)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

_9 -> { _4 }
p_10 -> { p_6(D) }
Incremental SSA update started at block: 2
Number of blocks in CFG: 3
Number of blocks to update: 1 ( 33%)



Value ranges after VRP:

_1: int (*) () * VARYING
_2: long int VARYING
_3: sizetype VARYING
_4: struct D2 * [1B, +INF]
p_6(D): struct D2 * VARYING
_9: struct D2 * [1B, +INF]  EQUIVALENCES: { _4 } (1 elements)
p_10: struct D2 * [1B, +INF]  EQUIVALENCES: { p_6(D) } (1 elements)


void f (struct D2 * p)
{
  int (*) () * _1;
  long int _2;
  sizetype _3;
  struct D2 * _4;

   [local count: 1073741824]:
  _1 = p_6(D)->D.2549._vptr.V1;
  _2 = MEM[(long int *)_1 + -24B];
  _3 = (sizetype) _2;
  _4 = p_6(D) + _3;
  MEM[(struct A1 *)_4].a1a[0] = 24;
  MEM[(struct A1 *)_4].a1a[1] = 40;   <<< _4's type is D2 and a1a[1] overlaps
its _vptr
  return;

}

[Bug ada/99624] Address sanitizer detects heap-buffer-overflow in namet.adb

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

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

--- Comment #5 from Eric Botcazou  ---
> I am very very rusty on Ada, what should I do to check that Id is good?

Probably put back the original assert on line 155.

[Bug ada/99624] Address sanitizer detects heap-buffer-overflow in namet.adb

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Vittorio Zecca  ---
I added

pragma Assert (Id in Name_Entries.Table'Range);

at namet.adb:156, but then I get at compile time

namet.adb:156:25: warning: condition can only be False if invalid values
present

and the build stops.
I am very very rusty on Ada, what should I do to check that Id is good?

[Bug ada/99624] Address sanitizer detects heap-buffer-overflow in namet.adb

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED

--- Comment #3 from Eric Botcazou  ---
> Yes, probably gcc -fsanitize=address is miscompiling the Ada compiler.
> I had to take out the -gnata option to disable pragma assert that was
> failing.

OK, thanks for the confirmation.

> So I do not know if this is a genuine compiler bug or it is due to
> miscompilation.

Most probably -fsanitize=address does not work correctly on Ada code.

> The Ada compiler compiled with the undefined behavior sanitizer
> compiles and works fine with a successful run of the testsuite.

Interesting data point, thanks.

[Bug c++/76262] list-initialization prefers initializer_list over copy constructor

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
See Bug 85577 and it's duplicates too.

[Bug c++/99629] Misleading diagnostic when looking up rewritten candidate and failing

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-03-17
   Keywords||diagnostic

[Bug c++/76262] list-initialization prefers initializer_list over copy constructor

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

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

--- Comment #6 from Jonathan Wakely  ---
This behaviour is what the standard (still) requires.

[Bug c++/99629] New: Misleading diagnostic when looking up rewritten candidate and failing

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 99629
   Summary: Misleading diagnostic when looking up rewritten
candidate and failing
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

>From StackOverflow (https://stackoverflow.com/q/66674463/2069064):

#include 

struct S {};

int operator<=>(S, int) { return 0;  }
S   operator<=>(S,   S) { return {}; }

auto x = S{} < S{};

gcc correctly rejects this code as ill-formed. However, the diagnostic provided
is:

:8:14: error: no match for 'operator<' (operand types are 'S' and
'int')
8 | auto x = S{} < S{};
  |  ^

This is technically correct (in the sense that the compiler should be looking
for, specifically, an operator< between S and 0 and fail because it does not
find such a thing) but it's quite a confusing diagnostic since (a) the
highlighted line is not comparing an S to an int and (b) it sure looks like
from the code that you can compare an S to an int. 

It would be nice if the diagnostic somehow made clear that having found
operator<=>(S, S) that it's trying to resolve S{} < S{} as (S{} <=> S{}) < 0
and that subsequent lookup doesn't consider rewritten candidates somehow. 

Not especially high priority (I don't expect this to be an especially common
idiom...), more of a nice to have.

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #18 from Jakub Jelinek  ---
Just tried the #c14 testcase with GCC 4.7.2 (ok, not -gdwarf-5, just -g3) and
with
GNU ld version 2.22.52.0.1-10.fc17 20120131
and it works fine.
So it is the linker that regressed here.

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

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

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

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
I think we should do a variation on (3): use poly-int subtraction
in rtx_vector_builder::step but force the returned value to a constant
using to_constant ().  The justification is that the encoding
requires the step to be constant, but doesn't require the individual
elements to be.

[Bug testsuite/99626] [10/11 regression] gcc.dg/strlenopt-73.c fails for 32 bits

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

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

--- Comment #1 from Jakub Jelinek  ---
Doesn't FAIL on i686-linux.
I wonder if it is SLOW_UNALIGNED_ACCESS or something similar that for powerpc64
-m32 causes a lot of memcpy calls not to be folded.
grep memcpy strlenopt-73.c.023t.ssa 
  memcpy (pa_41, iftmp.0_21, 17);
  memcpy (pa_49, iftmp.2_22, 17);
  memcpy (pa_56, iftmp.4_23, 16);
  memcpy (pa_63, iftmp.6_24, 15);
  memcpy (pa_78, iftmp.10_26, 32);
  memcpy (pa_85, iftmp.12_27, 31);
  memcpy (pa_92, iftmp.14_28, 30);
is the same between i686 and powerpc64 -m64, while for powerpc64 -m32 shows
grep memcpy strlenopt-73.c.023t.ssa 
  memcpy (pa_41, iftmp.0_21, 17);
  memcpy (pa_49, iftmp.2_22, 17);
  memcpy (pa_56, iftmp.4_23, 16);
  memcpy (pa_63, iftmp.6_24, 15);
  memcpy (pa_78, iftmp.10_26, 32);
  memcpy (pa_85, iftmp.12_27, 31);
  memcpy (pa_92, iftmp.14_28, 30);
  memcpy (pa_25, iftmp.20_13, 8);
  memcpy (pa_33, iftmp.22_14, 8);
  memcpy (pa_40, iftmp.24_15, 8);
  memcpy (pa_47, iftmp.26_16, 8);
  memcpy (pa_54, iftmp.28_17, 8);
  memcpy (pa_61, iftmp.30_18, 8);

The test_copy_cond_unequal_length_i128 has the following misleading comment:
#if __i386__ && __SIZEOF_INT128__ == 16

/* The following tests assume GCC transforms the memcpy calls into
   int128_t assignments which it does only on targets that define
   the MOVE_MAX macro to 16.  That's only s390 and i386 with
   int128_t support.  */
I bet it is never tested, because __int128 isn't supported on 32-bit targets.
But __i386__ is defined only on 32-bit x86, so perhaps it meant to use
__x86_64__ define instead?

And test_copy_cond_unequal_length_i64 is essentially the same except with
smaller size, so it again relies on targets transforming the memcpy calls to
long long assignments.
And there is a lot of targets that define MOVE_MAX to 4 or smaller:
config/arc/arc.h:#define MOVE_MAX 4
config/arm/arm.h:#define MOVE_MAX 4
config/c6x/c6x.h:#define MOVE_MAX 4
config/cr16/cr16.h:#define MOVE_MAX 4
config/cris/cris.h:#define MOVE_MAX 4
config/csky/csky.h:#define MOVE_MAX 4
config/ft32/ft32.h:#define MOVE_MAX 4
config/h8300/h8300.h:#define MOVE_MAX   4
config/iq2000/iq2000.h:#define MOVE_MAX 4
config/lm32/lm32.h:#define MOVE_MAXUNITS_PER_WORD
config/m32c/m32c.h:#define MOVE_MAX 4
config/m32r/m32r.h:#define MOVE_MAX 4
config/m68k/m68k.h:#define MOVE_MAX 4
config/mcore/mcore.h:#define MOVE_MAX 4
config/microblaze/microblaze.h:#define MOVE_MAX 4
config/mn10300/mn10300.h:#define MOVE_MAX   4
config/moxie/moxie.h:#define MOVE_MAX 4
config/nds32/nds32.h:#define MOVE_MAX 4
config/nios2/nios2.h:#define MOVE_MAX 4
config/or1k/or1k.h:#define MOVE_MAX 4
config/pdp11/pdp11.h:#define MOVE_MAX 2
config/rl78/rl78.h:#define MOVE_MAX 2
config/rs6000/rs6000.h:#define MOVE_MAX (! TARGET_POWERPC64 ? 4 : 8)
config/rx/rx.h:#define MOVE_MAX 4
config/sh/sh.h:#define MOVE_MAX (4)
config/stormy16/stormy16.h:#define MOVE_MAX 2
config/v850/v850.h:#define MOVE_MAX 4
config/visium/visium.h:#define MOVE_MAX 4
config/xtensa/xtensa.h:#define MOVE_MAX 4

So IMNSHO that function should be compiled only on a couple of targets known to
fold memcpy (, , 8);
to the assignments.

[Bug testsuite/99626] [10/11 regression] gcc.dg/strlenopt-73.c fails for 32 bits

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.3

[Bug preprocessor/99446] [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1005

[sbergman at redhat dot com via Gcc-bugs]

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

--- Comment #3 from Stephan Bergmann  ---
(In reply to Stephan Bergmann from comment #2)
> At least with recent GCC master (bc2127767a0076afdbc9075fda29f97f82ef7ec6),
> I can consistently reproduce the following:

what I failed to include in comment 2 is

> $ cat test.cc
> #include 

[Bug c++/99628] New: g++ fails to do the implicit conversion when rewritten operator<=>

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99628
   Summary: g++ fails to do the implicit conversion when rewritten
operator<=>
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

gcc-trunk rejects this valid code:

struct S{
  operator int() { return 0; }
};

auto operator<=>(S, S) { return S{}; }

int main() {
  return S{} < S{};
}

(godbolt://godbolt.org/z/9ah1xE)


The expression S{} < S{} would be rewritten as (S{} <=> S{}) < 0, since the
(S{} <=> S{}) return S{}, we compare S{} with 0, and S{} explicit convert to 0,
so we compare 0 < 0 which is false, but gcc-trunk rejects with:

:8:14: error: no match for 'operator<' (operand types are 'S' and
'int')
8 |   return S{} < S{};

[Bug ada/99624] Address sanitizer detects heap-buffer-overflow in namet.adb

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Vittorio Zecca  ---
Yes, probably gcc -fsanitize=address is miscompiling the Ada compiler.
I had to take out the -gnata option to disable pragma assert that was failing.

So I do not know if this is a genuine compiler bug or it is due to
miscompilation.

The Ada compiler compiled with the undefined behavior sanitizer
compiles and works fine
with a successful run of the testsuite.

[Bug rtl-optimization/99627] ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347 with -fprofile-use -fselective-scheduling -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -O3 -fno-strict-

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

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

--- Comment #2 from qinzhao at gcc dot gnu.org ---
NOTE, this failure is on aarch64.

[Bug rtl-optimization/99627] ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347 with -fprofile-use -fselective-scheduling -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -O3 -fno-strict-

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

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

--- Comment #1 from qinzhao at gcc dot gnu.org ---
Created attachment 50411
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50411=edit
testing case and script

testing case and script

[Bug rtl-optimization/99627] New: ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347 with -fprofile-use -fselective-scheduling -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops -O3 -fno-st

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

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

Bug ID: 99627
   Summary: ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347
with -fprofile-use -fselective-scheduling
-fsel-sched-pipelining
-fsel-sched-pipelining-outer-loops -O3
-fno-strict-aliasing
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

Another selective scheduler's bug with profiling feedback from CPU2017.
reduced testing case attached.

to reproduce:

download the *.tar.xz file;
untar it;
cd bug_4
sh t

qinzhao@gcc113:~/Bugs/bug_4$ sh t
during RTL pass: sched1
cfgloop.h: In function ‘loop_optimizer_finalize’:
cfgloop.h:41:1: internal compiler error: in sel_is_loop_preheader_p, at
sel-sched-ir.c:6347
0xcb24b3 sel_is_loop_preheader_p(basic_block_def*)
../../latest_gcc/gcc/sel-sched-ir.c:6347
0xcc5307 sel_sched_region_1
../../latest_gcc/gcc/sel-sched.c:7588
0xcc68bb sel_sched_region(int)
../../latest_gcc/gcc/sel-sched.c:7634
0xcc68bb sel_sched_region(int)
../../latest_gcc/gcc/sel-sched.c:7619
0xcc6ae7 run_selective_scheduling()
../../latest_gcc/gcc/sel-sched.c:7720
0xca511f rest_of_handle_sched
../../latest_gcc/gcc/sched-rgn.c:3724
0xca511f execute
../../latest_gcc/gcc/sched-rgn.c:3834
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ipa/96825] [11 Regression] Commit r11-2645 degrades CPU2017 548.exchange2_r by 35%

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

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

--- Comment #3 from Bill Schmidt  ---
Is this going to be addressed in GCC 11?  Should this be only a P3?

[Bug ipa/96825] [11 Regression] Commit r11-2645 degrades CPU2017 548.exchange2_r by 35%

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782 for more analysis

[Bug ipa/96825] [11 Regression] Commit r11-2645 degrades CPU2017 548.exchange2_r by 35%

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 CC||jakub at gcc dot gnu.org
Summary|Commit r11-2645 degrades|[11 Regression] Commit
   |CPU2017 548.exchange2_r by  |r11-2645 degrades CPU2017
   |35% |548.exchange2_r by 35%

[Bug ada/99624] Address sanitizer detects heap-buffer-overflow in namet.adb

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #1 from Eric Botcazou  ---
> While building the ada compiler the address sanitizer detecst an
> heap-buffer-overflow in namet.adb line 157:
> 
>  Index : constant Int   := Name_Entries.Table (Id).Name_Chars_Index;
> 
> because Id=-3

The table is declared like this though:

   package Name_Entries is new Table.Table (
 Table_Component_Type => Name_Entry,
 Table_Index_Type => Valid_Name_Id'Base,
 Table_Low_Bound  => First_Name_Id,
 Table_Initial=> Alloc.Names_Initial,
 Table_Increment  => Alloc.Names_Increment,
 Table_Name   => "Name_Entries");

with:

   First_Name_Id : constant Name_Id := Names_Low_Bound + 2;
   --  Subscript of first entry in names table

   subtype Valid_Name_Id is Name_Id range First_Name_Id .. Name_Id'Last;
   --  All but No_Name and Error_Name

and:

  Names_Low_Bound : constant := -3;

so Id = -3 is well within the allowed range (9997 0-based index).

Are you sure that Id is not equal to Names_Low_Bound, which would be the -2
0-based index and, therefore, -32 bytes since the size of Name_Entry is 16?

On the other hand, this would mean that:

  pragma Assert (Is_Valid_Name (Id));

would have triggered because the compiler is supposed to be configured with
assertions enabled on the mainline, so I'm quite at a loss here.

It looks like the address sanitizer is miscompiling the Ada compiler?

[Bug target/99530] [i386] 'P' inline assembly operand modifier should obey -fno-plt

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |11.0
 Status|NEW |RESOLVED

--- Comment #15 from H.J. Lu  ---
It is fixed by

The master branch has been updated by H.J. Lu :

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

commit r11-7701-gadf14bdbc10d4114865a08cf20020a2616039057
Author: H.J. Lu 
Date:   Thu Mar 11 06:48:24 2021 -0800

x86: Update 'P' operand modifier for -fno-plt

Update 'P' operand modifier for -fno-plt to support inline assembly
statements.  In 64-bit, we can always load function address with
@GOTPCREL.  In 32-bit, we load function address with @GOT only for
non-PIC since PIC register may not be available at call site.

gcc/

PR target/99504
* config/i386/i386.c (ix86_force_load_from_GOT_p): Support
inline assembly statements.
(ix86_print_operand): Update 'P' handling for -fno-plt.

gcc/testsuite/

PR target/99504
* gcc.target/i386/pr99530-1.c: New test.
* gcc.target/i386/pr99530-2.c: Likewise.
* gcc.target/i386/pr99530-3.c: Likewise.
* gcc.target/i386/pr99530-4.c: Likewise.
* gcc.target/i386/pr99530-5.c: Likewise.
* gcc.target/i386/pr99530-6.c: Likewise.

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #17 from Jakub Jelinek  ---
No.  The point is that the compiler splits macros from each of the includes
into a separate comdat .debug_macro section, the TU .debug_macro additions
should stay but they macros from the same headers should be merged when
identical.

[Bug tree-optimization/99504] Missing memmove detection

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

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

--- Comment #3 from H.J. Lu  ---
(In reply to CVS Commits from comment #2)
> The master branch has been updated by H.J. Lu :
> 
> https://gcc.gnu.org/g:adf14bdbc10d4114865a08cf20020a2616039057
> 
> commit r11-7701-gadf14bdbc10d4114865a08cf20020a2616039057
> Author: H.J. Lu 
> Date:   Thu Mar 11 06:48:24 2021 -0800
> 
> x86: Update 'P' operand modifier for -fno-plt
> 
> Update 'P' operand modifier for -fno-plt to support inline assembly
> statements.  In 64-bit, we can always load function address with
> @GOTPCREL.  In 32-bit, we load function address with @GOT only for
> non-PIC since PIC register may not be available at call site.
> 
> gcc/
> 
> PR target/99504
> * config/i386/i386.c (ix86_force_load_from_GOT_p): Support
> inline assembly statements.
> (ix86_print_operand): Update 'P' handling for -fno-plt.
> 
> gcc/testsuite/
> 
> PR target/99504
> * gcc.target/i386/pr99530-1.c: New test.
> * gcc.target/i386/pr99530-2.c: Likewise.
> * gcc.target/i386/pr99530-3.c: Likewise.
> * gcc.target/i386/pr99530-4.c: Likewise.
> * gcc.target/i386/pr99530-5.c: Likewise.
> * gcc.target/i386/pr99530-6.c: Likewise.

Wrong PR number in commit log.

[Bug tree-optimization/99504] Missing memmove detection

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

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

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

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

commit r11-7701-gadf14bdbc10d4114865a08cf20020a2616039057
Author: H.J. Lu 
Date:   Thu Mar 11 06:48:24 2021 -0800

x86: Update 'P' operand modifier for -fno-plt

Update 'P' operand modifier for -fno-plt to support inline assembly
statements.  In 64-bit, we can always load function address with
@GOTPCREL.  In 32-bit, we load function address with @GOT only for
non-PIC since PIC register may not be available at call site.

gcc/

PR target/99504
* config/i386/i386.c (ix86_force_load_from_GOT_p): Support
inline assembly statements.
(ix86_print_operand): Update 'P' handling for -fno-plt.

gcc/testsuite/

PR target/99504
* gcc.target/i386/pr99530-1.c: New test.
* gcc.target/i386/pr99530-2.c: Likewise.
* gcc.target/i386/pr99530-3.c: Likewise.
* gcc.target/i386/pr99530-4.c: Likewise.
* gcc.target/i386/pr99530-5.c: Likewise.
* gcc.target/i386/pr99530-6.c: Likewise.

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #16 from H.J. Lu  ---
(In reply to Richard Biener from comment #15)
> So as expected all of the linkers are happy with
> 
> .section.gnu.debuglto_.debug_macro,"e",@progbits
> .Ldebug_macro0:
> .long   debug_macro2
> .section.gnu.debuglto_.debug_macro,"eG",@progbits,wm4,comdat
> .globl debug_macro2
> debug_macro2:
> .value  0x4

You can put the first .gnu.debuglto_.debug_macro in a comdat group section.

[Bug libstdc++/99433] [11 Regression] custom friend pipe-operator| conflicts with range adaptor?

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-03-17

--- Comment #2 from Patrick Palka  ---
I think the underlying problem here is excessive instantiation due to usage of
deduced return types, which leads to hard errors during overload resolution.

If I give the lambda in your testcase a concrete return type decltype(nucl + '
'), and apply the following change to  (giving concrete return types to
a couple of lambdas therein) then we accept the testcase.

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges  
index 1be74beb860..9fd647c144f 100644   
--- a/libstdc++-v3/include/std/ranges   
+++ b/libstdc++-v3/include/std/ranges   
@@ -803,7 +803,11 @@ namespace views
// otherwise capture by value.  
auto __closure  
  = [...__args(__maybe_refwrap(std::forward<_Args>(__args)))]   
-(_Range&& __r) {  
+(_Range&& __r)
+ -> decltype(_Callable{}(std::forward<_Range>(__r),
+  (static_cast>> 
+   (__args))...)) {
  // This static_cast has two purposes: it forwards a   
  // reference_wrapper capture as a T&, and otherwise
  // forwards the captured argument as an rvalue.   
@@ -1655,6 +1659,7 @@ namespace views   
   {
 inline constexpr __adaptor::_RangeAdaptor transform
   = []  (_Range&& __r, _Fp&& __f) 
+  -> decltype(transform_view{std::forward<_Range>(__r),
std::forward<_Fp>(__f)})
   {
return transform_view{std::forward<_Range>(__r),
std::forward<_Fp>(__f)};
   };   


For maximum SFINAE friendliness, all the range adaptors objects should probably
be changed to avoid using deduced return types, in a manner similar to the
above.  While we're at it, we should make them conditionally noexcept.

[Bug c/99623] Code behaves differently at -O2 optimization

[sebastiano.vigna at unimi dot it via Gcc-bugs]

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

--- Comment #10 from Sebastiano Vigna  ---
Ahem no, my correction goes in the opposite direction it should go. I'll ask
suggestions to the library authors.

I really apologize for all the noise.

[Bug testsuite/99626] New: [10/11 regression] gcc.dg/strlenopt-73.c fails for 32 bits

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

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

Bug ID: 99626
   Summary: [10/11 regression] gcc.dg/strlenopt-73.c fails for 32
bits
   Product: gcc
   Version: 11.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: ---

This is an old one but I don't see a PR for it.  Note that PR91449 fixed this
for 64 bit.

g:34fcf41e30ff56155e996f5e04f6ca13948a19b6, r10-2528
make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
dg.exp=gcc.dg/strlenopt-73.c"
FAIL: gcc.dg/strlenopt-73.c scan-tree-dump-times optimized "strlen" 0
FAIL: gcc.dg/strlenopt-73.c scan-tree-dump-times optimized "_not_eliminated_" 0
# of expected passes1
# of unexpected failures2

The revision is where the test case was added in gcc 10 and it still fails for
32 bits on powerpc64 BE now in both gcc 10 and trunk.

commit 34fcf41e30ff56155e996f5e04f6ca13948a19b6
Author: Martin Sebor 
Date:   Wed Aug 14 16:27:59 2019 +

PR tree-optimization/91294 - [10 Regression] wrong strlen result of a
conditional with an offset

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #15 from Richard Biener  ---
So as expected all of the linkers are happy with

.section.gnu.debuglto_.debug_macro,"e",@progbits
.Ldebug_macro0:
.long   debug_macro2
.section.gnu.debuglto_.debug_macro,"eG",@progbits,wm4,comdat
.globl debug_macro2
debug_macro2:
.value  0x4

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #14 from Jakub Jelinek  ---
Looking at current binutils, it seems to misbehave though.
If I compile:
pr99618.c:
#include 
int i;
pr99618-2.c:
#include 
extern int i;

int
main ()
{
  return i++;
}
gcc -g3 -gdwarf-5 -O2 -o pr99618{,.c,-2.c}
then readelf -wm shows:
Contents of the .debug_macro section:

  Offset:  0x0
  Version: 5
  Offset size: 4
  Offset into .debug_line: 0x0

 DW_MACRO_import - offset : 0x14a
 DW_MACRO_start_file - lineno: 0 filenum: 1 filename: pr99618.c
 DW_MACRO_start_file - lineno: 0 filenum: 2 filename:
/usr/include/stdc-predef.h
 DW_MACRO_import - offset : 0x9a0
 DW_MACRO_end_file
...
  Offset:  0x14a
  Version: 5
  Offset size: 4

 DW_MACRO_define_strp - lineno : 0 macro : __STDC__ 1
 DW_MACRO_define_strp - lineno : 0 macro : __STDC_VERSION__ 201710L
...
  Offset:  0x11c2
  Version: 5
  Offset size: 4
  Offset into .debug_line: 0x1ec

 DW_MACRO_import - offset : 0x0
 DW_MACRO_start_file - lineno: 0 filenum: 1 filename: pr99618-2.c
 DW_MACRO_start_file - lineno: 0 filenum: 2 filename:
/usr/include/stdc-predef.h
 DW_MACRO_import - offset : 0x0
 DW_MACRO_end_file

Obviously the last two DW_MACRO_import should have been 0x14a and 0x9a0.
I don't think we can use a global symbol though, we don't want that exported
from libraries, nor have any special naming for those.

[Bug c++/76262] list-initialization prefers initializer_list over copy constructor

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

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #5 from Arthur O'Dwyer  ---
GCC still has the buggy behavior as of 2021. This bug should be reopened.

GCC's behavior here disagrees with all of Clang, ICC, MSVC, and common sense.

// https://godbolt.org/z/GKxh8P
struct A {};
struct B {
B(const B&);
explicit B(std::initializer_list);
operator A() const;
};

extern B b;
void test() {
auto a{b};  // constructs as if by `B a = { static_cast(b) }`, not `B a
= b`
}

I recently observed real teaching materials claiming that brace-initialization
didn't work for copies -- if you want to invoke the copy constructor you MUST
use parentheses -- and giving essentially this bug as the reason. (They
apparently didn't realize that this behavior was unique to GCC, and the subject
of a bug report.)

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||amodra at gcc dot gnu.org

--- Comment #13 from Richard Biener  ---
In the end the question is what the spec for ELF says here.

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #12 from Richard Biener  ---
Btw, gold happily links w/o a problem.  lld (from llvm9) reports

> ld.lld -r bad.o bad.o
ld.lld: warning: relocation refers to a discarded section:
.gnu.debuglto_.debug_macro
>>> referenced by bad.o:(.rela.gnu.debuglto_.debug_macro+0x4)

looks like gold adjusts SECTION relocs upon comdat section "merging"

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #11 from Jakub Jelinek  ---
It has never been global.  All it needs is the start of the comdat section.
And GCC is doing it that way for 9.5 years already.

[Bug c++/99604] GC related ICE in 23_containers/vector/modifiers/insert_vs_emplace.cc

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

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

--- Comment #6 from Nathan Sidwell  ---
Myth Plausible

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #10 from Richard Biener  ---
(In reply to H.J. Lu from comment #9)
> (In reply to Jakub Jelinek from comment #6)
> > I don't see how that is any different from the above.  The intent is (and it
> > has been working fine for years) that linker merges the comdat sections with
> > the same hash into one, and the import relocations resolve to the start of
> > that section.
> 
> This works if the symbol reference to the comdat section is global.

Ah, yeah.  The issue is we get a SECTION relocation because we use a
local label here?

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|REOPENED|NEW

--- Comment #9 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #6)
> I don't see how that is any different from the above.  The intent is (and it
> has been working fine for years) that linker merges the comdat sections with
> the same hash into one, and the import relocations resolve to the start of
> that section.

This works if the symbol reference to the comdat section is global.

[Bug c/99623] Code behaves differently at -O2 optimization

[sebastiano.vigna at unimi dot it via Gcc-bugs]

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

--- Comment #9 from Sebastiano Vigna  ---
Finally solved: the problematic statement

if (h == NULL) h = (struct prb_node *)>prb_root;

should just be

if (h == NULL) h = tree->prb_root->prb_link[0];

The position in memory of the two pointers is the same, but the second access
has the right type. I guess the GNU libavl author wanted to save an
indirection, but did not realize the possible dangers.

For the user, this behavior of the optimizer remains very confusing tho.

[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #15 from Jürgen Reuter  ---
(In reply to anlauf from comment #14)
> (In reply to Jürgen Reuter from comment #13)
> > Cool, thanks for the quick reaction, Paul. Maybe Harald can have a look at
> > it as well :D
> 
> LGTM.  It's by Paul.  He simply needs to get the testcase's dg-foo right...
> ;-)

Now I'm confused. So you consider the fix ok? Will it then be committed?

[Bug debug/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #8 from H.J. Lu  ---
(In reply to Richard Biener from comment #5)
> Maybe it's an assembler bug that it fails to set 'E' on the GROUP section?
> 

SHF_EXLCUDE doesn't apply to "ld -r".

[Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #7 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #6)
> For normal non-LTO debug macro we emit:
> .section.debug_macro,"",@progbits
> .Ldebug_macro0:
> .value  0x5 # DWARF macro version number
> .byte   0x2 # Flags: 32-bit, lineptr present
> .long   .Ldebug_line0
> .byte   0x7 # Import
> .long   .Ldebug_macro2
> ...
> .section   
> .debug_macro,"G",@progbits,wm4.0.d634b2ca9ddb72f687ab125549c033d0,comdat
> .Ldebug_macro2:
> .value  0x5 # DWARF macro version number
> .byte   0   # Flags: 32-bit
> .byte   0x5 # Define macro strp
> .uleb128 0  # At line number 0
> ...
> I don't see how that is any different from the above.  The intent is (and it
> has been working fine for years) that linker merges the comdat sections with
> the same hash into one, and the import relocations resolve to the start of
> that section.

Same result:

[hjl@gnu-cfl-2 pr27590]$ cat bad2.s 
.section.gnu.debuglto_.debug_macro,"",@progbits
.Ldebug_macro0:
.long   .Ldebug_macro2
.section.gnu.debuglto_.debug_macro,"G",@progbits,wm4,comdat
.Ldebug_macro2:
.value  0x4
[hjl@gnu-cfl-2 pr27590]$ gcc -c bad2.s
[hjl@gnu-cfl-2 pr27590]$ ld -r bad2.o bad2.o
`.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro'
of bad2.o: defined in discarded section `.gnu.debuglto_.debug_macro[wm4]' of
bad2.o
[hjl@gnu-cfl-2 pr27590]$

[Bug c++/99604] GC related ICE in 23_containers/vector/modifiers/insert_vs_emplace.cc

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Nathan Sidwell from comment #4)
> I wonder if this was an instance of 99423?

It doesn't use any modules, so unlikely.  I thought of PR99447 instead but
since it doesn't reproduce...

[Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #6 from Jakub Jelinek  ---
For normal non-LTO debug macro we emit:
.section.debug_macro,"",@progbits
.Ldebug_macro0:
.value  0x5 # DWARF macro version number
.byte   0x2 # Flags: 32-bit, lineptr present
.long   .Ldebug_line0
.byte   0x7 # Import
.long   .Ldebug_macro2
...
.section   
.debug_macro,"G",@progbits,wm4.0.d634b2ca9ddb72f687ab125549c033d0,comdat
.Ldebug_macro2:
.value  0x5 # DWARF macro version number
.byte   0   # Flags: 32-bit
.byte   0x5 # Define macro strp
.uleb128 0  # At line number 0
...
I don't see how that is any different from the above.  The intent is (and it
has been working fine for years) that linker merges the comdat sections with
the same hash into one, and the import relocations resolve to the start of that
section.

[Bug c++/99604] GC related ICE in 23_containers/vector/modifiers/insert_vs_emplace.cc

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

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

--- Comment #4 from Nathan Sidwell  ---
I wonder if this was an instance of 99423?

[Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #5 from Richard Biener  ---
Maybe it's an assembler bug that it fails to set 'E' on the GROUP section?

Section Headers:
  [Nr] Name  Type Address   Offset
   Size  EntSize  Flags  Link  Info  Align
  [ 0]   NULL   
        0 0 0
  [ 1] .groupGROUP  0040
   0008  0004   8 6 4
...
  [ 5] .gnu.debuglt[...] PROGBITS   0048
   0004     E   0 0 1
  [ 6] .rela.gnu.de[...] RELA   0118
   0018  0018   I   8 5 8
  [ 7] .gnu.debuglt[...] PROGBITS   004c
   0002    GE   0 0 1

COMDAT group section [1] `.group' [wm4] contains 1 sections:
   [Index]Name
   [7]   .gnu.debuglto_.debug_macro

[Bug c++/99625] New: GCC does not detect narrowing in aggregate initialization

[dangelog at gmail dot com via Gcc-bugs]

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

Bug ID: 99625
   Summary: GCC does not detect narrowing in aggregate
initialization
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dangelog at gmail dot com
  Target Milestone: ---

Testcase:

extern long double l;

struct S {
S(int) {}
};

S s[] = { l };


This is supposed to be ill-formed because of narrowing. GCC does not reject the
code, nor it warns (as it usually does for narrowing).

The relevant rule is in [dcl.init.aggr]:

https://eel.is/c++draft/dcl.init.aggr#4.2.sentence-2

> Otherwise, the element is copy-initialized from the corresponding 
> initializer-clause or is initialized with the brace-or-equal-initializer of 
> the corresponding designated-initializer-clause.
> If that initializer is of the form assignment-expression or = 
> assignment-expression and a narrowing conversion ([dcl.init.list]) is 
> required to convert the expression, the program is ill-formed.


That rule has been changed in C++20 with designated initializers, but the same
one was also there for C++17 and before, e.g.
https://timsong-cpp.github.io/cppwp/n4659/dcl.init.aggr#3


For comparison, Clang accepts with no warnings, but MSVC warns about narrowing.

[Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

--- Comment #4 from Richard Biener  ---
(In reply to H.J. Lu from comment #3)
> This is what GCC generates:
> 
> hjl@gnu-cfl-2 pr27590]$ cat bad.s
>   .section.gnu.debuglto_.debug_macro,"e",@progbits
> .Ldebug_macro0:
>   .long   .Ldebug_macro2
>   .section.gnu.debuglto_.debug_macro,"eG",@progbits,wm4,comdat
> .Ldebug_macro2:
>   .value  0x4
> [hjl@gnu-cfl-2 pr27590]$ gcc -c bad.s
> [hjl@gnu-cfl-2 pr27590]$ ld -r bad.o bad.o
> `.gnu.debuglto_.debug_macro' referenced in section
> `.gnu.debuglto_.debug_macro' of bad.o: defined in discarded section
> `.gnu.debuglto_.debug_macro[wm4]' of bad.o
> [hjl@gnu-cfl-2 pr27590]$

what's wrong with it?  All sections are marked as to be Excluded, that
the excluded sections reference each other should be irrelevant?  I suppose
that one s comdat confuses the linker?

[Bug c/99623] Code behaves differently at -O2 optimization

[sebastiano.vigna at unimi dot it via Gcc-bugs]

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

--- Comment #8 from Sebastiano Vigna  ---
I'm sorry, I did the test on the wrong file. No, you cannot eliminate the &,
even if the type is correct, and h can be NULL at that point. I'll ask the
libavl maintainers their opinion. We can compile with that option but other
people might incur in the same problem.

[Bug c++/99604] GC related ICE in 23_containers/vector/modifiers/insert_vs_emplace.cc

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Richard Biener  ---
Didn't reproduce today, tried with --param ggc-min-expand=0 --param
ggc-min-heapsize=0 as well which also did not reproduce the issue.

[Bug lto/99618] `.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro' of X defined in discarded section

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|MOVED   |---
   Last reconfirmed||2021-03-17
 Status|RESOLVED|REOPENED
 Ever confirmed|0   |1

--- Comment #3 from H.J. Lu  ---
This is what GCC generates:

hjl@gnu-cfl-2 pr27590]$ cat bad.s
.section.gnu.debuglto_.debug_macro,"e",@progbits
.Ldebug_macro0:
.long   .Ldebug_macro2
.section.gnu.debuglto_.debug_macro,"eG",@progbits,wm4,comdat
.Ldebug_macro2:
.value  0x4
[hjl@gnu-cfl-2 pr27590]$ gcc -c bad.s
[hjl@gnu-cfl-2 pr27590]$ ld -r bad.o bad.o
`.gnu.debuglto_.debug_macro' referenced in section `.gnu.debuglto_.debug_macro'
of bad.o: defined in discarded section `.gnu.debuglto_.debug_macro[wm4]' of
bad.o
[hjl@gnu-cfl-2 pr27590]$

[Bug lto/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #11 from Jan Hubicka  ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447
> 
> --- Comment #10 from Richard Biener  ---
> So like this.
> 
> diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> index 80140757d16..447d9a920f7 100644
> --- a/gcc/cgraph.c
> +++ b/gcc/cgraph.c
> @@ -1854,6 +1854,9 @@ cgraph_node::release_body (bool keep_arguments)
>   needed to emit debug info later.  */
>if (!used_as_abstract_origin && DECL_INITIAL (decl))
>  DECL_INITIAL (decl) = error_mark_node;
> +  /* Zap references to call stmts of our body.  */
> +  for (cgraph_edge *e = callees; e; e = e->next_callee)
> +e->call_stmt = NULL;

Looks good but will also need to warlk indirect calls.
However I wonder in what situations it makes sense to release body but
keep cgraph edges?

Honza
>release_function_body (decl);
>if (lto_file_data)
>  {
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.