[Bug c++/95310] [concepts] Unrelated template parameters printed in diagnostic

[ensadc at mailnesia dot com via Gcc-bugs]

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

--- Comment #3 from ensadc at mailnesia dot com ---
When verifying the fix, I noticed a new bug:


template  requires true
using iter_reference_t = decltype(*T{});

template 
struct result {
  using type = iter_reference_t;
};

template 
concept indirectly_writable = requires(Out&& o, T&& t) {
  iter_reference_t(*o) = 0;
};

template
requires indirectly_writable>
void copy(In in, Out out) {}

void test(const int* p, int* q) {
copy(q, p);
}


: In function 'void test(const int*, int*)':
:19:14: error: no matching function for call to 'copy(int*&, const
int*&)'
   19 | copy(q, p);
  |  ^
:16:6: note: candidate: 'template  requires 
indirectly_writable void copy(In, Out)'
   16 | void copy(In in, Out out) {}
  |  ^~~~
:16:6: note:   template argument deduction/substitution failed:
:16:6: note: constraints not satisfied
: In substitution of 'template  requires 
indirectly_writable void copy(In, Out) [with In = int*; Out
= const int*]':
:19:14:   required from here
:10:9:   required for the satisfaction of 'indirectly_writable >' [with Out = const int*; In = int*]
:10:31:   in requirements with 'Out&& o', 'T&& t' [with T = int&; Out =
const int*]
:11:29: note: the required expression 'decltype(*{})(*o)=0' is invalid
   11 |   iter_reference_t(*o) = 0;
  |   ~~^~~
cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more
detail


In

  :10:9:   required for the satisfaction of 'indirectly_writable >' [with Out = const int*; In = int*]

Note the mismatch between `F` and `In`.

GCC 10.2 prints `F = int*` instead of `In = int*`:

  :10:9:   required for the satisfaction of 'indirectly_writable >' [with Out = const int*; F = int*]

The name `F` comes from a completely unrelated class template, but at least the
names match in GCC 10.2.

(Interestingly, the alias template is not expanded in this line.)

[Bug c++/97452] [coroutines] incorrect sequencing of await_resume() when multiple co_await expressions occur in a single statement

[davidledger at live dot com.au via Gcc-bugs]

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

David Ledger  changed:

   What|Removed |Added

 CC||davidledger at live dot com.au

--- Comment #2 from David Ledger  ---
I'm happy to use this thread for the issue, I can just repost my link to the
same issue here.

My reporting of the issue is here, but Lewis Bakers example is seperate.

https://stackoverflow.com/questions/64348125/c20-coroutines-unexpected-reordering-of-await-resume-return-value-and-yield

Is there anything I can do to help this issue get resolved? I've been throwing
things at the wall trying to get something to stick (for a work around) but so
far nothing helps with this particular case.

[Bug libstdc++/97465] cross build gcc with vtv enabled failed. Cannot find out headers in glibc why?

[euloanty at live dot com via Gcc-bugs]

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

--- Comment #3 from fdlbxtqi  ---
(In reply to Jonathan Wakely from comment #2)
> e.g. what kind of cross build? We're not psychic.

I try to build x86_64-linux-gnu to x86_64-linux-gnu lol since I do not want vtv
to ruin my ABIs.

However, after I disabled vtv, the build is successful without any problems.
The new toolchain works just fine.

[Bug c++/82343] internal compiler error: Segmentation fault - template recurrency, SFINAE

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Fixed by r10-6464.

[Bug tree-optimization/97466] New: ICE in vect_get_and_check_slp_defs, at tree-vect-slp.c:538 (at -O3)

[su at cs dot ucdavis.edu via Gcc-bugs]

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

Bug ID: 97466
   Summary: ICE in vect_get_and_check_slp_defs, at
tree-vect-slp.c:538 (at -O3)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

[503] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201016 (experimental) [master revision
3e8d8f3b883:93f23a96b87:02629b116eed7c6911ef0eb2ef97e1883e9fb1de] (GCC) 
[504] % 
[504] % gcctk -O2 small.c
[505] % 
[505] % gcctk -O3 small.c
during GIMPLE pass: vect
small.c: In function ‘main’:
small.c:59:5: internal compiler error: in vect_get_and_check_slp_defs, at
tree-vect-slp.c:538
   59 | int main () {
  | ^~~~
0xfdf1ee vect_get_and_check_slp_defs
../../gcc-trunk/gcc/tree-vect-slp.c:536
0xfe4c11 vect_build_slp_tree_2
../../gcc-trunk/gcc/tree-vect-slp.c:1443
0xfe36e9 vect_build_slp_tree
../../gcc-trunk/gcc/tree-vect-slp.c:1266
0xfe4d2c vect_build_slp_tree_2
../../gcc-trunk/gcc/tree-vect-slp.c:1486
0xfe36e9 vect_build_slp_tree
../../gcc-trunk/gcc/tree-vect-slp.c:1266
0xfe4d2c vect_build_slp_tree_2
../../gcc-trunk/gcc/tree-vect-slp.c:1486
0xfe36e9 vect_build_slp_tree
../../gcc-trunk/gcc/tree-vect-slp.c:1266
0xfeae71 vect_analyze_slp_instance
../../gcc-trunk/gcc/tree-vect-slp.c:2135
0xfee1da vect_analyze_slp(vec_info*, unsigned int)
../../gcc-trunk/gcc/tree-vect-slp.c:2441
0xfcde42 vect_analyze_loop_2
../../gcc-trunk/gcc/tree-vect-loop.c:2262
0xfcde42 vect_analyze_loop(loop*, vec_info_shared*)
../../gcc-trunk/gcc/tree-vect-loop.c:2799
0xff679c try_vectorize_loop_1
../../gcc-trunk/gcc/tree-vectorizer.c:994
0xff7269 vectorize_loops()
../../gcc-trunk/gcc/tree-vectorizer.c:1226
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[506] % 
[506] % cat small.c
struct b {
  int c;
  char e;
  char f;
  unsigned g;
};

struct h {
  int i : 2;
};

static short j = 5;
static int k, l, m, ah;
static char n;
static struct b o, p;
int *q;
static int **r = 
char s;
static struct h t;
short u;

unsigned char a (unsigned char v, unsigned char w) {
  return w ? v % w : 0;
}

void ac () {
  ah = 0 >= t.i;
  while (n)
;
}

short d (short v) { return v; }

static int x () {
  int y;
  char aa;
  int *ab = 
  o.f = 0;
  while (!j)
;
  ac();
  while (s) {
char ad;
int ae;
p.e = ad = 7;
for (; ad; ad--) {
  unsigned af = 4;
  ae = 1;
  for (; ae >= 0; ae--) {
aa = a ((p.g == (l >= af) || y), *ab);
**r ^= (d ((m < o.c) ^ aa) == 0) ^ u;
  }
}
*ab = 0;
  }
  return 0;
}

int main () {
  x();
  return 0;
}

[Bug fortran/97039] -fbounds-check misses violation with slice of array but not an element

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic
   Last reconfirmed||2020-10-16
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Reduced testcase:

program test
  implicit none
  integer, parameter :: m=2, n=3
  real, allocatable  :: r(:,:)
  allocate (r(m,n))  
  write(*,*) r(m+1,:)
  write(*,*) r(m+1,1)
end

Looking at the tree dump, there are array bounds checks generated for both
dimensions in the latter write, but there are suspiciously looking checks
for dimension 2 for the first case (r(m+1,:)).

[Bug libstdc++/97465] cross build gcc with vtv enabled failed. Cannot find out headers in glibc why?

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

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

--- Comment #2 from Jonathan Wakely  ---
e.g. what kind of cross build? We're not psychic.

[Bug libstdc++/97465] cross build gcc with vtv enabled failed. Cannot find out headers in glibc why?

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-16

--- Comment #1 from Jonathan Wakely  ---
As https://gcc.gnu.org/bugs/ says, you need to provide the configure options
used (among other info).

[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!

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

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

--- Comment #15 from Mark Wielaard  ---
(In reply to Jakub Jelinek from comment #14)
> In any case, the change to use -gdwarf-* by default even when not compiling
> just assembly was based on the assumption that gas would in that case pretty
> much only change the format of the .debug_line section generated from
> .file/.loc directives, but certainly not append anything on top of that
> itself (e.g. append some stuff to the compiler emitted .debug* sections).

Right, that was certainly the intention. I believe it is simply a bug is gas
where a file is kept that isn't used and put into the file table anyway:
https://sourceware.org/bugzilla/show_bug.cgi?id=26740#c1
There is already a patch to fix it:
https://sourceware.org/pipermail/binutils/2020-October/113741.html
We just have to double check with Nick this is really what his original code
was intended to do.

[Bug libstdc++/97465] New: cross build gcc with vtv enabled failed. Cannot find out headers in glibc why?

[euloanty at live dot com via Gcc-bugs]

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

Bug ID: 97465
   Summary: cross build gcc with vtv enabled failed. Cannot find
out headers in glibc why?
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

./../libstdc++-v3/include/x86_64-cross-linux/bits/os_defines.h:39:10: fatal
error: features.h: No such file or directory
   39 | #include 
  |  ^~~~
compilation terminated.
Makefile:604: recipe for target 'vtv_malloc.lo' failed
make[4]: *** [vtv_malloc.lo] Error 1
mv -f .deps/rwlock.Tpo .deps/rwlock.Plo
libtool: compile:  /home/cqwrteur/gcc_build/./gcc/xgcc
-B/home/cqwrteur/gcc_build/./gcc/ "-DPACKAGE_NAME=\"GNU Vtable Verification
Runtime Library\"" -DPACKAGE_TARNAME=\"libvtv\" -DPACKAGE_VERSION=\"1.0\"
"-DPACKAGE_STRING=\"GNU Vtable Verification Runtime Library 1.0\""
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"http://www.gnu.org/software/libvtv/\;
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -D__EXTENSIONS__=1 -D_ALL_SOURCE=1
-D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D_TANDEM_SOURCE=1
-DPACKAGE=\"libvtv\" -DVERSION=\"1.0\" -DHAVE_SECURE_GETENV=1
-DHAVE___FORTIFY_FAIL=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
-DHAVE__OBSTACK_BEGIN=1 -I. -I../../../gcc/libvtv
-I../../../gcc/libvtv/../include -D_GNU_SOURCE -Wall -Wextra -fno-exceptions
-fcf-protection -mshstk -I./../libstdc++-v3/include
-I./../libstdc++-v3/include/x86_64-cross-linux
-I../../../gcc/libvtv/../libstdc++-v3/libsupc++
-Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -g -O2 -D_GNU_SOURCE -MT
vtv_utils.lo -MD -MP -MF .deps/vtv_utils.Tpo -c
../../../gcc/libvtv/vtv_utils.cc  -fPIC -DPIC -o .libs/vtv_utils.o
mv -f .deps/aatree.Tpo .deps/aatree.Plo
../../../gcc/libvtv/vtv_utils.cc:28:10: fatal error: sys/types.h: No such file
or directory
   28 | #include 
  |  ^
compilation terminated.

[Bug fortran/95979] [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:02629b116eed7c6911ef0eb2ef97e1883e9fb1de

commit r11-4020-g02629b116eed7c6911ef0eb2ef97e1883e9fb1de
Author: Harald Anlauf 
Date:   Fri Oct 16 22:17:46 2020 +0200

PR fortran/95979 - ICE in get_kind, at fortran/simplify.c:129

Simplification of the elemental intrinsic INDEX with constant array-valued
arguments failed with an ICE or did not reduce to a constant array,
depending
also on the presence of the optional KIND argument.  Add a further attempt
of
simplification in the case of elemental intrinsics, and make sure the KIND
argument is not removed prematurely during simplification of INDEX.

gcc/fortran/ChangeLog:

PR fortran/95979
* expr.c (gfc_check_init_expr): Fix check of return code from
gfc_intrinsic_func_interface.
* intrinsic.c (gfc_intrinsic_func_interface): Add further attempt
of simplification of elemental intrinsics with array arguments.
* iresolve.c (gfc_resolve_index_func): Keep optional KIND argument
for simplification of elemental use of INDEX.

gcc/testsuite/ChangeLog:

PR fortran/95979
* gfortran.dg/index_4.f90: New test.

[Bug bootstrap/94761] host != target

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

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

--- Comment #3 from Segher Boessenkool  ---
Commit e69bf64be925 added the host and target flags originally, and it
seems to have been just a mistake that is used --build=${build_alias}
--host=${build_alias}.  (Now of course that has spread to many more
places.)

[Bug other/96927] [11 regression] ICE in libstdc++-v3/include/chrono:442

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from seurer at gcc dot gnu.org ---
I haven't seen these in a while so it does look like whatever was fixed.

[Bug tree-optimization/97462] ICE in op1_range, at range-op.cc:1580 (-Os and above)

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

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

commit r11-4016-g4a135bd987e7bff6d3b94efa085e0c246348b486
Author: Andrew MacLeod 
Date:   Fri Oct 16 15:02:42 2020 -0400

Don't assert on a negative shift.

Don't assert, simply Return false for negative shifts as we can't tell
anything about the operand.

PR tree-optimization/97462
gcc/
* range-op.cc (operator_lshift::op1_range): Don't trap on negative
shifts.
gcc/testsuite/
* gcc.dg/pr97462.c: New file.

[Bug tree-optimization/97456] [10/11 Regression] An incorrect optimization causes a function to always return the same value when using -flto

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

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

Martin Jambor  changed:

   What|Removed |Added

  Component|ipa |tree-optimization

--- Comment #7 from Martin Jambor  ---
Changing component to tree-optimization.

[Bug ipa/97456] [10/11 Regression] An incorrect optimization causes a function to always return the same value when using -flto

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

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

--- Comment #6 from Martin Jambor  ---
I have posted the patch to the mailing list:

https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556399.html

[Bug bootstrap/97451] [11 Regression] r11-3959 failed --with-build-config=bootstrap-cet

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

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

H.J. Lu  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from H.J. Lu  ---
(In reply to H.J. Lu from comment #4)
> Created attachment 49389 [details]
> A patch
> 
> I am testing this patch.

It works:

https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556394.html

[Bug c++/97464] New: Missed redundant store optimization opportunity

[pdimov at gmail dot com via Gcc-bugs]

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

Bug ID: 97464
   Summary: Missed redundant store optimization opportunity
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdimov at gmail dot com
  Target Milestone: ---

The code

void f( int& x, float& y )
{
++x;
y = 1;
--x;
}

compiles to

f(int&, float&):
mov eax, DWORD PTR [rdi]
mov DWORD PTR [rsi], 0x3f80
mov DWORD PTR [rdi], eax
ret

(https://godbolt.org/z/so4h3v)

but the load from, and the store to, [rdi] are redundant. It's obvious that
TBAA is active, but it for some reason doesn't go far enough.

This is a simplified example from "realer" code where x is a reference count
whose unnecessary manipulations could have been optimized out entirely.

[Bug c++/97460] [11 Regression] A boost ICE since r11-3883-g068644a14976ce67

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Fixed ccb4f20cbee 2020-10-16 | c++: Fix nullptr deref [pr97460[

[Bug c++/97460] [11 Regression] A boost ICE since r11-3883-g068644a14976ce67

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

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

commit r11-4015-gccb4f20cbee1756c464033bbdda2f27b6aa2a63f
Author: Nathan Sidwell 
Date:   Fri Oct 16 10:22:16 2020 -0700

c++: Fix nullptr deref [pr97460[

My changes to friend handling meant that there are now cases where a
friend doesn't get a lang-specific object.  So we need to check there
is one before looking inside it.

PR c++/97460
gcc/cp/
* pt.c (push_template_decl): Check DECL_LANG_SPECIFIC in friend
case.
gcc/testsuite/
* g++.dg/template/pr97460.C: New.

[Bug bootstrap/94761] host != target

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
All of the text of the report is missing, apparently?

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #21 from Andrew Macleod  ---
(In reply to rguent...@suse.de from comment #20)

> >
> >Is this your preferred solution?
> 
> The backen should use more lowlevel functions to build this type rather than
> copying from a type that isn't appropriate. Off my head it wants
> fixup_unsigned_type after setting the mode and eventually a different
> function to build the original type. See tree.c where we build for example
> boolean_type_node
> 


If thast the case, then I leave the construction/decision of how to build this
backend type more properly to a PowerPC person that knows what they are doing.

At least it should be straightforward for someone now.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #20 from rguenther at suse dot de  ---
On October 16, 2020 5:46:28 PM GMT+02:00, amacleod at redhat dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
>
>--- Comment #19 from Andrew Macleod  ---
>(In reply to rguent...@suse.de from comment #18)
>> On October 16, 2020 4:17:43 PM GMT+02:00, amacleod at redhat dot com
>> 
>> >
>> >Yeah, I haven't tripped over it in ADA. This was a 512 byte quad on
>the
>> >powerpc
>> >target.. so far the only place I have seen this issue.
>> >
>> >  tree xi_uns_type = make_unsigned_type (512);
>> >  vector_quad_type_node = build_distinct_type_copy
>(xi_uns_type);
>> >  SET_TYPE_MODE (vector_quad_type_node, PXImode);
> ^^
>
>This is why types_compatible_p() fails.  before checking sign and
>precision
>matching, it does:
>
>  inner_type = TYPE_MAIN_VARIANT (inner_type);
>  outer_type = TYPE_MAIN_VARIANT (outer_type);
>
>  if (inner_type == outer_type)
>return true;
>
>/* Changes in machine mode are never useless conversions because the
>RTL
> middle-end expects explicit conversions between modes.  */
>  if (TYPE_MODE (inner_type) != TYPE_MODE (outer_type))
>return false;
>
>and since the modes are now different, it never gets to check the sign
>and
>precision (which do match).
>
>
>
>> >  layout_type (vector_quad_type_node);
>> 
>> Why not put the fix here instead of in build distinct type copy?? 
>> 
>>  lang_hooks.types.register_builtin_type (vector_quad_type_node,
>> >  "__vector_quad")
>> >
>> >The vector_quad ends up with MAX and MIN set to the uint512_t type,
>> >which is
>> >not types_compatible_p...  
>> >Perhaps the type should be created some other way rather than
>> >distinct_type?
>> 
>> Quite sure. 
>
>
>I could fix it right there... but it wont prevent something similar
>from
>happening elsewhere.  Anyone changing the mode of the new distinct type
>will
>continue to allow types_incompatible_p() types for MIN and MAX.
>
>Maybe its not a big deal, but it just seems like a glaring
>inconsistency to me.
>If you ask for  distinct type, you should get one, complete with
>distinct
>elements so you don't need to worry about things like this.
>
>It doesn't seem like powerpc is doing anything wrong, but they are
>getting an
>inconsistent type back due to the way types_compatible_p checks things.
>
>Now, looking further into it, this would appear to be the only 2 places
>in all
>the architectures where build_distinct_type_copy() is called, and then
>the mode
>is changed.   All the other places build a type then set the mode
>rather than
>getting a copy. 
>
>I'd still prefer to fix it at its source, but given the lack of
>prevalence, I
>could just set the MIN MAX properly here where these 2 types are having
>their
>mode changed.   
>
>Is this your preferred solution?

The backen should use more lowlevel functions to build this type rather than
copying from a type that isn't appropriate. Off my head it wants
fixup_unsigned_type after setting the mode and eventually a different function
to build the original type. See tree.c where we build for example
boolean_type_node

>diff --git a/gcc/config/rs6000/rs6000-call.c
>b/gcc/config/rs6000/rs6000-call.c
>index 9fdf97bc803..1fcb438ef95 100644
>--- a/gcc/config/rs6000/rs6000-call.c
>+++ b/gcc/config/rs6000/rs6000-call.c
>@@ -12917,6 +12917,13 @@ rs6000_init_builtins (void)
>   tree oi_uns_type = make_unsigned_type (256);
>   vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
>   SET_TYPE_MODE (vector_pair_type_node, POImode);
>+  // Changing modes makes the types incompatable.
>+  TYPE_MIN_VALUE (vector_pair_type_node)
>+   = wide_int_to_tree (vector_pair_type_node,
>+   wi::to_wide (TYPE_MIN_VALUE
>(oi_uns_type)));
>+  TYPE_MAX_VALUE (vector_pair_type_node)
>+   = wide_int_to_tree (vector_pair_type_node,
>+   wi::to_wide (TYPE_MAX_VALUE
>(oi_uns_type)));
>   layout_type (vector_pair_type_node);
>   lang_hooks.types.register_builtin_type (vector_pair_type_node,
>  "__vector_pair");
>@@ -12924,6 +12931,13 @@ rs6000_init_builtins (void)
>   tree xi_uns_type = make_unsigned_type (512);
>   vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
>   SET_TYPE_MODE (vector_quad_type_node, PXImode);
>+  // Changing modes makes the types incompatable.
>+  TYPE_MIN_VALUE (vector_quad_type_node)
>+   = wide_int_to_tree (vector_quad_type_node,
>+   wi::to_wide (TYPE_MIN_VALUE
>(xi_uns_type)));
>+  TYPE_MAX_VALUE (vector_quad_type_node)
>+   = wide_int_to_tree (vector_quad_type_node,
>+   wi::to_wide (TYPE_MAX_VALUE
>(xi_uns_type)));
>   layout_type (vector_quad_type_node);
>   lang_hooks.types.register_builtin_type 

[Bug c/97463] [11 Regression] ICE in warn_parm_ptrarray_mismatch on an incompatible function redeclaration

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
An almost identical problem was already fixed once in pr97131, but clearly the
fix was incomplete.

[Bug tree-optimization/97462] ICE in op1_range, at range-op.cc:1580 (-Os and above)

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #1 from Andrew Macleod  ---
Created attachment 49390
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49390=edit
return false, not assert on negative shifts

Development assert should be changed to returning "false" indicating we wont
try to look through negative shifts.

patch being tested

[Bug c/96171] [10 Regression] ICE on invalid VLA argument declaration and attribute access

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

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||11.0, 9.3.0
  Known to fail|11.0|
Summary|ICE on invalid VLA argument |[10 Regression] ICE on
   |declaration and attribute   |invalid VLA argument
   |access  |declaration and attribute
   ||access

--- Comment #2 from Martin Sebor  ---
The ICE is gone on trunk, most likely as a result of the fix for pr97189.  GCC
10 still ICEs:

pr96171.c:1:54: error: ‘n’ undeclared here (not in a function)
1 | __attribute__ ((access (read_write, 1))) void f (int[n], int n);
  |  ^
‘
pr96171.c:1: confused by earlier errors, bailing out

[Bug c++/97460] [11 Regression] A boost ICE since r11-3883-g068644a14976ce67

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug bootstrap/97451] [11 Regression] r11-3959 failed --with-build-config=bootstrap-cet

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-10-16
   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com
 Ever confirmed|0   |1

--- Comment #4 from H.J. Lu  ---
Created attachment 49389
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49389=edit
A patch

I am testing this patch.

[Bug c++/96258] [11 Regression] ICE: Segmentation fault (in cp_parser_declaration)

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
resolved a16da48bf19 2020-10-16 | c++: Fix null deref at EOF [PR96258]

[Bug c++/96258] [11 Regression] ICE: Segmentation fault (in cp_parser_declaration)

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

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

commit r11-4014-ga16da48bf19bb139e5461e5b5b7f072d5369b054
Author: Nathan Sidwell 
Date:   Fri Oct 16 09:22:22 2020 -0700

c++: Fix null deref at EOF [PR96258]

cp_parser_declaration peeks at 1 or 2 tokens, when I changed it not to
peek past EOF, I set the second token to NULL.  But there are paths
through the function that just look at the second token.  Fixed by
setting that token to EOF rather than NULL in this case.

PR c++/96258
gcc/cp/
* parser.c (cp_parser_declaration): Make token2 point to EOF if
token1 was EOF.
gcc/testsuite/
* g++.dg/parse/pr96258.C: New.

[Bug c/97463] New: [11 Regression] ICE in warn_parm_ptrarray_mismatch on an incompatible function redeclaration

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

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

Bug ID: 97463
   Summary: [11 Regression] ICE in warn_parm_ptrarray_mismatch on
an incompatible function redeclaration
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following invalid program triggers an ICE in the recently added 
warn_parm_ptrarray_mismatch function.

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout z.c
void f (void**);
void f (int n) {  }
z.c:2:1: internal compiler error: Segmentation fault
2 | void f (int n) {  }
  | ^~~~
0x131e972 crash_signal
/src/gcc/master/gcc/toplev.c:330
0xaea1f4 warn_parm_ptrarray_mismatch
/src/gcc/master/gcc/c-family/c-warn.c:3182
0xaeae8b warn_parm_array_mismatch(unsigned int, tree_node*, tree_node*)
/src/gcc/master/gcc/c-family/c-warn.c:3351
0x969c70 start_function(c_declspecs*, c_declarator*, tree_node*)
/src/gcc/master/gcc/c/c-decl.c:9560
0x9d2682 c_parser_declaration_or_fndef
/src/gcc/master/gcc/c/c-parser.c:2444
0x9d0e02 c_parser_external_declaration
/src/gcc/master/gcc/c/c-parser.c:1777
0x9d0923 c_parser_translation_unit
/src/gcc/master/gcc/c/c-parser.c:1650
0xa0ee9c c_parse_file()
/src/gcc/master/gcc/c/c-parser.c:21821
0xaa27cd c_common_parse_file()
/src/gcc/master/gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/97463] [11 Regression] ICE in warn_parm_ptrarray_mismatch on an incompatible function redeclaration

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

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |11.0
   Keywords||ice-on-invalid-code
   Last reconfirmed||2020-10-16

[Bug tree-optimization/97462] New: ICE in op1_range, at range-op.cc:1580 (-Os and above)

[su at cs dot ucdavis.edu via Gcc-bugs]

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

Bug ID: 97462
   Summary: ICE in op1_range, at range-op.cc:1580 (-Os and above)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

[554] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201016 (experimental) [master revision
37753588116:be453072dd2:6c6e0cafa38cee8309f37b846cb7db813a472a54] (GCC) 
[555] % 
[555] % gcctk -O1 -c -w small.c
[556] % gcctk -Os -c -w small.c
during GIMPLE pass: evrp
small.c: In function ‘d’:
small.c:7:1: internal compiler error: in op1_range, at range-op.cc:1580
7 | }
  | ^
0x7d0131 operator_lshift::op1_range(irange&, tree_node*, irange const&, irange
const&) const
../../gcc-trunk/gcc/range-op.cc:1580
0x1867d23 gori_compute::compute_name_range_op(irange&, gimple*, irange const&,
tree_node*)
../../gcc-trunk/gcc/gimple-range-gori.cc:494
0x186b139 gori_compute::compute_operand_range(irange&, gimple*, irange const&,
tree_node*)
../../gcc-trunk/gcc/gimple-range-gori.cc:575
0x186b139 gori_compute_cache::compute_operand_range(irange&, gimple*, irange
const&, tree_node*)
../../gcc-trunk/gcc/gimple-range-gori.cc:1271
0x1868729 gori_compute::compute_operand1_range(irange&, gimple*, irange const&,
tree_node*)
../../gcc-trunk/gcc/gimple-range-gori.cc:903
0x186b139 gori_compute::compute_operand_range(irange&, gimple*, irange const&,
tree_node*)
../../gcc-trunk/gcc/gimple-range-gori.cc:575
0x186b139 gori_compute_cache::compute_operand_range(irange&, gimple*, irange
const&, tree_node*)
../../gcc-trunk/gcc/gimple-range-gori.cc:1271
0x186a1cf gori_compute::outgoing_edge_range_p(irange&, edge_def*, tree_node*)
../../gcc-trunk/gcc/gimple-range-gori.cc:1002
0x186632e ranger_cache::iterative_cache_update(tree_node*)
../../gcc-trunk/gcc/gimple-range-cache.cc:636
0x186681a ranger_cache::fill_block_cache(tree_node*, basic_block_def*,
basic_block_def*)
../../gcc-trunk/gcc/gimple-range-cache.cc:808
0x1866fbd ranger_cache::block_range(irange&, basic_block_def*, tree_node*,
bool)
../../gcc-trunk/gcc/gimple-range-cache.cc:589
0x185fe61 gimple_ranger::range_on_entry(irange&, basic_block_def*, tree_node*)
../../gcc-trunk/gcc/gimple-range.cc:909
0x1860577 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
../../gcc-trunk/gcc/gimple-range.cc:880
0x108b86d range_query::value_of_expr(tree_node*, gimple*)
../../gcc-trunk/gcc/value-query.cc:85
0x17148b1 hybrid_folder::value_of_expr(tree_node*, gimple*)
../../gcc-trunk/gcc/gimple-ssa-evrp.c:235
0xf456d3 substitute_and_fold_engine::replace_uses_in(gimple*)
../../gcc-trunk/gcc/tree-ssa-propagate.c:871
0xf459ec substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../gcc-trunk/gcc/tree-ssa-propagate.c:1141
0x16ec3b7 dom_walker::walk(basic_block_def*)
../../gcc-trunk/gcc/domwalk.c:309
0xf44e65 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
../../gcc-trunk/gcc/tree-ssa-propagate.c:1283
0x1714526 execute_early_vrp
../../gcc-trunk/gcc/gimple-ssa-evrp.c:340
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[557] % 
[557] % cat small.c
int a, b;

void d ()
{
  a << ~0 && b;
  b = a;
}

[Bug c++/83417] Pointer-to-member template parameter with auto member type dependent container type does not work (C++17)

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-10-16
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Confirmed.

[Bug rtl-optimization/97459] __uint128_t remainder for division by 3

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

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

--- Comment #3 from Jakub Jelinek  ---
Or:
unsigned r3_128u_v4 (__uint128_t n)
{
  unsigned long a;
  a = (n >> 96);
  a += (n >> 64) & 0xULL;
  a += (n >> 32) & 0xULL;
  a += (n & 0xULL);
  return a % 3;
}
if the target doesn't have (efficient) multi-word shifts.

[Bug ipa/97456] [10/11 Regression] An incorrect optimization causes a function to always return the same value when using -flto

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

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

--- Comment #5 from Martin Jambor  ---
And indeed the following avoids the issue:

diff --git a/gcc/tree-complex.c b/gcc/tree-complex.c
index 2e54bbb917c..71ad7c18523 100644
--- a/gcc/tree-complex.c
+++ b/gcc/tree-complex.c
@@ -570,8 +570,10 @@ set_component_ssa_name (tree ssa_name, bool imag_p, tree
value)
   /* Replace an anonymous base value with the variable from cvc_lookup.
 This should result in better debug info.  */
   if (SSA_NAME_VAR (ssa_name)
- && (!SSA_NAME_VAR (value) || DECL_IGNORED_P (SSA_NAME_VAR (value)))
- && !DECL_IGNORED_P (SSA_NAME_VAR (ssa_name)))
+ && !DECL_IGNORED_P (SSA_NAME_VAR (ssa_name))
+ && (!SSA_NAME_VAR (value)
+ || (DECL_IGNORED_P (SSA_NAME_VAR (value))
+ && !SSA_NAME_IS_DEFAULT_DEF (value
{
  comp = get_component_var (SSA_NAME_VAR (ssa_name), imag_p);
  replace_ssa_name_symbol (value, comp);

[Bug rtl-optimization/97459] __uint128_t remainder for division by 3

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

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

--- Comment #2 from Jakub Jelinek  ---
E.g.
unsigned r3_128u_v3 (__uint128_t n)
{
  unsigned long a;
  a = (n >> 88);
  a += (n >> 44) & 0xfffULL;
  a += (n & 0xfffULL);
  return a % 3;
}
could work, but haven't measured how fast it is on average against the libcall.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #19 from Andrew Macleod  ---
(In reply to rguent...@suse.de from comment #18)
> On October 16, 2020 4:17:43 PM GMT+02:00, amacleod at redhat dot com
> 
> >
> >Yeah, I haven't tripped over it in ADA. This was a 512 byte quad on the
> >powerpc
> >target.. so far the only place I have seen this issue.
> >
> >  tree xi_uns_type = make_unsigned_type (512);
> >  vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
> >  SET_TYPE_MODE (vector_quad_type_node, PXImode);
 ^^

This is why types_compatible_p() fails.  before checking sign and precision
matching, it does:

  inner_type = TYPE_MAIN_VARIANT (inner_type);
  outer_type = TYPE_MAIN_VARIANT (outer_type);

  if (inner_type == outer_type)
return true;

  /* Changes in machine mode are never useless conversions because the RTL
 middle-end expects explicit conversions between modes.  */
  if (TYPE_MODE (inner_type) != TYPE_MODE (outer_type))
return false;

and since the modes are now different, it never gets to check the sign and
precision (which do match).



> >  layout_type (vector_quad_type_node);
> 
> Why not put the fix here instead of in build distinct type copy?? 
> 
>  lang_hooks.types.register_builtin_type (vector_quad_type_node,
> >  "__vector_quad")
> >
> >The vector_quad ends up with MAX and MIN set to the uint512_t type,
> >which is
> >not types_compatible_p...  
> >Perhaps the type should be created some other way rather than
> >distinct_type?
> 
> Quite sure. 


I could fix it right there... but it wont prevent something similar from
happening elsewhere.  Anyone changing the mode of the new distinct type will
continue to allow types_incompatible_p() types for MIN and MAX.

Maybe its not a big deal, but it just seems like a glaring inconsistency to me.
If you ask for  distinct type, you should get one, complete with distinct
elements so you don't need to worry about things like this.

It doesn't seem like powerpc is doing anything wrong, but they are getting an
inconsistent type back due to the way types_compatible_p checks things.

Now, looking further into it, this would appear to be the only 2 places in all
the architectures where build_distinct_type_copy() is called, and then the mode
is changed.   All the other places build a type then set the mode rather than
getting a copy. 

I'd still prefer to fix it at its source, but given the lack of prevalence, I
could just set the MIN MAX properly here where these 2 types are having their
mode changed.   

Is this your preferred solution?

diff --git a/gcc/config/rs6000/rs6000-call.c b/gcc/config/rs6000/rs6000-call.c
index 9fdf97bc803..1fcb438ef95 100644
--- a/gcc/config/rs6000/rs6000-call.c
+++ b/gcc/config/rs6000/rs6000-call.c
@@ -12917,6 +12917,13 @@ rs6000_init_builtins (void)
   tree oi_uns_type = make_unsigned_type (256);
   vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
   SET_TYPE_MODE (vector_pair_type_node, POImode);
+  // Changing modes makes the types incompatable.
+  TYPE_MIN_VALUE (vector_pair_type_node)
+   = wide_int_to_tree (vector_pair_type_node,
+   wi::to_wide (TYPE_MIN_VALUE (oi_uns_type)));
+  TYPE_MAX_VALUE (vector_pair_type_node)
+   = wide_int_to_tree (vector_pair_type_node,
+   wi::to_wide (TYPE_MAX_VALUE (oi_uns_type)));
   layout_type (vector_pair_type_node);
   lang_hooks.types.register_builtin_type (vector_pair_type_node,
  "__vector_pair");
@@ -12924,6 +12931,13 @@ rs6000_init_builtins (void)
   tree xi_uns_type = make_unsigned_type (512);
   vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
   SET_TYPE_MODE (vector_quad_type_node, PXImode);
+  // Changing modes makes the types incompatable.
+  TYPE_MIN_VALUE (vector_quad_type_node)
+   = wide_int_to_tree (vector_quad_type_node,
+   wi::to_wide (TYPE_MIN_VALUE (xi_uns_type)));
+  TYPE_MAX_VALUE (vector_quad_type_node)
+   = wide_int_to_tree (vector_quad_type_node,
+   wi::to_wide (TYPE_MAX_VALUE (xi_uns_type)));
   layout_type (vector_quad_type_node);
   lang_hooks.types.register_builtin_type (vector_quad_type_node,
  "__vector_quad");

.


> 
> >
> >Im starting to wonder if I should stop trying to assert type
> >correctness when
> >processing ranges since our type "system" has too many tweaky
> >inconsistencies
> >that we continue to trip over.  
> >
> >Instead, just make sure precision and sign are the same and "trust"
> >gimple to
> >be right otherwise.
> 
> If precision and sign are the same then types_compatible_p will return true.

except in cases like this :-P

[Bug c++/97460] [11 Regression] A boost ICE since r11-3883-g068644a14976ce67

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #1 from Martin Liška  ---
Reduced test-case:

$ cat manager.ii
class io_context {
  template  class basic_executor_type;
};
template  class io_context::basic_executor_type {
  template  friend class basic_executor_type;
};

[Bug target/97457] [10/11 Regression] SVE: wrong code since r10-4752-g2d56600c

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

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

--- Comment #2 from Alex Coplan  ---
For the similar testcase:

long a;
short b;
signed char c(char d, char e) { return d + e; }
int main(void) {
  a = -30;
  for (; a < 24; a = c(a, 5)) {
short *f = 
(*f)--;
  }
  if (b != -11)
__builtin_abort();
}

we fail to assemble it after r10-4752. This is fixed by
r10-5304-g30f8bf3d6c072a8fce14e8a003dff485a9068a97, but we have wrong code
thereafter.

[Bug rtl-optimization/97459] __uint128_t remainder for division by 3

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I don't think the two are equivalent, consider e.g.
(((__uint128_t)0xffdfULL)<<64)+0xffdfULL
on this, the first function returns 1, the second 2.
I believe Hacker's delign says that
n % 3 == (((n >> 64) + (n & 0x)) % 3),
but the addition there isn't a 64-bit number, but a 65-bit number, so either
we'd need to take into account also the carry from the addition, or we'd need
to do the addition still in 128-bits and do it once again afterwards e.g. (n >>
32) + (n & 0x), which then could be done in 64-bits already.

[Bug c++/97419] crash in decl_as_string(TFF_DECL_SPECIFIERS | TFF_CHASE_TYPEDEF) from plugin using std::declval()

[sphink at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Steve Fink  ---
I can workaround the bug by avoiding declval:

-   using Iter = decltype(std::declval().begin());
-   using Elem = decltype(*std::declval());
+   using Iter = decltype(static_cast(nullptr)->begin());
+   using Elem = decltype(*static_cast(nullptr)->begin());

fixes it in my original code. In the minimized testcase, it would be the more
pedestrian

-   using Iter = typename Container::ValueType*;
-   using Elem = decltype(*std::declval());
+   using Iter = typename Container::ValueType*;
+   using Elem = typename Container::ValueType;

[Bug gcov-profile/97461] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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

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

--- Comment #3 from Sergei Trofimovich  ---
Probably started from
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=871e5ada6d53d5eb ("Make TOPN
counter dynamically allocated.") when dynamic memory allocation call was added
to gcov_topn_add_value().

[Bug gcov-profile/97461] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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

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

--- Comment #2 from Sergei Trofimovich  ---
Original firefox lockup is slightly more complicated: malloc() call happens in
a constructor of external library (at _gpg_err_init()).

(gdb) bt
#0  __lll_lock_wait (futex=0x5591defd9720 , private=0) at
lowlevellock.c:52
#1  0x7f6e72d23305 in __GI___pthread_mutex_lock (mutex=0x5591defd9720
) at ../nptl/pthread_mutex_lock.c:135
#2  0x5591deeb60a1 in malloc_init_hard() ()
#3  0x5591deebf75e in calloc ()
#4  0x5591defa70df in allocate_gcov_kvp () at
/var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/libgcov.h:441
#5  gcov_topn_add_value (count=1, use_atomic=1, increment_total=1, value=4096,
counters=0x5591df011520 <__gcov3._ZL16malloc_init_hardv>)
at
/var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/libgcov.h:489
#6  __gcov_topn_values_profiler_body (use_atomic=1, value=4096,
counters=0x5591df011520 <__gcov3._ZL16malloc_init_hardv>)
at
/var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/libgcov-profiler.c:103
#7  __gcov_topn_values_profiler_atomic (counters=0x5591df011520
<__gcov3._ZL16malloc_init_hardv>, value=4096)
at
/var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/libgcov-profiler.c:128
#8  0x5591deeb6121 in malloc_init_hard() ()
#9  0x5591deec052e in malloc ()
#10 0x7f6e5c5ecddf in set_binding_values (domainname=0x7f6e58451245
"libgpg-error", dirnamep=0x7fffd54f39c8, codesetp=0x0) at bindtextdom.c:202
#11 0x7f6e5c5ed071 in set_binding_values (codesetp=0x0,
dirnamep=0x7fffd54f39c8, domainname=) at bindtextdom.c:82
#12 __bindtextdomain (domainname=, dirname=) at
bindtextdom.c:320
#13 0x7f6e5843cbc7 in _gpg_err_init () at /usr/lib64/libgpg-error.so.0
#14 0x7f6e72d94cfe in call_init (l=, argc=argc@entry=3,
argv=argv@entry=0x7fffd54f3a68, env=env@entry=0x7fffd54f3a88) at dl-init.c:74
#15 0x7f6e72d94de0 in call_init (env=0x7fffd54f3a88, argv=0x7fffd54f3a68,
argc=3, l=) at dl-init.c:37
#16 _dl_init (main_map=0x7f6e72db11a0, argc=3, argv=0x7fffd54f3a68,
env=0x7fffd54f3a88) at dl-init.c:121
#17 0x7f6e72d8608a in _dl_start_user () at /lib64/ld-linux-x86-64.so.2
#18 0x0003 in  ()
#19 0x7fffd54f4a83 in  ()
#20 0x7fffd54f4a9c in  ()
#21 0x7fffd54f4b15 in  ()
#22 0x in  ()

[Bug gcov-profile/97461] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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

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

--- Comment #1 from Sergei Trofimovich  ---
Created attachment 49388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49388=edit
a.c

[Bug gcov-profile/97461] New: allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

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

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

Bug ID: 97461
   Summary: allocate_gcov_kvp() deadlocks in firefox LTO+PGO build
(overridden malloc() recursion)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Single-file example is extracted from firefox-81 build hangup (LTO+PGO
flavour).

Here is the single-file reproducer that converts hangup to a crash:

// gcc-11.0.0 a.c -o a -fprofile-generate -ggdb3 && ./a

#include 
#include 
#include 

static int malloc_depth = 0;

static char memory[128* 1024];
static size_t memory_p = 0;

void f1(void) {}
void f2(void) {}

typedef void (*fun_t)(void);
static const fun_t funs[2] = { f1, f2, };

static void * malloc_impl(size_t size) {
void * r = [memory_p];
memory_p += size;

// force TOPN profile
funs[size % 2]();
return r;
}

// Override default malloc, check it it get s called recursively
void * malloc(size_t size) {
// Must not be called recursively. Malloc implementation does not support
it.
if (malloc_depth != 0) __builtin_trap();

++malloc_depth;
  void * r = malloc_impl(size);
--malloc_depth;
return r;
}

// Called from gcov
void *calloc(size_t nmemb, size_t size) {
// Must not be called recursively.  Malloc implementation does not support
it.
if (malloc_depth != 0) __builtin_trap();

++malloc_depth;
  void * r = malloc_impl(size * nmemb);
  memset(r, 0, size * nmemb);
--malloc_depth;
return r;
}

void free(void *ptr){}

int main() {
void * p = malloc(8);
return p != 0;
}

How to crash:

$ gcc-11.0.0 a.c -o a -ggdb3 && ./a
$ gcc-11.0.0 a.c -o a -fprofile-generate -ggdb3 && ./a
Illegal instruction (core dumped)

Here we have a malloc recursion of
malloc()->malloc_internals()->gcov->calloc()->malloc_internals().

malloc() is re-entered twice:

Program received signal SIGILL, Illegal instruction.
0x65e7 in calloc (nmemb=1, size=24) at a.c:103
103 if (malloc_depth != 0) __builtin_trap();
(gdb) bt
#0  0x65e7 in calloc (nmemb=1, size=24) at a.c:103
#1  0x6cf3 in allocate_gcov_kvp () at
/var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/libgcov.h:441
#2  gcov_topn_add_value (count=1, increment_total=1, use_atomic=0,
value=721827547, counters=0x5557b660 <__gcov4.malloc_impl>) at
/var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/libgcov.h:489
#3  __gcov_topn_values_profiler_body (use_atomic=0, value=721827547,
counters=0x5557b660 <__gcov4.malloc_impl>) at
/var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/libgcov-profiler.c:103
#4  __gcov_indirect_call_profiler_body (use_atomic=0, cur_func=,
value=721827547) at
/var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/libgcov-profiler.c:163
#5  __gcov_indirect_call_profiler_v4 (value=721827547, cur_func=) at
/var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/libgcov-profiler.c:172
#6  0x631e in f1 () at a.c:74
#7  0x6482 in malloc_impl (size=8) at a.c:85
#8  0x6537 in malloc (size=8) at a.c:95
#9  0x6760 in main () at a.c:115

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #18 from rguenther at suse dot de  ---
On October 16, 2020 4:17:43 PM GMT+02:00, amacleod at redhat dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
>
>--- Comment #17 from Andrew Macleod  ---
>(In reply to rguent...@suse.de from comment #16)
>> On Fri, 16 Oct 2020, amacleod at redhat dot com wrote:
>> 
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
>> > 
>> > --- Comment #15 from Andrew Macleod 
>---
>> > Well it seems far more incorrect that types_compatible_p () is
>FALSE for a type
>> > and its MIN/MAX value?
>> 
>> But then this (types_compatible_p () is FALSE) is not going to be
>fixed
>> by the patch - or at least the type that was copied retains the
>issue.
>> So it's certainly the wrong place to fix.
>
>Why doesn't it?  it creates new min and maxs based from the old
>wide_ints, only
>with the new type. So it'll be the correct mina dn max, with the corect
>type
>set? It now passes the types_compatible_p() test in the testcase..
>because
>they are the same type instead of the old type.  
>
>Its not an interaction between the old type and the new that is at
>issue, its
>interaction between the new type and its MIN/MAX values when we are
>type
>checking something created from the MIN/MAX.
>
>
>> 
>> Note that for integer subtypes generated by Ada the min/max values
>> are in the "parent" type.  Usually the types are compatible though
>> (same precision and signedness).
>
>Yeah, I haven't tripped over it in ADA. This was a 512 byte quad on the
>powerpc
>target.. so far the only place I have seen this issue.
>
>  tree xi_uns_type = make_unsigned_type (512);
>  vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
>  SET_TYPE_MODE (vector_quad_type_node, PXImode);
>  layout_type (vector_quad_type_node);

Why not put the fix here instead of in build distinct type copy?? 

 lang_hooks.types.register_builtin_type (vector_quad_type_node,
>  "__vector_quad")
>
>The vector_quad ends up with MAX and MIN set to the uint512_t type,
>which is
>not types_compatible_p...  
>Perhaps the type should be created some other way rather than
>distinct_type?

Quite sure. 

>
>Im starting to wonder if I should stop trying to assert type
>correctness when
>processing ranges since our type "system" has too many tweaky
>inconsistencies
>that we continue to trip over.  
>
>Instead, just make sure precision and sign are the same and "trust"
>gimple to
>be right otherwise.

If precision and sign are the same then types_compatible_p will return true.

[Bug ipa/97456] [10/11 Regression] An incorrect optimization causes a function to always return the same value when using -flto

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

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

--- Comment #4 from Martin Jambor  ---
Looking at Martin's reduced testcase

(In reply to Richard Biener from comment #2)
> Confirmed with -fwhole-program -O3  IPA SRA messes things up here cloning
> wrong
> and producing the strange
> 
> wrong.isra (floatD.41 ISRA.85D.75004)
> {
[...]
> 
>[local count: 1073741824]:
> 
>[local count: 1073741824]:
>   _1 = ISRA.85_10(D);
> 
> eventually mixing up param/replacement here?

...this is simple conversion of a parameter passed by reference to one
passed by value.  I'm good at overlooking things but at least at the
moment I cannot see anything wrong with it.

Rather, I believe it is cplxlower1 which turns

   [local count: 1073741824]:
  a$_M_value_21 = COMPLEX_EXPR ;

into:

   [local count: 1073741824]:
  a$_M_value_21 = COMPLEX_EXPR ;

i.e. it replaces two uses of the parameter default-def with two
uninitialized value variable default-defs.

When I disable IPA-SRA, the pass starts with:

   [local count: 1073741824]:
  _1 = *pos_6(D);
  a$_M_value_21 = COMPLEX_EXPR <_1, _1>;

and changes it into:

   [local count: 1073741824]:
  a$_M_value$real_1 = *pos_6(D);
  a$_M_value_21 = COMPLEX_EXPR ;

...so my hypothesis is that cplxlower does not handle good
default-defs properly.

[Bug rtl-optimization/97129] [11 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2405

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #3 from Uroš Bizjak  ---
'naked'
 This attribute allows the compiler to construct the requisite
 function declaration, while allowing the body of the function to be
 assembly code.  The specified function will not have
 prologue/epilogue sequences generated by the compiler.  Only basic
 'asm' statements can safely be included in naked functions (*note
 Basic Asm::).  While using extended 'asm' or a mixture of basic
 'asm' and C code may appear to work, they cannot be depended upon
 to work reliably and are not supported.

[Bug c++/96258] [11 Regression] ICE: Segmentation fault (in cp_parser_declaration)

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug c++/96258] [11 Regression] ICE: Segmentation fault (in cp_parser_declaration)

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
@Nathan: Can you please take a look?

[Bug rtl-optimization/97129] [11 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2405

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Started with r8-2294-g2ec580be156c39a8 where naked attribute was added for x86.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #17 from Andrew Macleod  ---
(In reply to rguent...@suse.de from comment #16)
> On Fri, 16 Oct 2020, amacleod at redhat dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
> > 
> > --- Comment #15 from Andrew Macleod  ---
> > Well it seems far more incorrect that types_compatible_p () is FALSE for a 
> > type
> > and its MIN/MAX value?
> 
> But then this (types_compatible_p () is FALSE) is not going to be fixed
> by the patch - or at least the type that was copied retains the issue.
> So it's certainly the wrong place to fix.

Why doesn't it?  it creates new min and maxs based from the old wide_ints, only
with the new type. So it'll be the correct mina dn max, with the corect type
set? It now passes the types_compatible_p() test in the testcase.. because
they are the same type instead of the old type.  

Its not an interaction between the old type and the new that is at issue, its
interaction between the new type and its MIN/MAX values when we are type
checking something created from the MIN/MAX.


> 
> Note that for integer subtypes generated by Ada the min/max values
> are in the "parent" type.  Usually the types are compatible though
> (same precision and signedness).

Yeah, I haven't tripped over it in ADA. This was a 512 byte quad on the powerpc
target.. so far the only place I have seen this issue.

  tree xi_uns_type = make_unsigned_type (512);
  vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
  SET_TYPE_MODE (vector_quad_type_node, PXImode);
  layout_type (vector_quad_type_node);
  lang_hooks.types.register_builtin_type (vector_quad_type_node,
  "__vector_quad")

The vector_quad ends up with MAX and MIN set to the uint512_t type, which is
not types_compatible_p...  
Perhaps the type should be created some other way rather than distinct_type?


Im starting to wonder if I should stop trying to assert type correctness when
processing ranges since our type "system" has too many tweaky inconsistencies
that we continue to trip over.  

Instead, just make sure precision and sign are the same and "trust" gimple to
be right otherwise.

[Bug c++/97460] New: [11 Regression] A boost ICE since r11-3883-g068644a14976ce67

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

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

Bug ID: 97460
   Summary: [11 Regression] A boost ICE since
r11-3883-g068644a14976ce67
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49387=edit
Unreduced test-case

The following fails:

$ g++ manager.ii -c
...
0x10167cf crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:330
0x7788e6bf ???
   
/usr/src/debug/glibc-2.32-1.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xa6a292 push_template_decl(tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:5880
0x9ce6d2 maybe_process_template_type_declaration
/home/marxin/Programming/gcc/gcc/cp/name-lookup.c:6845
0x9ce6d2 do_pushtag
/home/marxin/Programming/gcc/gcc/cp/name-lookup.c:6971
0x9ce6d2 pushtag(tree_node*, tree_node*, TAG_how)
/home/marxin/Programming/gcc/gcc/cp/name-lookup.c:7062
0x947e20 xref_tag(tag_types, tree_node*, TAG_how, bool)
/home/marxin/Programming/gcc/gcc/cp/decl.c:15071
0xa06bc1 cp_parser_elaborated_type_specifier
/home/marxin/Programming/gcc/gcc/cp/parser.c:19147
0x9ee185 cp_parser_type_specifier
/home/marxin/Programming/gcc/gcc/cp/parser.c:17901
0x9ef1ae cp_parser_decl_specifier_seq
/home/marxin/Programming/gcc/gcc/cp/parser.c:14500
0xa16dd5 cp_parser_single_declaration
/home/marxin/Programming/gcc/gcc/cp/parser.c:29580
0xa17146 cp_parser_template_declaration_after_parameters
/home/marxin/Programming/gcc/gcc/cp/parser.c:29244
0xa178f0 cp_parser_explicit_template_declaration
/home/marxin/Programming/gcc/gcc/cp/parser.c:29509
0x9ebf98 cp_parser_member_specification_opt
/home/marxin/Programming/gcc/gcc/cp/parser.c:24972
0x9ebf98 cp_parser_class_specifier_1
/home/marxin/Programming/gcc/gcc/cp/parser.c:24065
0x9ee243 cp_parser_class_specifier
/home/marxin/Programming/gcc/gcc/cp/parser.c:24372
0x9ee243 cp_parser_type_specifier
/home/marxin/Programming/gcc/gcc/cp/parser.c:17875
0x9ef1ae cp_parser_decl_specifier_seq
/home/marxin/Programming/gcc/gcc/cp/parser.c:14500
0xa16dd5 cp_parser_single_declaration
/home/marxin/Programming/gcc/gcc/cp/parser.c:29580
0xa17146 cp_parser_template_declaration_after_parameters
/home/marxin/Programming/gcc/gcc/cp/parser.c:29244
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I'm reducing the test-case right now.

[Bug c++/97460] [11 Regression] A boost ICE since r11-3883-g068644a14976ce67

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Last reconfirmed||2020-10-16
 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
   Keywords||needs-reduction
 Ever confirmed|0   |1
  Known to work||10.2.0
  Known to fail||11.0

[Bug c++/97453] Implement CWG issue 2303

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Blocks||94404
   Last reconfirmed||2020-10-16

--- Comment #1 from Marek Polacek  ---
Confirmed.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
[Bug 94404] [meta-bug] C++ core issues

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #16 from rguenther at suse dot de  ---
On Fri, 16 Oct 2020, amacleod at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
> 
> --- Comment #15 from Andrew Macleod  ---
> Well it seems far more incorrect that types_compatible_p () is FALSE for a 
> type
> and its MIN/MAX value?

But then this (types_compatible_p () is FALSE) is not going to be fixed
by the patch - or at least the type that was copied retains the issue.
So it's certainly the wrong place to fix.

Note that for integer subtypes generated by Ada the min/max values
are in the "parent" type.  Usually the types are compatible though
(same precision and signedness).

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #15 from Andrew Macleod  ---
Well it seems far more incorrect that types_compatible_p () is FALSE for a type
and its MIN/MAX value?

Whats the point of MIN/MAX if you cant count on them being the right types, or
at least conmpatible.  

And why can we not make that expectation? it seems more natural and wouldn't
require a special comment buried back in a build_* routine indicating that
something non-obvious may now be true.

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

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

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

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

https://gcc.gnu.org/g:90042c43a92c452a5f9f3afbfcdad511ea09a54f

commit r11-4006-g90042c43a92c452a5f9f3afbfcdad511ea09a54f
Author: Srinath Parvathaneni 
Date:   Fri Oct 16 14:53:28 2020 +0100

arm: Fix the warning -mcpu=cortex-m55 conflicting with
-march=armv8.1-m.main (pr97327).

This patch fixes (PR97327) the warning -mcpu=cortex-m55 conflicts with
-march=armv8.1-m.main
for -mfloat-abi=soft by adding the isa_bit_mve_float to clearing FP bit
list.

The following combination are fixed with this patch:
$ cat bug.c
int main(){
return 0;
}

$ arm-none-eabi-gcc -mcpu=cortex-m55 -mfloat-abi=soft bug.c -c
$ arm-none-eabi-gcc -mcpu=cortex-m55 -mfloat-abi=soft
-march=armv8.1-m.main+mve bug.c -c

Before this patch for above combinations:
cc1: warning: switch '-mcpu=cortex-m55' conflicts with
'-march=armv8.1-m.main' switch

After this patch for above combinations no warning/errors.

gcc/ChangeLog:

2020-10-16  Srinath Parvathaneni  

PR target/97327
* config/arm/arm.c (fp_bitlist): Add isa_bit_mve_float to FP bits
array.

gcc/testsuite/ChangeLog:

PR target/97327
* gcc.target/arm/mve/intrinsics/pr97327.c: New test.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

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

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

--- Comment #14 from Richard Biener  ---
But that's just a waste of memory ... the expectation that the min/max values
are of the same type is simply wrong.

[Bug sanitizer/97414] AddressSanitizer CHECK failed: detect_stack_use_after_return and detect_invalid_pointer_pairs

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

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

Martin Liška  changed:

   What|Removed |Added

URL||https://reviews.llvm.org/D8
   ||9552

--- Comment #3 from Martin Liška  ---
I've just an upstream fix:
https://reviews.llvm.org/D89552

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #13 from Andrew Macleod  ---
Created attachment 49386
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49386=edit
Patch to create integral MAX and MiN

Joy.  I'll try it and see what happens. 

And back to the first problem where the MIN and MAXs are not the right type.  I
found this nugget in tree.c::build_distinct_type_copy ()

  /* Note that it is now possible for TYPE_MIN_VALUE to be a value
 whose TREE_TYPE is not t.  This can also happen in the Ada
 frontend when using subtypes.  */

What? That seems ridiculous, especially for types that are now distinct.  

Why on earth don't we create new MIN and MAX values for the type?

I'm trying the attached patch which at least corrects it for integral types..
and does resolve the compilation failure.

Is this the correct way to resolve this, or am I missing something else? 


+  if (INTEGRAL_TYPE_P (type))
+{
+  TYPE_MIN_VALUE (t)= wide_int_to_tree (t, wi::to_wide (TYPE_MIN_VALUE
(type)));
+  TYPE_MAX_VALUE (t)= wide_int_to_tree (t, wi::to_wide (TYPE_MAX_VALUE
(type)));
+}
+

[Bug rtl-optimization/97459] New: __uint128_t remainder for division by 3

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

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

Bug ID: 97459
   Summary: __uint128_t remainder for division by 3
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

The following two functions are equivalent:

unsigned r3_128u_v1 (__uint128_t n)
{
  unsigned long a;
  a = (n >> 64) + (n & 0x);
  return a % 3;
}

unsigned r3_128u_v2 (__uint128_t n)
{
  return (unsigned) (n%3);
}

and the first one is definitely faster.

(The approach is due to Hacker's Delight, 2nd edition, "Remainder by
Summing Digits". There are also other interesting approaches there.)

[Bug tree-optimization/97428] -O3 is great for basic AoSoA packing of complex arrays, but horrible one step above the basic

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

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

--- Comment #10 from Richard Biener  ---
(In reply to Michael_S from comment #9)
> Hopefully, you did regression tests for all main AoS<->SoA cases.

We only test what we have in the testsuite ;)

> I.e.
> 
> typedef struct { double re, im; } dcmlx_t;
> void soa2aos(double* restrict dstRe, double* restrict dstIm, const dcmlx_t
> src[], int nq)
> {
>   for (int i = 0; i < nq*4; ++i) {
> dcmlx_t s = src[i];
> dstRe[i] = s.re;
> dstIm[i] = s.im;
>   }
> }
> 
> void aos2soa(dcmlx_t* restrict dst, const double* srcRe, const double*
> srcIm, int nq)
> {
>   for (int i = 0; i < nq*4; ++i) {
> dst[i].re = srcRe[i];
> dst[i].im = srcIm[i];
>   }
> }
> 
> And equivalents with float instead of double.
> 
> Right now 'gcc.10.2 -march=skylake -O3' does very good job for soa2aos() and
> suboptimal, but not horrible job for aos2soa(). Hopefully, your changes do
> not break any of it.

None of the above should be affected since neither involves SLP

> Personally, I don't like SoA layouts and very much prefer AoSoA, but I
> recognize that in existing code bases SoA is more common.

[Bug target/96914] missing MVE intrinsics

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-10 branch has been updated by SRINATH PARVATHANENI
:

https://gcc.gnu.org/g:7591fc054f40c96fabe05d74d61d1c144798354b

commit r10-8907-g7591fc054f40c96fabe05d74d61d1c144798354b
Author: Christophe Lyon 
Date:   Mon Oct 5 09:52:59 2020 +

arm: [MVE] Add missing __arm_vcvtnq_u32_f32 intrinsic (PR 96914)

__arm_vcvtnq_u32_f32 was missing from arm_mve.h, although the s32_f32 and
[su]16_f16 versions were present.

This patch adds the missing version and testcase, which are
cut-and-paste from the other versions.

2020-10-08  Christophe Lyon  

gcc/
PR target/96914
* config/arm/arm_mve.h (__arm_vcvtnq_u32_f32): New.

gcc/testsuite/
PR target/96914
* gcc.target/arm/mve/intrinsics/vcvtnq_u32_f32.c: New test.

(cherry picked from commit 5a448362da6133c3b16ffdb0c795b657af7fa5a4)

[Bug target/96914] missing MVE intrinsics

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by SRINATH PARVATHANENI
:

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

commit r10-8906-gc4fb78e5d79b02ae720b2db42fa00e2c8d2d7ed5
Author: Christophe Lyon 
Date:   Tue Oct 6 07:36:31 2020 +

arm: [MVE] Remove illegal intrinsics (PR target/96914)

A few MVE intrinsics had an unsigned variant implement while they are
supported by the hardware.  This patch removes them:
__arm_vqrdmlashq_n_u8
__arm_vqrdmlahq_n_u8
__arm_vqdmlahq_n_u8
__arm_vqrdmlashq_n_u16
__arm_vqrdmlahq_n_u16
__arm_vqdmlahq_n_u16
__arm_vqrdmlashq_n_u32
__arm_vqrdmlahq_n_u32
__arm_vqdmlahq_n_u32
__arm_vmlaldavaxq_p_u32
__arm_vmlaldavaxq_p_u16

2020-10-08  Christophe Lyon  

gcc/
PR target/96914
* config/arm/arm_mve.h (vqrdmlashq_n_u8, vqrdmlashq_n_u16)
(vqrdmlashq_n_u32, vqrdmlahq_n_u8, vqrdmlahq_n_u16)
(vqrdmlahq_n_u32, vqdmlahq_n_u8, vqdmlahq_n_u16, vqdmlahq_n_u32)
(vmlaldavaxq_p_u16, vmlaldavaxq_p_u32): Remove.
* config/arm/arm_mve_builtins.def (vqrdmlashq_n_u, vqrdmlahq_n_u)
(vqdmlahq_n_u, vmlaldavaxq_p_u): Remove.
* config/arm/unspecs.md (VQDMLAHQ_N_U, VQRDMLAHQ_N_U)
(VQRDMLASHQ_N_U)
(VMLALDAVAXQ_P_U): Remove unspecs.
* config/arm/iterators.md (VQDMLAHQ_N_U, VQRDMLAHQ_N_U)
(VQRDMLASHQ_N_U, VMLALDAVAXQ_P_U): Remove attributes.
(VQDMLAHQ_N, VQRDMLAHQ_N, VQRDMLASHQ_N, VMLALDAVAXQ_P): Remove
unsigned variants from iterators.
* config/arm/mve.md (mve_vqdmlahq_n_)
(mve_vqrdmlahq_n_)
(mve_vqrdmlashq_n_, mve_vmlaldavaxq_p_):
Update comment.

gcc/testsuite/
PR target/96914
* gcc.target/arm/mve/intrinsics/vmlaldavaxq_p_u16.c: Remove.
* gcc.target/arm/mve/intrinsics/vmlaldavaxq_p_u32.c: Remove.
* gcc.target/arm/mve/intrinsics/vqdmlahq_n_u16.c: Remove.
* gcc.target/arm/mve/intrinsics/vqdmlahq_n_u32.c: Remove.
* gcc.target/arm/mve/intrinsics/vqdmlahq_n_u8.c: Remove.
* gcc.target/arm/mve/intrinsics/vqrdmlahq_n_u16.c: Remove.
* gcc.target/arm/mve/intrinsics/vqrdmlahq_n_u32.c: Remove.
* gcc.target/arm/mve/intrinsics/vqrdmlahq_n_u8.c: Remove.
* gcc.target/arm/mve/intrinsics/vqrdmlashq_n_u16.c: Remove.
* gcc.target/arm/mve/intrinsics/vqrdmlashq_n_u32.c: Remove.
* gcc.target/arm/mve/intrinsics/vqrdmlashq_n_u8.c: Remove.

(cherry picked from commit 237f12da4124b91503646b099a8282aa6b251ef9)

[Bug target/96914] missing MVE intrinsics

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-10 branch has been updated by SRINATH PARVATHANENI
:

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

commit r10-8905-gf5d0b57da1a0529a44da772f4f0b227cd5c50fd5
Author: Christophe Lyon 
Date:   Mon Oct 5 13:11:07 2020 +

arm: [MVE[ Add vqdmlashq intrinsics (PR target/96914)

This patch adds:
vqdmlashq_m_n_s16
vqdmlashq_m_n_s32
vqdmlashq_m_n_s8
vqdmlashq_n_s16
vqdmlashq_n_s32
vqdmlashq_n_s8

2020-10-08  Christophe Lyon  

gcc/
PR target/96914
* config/arm/arm_mve.h (vqdmlashq, vqdmlashq_m): Define.
* config/arm/arm_mve_builtins.def (vqdmlashq_n_s)
(vqdmlashq_m_n_s,): New.
* config/arm/unspecs.md (VQDMLASHQ_N_S, VQDMLASHQ_M_N_S): New
unspecs.
* config/arm/iterators.md (VQDMLASHQ_N_S, VQDMLASHQ_M_N_S): New
attributes.
(VQDMLASHQ_N): New iterator.
* config/arm/mve.md (mve_vqdmlashq_n_, mve_vqdmlashq_m_n_s): New
patterns.

gcc/testsuite/
PR target/96914
* gcc.target/arm/mve/intrinsics/vqdmlashq_m_n_s16.c: New test.
* gcc.target/arm/mve/intrinsics/vqdmlashq_m_n_s32.c: New test.
* gcc.target/arm/mve/intrinsics/vqdmlashq_m_n_s8.c: New test.
* gcc.target/arm/mve/intrinsics/vqdmlashq_n_s16.c: New test.
* gcc.target/arm/mve/intrinsics/vqdmlashq_n_s32.c: New test.
* gcc.target/arm/mve/intrinsics/vqdmlashq_n_s8.c: New test.

(cherry picked from commit afb198ee3729c29c8e681aedc656f55f4afe4053)

[Bug c++/97458] New: C++ parsing fails when calling specialized template method inside lambda

[gabriel_machado at live dot com via Gcc-bugs]

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

Bug ID: 97458
   Summary: C++ parsing fails when calling specialized template
method inside lambda
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabriel_machado at live dot com
  Target Milestone: ---

Created attachment 49385
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49385=edit
Minimal example

Minimal example:

template
struct A {
template void fn();
struct B { void init(A *p); };
};

template
void A::B::init(A *p) {
[p](){ p->fn(); }; // BUG
// [p](){ p->A::fn(); }; // OK
// [=](){ p->fn(); }; // OK
}

int main(){}



Command: g++ gcc-bug.cpp
Output:

gcc-bug.cpp: In lambda function:
gcc-bug.cpp:13:18: error: expected primary-expression before ‘int’
 [p](){ p->fn(); }; // BUG
  ^~~
gcc-bug.cpp:13:18: error: expected ‘;’ before ‘int’
 [p](){ p->fn(); }; // BUG
  ^~~
  ;



Command: g++ -v
Output:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)

System: Debian GNU/Linux 10 under WSL

[Bug c++/97372] [8/9/10/11 Regression] ICE in Tracy 0.7.3 in template class since r8-2836-gb54d4018b17c8e7b

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.5

[Bug c++/96425] [8/9/10/11 regression] internal compiler error in maybe_process_partial_specialization()

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.5

[Bug c++/96379] [10/11 Regression] GCC accepts totally invalid template declaration

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.3

[Bug c++/97237] [10/11 Regression] static_assert does not accept fpermissive code

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.3

[Bug target/96759] [10/11 Regression] ICE in extract_insn, at recog.c:2294

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.3

[Bug testsuite/97426] [11 regression] new test case gcc.dg/ipa/modref-1.c fails

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug bootstrap/97451] [11 Regression] r11-3959 failed --with-build-config=bootstrap-cet

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug analyzer/97411] [11 regression] bogus message from gcc.dg/analyzer/malloc-vs-local-1b.c after r11-3840

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug ada/95953] UTF Convert for UTF_16 to UTF_8 fails for values in U+10000 to U+10FFFF.

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

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

Arnaud Charlet  changed:

   What|Removed |Added

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

--- Comment #4 from Arnaud Charlet  ---
Fixed.

[Bug tree-optimization/97428] -O3 is great for basic AoSoA packing of complex arrays, but horrible one step above the basic

[already5chosen at yahoo dot com via Gcc-bugs]

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

--- Comment #9 from Michael_S  ---
Hopefully, you did regression tests for all main AoS<->SoA cases.
I.e.

typedef struct { double re, im; } dcmlx_t;
void soa2aos(double* restrict dstRe, double* restrict dstIm, const dcmlx_t
src[], int nq)
{
  for (int i = 0; i < nq*4; ++i) {
dcmlx_t s = src[i];
dstRe[i] = s.re;
dstIm[i] = s.im;
  }
}

void aos2soa(dcmlx_t* restrict dst, const double* srcRe, const double* srcIm,
int nq)
{
  for (int i = 0; i < nq*4; ++i) {
dst[i].re = srcRe[i];
dst[i].im = srcIm[i];
  }
}

And equivalents with float instead of double.

Right now 'gcc.10.2 -march=skylake -O3' does very good job for soa2aos() and
suboptimal, but not horrible job for aos2soa(). Hopefully, your changes do not
break any of it.

Personally, I don't like SoA layouts and very much prefer AoSoA, but I
recognize that in existing code bases SoA is more common.

[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||rguenth at gcc dot gnu.org

--- Comment #12 from Richard Biener  ---
See verify_gimple_comparison for what GIMPLE allows [to slip through]:

  /* For comparisons we do not have the operations type as the
 effective type the comparison is carried out in.  Instead
 we require that either the first operand is trivially
 convertible into the second, or the other way around.
 Because we special-case pointers to void we allow
 comparisons of pointers with the same mode as well.  */
  if (!useless_type_conversion_p (op0_type, op1_type)
  && !useless_type_conversion_p (op1_type, op0_type)
  && (!POINTER_TYPE_P (op0_type)
  || !POINTER_TYPE_P (op1_type)
  || TYPE_MODE (op0_type) != TYPE_MODE (op1_type)))
{

so this is the two pointers, same mode "exception".  I don't see the void *
special-casing anymore though.  That means removing the exception above
and fixing the fallout might be the way to go.  I guess FEs are in the
end responsible for the above.

[Bug testsuite/97301] [11 regression] gcc.target/powerpc/sse-movlps-1.c fails after r11-3434

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|ipa |testsuite

--- Comment #1 from Richard Biener  ---
testsuite issue - find the TBAA violation or add -fno-strict-aliasing.

[Bug ipa/97264] [11 Regression] -fpa-modref breaks va_arg on glibc

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/97056] aarch64/sve/cost_model_2.c fails on aarch64_be since r11-3148

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|11.0|---
Summary|[11 regression] |aarch64/sve/cost_model_2.c
   |aarch64/sve/cost_model_2.c  |fails on aarch64_be since
   |fails on aarch64_be since   |r11-3148
   |r11-3148|

--- Comment #4 from Richard Biener  ---
Unclear regression status.

[Bug tree-optimization/97104] [11 Regression] aarch64, SVE: ICE in vect_get_loop_mask since r11-3070-g783dc66f9cc

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug other/96927] [11 regression] ICE in libstdc++-v3/include/chrono:442

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-16

--- Comment #2 from Richard Biener  ---
https://gcc.gnu.org/pipermail/gcc-testresults/2020-October/609403.html doesn't
see any of those, so fixed?

[Bug c++/96901] [11 Regression] Many libstdc++ tests FAIL on i686-linux due to a PCH FE bug

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug ipa/97456] [10/11 Regression] An incorrect optimization causes a function to always return the same value when using -flto

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

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

--- Comment #3 from Martin Liška  ---
A bit reduced test-case:

$ #include 

auto wrong(float ) -> int {
  auto a = std::complex(pos, pos);
  auto b = std::complex(0.0f, 0.0f);

  b = b + a;

  if (b == 0.0f)
return 1;

  printf("%f\n", b.imag());
  return 0;
}

float val2 = 1.710780f;
float val3;

int main(int argc, char **argv) {
  auto val = argc == 1 ? val2 : val3;

  printf("val is %f\n", val);

  return (wrong(val), wrong(val));
}

It's not easy to bisect as it depends on definitions in complex.h.

[Bug tree-optimization/96376] [11 regression] vect/vect-alias-check.c and vect/vect-live-5.c fail on armeb

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

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

--- Comment #3 from Christophe Lyon  ---
I mentioned the configuration flags above:
--target armeb-none-linux-gnueabihf --with-mode arm --with-cpu cortex-a9
--with-fpu neon-fp16

[Bug c++/96840] [11 Regression] Recursive substitution in constrained commutative operator

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-16

[Bug target/95234] [11 Regression] 416.gamess Miscompare of exam29.out since r11-455-g94f687bd9ae37ece

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Martin Liška  ---
It's already fine.

[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 95234, which changed state.

Bug 95234 Summary: [11 Regression] 416.gamess Miscompare of exam29.out since 
r11-455-g94f687bd9ae37ece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95234

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug other/96800] [11 regression] compilation error for 20_util/function_objects/searchers.cc after r11-2857

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Don't see it in
https://gcc.gnu.org/pipermail/gcc-testresults/2020-October/609403.html so
assuming fixed.

[Bug middle-end/95757] [11 regression] missing warning in gcc.dg/Wstringop-overflow-25.c since r11-1517

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

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

--- Comment #4 from Christophe Lyon  ---
Yes I still see
FAIL: gcc.dg/Wstringop-overflow-25.c pr92814 (test for warnings, line 378)
for
arm-none-linux-gnueabihf --with-cpu=cortex-a5
arm-none-eabi -mcpu=cortex-m[034]

but for instance arm-none-linux-gnueabihf --with-cpu=cortex-a9 works.

[Bug middle-end/96680] [11 Regression][OpenMP][LTO] Declare variant + ICE in lto_fixup_prevailing_decls, at lto/lto-common.c:2595

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #4 from Richard Biener  ---
 

[Bug tree-optimization/96376] [11 regression] vect/vect-alias-check.c and vect/vect-live-5.c fail on armeb

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-10-16
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
I will have a look.  How do I need to configure to reproduce with a cc1 cross?

[Bug target/96375] [11 regression] arm/lob[2-5].c fail on some configurations

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
I assume fixed.

[Bug target/97457] [10/11 Regression] SVE: wrong code since r10-4752-g2d56600c

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

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

--- Comment #1 from Alex Coplan  ---
To be clear, the second beq .L8 is in the body of the main loop is not taken
either in the execution described here. The lack of a comment there might have
suggested otherwise.

[Bug c++/96162] [11 Regression] ICE in discriminator_for_local_entity, at cp/mangle.c:1910

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug tree-optimization/96147] [11 regression] gcc.dg/vect/slp-43.c etc. FAIL

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-10-16
   Priority|P3  |P1
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

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

[Bug tree-optimization/96129] [11 regression] gcc.dg/vect/vect-alias-check.c etc. FAIL

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Quite some revs, two vectorizer changes.  Do the FAILs still occur?