[Bug target/99621] [8/9/10/11 REGRESSION] [bisected to 058e97ecf33ad0dfd926b3876a4bcf59ac9556ff] regression with -m32 -O1 -fcaller-saves -fexpensive-optimizations

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Confirmed. I'm trying to simplify the test-case..

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[8/9/10/11 REGRESSION]  |[8/9/10/11 Regression]
   |[bisected to|Wrong code with -m32 -O1
   |058e97ecf33ad0dfd926b3876a4 |-fcaller-saves
   |bcf59ac9556ff] regression   |-fexpensive-optimizations
   |with -m32 -O1   |since
   |-fcaller-saves  |g:058e97ecf33ad0dfd926b3876
   |-fexpensive-optimizations   |a4bcf59ac9556ff
 CC||vmakarov at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
I just removed all the warnings that were reported:

#include 
int a = 12243, g, ad, o, p;
enum { b = 8 };
typedef struct {
  int data_len;
} d;
double e;
struct j ak;
struct j am_sj;
d main_breaks_blob;
double q(char *aa, int *ab, int c) {
  double n;
  int i = *ab;
  g = 1;
  if (aa[i] == '-') {
g = -1;
i++;
  }
  n = 0;
  while (aa[i] >= '0') {
n = n * 10 + aa[i] - '0';
i++;
  }
  if (aa[i] == '.')
i++;
  e = 1.0;
  while (aa[i] >= '0') {
e *= 10;
n += (aa[i] - '0') / e;
i++;
  }
  n *= g;
  *ab = i;
  return n;
}
struct j {
  FILE *k;
} l(d *m, int r) {
  int ae = 1;
  ad = r;
  while (ad >= 10) {
ae++;
ad /= 10;
  }
  m->data_len += ae;
  m->data_len++;
}
void af(char *aa, int ag, int ah, double *ai, int aj) {
  for (; p < ah; p++) {
double n = 0;
o++;
while (aa[o] >= '0') {
  n = n * 10 + aa[o] - '0';
  o++;
}
ai[p] = n;
  }
}
void am(char *an, d *m) {
  int ao, ap, aq, ac, ag, ab, aw;
  double ar, as, at, au, av;
  char aa[8192];
  struct j *ay, *f = &am_sj;
  FILE *az;
  char *ba = an;
  f->k = fopen(ba, "r");
  ak = *f;
  ay = &ak;
  az = ay->k;
  m->data_len = b + 1;
  while (aw != EOF) {
ag = 0;
while (aw != '\r' && ag < 92) {
  aa[ag++] = aw;
  aw = getc(az);
}
while (aw == '\n' || aw == '\r')
  aw = getc(az);
if (__builtin_strncmp(aa, "%%HiResBoundingBox", 9) == 0) {
  int i;
  double ai[4];
  i = 19;
  af(&aa[i], i, 4, ai, 0);
  ar = ai[3];
}
ab = 0;
int bb;
double bc, bd;
bb = 0;
if (aa[ab] == 'g')
  bb = ab = 2;
bc = q(aa, &ab, ac);
ab++;
bd = q(aa, &ab, ac);
ab++;
if (bb)
  au += bc;
if (!as && __builtin_memcmp(&aa[ab], "1 dup neg S t", 3) == 0) {
  as = au = bc;
  av = bd;
}
if (aa[ab] == 'm' && aw == '<') {
  bc += au;
  bd += av + ar;
  if (bd > at || bc > a * 72 / 7227) {
double be;
int bf = bd < at;
be = bd;
if (bd - at < 2)
  be += 8;
if (bf)
  aq += ap;
at = bd;
ap = be;
ao = (aq + be) * 7227 / 72;
l(m, ao);
  }
}
  }
}
int main() {
  am("4329652-1.eps", &main_breaks_blob);
  printf("%d %s\n", main_breaks_blob,
 main_breaks_blob.data_len == 5167 ? "bug" : "ok");
}

Leaving that to Vlad.

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

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Known to fail||11.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-17

--- Comment #2 from Richard Biener  ---
Confirmed.  For sub_good we detect .SUB_OVERFLOW while for sub_bad we do not.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Are you sure this just isn't an excess precision problem in all the floating
point calculations?
-mfpmath=sse -msse2 makes it go away, -fexcess-precision=standard too.
Why is 5167 bad but both 4806 and 5749 I'm getting with other options are good?
When I try it on with -m64, at -O0 I get 7019, at -O1 and higher 4806.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from William Bader  ---
`gcc -S -m32 -O2 bfinal-format.c` with Fedora 32 gcc 10.2.1 gives a section
similar to one in my first comment. In particular, it calls fucomi "floating
unordered compare of st(0) and st(i)" and then fstp "floating store of st(0)
and then pop fpu 
 stack". fstp can change the condition registers set by fucomi. It sets C1 for
stack underflow, and its actions on C0, C2, and C3 are undefined. Does every
place that generates fstp in config/i386/i386.c know that it can modify the C
flags? Maybe the bad executable still works correctly in valgrind because
valgrind's emulation of fstp doesn't trash the C flags.
.L42:
testl   %esi, %esi
je  .L43
fldl8(%esp)
faddl   (%esp)
fstpl   8(%esp)
.L43:
fldz
fldl16(%esp)
fucomi  %st(1), %st 
fstp%st(1)
jp  .L105
jne .L106

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Yeah.  If you write it explicitly as:
auto sub_good(u128 a, u128 b)
{
u64 l;
bool k = __builtin_sub_overflow (a.l, b.l, &l);
auto h = a.h - b.h - k;
return u128{l, h};
}
it will be optimized too.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

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

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

--- Comment #6 from Jakub Jelinek  ---
fucomi sets %eflags in addition to some effects on c[0-3] in FPU flags, fstp
has some effects on c[0-3] in FPU flags.  Nothing in the program really cares
about the FPU flags.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from William Bader  ---
>Are you sure this just isn't an excess precision problem in all the floating 
>point calculations?


I am pretty sure that it isn't a precision problem because the original program
is parsing numbers from postscript, and they are all in a reasonable range
between 0 and 3000 with at most 4 decimal places.

>-mfpmath=sse -msse2 makes it go away, -fexcess-precision=standard too.
>Why is 5167 bad but both 4806 and 5749 I'm getting with other options are good?


The original program makes list with the starting Y position of each line.
The buffer ends up 4287 when it runs correctly and 5167 when it fails.

I cut the program down with creduce, targeting 5167.
creduce eliminated the saves of Y position to the buffer.


I don't think that it is a precision problem because the output would still
work if it was off by a little bit.

Also, the original program works correctly with -m32 and -m64 with various
options and with clang with various options. If fails only with gcc -m32 -O2. A
precision problem would probably give different results with different
optimization levels, different architectures, or different compilers. Also, the
original program has an #if that calls an empty function. Enabling that call
makes it work with gcc -m32 -O2. I think that is a strong sign that it is not a
precision error.

If you want, I can post the program before I fed it to creduce. It is 962 lines
and is human-readable.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from William Bader  ---
Created attachment 50404
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50404&action=edit
example program before creduce

This is the example that I cut from a much larger module. The problematic area
is around the line `#if DBUG_FIX`.

$ rm a.out ; gcc -Wall -O9 gcc-bug1-init.c ; a.out # ok in m64
len 4287, good
$ rm a.out ; gcc -m32 -Wall -O9 gcc-bug1-init.c ; a.out # fails in m32 -O9
len 5167, expected bad
$ rm a.out ; gcc -m32 -Wall -O0 gcc-bug1-init.c ; a.out # ok in m32 -O0
len 4287, good
$ rm a.out ; gcc -m32 -Wall -O9 -DBUG_FIX=1 gcc-bug1-init.c gcc-bug1b.c ; a.out
# ok in m32 -O9 calling an empty function
gcc-bug1-init.c: In function ‘find_ad_image_breaks’:
gcc-bug1-init.c:756:4: warning: implicit declaration of function ‘gcc_bug_fix’
[-Wimplicit-function-declaration]
  756 |gcc_bug_fix();
  |^~~
len 4287, good
$ cat gcc-bug1b.c 
void gcc_bug_fix(void) { }
$ rm a.out ; clang -m32 -Wall -O3 gcc-bug1-init.c ; a.out # ok in clang
gcc-bug1-init.c:154:19: warning: illegal character encoding in string literal
[-Winvalid-source-encoding]
  memcmp(buf, COREL_HEADER_STRING, COREL_HEADER_STRING_LEN) != 0) {
  ^~~
gcc-bug1-init.c:130:30: note: expanded from macro 'COREL_HEADER_STRING'
#define COREL_HEADER_STRING ""  /* start of header
*/
 ^~~~
1 warning generated.
len 4287, good
$ uname -a
Linux laptop 5.10.22-100.fc32.x86_64 #1 SMP Tue Mar 9 17:40:24 UTC 2021 x86_64
x86_64 x86_64 GNU/Linux
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
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 --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 10.2.1 20201125 (Red Hat 10.2.1-9) (GCC)

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

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

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

--- Comment #9 from Martin Liška  ---
(In reply to William Bader from comment #8)
> Created attachment 50404 [details]
> example program before creduce

I modified the file to:
  find_ad_image_breaks("123", "4329652-1.eps", 0, 0, &breaks_blob,

but I see the following:
$ gcc pr99621-2.c && ./a.out 
len 9, unknown bad

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com via Gcc-bugs]

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

--- Comment #10 from William Bader  ---
The program before creduce has debug code. Setting the variable to print the
debug code makes the program work. Usually for something like this, I would put
in debug code and see where the good and bad versions first differ, but that
doesn't work because any call to an external function (even to an empty
function) makes the program work. That is why I first suspected it was related
to -fcaller-saves.
In MSDOS days, stdio data was often in low memory, and null pointer references
would sometimes get into stdio buffers, and adding a printf would keep it from
doing damage, but I do not think that is the case with this program because
just calling a an empty function makes it work. Also, the program runs cleanly
in valgrind, gcc -fsanitize=undefined, and bounds-checking-gcc
http://williambader.com/bounds/example.html 
and neither gcc, gcc -fanalyzer, or clang give warnings about uninitialized
variables.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

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

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

--- Comment #11 from Martin Liška  ---
(In reply to William Bader from comment #10)
> The program before creduce has debug code. Setting the variable to print the
> debug code makes the program work.

Can you please attach a version that works with the provided .eps file?

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com via Gcc-bugs]

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

--- Comment #12 from William Bader  ---
>I modified the file to:

Sorry about that. I hadn't originally intended to post that file, and I forgot
to clean it up.

>len 9, unknown bad

That means that the data file isn't valid. I posted a binary file that needs to
be uncompressed by bzip2 to make a viewable EPSF (eps with an embedded TIFF
preview). The program needs the uncompressed file. I had to compress it to get
under the byte limit for attachments.
The buffer that the program generates has a count and then a list of Y
positions of lines.
A length of 9 is probably just the count and one Y position of 0 from not being
able to parse the file.
I cut it from a much larger program, and I removed some of the error checks.
My guess is that the test program was looking at the compressed file or that
the decompression was done in text mode on a system that converts to msdos line
endings.
This is what the data file should be
$ ls -l 4329652-1.eps
-rw-rw-rw- 1 william william 32 Mar 17 09:09 4329652-1.eps
$ sum 4329652-1.eps
21790 1
$ md5sum 4329652-1.eps
3b34996094eb7f27ae046d9cae25587e  4329652-1.eps

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #13 from Martin Liška  ---
(In reply to William Bader from comment #12)
> >I modified the file to:
> 
> Sorry about that. I hadn't originally intended to post that file, and I
> forgot to clean it up.

I understand that.

> 
> >len 9, unknown bad
> 
> This is what the data file should be
> $ ls -l 4329652-1.eps
> -rw-rw-rw- 1 william william 32 Mar 17 09:09 4329652-1.eps
> $ sum 4329652-1.eps
> 21790 1
> $ md5sum 4329652-1.eps
> 3b34996094eb7f27ae046d9cae25587e  4329652-1.eps

It seems you attached a different file then:
$ ls -l 4329652-1.eps
-rw-r--r-- 1 marxin users 2134013 Mar 17 10:21 4329652-1.eps
$ md5sum 4329652-1.eps
25607f50713e15f2bae5c322b95a8014  4329652-1.eps

[Bug tree-optimization/93964] [8/9 Regression] [graphite] ICE in assign_parameter_index_in_region, at graphite-scop-detection.c:1104

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Biener
:

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

commit r9-9287-gbb0ec9cffb1d0a3326d8c4ed197717fc08eeec37
Author: Richard Biener 
Date:   Wed Mar 4 10:40:32 2020 +0100

tree-optimization/93964 - adjust ISL code generation for pointer params

Pointers eventually need intermediate conversions in code generation.
Allowing them is much easier than fending them off since niter
and scev expansion easily drag those in.

2020-02-04  Richard Biener  

PR tree-optimization/93964
* graphite-isl-ast-to-gimple.c
(gcc_expression_from_isl_ast_expr_id): Add intermediate
conversion for pointer to integer converts.
* graphite-scop-detection.c (assign_parameter_index_in_region):
Relax assert.

* gcc.dg/graphite/pr93964.c: New testcase.

(cherry picked from commit dca54007ebb5d49c3d6cea63ee87fd8f3ccb9ca5)

[Bug tree-optimization/98117] [8/9 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:4db478784807708c031a77ae11850529fa5ecff1

commit r9-9288-g4db478784807708c031a77ae11850529fa5ecff1
Author: Richard Biener 
Date:   Mon Dec 7 10:29:07 2020 +0100

tree-optimization/98117 - fix range set by vectorization on niter IVs

This avoids the degenerate case of a TYPE_MAX_VALUE latch iteration
count value causing wrong range info for the vector IV.  There's
still the case of VF == 1 where if we don't know whether we hit the
above case we cannot emit a range.

2020-12-07  Richard Biener  

PR tree-optimization/98117
* tree-vect-loop-manip.c (vect_gen_vector_loop_niters):
Properly handle degenerate niter when setting the vector
loop IV range.

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

(cherry picked from commit 69894ce172412996c10c89838717980ede7c9003)

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com via Gcc-bugs]

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

--- Comment #14 from William Bader  ---
>It seems you attached a different file then:

Sorry. I was testing how the 9 result came out, and I put in a small file. I've
been up all night. It is 9:30am my time.

This is the real file. It looks like it matches your file.

$ ls -l 4329652-1.eps 
-r--r--r-- 1 william william 2134013 Mar 16 23:05 4329652-1.eps
$ sum 4329652-1.eps 
32813  2084
$ md5sum 4329652-1.eps 
25607f50713e15f2bae5c322b95a8014  4329652-1.eps

[Bug tree-optimization/98282] [8/9 Regression] Segmentation fault when compiling with optimization >= 2

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:9bb84bd30dcfcdc12f69b148d4dcf8f2e3fe8046

commit r9-9289-g9bb84bd30dcfcdc12f69b148d4dcf8f2e3fe8046
Author: Richard Biener 
Date:   Mon Jan 4 11:40:40 2021 +0100

tree-optimization/98282 - classify V_C_E as nary

This avoids running into memory reference code in compute_avail by
properly classifying unfolded reference trees on constants.

2021-01-04  Richard Biener  

PR tree-optimization/98282
* tree-ssa-sccvn.c (vn_get_stmt_kind): Classify tcc_reference on
invariants as VN_NARY.

* g++.dg/opt/pr98282.C: New testcase.

(cherry picked from commit edb7dbc25de455300ce066a2ebe728256ea46e3a)

[Bug tree-optimization/98758] [9 Regression] ice in lambda_matrix_right_hermite by r9-3927

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:396cc56368a68d25456ea5a29c24069e46ae5f46

commit r9-9290-g396cc56368a68d25456ea5a29c24069e46ae5f46
Author: Richard Biener 
Date:   Wed Jan 20 08:48:34 2021 +0100

tree-optimization/98758 - fix integer arithmetic in data-ref analysis

This fixes some int arithmetic issues and a bogus truncation.

2021-01-20  Richard Biener  

PR tree-optimization/98758
* tree-data-ref.c (int_divides_p): Use lambda_int arguments.
(lambda_matrix_right_hermite): Avoid undefinedness with
signed integer abs and multiplication.
(analyze_subscript_affine_affine): Use lambda_int.

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

(cherry picked from commit 85977f624a34eac309f9d77a58164553dfc82975)

[Bug target/98891] [10/11 regression] Neon logical operations not vectorized in DImode since g:cdfc0e863a03698a80c74896cbdc9f5c8c652e64

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Reduced testcase:
extern unsigned long long a, b, c;

void
foo (void)
{
  a = b | ~c;
}

Seems this is the usual dilemma between split double-word operations early vs.
split it late, each has its advantages and serious disadvantages.
By splitting early, combiner can't really do much with it, it is split into
loads, not, or and store of the halves separately and combiner doesn't see the
two halves together, one would need essentially vectorization on RTL to match
that.

[Bug tree-optimization/98758] [9 Regression] ice in lambda_matrix_right_hermite by r9-3927

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to fail||9.3.0
 Status|ASSIGNED|RESOLVED
  Known to work||9.3.1

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

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

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

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

--- Comment #15 from Martin Liška  ---
> This is the real file. It looks like it matches your file.

Good. But then my comment 9 is still and I cannot reproduce your problem..

[Bug target/98891] [10/11 regression] Neon logical operations not vectorized in DImode since g:cdfc0e863a03698a80c74896cbdc9f5c8c652e64

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

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

--- Comment #2 from Jakub Jelinek  ---
E.g. x86_64 (both -m32 and -m64) keeps the double-word logicals in the IL, then
has its machine dependent stv pass that promotes some sets of operations into
SIMD ones and finally (admittedly, clearly too late) splits the double-word
operations into the operations on halves when SIMD wasn't beneficial.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com via Gcc-bugs]

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

--- Comment #16 from William Bader  ---
Is your pr99621-2.c somewhere that I can look at it?
I tried downloading all of the attachments, and it all works for me, on my
Fedora 32 laptop and on a CentOS 6 test server.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

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

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

--- Comment #17 from Martin Liška  ---
(In reply to William Bader from comment #16)
> Is your pr99621-2.c somewhere that I can look at it?

Sure, it's here:
https://gist.githubusercontent.com/marxin/21562b2795430152de5a18ee89fc4e89/raw/5ffbcfb5d7f433c191816b1a27ffedcb88547a35/pr99621-2.c

> I tried downloading all of the attachments, and it all works for me, on my
> Fedora 32 laptop and on a CentOS 6 test server.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com via Gcc-bugs]

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

--- Comment #18 from William Bader  ---
Created attachment 50405
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50405&action=edit
the example program with the binary string constant replaced

Thanks for posting it. Your copy of the example C program was corrupted.

The example program has binary text at line 130: 
#define COREL_HEADER_STRING should define xC5 xD0 xD3 xC6
in pr99621-2.c, they have been encoded as UTF-8.

I changed the constant to use "\xC5\xD0\xD3\xC6"

I think that in one of the comments, I showed a clang diagnostic complaining
about that constant.

In addition, I removed the path from the file name at the end.

Also, if you are not on Linux, the second parameter to the fopen() at line 218
might need to be changed from "r" to "rb".

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #19 from Martin Liška  ---
> Thanks for posting it. Your copy of the example C program was corrupted.

Thanks, now I can reproduce it. I'll try to reduce it ..

[Bug tree-optimization/99296] [11 Regression] ICE:in irange_set_anti_range, at value-range.cc:205 with "-Os -fno-toplevel-reorder -fno-tree-bit-ccp" since r11-5105-ga5f9c27bfc441722

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
signed 1 bit precision are always a nightmare to deal with.
  wide_int lim1 = wi::sub (w_min, 1, sign, &ovf);
  gcc_checking_assert (ovf != wi::OVF_OVERFLOW);
1 is not really representable in that type, which is why I think we're getting
the overflow.  So I think we need to use
  wide_int lim1
= !sign && w_min.get_precision () == 1
  ? wi::add (w_min, -1, sign, &ovf)
  : wi::sub (w_min, 1, sign, &ovf);
instead.
And in the other spot in the same function the other way around (when it is
called on signed precision 1 -1, -1.  One can't wi::add (w_max, 1, sign, &ovf)
either, needs wi::sub (w_max, -1, sign, &ovf).

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

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

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

--- Comment #20 from Jakub Jelinek  ---
I'd say before reducing, it would be nice to see what is and is not inlined and
see which function is problematic (e.g. by trying different optimize
attributes).

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

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

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

--- Comment #21 from Martin Liška  ---
All right, I think it's a well-known problem called X87 FP unit.
The test-case is fixed with:

$ gcc pr99621-3.c -O2 -m32 && ./a.out
len 5167, expected bad
$ gcc pr99621-3.c -O2 -m32 -ffloat-store && ./a.out
len 4287, good
$ gcc pr99621-3.c -O2 -m32 -mfpmath=sse && ./a.out
len 4287, good

[Bug tree-optimization/99296] [11 Regression] ICE:in irange_set_anti_range, at value-range.cc:205 with "-Os -fno-toplevel-reorder -fno-tree-bit-ccp" since r11-5105-ga5f9c27bfc441722

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

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

--- Comment #4 from Jakub Jelinek  ---
Or perhaps better use as the condition whether type_range.upper_bound () is
zero.

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

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

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #22 from Martin Liška  ---
https://gcc.gnu.org/wiki/x87note

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

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

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

--- Comment #23 from Jakub Jelinek  ---
Which is why I was talking about excess precision, depending on the
optimizations if something needs to be spilled from the FPU stack where it is
computed in 80-bit precision to stack where the spilling then rounds it to
double precision.
With -fexcess-precision=standard one gets the excess precision predictably
everywhere, with -mfpmath=sse -msse2 there is no excess precision, double is
supported naturally.

[Bug target/94479] NetBSD: internal compiler error: in recompute_tree_invariant_for_addr_expr

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:27b298a840e5046ac8a8e045b580128a88d25c44

commit r8-10799-g27b298a840e5046ac8a8e045b580128a88d25c44
Author: Richard Biener 
Date:   Tue Apr 7 16:29:37 2020 +0200

middle-end/94479 - fix gimplification of address

When gimplifying an address operand we may expose an indirect
ref via DECL_VALUE_EXPR for example.  This is dealt with in the
code already but it fails to consider that INDIRECT_REFs get
gimplified to MEM_REFs.

Fixed which makes the ICE observed on x86_64-netbsd go away.

2020-04-07  Richard Biener  

PR middle-end/94479
* gimplify.c (gimplify_addr_expr): Also consider generated
MEM_REFs.

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

(cherry picked from commit 0f1cf13ecee1b4f9d963426b35acb5a0625816c4)

[Bug tree-optimization/98282] [8 Regression] Segmentation fault when compiling with optimization >= 2

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:55bac5c2824dcb4bdae5b309b2b2a26703f273f0

commit r8-10800-g55bac5c2824dcb4bdae5b309b2b2a26703f273f0
Author: Richard Biener 
Date:   Mon Jan 4 11:40:40 2021 +0100

tree-optimization/98282 - classify V_C_E as nary

This avoids running into memory reference code in compute_avail by
properly classifying unfolded reference trees on constants.

2021-01-04  Richard Biener  

PR tree-optimization/98282
* tree-ssa-sccvn.c (vn_get_stmt_kind): Classify tcc_reference on
invariants as VN_NARY.

* g++.dg/opt/pr98282.C: New testcase.

(cherry picked from commit edb7dbc25de455300ce066a2ebe728256ea46e3a)

[Bug tree-optimization/97081] [8 Regression] wrong code for rotate vectorization (x86 target)

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:16e2f38167eb90a4dc977b806dcc0dc9011cc456

commit r8-10801-g16e2f38167eb90a4dc977b806dcc0dc9011cc456
Author: Richard Biener 
Date:   Fri Sep 18 13:36:24 2020 +0200

tree-optimization/97081 - fix wrong-code with vectorized shift

This corrects the mask for creation of x << s | x >> (-x & mask)
from a rotate x <

PR tree-optimization/97081
* tree-vect-patterns.c (vect_recog_rotate_pattern): Use the
precision of the shifted operand to determine the mask.

* gcc.dg/vect/pr97081.c: New testcase.

(cherry picked from commit 86b25a1a5e1956c30fe7eaee80ebf719b759d631)

[Bug tree-optimization/97081] [8 Regression] wrong code for rotate vectorization (x86 target)

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Richard Biener
:

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

commit r8-10802-ge407585a3ae48a25f031450565cf2b657d431cee
Author: Jakub Jelinek 
Date:   Fri Sep 18 15:05:53 2020 +0200

testsuite: add another test for the rotate vectorization miscompilation

This time with short and char where the used mask used to be larger
than it should have been.

2020-09-18  Jakub Jelinek  

PR tree-optimization/97081
* gcc.dg/vect/pr97081-2.c: New test.

(cherry picked from commit f75352bdb139c40abb400746c03d9242a0c30bd6)

[Bug tree-optimization/97081] [8 Regression] wrong code for rotate vectorization (x86 target)

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.4.1
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[Bug target/94479] NetBSD: internal compiler error: in recompute_tree_invariant_for_addr_expr

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.4.1
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||8.4.0

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

[Bug tree-optimization/98282] [8 Regression] Segmentation fault when compiling with optimization >= 2

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||8.4.1
 Status|ASSIGNED|RESOLVED
  Known to fail||8.4.0

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

[Bug target/99621] [8/9/10/11 Regression] Wrong code with -m32 -O1 -fcaller-saves -fexpensive-optimizations since g:058e97ecf33ad0dfd926b3876a4bcf59ac9556ff

[williambader at hotmail dot com via Gcc-bugs]

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

--- Comment #24 from William Bader  ---
Jakub was right. I didn't understand what he meant at first. Sorry about that.

I can confirm `gcc -m32 -O9 -fexcess-precision=standard gcc-bug1-init.c` on the
original example works correctly for me.

If I change line 758 (the line after #if BUG_FIX) from
  if (new_qxd4_y == cur_qxd4_y && new_qxd4_x > cur_qxd4_x) {
to
  if (new_qxd4_y >= cur_qxd4_y - 0.001 && new_qxd4_y <= cur_qxd4_y + 0.001 &&
new_qxd4_x > cur_qxd4_x) {

then it also works.

Years ago I did scientific programming in fortran, and I should have remembered
from that never to compare two real numbers for equality.

[Bug ipa/98078] ICE in cgraph_add_edge_to_call_site_hash, at cgraph.c:698 since r6-1705-gd88511aec7338a93

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Martin Jambor
:

https://gcc.gnu.org/g:25fc4cb3ff7bb86d31ac886e04bbe5dd69db832e

commit r9-9291-g25fc4cb3ff7bb86d31ac886e04bbe5dd69db832e
Author: Martin Jambor 
Date:   Wed Mar 17 11:32:50 2021 +0100

ipa: Fix resolving speculations through cgraph_edge::set_call_stmt

In the PR 98078 testcase, speculative call-graph edges which were
created by IPA-CP are confirmed during inlining but
cgraph_edge::set_call_stmt does not take it very well.

The function enters the update_speculative branch and updates the
edges in the speculation bundle separately (by a recursive call), but
when it processes the first direct edge, most of the bundle actually
ceases to exist because it is devirtualized.  It nevertheless goes on
to attempt to update the indirect edge (that has just been removed),
which surprisingly gets as far as adding the edge to the
call_site_hash, the same devirtualized edge for the second time, and
that triggers an assert.

Fixed by this patch which makes the function aware that it is about to
resolve a speculation and do so instead of updating components of
speculation.  Also, it does so before dealing with the hash because
the speculation resolution code needs the hash to point to the first
speculative direct edge and also cleans the hash up by calling
update_call_stmt_hash_for_removing_direct_edge.

Bootstrapped and tested on x86_64-linux, also profile-LTO-bootstrapped
on the same system.

gcc/ChangeLog:

2021-01-20  Martin Jambor  

PR ipa/98078
* cgraph.c (cgraph_edge::set_call_stmt): Do not update all
corresponding speculative edges if we are about to resolve
speculation.  Make edge direct (and so resolve speculations) before
removing it from call_site_hash.
(cgraph_edge::make_direct): Relax the initial assert to allow
calling
the function on speculative direct edges.

(cherry picked from commit b8188b7d7382e4a74af5dd6a125e76e8d43a68a5)

[Bug ipa/98078] ICE in cgraph_add_edge_to_call_site_hash, at cgraph.c:698 since r6-1705-gd88511aec7338a93

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Jambor  ---
Fixed on master and both opened released branches.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

--- Comment #39 from Jakub Jelinek  ---
Ok, so what do we want to do on the gcc side?
Nothing, just tell users they need latest binutils?
Or try to add a configure check to detect broken binutils that doesn't handle
the DWARF5 new sections and if it detects broken binutils, in
ix86_option_override_internal if (TARGET_PECOFF && dwarf_version > 4) and
#ifdef the new macro about broken pecoff binutils set dwarf_version to 4
(if !global_options_set.x_dwarf_version silently, otherwise with a warning (but
perhaps just once per the whole TU))?
As I have no access to Windows, I'm afraid I can't easily write a configure
test myself, I can help with the i386-options.c change if needed, but can't
test anything.

[Bug tree-optimization/96369] [8 Regression] Wrong evaluation order of || operator

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:371ae12cf3b22795246a5707017f07257b5cbc97

commit r8-10803-g371ae12cf3b22795246a5707017f07257b5cbc97
Author: Richard Biener 
Date:   Fri Jul 31 08:41:56 2020 +0200

middle-end/96369 - fix missed short-circuiting during range folding

This makes the special case of constant evaluated LHS for a
short-circuiting or/and explicit rather than doing range
merging and eventually exposing a side-effect that shouldn't be
evaluated.

2020-07-31  Richard Biener  

PR middle-end/96369
* fold-const.c (fold_range_test): Special-case constant
LHS for short-circuiting operations.

* c-c++-common/pr96369.c: New testcase.

(cherry picked from commit 505767905735a3c8f171c140108ee263f9fdcad6)

[Bug tree-optimization/96370] [8 Regression] ICE with -ffast-math since r7-950-g8a85cee26eabf5cf

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:0307275acc789491bcc33dc67948009ec7d9c51d

commit r8-10804-g0307275acc789491bcc33dc67948009ec7d9c51d
Author: Richard Biener 
Date:   Thu Jul 30 10:24:42 2020 +0200

tree-optimization/96370 - make reassoc expr rewrite more robust

In the face of the more complex tricks in reassoc with respect
to negate processing it can happen that the expression rewrite
is fooled to recurse on a leaf and pick up a bogus expression
code.  The following patch makes the expression rewrite more
robust in providing the expression code to it directly since
it is the same for all operations in a chain.

2020-07-30  Richard Biener  

PR tree-optimization/96370
* tree-ssa-reassoc.c (rewrite_expr_tree): Add operation
code parameter and use it instead of picking it up from
the stmt that is being rewritten.
(reassociate_bb): Pass down the operation code.

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

(cherry picked from commit a5fff78405c3bfea287434e7711c6f10a770cb0a)

[Bug tree-optimization/96579] [8 Regression] ICE in gimple check: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_rhs1, at gimple.h:2605 since r7-950-g8a85cee26eabf5cf

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:19b7dd1caf953f8b79b16c6fc0439dba2a598b1f

commit r8-10805-g19b7dd1caf953f8b79b16c6fc0439dba2a598b1f
Author: Richard Biener 
Date:   Thu Aug 27 10:02:22 2020 +0200

tree-optimization/96579 - another special-operands fix in reassoc

This makes sure to put special-ops expanded rhs left where
expression rewrite expects it.

2020-08-27  Richard Biener  

PR tree-optimization/96579
* tree-ssa-reassoc.c (linearize_expr_tree): If we expand
rhs via special ops make sure to swap operands.

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

(cherry picked from commit 92b6627874cc924eeed9084a09f09504e20b5387)

[Bug tree-optimization/97255] [8 Regression] Vectorizer gives a boolean a value of 255

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:87da0caaec663bd427147c04e5784d7843ede96a

commit r8-10806-g87da0caaec663bd427147c04e5784d7843ede96a
Author: Richard Biener 
Date:   Thu Oct 1 09:29:32 2020 +0200

tree-optimization/97255 - missing vector bool pattern of SRAed bool

SRA tends to use VIEW_CONVERT_EXPR when replacing bool fields with
unsigned char fields.  Those are not handled in vector bool pattern
detection causing vector true values to leak.  The following fixes
this by turning those into b ? 1 : 0 as well.

2020-10-01  Richard Biener  

PR tree-optimization/97255
* tree-vect-patterns.c (vect_recog_bool_pattern): Also handle
VIEW_CONVERT_EXPR.

* g++.dg/vect/pr97255.cc: New testcase.

(cherry picked from commit f720a0d776252aac3002a0a9307a96465f1975bd)

[Bug target/99542] [9/10 Regression] ICE in exact_div, at poly-int.h:2219

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:39916ceab4940315e84bcd966da2c1d4a8e1734b

commit r11-7700-g39916ceab4940315e84bcd966da2c1d4a8e1734b
Author: Tamar Christina 
Date:   Wed Mar 17 11:12:25 2021 +

AArch64: Fix -Werror issue in
aarch64_simd_clone_compute_vecsize_and_simdlen

g:fcefc59befd396267b824c170b6a37acaf10874e introduced a new variable named
arg_type which shadows the function scoped one.

The function scoped one is now unused and so causes bootstrap to fail due
to
-Werror.

This patch removes the unused variable.

gcc/ChangeLog:

PR target/99542
* config/aarch64/aarch64.c
(aarch64_simd_clone_compute_vecsize_and_simdlen): Remove unused
var.

[Bug tree-optimization/96369] [8 Regression] Wrong evaluation order of || operator

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to fail||8.4.0
  Known to work||8.4.1
 Status|ASSIGNED|RESOLVED

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

[Bug tree-optimization/96370] [8 Regression] ICE with -ffast-math since r7-950-g8a85cee26eabf5cf

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||8.4.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to work||8.4.1

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

[Bug tree-optimization/96579] [8 Regression] ICE in gimple check: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_rhs1, at gimple.h:2605 since r7-950-g8a85cee26eabf5cf

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.4.1
 Resolution|--- |FIXED
  Known to fail||8.4.0
 Status|ASSIGNED|RESOLVED

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

[Bug tree-optimization/96579] [8 Regression] ICE in gimple check: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_rhs1, at gimple.h:2605 since r7-950-g8a85cee26eabf5cf

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

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

Bug 96370 Summary: [8 Regression] ICE with -ffast-math since 
r7-950-g8a85cee26eabf5cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96370

   What|Removed |Added

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

[Bug tree-optimization/97255] [8 Regression] Vectorizer gives a boolean a value of 255

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||8.4.0
 Status|ASSIGNED|RESOLVED
  Known to work||8.4.1
 Resolution|--- |FIXED

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

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

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

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

--- Comment #8 from Jakub Jelinek  ---
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.

[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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

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

> $ cat dir1/file2
> #pragma GCC diagnostic push
> #include_next 
> #pragma GCC diagnostic pop

> $ cat dir2/file1
> #include 

> $ cat dir2/file2

> $ g++ -Idir1 -Idir2 -fsyntax-only test.cc
> test.cc:2: internal compiler error: in linemap_position_for_loc_and_offset, 
> at libcpp/line-map.c:1005
> 0x1ca855b linemap_position_for_loc_and_offset(line_maps*, unsigned int, 
> unsigned int)
> ../../src/libcpp/line-map.c:1005
> 0xa94ef3 cp_lexer_new_main
> ../../src/gcc/cp/parser.c:676
> 0xa94ef3 c_parse_file()
> ../../src/gcc/cp/parser.c:45237
> 0xbb8ead c_common_parse_file()
> ../../src/gcc/c-family/c-opts.c:1218
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

--- Comment #40 from jyong at gcc dot gnu.org ---
Personally I'm fine with gcc configure warning of a potentially broken binutils
dwarf5 handing when targeting mingw/cygwin with binutils 2.35.1 or earlier.

How do you even parse binutils versions? Of course, all bets are off if
build!=host.

[Bug tree-optimization/93964] [8 Regression] [graphite] ICE in assign_parameter_index_in_region, at graphite-scop-detection.c:1104

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Richard Biener
:

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

commit r8-10807-g5fb76d406e75acc7223df06b66b95e70705e1185
Author: Richard Biener 
Date:   Wed Mar 4 10:40:32 2020 +0100

tree-optimization/93964 - adjust ISL code generation for pointer params

Pointers eventually need intermediate conversions in code generation.
Allowing them is much easier than fending them off since niter
and scev expansion easily drag those in.

2020-02-04  Richard Biener  

PR tree-optimization/93964
* graphite-isl-ast-to-gimple.c
(gcc_expression_from_isl_ast_expr_id): Add intermediate
conversion for pointer to integer converts.
* graphite-scop-detection.c (assign_parameter_index_in_region):
Relax assert.

* gcc.dg/graphite/pr93964.c: New testcase.

(cherry picked from commit bb0ec9cffb1d0a3326d8c4ed197717fc08eeec37)

[Bug tree-optimization/93964] [8 Regression] [graphite] ICE in assign_parameter_index_in_region, at graphite-scop-detection.c:1104

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.4.1
  Known to fail||8.4.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

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

[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues

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

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

Bug 93964 Summary: [8 Regression] [graphite] ICE in 
assign_parameter_index_in_region, at graphite-scop-detection.c:1104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93964

   What|Removed |Added

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

[Bug c/99623] New: 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

Bug ID: 99623
   Summary: Code behaves differently at -O2 optimization
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastiano.vigna at unimi dot it
  Target Milestone: ---

Created attachment 50406
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50406&action=edit
Output of --save-temps

The included code compares two variants of Ben Pfaff's GNU LibAVL library. One
implementation is the original one, and it stores pointers to uint64_t values,
comparing them with a user-supplied function. The second implementation is a
mild variation storing the uint64_t values directly into the map, and comparing
them directly using the language operators. The two implementations should be
equivalent--the code builds the same RB tree with the same values and compares
the results after each insertion.

The two trees are identical:

- with clang, any level optimization, Mac OS X, Linux
- with gcc 10.2.1, no optimization or -O1, Mac OS X, Linux

The two trees diverge after 5 insertions:

- with gcc 10.2.1, -O2, Mac OS X, Linux

We have tried all possible diagnostics, including the sanitizer, but any
perturbation to the code makes the two trees identical. The problem seems to
lie in myprob_probe()--even adding a printf(""); anywhere between lines 207-231
makes the test work.

Note that this test is reported using a compare() function for trees that might
be bugged, but the original bug was that when deleting the tree the library
would give a segmentation fault. We tracked down the problem to a divergence in
the construction of the tree.

To replicate the bug, try

gcc -O1 bug.c
./a.out
gcc -O2 bug.c
./a.out

[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 #1 from Sebastiano Vigna  ---
Created attachment 50407
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50407&action=edit
Output of gcc with -O2

[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 #2 from Sebastiano Vigna  ---
Created attachment 50408
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50408&action=edit
Source

[Bug ada/99624] New: 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

Bug ID: 99624
   Summary: Address sanitizer detects heap-buffer-overflow in
namet.adb
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

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

make[7]: Entering directory '/home/vitti/gcc-150321-ada-address/gcc/ada/rts'
/home/vitti/gcc-150321-ada-address/./gcc/xgcc
-B/home/vitti/gcc-150321-ada-address/./gcc/
-B/home/vitti/local/gcc-150321-ada-address/x86_64-pc-linux-gnu/bin/
-B/home/vitti/local/gcc-150321-ada-address/x86_64-pc-linux-gnu/lib/ -isystem
/home/vitti/local/gcc-150321-ada-address/x86_64-pc-linux-gnu/include -isystem
/home/vitti/local/gcc-150321-ada-address/x86_64-pc-linux-gnu/sys-include-c
-g -O2  -fpic  -W -Wall -gnatpg -nostdinc   a-assert.adb -o a-assert.o
=
==1168930==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x632007e0 at pc 0x0093e734 bp 0x7ffe21e0f6b0 sp 0x7ffe21e0f6a8
READ of size 4 at 0x632007e0 thread T0
#0 0x93e733 in namet__append__5 ../../gcc-150321/gcc/ada/namet.adb:157
#1 0x93f260 in namet__append_decoded ../../gcc-150321/gcc/ada/namet.adb:177
#2 0x942c2c in namet__get_decoded_name_string
../../gcc-150321/gcc/ada/namet.adb:787
#3 0xe1769e in sem_util__get_default_external_name
../../gcc-150321/gcc/ada/sem_util.adb:10490
#4 0x8adfd5 in freeze__freeze_entity
../../gcc-150321/gcc/ada/freeze.adb:5493
#5 0x8ac9a5 in freeze__freeze_before
../../gcc-150321/gcc/ada/freeze.adb:2126
#6 0xbb087c in sem_ch3__analyze_object_declaration
../../gcc-150321/gcc/ada/sem_ch3.adb:4152
#7 0xaa2e76 in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:351
#8 0xbaadf0 in sem_ch3__analyze_declarations
../../gcc-150321/gcc/ada/sem_ch3.adb:2655
#9 0xc63de4 in sem_ch7__analyze_package_specification
../../gcc-150321/gcc/ada/sem_ch7.adb:1582
#10 0xaa3092 in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:459
#11 0xc638b0 in sem_ch7__analyze_package_declaration
../../gcc-150321/gcc/ada/sem_ch7.adb:1210
#12 0xaa3065 in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:450
#13 0xb0386d in sem_ch10__analyze_compilation_unit
../../gcc-150321/gcc/ada/sem_ch10.adb:913
#14 0xaa2b1f in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:180
#15 0xaa5125 in sem__semantics__do_analyze
../../gcc-150321/gcc/ada/sem.adb:1421
#16 0xaa5d48 in sem__semantics ../../gcc-150321/gcc/ada/sem.adb:1615
#17 0xb0376a in sem_ch10__analyze_compilation_unit
../../gcc-150321/gcc/ada/sem_ch10.adb:878
#18 0xaa2b1f in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:180
#19 0xaa5125 in sem__semantics__do_analyze
../../gcc-150321/gcc/ada/sem.adb:1421
#20 0xaa5d48 in sem__semantics ../../gcc-150321/gcc/ada/sem.adb:1615
#21 0xb0957b in sem_ch10__analyze_with_clause
../../gcc-150321/gcc/ada/sem_ch10.adb:2634
#22 0xaa338d in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:613
#23 0xb04fdd in sem_ch10__analyze_context
../../gcc-150321/gcc/ada/sem_ch10.adb:1433
#24 0xb03268 in sem_ch10__analyze_compilation_unit
../../gcc-150321/gcc/ada/sem_ch10.adb:700
#25 0xaa2b1f in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:180
#26 0xaa5125 in sem__semantics__do_analyze
../../gcc-150321/gcc/ada/sem.adb:1421
#27 0xaa5d48 in sem__semantics ../../gcc-150321/gcc/ada/sem.adb:1615
#28 0xb032b7 in sem_ch10__analyze_compilation_unit
../../gcc-150321/gcc/ada/sem_ch10.adb:719
#29 0xaa2b1f in sem__analyze ../../gcc-150321/gcc/ada/sem.adb:180
#30 0xaa5125 in sem__semantics__do_analyze
../../gcc-150321/gcc/ada/sem.adb:1421
#31 0xaa5d48 in sem__semantics ../../gcc-150321/gcc/ada/sem.adb:1615
#32 0x8d0e5f in _ada_frontend ../../gcc-150321/gcc/ada/frontend.adb:422
#33 0xefdd8c in _ada_gnat1drv ../../gcc-150321/gcc/ada/gnat1drv.adb:1237
#34 0x496d83 in gnat_parse_file
../../gcc-150321/gcc/ada/gcc-interface/misc.c:118
#35 0x2182d2d in compile_file ../../gcc-150321/gcc/toplev.c:457
#36 0x218bfe8 in do_compile ../../gcc-150321/gcc/toplev.c:2201
#37 0x218c84b in toplev::main(int, char**)
../../gcc-150321/gcc/toplev.c:2340
#38 0x4c08b33 in main ../../gcc-150321/gcc/main.c:39
#39 0x1468000181e1 in __libc_start_main (/usr/lib64/libc.so.6+0x281e1)
#40 0x41c48d in _start
(/home/vitti/gcc-150321-ada-address/gcc/gnat1+0x41c48d)

0x632007e0 is located 32 bytes to the left of 96000-byte region
[0x63200800,0x63217f00)
allocated by thread T0 here:
#0 0x146800786a8f in __interceptor_malloc
../../../../gcc-150221/libsanitizer/asan/asan_malloc_

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

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #6 from Richard Biener  ---
More specifically, likely caused by g:ae99b315ba5b9e1ccc221b3c45de323cbc574400
which did

diff --git a/gcc/cfg.c b/gcc/cfg.c
index 529b6ed2105..e8bd1456c9f 100644
--- a/gcc/cfg.c
+++ b/gcc/cfg.c
@@ -102,8 +102,7 @@ free_block (basic_block bb)
bb->succs = NULL;
vec_free (bb->preds);
bb->preds = NULL;
-   /* Do not free BB itself yet since we leak pointers to dead statements
-  that points to dead basic blocks.  */
+   ggc_free (bb);
 }

 /* Free the memory associated with the CFG in FN.  */

and the backtrace of the crash points at some RTX tree (if gtype-desc from
trunk still matches, it's likely SYMBOL_REF_DECL) refers to a GIMPLE stmt
via the callgraph edge ->call_stmt which refers to the CFG BB it is contained
in.

unfortunately it's not visible what pass/phase this segfault occurs in
(might be WPA function materialization or ltrans compilation).

That said, the ggc_free above looks like a bad idea until we can sort out
these issue.  So - should we simply revert the change again?

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

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #3 from Vittorio Zecca  ---
Where is prb.h ?

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

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

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

--- Comment #7 from Richard Biener  ---
(In reply to Matthias Klose from comment #5)
> I'm able to reduce the amount of object files involved in this ICE. But then
> trying to rebuild the package with -save-temps makes the ICE disappear.

I guess always-collect might ease triggering it (--enable-checking=yes,gcac).

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

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Goes away with -fno-strict-aliasing and -Wstrict-aliasing=2 warns about it:
bug.c: In function ‘prb_probe’:
bug.c:105:42: warning: dereferencing type-punned pointer might break
strict-aliasing rules [-Wstrict-aliasing]
bug.c:139:42: warning: dereferencing type-punned pointer might break
strict-aliasing rules [-Wstrict-aliasing]
bug.c: In function ‘myprb_probe’:
bug.c:251:44: warning: dereferencing type-punned pointer might break
strict-aliasing rules [-Wstrict-aliasing]
bug.c:285:44: warning: dereferencing type-punned pointer might break
strict-aliasing rules [-Wstrict-aliasing]
bug.c: In function ‘compare’:
bug.c:375:9: warning: format ‘%d’ expects argument of type ‘int’, but argument
2 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
bug.c:375:9: warning: format ‘%d’ expects argument of type ‘int’, but argument
3 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
I bet the program is invalid, just don't have time to prove it now.

[Bug target/97252] [10/11 Regression] arm: ICE compiling pure-code/pr94538-2.c with MVE since r10-7293-g3eff57aa

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

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

Alex Coplan  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |acoplan at gcc dot 
gnu.org

--- Comment #4 from Alex Coplan  ---
Mine

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

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

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

--- Comment #8 from Richard Biener  ---
(In reply to Richard Biener from comment #6)
> More specifically, likely caused by
> g:ae99b315ba5b9e1ccc221b3c45de323cbc574400 which did
> 
> diff --git a/gcc/cfg.c b/gcc/cfg.c
> index 529b6ed2105..e8bd1456c9f 100644
> --- a/gcc/cfg.c
> +++ b/gcc/cfg.c
> @@ -102,8 +102,7 @@ free_block (basic_block bb)
> bb->succs = NULL;
> vec_free (bb->preds);
> bb->preds = NULL;
> -   /* Do not free BB itself yet since we leak pointers to dead statements
> -  that points to dead basic blocks.  */
> +   ggc_free (bb);
>  }
>  
>  /* Free the memory associated with the CFG in FN.  */
> 
> and the backtrace of the crash points at some RTX tree (if gtype-desc from
> trunk still matches, it's likely SYMBOL_REF_DECL) refers to a GIMPLE stmt
> via the callgraph edge ->call_stmt which refers to the CFG BB it is
> contained in.
> 
> unfortunately it's not visible what pass/phase this segfault occurs in
> (might be WPA function materialization or ltrans compilation).
> 
> That said, the ggc_free above looks like a bad idea until we can sort out
> these issue.  So - should we simply revert the change again?

Note we can't leave cgraph & edge reclaim to GC when we free a function
and at the same time forcefully ggc_free things pointed to (but ultimatively
dead).  That's in principle true for the gimple stmts themselves as well.

It looks like release_function_body simply leaves stmts dangling, it doesn't
remove them from blocks (clearing ->bb).  We've not seen ICEs from that
for unknown reasons.

I'm not sure it's worth all the trouble?

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

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

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

--- Comment #9 from Richard Biener  ---
For the ICE in this bug it might be enough to, in cgraph_node::release_body,
walk callees and zap ->call_stmt on the cgraph edges.  But the more general
issue remains - GC will still try to collect the now unreferenced stmts and
follow the link to the ggc_free()ed basic-block.

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

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

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;
   release_function_body (decl);
   if (lto_file_data)
 {

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

--- Comment #41 from Jakub Jelinek  ---
gcc/configure has e.g. $ld_vers_major and $ld_vers_minor and $ld_vers_patch.
But as the fix was March 1st, I think it is neither in 2.35.2 nor in 2.36.
I think a feature test would be better, try to assemble as short assembly as
possible with the new DWARF5 sections in it (with the actual code perhaps
replaced just by a nop), link it and look at it using objdump if the sections
are right or not?

[Bug target/98891] [10/11 regression] Neon logical operations not vectorized in DImode since g:cdfc0e863a03698a80c74896cbdc9f5c8c652e64

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

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

--- Comment #3 from Wilco  ---
Older GCCs only ever did this for vorn, not for other operations like
add/sub/and/orr/eor, so current behaviour is now fully consistent, and I don't
consider it a bug.

One could argue these intrinsics should always map to Neon instructions rather
than being optimized into 64-bit integer operations. However GCC never did
support this except for vorn, so it's not clear whether there is an advantage
in changing this now.

[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 #5 from Sebastiano Vigna  ---
Created attachment 50409
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50409&action=edit
Source

[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 #6 from Sebastiano Vigna  ---
Created attachment 50410
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50410&action=edit
Source

[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10

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

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

--- Comment #42 from Jakub Jelinek  ---
As a start, perhaps compiling
void
foo (void)
{
  int a = 1;
  asm ("nop");
  a = 2;
  asm ("nop");
  a = 3;
}
with -gdwarf-5 -O2 -dA to get the assembly.  But bet it can be reduced manually
somewhat, it would e.g. just drop the function altogether and in .debug_info
have just DW_TAG_compile_unit DIE with its attributes and drop
DW_TAG_subprogram etc., and only have DW_AT_ranges on it that points to minimal
.debug_rnglists.
Or keep the DW_TAG_subprogram in there but just say the ranges and nothing else
for it.
But if it needs to cover both 64-bit and 32-bit assembly for PE, either you
need two sets of assembly in the configure or tweak it by hand.
You can have a look e.g. at what the HAVE_AS_WORKING_DWARF_N_FLAG testing uses
as assembly as an example.

[Bug target/98891] [10/11 regression] Neon logical operations not vectorized in DImode since g:cdfc0e863a03698a80c74896cbdc9f5c8c652e64

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

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

--- Comment #4 from Wilco  ---
(In reply to Jakub Jelinek from comment #1)
> Reduced testcase:
> extern unsigned long long a, b, c;
> 
> void
> foo (void)
> {
>   a = b | ~c;
> }
> 
> Seems this is the usual dilemma between split double-word operations early
> vs. split it late, each has its advantages and serious disadvantages.
> By splitting early, combiner can't really do much with it, it is split into
> loads, not, or and store of the halves separately and combiner doesn't see
> the two halves together, one would need essentially vectorization on RTL to
> match that.

Splitting early is required since it results in much more efficient code.
However the real underlying problem is the concept that a type can map to
different register files. Generally a compiler must decide the register file
for each operand before register allocation, but GCC does this during register
allocation. And it does it badly with incomplete knowledge and way too many
costing hacks. To get decent code for AArch64 we had to add special hooks to
force the allocator to strongly prefer allocating integer types to integer
registers and FP/SIMD types to FP/SIMD registers.

[Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
I chose to bisect randomly one test, gcc.target/aarch64/sve/slp_perm_1.c
started FAILing with r11-3823 and FAILs even with current trunk, the difference
seems to be that previously it was using the SVE variable length vectors and
now it uses fixed V16QImode vectors.
As this PR mentions a lot of different FAILs, some started earlier, others
later, some got fixed afterwards, others not, it is hard to find out what
can/should be done.
I can't reproduce the gcc.target/aarch64/sve/mask_load_slp_1.c FAILs, I get 48
/ 40 instructions as expected even with r11-3822.
I get 40 / 32 in r11-3823 up to r11-4480, and starting from r11-4481 again 48 /
40 until now.

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

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

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

Martin Liška  changed:

   What|Removed |Added

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
[Bug 86656] [meta-bug] Issues found with -fsanitize=address

[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

Sebastiano Vigna  changed:

   What|Removed |Added

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

--- Comment #7 from Sebastiano Vigna  ---
Thank you for the prompt answer.

It is all very weird, and certainly unexpected, but this could be a problem
with GNU libavl.

The four assignments marked by -Wstrict-aliasing=2 are completely wrong: there
is an additional & that shouldn't be there. Since this is a GNU library with
two decades of development behind, we did not check in particular the code we
did not change.

If we remove the &, the warnings go away and the problem disappears.

Adding some assertions we established that the nonsensical assignment are,
simply, never executed. This is why, in spite of being nonsensical, they do not
cause any harm. But their very existence, even if they are not executed,
appears to trigger the problem we faced with -O2.

I guess that once you have undefined statements all bets are off, so this is
not a gcc bug. We will report the problem to the libavl authors.

[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.

[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 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 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 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++/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 #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++/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

[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

[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

[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 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 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 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 *)&tree->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 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 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 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

[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 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"