[Bug c/97261] gcc-10 produces invalid -Warray-bounds warning

[gccbugs at dima dot secretsauce.net via Gcc-bugs]

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

--- Comment #1 from Dima Kogan  ---
Created attachment 49294
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49294=edit
Code to demo the issue

[Bug c/97261] New: gcc-10 produces invalid -Warray-bounds warning

[gccbugs at dima dot secretsauce.net via Gcc-bugs]

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

Bug ID: 97261
   Summary: gcc-10 produces invalid -Warray-bounds warning
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugs at dima dot secretsauce.net
  Target Milestone: ---

Hi. I'm seeing gcc-10 flag a warning that I'm pretty sure is incorrect. gcc-9
and older did not warn about this (although that's probably because they
weren't looking for these kinds of problems).

Recipe:

1. save the attached as tst.c

2. gcc-10 -Wall -Wextra -Wno-unused-variable -fPIC -O3 -c -o tst.o tst.c

I see this:



tst.c: In function 'f':
tst.c:21:17: warning: array subscript -1 is outside array bounds of 'double[1]'
[-Warray-bounds]
   21 | const ab_t* ab = (ab_t*)(pb - 1);
  | ^~
tst.c:16:13: note: while referencing 'b'
   16 | double  b  = 4.;
  | ^



I believe this is false. Inside g(), ab->a is indeed out-of-bounds, but ab->b
is not. And I only use ab->b. Taking away -fPIC or -O3 makes the warning go
away. Making g() static makes it go away also.

I'm using gcc-10 from Debian. Package version 10.1.0-5.

Thanks!

[Bug c++/90210] [C++17] CTAD forbidding explicit deduction guide for copy-list-initialization

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Fixed in GCC 11.

[Bug c++/90210] [C++17] CTAD forbidding explicit deduction guide for copy-list-initialization

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

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

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

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

commit r11-3574-gcf7dae01734eea0dfb4c387e4cd40e1f9a682f56
Author: Marek Polacek 
Date:   Fri Sep 18 16:57:34 2020 -0400

c++: CTAD and explicit deduction guides for copy-list-init [PR90210]

This PR points out that we accept

  template struct tuple { tuple(T); }; // #1
  template explicit tuple(T t) -> tuple; // #2
  tuple t = { 1 };

despite the 'explicit' deduction guide in a copy-list-initialization
context.  That's because in deduction_guides_for we first find the
user-defined deduction guide (#2), and then ctor_deduction_guides_for
creates artificial deduction guides: one from the tuple(T) constructor and
a copy guide.  So we end up with these three guides:

  (1) template tuple(T) -> tuple [DECL_NONCONVERTING_P]
  (2) template tuple(tuple) -> tuple
  (3) template tuple(T) -> tuple

Then, in do_class_deduction, we prune this set, and get rid of (1).
Then overload resolution selects (3) and we succeed.

But [over.match.list]p1 says "In copy-list-initialization, if an explicit
constructor is chosen, the initialization is ill-formed."  It also goes
on to say that this differs from other situations where only converting
constructors are considered for copy-initialization.  Therefore for
list-initialization we consider explicit constructors and complain if one
is chosen.  E.g. convert_like_internal/ck_user can give an error.

So my logic runs that we should not prune the deduction_guides_for guides
in a copy-list-initialization context, and only complain if we actually
choose an explicit deduction guide.  This matches clang++/EDG/msvc++.

gcc/cp/ChangeLog:

PR c++/90210
* pt.c (do_class_deduction): Don't prune explicit deduction guides
in copy-list-initialization.  In copy-list-initialization, if an
explicit deduction guide was selected, give an error.

gcc/testsuite/ChangeLog:

PR c++/90210
* g++.dg/cpp1z/class-deduction73.C: New test.

[Bug tree-optimization/97260] [9/10/11 regression] memcmp of constant string and local constant array not folded

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

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

--- Comment #2 from Martin Sebor  ---
Bisection points to r200211 as the first commit after which the call wasn't
folded:

commit 6a6dac5293ee21d9aed0d394a0cb23948bb1efad
Author: Jan Hubicka 
Date:   Wed Jun 19 20:06:12 2013 +0200

cgraph.h (const_value_known_p): Replace by ...


* cgraph.h (const_value_known_p): Replace by ...
(ctor_for_folding): .. this one.
* cgraphunit.c (process_function_and_variable_attributes): Use it.
* lto-cgraph.c (compute_ltrans_boundary): Use ctor_for_folding.
* expr.c (expand_expr_real_1): Likewise.
(string_constant): Likewise.
* tree-ssa-loop-ivcanon.c (constant_after_peeling): Likewise.
* ipa.c (process_references): Likewise.
(symtab_remove_unreachable_nodes): Likewise.
* ipa-inline-analysis.c (param_change_prob): Likewise.
* gimple-fold.c (canonicalize_constructor_val): Likewise.
(get_base_constructor): Likwise.
* varpool.c (varpool_remove_node): Likewise.
(varpool_remove_initializer): LIkewise.
(dump_varpool_node): LIkwise.
(const_value_known_p): Rewrite to ...
(ctor_for_folding): ... this one.

* lto-partition.c (add_references_to_partition): Use
ctor_for_folding.

* gcc.dg/tree-ssa/attr-alias-2.c: New testcase.

From-SVN: r200211

[Bug tree-optimization/97260] [9/10/11 regression] memcmp of constant string and local constant array not folded

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

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||4.8.5
  Known to fail||10.2.0, 11.0, 9.3.0
 Blocks||83819
Summary|memcmp of constant string   |[9/10/11 regression] memcmp
   |and local constant array|of constant string and
   |not folded  |local constant array not
   ||folded

--- Comment #1 from Martin Sebor  ---
It appears that GCC was able to fold such calls until version 4.8.  Starting
with 4.9 it can't anymore.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

[Bug tree-optimization/97260] New: memcmp of constant string and local constant array not folded

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

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

Bug ID: 97260
   Summary: memcmp of constant string and local constant array not
folded
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC fails to fold the memcmp call below into a constant.  Clang folds it
successfully.

$ cat x.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout
-o/dev/stdout x.c
int f (void)
{
  const char a[] = "1234";
  return __builtin_memcmp (a, "1234", 4);
}
.file   "x.c"
.text

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

f ()
{
  const char a[5];
  int _3;

   [local count: 1073741824]:
  a = "1234";
  _3 = __builtin_memcmp (, "1234", 4);
  a ={v} {CLOBBER};
  return _3;

}


.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "1234"
.text
.p2align 4
.globl  f
.type   f, @function
f:
.LFB0:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movl$4, %edx
movl$.LC0, %esi
leaq11(%rsp), %rdi
movl$875770417, 11(%rsp)
movb$0, 15(%rsp)
callmemcmp
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size   f, .-f
.ident  "GCC: (GNU) 11.0.0 20200930 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug target/97259] New: Incorrect ENQCMD and ENQCMDS patterns

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

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

Bug ID: 97259
   Summary: Incorrect ENQCMD and ENQCMDS patterns
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, wwwhhhyyy333 at gmail dot com
  Target Milestone: ---

i386.md has

;; ENQCMD and ENQCMDS

(define_int_iterator ENQCMD [UNSPECV_ENQCMD UNSPECV_ENQCMDS])
(define_int_attr enqcmd_sfx [(UNSPECV_ENQCMD "") (UNSPECV_ENQCMDS "s")])

(define_insn "@enqcmd_"
  [(set (reg:CCZ FLAGS_REG)
(unspec_volatile:CCZ [(match_operand:P 0 "register_operand" "r")
  (match_operand:XI 1 "memory_operand" "m")] 
 ENQCMD))]
  "TARGET_ENQCMD"
  "enqcmd\t{%1, %0|%0, %1}"
  [(set_attr "type" "other")])

They write 512 bytes at address in register operand.

[Bug analyzer/97258] New: -fanalyze fails to analyze static callbacks

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

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

Bug ID: 97258
   Summary: -fanalyze fails to analyze static callbacks
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

If a function is "static" we only look inside it if it gets directly called by
a non-static function in the TU; we don't consider callbacks that get
registered and perhaps called at some later point via machinery that isn't in
the TU.

In the following, -fanalyzer doesn't attempt to look inside callback_1, and
fails to report the obvious double-free.

Perhaps we should have logic to determine if the function escapes and inject an
entrypoint into the worklist that way.  Or perhaps we should simply analyze
static functions at the "top level" of the worklist.

Seen whilst attempting to detect CVE-2019-19078 with a custom
allocator/deallocator handler for linux "struct urb".

***

#include 

static void callback_1 (void *p)
{
  free (p);
  free (p);
}

struct ops {
  void (*cb) (void *);
};

static const struct ops ops_1 = {
  .cb = callback_1
};

extern void registration (const void *);

void register_1 (void)
{
  registration (_1);
}

***

[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event

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

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

--- Comment #10 from Mark Wielaard  ---
Created attachment 49293
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49293=edit
supergraph

> Mark: please can you add -fdump-analyzer-supergraph to the arguments and 
> attach > the bzip2.c.supergraph.dot file to this bug.  Doing so may help 
> track down (d).

gcc -g -O2 -fanalyzer -fdump-analyzer-supergraph -c bzip2.c

[Bug target/97257] FAIL: gcc.target/i386/movdir64b.c (test for excess errors)

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

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

H.J. Lu  changed:

   What|Removed |Added

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

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

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

[Bug fortran/86117] bogus warning maybe-uninitialized with class(*) and source argument in allocate

[damian at sourceryinstitute dot org via Gcc-bugs]

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

Damian Rouson  changed:

   What|Removed |Added

 CC||damian at sourceryinstitute 
dot or
   ||g

--- Comment #5 from Damian Rouson  ---
Below is an example without the polymorphism employed in the original
submission.  In gfortran 11, the warnings and notes now total 70 lines stemming
from a single executable line.  In my opinion, this volume renders -Wall nearly
unusable because of the time it can take to sift out the truly useful
information from the spurious information.

± cat copious-warnings.f90 
module results_interface
  type results_t
real, allocatable :: output(:)
  end type
contains
  subroutine max_filtered_normalized_distance(rhs)
type(results_t) rhs
real, allocatable :: rhs_filtered(:)
rhs_filtered = rhs%output
  end subroutine
end module

± gfortran -c -Wall copious-warnings.f90 
copious-warnings.f90:9:0:

9 | rhs_filtered = rhs%output
  | 
Warning: ‘rhs_filtered.offset’ is used uninitialized [-Wuninitialized]
copious-warnings.f90:8:40:

8 | real, allocatable :: rhs_filtered(:)
  |^
note: ‘rhs_filtered’ declared here
copious-warnings.f90:9:0:

9 | rhs_filtered = rhs%output
  | 
Warning: ‘rhs_filtered.dim[0].lbound’ is used uninitialized [-Wuninitialized]
copious-warnings.f90:8:40:

8 | real, allocatable :: rhs_filtered(:)
  |^
note: ‘rhs_filtered’ declared here
copious-warnings.f90:9:0:

9 | rhs_filtered = rhs%output
  | 
Warning: ‘rhs_filtered.dim[0].ubound’ is used uninitialized [-Wuninitialized]
copious-warnings.f90:8:40:

8 | real, allocatable :: rhs_filtered(:)
  |^
note: ‘rhs_filtered’ declared here
copious-warnings.f90:9:0:

9 | rhs_filtered = rhs%output
  | 
Warning: ‘rhs_filtered.dim[0].lbound’ may be used uninitialized
[-Wmaybe-uninitialized]
copious-warnings.f90:8:40:

8 | real, allocatable :: rhs_filtered(:)
  |^
note: ‘rhs_filtered’ declared here
copious-warnings.f90:9:0:

9 | rhs_filtered = rhs%output
  | 
Warning: ‘rhs_filtered.dim[0].ubound’ may be used uninitialized
[-Wmaybe-uninitialized]
copious-warnings.f90:8:40:

8 | real, allocatable :: rhs_filtered(:)
  |^
note: ‘rhs_filtered’ declared here
copious-warnings.f90:9:0:

9 | rhs_filtered = rhs%output
  | 
Warning: ‘rhs_filtered.dim[0].ubound’ may be used uninitialized
[-Wmaybe-uninitialized]
copious-warnings.f90:8:40:

8 | real, allocatable :: rhs_filtered(:)
  |^
note: ‘rhs_filtered’ declared here
copious-warnings.f90:9:0:

9 | rhs_filtered = rhs%output
  | 
Warning: ‘rhs_filtered.dim[0].lbound’ may be used uninitialized
[-Wmaybe-uninitialized]
copious-warnings.f90:8:40:

8 | real, allocatable :: rhs_filtered(:)
  |^
note: ‘rhs_filtered’ declared here

± gfortran --version
GNU Fortran (GCC) 11.0.0 20200804 (experimental)

[Bug libgomp/81688] libgomp.c/target-3{3,4}.c fails: GOMP_OFFLOAD_async_run unimplemented for nvptx

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

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #6 from Tom de Vries  ---
This no longer fails at current trunk.

[Bug target/90931] [nvptx] FAIL: gcc.c-torture/execute/pr78675.c -O1 execution test

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

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #1 from Tom de Vries  ---
No longer occurs for current trunk with driver 450.66.

[Bug bootstrap/97183] zstd build failure for gcc 10 on Ubuntu 16.04

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

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

Jim Wilson  changed:

   What|Removed |Added

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

--- Comment #8 from Jim Wilson  ---
Remember to set it to resolved/fixed this tine,

[Bug bootstrap/97183] zstd build failure for gcc 10 on Ubuntu 16.04

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

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

--- Comment #7 from Jim Wilson  ---
Fixed on mainline and the gcc-10 branch.

[Bug bootstrap/97183] zstd build failure for gcc 10 on Ubuntu 16.04

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jim Wilson :

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

commit r10-8831-g9d85b9880e1772ead961c7b5a2bd8caab57815bf
Author: Jim Wilson 
Date:   Wed Sep 30 13:06:28 2020 -0700

Fix build failure with zstd versio9n 1.2.0 or older.

Extends the configure check for zstd.h to also verify the zstd version,
since gcc requires features that only exist in 1.3.0 and newer.  Without
this patch we get a build error for lto-compress.c when using an old zstd
version.

Backported from master:
2020-09-29  Jim Wilson  

gcc/
PR bootstrap/97183
* configure.ac (gcc_cv_header_zstd_h): Check ZSTD_VERISON_NUMBER.
* configure: Regenerated.

[Bug middle-end/97189] [11 Regression] ICE in attr_access::array_as_string at gcc/attribs.c:2276 since r11-3303-g6450f07388f9fe57

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Fixed in r11-3571.

[Bug c/97206] [11 Regression] internal compiler error: in composite_type, at c/c-typeck.c:447 since r11-3303-g6450f07388f9fe57

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
Fixed in r11-3570.

[Bug middle-end/97189] [11 Regression] ICE in attr_access::array_as_string at gcc/attribs.c:2276 since r11-3303-g6450f07388f9fe57

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:7dbc7ad524a540e34ce25d120d0968f36c571bbb

commit r11-3571-g7dbc7ad524a540e34ce25d120d0968f36c571bbb
Author: Martin Sebor 
Date:   Wed Sep 30 12:58:09 2020 -0600

Avoid assuming a VLA access specification string contains a closing bracket
(PR middle-end/97189).

Resolves:
PR middle-end/97189 - ICE on redeclaration of a function with VLA argument
and attribute access

gcc/ChangeLog:

PR middle-end/97189
* attribs.c (attr_access::array_as_string): Avoid assuming a VLA
access specification string contains a closing bracket.

gcc/c-family/ChangeLog:

PR middle-end/97189
* c-attribs.c (append_access_attr): Use the function declaration
location for a warning about an attribute access argument.

gcc/testsuite/ChangeLog:

PR middle-end/97189
* gcc.dg/attr-access-2.c: Adjust caret location.
* gcc.dg/Wvla-parameter-6.c: New test.
* gcc.dg/Wvla-parameter-7.c: New test.

[Bug c/97206] [11 Regression] internal compiler error: in composite_type, at c/c-typeck.c:447 since r11-3303-g6450f07388f9fe57

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

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

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

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

commit r11-3570-ge808f3fdfa8f31066da19011b55acb8c0446c72d
Author: Martin Sebor 
Date:   Wed Sep 30 09:31:29 2020 -0600

PR c/97206 - ICE in composite_type on declarations of a similar array types

gcc/ChangeLog:

PR c/97206
* attribs.c (attr_access::array_as_string): Avoid modifying a
shared
type in place and use build_type_attribute_qual_variant instead.

gcc/testsuite/ChangeLog:

PR c/97206
* gcc.dg/Warray-parameter-7.c: New test.
* gcc.dg/Warray-parameter-8.c: New test.
* gcc.dg/Wvla-parameter-5.c: New test.

[Bug middle-end/95673] missing -Wstring-compare for an impossible strncmp test

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

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||83819

--- Comment #6 from Martin Sebor  ---
There warning doesn't trigger for the first strcmp call (i.e., strcmp(file,
"file123.txt")) because it's folded into a conditional expression involving
just the lengths of the strings before it reaches the stage when it would
otherwise be issued.

Here's a small test case showing how it happens:

  int f (int c)
  {
const char *s = c ? "12345" : "12";
return 0 == __builtin_strcmp (s, "123");
  }

and the output pf the PRE pass (-fdump-tree-pre-details) shows:

...
Found partial redundancy for expression
{call_expr<__builtin_strcmp>,iftmp.0_3,addr_expr<"123">}@.MEM_5(D) (0001)
Created phi prephitmp_7 = PHI <-1(3), 1(5)>
 in block 4 (0001)
Starting insert iteration 2
Replaced 0 with pretmp_11 in all uses of pretmp_9 = 0;
Replaced 0 with pretmp_10 in all uses of pretmp_8 = 0;
Replaced __builtin_strcmp (iftmp.0_3, "123") with prephitmp_7 in all uses of _1
= __builtin_strcmp (iftmp.0_3, "123");
...
Removing dead stmt _1 = __builtin_strcmp (iftmp.0_3, "123");
...

The PRE pass runs much earlier than the strlen pass that issues the warning so
I don't think there's going to be anything to emit the warning in this case
(involving all string literals).

The PRE optimization isn't smart enough to handle the case when at least one of
the arguments is an ordinary array and so then warning does trigger:

  extern char a[3];

  int f (int c)
  {
const char *s = c ? "12345" : a;
return 0 == __builtin_strcmp (s, "123");
  }

The call is then folded away by the strlen pass (by the same code that issues
the warning).

In general, the warning code doesn't necessarily know the contents of the
arrays it's based on, only their lengths and/or sizes, so it can't very well
print them.  (Printing strings is also tricky because of constraints on the
volume of output, or the question how to deal with non-printable characters.)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

[Bug c++/92271] for consistency, __is_same_as should be named __is_same

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

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

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

https://gcc.gnu.org/g:73ae6eb572515ad627b575a7fbdfdd47a4368e1c

commit r11-3569-g73ae6eb572515ad627b575a7fbdfdd47a4368e1c
Author: Jonathan Wakely 
Date:   Wed Sep 30 18:24:48 2020 +0100

libstdc++: Use __is_same instead of __is_same_as

PR 92271 added __is_same as another spelling of __is_same_as. Since
Clang also spells it __is_same, let's just use that consistently.

It appears that Intel icc sets __GNUC__ to 10, but only supports
__is_same_as. If we only use __is_same for __GNUC__ >= 11 then we won't
break icc again (it looks like we broke previous versions of icc when we
started using __is_same_as).

libstdc++-v3/ChangeLog:

* include/bits/c++config (_GLIBCXX_HAVE_BUILTIN_IS_SAME):
Define for GCC 11 or when !__is_identifier(__is_same).
(_GLIBCXX_BUILTIN_IS_SAME_AS): Remove.
* include/std/type_traits (is_same, is_same_v): Replace uses
of _GLIBCXX_BUILTIN_IS_SAME_AS.

[Bug tree-optimization/97225] Failure to optimize out conditional addition of zero

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug libstdc++/95788] std::ranges::construct_at's placement new not intercepted

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 CC||ppalka at gcc dot gnu.org
   Last reconfirmed||2020-09-30

[Bug target/97257] New: FAIL: gcc.target/i386/movdir64b.c (test for excess errors)

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

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

Bug ID: 97257
   Summary: FAIL: gcc.target/i386/movdir64b.c (test for excess
errors)
   Product: gcc
   Version: 8.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

./xgcc -B./
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/gcc.target/i386/movdir64b.c
-mx32  -mmovdir64b -O2 -c
/tmp/ccbKBoZC.s: Assembler messages:
/tmp/ccbKBoZC.s:20: Error: invalid register operand size for `movdir64b'
[hjl@gnu-skx-1 gcc]$

[Bug ipa/97235] [11 Regression] ICE in duplicate, at ipa-prop.c:4251 since r11-3478-gada353b87909fd6c

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #2 from Jan Hubicka  ---
I am testing this fix. Problem is that when modref is disabled we never
relase ipa-prop datastructures.

2020-09-30  Jan Hubicka  

* ipa-fnsummary.c: (pass_free_fnsummary:execute): Call  
ipa_free_all_structures_after_iinln.
* ipa-modref.c (pass_ipa_modref::execute): Do not call
ipa_free_all_structures_after_iinln.
* ipa-prop.c (ipa_free_all_node_params): Do not crash if info
is not allocated.
(ipa_unregister_cgraph_hooks): Likewise.


diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c
index 4c1c1f91482..8285cc00d33 100644
--- a/gcc/ipa-fnsummary.c
+++ b/gcc/ipa-fnsummary.c
@@ -4680,6 +4680,8 @@ public:
   virtual unsigned int execute (function *)
 {
   ipa_free_fn_summary ();
+  /* Free ipa-prop structures if they are no longer needed.  */
+  ipa_free_all_structures_after_iinln ();
   if (!flag_wpa)
ipa_free_size_summary ();
   return 0;
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 6225552e41a..2f4da8f2a14 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -1681,8 +1681,6 @@ pass_ipa_modref::execute (function *)
 }
   ((modref_summaries *)summaries)->ipa = false;
   ipa_free_postorder_info ();
-  /* Free ipa-prop structures if they are no longer needed.  */
-  ipa_free_all_structures_after_iinln ();
   return 0;
 }

diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index b28c78eeab4..ea88fd3fd95 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -4124,7 +4124,8 @@ ipa_free_all_edge_args (void)
 void
 ipa_free_all_node_params (void)
 {
-  ggc_delete (ipa_node_params_sum);
+  if (ipa_node_params_sum)
+ggc_delete (ipa_node_params_sum);
   ipa_node_params_sum = NULL;
 }

@@ -4368,7 +4369,8 @@ ipa_register_cgraph_hooks (void)
 static void
 ipa_unregister_cgraph_hooks (void)
 {
-  symtab->remove_cgraph_insertion_hook (function_insertion_hook_holder);
+  if (function_insertion_hook_holder)
+symtab->remove_cgraph_insertion_hook (function_insertion_hook_holder);
   function_insertion_hook_holder = NULL;
 }

[Bug target/96827] [10/11 Regression] __m128i from _mm_set_epi32 is backwards with -O3

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

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

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

https://gcc.gnu.org/g:373b99dc40949efa697326f378e5022a02e0328b

commit r11-3565-g373b99dc40949efa697326f378e5022a02e0328b
Author: H.J. Lu 
Date:   Wed Sep 30 08:13:21 2020 -0700

Add a testcase for PR target/96827

Add a testcase for PR target/96827 which was fixed by r11-3559:

commit 97b798d80baf945ea28236eef3fa69f36626b579
Author: Joel Hutton 
Date:   Wed Sep 30 15:08:13 2020 +0100

[SLP][VECT] Add check to fix 96837

PR target/96827
* gcc.target/i386/pr96827.c: New test.

[Bug middle-end/97189] [11 Regression] ICE in attr_access::array_as_string at gcc/attribs.c:2276 since r11-3303-g6450f07388f9fe57

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

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
  Component|tree-optimization   |middle-end

[Bug target/96827] [10/11 Regression] __m128i from _mm_set_epi32 is backwards with -O3

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #11 from H.J. Lu  ---
GCC 10 branch isn't fixed.

[Bug tree-optimization/97255] [8/9/10/11 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

  Component|c++ |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.5
 Status|NEW |ASSIGNED

--- Comment #2 from Richard Biener  ---
I will have a look.

[Bug c++/97256] auto function return different result

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

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

--- Comment #1 from Richard Biener  ---
possibly this returns a reference to a local variable which is undefined?

[Bug libgomp/96837] A false if clause in "omp parallel" seriously affects the performance

[joel.hutton at arm dot com via Gcc-bugs]

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

Joel Hutton  changed:

   What|Removed |Added

 CC||joel.hutton at arm dot com

--- Comment #5 from Joel Hutton  ---
Sorry, my commit does not address this bug, I made a typo with PR number in the
commit message.

[Bug target/96827] [10/11 Regression] __m128i from _mm_set_epi32 is backwards with -O3

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

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

--- Comment #10 from Jakub Jelinek  ---
r11-3559-g97b798d80baf945ea28236eef3fa69f36626b579
(so that there is link to that commit).

[Bug target/94595] gcc.target/arm/thumb2-cond-cmp-*.c fail for cortex-m

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

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

commit r11-3564-gef11f5b37b0a62dbad9ed37613a3799dc98f6f8b
Author: Christophe Lyon 
Date:   Mon Sep 7 14:53:38 2020 +

arm: [testsuite] Skip thumb2-cond-cmp tests on Cortex-M [PR94595]

Since r204778 (g571880a0a4c512195aa7d41929ba6795190887b2), we favor
branches over IT blocks on Cortex-M. As a result, instead of
generating two nested IT blocks in thumb2-cond-cmp-[1234].c, we
generate either a single IT block, or use branches depending on
conditions tested by the program.

Since this was a deliberate change and the tests still pass as
expected on Cortex-A, this patch skips them when targetting
Cortex-M. The avoids the failures on Cortex M3, M4, and M33.  This
patch makes the testcases unsupported on Cortex-M7 although they pass
in this case because this CPU has different branch costs.

I tried to relax the scan-assembler directives using eg. cmpne|subne
or cmpgt|ble but that seemed fragile.

2020-09-07  Christophe Lyon  

gcc/testsuite/
PR target/94595
* gcc.target/arm/thumb2-cond-cmp-1.c: Skip if arm_cortex_m.
* gcc.target/arm/thumb2-cond-cmp-2.c: Skip if arm_cortex_m.
* gcc.target/arm/thumb2-cond-cmp-3.c: Skip if arm_cortex_m.
* gcc.target/arm/thumb2-cond-cmp-4.c: Skip if arm_cortex_m.

[Bug target/94595] gcc.target/arm/thumb2-cond-cmp-*.c fail for cortex-m

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

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #3 from Christophe Lyon  ---
Fixed on trunk

[Bug target/96827] [10/11 Regression] __m128i from _mm_set_epi32 is backwards with -O3

[joel.hutton at arm dot com via Gcc-bugs]

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

Joel Hutton  changed:

   What|Removed |Added

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

--- Comment #9 from Joel Hutton  ---
This is fixed on trunk by 97b798d8, unfortunately I made a typo in the commit
message.

[Bug target/97251] [10/11 Regression] arm: ICEs compiling pure-code/no-literal-pool.c with integer MVE

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

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

Alex Coplan  changed:

   What|Removed |Added

   Target Milestone|--- |10.3

[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

   Target Milestone|--- |10.3

[Bug target/96795] MVE: issue with polymorphism and integer promotion

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by SRINATH PARVATHANENI
:

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

commit r11-3560-g6bd4ce64eb48a72eca300cb52773e6101d646004
Author: Srinath Parvathaneni 
Date:   Wed Sep 30 15:19:17 2020 +0100

[GCC][PATCH] arm: Fix MVE intrinsics polymorphic variants wrongly
generating __ARM_undef type (pr96795).

Hello,

This patch fixes (PR96795) MVE intrinsic polymorphic variants vaddq,
vaddq_m, vaddq_x, vcmpeqq_m,
vcmpeqq, vcmpgeq_m, vcmpgeq, vcmpgtq_m, vcmpgtq, vcmpleq_m, vcmpleq,
vcmpltq_m, vcmpltq,
vcmpneq_m, vcmpneq, vfmaq_m, vfmaq, vfmasq_m, vfmasq, vmaxnmavq,
vmaxnmavq_p, vmaxnmvq,
vmaxnmvq_p, vminnmavq, vminnmavq_p, vminnmvq, vminnmvq_p, vmulq_m, vmulq,
vmulq_x, vsetq_lane,
vsubq_m, vsubq and vsubq_x which are incorrectly generating __ARM_undef and
mismatching the passed
floating point scalar arguments.

Bootstrapped on arm-none-linux-gnueabihf and regression tested on
arm-none-eabi and found no regressions.

Ok for master? Ok for GCC-10 branch?

Regards,
Srinath.

gcc/ChangeLog:

2020-09-30  Srinath Parvathaneni  

PR target/96795
* config/arm/arm_mve.h (__ARM_mve_coerce2): Define.
(__arm_vaddq): Correct the scalar argument.
(__arm_vaddq_m): Likewise.
(__arm_vaddq_x): Likewise.
(__arm_vcmpeqq_m): Likewise.
(__arm_vcmpeqq): Likewise.
(__arm_vcmpgeq_m): Likewise.
(__arm_vcmpgeq): Likewise.
(__arm_vcmpgtq_m): Likewise.
(__arm_vcmpgtq): Likewise.
(__arm_vcmpleq_m): Likewise.
(__arm_vcmpleq): Likewise.
(__arm_vcmpltq_m): Likewise.
(__arm_vcmpltq): Likewise.
(__arm_vcmpneq_m): Likewise.
(__arm_vcmpneq): Likewise.
(__arm_vfmaq_m): Likewise.
(__arm_vfmaq): Likewise.
(__arm_vfmasq_m): Likewise.
(__arm_vfmasq): Likewise.
(__arm_vmaxnmavq): Likewise.
(__arm_vmaxnmavq_p): Likewise.
(__arm_vmaxnmvq): Likewise.
(__arm_vmaxnmvq_p): Likewise.
(__arm_vminnmavq): Likewise.
(__arm_vminnmavq_p): Likewise.
(__arm_vminnmvq): Likewise.
(__arm_vminnmvq_p): Likewise.
(__arm_vmulq_m): Likewise.
(__arm_vmulq): Likewise.
(__arm_vmulq_x): Likewise.
(__arm_vsetq_lane): Likewise.
(__arm_vsubq_m): Likewise.
(__arm_vsubq): Likewise.
(__arm_vsubq_x): Likewise.

gcc/testsuite/ChangeLog:

PR target/96795
* gcc.target/arm/mve/intrinsics/mve_fp_vaddq_n.c: New Test.
* gcc.target/arm/mve/intrinsics/mve_vaddq_n.c: Likewise.
* gcc.target/arm/mve/intrinsics/vaddq_m_n_f16-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vaddq_m_n_f32-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vaddq_x_n_f16-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vaddq_x_n_f32-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpeqq_m_n_f16-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpeqq_m_n_f32-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpeqq_n_f16-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpeqq_n_f32-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpgeq_m_n_f16-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpgeq_m_n_f32-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpgeq_n_f16-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpgeq_n_f32-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpgtq_m_n_f16-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpgtq_m_n_f32-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpgtq_n_f16-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpgtq_n_f32-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpleq_m_n_f16-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpleq_m_n_f32-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpleq_n_f16-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpleq_n_f32-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpltq_m_n_f16-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpltq_m_n_f32-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpltq_n_f16-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpltq_n_f32-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpneq_m_n_f16-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpneq_m_n_f32-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpneq_n_f16-1.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcmpneq_n_f32-1.c: Likewise.
* 

[Bug libgomp/96837] A false if clause in "omp parallel" seriously affects the performance

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Joel Hutton :

https://gcc.gnu.org/g:97b798d80baf945ea28236eef3fa69f36626b579

commit r11-3559-g97b798d80baf945ea28236eef3fa69f36626b579
Author: Joel Hutton 
Date:   Wed Sep 30 15:08:13 2020 +0100

[SLP][VECT] Add check to fix 96837

The following patch adds a simple check to prevent slp stmts from
vector constructors being rearranged. vect_attempt_slp_rearrange_stmts
tries to rearrange to avoid a load permutation.

This fixes PR target/96837
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96827

gcc/ChangeLog:

2020-09-29  Joel Hutton  

PR target/96837
* tree-vect-slp.c (vect_analyze_slp): Do not call
vect_attempt_slp_rearrange_stmts for vector constructors.

gcc/testsuite/ChangeLog:

2020-09-29  Joel Hutton  

PR target/96837
* gcc.dg/vect/bb-slp-49.c: New test.

[Bug c++/97255] [8/9/10/11 Regression] Vectorizer gives a boolean a value of 255

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-09-30
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Vectorizer gives a boolean  |[8/9/10/11 Regression]
   |a value of 255  |Vectorizer gives a boolean
   ||a value of 255
   Keywords||wrong-code

--- Comment #1 from Martin Liška  ---
Confirmed, started with r7-717-geb09cdcb1a8b55b9.

[Bug c++/97256] New: auto function return different result

[tangyixuan at mail dot dlut.edu.cn via Gcc-bugs]

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

Bug ID: 97256
   Summary: auto function return different result
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tangyixuan at mail dot dlut.edu.cn
  Target Milestone: ---

Hi, when executing the following code, GCC reports 32765 while clang reports 1. 
Maybe there is something wrong?
$ cat s.cpp

#include 
auto func(const int a) {
  const int b = a;
  return [&](){ return b; };
}


int main() {
  auto c = func(1);
  std::cout << c() ;
  return 0;
}

$ g++ -std=c++2a s.cpp
$ ./a.out
32765


$ clang++ -std=c++2a s.cpp
$ ./a.out
1

[Bug target/97251] [10/11 Regression] arm: ICEs compiling pure-code/no-literal-pool.c with integer MVE

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

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

Alex Coplan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-09-30
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |acoplan at gcc dot 
gnu.org

[Bug sanitizer/97229] pointer-compare sanitizer is very slow due to __asan::IsAddressNearGlobal

[mail at milianw dot de via Gcc-bugs]

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

--- Comment #2 from Milian Wolff  ---
As I said, >99% of the samples point to this backtrace:

```

__sanitizer_ptr_cmp
__asanCheckForInvalidPointerPair
__asanCheckForInvalidPointerPair
__asan::IsInvalidPointerPair
__asan::GetGlobalAddressInformation(unsigned long, unsigned long, ...)
__asan::GetGlobalsForAddress(unsigned long, __asan_global*, ...)
__asan::isAddressNearGlobal
```

if you want per-line cost attribution, I'd first have to compile the sanitizer
runtime with debug symbols.

If you really need the `perf report` output instead (why?) I can redo the
measurement again.

[Bug fortran/97242] Pointer assignment: Noncontiguous target to contiguous pointer wrongly accepted.

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #1 from Tobias Burnus  ---
FIXED – but the git-hook script did not add the commit :-(

r11-3556-g65167982efa4dbb96698d026e6d7e17acb513f0a
commit 65167982efa4dbb96698d026e6d7e17acb513f0a
Author: Tobias Burnus 
Date:   Wed Sep 30 15:01:13 2020 +0200

Fortran: add contiguous check for ptr assignment, fix non-contig check
(PR97242)

gcc/fortran/ChangeLog:

PR fortran/97242
* expr.c (gfc_is_not_contiguous): Fix check.
(gfc_check_pointer_assign): Use it.

gcc/testsuite/ChangeLog:

PR fortran/97242
* gfortran.dg/contiguous_11.f90: New test.
* gfortran.dg/contiguous_4.f90: Update.
* gfortran.dg/contiguous_7.f90: Update.

[Bug target/97184] Incorrect MOVDIRI and MOVDIR64B patterns

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
Fix for GCC 8.5, GCC 9.4, GCC 10.3 and GCC 11.

[Bug target/97184] Incorrect MOVDIRI and MOVDIR64B patterns

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

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

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

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

commit r8-10556-gb0e6f198547d423b24520c13e3c29f3712026fce
Author: H.J. Lu 
Date:   Wed Sep 23 12:11:45 2020 -0700

x86: Use SET operation in MOVDIRI and MOVDIR64B

Since MOVDIRI and MOVDIR64B write to memory, similar to UNSPEC_MOVNT,
use SET operation in MOVDIRI and MOVDIR64B patterns with UNSPEC instead
of UNSPECV.

gcc/

PR target/97184
* config/i386/i386.md (UNSPECV_MOVDIRI): Renamed to ...
(UNSPEC_MOVDIRI): This.
(UNSPECV_MOVDIR64B): Renamed to ...
(UNSPEC_MOVDIR64B): This.
(movdiri): Use SET operation.
(@movdir64b_): Likewise.

gcc/testsuite/

PR target/97184
* gcc.target/i386/movdir64b.c: New test.
* gcc.target/i386/movdiri32.c: Likewise.
* gcc.target/i386/movdiri64.c: Likewise.
* lib/target-supports.exp (check_effective_target_movdir): New.

(cherry picked from commit 5521e8a629f8bee3a7778d69521d857496556d1f)

[Bug target/97184] Incorrect MOVDIRI and MOVDIR64B patterns

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

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

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

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

commit r9-8959-gcbe1264d10f34d514cae5f002e0d717bbc8d32a3
Author: H.J. Lu 
Date:   Wed Sep 23 12:11:45 2020 -0700

x86: Use SET operation in MOVDIRI and MOVDIR64B

Since MOVDIRI and MOVDIR64B write to memory, similar to UNSPEC_MOVNT,
use SET operation in MOVDIRI and MOVDIR64B patterns with UNSPEC instead
of UNSPECV.

gcc/

PR target/97184
* config/i386/i386.md (UNSPECV_MOVDIRI): Renamed to ...
(UNSPEC_MOVDIRI): This.
(UNSPECV_MOVDIR64B): Renamed to ...
(UNSPEC_MOVDIR64B): This.
(movdiri): Use SET operation.
(@movdir64b_): Likewise.

gcc/testsuite/

PR target/97184
* gcc.target/i386/movdir64b.c: New test.
* gcc.target/i386/movdiri32.c: Likewise.
* gcc.target/i386/movdiri64.c: Likewise.
* lib/target-supports.exp (check_effective_target_movdir): New.

(cherry picked from commit 5521e8a629f8bee3a7778d69521d857496556d1f)

[Bug target/97184] Incorrect MOVDIRI and MOVDIR64B patterns

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

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

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

https://gcc.gnu.org/g:021c792a36143f3aaaf27efc7190c6e59b56f084

commit r10-8829-g021c792a36143f3aaaf27efc7190c6e59b56f084
Author: H.J. Lu 
Date:   Wed Sep 23 12:11:45 2020 -0700

x86: Use SET operation in MOVDIRI and MOVDIR64B

Since MOVDIRI and MOVDIR64B write to memory, similar to UNSPEC_MOVNT,
use SET operation in MOVDIRI and MOVDIR64B patterns with UNSPEC instead
of UNSPECV.

gcc/

PR target/97184
* config/i386/i386.md (UNSPECV_MOVDIRI): Renamed to ...
(UNSPEC_MOVDIRI): This.
(UNSPECV_MOVDIR64B): Renamed to ...
(UNSPEC_MOVDIR64B): This.
(movdiri): Use SET operation.
(@movdir64b_): Likewise.

gcc/testsuite/

PR target/97184
* gcc.target/i386/movdir64b.c: New test.
* gcc.target/i386/movdiri32.c: Likewise.
* gcc.target/i386/movdiri64.c: Likewise.
* lib/target-supports.exp (check_effective_target_movdir): New.

(cherry picked from commit 5521e8a629f8bee3a7778d69521d857496556d1f)

[Bug c++/97255] New: Vectorizer gives a boolean a value of 255

[iwans at xilinx dot com via Gcc-bugs]

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

Bug ID: 97255
   Summary: Vectorizer gives a boolean a value of 255
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iwans at xilinx dot com
  Target Milestone: ---

Created attachment 49292
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49292=edit
Minimal file demonstrating bug

Here is a godbolt link demonstrating the bug: https://godbolt.org/z/jK8Wsz

The following function with -O3 assigns a value of 255 to variables in the out
array. Building with -O3 -fno-tree-vectorize allows the code to execute
correctly 

void
logicalOr(Array< char, 4 > in1[60], 
Array< bool, 4 > out[60])
{
for (unsigned k0 = 0u; k0 < 60u; ++k0) {
Array< char, 4 > in1m = in1[k0];
Array< bool, 4 > x;
for (unsigned k1 = 0u; k1 < 4u; ++k1) {
char in1s = in1m[k1];
x[k1] = in1s != char(0) || in1s != char(0);
}
out[k0] = x;
}
}


build the attached cpp file (it has no #includes) with 

(Buggy)
gcc -O3 vectorizedBool.cpp
./a.out
echo $? // correct value is 1. Actually returns 255

(Not buggy)
gcc -O3 -fno-tree-vectorize vectorizedBool.cpp 
./a.out
echo $? // correct value is 1. returns 1

Here is some output from -v

COLLECT_GCC=/opt/compiler-explorer/gcc-10.2.0/bin/g++

Target: x86_64-linux-gnu

Configured with: ../gcc-10.2.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,go,d --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build

Thread model: posix

Supported LTO compression algorithms: zlib

gcc version 10.2.0 (Compiler-Explorer-Build) 

COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' './output.s'
'-masm=intel' '-S' '-v' '-O3' '-g' '-Wall' '-Wextra' '-fno-strict-aliasing'
'-fwrapv' '-fno-aggressive-loop-optimizations' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'


/opt/compiler-explorer/gcc-10.2.0/bin/../libexec/gcc/x86_64-linux-gnu/10.2.0/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-10.2.0/bin/../lib/gcc/x86_64-linux-gnu/10.2.0/
-D_GNU_SOURCE  -quiet -dumpbase example.cpp -masm=intel -mtune=generic
-march=x86-64 -auxbase-strip ./output.s -g -g -O3 -Wall -Wextra -version
-fdiagnostics-color=always -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -o ./output.s

GNU C++14 (Compiler-Explorer-Build) version 10.2.0 (x86_64-linux-gnu)

compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP



GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

[Bug fortran/97045] A wrong column is selected when addressing individual elements of unlimited polymorphic dummy argument

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r11-3554-gfcc4891d7f3bff1a3f7428f12830bc942989306c
Author: Paul Thomas 
Date:   Wed Sep 30 13:44:39 2020 +0100

This patch fixes PR97045 - unlimited polymorphic array element selectors.

2020-30-09  Paul Thomas  

gcc/fortran
PR fortran/97045
* trans-array.c (gfc_conv_array_ref): Make sure that the class
decl is passed to build_array_ref in the case of unlimited
polymorphic entities.
* trans-expr.c (gfc_conv_derived_to_class): Ensure that array
refs do not preceed the _len component. Free the _len expr.
* trans-stmt.c (trans_associate_var): Reset 'need_len_assign'
for polymorphic scalars.
* trans.c (gfc_build_array_ref): When the vptr size is used for
span, multiply by the _len field of unlimited polymorphic
entities, when non-zero.

gcc/testsuite/
PR fortran/97045
* gfortran.dg/select_type_50.f90 : New test.

[Bug target/97184] Incorrect MOVDIRI and MOVDIR64B patterns

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

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

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

https://gcc.gnu.org/g:46183c96d2aea8181efb6bc3cfdb221987fe002d

commit r11-3552-g46183c96d2aea8181efb6bc3cfdb221987fe002d
Author: H.J. Lu 
Date:   Wed Sep 23 12:11:45 2020 -0700

x86: Use SET operation in MOVDIRI and MOVDIR64B

Since MOVDIRI and MOVDIR64B write to memory, similar to UNSPEC_MOVNT,
use SET operation in MOVDIRI and MOVDIR64B patterns with UNSPEC instead
of UNSPECV.

gcc/

PR target/97184
* config/i386/i386.md (UNSPECV_MOVDIRI): Renamed to ...
(UNSPEC_MOVDIRI): This.
(UNSPECV_MOVDIR64B): Renamed to ...
(UNSPEC_MOVDIR64B): This.
(movdiri): Use SET operation.
(@movdir64b_): Likewise.

gcc/testsuite/

PR target/97184
* gcc.target/i386/movdir64b.c: New test.
* gcc.target/i386/movdiri32.c: Likewise.
* gcc.target/i386/movdiri64.c: Likewise.
* lib/target-supports.exp (check_effective_target_movdir): New.

[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 #1 from Florian Weimer  ---
First patch committed (preparatory only):
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=92e652d8c21bd7e66c

Second patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/555174.html

[Bug target/97127] FMA3 code transformation leads to slowdown on Skylake

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #18 from rsandifo at gcc dot gnu.org  
---
Not sure this is a good idea or not, but: combine could
look at the constraints of the instruction it matches,
compare that with the information it has about whether
the inputs remain live after the instruction, and cost
in an extra move if all alternatives require a reload.

[Bug target/97254] New: [nvptx] Define PCC_BITFIELD_TYPE_MATTERS

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

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

Bug ID: 97254
   Summary: [nvptx] Define PCC_BITFIELD_TYPE_MATTERS
   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: ---

While debugging gcc/testsuite/gcc.dg/pr94600-1.c, I found that nvptx doesn't
define PCC_BITFIELD_TYPE_MATTERS.

AFAIU, the theory for offloading is that settings that influence abi should be
compatible with the host.

And in i386.h, we find:
...
 /* If bit field type is int, don't let it cross an int,
   and give entire struct the alignment of an int.  */
/* Required on the 386 since it doesn't have bit-field insns.  */
#define PCC_BITFIELD_TYPE_MATTERS 1
...

OTOH, the value may be different for other hosts.

On the llvm side, we find this comment in
llvm.git/clang/lib/Basic/Targets/ARM.cpp:
...
  // Do not respect the alignment of bit-field types when laying out
  // structures. This corresponds to PCC_BITFIELD_TYPE_MATTERS in gcc.  
  UseBitFieldTypeAlignment = false;
...
and in llvm.git/clang/lib/Basic/Targets/NVPTX.cpp:
...
  UseBitFieldTypeAlignment = HostTarget->useBitFieldTypeAlignment();
...
which seems to confirm that approach.

It should be possible to get the host target by looking at the
--enable-as-accelerator, and figure out the value from there.

OTOH, it's possible that for GCC the nvptx implementation of the hook is moot,
given that part of the processing is done in the host compiler.

That does not answer the question what to do for the standalone target though.
But probably, given that the value is set for both known offloading hosts
x86_64 and ppc, it might be a good idea to have the standalone target do the
same.

[Bug c++/97253] [c++20] last character not shown when printing out std::array via -Wunused-local-typedefs

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed||2020-09-30
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
I think the bug is that it's trying to print char[4] as a quoted string, rather
than as an array of four elements. I would expect it to show {'a','b','c','d'}
instead.

[Bug target/97150] [AArch64] 2nd parameter of unsigned Neon scalar shift intrinsics should be signed

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2020-09-30
   Target Milestone|--- |8.5
  Known to fail||10.0, 8.4.1, 9.3.1
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
 CC||ktkachov at gcc dot gnu.org
  Known to work||11.0

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Fixed on trunk. Will backport to the branches later

[Bug target/96313] [AArch64] vqmovun* return types should be unsigned

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
 Status|NEW |ASSIGNED
 CC||ktkachov at gcc dot gnu.org
  Known to work||11.0
   Target Milestone|--- |8.5
  Known to fail||10.0, 8.4.1, 9.3.1

--- Comment #6 from ktkachov at gcc dot gnu.org ---
Fixed on trunk. Will backport to branches later

[Bug target/97150] [AArch64] 2nd parameter of unsigned Neon scalar shift intrinsics should be signed

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Kyrylo Tkachov :

https://gcc.gnu.org/g:2d8fbebdb1eaca8de557ab3052535a8e4b8f8972

commit r11-3548-g2d8fbebdb1eaca8de557ab3052535a8e4b8f8972
Author: Kyrylo Tkachov 
Date:   Wed Sep 30 12:01:23 2020 +0100

PR target/97150 AArch64: 2nd parameter of unsigned Neon scalar shift
intrinsics should be signed

In this PR the second argument to the intrinsics should be signed but we
use an unsigned one erroneously.
The corresponding builtins are already using the correct types so it's
just a matter of correcting the signatures in arm_neon.h

gcc/
PR target/97150
* config/aarch64/arm_neon.h (vqrshlb_u8): Make second argument
signed.
(vqrshlh_u16): Likewise.
(vqrshls_u32): Likewise.
(vqrshld_u64): Likewise.
(vqshlb_u8): Likewise.
(vqshlh_u16): Likewise.
(vqshls_u32): Likewise.
(vqshld_u64): Likewise.
(vshld_u64): Likewise.

gcc/testsuite/
PR target/97150
* gcc.target/aarch64/pr97150.c: New test.

[Bug target/96313] [AArch64] vqmovun* return types should be unsigned

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Kyrylo Tkachov :

https://gcc.gnu.org/g:135b043196b5575c690ef1e07bcbb49bf037c3a2

commit r11-3547-g135b043196b5575c690ef1e07bcbb49bf037c3a2
Author: Kyrylo Tkachov 
Date:   Wed Sep 30 12:00:20 2020 +0100

PR target/96313 AArch64: vqmovun* return types should be unsigned

In this PR we have the wrong return type for some intrinsics. It should
be unsigned, but we implement it as signed.
Fix this by adjusting the type qualifiers used when creating the
builtins and fixing the type in the arm_neon.h intrinsic.
With the adjustment in qualifiers we now don't need to cast the result
when returning.

Bootstrapped and tested on aarch64-none-linux-gnu.

gcc/
PR target/96313
* config/aarch64/aarch64-simd-builtins.def (sqmovun): Use UNOPUS
qualifiers.
* config/aarch64/arm_neon.h (vqmovun_s16): Adjust builtin call.
Remove unnecessary result cast.
(vqmovun_s32): Likewise.
(vqmovun_s64): Likewise.
(vqmovunh_s16): Likewise.  Fix return type.
(vqmovuns_s32): Likewise.
(vqmovund_s64): Likewise.

gcc/testsuite/
PR target/96313
* gcc.target/aarch64/pr96313.c: New test.
* gcc.target/aarch64/scalar_intrinsics.c (test_vqmovunh_s16):
Adjust return type.
(test_vqmovuns_s32): Likewise.
(test_vqmovund_s64): Likewise.

[Bug c++/97253] New: [c++20] last character not shown when printing out std::array via -Wunused-local-typedefs

[dimitri.gorokhovik at free dot fr via Gcc-bugs]

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

Bug ID: 97253
   Summary: [c++20] last character not shown when printing out
std::array  via -Wunused-local-typedefs
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimitri.gorokhovik at free dot fr
  Target Milestone: ---

The following code:

#include 
#include 

template  struct s { constexpr static auto m = M; };

int main ()
{
  constexpr auto s1 = s  { 'a', 'b', 'c', 'd' }> {};
  constexpr auto s2 = s  { 'a', 'b', 'c', 'd' }> {};  

  using _1 = decltype (s1);
  using _2 = decltype (s2);

  for (auto i : s1.m)
printf ("%c", i);
  printf ("\n");

  return 0;
};


when built as:
g++ -std=c++20 -Wunused-local-typedefs -o bug-7  bug-7.cpp && ./bug-7

produces the following warnings:

bug-7.cpp: In function ‘int main()’:
bug-7.cpp:11:9: warning: typedef ‘using _1 = const struct s{"abc"}>’ locally defined but not used [-Wunused-local-typedefs]
   11 |   using _1 = decltype (s1);
  | ^~
bug-7.cpp:12:9: warning: typedef ‘using _2 = const struct s{std::__array_traits::_Type{97, 98, 99, 100}}>’ locally defined
but not used [-Wunused-local-typedefs]
   12 |   using _2 = decltype (s2);
  | ^~

When it is run, the output is:
abcd

I.e., when the warning displays the contents of the literal of the type
std::array , it presents it as a character string ("abc") in which the
last character is missing ('d' in this example). This doesn't happen when the
array type doesn't allow to show it as char string -- all array elements are
shown.

Running the binary confirms that the array literal actually contains the
non-shown character.

g++ (GCC) 11.0.0 20200924 (experimental)

[Bug fortran/97242] Pointer assignment: Noncontiguous target to contiguous pointer wrongly accepted.

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

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
   Last reconfirmed||2020-09-30
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/97236] [10/11 Regression] g:e93428a8b056aed83a7678 triggers vlc miscompile

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Richard Biener from comment #4)
> So what goes wrong is the single-element interleaving code-gen for the
> pointer copy.  We have
> 
> t.c:18:21: note:   Detected single element interleaving
> picture_7(D)->p[i_18].p_pixels step 16
> 
> but for the store:
> 
> t.c:18:21: missed:   not consecutive access res_8(D)->p[i_18].p_pixels = _1;
> t.c:18:21: note:   using strided accesses
> 
> ...
> 
> t.c:18:21: note:   ==> examining statement: _1 =
> picture_7(D)->p[i_18].p_pixels;
> t.c:18:21: note:   vect_model_load_cost: aligned.
> t.c:18:21: note:   vect_model_load_cost: inside_cost = 24, prologue_cost = 0
> .
> 
> and in group get-load-store type we handle it as (V1DI)
> 
>   if (!STMT_VINFO_STRIDED_P (first_stmt_info)
>   && (can_overrun_p || !would_overrun_p)
>   && compare_step_with_zero (vinfo, stmt_info) > 0)
> {
>   /* First cope with the degenerate case of a single-element
>  vector.  */
>   if (known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U))
> *memory_access_type = VMAT_CONTIGUOUS;

So both doing && gap == 0 here and removing this special-case alltogether
passes bootstrap / regtest on x86_64.

I have no idea why the special case was needed in the first place?
Was the load-lanes code confused?  I think VMAT_ELEMENTWISE for
single-element vectors is a good enough match?  What's the advantage
of VMAT_CONTIGUOUS here?

[Bug target/97252] New: [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

Bug ID: 97252
   Summary: [10/11 Regression] arm: ICE compiling
pure-code/pr94538-2.c with MVE since
r10-7293-g3eff57aa
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

Since r10-7293-g3eff57aacfef6e05f55e9dd6ecae3ef8568aaac4, AArch32 GCC ICEs
compiling gcc/testsuite/gcc.target/arm/pure-code/pr94538-2.c.

To reproduce:

$ arm-eabi-gcc -c pr94538-2.c -march=armv8.1-m.main+mve -mpure-code
during RTL pass: final
pr94538-2.c: In function 'foo':
pr94538-2.c:12:1: internal compiler error: in arm_print_operand, at
config/arm/arm.c:24158
   12 | }
  | ^
0x111a814 arm_print_operand
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm.c:24158
0x92a8ca output_operand(rtx_def*, int)
/home/alecop01/toolchain/src/gcc/gcc/final.c:4051
0x92b3ac output_asm_insn(char const*, rtx_def**)
/home/alecop01/toolchain/src/gcc/gcc/final.c:3944
0x15b7ed4 output_2993
/home/alecop01/toolchain/src/gcc/gcc/config/arm/mve.md:728
0x92a2ad get_insn_template(int, rtx_insn*)
/home/alecop01/toolchain/src/gcc/gcc/final.c:2070
0x92ddbb final_scan_insn_1
/home/alecop01/toolchain/src/gcc/gcc/final.c:3039
0x92e0a6 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/alecop01/toolchain/src/gcc/gcc/final.c:3152
0x92ecac final_1
/home/alecop01/toolchain/src/gcc/gcc/final.c:2020
0x92f00a rest_of_handle_final
/home/alecop01/toolchain/src/gcc/gcc/final.c:4658
0x92f00a execute
/home/alecop01/toolchain/src/gcc/gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/97251] [10/11 Regression] arm: ICEs compiling pure-code/no-literal-pool.c with integer MVE

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

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

--- Comment #2 from Alex Coplan  ---
Fixed on trunk. Needs backporting to GCC 10.

[Bug target/97251] [10/11 Regression] arm: ICEs compiling pure-code/no-literal-pool.c with integer MVE

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Alex Coplan :

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

commit r11-3545-gf63023fafbbc13545fef67e6b32a55b48a945fcf
Author: Alex Coplan 
Date:   Wed Sep 30 09:02:47 2020 +0100

arm: Fix ICEs in no-literal-pool.c on MVE [PR97251]

This patch fixes ICEs when compiling
gcc/testsuite/gcc.target/arm/pure-code/no-literal-pool.c with
-mfp16-format=ieee -mfloat-abi=hard -march=armv8.1-m.main+mve
-mpure-code.

The existing conditions in the movsf/movdf expanders (as well as the
no_literal_pool patterns) were too restrictive, requiring
TARGET_HARD_FLOAT instead of TARGET_VFP_BASE, which caused unrecognised
insns when compiling this testcase with integer MVE and -mpure-code.

gcc/ChangeLog:

PR target/97251
* config/arm/arm.md (movsf): Relax TARGET_HARD_FLOAT to
TARGET_VFP_BASE.
(movdf): Likewise.
* config/arm/vfp.md (no_literal_pool_df_immediate): Likewise.
(no_literal_pool_sf_immediate): Likewise.

[Bug target/97251] New: [10/11 Regression] arm: ICEs compiling pure-code/no-literal-pool.c with integer MVE

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

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

Bug ID: 97251
   Summary: [10/11 Regression] arm: ICEs compiling
pure-code/no-literal-pool.c with integer MVE
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

Since r10-7193-g63c8f7d6a082b1cd0519fe06d4ed506b04280921, GCC ICEs compiling
gcc/testsuite/gcc.target/arm/pure-code/no-literal-pool.c with integer MVE.

To reproduce:

$ arm-eabi-gcc no-literal-pool.c -c -march=armv8.1-m.main+mve
-mfp16-format=ieee -mpure-code -mfloat-abi=hard
no-literal-pool.c: In function 'testsfp16':
no-literal-pool.c:20:1: error: unrecognizable insn:
   20 | }
  | ^
(insn 33 32 34 2 (set (reg:SF 1 r1)
(const_double:SF 1.1233999729156494140625e+0 [0x0.8fcb92p+1]))
"no-literal-pool.c":16:6 -1
 (nil))
during RTL pass: vregs
no-literal-pool.c:20:1: internal compiler error: in extract_insn, at
recog.c:2294
0xc6c405 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/alecop01/toolchain/src/gcc/gcc/rtl-error.c:108
0xc6c424 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/alecop01/toolchain/src/gcc/gcc/rtl-error.c:116
0xc3bf7f extract_insn(rtx_insn*)
/home/alecop01/toolchain/src/gcc/gcc/recog.c:2294
0x97d49a instantiate_virtual_regs_in_insn
/home/alecop01/toolchain/src/gcc/gcc/function.c:1607
0x97d49a instantiate_virtual_regs
/home/alecop01/toolchain/src/gcc/gcc/function.c:1977
0x97d49a execute
/home/alecop01/toolchain/src/gcc/gcc/function.c:2026
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I have a patch (already approved) to fix the issue:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/555069.html, just
opening the bug to track backporting progress.

[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

Florian Weimer  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-30
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug target/97250] New: 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

Bug ID: 97250
   Summary: Implement -march=x86-64-v2, -march=x86-64-v3,
-march=x86-64-v4 for x86-64
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: fw at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

x86-64-v2, x86-64-v3, x86-64-v4 have been added to the psABI as new
micro-architecture levels:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9a6b9396884b67c7c

GCC should provide -march= options so that programmers can easily built
programs and shared objects that are optimized for these levels.

[Bug target/96968] aarch64 : ICE in vregs or expand pass, lowering __builtin_aarch64_get_{fpcr,fpsr,fpcr64,fpsr64}

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

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

akrl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from akrl at gcc dot gnu.org ---
Thanks, closing.

[Bug rtl-optimization/97249] Missing vec_select and subreg optimization

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-30
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Richard Biener  ---
Guess you want to figure what built the (vec_select:V8QI (V16QI)) and if
it was appropriately simplified (and simplify_rtx would handle this case).
In any case the vec_select is the same as (subreg:V8QI (V16QI)).

[Bug rtl-optimization/97249] Missing vec_select and subreg optimization

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #1)
> for i386 backend, maybe we can adjust pattern of
> 
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 934b60a288f..2bfa9635fab 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -17658,12 +17658,7 @@ (define_expand "v32qiv32hi2"
>  (define_insn "sse4_1_v8qiv8hi2"
>[(set (match_operand:V8HI 0 "register_operand" "=Yr,*x,v")
> (any_extend:V8HI
> - (vec_select:V8QI
> -   (match_operand:V16QI 1 "register_operand" "Yr,*x,v")
> -   (parallel [(const_int 0) (const_int 1)
> -  (const_int 2) (const_int 3)
> -  (const_int 4) (const_int 5)
> -  (const_int 6) (const_int 7)]]
> + (subreg:V8HI(match_operand:V16QI 1 "register_operand" "Yr,*x,v")
> 0)))]
>"TARGET_SSE4_1 &&  && "
>"%vpmovbw\t{%1, %0|%0, %1}"
>[(set_attr "isa" "noavx,noavx,avx")

Correct typo 
 @@ -17658,12 +17658,7 @@ (define_expand "v32qiv32hi2"
  (define_insn "sse4_1_v8qiv8hi2"
[(set (match_operand:V8HI 0 "register_operand" "=Yr,*x,v")
 (any_extend:V8HI
 - (vec_select:V8QI
 -   (match_operand:V16QI 1 "register_operand" "Yr,*x,v")
 -   (parallel [(const_int 0) (const_int 1)
 -  (const_int 2) (const_int 3)
 -  (const_int 4) (const_int 5)
 -  (const_int 6) (const_int 7)]]
 + (subreg:V8HI (match_operand:V16QI 1 "register_operand" "Yr,*x,v")
> 0)))]

[Bug rtl-optimization/97249] Missing vec_select and subreg optimization

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
for i386 backend, maybe we can adjust pattern of

diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 934b60a288f..2bfa9635fab 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -17658,12 +17658,7 @@ (define_expand "v32qiv32hi2"
 (define_insn "sse4_1_v8qiv8hi2"
   [(set (match_operand:V8HI 0 "register_operand" "=Yr,*x,v")
(any_extend:V8HI
- (vec_select:V8QI
-   (match_operand:V16QI 1 "register_operand" "Yr,*x,v")
-   (parallel [(const_int 0) (const_int 1)
-  (const_int 2) (const_int 3)
-  (const_int 4) (const_int 5)
-  (const_int 6) (const_int 7)]]
+ (subreg:V8QI(match_operand:V16QI 1 "register_operand" "Yr,*x,v")
0)))]
   "TARGET_SSE4_1 &&  && "
   "%vpmovbw\t{%1, %0|%0, %1}"
   [(set_attr "isa" "noavx,noavx,avx")

[Bug c++/97246] [10/11 regression] mismatched argument pack lengths since r10-7865-gaedd04caa945260e

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-09-30
 Ever confirmed|0   |1
Summary|[10/11 regression]  |[10/11 regression]
   |mismatched argument pack|mismatched argument pack
   |lengths |lengths since
   ||r10-7865-gaedd04caa945260e
 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to fail||11.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-7865-gaedd04caa945260e.

[Bug rtl-optimization/97249] New: Missing vec_select and subreg optimization

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 97249
   Summary: Missing vec_select and subreg optimization
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com, wwwhhhyyy333 at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Cat test.c
---
void
foo (unsigned char* p1, unsigned char* p2, short* __restrict p3)
{
for (int i = 0 ; i != 8; i++)
 p3[i] = p1[i] + p2[i];
 return;
}
---

gcc11 -Ofast -mavx2 test.c  got

---
foo:
.LFB0:
.cfi_startproc
vmovq   (%rdi), %xmm0
vmovq   (%rsi), %xmm1
vpmovzxbw   %xmm0, %xmm0
vpmovzxbw   %xmm1, %xmm1
vpaddw  %xmm1, %xmm0, %xmm0
vmovdqu %xmm0, (%rdx)
ret
.cfi_endproc
---

memory operand doesn't propagate into *vpmovzxbw* because rtl didn't simplify
---
(insn 9 8 10 2 (set (reg:V8HI 92 [ vect__33.6 ])
(zero_extend:V8HI (vec_select:V8QI (subreg:V16QI (reg:V8QI 91 [
vect__40.5 ]) 0)
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
(const_int 4 [0x4])
(const_int 5 [0x5])
(const_int 6 [0x6])
(const_int 7 [0x7])
] "test.c":5:16 4638 {sse4_1_zero_extendv8qiv8hi2}
 (expr_list:REG_DEAD (reg:V8QI 91 [ vect__40.5 ])
(nil)))
--- 

to 

---
(insn 9 8 10 2 (set (reg:V8HI 92 [ vect__33.6 ])
(zero_extend:V8HI (reg:V8QI 91 [ vect__40.5 ] "test.c":5:16 4638
{sse4_1_zero_extendv8qiv8hi2}
 (expr_list:REG_DEAD (reg:V8QI 91 [ vect__40.5 ])
(nil)))
---

Similar for other vector modes.

[Bug c++/97246] [10/11 regression] mismatched argument pack lengths

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[10.1 regression]   |[10/11 regression]
   |mismatched argument pack|mismatched argument pack
   |lengths |lengths
   Keywords||rejects-valid
  Known to fail||10.1.0
  Known to work||9.3.0
   Target Milestone|--- |10.3