[Bug middle-end/97336] False positive -Wstring-compare warning for strncmp()

[franke at computer dot org via Gcc-bugs]

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

--- Comment #2 from Christian Franke  ---
Sorry, but I disagree that this report is INVALID.

Unlike for example -Wstringop-overflow, warnings like -Wstring-compare should
IMO only occur if the warning condition holds for *all* function calls
generated by loop unrolling.

BTW, if the partial loop unrolling is done manually, the warning should occur,
but does not:

int f(const char * p, int n)
{
  char buf[10] = {0, };
  int i = 0;
  if (n <= 0) {
if (!__builtin_strncmp(buf, "12345", 5) // <== no warning
&& (i == 5 || buf[5] == ' ')) // <== warning if removed
  return 1;
  }
  else {
do {
  buf[i] = p[i]; i++;
} while (i < (int)sizeof(buf)-1 && i < n);
if (!__builtin_strncmp(buf, "12345", 5)
&& (i == 5 || buf[5] == ' '))
  return 1;
  }
  return 0;
}

With the above code, the warning occurs if the condition "&& (i == 5 || buf[5]
== ' ')" is removed. If this is done in the original testcase, the warning does
no longer occur.

[Bug target/97148] Add

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #3 from H.J. Lu  ---
Fixed by

commit 59a95143ddeb4939fe2336e8f86cbc908bfa8e1a
Author: H.J. Lu 
Date:   Mon Sep 21 12:17:01 2020 -0700

x86: Add 

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define __CX16__.

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

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

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

--- Comment #5 from Florian Weimer  ---
(In reply to H.J. Lu from comment #4)
> x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define __CX16__.

It's called __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16, I think. Is this good enough?

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

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

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

--- Comment #6 from H.J. Lu  ---
(In reply to Florian Weimer from comment #5)
> (In reply to H.J. Lu from comment #4)
> > x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define __CX16__.
> 
> It's called __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16, I think. Is this good
> enough?

Yes. But a test is missing.

[Bug target/97329] POWER9 default cache and line sizes appear to be wrong

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

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

--- Comment #8 from Segher Boessenkool  ---
The default -mcpu= for a compiler targeting powerpc64le-linux is
normally power8 (you can change this with the --with-cpu= configure
option though).  -mcpu=powerpc64le is also (currently) equal to
-mcpu=power8.  But the numbers for Power8 (in power8_cost) are
wrong it seems: it has a 64kB L1-D cache, and a 512kB L2 cache (it
looks like we have simply copied the Power7 numbers here; 32 and
256 is correct for Power7).

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

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

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

--- Comment #7 from Florian Weimer  ---
(In reply to H.J. Lu from comment #6)
> (In reply to Florian Weimer from comment #5)
> > (In reply to H.J. Lu from comment #4)
> > > x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define 
> > > __CX16__.
> > 
> > It's called __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16, I think. Is this good
> > enough?
> 
> Yes. But a test is missing.

Fair enough.  Are you going to send a patch?

[Bug target/97250] Implement -march=x86-64-v2, -march=x86-64-v3, -march=x86-64-v4 for x86-64

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

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

--- Comment #8 from H.J. Lu  ---
(In reply to Florian Weimer from comment #7)
> (In reply to H.J. Lu from comment #6)
> > (In reply to Florian Weimer from comment #5)
> > > (In reply to H.J. Lu from comment #4)
> > > > x86-64-v2 includes CMPXCHG16B, aka CX16. But -mcx16 doesn't define 
> > > > __CX16__.
> > > 
> > > It's called __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16, I think. Is this good
> > > enough?
> > 
> > Yes. But a test is missing.
> 
> Fair enough.  Are you going to send a patch?

Sure.

[Bug middle-end/95189] [9/10 Regression] memcmp being wrongly stripped like strcmp

[luke-jr+gccbugs at utopios dot org via Gcc-bugs]

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

--- Comment #27 from Luke Dashjr  ---
AFAIK it's complete, but I am not a GCC developer.

[Bug tree-optimization/97333] [gimple_can_duplicate_bb_p == false, tree-ssa-threadupdate] ICE in duplicate_block, at cfghooks.c:1093

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

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

--- Comment #2 from Tom de Vries  ---
(In reply to Richard Biener from comment #1)
> (because well, on GIMPLE we can duplicate all blocks).

I'm not sure I understand why, given that tracer.c has a can_duplicate_bb_p
that sometimes returns false.  Sent an RFC patch to ask for clarification:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555890.html .

[Bug rtl-optimization/97313] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-937-g5261cf8ce824bfc7

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Vladimir Makarov :

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

commit r11-3758-gbb37ad8cc0fc937c7afcdab471e5d65d176041c3
Author: Vladimir N. Makarov 
Date:   Fri Oct 9 10:01:13 2020 -0400

Don't keep strict_low_part in reloads for non-registers. [PR97313]

gcc/ChangeLog:

2020-10-09  Vladimir Makarov  

PR rtl-optimization/97313
* lra-constraints.c (match_reload): Don't keep strict_low_part in
reloads for non-registers.

gcc/testsuite/ChangeLog:

2020-10-09  Vladimir Makarov  

PR rtl-optimization/97313
* gcc.target/i386/pr97313.c: New.

[Bug middle-end/95464] [10 Regression] Miscompilation of mesa on x86_64-linux since r10-6426

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

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

--- Comment #11 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #7)
> Vlad, do you plan to backport this to 10.3?

Unfortunately, a few days ago people reported a serious problem with the patch
(see PR97313).  I've just submitted a patch fixing the new problem

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=bb37ad8cc0fc937c7afcdab471e5d65d176041c3

I believe this new patch should be also cherry-picked to gcc-10 branch.

[Bug middle-end/97353] New: -Wuninitialized should warn about reading condition in do-loop

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

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

Bug ID: 97353
   Summary: -Wuninitialized should warn about reading condition in
do-loop
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Here in the first iteration of the loop we continue, which jumps to the end of
the loop where we read ok which hasn't yet been initialized, but we issue no
warning:

int main()
{
  int ok;
  int n = 0;
  do
{
  n++;
  if (n == 1)
continue;
  ok = n >= 2;
}
  while (ok == 0);
}

clang-tidy detects this.  This was distilled from libmpc.

[Bug middle-end/95464] [10 Regression] Miscompilation of mesa on x86_64-linux since r10-6426

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

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

--- Comment #12 from Jakub Jelinek  ---
Certainly.

[Bug tree-optimization/97079] [11 Regression] aarch64, SVE: ICE in SLP recognizer since r11-3148-g8d3767c30240c901a493d82d9d20f306b2f0152d

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

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

--- Comment #4 from Alex Coplan  ---
Related testcase that gives a similar ICE:

int c, d;
int e[1];
void a(int *);
void f(void) {
  while (d);
  int g[5];
  for (; d < 2; d++)
e[d] = c;
  for (; d; d++)
g[d] = (long)e;
  a(g);
}

$ aarch64-elf-gcc -c test.c -O1 -ftree-vectorize -march=armv8.2-a+sve
during GIMPLE pass: slp
test.c: In function 'f':
test.c:4:6: internal compiler error: Segmentation fault
4 | void f(void) {
  |  ^
0xd89397 crash_signal
/home/alecop01/toolchain/src/gcc/gcc/toplev.c:330
0x1a408b7 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/alecop01/toolchain/src/gcc/gcc/tree.h:3416
0x1a408b7 vect_convert_input
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-patterns.c:728
0x1a411f6 vect_convert_inputs
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-patterns.c:818
0x1a418bb vect_recog_over_widening_pattern
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-patterns.c:1718
0x1a3ba60 vect_pattern_recog_1
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-patterns.c:5344
0x1a44001 vect_pattern_recog(vec_info*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-patterns.c:5502
0x10c994e vect_slp_analyze_bb_1
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-slp.c:3564
0x10c994e vect_slp_region
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-slp.c:3663
0x10c994e vect_slp_bbs
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-slp.c:3819
0x10cb0d1 vect_slp_function(function*)
/home/alecop01/toolchain/src/gcc/gcc/tree-vect-slp.c:3870
0x10ce3d9 execute
/home/alecop01/toolchain/src/gcc/gcc/tree-vectorizer.c:1432
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

We don't ICE at -O2 and above here.

[Bug rtl-optimization/97313] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-937-g5261cf8ce824bfc7

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Vladimir Makarov
:

https://gcc.gnu.org/g:70a66ff0228277b4dd89263a663c0a87eb5d782f

commit r10-8874-g70a66ff0228277b4dd89263a663c0a87eb5d782f
Author: Vladimir N. Makarov 
Date:   Fri Oct 9 10:01:13 2020 -0400

Don't keep strict_low_part in reloads for non-registers. [PR97313]

gcc/ChangeLog:

2020-10-09  Vladimir Makarov  

PR rtl-optimization/97313
* lra-constraints.c (match_reload): Don't keep strict_low_part in
reloads for non-registers.

gcc/testsuite/ChangeLog:

2020-10-09  Vladimir Makarov  

PR rtl-optimization/97313
* gcc.target/i386/pr97313.c: New.

[Bug middle-end/95464] [10 Regression] Miscompilation of mesa on x86_64-linux since r10-6426

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

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

--- Comment #13 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #12)
> Certainly.

I've just committed it into the branch
https://gcc.gnu.org/g:70a66ff0228277b4dd89263a663c0a87eb5d782f

[Bug libstdc++/94823] modulo arithmetic bug in random.tcc

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

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

--- Comment #7 from Jonathan Wakely  ---
Despite the code being correct, I think it would be better to hoist this branch
out of the loop:

  if (__k == 0)
__r2 += __s;
  else if (__k <= __s)
__r2 += __kn + _M_v[__k - 1];
  else
__r2 += __kn;

We can do the k=0 case first, where we know that (k+p)%n==p and (k+q)%n==q,
and we also know that for that first iteration begin[0]^begin[q]^begin[n-1] is
simply 0x8b8b8b8bu because every element has that value:

// k == 0, every element in [begin,end) equals 0x8b8b8b8bu
  {
uint_least32_t __r1 = 1371501266u;
uint_least32_t __r2 = __r1 + __s;
__begin[__p] += __r1;
__begin[__q] += __r2;
__begin[0] = __r2;
  }

The we can loop up to __s+1

for (size_t __k = 1; __k <= __s; ++__k)
  ...

And then up to m

for (size_t __k = __s + 1; __k < __m; ++__k)
  ...

This unasks the question of whether begin[-1ul % n] is the right element or has
the right value.

[Bug target/97348] [nvptx] Make -misa=sm_35 the default

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

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

--- Comment #6 from Tom de Vries  ---
(In reply to CVS Commits from comment #4)
> Both build again cuda 9.1.

FWIW, tested post-commit against cuda 11.1, no issues found.

[Bug c/97354] New: ice during GIMPLE pass: slp

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 97354
   Summary: ice during GIMPLE pass: slp
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

The following C code:

int a, c, d;
_Complex *b;
_Complex e;
void f(void) {
  _Complex g;
  for (; a;) {
e = b[0];
for (; d; d++)
  b[c] = e;
  }
  e = g * 0;
}


with compiler flag -O3, does this:

during GIMPLE pass: slp
bug650.c: In function ‘f’:
bug650.c:4:6: internal compiler error: in as_a, at is-a.h:197
4 | void f(void) {
  |  ^
0xf7b1b4 gphi* as_a(gimple*)
../../trunk.git/gcc/is-a.h:197
0xf7b1b4 gphi_iterator::phi() const
../../trunk.git/gcc/gimple-iterator.h:43
0xf7b1b4 _bb_vec_info::~_bb_vec_info()
../../trunk.git/gcc/tree-vect-slp.c:2777
0xf7dcf0 vect_slp_region(vec,
vec, vec*, unsigned
int)
../../trunk.git/gcc/tree-vect-slp.c:3741

The bug first seems to occur sometime between 20201008 and 20201009.

[Bug middle-end/97336] False positive -Wstring-compare warning for strncmp()

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

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

--- Comment #3 from Martin Sebor  ---
For better or worse, in the internal representation there's no way to
differentiate a call that was synthesized during loop unrolling (or any other
similar transformation) from the original call in the source code, or even tell
whether or not loop unrolling or any other such transformation took place.

It also helps to keep in mind that the documented purpose of warnings in GCC
"is to report constructions that are not inherently erroneous but that are
risky or suggest there may have been an error."  If the test case in comment #0
is representative of real code then even if it doesn't indicate a bug I would
suggest to view the warning as an indication that the code can be improved. 
(This is often true for all of these flow-based warnings.) 

In the test case in comment #3 the body of the true branch of the if statement
is eliminated early on because the condition (i == 5 || buf[5] == ' ') is known
to be false.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

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

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

--- Comment #8 from Jonathan Wakely  ---
And please ping patches like
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552844.html if you don't
get a review.

[Bug libstdc++/94823] modulo arithmetic bug in random.tcc

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:3ee44d4c518d61c6bbf75fcf280edc6ce5326ce0

commit r11-3759-g3ee44d4c518d61c6bbf75fcf280edc6ce5326ce0
Author: Jonathan Wakely 
Date:   Fri Oct 9 16:10:31 2020 +0100

libstdc++: Fix incorrect results in std::seed_seq::generate [PR 97311]

This ensures that intermediate results are done in uint32_t values,
meeting the requirement for operations to be done modulo 2^32.

If the target doesn't define __UINT32_TYPE__ then substitute uint32_t
with a class type that uses uint_least32_t and masks the value to
UINT32_MAX.

I've also split the first loop that goes from k=0 to k

[Bug libstdc++/97311] Bug in std::seed_seq::generate() when integer type has more than 32 bits

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:3ee44d4c518d61c6bbf75fcf280edc6ce5326ce0

commit r11-3759-g3ee44d4c518d61c6bbf75fcf280edc6ce5326ce0
Author: Jonathan Wakely 
Date:   Fri Oct 9 16:10:31 2020 +0100

libstdc++: Fix incorrect results in std::seed_seq::generate [PR 97311]

This ensures that intermediate results are done in uint32_t values,
meeting the requirement for operations to be done modulo 2^32.

If the target doesn't define __UINT32_TYPE__ then substitute uint32_t
with a class type that uses uint_least32_t and masks the value to
UINT32_MAX.

I've also split the first loop that goes from k=0 to k

[Bug libstdc++/94823] modulo arithmetic bug in random.tcc

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed for gcc 11.

[Bug libstdc++/97311] Bug in std::seed_seq::generate() when integer type has more than 32 bits

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
Fixed on master.

The current code produces the wrong results for signed 64-bit types, but I'm
not sure whether backporting it (and changing the results in the middle of a
release series) is a good idea.

[Bug bootstrap/97355] New: Bootstrap comparison failure!

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

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

Bug ID: 97355
   Summary: Bootstrap comparison failure!
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

make[3]: Leaving directory '/home/dave/gnu/gcc/objdir'
Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
gcc/ada/get_targ.o differs
gcc/ada/csets.o differs
gcc/ada/snames.o differs
gcc/ada/aspects.o differs
gcc/ada/libgnat/s-utf_32.o differs
gcc/ada/libgnat/s-stoele.o differs
gcc/ada/libgnat/s-wchcnv.o differs
gcc/ada/libgnat/s-purexc.o differs
gcc/ada/libgnat/s-strcom.o differs
gcc/ada/libgnat/s-secsta.o differs
gcc/ada/libgnat/s-excmac.o differs
gcc/ada/libgnat/s-restri.o differs
gcc/ada/libgnat/s-traent.o differs
gcc/ada/libgnat/s-stache.o differs
gcc/ada/libgnat/s-carun8.o differs
gcc/ada/libgnat/s-stalib.o differs
gcc/ada/libgnat/s-string.o differs
gcc/ada/b_gnat1.o differs
gcc/ada/treeprs.o differs
gcc/ada/types.o differs
gcc/ada/scans.o differs
gcc/ada/impunit.o differs
gcc/ada/opt.o differs
gcc/ada/scil_ll.o differs
gcc/ada/eval_fat.o differs
gcc/ada/debug_a.o differs
gcc/ada/stand.o differs
gcc/ada/rident.o differs
hppa-linux-gnu/libstdc++-v3/libsupc++/eh_globals.o differs
libiberty/lbasename.o differs
make[2]: *** [Makefile:25111: compare] Error 1
make[2]: Leaving directory '/home/dave/gnu/gcc/objdir'
make[1]: *** [Makefile:25091: stage3-bubble] Error 2
make[1]: Leaving directory '/home/dave/gnu/gcc/objdir'
make: *** [Makefile:25154: bootstrap] Error 2
Thu Oct  8 23:35:28 EDT 2020

[Bug tree-optimization/97356] New: [11 regression] several test case failures after r11-3748

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

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

Bug ID: 97356
   Summary: [11 regression] several test case failures after
r11-3748
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:ffe8baa996486fa0313aa804a064a58b0b161f07, r11-3748

make -k check-gcc RUNTESTFLAGS=tree-ssa.exp=gcc.dg/tree-ssa/modref-2.c
FAIL: gcc.dg/tree-ssa/modref-2.c execution test
# of expected passes1
# of unexpected failures1

(gdb) run
Starting program: /home/seurer/gcc/git/build/gcc-test/./modref-2.exe 

Program received signal SIGABRT, Aborted.
0x3fffb7cd260c in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:55
55return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) where
#0  0x3fffb7cd260c in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:55
#1  0x3fffb7cd47f8 in __GI_abort () at abort.c:90
#2  0x153c in main () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/modref-2.c:22



Also

FAIL: gcc.dg/lto/modref-1 c_lto_modref-1_0.o-c_lto_modref-1_1.o execute -O2
-flto-partition=max -flto



commit ffe8baa996486fa0313aa804a064a58b0b161f07
Author: Jan Hubicka 
Date:   Fri Oct 9 11:29:58 2020 +0200

IPA modref: fix miscompilation in clone when IPA modref is used

gcc/ChangeLog:

PR ipa/97292
PR ipa/97335
* ipa-modref-tree.h (copy_from): Drop summary in a
clone.

[Bug target/97349] Incorrect types for some AArch64 Neon vdupq_n_<...> intrinsics

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Testing a patch.

[Bug middle-end/97357] New: Unable to coalesce ssa_names which are marked as MUST COALESCE.

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

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

Bug ID: 97357
   Summary: Unable to coalesce ssa_names  which are marked as MUST
COALESCE.
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

the latest gcc10.2.1 failed with SSA corruption on multiple c modules of our
important application on O3. disabling -fsplit-loops cures the failure.

I was able to reduce the huge routine to the following simple one to reproduce
the failure:

#include 
#include 

static void * my_malloc (size_t size);

typedef struct glk {
  struct glk *nxt;
} glk;

typedef struct Lock
{
 glk ByteLock;
} Lock;

static Lock *l, *lk;

void bytelocks(glk *rethead, jmp_buf jb)
{
  glk *cur, *cur_lk;

  if (( _setjmp (jb)) == 0) 
for (cur = &l->ByteLock; cur != ((glk *)0) ; cur = (cur)->nxt)
for (cur_lk = &lk->ByteLock; cur_lk != ((glk *)0); cur_lk =
cur_lk->nxt)
  {
glk *retrng;

if(!rethead)
  rethead = (glk *) my_malloc (sizeof(glk));
retrng = (glk *) my_malloc (sizeof(glk));

retrng->nxt = rethead;
  }

 return;
}
/home/qinzhao/Install/latest/bin/gcc -O3 t.c
t.c:4:15: warning: ‘my_malloc’ used but never defined
4 | static void * my_malloc (size_t size);
  |   ^

Unable to coalesce ssa_names 5 and 6 which are marked as MUST COALESCE.
rethead_5(ab) and  rethead_6(ab)
during RTL pass: expand
t.c: In function ‘bytelocks’:
t.c:17:6: internal compiler error: SSA corruption
   17 | void bytelocks(glk *rethead, jmp_buf jb)
  |  ^
0xbcca65 fail_abnormal_edge_coalesce
../../latest_gcc/gcc/tree-ssa-coalesce.c:1003
0xbcca65 coalesce_partitions
../../latest_gcc/gcc/tree-ssa-coalesce.c:1425
0xbcca65 coalesce_ssa_name(_var_map*)
../../latest_gcc/gcc/tree-ssa-coalesce.c:1755
0xb7d597 remove_ssa_form
../../latest_gcc/gcc/tree-outof-ssa.c:1065
0xb7d597 rewrite_out_of_ssa(ssaexpand*)
../../latest_gcc/gcc/tree-outof-ssa.c:1323
0x6fb5d5 execute
../../latest_gcc/gcc/cfgexpand.c:6352
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/97357] Unable to coalesce ssa_names which are marked as MUST COALESCE.

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

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

--- Comment #1 from qinzhao at gcc dot gnu.org ---
/home/qinzhao/Install/latest/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/qinzhao/Install/latest/bin/gcc
COLLECT_LTO_WRAPPER=/home/qinzhao/Install/latest/libexec/gcc/x86_64-pc-linux-gnu/10.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../latest_gcc/configure --prefix=/home/qinzhao/Install/latest
-enable-languages=c,c++,fortran,lto
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20201009 (GCC)

[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359

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

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

--- Comment #7 from qinzhao at gcc dot gnu.org ---
as we noticed, when using gcc10.2.1 compile our application, 528 C++ modules
failed with this bug. 

looks like a high priority bug to me.

[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/97318] [nvptx] Function splitting results in invalid function name

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

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

--- Comment #1 from Tom de Vries  ---
Tentative patch:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index afac1bda45d..7b6a42893f9 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -365,6 +365,30 @@ nvptx_name_replacement (const char *name)
 return "__nvptx_free";
   if (strcmp (name, "realloc") == 0)
 return "__nvptx_realloc";
+
+  if (strchr (name, '.') != NULL)
+{
+  static char *p = NULL;
+  static size_t p_size = 0;
+  size_t len = strlen (name);
+  size_t len_0 = len + 1;
+  if (p == NULL)
+   {
+ p_size = len_0;
+ p = XNEWVEC (char, p_size);
+   }
+  else if (len_0 > p_size)
+   {
+ p_size = len_0;
+ p = XRESIZEVEC (char, p, p_size);
+   }
+  strncpy (p, name, len_0);
+  for (size_t i = 0; i < len_0; ++i)
+   if (p[i] == '.')
+ p[i] = '$';
+  return p;
+}
+
   return name;
 }

...

[Bug testsuite/97168] [11 Regression] FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c, diagnostic-test-paths-2.c, location-overflow-test-1.c

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

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

--- Comment #3 from David Malcolm  ---
(In reply to Thomas Schwinge from comment #2)
[...]
> (In reply to Martin Sebor from comment #0)
> > FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
> > -fplugin=./diagnostic_plugin_test_tree_expression_range.so  1 blank line(s)
> > in output
> > FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
> > -fplugin=./diagnostic_plugin_test_tree_expression_range.so  expected
> > multiline pattern lines 550-551 not found: "   
> > __builtin_types_compatible_p \\(long, int\\) \\+ f \\(i\\)\\);.*\\n 
> > ~\\^~~\\n"
> > FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
> > -fplugin=./diagnostic_plugin_test_tree_expression_range.so (test for excess
> > errors)
> 
> These FAILs I'm not seeing in my testing.

Likewise, I'm not seeing those FAILs either.

> > FAIL: gcc.dg/plugin/location-overflow-test-1.c
> > -fplugin=./location_overflow_plugin.so adding '-flarge-source-files' (test
> > for warnings, line 16)
> 
> But this one I still see, too.

Likewise; am investigating.

[Bug libstdc++/95904] Improve the diagnostic for conflicting return types in std::visit

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Ville Voutilainen :

https://gcc.gnu.org/g:3427e31331677ca826c5588c87924214f7e5c54b

commit r11-3760-g3427e31331677ca826c5588c87924214f7e5c54b
Author: Ville Voutilainen 
Date:   Fri Oct 9 20:47:01 2020 +0300

libstdc++: Diagnose visitors with different return types [PR95904]

libstdc++-v3/ChangeLog:

PR libstdc++/95904
* include/std/variant (__deduce_visit_result): Add a nested ::type.
(__gen_vtable_impl::_S_apply):
Check the visitor return type.
(__same_types): New.
(__check_visitor_result): Likewise.
(__check_visitor_results): Likewise.
(visit(_Visitor&&, _Variants&&...)): Use __check_visitor_results
in case we're visiting just one variant.
* testsuite/20_util/variant/visit_neg.cc: Adjust.

[Bug libstdc++/95904] Improve the diagnostic for conflicting return types in std::visit

[ville.voutilainen at gmail dot com via Gcc-bugs]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #2 from Ville Voutilainen  ---
There are aspirations to change the variant tables to a flat one, but that's a
separate enhancement. This particular problem is fixed.

[Bug c++/97358] New: [8/9/10/11 Regression] ICE while building firefox since r8-2720

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

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

Bug ID: 97358
   Summary: [8/9/10/11 Regression] ICE while building firefox
since r8-2720
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The following testcase reduced from firefox ICEs with -std=c++17 starting with
r8-2720-gf44a8dd56f5bfbd0596c39693e268ef880c06221 (before it has been
rejected).
clang++ accepts it, though unsure if the reduction didn't make it invalid (or
whether the original 13MB+ :( testcase is valid).

struct A;
struct B { A foo (); };
enum C { E };
struct A { template  void bar (T... x) { auto v {[x...] { x;
}...}; } };
template  using F = B;
struct G { F baz (); };
enum H { J };
struct D { using K = G; };
template  struct I : D { void qux (); };
template  void I::qux () { K a; a.baz ().foo ().bar (); }
template class I;

[Bug c++/97358] [8/9/10/11 Regression] ICE while building firefox since r8-2720

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
   Last reconfirmed||2020-10-09
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

[Bug c++/97358] [8/9/10/11 Regression] ICE while building firefox since r8-2720

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

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

--- Comment #1 from Jakub Jelinek  ---
Slightly modified testcase where bar is surely instantiated and clang++ still
accepts it.  It actually ICEs in all of -std=c++{11,14,17,20}.
struct A;
struct B { A foo (); };
enum C { E };
struct A { template  void bar (T... x) { int v {[x...] { x;
}...}; } };
template  using F = B;
struct G { F baz (); };
enum H { J };
struct D { using K = G; };
template  struct I : D { void qux (); };
template  void I::qux () { K a; a.baz ().foo ().bar (); }
void
test ()
{
  I i;
  i.qux ();
}

[Bug fortran/82721] [8/9/10/11 Regression] Error message with corrupted text, sometimes ICE

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #12 from anlauf at gcc dot gnu.org ---
On Linux it seems to help setting MALLOC_PERTURB_ to a non-zero value to
get a consistent ICE.

[Bug c/97359] New: ice in logical_combine, at gimple-range-gori.cc:754

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 97359
   Summary: ice in logical_combine, at gimple-range-gori.cc:754
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

The attached C code, when compiled by recent gcc trunk
and compiler flag -O2, does this:

$ ../results/bin/gcc -c -O2 -w bug651.c
during GIMPLE pass: evrp
bug651.c: In function ‘func_14’:
bug651.c:12278:1: internal compiler error: in logical_combine, at
gimple-range-gori.cc:754
12278 | }
  | ^
0x18d8f56 gori_compute::logical_combine(irange&, tree_code, irange const&,
tf_range const&, tf_range const&)
../../trunk.git/gcc/gimple-range-gori.cc:754
0x18da9e2 gori_compute_cache::cache_stmt(gimple*)
../../trunk.git/gcc/gimple-range-gori.cc:1314
0x18da6c4 gori_compute_cache::compute_operand_range(irange&, gimple*, irange
const&, tree_node*)
../../trunk.git/gcc/gimple-range-gori.cc:1279
0x18d881e gori_compute::compute_operand1_range(irange&, gimple*, irange const&,
tree_node*)

I'll have a go at reducing the code.

[Bug c/97359] ice in logical_combine, at gimple-range-gori.cc:754

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
The code seems to break gcc trunk sometime between 20201006 and 20201007.

[Bug c/97359] ice in logical_combine, at gimple-range-gori.cc:754

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
The reduced C code is

typedef unsigned int uint32_t;
int a;
void b(uint32_t c) {
  uint32_t *d = &c;
  for (; a;)
for (;; (*d %= a) / (*d > 1 > (c > 0)) ?: d)
  ;
}

[Bug tree-optimization/97359] [11 Regression] ice in logical_combine, at gimple-range-gori.cc:754

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|ice in logical_combine, at  |[11 Regression] ice in
   |gimple-range-gori.cc:754|logical_combine, at
   ||gimple-range-gori.cc:754
   Target Milestone|--- |11.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-10-09
 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com,
   ||jakub at gcc dot gnu.org
  Component|c   |tree-optimization

--- Comment #3 from Jakub Jelinek  ---
Since r11-3685-gfcae5121154d1c3382b056bcc2c563cedac28e74 or r11-3684 (the
latter doesn't build) in particular.

[Bug testsuite/97168] [11 Regression] FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c, diagnostic-test-paths-2.c, location-overflow-test-1.c

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
The failure in location-overflow-test-1.c is the subject of pr97117.

[Bug testsuite/97168] [11 Regression] FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c, diagnostic-test-paths-2.c, location-overflow-test-1.c

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #5 from David Malcolm  ---
(In reply to Martin Sebor from comment #4)
> The failure in location-overflow-test-1.c is the subject of pr97117.

Thanks; in that case the only remaining failures are the ones in
gcc.dg/plugin/diagnostic-test-expressions-1.c; are you still seeing those?

[Bug testsuite/97168] [11 Regression] FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c, diagnostic-test-paths-2.c, location-overflow-test-1.c

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

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

--- Comment #6 from Martin Sebor  ---
No failures in diagnostic-test-expressions-1.c in my latest build (just about
an hour old).  The latest x86_64 result posted to gcc-testresults also looks
clear of plugin test failures except pr97117:
https://gcc.gnu.org/pipermail/gcc-testresults/2020-October/614433.html
Please feel free to close this.

[Bug tree-optimization/97360] New: ICE in range_on_exit

[amodra at gmail dot com via Gcc-bugs]

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

Bug ID: 97360
   Summary: ICE in range_on_exit
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

during GIMPLE pass: evrp
/home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/mma-double-test.c: In
function 'MMA':
/home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/mma-double-test.c:186:1:
internal compiler error: in range_on_exit, at gimple-range.cc:931

The types involved are:
  constant 512>
unit-size  constant 64>
align:512 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76622bd0 precision:512 min  max

pointer_to_this >

and:
  constant 512>
unit-size  constant 64>
align:512 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76622b28 precision:512 min  max
>

So this may well be a powerpc target bug.

[Bug target/97361] New: power10 unrecognizable insn

[amodra at gmail dot com via Gcc-bugs]

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

Bug ID: 97361
   Summary: power10 unrecognizable insn
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

-mcpu=power10 -O2 -mno-isel

/home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/ppc-ne0-1.c: In function
'ne0':
/home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/ppc-ne0-1.c:12:1: error:
unrecognizable insn:
   12 | }
  | ^
(insn 8 7 9 2 (set (reg:DI 122)
(if_then_else:DI (eq (reg:CC 123)
(const_int 0 [0]))
(const_int 0 [0])
(reg:DI 124)))
"/home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/ppc-ne0-1.c":11:12 -1
 (nil))
during RTL pass: vregs

[Bug tree-optimization/97359] [11 Regression] ice in logical_combine, at gimple-range-gori.cc:754

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

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

--- Comment #4 from Aldy Hernandez  ---
Created attachment 49340
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49340&action=edit
untested proposed patch

Untested.

[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054

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

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

--- Comment #16 from Martin Liška  ---
I was able to find a minimal debug counter for IPA modref that triggers that:
-fdbg-cnt=ipa_mod_ref:10902-10904

[Bug rtl-optimization/94440] [8/9/10/11 Regression] ICE in check_bool_attrs, at recog.c:2168 since r7-5324-gb8cab8a5492e9639

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #8 from David Binderman  ---
Nothing has happened on this bug report for more than two months.
Perhaps Uros is best placed to make progress with this bug.

I would be happy to help with any testing of patches.

[Bug testsuite/97337] new test case gcc.dg/pr97315-1.c fails with excess errors

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

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

Aldy Hernandez  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |aldyh at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-10-09
 Ever confirmed|0   |1

--- Comment #1 from Aldy Hernandez  ---
Confirmed.  Test should've gone in g++.dg/ not gcc.dg/.

[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054

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

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

--- Comment #17 from Jan Hubicka  ---
And is it again the operator++ triggering the problem?
It looks like aliasing bug to me, but in a template hell and
-Wstrict-aliasing=3 is happy.

The reason why parameter tracking is necessary seems to be the fact that we
figure out some accesses from inner calls are local to the ++ operator and do
not consider them in a summary (that is correct)

[Bug fortran/97345] New: FE passes do_subscript leaks gmp memory

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

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

Bug ID: 97345
   Summary: FE passes do_subscript leaks gmp memory
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

==15138== 8 bytes in 1 blocks are definitely lost in loss record 5 of 742
==15138==at 0x4C2E2DF: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==15138==by 0x568C698: __gmp_default_allocate (in
/usr/lib64/libgmp.so.10.3.2)
==15138==by 0x569CA22: __gmpz_init_set (in /usr/lib64/libgmp.so.10.3.2)
==15138==by 0xC04033: do_subscript(gfc_expr**) (frontend-passes.c:2861)
==15138==by 0xC03C58: do_function(gfc_expr**, int*, void*)
(frontend-passes.c:2699)
==15138==by 0xC0A1CD: gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**, int*,
void*), void*) (frontend-passes.c:5189)

the code is doing mpz_init_set (...) but no where freeing the memory
associated with mpz_t do_start, do_step, do_end

[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054

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

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

--- Comment #18 from Martin Liška  ---
(In reply to Jan Hubicka from comment #17)
> And is it again the operator++ triggering the problem?
> It looks like aliasing bug to me, but in a template hell and
> -Wstrict-aliasing=3 is happy.

It's another place where a *(&cell + 12) is moved by PRE:

[local count: 365109597]:
   pretmp_2371 = MEM[(const struct Triangulation * *)&cell + 16B];
   pretmp_2373 = MEM[(int *)&cell + 8B];
-  pretmp_2375 = MEM[(int *)&cell + 12B];
   goto ; [100.00%]


> 
> The reason why parameter tracking is necessary seems to be the fact that we
> figure out some accesses from inner calls are local to the ++ operator and
> do not consider them in a summary (that is correct)

[Bug testsuite/97337] new test case gcc.dg/pr97315-1.c fails with excess errors

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
g++.dg/opt/ in particular.  And should have also the -fno-exceptions in
dg-options.

[Bug ipa/97346] New: IPA reference reference_vars_to_consider leaks

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

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

Bug ID: 97346
   Summary: IPA reference reference_vars_to_consider leaks
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

==20551== 96 (8 direct, 88 indirect) bytes in 1 blocks are definitely lost in
loss record 535 of 730
==20551==at 0x4C2E94F: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20551==by 0x14A6E6B: void vec_alloc(vec*&, unsigned int) (vec.h:1567)
==20551==by 0x24BB41F: ipa_init() (ipa-reference.c:461)
==20551==by 0x24BB896: generate_summary() (ipa-reference.c:597)
==20551==by 0x24BC18A: propagate() (ipa-reference.c:768)
==20551==by 0x24BD88C: (anonymous
namespace)::pass_ipa_reference::execute(function*) (ipa-reference.c:1299)
==20551==by 0x121A924: execute_one_pass(opt_pass*) (passes.c:2509)
==20551==by 0x121B893: execute_ipa_pass_list(opt_pass*) (passes.c:2936)
==20551==by 0xC6ED1D: ipa_passes() (cgraphunit.c:2700)

the use of this global is quite odd, with two allocations, one release
site using just 'delete' and one conditional freeing the vector but
unconditionally NULLing the pointer to it.

I wonder if the array should be made local to a few functions to make
lifetime more obvious.

[Bug tree-optimization/97347] New: [11 Regression] error: statement marked for throw in middle of block in botan

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

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

Bug ID: 97347
   Summary: [11 Regression] error: statement marked for throw in
middle of block in botan
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ cat botan.ii
inline namespace __cxx11 {}
typedef int size_t;
class MessageAuthenticationCode;
class __uniq_ptr_impl {
  struct _Ptr {
using type = MessageAuthenticationCode *;
  };
public:
  using pointer = _Ptr::type;
};
class unique_ptr {
public:
  using pointer = __uniq_ptr_impl::pointer;
  unique_ptr(pointer);
};
namespace __cxx11 {
class basic_string {
public:
  basic_string(char *);
  ~basic_string();
};
} // namespace __cxx11
class MessageAuthenticationCode {};
class SCAN_Name {
public:
  SCAN_Name(basic_string);
  size_t arg_as_integer();
};
class SipHash : public MessageAuthenticationCode {
public:
  SipHash(size_t c, size_t d) : m_C(c), m_D(d) {}
  size_t m_C, m_D;
};
void create(basic_string algo_spec) {
  basic_string provider = "";
  SCAN_Name req(algo_spec);
  unique_ptr(new SipHash(req.arg_as_integer(), req.arg_as_integer()));
}

$ g++ -O3 botan.ii -c -fdump-tree-all
botan.ii: In function ‘void create(__cxx11::basic_string)’:
botan.ii:35:27: warning: ISO C++ forbids converting a string constant to
‘char*’ [-Wwrite-strings]
   35 |   basic_string provider = "";
  |   ^~
botan.ii:34:6: error: statement marked for throw in middle of block
   34 | void create(basic_string algo_spec) {
  |  ^~
# .MEM_11 = VDEF <.MEM_9>
_12 = operator new (8);
during GIMPLE pass: slp
dump file: botan.ii.175t.slp2
botan.ii:34:6: internal compiler error: verify_gimple failed
0x1057d5a verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5482
0xf3d36f execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1992
0xf3e1bc do_per_function
/home/marxin/Programming/gcc/gcc/passes.c:1640
0xf3e1bc execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The insertion code mentions statements that can throw but does not handle it.

Patch candidate:

diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index 7e22506b49f..84bc8970f33 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -4148,13 +4148,22 @@ vect_create_constant_vectors (vec_info *vinfo, slp_tree
op_node)
gsi = gsi_for_stmt (insert_after->stmt);
  else
{
- /* When we want to insert after a def where the
-defining stmt throws then insert on the fallthru
-edge.  */
  edge e = find_fallthru_edge
 (gimple_bb (insert_after->stmt)->succs);
  gcc_assert (single_pred_p (e->dest));
  gsi = gsi_after_labels (e->dest);
+
+ /* When we want to insert after a def where the
+defining stmt throws then insert on the fallthru
+edge.  */
+ while (!gsi_end_p (gsi)
+&& stmt_can_throw_internal (cfun, gsi_stmt
(gsi)))
+   {
+ e = find_fallthru_edge (e->dest->succs);
+ gcc_assert (single_pred_p (e->dest));
+ gsi = gsi_after_labels (e->dest);
+   }
+
}
  gsi_insert_seq_after (&gsi, ctor_seq,
GSI_CONTINUE_LINKING);

What do you think Richi about the patch?

[Bug tree-optimization/97347] [11 Regression] error: statement marked for throw in middle of block in botan

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
   Last reconfirmed||2020-10-09

[Bug ipa/97346] IPA reference reference_vars_to_consider leaks

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

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

--- Comment #1 from Richard Biener  ---
At least

diff --git a/gcc/ipa-reference.c b/gcc/ipa-reference.c
index 4a6c011c525..6df4be09471 100644
--- a/gcc/ipa-reference.c
+++ b/gcc/ipa-reference.c
@@ -1114,7 +1113,8 @@ ipa_reference_write_optimization_summary (void)
  }
   }
   lto_destroy_simple_output_block (ob);
-  delete reference_vars_to_consider;
+  vec_free (reference_vars_to_consider);
+  reference_vars_to_consider = NULL;
 }

 /* Deserialize the ipa info for lto.  */

is maybe obvious.  Then there's

diff --git a/gcc/ipa-reference.c b/gcc/ipa-reference.c
index 4a6c011c525..f0555929340 100644
--- a/gcc/ipa-reference.c
+++ b/gcc/ipa-reference.c
@@ -1056,6 +1056,7 @@ ipa_reference_write_optimization_summary (void)
   auto_bitmap ltrans_statics;
   int i;

+  gcc_assert (!reference_vars_to_consider);
   vec_alloc (reference_vars_to_consider, ipa_reference_vars_uids);
   reference_vars_to_consider->safe_grow (ipa_reference_vars_uids, true);


that will likely trip because of the ipa_init allocation.  And

diff --git a/gcc/ipa-reference.c b/gcc/ipa-reference.c
index 4a6c011c525..93b2b677a76 100644
--- a/gcc/ipa-reference.c
+++ b/gcc/ipa-reference.c
@@ -964,8 +964,10 @@ propagate (void)
 }

   if (dump_file)
-vec_free (reference_vars_to_consider);
-  reference_vars_to_consider = NULL;
+{
+  vec_free (reference_vars_to_consider);
+  reference_vars_to_consider = NULL;
+}
   return remove_p ? TODO_remove_functions : 0;
 }


anyway, it all looks like a mess ;)

[Bug ipa/97295] ICE on firefox built with lto+pgo: dist/include/mozilla/Casting.h:64:1: internal compiler error: in to_frequency, at profile-count.c:273

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

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

--- Comment #6 from Sergei Trofimovich  ---
Created attachment 49336
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49336&action=edit
b.tar.gz

Managed to craft self-contained example which is able to crash both gcc-10 and
gcc-11. Attached as b.tar.gz.

The session looks like:

$ LANG=C bash -x ./mk2.bash
+ rm TestFloatingPoint.o Unified_cpp_mfbt0.o main.o Unified_cpp_mfbt0.gcda
main.gcda main
+ cxx=g++-11.0.0
+ cxxflags=(-flto -fPIC -O1 -Wno-error=coverage-mismatch -Wno-coverage-mismatch
-Wno-missing-profile "$@")
+ g++-11.0.0 -flto -fPIC -O1 -Wno-error=coverage-mismatch
-Wno-coverage-mismatch -Wno-missing-profile -o Unified_cpp_mfbt0.o -c -O1
-fprofile-generate -fprofile-correction Unified_cpp_mfbt0.cpp
+ g++-11.0.0 -flto -fPIC -O1 -Wno-error=coverage-mismatch
-Wno-coverage-mismatch -Wno-missing-profile -o main.o -c -O1 -fprofile-generate
-fprofile-correction main.cc
+ g++-11.0.0 -flto -fPIC -O1 -Wno-error=coverage-mismatch
-Wno-coverage-mismatch -Wno-missing-profile -o main -O1 -fprofile-generate
main.o Unified_cpp_mfbt0.o
+ ./main
+ g++-11.0.0 -flto -fPIC -O1 -Wno-error=coverage-mismatch
-Wno-coverage-mismatch -Wno-missing-profile -o Unified_cpp_mfbt0.o -c -O1
-fprofile-use -fprofile-correction Unified_cpp_mfbt0.cpp
+ g++-11.0.0 -flto -fPIC -O1 -Wno-error=coverage-mismatch
-Wno-coverage-mismatch -Wno-missing-profile -o TestFloatingPoint.o -c -O0
TestFloatingPoint.cpp
+ g++-11.0.0 -flto -fPIC -O1 -Wno-error=coverage-mismatch
-Wno-coverage-mismatch -Wno-missing-profile -o TestFloatingPoint -O1 -shared
TestFloatingPoint.o Unified_cpp_mfbt0.o
during RTL pass: ira
TestFloatingPoint.cpp: In function 'BitwiseCast':
TestFloatingPoint.cpp:11:1: internal compiler error: in to_frequency, at
profile-count.c:273
   11 | }
  | ^
0x5c6aaf profile_count::to_frequency(function*) const
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/profile-count.c:273
0x9f2511 regstat_bb_compute_ri
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/regstat.c:200
0x9f2511 regstat_compute_ri()
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/regstat.c:253
0x8b5680 ira
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/ira.c:5300
0x8b5680 execute
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/ira.c:5672
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /usr/bin/g++-11.0.0 returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug c++/97340] Spurious rejection of member variable template of reference type

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
If I see correctly, it started with r6-2648-gdc062b4986328bfe.

[Bug tree-optimization/97347] [11 Regression] error: statement marked for throw in middle of block in botan

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug ipa/97295] ICE on firefox built with lto+pgo: dist/include/mozilla/Casting.h:64:1: internal compiler error: in to_frequency, at profile-count.c:273

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

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

--- Comment #7 from Sergei Trofimovich  ---
(In reply to Sergei Trofimovich from comment #6)
> Created attachment 49336 [details]
> b.tar.gz
> 
> Managed to craft self-contained example which is able to crash both gcc-10
> and gcc-11. Attached as b.tar.gz.

On this test I observe failures on: 8.4.0, 9.3.0, 10.2.0, 11.0.0. Last working
version is 7.5.0.

[Bug target/97348] New: [nvptx] Make -misa=sm_35 the default

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

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

Bug ID: 97348
   Summary: [nvptx] Make  -misa=sm_35 the default
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

The gcc objects and executables for nvptx are somewhat funny given that they
contain just ptx text.

However, during assembling, we do verify that the ptx is valid, by running it
through ptxas, if that happens to be available in the path.  This step can be
skipped by using -Wa,--no-verify, but it's done by default.

The system cuda on my system (ubuntu Ubuntu 18.04.5) is V9.1.108, and I can do
a build (where the system ptxas will be used for verification).

However, if I want to compile something while my path is set to include the
most recent cuda (11.1), I get:
...
$ c=~/cuda/11.1/bin; ( export PATH=$c:$PATH;
/home/vries/nvptx/trunk/build-gcc/gcc/xgcc
-B/home/vries/nvptx/trunk/build-gcc/gcc/ -fdiagnostics-plain-output
--sysroot=/home/vries/nvptx/trunk/install/nvptx-none -O0 -w -c -isystem
/home/vries/nvptx/trunk/build-gcc/nvptx-none/./newlib/targ-include -isystem
/home/vries/nvptx/trunk/source-gcc/newlib/libc/include -o pr42717.o
/home/vries/nvptx/trunk/source-gcc/gcc/testsuite/gcc.c-torture/compile/pr42717.c
)
ptxas fatal   : Value 'sm_30' is not defined for option 'gpu-name'
nvptx-as: ptxas returned 255 exit status
...

By adding -misa=sm_35, the compilation succeeds.

For a test-case, it's stil feasible to add this, but not for a build.

So, it looks like it's time to make -misa=sm_35 the new default.

[ It's good to note that the ptxas code will not actually be executed, and that
in the end the installed driver is the one making the translation for
execution.  So atm my exec using sm_30 is still supported by Long Lived Branch
driver version 450.66. ]

[Bug target/97348] [nvptx] Make -misa=sm_35 the default

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

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

Tom de Vries  changed:

   What|Removed |Added

 Target||nvptx

--- Comment #1 from Tom de Vries  ---
Using this:
...
diff --git a/gcc/config/nvptx/nvptx.opt b/gcc/config/nvptx/nvptx.opt
index 75c3d54864e..4c27a832d28 100644
--- a/gcc/config/nvptx/nvptx.opt
+++ b/gcc/config/nvptx/nvptx.opt
@@ -60,5 +60,5 @@ EnumValue
 Enum(ptx_isa) String(sm_35) Value(PTX_ISA_SM35)

 misa=
-Target RejectNegative ToLower Joined Enum(ptx_isa) Var(ptx_isa_option)
Init(PTX_ISA_SM30)
+Target RejectNegative ToLower Joined Enum(ptx_isa) Var(ptx_isa_option)
Init(PTX_ISA_SM35)
 Specify the version of the ptx ISA to use.
...
and rebuilding cc1, we indeed get the sm_35 in the .s file.

However, when doing a complete rebuild against system cuda, we run into this in
configure doing a conftest:
...
ptxas fatal   : SM version specified by .target is higher than default SM
version assumed
nvptx-as: ptxas returned 255 exit status
...

If we add -misa=sm_35 to the command line, the conftest passes.

Looking in the nvptx-as sources, we find a hard_coded default:
...
  const char *smver = "sm_30";
...
and after changing that to sm_35, the conftest passes.

I'm not sure if nvptx-as should have a hardcoded default, probably it should
parse the .target line and pass that to ptxas.

[Bug tree-optimization/97347] [11 Regression] error: statement marked for throw in middle of block in botan

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

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

Richard Biener  changed:

   What|Removed |Added

Version|10.0|11.0
   Assignee|marxin at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #1 from Richard Biener  ---
Since we're really want to insert on the edge and merely assert that will be
possible we should instead do

  else
{
  /* When we want to insert after a def where the
 defining stmt throws then insert on the fallthru
 edge.  */
  edge e = find_fallthru_edge
 (gimple_bb (insert_after->stmt)->succs);
  basic_block new_bb
= gsi_insert_seq_on_edge_immediate (e, ctor_seq);
  gcc_assert (!new_bb);
}

possibly even allowing a new BB to be created (though our region collection
restrictions should not make this necessary).  Let me take this.

[Bug testsuite/97337] new test case gcc.dg/pr97315-1.c fails with excess errors

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

https://gcc.gnu.org/g:6887244269e0c412afd43474e13fa5ca12c350c4

commit r11-3742-g6887244269e0c412afd43474e13fa5ca12c350c4
Author: Aldy Hernandez 
Date:   Fri Oct 9 09:31:47 2020 +0200

Move pr97315-1.c test to g++.dg/opt/.

gcc/testsuite/ChangeLog:

PR testsuite/97337
* gcc.dg/pr97315-1.c: Moved to...
* g++.dg/opt/pr97315-1.C: ...here.

[Bug tree-optimization/97325] [11 Regression] wrong code with __builtin_ffs() at -O2

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:600cf1128e49f086522bfddc54490b4e39e30383

commit r11-3743-g600cf1128e49f086522bfddc54490b4e39e30383
Author: Jakub Jelinek 
Date:   Fri Oct 9 10:16:57 2020 +0200

match.pd: Fix up FFS -> CTZ + 1 optimization [PR97325]

And no testcase was included, I'm including one below.

Anyway, this PR and the other CTZ related discussions led me to discover a
bug I've made earlier, CLZ/CTZ builtins have unsigned arguments and e.g.
both the vr-values.cc and now gimple-range.cc code heavily relies on that,
but __builtin_ffs has a signed operand and this optimization was
incorrectly
making the operand signed too, so I guess it would greatly confuse VRP in
some cases.

2020-10-09  Jakub Jelinek  

PR tree-optimization/97325
* match.pd (FFS(nonzero) -> CTZ(nonzero) + 1): Cast argument to
corresponding unsigned type.

* gcc.c-torture/execute/pr97325.c: New test.

[Bug testsuite/97337] new test case gcc.dg/pr97315-1.c fails with excess errors

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #4 from Aldy Hernandez  ---
fixed in trunk

[Bug target/97312] [11 regression] aarch64/pr90838.c fails

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:781634daea8cb788efb33994f4a19df76598542e

commit r11-3744-g781634daea8cb788efb33994f4a19df76598542e
Author: Jakub Jelinek 
Date:   Fri Oct 9 10:19:16 2020 +0200

vrp: Fix up gcc.target/aarch64/pr90838.c [PR97312, PR94801]

> Perhaps another way out of this would be document and enforce that
> __builtin_c[lt]z{,l,ll} etc calls are undefined at zero, but C[TL]Z ifn
> calls are defined there based on *_DEFINED_VALUE_AT_ZERO (*) == 2

The following patch implements that, i.e. __builtin_c?z* now take full
advantage of them being UB at zero, while the ifns are well defined at zero
if *_DEFINED_VALUE_AT_ZERO (*) == 2.  That is what fixes PR94801.

Furthermore, to fix PR97312, if it is well defined at zero and the value at
zero is prec, we don't lower the maximum unless the argument is known to be
non-zero.
For gimple-range.cc I guess we could improve it if needed e.g. by returning
a [0,7][32,32] range for .CTZ of e.g. [0,137], but for now it (roughly)
matches what vr-values.c does.

2020-10-09  Jakub Jelinek  

PR tree-optimization/94801
PR target/97312
* vr-values.c (vr_values::extract_range_basic) : When stmt is not an internal-fn call or
C?Z_DEFINED_VALUE_AT_ZERO is not 2, assume argument is not zero
and thus use [0, prec-1] range unless it can be further improved.
For CTZ, don't update maxi from upper bound if it was previously
prec.
* gimple-range.cc (gimple_ranger::range_of_builtin_call)
: Likewise.

* gcc.dg/tree-ssa/pr94801.c: New test.

[Bug tree-optimization/94801] Failure to optimize narrowed __builtin_clz

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:781634daea8cb788efb33994f4a19df76598542e

commit r11-3744-g781634daea8cb788efb33994f4a19df76598542e
Author: Jakub Jelinek 
Date:   Fri Oct 9 10:19:16 2020 +0200

vrp: Fix up gcc.target/aarch64/pr90838.c [PR97312, PR94801]

> Perhaps another way out of this would be document and enforce that
> __builtin_c[lt]z{,l,ll} etc calls are undefined at zero, but C[TL]Z ifn
> calls are defined there based on *_DEFINED_VALUE_AT_ZERO (*) == 2

The following patch implements that, i.e. __builtin_c?z* now take full
advantage of them being UB at zero, while the ifns are well defined at zero
if *_DEFINED_VALUE_AT_ZERO (*) == 2.  That is what fixes PR94801.

Furthermore, to fix PR97312, if it is well defined at zero and the value at
zero is prec, we don't lower the maximum unless the argument is known to be
non-zero.
For gimple-range.cc I guess we could improve it if needed e.g. by returning
a [0,7][32,32] range for .CTZ of e.g. [0,137], but for now it (roughly)
matches what vr-values.c does.

2020-10-09  Jakub Jelinek  

PR tree-optimization/94801
PR target/97312
* vr-values.c (vr_values::extract_range_basic) : When stmt is not an internal-fn call or
C?Z_DEFINED_VALUE_AT_ZERO is not 2, assume argument is not zero
and thus use [0, prec-1] range unless it can be further improved.
For CTZ, don't update maxi from upper bound if it was previously
prec.
* gimple-range.cc (gimple_ranger::range_of_builtin_call)
: Likewise.

* gcc.dg/tree-ssa/pr94801.c: New test.

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

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

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

Bug 94801 Summary: Failure to optimize narrowed __builtin_clz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94801

   What|Removed |Added

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

[Bug tree-optimization/94801] Failure to optimize narrowed __builtin_clz

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed on the trunk now.

[Bug target/97348] [nvptx] Make -misa=sm_35 the default

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

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

--- Comment #2 from Tom de Vries  ---
Anyway, we should be able to work around this by having gcc explicitly pass -m
sm_35 to nvptx-as:
...
-#define ASM_SPEC "%{misa=*:-m %*}"
+#define ASM_SPEC "%{misa=*:-m %*; :-m sm_35}"
...

[Bug target/97348] [nvptx] Make -misa=sm_35 the default

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

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

--- Comment #3 from Tom de Vries  ---
(In reply to Tom de Vries from comment #1)
> Looking in the nvptx-as sources, we find a hard_coded default:
> ...
>   const char *smver = "sm_30";
> ...
> and after changing that to sm_35, the conftest passes.
> 
> I'm not sure if nvptx-as should have a hardcoded default, probably it should
> parse the .target line and pass that to ptxas.

Filed https://github.com/MentorEmbedded/nvptx-tools/issues/24.

[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803

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

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

--- Comment #4 from Martin Liška  ---
This case is about:

[local count: 177167400]:
+  pretmp_327 = MEM[(int *)dep_dp_76(D) + 8B];
+  goto ; [100.00%]
+
+   [local count: 177167400]:
   ctx_144 = _44 + 4;
+  pretmp_335 = MEM[(int *)dep_dp_76(D) + 8B];

where dep_dp is of type:

typedef struct
{
  unsigned intDrange;
  unsigned intDvalue;
  int DbitsLeft;
  byte*Dcodestrm;
  int *Dcodestrm_len;
} DecodingEnvironment;

and so dep_dp_76(D) + 8B is 'Dvalue' field of the struct.

Looking at the code, there are really places where one takes pointer of the
field:

benchspec/CPU/525.x264_r/src/ldecod_src/biaridecod.c:  unsigned int *value =
&dep->Dvalue;
benchspec/CPU/525.x264_r/src/ldecod_src/biaridecod.c:   unsigned int *value =
&dep->Dvalue;

But the usage seems fine to me, no casting and direct usage of the 'unsigned
int *'.

[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803

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

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

--- Comment #5 from Martin Liška  ---
(In reply to Martin Liška from comment #4)
> This case is about:
> 
> [local count: 177167400]:
> +  pretmp_327 = MEM[(int *)dep_dp_76(D) + 8B];
> +  goto ; [100.00%]
> +
> +   [local count: 177167400]:
>ctx_144 = _44 + 4;
> +  pretmp_335 = MEM[(int *)dep_dp_76(D) + 8B];
> 
> where dep_dp is of type:
> 
> typedef struct
> {
>   unsigned intDrange;
>   unsigned intDvalue;
>   int DbitsLeft;
>   byte*Dcodestrm;
>   int *Dcodestrm_len;
> } DecodingEnvironment;
> 

Sorry, dep_dp_76(D) + 8B corresponds to DbitsLeft. But again, both places where
address is taken don't cast the pointer or so:

benchspec/CPU/525.x264_r/src/ldecod_src/biaridecod.c:  int *DbitsLeft =
&dep->DbitsLeft;
benchspec/CPU/525.x264_r/src/ldecod_src/biaridecod.c:   int *DbitsLeft =
&dep->DbitsLeft;

[Bug target/97203] [nvptx] 'illegal memory access was encountered' with 'omp simd'/SIMT and cexpf call

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #6 from Alexander Monakov  ---
(In reply to Tom de Vries from comment #4)
> So, I think calling functions from simd code is atm not supported for nvptx.
> 
> Stack variables in simd code are mapped on a per-thread stack rather than on
> the
> usual per-warp stack.
> 
> The functions are compiled with the usual per-warp stack, so calling those
> functions from simd might mean the different lanes are gonna disagree about
> what the value in a stack variable should be.

This is inaccurate. In -msoft-stack mode there's no baked-in assumption that
stacks are always per-warp. The "soft stack" pointer can point either to global
memory (outside of SIMD regions), or to local memory (inside SIMD regions). The
pointer is switched between per-warp global memory and per-lane local memory by
nvptx.c:nvptx_output_softstack_switch.

The main requirement is that functions callable from OpenMP offloaded code are
compiled for -mgomp multilib variant. The design allows calling functions even
from inside SIMD regions, and it should be supported.

It is very disappointing that the first reaction was "I think ... is not
supported" without reaching out and asking questions. Lack of efficient
communication was a huge issue when OpenMP offloading support was contributed,
and it's disappointing to see it again years later.

[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803

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

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

--- Comment #6 from Martin Liška  ---
PRE dump files:

https://drive.google.com/file/d/1pWbEPfAqIThlTdEYWJ_g2yvDowqUSa-Q/view?usp=sharing

https://drive.google.com/file/d/1pWbEPfAqIThlTdEYWJ_g2yvDowqUSa-Q/view?usp=sharing

[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803

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

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

--- Comment #7 from Martin Liška  ---
(In reply to Martin Liška from comment #6)
> PRE dump files:
> 
> https://drive.google.com/file/d/1pWbEPfAqIThlTdEYWJ_g2yvDowqUSa-Q/
> view?usp=sharing
> 
> https://drive.google.com/file/d/1pWbEPfAqIThlTdEYWJ_g2yvDowqUSa-Q/
> view?usp=sharing

The second one is:

https://drive.google.com/file/d/11qmfbZCgWrkkpuTxRxFE6gq1Bcd3GkHf/view?usp=sharing

[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803

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

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

--- Comment #8 from Martin Liška  ---
The change is:
ipa-modref: in read_MVD_CABAC/1761, call to exp_golomb_decode_eq_prob/1803 does
not clobber  3->3

[Bug tree-optimization/97347] [11 Regression] error: statement marked for throw in middle of block in botan

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

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

Martin Liška  changed:

   What|Removed |Added

 Blocks||26163

--- Comment #2 from Martin Liška  ---
Just for the record, one can see the same error in 520.omnetpp_r.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/97317] [11 Regression] ICE in verify_range, at value-range.cc:369

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

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #8 from Aldy Hernandez  ---
fixed

[Bug tree-optimization/97317] [11 Regression] ICE in verify_range, at value-range.cc:369

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

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

commit r11-3746-g1cde5d85bec20877bed063fc0046b9885231a0ae
Author: Andrew MacLeod 
Date:   Fri Oct 9 10:46:50 2020 +0200

Fix for PR97317.

gcc/ChangeLog:

PR tree-optimization/97317
* range-op.cc (operator_cast::op1_range): Handle casts where the
precision
of the RHS is only 1 greater than the precision of the LHS.

gcc/testsuite/ChangeLog:
* gcc.dg/pr97317.c: New test.

[Bug target/97349] New: Incorrect types for some Neon vdupq_n_<...> intrinsics

[david.spickett at linaro dot org via Gcc-bugs]

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

Bug ID: 97349
   Summary: Incorrect types for some Neon vdupq_n_<...> intrinsics
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.spickett at linaro dot org
  Target Milestone: ---

Created attachment 49337
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49337&action=edit
test C file

The attached file has function pointers with the expected types for these
intrinsics as shown in the ACLE. 

https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics?search=vdupq_n_

This fails to compile because some of the intrinsic types are incorrect.
(I haven't included all the vdupq_n_, just the ones that have issues)

$ ./aarch64-none-elf-gcc -v
Using built-in specs.
COLLECT_GCC=./aarch64-none-elf-gcc
COLLECT_LTO_WRAPPER=/arm/pdtl/builds/fsf-trunk.2226/installed/rhe6x86_64/aarch64-none-elf/bin/../libexec/gcc/aarch64-none-elf/11.0.0/lto-wrapper
Target: aarch64-none-elf
Configured with:
/tmp/dgboter/bbs/rhev-vm4--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-elf/build/src/gcc/configure
--target=aarch64-none-elf
--prefix=/tmp/dgboter/bbs/rhev-vm4--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-elf/build/build-aarch64-none-elf/install//
--with-gmp=/tmp/dgboter/bbs/rhev-vm4--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-elf/build/build-aarch64-none-elf/host-tools
--with-mpfr=/tmp/dgboter/bbs/rhev-vm4--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-elf/build/build-aarch64-none-elf/host-tools
--with-mpc=/tmp/dgboter/bbs/rhev-vm4--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-elf/build/build-aarch64-none-elf/host-tools
--with-isl=/tmp/dgboter/bbs/rhev-vm4--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-elf/build/build-aarch64-none-elf/host-tools
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --enable-languages=c,c++,fortran --with-newlib
--with-pkgversion=fsf-trunk.2226
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200609 (experimental) (fsf-trunk.2226)

$ ./aarch64-none-elf-gcc /tmp/test.c -Wall -Wextra -c -o /dev/null
/tmp/test.c:3:32: warning: initialization of 'poly16x8_t (*)(poly16_t)' {aka
'poly16x8_t (*)(__Poly16_t)'} from incompatible pointer type 'poly16x8_t
(*)(uint32_t)' {aka 'poly16x8_t (*)(unsigned int)'}
[-Wincompatible-pointer-types]
3 | poly16x8_t  (*fp0)(poly16_t) = vdupq_n_p16;
  |^~~
/tmp/test.c:4:32: warning: initialization of 'poly64x2_t (*)(poly64_t)' {aka
'poly64x2_t (*)(__Poly64_t)'} from incompatible pointer type 'poly64x2_t
(*)(uint64_t)' {aka 'poly64x2_t (*)(long unsigned int)'}
[-Wincompatible-pointer-types]
4 | poly64x2_t  (*fp1)(poly64_t) = vdupq_n_p64;
  |^~~
/tmp/test.c:5:32: warning: initialization of 'poly8x16_t (*)(poly8_t)' {aka
'poly8x16_t (*)(__Poly8_t)'} from incompatible pointer type 'poly8x16_t
(*)(uint32_t)' {aka 'poly8x16_t (*)(unsigned int)'}
[-Wincompatible-pointer-types]
5 | poly8x16_t  (*fp2)(poly8_t)  = vdupq_n_p8;
  |^~
/tmp/test.c:6:32: warning: initialization of 'int16x8_t (*)(int16_t)' {aka
'int16x8_t (*)(short int)'} from incompatible pointer type 'int16x8_t
(*)(int32_t)' {aka 'int16x8_t (*)(int)'} [-Wincompatible-pointer-types]
6 | int16x8_t   (*fp3)(int16_t)  = vdupq_n_s16;
  |^~~
/tmp/test.c:7:32: warning: initialization of 'int8x16_t (*)(int8_t)' {aka
'int8x16_t (*)(signed char)'} from incompatible pointer type 'int8x16_t
(*)(int32_t)' {aka 'int8x16_t (*)(int)'} [-Wincompatible-pointer-types]
7 | int8x16_t   (*fp4)(int8_t)   = vdupq_n_s8;
  |^~
/tmp/test.c:8:32: warning: initialization of 'uint16x8_t (*)(uint16_t)' {aka
'uint16x8_t (*)(short unsigned int)'} from incompatible pointer type
'uint16x8_t (*)(uint32_t)' {aka 'uint16x8_t (*)(unsigned int)'}
[-Wincompatible-pointer-types]
8 | uint16x8_t  (*fp5)(uint16_t) = vdupq_n_u16;
  |^~~
/tmp/test.c:9:32: warning: initialization of 'uint8x16_t (*)(uint8_t)' {aka
'uint8x16_t (*)(unsigned char)'} from incompatible pointer type 'uint8x16_t
(*)(uint32_t)' {aka 'uint8x16_t (*)(unsigned int)'}
[-Wincompatible-pointer-types]
9 | uint8x16_t  (*fp6)(uint8_t)  = vdupq_n_u8;
  |^~

[Bug tree-optimization/97347] [11 Regression] error: statement marked for throw in middle of block in botan

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #3 from David Binderman  ---
I am seeing the same problem in a large piece of C++ from the tesseract
package.

I will reduce the code and report back.

[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803

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

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

--- Comment #9 from Martin Liška  ---
So adding only -fno-ipa-cp fixes the problem!

[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803

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

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

--- Comment #10 from Jan Hubicka  ---
Created attachment 49338
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49338&action=edit
disable param tracking on clones

Perhaps this has chance to help.

[Bug tree-optimization/97347] [11 Regression] error: statement marked for throw in middle of block in botan

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

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

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

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

commit r11-3747-g5d708c6315e0fc57992cda7b466a5a9877ced4e3
Author: Richard Biener 
Date:   Fri Oct 9 10:19:38 2020 +0200

tree-optimization/97347 - fix another SLP constant insertion issue

Just use edge insertion which will appropriately handle the situation
from botan.

2020-10-09  Richard Biener  

PR tree-optimization/97347
* tree-vect-slp.c (vect_create_constant_vectors): Use
edge insertion when inserting on the fallthru edge,
appropriately insert at the start of BBs when inserting
after PHIs.

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

[Bug tree-optimization/97347] [11 Regression] error: statement marked for throw in middle of block in botan

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 97347 Summary: [11 Regression] error: statement marked for throw in middle 
of block in botan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97347

   What|Removed |Added

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

[Bug target/97349] Incorrect types for some Arm Neon vdupq_n_<...> intrinsics

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-10-09
 Target|arm |aarch64
 Ever confirmed|0   |1
   Target Milestone|--- |8.5
  Known to fail||10.2.1, 11.0, 8.4.1, 9.3.1
 Status|UNCONFIRMED |NEW
 CC||ktkachov at gcc dot gnu.org

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

[Bug target/97327] -mcpu=cortex-m55 warns without -mfloat-abi=hard or -march=armv8.1-m.main

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

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

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

[Bug tree-optimization/97334] inefficient vectorization of gcc.dg/vect/bb-slp-pr65935.c

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

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

--- Comment #2 from Richard Biener  ---
So what happens is that we fatally fail the SLP build of the multiplication
operands since they look like

t5.c:20:37: note:   vect_is_simple_use: operand _58 * _59, type of def:
internal
t5.c:20:37: note:   vect_is_simple_use: operand _59 * _62, type of def:
internal
t5.c:20:37: note:   vect_is_simple_use: operand _59 * _65, type of def:
internal
...

with both having the unvectorizable (non-group) _59.  We should commutate
the first stmt to move all unvectorizable ops into operand one and only
build that from scalars.

This is fortunately the "good" order I have a fix^Whack for.

[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054

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

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

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

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

commit r11-3748-gffe8baa996486fa0313aa804a064a58b0b161f07
Author: Jan Hubicka 
Date:   Fri Oct 9 11:29:58 2020 +0200

IPA modref: fix miscompilation in clone when IPA modref is used

gcc/ChangeLog:

PR ipa/97292
PR ipa/97335
* ipa-modref-tree.h (copy_from): Drop summary in a
clone.

[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803

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

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

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

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

commit r11-3748-gffe8baa996486fa0313aa804a064a58b0b161f07
Author: Jan Hubicka 
Date:   Fri Oct 9 11:29:58 2020 +0200

IPA modref: fix miscompilation in clone when IPA modref is used

gcc/ChangeLog:

PR ipa/97292
PR ipa/97335
* ipa-modref-tree.h (copy_from): Drop summary in a
clone.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 97292 Summary: [11 Regression] dealII from SPECCPU 2006 no longer 
terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292

   What|Removed |Added

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