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

[haoxintu at gmail dot com]

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

Bug ID: 96162
   Summary: [11 Regression] ICE in discriminator_for_local_entity,
at cp/mangle.c:1910
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This code, test.cc, is an invalid code, makes GCC-trunk ICE. Interestingly,
this code does not trigger other released GCC-10 or GCC-9 ICE (confused by
earlier errors, bailing out). I guess this is a special regression
error-recovery case that is different from others.

$cat test.cc
#include 
void foo() {  
for (thread_local int * a ){}
}

$g++ test.cc
test.cc: In function ‘void foo()’:
test.cc:3:30: error: expected ‘;’ before ‘)’ token
3 | for (thread_local int * a ){}
  |  ^~
  |  ;
test.cc:3:31: error: expected primary-expression before ‘)’ token
3 | for (thread_local int * a ){}
  |   ^
test.cc:3:30: error: expected ‘;’ before ‘)’ token
3 | for (thread_local int * a ){}
  |  ^~
  |  ;
test.cc: At global scope:
test.cc:3:29: internal compiler error: in discriminator_for_local_entity, at
cp/mangle.c:1910
3 | for (thread_local int * a ){}
  | ^
0x69e943 discriminator_for_local_entity
../../gcc/cp/mangle.c:1910
0x9cdee8 write_local_name
../../gcc/cp/mangle.c:2019
0x9cdee8 write_name
../../gcc/cp/mangle.c:973
0x9d05a7 write_encoding
../../gcc/cp/mangle.c:825
0x9d5981 mangle_decl_string
../../gcc/cp/mangle.c:3858
0x9d5ba6 get_mangled_id
../../gcc/cp/mangle.c:3879
0x9d5ba6 mangle_decl(tree_node*)
../../gcc/cp/mangle.c:3917
0x12fca7d decl_assembler_name(tree_node*)
../../gcc/tree.c:708
0xbf17d9 symbol_table::insert_to_assembler_name_hash(symtab_node*, bool)
../../gcc/symtab.c:174
0xbf193c symbol_table::symtab_initialize_asm_name_hash()
../../gcc/symtab.c:266
0xbf2334 symbol_table::symtab_initialize_asm_name_hash()
../../gcc/symtab.c:1033
0xbf2334 symtab_node::get_for_asmname(tree_node const*)
../../gcc/symtab.c:1021
0xc02e60 handle_alias_pairs
../../gcc/cgraphunit.c:1512
0xc08ccc symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2962
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/haoxin/compilers/gcc/build/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure CC=gcc-10 CXX=g++-10
--prefix=/home/haoxin/compilers/gcc/build/ --enable-languages=c,c++
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200708 (experimental) (GCC) 

Thanks,
Haoxin

[Bug bootstrap/96160] Building gcc with multiple make jobs fails with: gcc/xgcc: No such file or directory

[plevine457 at gmail dot com]

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

--- Comment #4 from plevine457 at gmail dot com ---
The offending command is
> /var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/xgcc 
> -B/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/ -xc++ -nostdinc 
> /dev/null -S -o /dev/null 
> -fself-test=/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/testsuite/selftests

I would presume that there's no reason why gcc would emit "-o /dev/null" 
though I have seen it whaile using ccache.  

Looking further at
https://github.com/buildroot/buildroot/commit/58ecbbc3ef18c43ae1c02a5c4bf30aa7ef2d8092,
with regard to s-selftest-c:

> The problem only occurs when ccache is used with gcc 9 and 10,
> probably due to a race condition.
> 
> While debuging with "make -p" we can notice that s-selftest-c target
> contain only "cc1" as dependency instead of cc1 and SELFTEST_DEPS [4].
> 
>   s-selftest-c: cc1
> 
> While the build is failing, the s-selftest-c dependencies recipe is
> still running and reported as a bug by make.
> 
>   "Dependencies recipe running (THIS IS A BUG)."
> 
> A change [5] in gcc 9 seems to introduce the problem since we can't
> reproduce this problem with gcc 8.

So this is likely a ccache bug.

[Bug middle-end/77373] __attribute__((vector_size(N))) fails on AIX in symtab_node::get

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #5 from David Edelsohn  ---
Fixed

[Bug fortran/96158] Symbols not emitted for module common variables

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
% cat b.f90
module somemodule
   integer*8moduleVar
   common /othermodule/  moduleVar
end module
% cat a.f90
program myprogram
use somemodule
moduleVar = 123
call boo
end program
subroutine boo
   integer*8 n
   common /othermodule/n
   write(*, '(A, I3)') "moduleVar=", n
end
% nm -a b.o
 b .bss
 n .comment
 d .data
 N .debug_abbrev
 N .debug_aranges
 N .debug_info
 N .debug_line
 N .debug_str
 n .note.GNU-stack
 t .text
 a b.f90
0008 C othermodule_

The last line is what you're looking for.

% gfcx -g -o z b.f90 a.f90
% gdb ./z
(gdb) b main
Breakpoint 1 at 0x804867b: file a.f90, line 2.
(gdb) b boo
Breakpoint 2 at 0x80485ad: file a.f90, line 9.
(gdb) run
Starting program: /usr/home/kargl/tmp/z 

Breakpoint 1, main (argc=1, argv=0xffbfe7f0) at a.f90:2
2   use somemodule
(gdb) p moduleVar
No symbol "moduleVar" in current context.
(gdb) p (integer*8)othermodule_
$1 = 0
(gdb) c
Continuing.

Breakpoint 2, boo () at a.f90:9
9  write(*, '(A, I3)') "moduleVar=", n
(gdb) p n
$2 = 123
(gdb) p moduleVar
No symbol "moduleVar" in current context.
(gdb) p (integer*8)othermodule_
$3 = 123

I won't comment on the questionable programming idiom of placing
a common block in a module, which kind of defeats the niceties of
a module.

[Bug jit/96066] Cannot use values from some builtins because they are of void type

[bouanto at zoho dot com]

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

--- Comment #2 from Antoni  ---
An attempt to use, let's say, __atomic_fetch_add_4, will result in a error
like:

libgccjit.so: error: unimplemented primitive type for builtin (type: BT_I4)

[Bug c++/59135] Incorrect ambiguity in constexpr function overloads

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to fail||10.1.1, 11.0
   Keywords||rejects-valid
   Last reconfirmed||2020-07-10
 Ever confirmed|0   |1
 CC||jason at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
Fixed by r11-1571 which was also backported to the gcc-10 branch.

Jason, was this fixed by the change to tsubst_pack_expansion? Should it be
added to the testsuite before closing it?

[Bug libstdc++/96161] istream::ignore sets eofbit too soon

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-10
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=94749
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug target/95581] [11 Regression] ICE in gimple_call_arg, at gimple.h:3260 since r11-959-gb825a22890740f341eae566af27e18e528cd29a7

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Bill Seurer
:

https://gcc.gnu.org/g:21d3be2159f1b55e903caa2b1f80369d3681902b

commit r10-8463-g21d3be2159f1b55e903caa2b1f80369d3681902b
Author: Bill Seurer 
Date:   Fri Jul 10 17:30:26 2020 -0500

rs6000: Fix __builtin_altivec_mask_for_load to use correct type

gcc/ChangeLog:

PR target/95581
* config/rs6000/rs6000-call.c: Add new type v16qi_ftype_pcvoid.
(altivec_init_builtins) Change __builtin_altivec_mask_for_load to
use
v16qi_ftype_pcvoid with correct number of parameters.

(cherry picked from commit c6b7ba5de624f2a17d799bac5ff017cd065ce035)

[Bug fortran/96158] Symbols not emitted for module common variables

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||wrong-debug
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-10

--- Comment #1 from Thomas Koenig  ---
Confirmed with recent trunk, modulevar is not visible in gdb.

[Bug bootstrap/96160] Building gcc with multiple make jobs fails with: gcc/xgcc: No such file or directory

[plevine457 at gmail dot com]

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

--- Comment #3 from plevine457 at gmail dot com ---
> Which make version are you using?
GNU Make 4.3

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

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

--- Comment #34 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549880.html

[Bug c++/92812] Implement P1975R0: Fixing the wording of parenthesized aggregate-initialization

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Actually make that

  using T = int[1];
  T&& arr = static_cast(42);

[Bug c++/92812] Implement P1975R0: Fixing the wording of parenthesized aggregate-initialization

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
I don't know if this is supposed to be valid now too:

int arr[1] = static_cast(42);

or

using T = int[];
int arr[1] = static_cast(42);

but it seems so.

[Bug bootstrap/96160] Building gcc with multiple make jobs fails with: gcc/xgcc: No such file or directory

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Makefile.in:
GCC_PASSES=xgcc$(exeext) specs

SELFTEST_DEPS = $(GCC_PASSES) stmp-int-hdrs $(srcdir)/testsuite/selftests


c/Make-lang.in

C_SELFTEST_DEPS = cc1$(exeext) $(SELFTEST_DEPS)
...

s-selftest-c: $(C_SELFTEST_DEPS)

cp/Make-lang.in:
CPP_SELFTEST_DEPS = cc1plus$(exeext) $(SELFTEST_DEPS)
...
selftest-c++: s-selftest-c++
...
s-selftest-c++: $(CPP_SELFTEST_DEPS)

 CUT ---

This looks correct to me.  xgcc is there already in the depends of
s-selftest-c++.
Which make version are you using?

[Bug libstdc++/96161] New: istream::ignore sets eofbit too soon

[redi at gcc dot gnu.org]

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

Bug ID: 96161
   Summary: istream::ignore sets eofbit too soon
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
#include 
int main()
{
  std::istringstream s("++");
  s.ignore(2, '-');
  std::cout << "EOF? " << s.eof() << std::endl;
}

This shows that we set eofbit when the end of the stream is reached, even
though we have already discarded as many characters as requested.

Libc++ and MSVC do not set eofbit here.

[Bug bootstrap/96160] Building gcc with multiple make jobs fails with: gcc/xgcc: No such file or directory

[plevine457 at gmail dot com]

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

--- Comment #1 from plevine457 at gmail dot com ---
Created attachment 48861
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48861=edit
gcc-10.1.0-xgcc-selftest-makeopts.patch

This patch appears to resolve the issue on my end

[Bug bootstrap/96160] New: Building gcc with multiple make jobs fails with: gcc/xgcc: No such file or directory

[plevine457 at gmail dot com]

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

Bug ID: 96160
   Summary: Building gcc with multiple make jobs fails with:
gcc/xgcc: No such file or directory
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: plevine457 at gmail dot com
  Target Milestone: ---

Created attachment 48860
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48860=edit
build.log.bz2

Building GCC with multiple make jobs appears to trigger a race condition.  The
build often fails with:

> /var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/xgcc 
> -B/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/ -xc++ -nostdinc 
> /dev/null -S -o /dev/null 
> -fself-test=/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/testsuite/selftests
> /bin/bash: /var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/xgcc: No 
> such file or directory
> make[3]: *** 
> [/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/gcc/cp/Make-lang.in:178:
>  s-selftest-c++] Error 127

This has been noticeable at least since GCC-9.x.

Reported downstream at https://bugs.gentoo.org/728304.
Likely related to
https://github.com/cirosantilli/linux-kernel-module-cheat/issues/108

uname: Linux Laptop-PC 5.7.8-gentoo #1 SMP Fri Jul 10 04:05:05 EDT 2020 x86_64
Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz GenuineIntel GNU/Linux

[Bug translation/96159] atomic creates incorrect code for possible isaligned struct

[uecker at eecs dot berkeley.edu]

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

--- Comment #2 from Martin Uecker  ---

Clang produces a call to __atomic_load.

Also here is a godbolt link: https://godbolt.org/z/39PE1G

[Bug translation/96159] atomic creates incorrect code for possible isaligned struct

[uecker at eecs dot berkeley.edu]

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

--- Comment #1 from Martin Uecker  ---



On x86-64 the following struct has alignment 4 but gcc
creates a single mov instruction which according to my
understanding may fail to be atomic when it crosses a
cache line boundary. 

Documentation seems to imply that __atomic_load is
supposed to work for all types. It also compiles
without warning.


typedef struct { float re; float im; } foo_t;

int foo_align(void)
{
foo_t x;
return _Alignof(x);
}

foo_t foo_load(foo_t* x)
{
foo_t r;
__atomic_load(x, , __ATOMIC_SEQ_CST);
return r;
}


assembler:

foo_align:
mov eax, 4
ret
foo_load:
movqxmm0, QWORD PTR [rdi]
ret

[Bug translation/96159] New: atomic creates incorrect code for possible isaligned struct

[uecker at eecs dot berkeley.edu]

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

Bug ID: 96159
   Summary: atomic creates incorrect code for possible isaligned
struct
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: uecker at eecs dot berkeley.edu
  Target Milestone: ---

[Bug fortran/96158] New: Symbols not emitted for module common variables

[amelvill at umich dot edu]

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

Bug ID: 96158
   Summary: Symbols not emitted for module common variables
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amelvill at umich dot edu
  Target Milestone: ---

Created attachment 48859
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48859=edit
A tarball archive demonstrating the problem

I am trying to debug a Fortran program that uses common statements like this:

module somemodule

integer*8moduleVar

!Comment out the line below to make "call moduleVar" start working again
common /othermodule/  moduleVar

end module

... but it seems like gfortran does not emit debugging symbols that GDB can
use.

See this github repo for a minimal example: 
https://github.com/amelvill-umich/Fortran_GDB_Common

I have also attached a zip file with the sources (and a README that goes into
more detail, with GDB commands and output), if you prefer.
- With the common statement, I can access the variable in Fortran code, but GDB
is not able to read its value.
- Manually inspecting somemodule.o with a hex editor, I notice that the
.debug_str section seems to have information that might identify the common
variable, but it doesn't appear to be used

I almost filed a bug report with GDB about this, until I noticed that gfortran
emits only othermodule_ as a symbol for the othermodule common variable, which
didn't seem right. It doesn't seem like GDB would be able to provide very
useful information with only that as a symbol.

But, if this is the expected behavior let me know if you have any suggestions
for debugging variables like this (or if you think this is a bug/limitation in
GDB)

Additional information:

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.3.0-10ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--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-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--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,hsa
--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 9.3.0 (Ubuntu 9.3.0-10ubuntu2) 

The Makefile in the tarball/repository did not have -Wall -Wextra, but adding
these did not produce any additional information (no errors / warnings at all
from gfortran)
$ make
gfortran -c somemodule.f90 -g -Wall -Wextra
gfortran -c main.f90 -g -Wall -Wextra
gfortran -o main main.o somemodule.o -g -Wall -Wextra

I'm not aware of a way to reproduce this bug with a single file.

I mentioned this on the gfortran mailing list and somebody recommended that I
post this here.

Thanks,

- ajm

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2026-g70c884a4b82733027ac0e2620d09169b177080d7
Author: Harald Anlauf 
Date:   Fri Jul 10 21:35:35 2020 +0200

PR fortran/95980 - ICE in get_unique_type_string, at fortran/class.c:485

In SELECT TYPE, the argument may be an incorrectly specified unlimited
CLASS variable.  Avoid NULL pointer dereferences for clean error
recovery.

gcc/fortran/
PR fortran/95980
* class.c (gfc_add_component_ref, gfc_build_class_symbol):
Add checks for NULL pointer dereference.
* primary.c (gfc_variable_attr): Likewise.
* resolve.c (resolve_variable, resolve_assoc_var)
(resolve_fl_var_and_proc, resolve_fl_variable_derived)
(resolve_symbol): Likewise.

[Bug fortran/96086] ICE in gfc_match_select_rank, at fortran/match.c:6645

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:8a0b69f0b089c05d233b8e1a941825b1ceac93bd

commit r11-2025-g8a0b69f0b089c05d233b8e1a941825b1ceac93bd
Author: Harald Anlauf 
Date:   Fri Jul 10 21:00:13 2020 +0200

PR fortran/96086 - ICE in gfc_match_select_rank, at fortran/match.c:6645

Handle NULL pointer dereference on SELECT RANK with an invalid
assumed-rank array declaration.

gcc/fortran/
PR fortran/96086
* match.c (gfc_match_select_rank): Catch NULL pointer
dereference.
* resolve.c (resolve_assoc_var): Catch NULL pointer dereference
that may occur after an illegal declaration.

[Bug c++/92789] Non-obvious ?: behaviour with structurally equivalent types

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
Fixed for GCC 11.  Not suitable for backports.

[Bug middle-end/96151] [11 Regression] bootstrap fails due to ICE in c_omp_split_clauses

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Fixed.  Sorry for the breakage.

[Bug c++/92789] Non-obvious ?: behaviour with structurally equivalent types

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r11-2022-gefe99cca78215e339ba79f0a900a896b4c0a3d36
Author: Richard Sandiford 
Date:   Fri Jul 10 19:06:45 2020 +0100

arm: Treat GNU and Advanced SIMD vectors as distinct [PR92789, PR95726]

This is an arm version of aarch64 patch r11-1741.  The approach
is essentially identical, not much more than s/aarch64/arm/.

To recap, PR95726 is about template look-up for things like:

foo
foo

The immediate cause of the problem is that the hash function usually
returns different hashes for these types, yet the equality function
thinks they are equal.  This then raises the question of how the types
are supposed to be treated.

The answer we chose for AArch64 was that the GNU vector type should
be treated as distinct from float32x4_t, but that each type should
implicitly convert to the other.

This would mean that, as far as the PR is concerned, the hashing
function is right to (sometimes) treat the types differently and
the equality function is wrong to treat them as the same.

The most obvious way to enforce the type difference is to use a
target-specific type attribute.  That on its own is enough to fix
the PR.  The difficulty is deciding whether the knock-on effects
are acceptable.

One obvious effect is that GCC then rejects:

typedef float vecf __attribute__((vector_size(16)));
vecf x;
float32x4_t  = x;

on the basis that the types are no longer reference-compatible.
For AArch64 we took the approach that this was the correct behaviour.
It is also consistent with current Clang.

A trickier question is whether:

vecf x;
float32x4_t y;
⦠c ? x : y â¦

should be valid, and if so, what its type should be [PR92789].
As explained in the comment in the testcase, GCC and Clang both
accepted this, but GCC chose the âthenâ type while Clang chose
the âelseâ type.  This can lead to different mangling for (probably
artificial) corner cases, as seen for âsel1â and âsel2â in the
testcase.

Adding the attribute makes GCC reject the conditional expression
as ambiguous.  For AArch64 we took the approach that this too is
the correct behaviour, for the reasons described in the testcase.
However, it does seem to have the potential to break existing code.

gcc/
PR target/92789
PR target/95726
* config/arm/arm.c (arm_attribute_table): Add
"Advanced SIMD type".
(arm_comp_type_attributes): Check that the "Advanced SIMD type"
attributes are equal.
* config/arm/arm-builtins.c: Include stringpool.h and
attribs.h.
(arm_mangle_builtin_vector_type): Use the mangling recorded
in the "Advanced SIMD type" attribute.
(arm_init_simd_builtin_types): Add an "Advanced SIMD type"
attribute to each Advanced SIMD type, using the mangled type
as the attribute's single argument.

gcc/testsuite/
PR target/92789
PR target/95726
* g++.target/arm/pr95726.C: New test.

[Bug middle-end/96151] [11 Regression] bootstrap fails due to ICE in c_omp_split_clauses

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:510125d2272175f47b26227fbe9b8c8c5abfd988

commit r11-2023-g510125d2272175f47b26227fbe9b8c8c5abfd988
Author: Richard Sandiford 
Date:   Fri Jul 10 19:06:46 2020 +0100

expr: Move reduce_bit_field target mode check [PR96151]

In some cases, expand_expr_real_2 prefers to use the mode of the
caller-suggested target instead of the mode of the expression when
passing values to reduce_to_bit_field_precision.  E.g.:

  else if (target == 0)
op0 = convert_to_mode (mode, op0,
   TYPE_UNSIGNED (TREE_TYPE
  (treeop0)));
  else
{
  convert_move (target, op0,
TYPE_UNSIGNED (TREE_TYPE (treeop0)));
  op0 = target;
}

where âop0â might not have âmodeâ for the âelseâ branch,
but does for all the others.

reduce_to_bit_field_precision discards the suggested target if it
has the wrong mode.  This patch moves that to expand_expr_real_2
instead (conditional on reduce_bit_field).

gcc/
PR middle-end/96151
* expr.c (expand_expr_real_2): When reducing bit fields,
clear the target if it has a different mode from the expression.
(reduce_to_bit_field_precision): Don't do that here.  Instead
assert that the target already has the correct mode.

[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r11-2022-gefe99cca78215e339ba79f0a900a896b4c0a3d36
Author: Richard Sandiford 
Date:   Fri Jul 10 19:06:45 2020 +0100

arm: Treat GNU and Advanced SIMD vectors as distinct [PR92789, PR95726]

This is an arm version of aarch64 patch r11-1741.  The approach
is essentially identical, not much more than s/aarch64/arm/.

To recap, PR95726 is about template look-up for things like:

foo
foo

The immediate cause of the problem is that the hash function usually
returns different hashes for these types, yet the equality function
thinks they are equal.  This then raises the question of how the types
are supposed to be treated.

The answer we chose for AArch64 was that the GNU vector type should
be treated as distinct from float32x4_t, but that each type should
implicitly convert to the other.

This would mean that, as far as the PR is concerned, the hashing
function is right to (sometimes) treat the types differently and
the equality function is wrong to treat them as the same.

The most obvious way to enforce the type difference is to use a
target-specific type attribute.  That on its own is enough to fix
the PR.  The difficulty is deciding whether the knock-on effects
are acceptable.

One obvious effect is that GCC then rejects:

typedef float vecf __attribute__((vector_size(16)));
vecf x;
float32x4_t  = x;

on the basis that the types are no longer reference-compatible.
For AArch64 we took the approach that this was the correct behaviour.
It is also consistent with current Clang.

A trickier question is whether:

vecf x;
float32x4_t y;
⦠c ? x : y â¦

should be valid, and if so, what its type should be [PR92789].
As explained in the comment in the testcase, GCC and Clang both
accepted this, but GCC chose the âthenâ type while Clang chose
the âelseâ type.  This can lead to different mangling for (probably
artificial) corner cases, as seen for âsel1â and âsel2â in the
testcase.

Adding the attribute makes GCC reject the conditional expression
as ambiguous.  For AArch64 we took the approach that this too is
the correct behaviour, for the reasons described in the testcase.
However, it does seem to have the potential to break existing code.

gcc/
PR target/92789
PR target/95726
* config/arm/arm.c (arm_attribute_table): Add
"Advanced SIMD type".
(arm_comp_type_attributes): Check that the "Advanced SIMD type"
attributes are equal.
* config/arm/arm-builtins.c: Include stringpool.h and
attribs.h.
(arm_mangle_builtin_vector_type): Use the mangling recorded
in the "Advanced SIMD type" attribute.
(arm_init_simd_builtin_types): Add an "Advanced SIMD type"
attribute to each Advanced SIMD type, using the mangled type
as the attribute's single argument.

gcc/testsuite/
PR target/92789
PR target/95726
* g++.target/arm/pr95726.C: New test.

[Bug c++/92812] Implement P1975R0: Fixing the wording of parenthesized aggregate-initialization

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
This already works:

// P1975R0

struct Aggr { int x; int y; };

int
main ()
{
  Aggr a = static_cast(1);
  if (a.x != 1 || a.y != 0)
__builtin_abort ();
}

but we generate

q.C: In function ‘int main()’:
q.C:8:31: warning: missing initializer for member ‘Aggr::y’
[-Wmissing-field-initializers]
8 |   Aggr a = static_cast(1);
  |

[Bug middle-end/96151] [11 Regression] bootstrap fails due to ICE in c_omp_split_clauses

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
Summary|bootstrap fails due to ICE  |[11 Regression] bootstrap
   |in c_omp_split_clauses  |fails due to ICE in
   ||c_omp_split_clauses

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[mikestump at comcast dot net]

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

--- Comment #33 from Mike Stump  ---
Please, unless you expect it to work in an OS independent way, please
conditionalize on the systems it is known to work on, meaning, it important for
it to work on it, you think all the work for it to work on those systems has
been done.

[Bug c++/96077] GCC accepts ill-legal local enum definition

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Marek Polacek  ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549852.html

[Bug d/96157] d: No NRVO when returning an array of a non-POD struct

[ibuclaw at gdcproject dot org]

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

--- Comment #1 from Iain Buclaw  ---
If I were to propagate TREE_ADDRESSABLE from S to the static array, then the
assert doesn't trigger.

However, there lots of breakages that occur elsewhere within the front-end, so
a little more extra handling needs to be done.

[Bug target/96125] __attribute__((target("cpu=power10,mma"))) does not set TARGET_MMA

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #7 from Peter Bergner  ---
Fixed on GCC10 now too.

[Bug d/96157] New: d: No NRVO when returning an array of a non-POD struct

[ibuclaw at gdcproject dot org]

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

Bug ID: 96157
   Summary: d: No NRVO when returning an array of a non-POD struct
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

struct S
{
@disable this(this); // triggers nrvo
int v;
}

__gshared void* p;

S[1000] foo() nothrow
{
typeof(return) d;
p = 
return d;
}

extern(C) void main() nothrow
{
auto d = foo();
assert(p == );
}

[Bug c/96151] bootstrap fails due to ICE in c_omp_split_clauses

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 CC||rsandifo at gcc dot gnu.org
   Last reconfirmed||2020-07-10
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Fallout from my PR95694 patch.  I noticed earlier today that
it broke bootstrap on arm-linux-gnueabihf in the same way.
About to post a patch.

[Bug d/96156] New: d: No RVO when returning struct literals initialized with constructor.

[ibuclaw at gdcproject dot org]

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

Bug ID: 96156
   Summary: d: No RVO when returning struct literals initialized
with constructor.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

The address of 's' should become the 'this' pointer of the __ctor() call.

struct S66 {
int x;
__gshared void* ptr;
@disable this(this);
this(int x) { ptr =  this.x = x; }
}
auto f66() { return g66(); }
auto g66() { return h66(); }
auto h66() { return S66(100); }
void main()
{
auto s = f66();
assert( == S66.ptr);
}

[Bug c++/96155] "throw" that is not executed in constexpr function fails to compile

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.  Doesn't look like a regression.

[Bug c++/94554] spurious -Waddress warning within "if constexpr" function-null compares

[lts-rudolph at gmx dot de]

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

Klaus Rudolph  changed:

   What|Removed |Added

 CC||lts-rudolph at gmx dot de

--- Comment #4 from Klaus Rudolph  ---
The code can be modified to be well formed if changed to:

if constexpr (F != nullptr )) {

g++ still emits the bogus warning in that case which is a bug I believe!

[Bug target/96125] __attribute__((target("cpu=power10,mma"))) does not set TARGET_MMA

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:45b7f80f2e591d4f674d2f0798d31d51a7e46a72

commit r10-8458-g45b7f80f2e591d4f674d2f0798d31d51a7e46a72
Author: Peter Bergner 
Date:   Thu Jul 9 15:52:59 2020 -0500

rs6000: Allow MMA built-in initialization regardless of compiler options

Built-in initialization occurs only once and fairly early, when the
command line options are in force.  If the -mcpu= is pre-power10,
then we fail to initialize the MMA built-ins, so they are not
available to call in a #pragma target/attribute target function.
The fix is to basically always (on server type cpus) initialize the MMA
built-ins so we can use them in #pragma target/attribute target functions.

2020-07-09  Peter Bergner  

gcc/
PR target/96125
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Define the
MMA
specific types __vector_quad and __vector_pair, and initialize the
MMA built-ins if TARGET_EXTRA_BUILTINS is set.
(mma_init_builtins): Don't test for mask set in
rs6000_builtin_mask.
Remove now unneeded mask variable.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add the
OPTION_MASK_MMA flag for power10 if not already set.

gcc/testsuite/
PR target/96125
* gcc.target/powerpc/pr96125.c: New test.

(cherry picked from commit fd263be4b523ff1b7f7dda49d856cc57221e8d21)

[Bug c++/96155] New: "throw" that is not executed in constexpr function fails to compile

[r-gcc at mail dot uk]

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

Bug ID: 96155
   Summary: "throw" that is not executed in constexpr function
fails to compile
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: r-gcc at mail dot uk
  Target Milestone: ---

This fails to compile on gcc trunk, while the same code compiles fine in clang:

constexpr bool foo()
{
for(int i = 0; i != 5; ++i)
{
if(i == 3)
return false;
}
throw 5;
return true;
}


this is the message I am getting:

error: expression ‘’ is not a constant expression

live example:

https://godbolt.org/z/eqqr4f

[Bug c/96151] bootstrap fails due to ICE in c_omp_split_clauses

[acsawdey at gcc dot gnu.org]

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

--- Comment #1 from acsawdey at gcc dot gnu.org ---
This compile is successful like this but fails if I add -mcpu=power9.

/home2/sawdey/work/gcc/mamboCI/build-mambo/./prev-gcc/xg++
-B/home2/sawdey/work/gcc/mamboCI/build-mambo/./prev-gcc/
-B/opt/binutils-gcc-p10/powerpc64le-unknown-linux-gnu/bin/ -nostdinc++
-B/home2/sawdey/work/gcc/mamboCI/build-mambo/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home2/sawdey/work/gcc/mamboCI/build-mambo/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home2/sawdey/work/gcc/mamboCI/build-mambo/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu

-I/home2/sawdey/work/gcc/mamboCI/build-mambo/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include
 -I/home2/sawdey/work/gcc/mamboCI/gcc-master/libstdc++-v3/libsupc++
-L/home2/sawdey/work/gcc/mamboCI/build-mambo/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home2/sawdey/work/gcc/mamboCI/build-mambo/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2
-fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -Ic-family
-I../../gcc-master/gcc -I../../gcc-master/gcc/c-family
-I../../gcc-master/gcc/../include -I../../gcc-master/gcc/../libcpp/include 
-I../../gcc-master/gcc/../libdecnumber
-I../../gcc-master/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-master/gcc/../libbacktrace   -o c-family/c-omp.o -MT
c-family/c-omp.o -MMD -MP -MF c-family/.deps/c-omp.TPo
../../gcc-master/gcc/c-family/c-omp.c

[Bug d/96154] New: d: Add -Wvarargs warning flag to compiler

[ibuclaw at gdcproject dot org]

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

Bug ID: 96154
   Summary: d: Add -Wvarargs warning flag to compiler
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Because va_start() and va_arg() templates are recognized and mapped directly to
gcc builtins/codes in d/intrinsics.cc

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #32 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #31 from H.J. Lu  ---

>> If this is a Linux-only feature, shouldn't the tests rather be
>> restricted to Linux instead?  It certainly also fails on freebsd,
>> darwin, mingw and whatever more.  Having to skip it on all those
>> explicitly (until we discover the next target we forgot about) seems
>> just the wrong way round.
>
> These features aren't Linux specific.  But they do require special
> sequence at function entrance.  Solaris has a different function entry
> which may not work with these features.

Neither do all the other x86 targets listed above.  I still think that
the list of targets that *can* support this test is considerably shorter
than the one that don't.

[Bug d/96153] New: d: struct literals have non-deterministic hash values

[ibuclaw at gdcproject dot org]

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

Bug ID: 96153
   Summary: d: struct literals have non-deterministic hash values
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

struct Checked(T, Hook)
{
private T payload;
Hook hook;

size_t toHash() const nothrow @safe
{
return hashOf(payload) ^ hashOf(hook);
}
}

Checked!(T, Hook) checked(Hook, T)(const T value)
{
return Checked!(T, Hook)(value);
}

@system unittest
{
static struct Hook3
{
ulong var1 = ulong.max;
uint var2 = uint.max;
}

assert(checked!Hook3(12).toHash() != checked!Hook3(13).toHash());
assert(checked!Hook3(13).toHash() == checked!Hook3(13).toHash());
}

[Bug d/96152] New: d: associative array literals don't have alignment holes filled.

[ibuclaw at gdcproject dot org]

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

Bug ID: 96152
   Summary: d: associative array literals don't have alignment
holes filled.
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

auto assocArray(Keys, Values)(Keys keys, Values values)
{
void* aa;
{
if (values.length > keys.length)
values = values[0 .. keys.length];
else if (keys.length > values.length)
keys = keys[0 .. values.length];
aa = aaLiteral(keys, values);
}
alias Key = typeof(keys[0]);
alias Value = typeof(values[0]);
return (() @trusted => cast(Value[Key]) aa)();
}

@safe unittest
{
struct ThrowingElement
{
int i;
static bool b;
~this(){
if (b)
throw new Exception("");
}
}
assert(assocArray([ThrowingElement()], [0]) == [ThrowingElement(): 0]);
}

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

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

--- Comment #31 from H.J. Lu  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #30)
> > --- Comment #29 from H.J. Lu  ---
> > (In reply to r...@cebitec.uni-bielefeld.de from comment #28)
> >> > --- Comment #27 from H.J. Lu  ---
> >> > (In reply to r...@cebitec.uni-bielefeld.de from comment #26)
> >> >> > --- Comment #25 from H.J. Lu  ---
> >> >> > -fpatchable-function-entry and -mfentry generate special instruction
> >> >> > sequence at function entry.  Does Solaris support such special
> >> >> > instruction sequence?
> >> >> 
> >> >> Where would such support live?  The kernel?  libc.so.1?  ld.so.1?
> >> >
> >> > -fpatchable-function-entry and -mfentry are used in Linux kernel.
> >> 
> >> In that case: no.  The Solaris kernel can (and is) compiled both by gcc
> >> and Studio cc, and the latter certainly hasn't anything similar.
> >
> > Then just skip these tests on Solaris.
> 
> If this is a Linux-only feature, shouldn't the tests rather be
> restricted to Linux instead?  It certainly also fails on freebsd,
> darwin, mingw and whatever more.  Having to skip it on all those
> explicitly (until we discover the next target we forgot about) seems
> just the wrong way round.


These features aren't Linux specific.  But they do require special
sequence at function entrance.  Solaris has a different function entry
which may not work with these features.

[Bug c/96151] New: bootstrap fails due to ICE in c_omp_split_clauses

[acsawdey at gcc dot gnu.org]

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

Bug ID: 96151
   Summary: bootstrap fails due to ICE in c_omp_split_clauses
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
  Target Milestone: ---

Started to see this on trunk last night. Tested again and still see it with
r11-2018.

configured with: 

/home2/sawdey/work/gcc/mamboCI/gcc-master/configure
--prefix=/opt/binutils-gcc-p10 --enable-languages=all --enable-bootstrap
--with-cpu=power9


/home2/sawdey/work/gcc/mamboCI/build-mambo/./prev-gcc/xg++
-B/home2/sawdey/work/gcc/mamboCI/build-mambo/./prev-gcc/
-B/opt/binutils-gcc-p10/powerpc64le-unknown-linux-gnu/bin/ -nostdinc++
-B/home2/sawdey/work/gcc/mamboCI/build-mambo/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home2/sawdey/work/gcc/mamboCI/build-mambo/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home2/sawdey/work/gcc/mamboCI/build-mambo/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu

-I/home2/sawdey/work/gcc/mamboCI/build-mambo/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include
 -I/home2/sawdey/work/gcc/mamboCI/gcc-master/libstdc++-v3/libsupc++
-L/home2/sawdey/work/gcc/mamboCI/build-mambo/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home2/sawdey/work/gcc/mamboCI/build-mambo/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2
-fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -Ic-family
-I/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc
-I/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/c-family
-I/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/../include
-I/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/../libcpp/include 
-I/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/../libdecnumber
-I/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/../libdecnumber/dpd
-I../libdecnumber
-I/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/../libbacktrace   -o
c-family/c-omp.o -MT c-family/c-omp.o -MMD -MP -MF c-family/.deps/c-omp.TPo
/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/c-family/c-omp.c
during RTL pass: expand
/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/c-family/c-omp.c: In function
‘void c_omp_split_clauses(location_t, tree_code, omp_clause_mask, tree,
tree_node**)’:
/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/c-family/c-omp.c:1561:1: internal
compiler error: in reduce_to_bit_field_precision, at expr.c:11530
 1561 | c_omp_split_clauses (location_t loc, enum tree_code code,
  | ^~~
0x10decc9f reduce_to_bit_field_precision
/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/expr.c:11530
0x10dde35b expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/expr.c:8786
0x10de5443 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/expr.c:10152
0x10ddc6c7 expand_expr_real(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/expr.c:8469
0x10db55f7 expand_expr
/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/expr.h:282
0x10ddac03 expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/expr.c:8065
0x10ddc8f7 expand_cond_expr_using_cmove
/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/expr.c:8518
0x10de3c97 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/expr.c:9869
0x10b79587 expand_gimple_stmt_1
/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/cfgexpand.c:3786
0x10b798d3 expand_gimple_stmt
/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/cfgexpand.c:3847
0x10b83887 expand_gimple_basic_block
/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/cfgexpand.c:5888
0x10b861d7 execute
/home2/sawdey/work/gcc/mamboCI/gcc-master/gcc/cfgexpand.c:6572
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:1124: recipe for target 'c-family/c-omp.o' failed

[Bug ipa/96130] [10/11 Regression] ICE in analyze_function_body at gcc/ipa-fnsummary.c:2769 since r10-3199-g351e7c3b5fbd45bd

[jakub at gcc dot gnu.org]

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

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

So, my fix would be like this (untested except on the testcase so far).

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #29 from H.J. Lu  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #28)
>> > --- Comment #27 from H.J. Lu  ---
>> > (In reply to r...@cebitec.uni-bielefeld.de from comment #26)
>> >> > --- Comment #25 from H.J. Lu  ---
>> >> > -fpatchable-function-entry and -mfentry generate special instruction
>> >> > sequence at function entry.  Does Solaris support such special
>> >> > instruction sequence?
>> >> 
>> >> Where would such support live?  The kernel?  libc.so.1?  ld.so.1?
>> >
>> > -fpatchable-function-entry and -mfentry are used in Linux kernel.
>> 
>> In that case: no.  The Solaris kernel can (and is) compiled both by gcc
>> and Studio cc, and the latter certainly hasn't anything similar.
>
> Then just skip these tests on Solaris.

If this is a Linux-only feature, shouldn't the tests rather be
restricted to Linux instead?  It certainly also fails on freebsd,
darwin, mingw and whatever more.  Having to skip it on all those
explicitly (until we discover the next target we forgot about) seems
just the wrong way round.

[Bug ipa/96130] [10/11 Regression] ICE in analyze_function_body at gcc/ipa-fnsummary.c:2769 since r10-3199-g351e7c3b5fbd45bd

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
My understanding of the problem is that set_switch_stmt_execution_predicate
figures out that the default: is unreachable (operand is a bitfield with values
0 to 7 and there are cases for all 8) and notes that into the predicate for the
switch -> default: edge's aux, and then compute_bb_predicates iterates, but as
the 3 -> 9 predicate always resolves to false, nothing adds bb_9->aux.  And
later we try to dereference that.
So, either predicates in bb->aux are optional and we should treat a missing
predicate as false predicate, or compute_bb_predicate should ensure to fill in
bb->aux even for bbs it left NULL at the end.
  if (bb->aux)
bb_predicate = *(predicate *) bb->aux;
  else
bb_predicate = false;
in analyze_function_body suggests that perhaps the latter is the case.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

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

--- Comment #29 from H.J. Lu  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #28)
> > --- Comment #27 from H.J. Lu  ---
> > (In reply to r...@cebitec.uni-bielefeld.de from comment #26)
> >> > --- Comment #25 from H.J. Lu  ---
> >> > -fpatchable-function-entry and -mfentry generate special instruction
> >> > sequence at function entry.  Does Solaris support such special
> >> > instruction sequence?
> >> 
> >> Where would such support live?  The kernel?  libc.so.1?  ld.so.1?
> >
> > -fpatchable-function-entry and -mfentry are used in Linux kernel.
> 
> In that case: no.  The Solaris kernel can (and is) compiled both by gcc
> and Studio cc, and the latter certainly hasn't anything similar.

Then just skip these tests on Solaris.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #27 from H.J. Lu  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #26)
>> > --- Comment #25 from H.J. Lu  ---
>> > -fpatchable-function-entry and -mfentry generate special instruction
>> > sequence at function entry.  Does Solaris support such special
>> > instruction sequence?
>> 
>> Where would such support live?  The kernel?  libc.so.1?  ld.so.1?
>
> -fpatchable-function-entry and -mfentry are used in Linux kernel.

In that case: no.  The Solaris kernel can (and is) compiled both by gcc
and Studio cc, and the latter certainly hasn't anything similar.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

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

--- Comment #27 from H.J. Lu  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #26)
> > --- Comment #25 from H.J. Lu  ---
> > -fpatchable-function-entry and -mfentry generate special instruction
> > sequence at function entry.  Does Solaris support such special
> > instruction sequence?
> 
> Where would such support live?  The kernel?  libc.so.1?  ld.so.1?

-fpatchable-function-entry and -mfentry are used in Linux kernel.

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #25 from H.J. Lu  ---
> -fpatchable-function-entry and -mfentry generate special instruction
> sequence at function entry.  Does Solaris support such special
> instruction sequence?

Where would such support live?  The kernel?  libc.so.1?  ld.so.1?

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[hjl.tools at gmail dot com]

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

--- Comment #25 from H.J. Lu  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #24)
> > --- Comment #23 from H.J. Lu  ---
> > Do -fpatchable-function-entry and -mfentry work on Solaris?
> 
> I don't have the slightest idea what that would mean, and the
> descriptions of the options don't leave me any wiser.

-fpatchable-function-entry and -mfentry generate special instruction
sequence at function entry.  Does Solaris support such special
instruction sequence?

[Bug ipa/96130] [10/11 Regression] ICE in analyze_function_body at gcc/ipa-fnsummary.c:2769 since r10-3199-g351e7c3b5fbd45bd

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Reduced testcase from the other PR which is shorter:
struct S { unsigned j : 3; };
int k, l, m;

void
foo (struct S x)
{
  while (l != 5)
switch (x.j)
  {
  case 1:
  case 3:
  case 4:
  case 6:
  case 2:
  case 5:
l = m;
  case 7:
  case 0:
k = 0;
  default:
break;
  }
}

[Bug ipa/96130] [10/11 Regression] ICE in analyze_function_body at gcc/ipa-fnsummary.c:2769 since r10-3199-g351e7c3b5fbd45bd

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
*** Bug 96150 has been marked as a duplicate of this bug. ***

[Bug ipa/96150] [10/11 Regression] ICE in analyze_function_body on switch since r10-3199

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Liška  ---
Dup.

*** This bug has been marked as a duplicate of bug 96130 ***

[Bug ipa/96150] [10/11 Regression] ICE in analyze_function_body on switch since r10-3199

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
   Keywords||ice-on-valid-code
 CC||fxue at gcc dot gnu.org,
   ||hubicka at gcc dot gnu.org,
   ||jamborm at gcc dot gnu.org
   Last reconfirmed||2020-07-10
 Ever confirmed|0   |1
   Target Milestone|--- |10.2
 Status|UNCONFIRMED |NEW

[Bug ipa/96150] New: [10/11 Regression] ICE in analyze_function_body on switch since r10-3199

[jakub at gcc dot gnu.org]

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

Bug ID: 96150
   Summary: [10/11 Regression] ICE in analyze_function_body on
switch since r10-3199
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The following testcase at -O2 (-O1 and higher) since
r10-3199-g351e7c3b5fbd45bde3efb601f7fee9a31c4f2063
in 
rh1855742.i: In function ‘foo’:
rh1855742.i:23:1: internal compiler error: Segmentation fault
   23 | }
  | ^
0x1300ff4 crash_signal
../../gcc/toplev.c:328
0xf34e3e analyze_function_body
../../gcc/ipa-fnsummary.c:2802
0xf35974 compute_fn_summary(cgraph_node*, bool)
../../gcc/ipa-fnsummary.c:2974
0xf39486 inline_analyze_function(cgraph_node*)
../../gcc/ipa-fnsummary.c:4078
0xf39663 ipa_fn_summary_generate
../../gcc/ipa-fnsummary.c:4121
0x1182288 execute_ipa_summary_passes(ipa_opt_pass_d*)
../../gcc/passes.c:2191
0xbca2f3 ipa_passes
../../gcc/cgraphunit.c:2646
0xbca696 symbol_table::compile()
../../gcc/cgraphunit.c:2756
0xbcac42 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:3003


struct S { unsigned j : 3; };
int k, l, m;

void
foo (struct S x)
{
  while (l != 5)
switch (x.j)
  {
  case 1:
  case 3:
  case 4:
  case 6:
  case 2:
  case 5:
l = m;
  case 7:
  case 0:
k = 0;
  default:
break;
  }
}

[Bug target/95581] [11 Regression] ICE in gimple_call_arg, at gimple.h:3260 since r11-959-gb825a22890740f341eae566af27e18e528cd29a7

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Bill Seurer :

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

commit r11-2018-gc6b7ba5de624f2a17d799bac5ff017cd065ce035
Author: Bill Seurer, 507-253-3502, seu...@us.ibm.com <(no_default)>
Date:   Thu Jul 9 16:41:38 2020 -0500

rs6000: Fix __builtin_altivec_mask_for_load to use correct type

gcc/ChangeLog:

PR target/95581
* config/rs6000/rs6000-call.c: Add new type v16qi_ftype_pcvoid.
(altivec_init_builtins) Change __builtin_altivec_mask_for_load to
use
v16qi_ftype_pcvoid with correct number of parameters.

[Bug c++/90448] [8/9/10/11 Regression] decltype-based lambda parameter pack is rejected

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

Summary|[8/9 Regression]|[8/9/10/11 Regression]
   |decltype-based lambda   |decltype-based lambda
   |parameter pack is rejected  |parameter pack is rejected

--- Comment #8 from Rainer Orth  ---
At least on 32-bit Solaris/SPARC, the ICE also occurs on the gcc-10 branch and
master.

[Bug testsuite/96149] gcc.dg/vect/slp-46.c on aarch64

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
The two single-element interleaving cases are expected to be SLP vectorized
where the target needs a splat operation (permute of two doubles {0, 0}).

Ah, the reason is the aarch64 speciality that forces load/store-lanes ...

slp-46.c:17:3: note:   can use vec_store_lanes
slp-46.c:17:3: note:   can use vec_load_lanes
slp-46.c:17:3: missed:   Built SLP cancelled: can use load/store-lanes

I don't think we have an effective target for this?  So XFAIL for aarch64?

[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #23 from H.J. Lu  ---
> Do -fpatchable-function-entry and -mfentry work on Solaris?

I don't have the slightest idea what that would mean, and the
descriptions of the options don't leave me any wiser.

[Bug c++/59135] Incorrect ambiguity in constexpr function overloads

[familiebaumanns at gmail dot com]

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

Bernd Baumanns  changed:

   What|Removed |Added

 CC||familiebaumanns at gmail dot 
com

--- Comment #2 from Bernd Baumanns  ---
It works now in gcc trunk

[Bug tree-optimization/95694] [9/10 Regression] ICE in trunc_int_for_mode, at explow.c:59 since r9-7156-g33579b59aaf02eb7

[rsandifo at gcc dot gnu.org]

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Just realised that this breaks bootstrap on arm-linux-gnueabihf.
I'd originally moved the zeroing of incorrect targets to
expand_expr_real_2, but then forgot why and undid it in the
name of going for the minimal fix.  The reason is/was code like:

  else if (target == 0)
op0 = convert_to_mode (mode, op0,
   TYPE_UNSIGNED (TREE_TYPE
  (treeop0)));
  else
{
  convert_move (target, op0,
TYPE_UNSIGNED (TREE_TYPE (treeop0)));
  op0 = target;
}

where we could convert to the mode of the supplied target
instead of “mode”.

Testing a fix.

[Bug testsuite/96149] New: gcc.dg/vect/slp-46.c on aarch64

[clyon at gcc dot gnu.org]

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

Bug ID: 96149
   Summary: gcc.dg/vect/slp-46.c on aarch64
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

gcc.dg/vect/slp-46.c fails on aarch64 since it was introduced.

In the logs I can see:
PASS: gcc.dg/vect/slp-46.c execution test
gcc.dg/vect/slp-46.c: pattern found 0 times
FAIL: gcc.dg/vect/slp-46.c scan-tree-dump-times vect "vectorizing stmts using
SLP" 2

[Bug gcov-profile/96148] [11 regression] gcc.dg/tree-prof/crossmodule-indir-call-topn-[12].c UNRESOLVED

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2017-ge969e9be88e83871ef66f4cd1592db7e8ae6244b
Author: Martin Liska 
Date:   Fri Jul 10 14:45:13 2020 +0200

testsuite: Fix WPA scanning.

gcc/testsuite/ChangeLog:

PR gcov-profile/96148
* lib/scanwpaipa.exp: Fix wpa dump file suffix the same way
as other in the file.

[Bug gcov-profile/96148] [11 regression] gcc.dg/tree-prof/crossmodule-indir-call-topn-[12].c UNRESOLVED

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed on master.

[Bug gcov-profile/96148] [11 regression] gcc.dg/tree-prof/crossmodule-indir-call-topn-[12].c UNRESOLVED

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-10
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Thanks for the report, I know how to fix it.

[Bug demangler/96143] C++ demangler should not add a lambda as a substitution

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-10
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Nathan Sidwell  ---
Thanks for the reminder.  If you do indeed have a patch, you know what to do :)

[Bug c++/96052] Unlike Clang, alignment specifier is ignored on empty no_unique_address members

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r11-2014-ge47dfca5aa473e77fdff95d631dc39de87a41eec
Author: Jason Merrill 
Date:   Thu Jul 9 15:11:12 2020 -0400

c++: [[no_unique_address]] fixes. [PR96105]

We were wrongly checking is_empty_class on the result of strip_array_types
rather than the actual field type.  We weren't considering the alignment of
the data member.  We needed to handle unions the same way as
layout_nonempty_base_or_field.

gcc/cp/ChangeLog:

PR c++/96105
PR c++/96052
PR c++/95976
* class.c (check_field_decls): An array of empty classes is not an
empty data member.
(layout_empty_base_or_field): Handle explicit alignment.
Fix union handling.

gcc/testsuite/ChangeLog:

PR c++/96105
PR c++/96052
PR c++/95976
* g++.dg/cpp2a/no_unique_address4.C: New test.
* g++.dg/cpp2a/no_unique_address5.C: New test.
* g++.dg/cpp2a/no_unique_address6.C: New test.

[Bug c++/95976] [[no_unique_address]] on union members has the opposite-of-intended effect

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r11-2014-ge47dfca5aa473e77fdff95d631dc39de87a41eec
Author: Jason Merrill 
Date:   Thu Jul 9 15:11:12 2020 -0400

c++: [[no_unique_address]] fixes. [PR96105]

We were wrongly checking is_empty_class on the result of strip_array_types
rather than the actual field type.  We weren't considering the alignment of
the data member.  We needed to handle unions the same way as
layout_nonempty_base_or_field.

gcc/cp/ChangeLog:

PR c++/96105
PR c++/96052
PR c++/95976
* class.c (check_field_decls): An array of empty classes is not an
empty data member.
(layout_empty_base_or_field): Handle explicit alignment.
Fix union handling.

gcc/testsuite/ChangeLog:

PR c++/96105
PR c++/96052
PR c++/95976
* g++.dg/cpp2a/no_unique_address4.C: New test.
* g++.dg/cpp2a/no_unique_address5.C: New test.
* g++.dg/cpp2a/no_unique_address6.C: New test.

[Bug c++/96105] GCC not consistent on whether no_unique_address array is an empty data member

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r11-2014-ge47dfca5aa473e77fdff95d631dc39de87a41eec
Author: Jason Merrill 
Date:   Thu Jul 9 15:11:12 2020 -0400

c++: [[no_unique_address]] fixes. [PR96105]

We were wrongly checking is_empty_class on the result of strip_array_types
rather than the actual field type.  We weren't considering the alignment of
the data member.  We needed to handle unions the same way as
layout_nonempty_base_or_field.

gcc/cp/ChangeLog:

PR c++/96105
PR c++/96052
PR c++/95976
* class.c (check_field_decls): An array of empty classes is not an
empty data member.
(layout_empty_base_or_field): Handle explicit alignment.
Fix union handling.

gcc/testsuite/ChangeLog:

PR c++/96105
PR c++/96052
PR c++/95976
* g++.dg/cpp2a/no_unique_address4.C: New test.
* g++.dg/cpp2a/no_unique_address5.C: New test.
* g++.dg/cpp2a/no_unique_address6.C: New test.

[Bug c++/96105] GCC not consistent on whether no_unique_address array is an empty data member

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8456-g3bb330022ce47a3e8966a9930f392e497c608f59
Author: Jason Merrill 
Date:   Thu Jul 9 15:11:12 2020 -0400

c++: [[no_unique_address]] fixes. [PR96105]

We were wrongly checking is_empty_class on the result of strip_array_types
rather than the actual field type.  We weren't considering the alignment of
the data member.  We needed to handle unions the same way as
layout_nonempty_base_or_field.

gcc/cp/ChangeLog:

PR c++/96105
PR c++/96052
PR c++/95976
* class.c (check_field_decls): An array of empty classes is not an
empty data member.
(layout_empty_base_or_field): Handle explicit alignment.
Fix union handling.

gcc/testsuite/ChangeLog:

PR c++/96105
PR c++/96052
PR c++/95976
* g++.dg/cpp2a/no_unique_address4.C: New test.
* g++.dg/cpp2a/no_unique_address5.C: New test.
* g++.dg/cpp2a/no_unique_address6.C: New test.

[Bug c++/96052] Unlike Clang, alignment specifier is ignored on empty no_unique_address members

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

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

commit r10-8456-g3bb330022ce47a3e8966a9930f392e497c608f59
Author: Jason Merrill 
Date:   Thu Jul 9 15:11:12 2020 -0400

c++: [[no_unique_address]] fixes. [PR96105]

We were wrongly checking is_empty_class on the result of strip_array_types
rather than the actual field type.  We weren't considering the alignment of
the data member.  We needed to handle unions the same way as
layout_nonempty_base_or_field.

gcc/cp/ChangeLog:

PR c++/96105
PR c++/96052
PR c++/95976
* class.c (check_field_decls): An array of empty classes is not an
empty data member.
(layout_empty_base_or_field): Handle explicit alignment.
Fix union handling.

gcc/testsuite/ChangeLog:

PR c++/96105
PR c++/96052
PR c++/95976
* g++.dg/cpp2a/no_unique_address4.C: New test.
* g++.dg/cpp2a/no_unique_address5.C: New test.
* g++.dg/cpp2a/no_unique_address6.C: New test.

[Bug c++/95976] [[no_unique_address]] on union members has the opposite-of-intended effect

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8456-g3bb330022ce47a3e8966a9930f392e497c608f59
Author: Jason Merrill 
Date:   Thu Jul 9 15:11:12 2020 -0400

c++: [[no_unique_address]] fixes. [PR96105]

We were wrongly checking is_empty_class on the result of strip_array_types
rather than the actual field type.  We weren't considering the alignment of
the data member.  We needed to handle unions the same way as
layout_nonempty_base_or_field.

gcc/cp/ChangeLog:

PR c++/96105
PR c++/96052
PR c++/95976
* class.c (check_field_decls): An array of empty classes is not an
empty data member.
(layout_empty_base_or_field): Handle explicit alignment.
Fix union handling.

gcc/testsuite/ChangeLog:

PR c++/96105
PR c++/96052
PR c++/95976
* g++.dg/cpp2a/no_unique_address4.C: New test.
* g++.dg/cpp2a/no_unique_address5.C: New test.
* g++.dg/cpp2a/no_unique_address6.C: New test.

[Bug gcov-profile/96148] New: [11 regression] gcc.dg/tree-prof/crossmodule-indir-call-topn-[12].c UNRESOLVED

[ro at gcc dot gnu.org]

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

Bug ID: 96148
   Summary: [11 regression]
gcc.dg/tree-prof/crossmodule-indir-call-topn-[12].c
UNRESOLVED
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Between 20200525 (14cd049afcb992ac334b4a2ad7be42ee78fe31eb) and 20200526
(0981cf960d07752f9844a2f2799fbc85a7f1efd8), two tests started to regress
everywhere:

+UNRESOLVED: gcc.dg/tree-prof/crossmodule-indir-call-topn-1.c
scan-pgo-wpa-ipa-dump profile_estimate "2 (200.00%) speculations
produced."
+UNRESOLVED: gcc.dg/tree-prof/crossmodule-indir-call-topn-2.c
scan-pgo-wpa-ipa-dump profile_estimate "2 (200.00%) speculations
produced."

The log shows

gcc.dg/tree-prof/crossmodule-indir-call-topn-1.c: dump file does not exist
dump file: crossmodule-indir-call-topn-1.x02.wpa.profile_estimate

and indeed the generate step creates

-O2.wpa.073i.profile_estimate

(just like that, the filename is not included!) and the use step produces

-O2-crossmodule-indir-call-topn-1.gcda
-O2-crossmodule-indir-call-topn-1a.gcda

[Bug gcov-profile/96148] [11 regression] gcc.dg/tree-prof/crossmodule-indir-call-topn-[12].c UNRESOLVED

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug testsuite/96109] gcc.dg/vect/slp-47.c etc. FAIL

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org
 Target|sparc-sun-solaris2.11,  |sparc-sun-solaris2.11,
   |arm*-*-*,   |arm*-*-*,
   |ia64-suse-linux-gnu |ia64-suse-linux-gnu,
   ||aarch64*elf

--- Comment #4 from Christophe Lyon  ---
Also seen on aarch64-elf (aarch64-linux-gnu is OK)

[Bug tree-optimization/96133] [10 Regression] x86-64 gcc 10.1 using -O3 leads to wrong calculation since r10-1882-g831e688af50c5f77

[heckflosse67 at gmx dot de]

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

--- Comment #12 from Ingo Weyrich  ---
Thanks for fixing and kudos for your very fast response time!

[Bug target/96144] [11 Regression] ICE in extract_insn, at recog.c:2294 since r11-1970-gfab263ab0fc10ea0

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 11.

[Bug target/96144] [11 Regression] ICE in extract_insn, at recog.c:2294 since r11-1970-gfab263ab0fc10ea0

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2013-ga6645a826f58b68f68dff30e6e6e78542099d0cc
Author: H.J. Lu 
Date:   Thu Jul 9 14:56:48 2020 -0700

x86: Check TARGET_AVX512VL when enabling FMA

Check TARGET_AVX512VL when enabling FMA to avoid

gcc.target/i386/avx512er-vrsqrt28ps-3.c:25:1: error: unrecognizable insn:
(insn 29 28 30 6 (set (reg:V8SF 108)
(fma:V8SF (reg:V8SF 106)
(reg:V8SF 105)
(reg:V8SF 110)))

when TARGET_AVX512VL isn't enabled.

PR target/96144
* config/i386/i386-expand.c (ix86_emit_swsqrtsf): Check
TARGET_AVX512VL when enabling FMA.

[Bug c/96093] __MATHCALLX Error with ';' missing in header file

[daffra.claudio at gmail dot com]

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

--- Comment #2 from claudio daffra  ---
error disappear when i put   at top of include file , probably ...
FLAGS=-std=c11 -Wall  -Wextra -pedantic
LIBRARYS=-lm ...  link without header
boh .. can you close.


Il giorno mer 8 lug 2020 alle ore 23:44 pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> ha scritto:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96093
>
> Andrew Pinski  changed:
>
>What|Removed |Added
>
> 
>  Status|UNCONFIRMED |WAITING
>Keywords||diagnostic
>Last reconfirmed||2020-07-09
>  Ever confirmed|0   |1
>
> --- Comment #1 from Andrew Pinski  ---
> Can you attach the preprocessed source as requested by
> https://gcc.gnu.org/bugs.html ?
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug target/96144] [11 Regression] ICE in extract_insn, at recog.c:2294 since r11-1970-gfab263ab0fc10ea0

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-July/54
   ||9769.html
 CC|hjl at gcc dot gnu.org |

--- Comment #2 from H.J. Lu  ---
A patch was posted at

https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549769.html

[Bug tree-optimization/96146] VRP turns a terminating loop into an infinite loop

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-10
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Testing a patch.

[Bug tree-optimization/96133] [10 Regression] x86-64 gcc 10.1 using -O3 leads to wrong calculation since r10-1882-g831e688af50c5f77

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:8614106f121db118f9db260b9949883485d0bbf6

commit r10-8455-g8614106f121db118f9db260b9949883485d0bbf6
Author: Richard Biener 
Date:   Thu Jul 9 16:03:45 2020 +0200

fix constant folding from array CTORs

This fixes the case where we try to fold a read from an
array initalizer and happen to cross the boundary of
multiple CTORs which isn't really supported.  For the
interesting cases like the testcase we actually handle
the folding by encoding the whole initializer.

2020-07-10  Richard Biener  

PR tree-optimization/96133
* gimple-fold.c (fold_array_ctor_reference): Do not
recurse to folding a CTOR that does not fully cover the
asked for object.

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

(cherry picked from commit 6e41c27bf549d957eb399d39d7d0c213f8733351)

[Bug tree-optimization/96133] [10 Regression] x86-64 gcc 10.1 using -O3 leads to wrong calculation since r10-1882-g831e688af50c5f77

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/96146] VRP turns a terminating loop into an infinite loop

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Sorry, scratch that last message.  The optimisation is of course
correct in that case. ;-)

[Bug tree-optimization/96146] VRP turns a terminating loop into an infinite loop

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
FWIW, it doesn't look like this is specific to POLY_INT_CST.
A gimple reproducer shows a similar thing:

void __GIMPLE (ssa, startwith("vrp2"))
foo (volatile int *x)
{
  int i;

__BB(2):
  goto __BB3;

__BB(3):
  i_1 = __PHI (__BB2: 0, __BB4: i_2);
  *x = i_1;
  i_2 = i_1 + 1;
  if (i_2 != 2)
goto __BB4;
  else
goto __BB5;

__BB(4):
  goto __BB3;

__BB(5):
  return;
}

It works with a bound of 3 rather than 2.

[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl

[iii at linux dot ibm.com]

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

--- Comment #11 from Ilya Leoshkevich  ---
Sorry about that! I will have a look.

[Bug gcov-profile/96092] Should --coverage respect -ffile-prefix-map?

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Apparently we've got a patch in queue that does something similar:

+fprofile-prefix-path=
+Common·Joined·RejectNegative·Var(profile_prefix_path) 
+remove·prefix·from·absolute·path·before·manging·name·for·-fprofile-generate=·and·-fprofile-use=.

[Bug tree-optimization/96133] [10/11 Regression] x86-64 gcc 10.1 using -O3 leads to wrong calculation since r10-1882-g831e688af50c5f77

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1981-g6e41c27bf549d957eb399d39d7d0c213f8733351
Author: Richard Biener 
Date:   Thu Jul 9 16:03:45 2020 +0200

fix constant folding from array CTORs

This fixes the case where we try to fold a read from an
array initalizer and happen to cross the boundary of
multiple CTORs which isn't really supported.  For the
interesting cases like the testcase we actually handle
the folding by encoding the whole initializer.

2020-07-10  Richard Biener  

PR tree-optimization/96133
* gimple-fold.c (fold_array_ctor_reference): Do not
recurse to folding a CTOR that does not fully cover the
asked for object.

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

[Bug target/96144] [11 Regression] ICE in extract_insn, at recog.c:2294 since r11-1970-gfab263ab0fc10ea0

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
This shows in multiple testsuite fails on x86-64 as well.

FAIL: gcc.target/i386/avx512er-vrsqrt28ps-3.c (internal compiler error)
FAIL: gcc.target/i386/avx512er-vrsqrt28ps-3.c (test for excess errors)
UNRESOLVED: gcc.target/i386/avx512er-vrsqrt28ps-3.c compilation failed to
produce executable
FAIL: gcc.target/i386/avx512er-vrsqrt28ps-4.c (internal compiler error)
FAIL: gcc.target/i386/avx512er-vrsqrt28ps-4.c (test for excess errors)
UNRESOLVED: gcc.target/i386/avx512er-vrsqrt28ps-4.c scan-assembler-not
vrcp28ps[^\\n\\r]*zmm[0-9]+(?:\\n|[ t]+#)
UNRESOLVED: gcc.target/i386/avx512er-vrsqrt28ps-4.c scan-assembler-times
vrsqrt28ps[^\\n\\r]*zmm[0-9]+(?:\\n|[ t]+#) 1
FAIL: gcc.target/i386/avx512er-vrsqrt28ps-5.c (internal compiler error)
FAIL: gcc.target/i386/avx512er-vrsqrt28ps-5.c (test for excess errors)
UNRESOLVED: gcc.target/i386/avx512er-vrsqrt28ps-5.c compilation failed to
produce executable
FAIL: gcc.target/i386/avx512er-vrsqrt28ps-6.c (internal compiler error)
FAIL: gcc.target/i386/avx512er-vrsqrt28ps-6.c (test for excess errors)
UNRESOLVED: gcc.target/i386/avx512er-vrsqrt28ps-6.c scan-assembler-times
vrcp28ps[^\\n\\r]*zmm[0-9]+(?:\\n|[ t]+#) 1
UNRESOLVED: gcc.target/i386/avx512er-vrsqrt28ps-6.c scan-assembler-times
vrsqrt28ps[^\\n\\r]*zmm[0-9]+(?:\\n|[ t]+#) 1

[Bug c++/96145] Weird output in compiling a typedef union as a function return type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||rejects-valid
   Last reconfirmed||2020-07-10
 Ever confirmed|0   |1

[Bug tree-optimization/96146] VRP turns a terminating loop into an infinite loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---

i_1 = ASSERT_EXPR ;
Intersecting
  int [-INF, 1]  EQUIVALENCES: { i_7 } (1 elements)

so somehow we derive from i_7 != POLY_INT_CST [2, 2] that i_7 must
be [-INF, 1] - that looks wrong?

This goes via extract_range_for_var_from_comparison_expr and likely
compare_values goes off in

  if (limit_vr
  && limit_vr->kind () == VR_RANGE
  && compare_values (limit_vr->min (), limit_vr->max ()) == 0)
{
  min = limit_vr->min ();
  max = limit_vr->max ();
}

where min/max are then POLY_INT_CST [2, 2] and the anti-range we build
from that is canonicalized in odd ways.

I think VRP all over the place assumes integer typed constants are
INTEGER_CSTs so maybe sth else is off with POLY_INT_CSTs ...

CCing VRP people.

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

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  ---
Created attachment 48856
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48856=edit
32-bit sparc-sun-solaris2.11 slp-45.c.163t.vect

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

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

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

[ro at gcc dot gnu.org]

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

Bug ID: 96147
   Summary: [11 regression] gcc.dg/vect/slp-43.c etc. FAIL
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.11

Created attachment 48855
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48855=edit
32-bit sparc-sun-solaris2.11 slp-43.c.163t.vect

Between 20200708 (30fdaead5b7880c4e9f140618e26ad1c545642d5) and 20200709
(fab263ab0fc10ea08409b80afa7e8569438b8d28), a couple of testcases regressed on
Solaris/SPARC, both 32 and 64-bit:

+XPASS: gcc.dg/vect/bb-slp-32.c -flto -ffat-lto-objects  scan-tree-dump slp2
"vectorization is not profitable"
+XPASS: gcc.dg/vect/bb-slp-32.c scan-tree-dump slp2 "vectorization is not
profitable"
+XPASS: gcc.dg/vect/bb-slp-9.c -flto -ffat-lto-objects  scan-tree-dump-times
slp2 "basic block vectorized" 1
+XPASS: gcc.dg/vect/bb-slp-9.c scan-tree-dump-times slp2 "basic block
vectorized" 1
+FAIL: gcc.dg/vect/slp-43.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorized 1 loops" 2
+FAIL: gcc.dg/vect/slp-43.c scan-tree-dump-times vect "vectorized 1 loops" 2
+FAIL: gcc.dg/vect/slp-45.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorized 1 loops" 13
+FAIL: gcc.dg/vect/slp-45.c scan-tree-dump-times vect "vectorized 1 loops" 13

There's a similar regression reported on ia64-suse-linux-gnu.

Dumps for the FAILs attached.