[Bug ada/98134] New: [11 Regression] bootstrap error building gnat on mips64el-linux-gnu

[doko at debian dot org via Gcc-bugs]

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

Bug ID: 98134
   Summary: [11 Regression] bootstrap error building gnat on
mips64el-linux-gnu
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with trunk 20201203 on mips64el-linux-gnu

/<>/build/./gcc/xgcc -B/<>/build/./gcc/
-B/usr/lib/gcc-snapshot/mips64el-l
inux-gnuabi64/bin/ -B/usr/lib/gcc-snapshot/mips64el-linux-gnuabi64/lib/
-isystem /usr/lib/gcc-snapsh
ot/mips64el-linux-gnuabi64/include -isystem
/usr/lib/gcc-snapshot/mips64el-linux-gnuabi64/sys-includ
e   -fchecking=1 -c -g -O2  -fPIC  -W -Wall -gnatpg -nostdinc   a-nallfl.ads -o
a-nallfl.o
a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:48:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:48:13: warning: profile of "Sin" doesn't match the builtin it
binds
a-nallfl.ads:51:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:51:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:51:13: warning: profile of "Cos" doesn't match the builtin it
binds
a-nallfl.ads:54:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:54:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:54:13: warning: profile of "Tan" doesn't match the builtin it
binds
a-nallfl.ads:57:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:57:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:57:13: warning: profile of "Exp" doesn't match the builtin it
binds
a-nallfl.ads:60:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:60:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:60:13: warning: profile of "Sqrt" doesn't match the builtin it
binds
a-nallfl.ads:63:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:63:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:63:13: warning: profile of "Log" doesn't match the builtin it
binds
a-nallfl.ads:66:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:66:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:66:13: warning: profile of "Acos" doesn't match the builtin it
binds
a-nallfl.ads:69:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:69:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:69:13: warning: profile of "Asin" doesn't match the builtin it
binds
a-nallfl.ads:72:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:72:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:72:13: warning: profile of "Atan" doesn't match the builtin it
binds
a-nallfl.ads:75:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:75:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:75:13: warning: profile of "Sinh" doesn't match the builtin it
binds
a-nallfl.ads:78:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:78:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:78:13: warning: profile of "Cosh" doesn't match the builtin it
binds
a-nallfl.ads:81:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:81:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:81:13: warning: profile of "Tanh" doesn't match the builtin it
binds
a-nallfl.ads:84:13: warning: intrinsic binding type mismatch on return value
a-nallfl.ads:84:13: warning: intrinsic binding type mismatch on argument 1
a-nallfl.ads:84:13: warning: profile of "Pow" doesn't match the builtin it
binds
make[9]: *** [../gcc-interface/Makefile:302: a-nallfl.o] Error 1
make[9]: Leaving directory '/<>/build/gcc/ada/rts'
make[8]: *** [gcc-interface/Makefile:620: gnatlib] Error 2
make[8]: Leaving directory '/<>/build/gcc/ada'
make[7]: *** [gcc-interface/Makefile:655: gnatlib-shared-default] Error 2
make[7]: Leaving directory '/<>/build/gcc/ada'
make[4]: *** [Makefile:107: gnatlib-shared] Error 2
make[4]: Leaving directory
'/<>/build/mips64el-linux-gnuabi64/libada'
make[3]: *** [Makefile:22363: all-target-libada] Error 2

gcc is configured with

 --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++
 --prefix=/usr/lib/gcc-snapshot
 --with-gcc-major-version-only
 --program-prefix=
 --enable-shared
 --enable-linker-build-id
 --disable-nls
 --enable-clocale=gnu
 --enable-libstdcxx-debug
 --enable-libstdcxx-time=yes
 --with-default-libstdcxx-abi=new
 --enable-gnu-unique-object
 --disable-libitm
 --disable-libsanitizer
 --disable-libquadmath
 --disable-li

[Bug target/98135] New: arm: Inconsistent automatic selection of FPU variant from -mcpu= and -march= options

[sebastian.huber--- via Gcc-bugs]

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

Bug ID: 98135
   Summary: arm: Inconsistent automatic selection of FPU variant
from -mcpu= and -march= options
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

Since GCC 8, the FPU variant is derived from -mcpu= and -march= options. This
works well for the code generation by the compiler, but it doesn't work well
for the assembler if -mfpu=auto is not specified on the command line. For
example:

arm-rtems6-gcc -save-temps -c test.c -mthumb -march=armv8-r+crc+simd
-mfloat-abi=hard -wrapper echo
/tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/cc1 -E -quiet -D__USES_INITFINI__
test.c -mthumb -mfloat-abi=hard -march=armv8-r+crc+simd -fpch-preprocess -o
test.i
/tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/cc1 -fpreprocessed test.i -quiet
-dumpbase test.c -mthumb -mfloat-abi=hard -march=armv8-r+crc+simd -auxbase test
-o test.s
/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/as
-march=armv8-r+crc -mfloat-abi=hard -meabi=5 -o test.o test.s

The assembler is called without the "+simd".

It is discarded by arm_rewrite_selected_arch() probably because

(gdb) p *entry
$16 = {name = 0x4c1acc "simd", remove = false, alias = false, isa_bits =
{isa_bit_fp_d32, isa_bit_fp_dbl, isa_bit_fp16conv, isa_bit_fpv5, isa_bit_vfpv2,
isa_bit_vfpv3, isa_bit_vfpv4, isa_bit_neon, isa_nobit }}

and

#define ISA_ALL_FPU_INTERNAL \
  isa_bit_fp16conv, \
  isa_bit_crypto, \
  isa_bit_vfpv2, \
  isa_bit_vfpv3, \
  isa_bit_vfpv4, \
  isa_bit_fpv5, \
  isa_bit_neon, \
  isa_bit_fp_dbl, \
  isa_bit_fp_d32

So

(gdb) p/x fpu_bits
$17 = {m_bitmap = 0x778e60}
(gdb) p/x opt_bits
$18 = {m_bitmap = 0x778e20}

if (!bitmap_subset_p (opt_bits, fpu_bits))
optlist.push_back (entry->name);

doesn't push back entry->name.

The assembler doesn't complain about a -march=armv8-r+crc+simd and it makes the
assembler error go away. Probably older assembler versions doesn't support it.

What fixes the problem is adding the "-mfpu=auto" option. For example:

arm-rtems6-gcc -save-temps -c test.c -mthumb -march=armv8-a+crc+simd
-mfloat-abi=hard -mfpu=auto -wrapper echo
/tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/cc1 -E -quiet -D__USES_INITFINI__
test.c -mthumb -mfloat-abi=hard -mfpu=auto -march=armv8-a+crc+simd
-fpch-preprocess -o test.i
/tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/cc1 -fpreprocessed test.i -quiet
-dumpbase test.c -mthumb -mfloat-abi=hard -mfpu=auto -march=armv8-a+crc+simd
-auxbase test -o test.s
/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/as
-mfpu=neon-fp-armv8 -march=armv8-a+crc -mfloat-abi=hard -meabi=5 -o test.o
test.s

This is not really nice since the -mfpu=auto option seems to have no effect on
the code generation (compiler):

arm-rtems6-gcc -save-temps -E -P -v -dD test.c -mthumb -march=armv8-a+crc+simd
-mfloat-abi=hard -mfpu=auto > auto.txt 2>&1

arm-rtems6-gcc -save-temps -E -P -v -dD test.c -mthumb -march=armv8-a+crc+simd
-mfloat-abi=hard  > noauto.txt 2>&1

diff -u auto.txt noauto.txt
--- auto.txt2020-12-03 15:18:46.466141382 +0100
+++ noauto.txt  2020-12-03 15:18:52.282185710 +0100
@@ -5,8 +5,8 @@
 Thread model: rtems
 Supported LTO compression algorithms: zlib
 gcc version 10.2.1 20201203 [releases/gcc-10 revision
75a5af680a1:72d226ca97d:3444cb38a4d8df2c198ae5b4bdc747ff0c42a940] (GCC)
-COLLECT_GCC_OPTIONS='-save-temps' '-E' '-P' '-v' '-dD' '-mthumb'
'-mfloat-abi=hard' '-mfpu=auto' '-march=armv8-a+crc+simd'
- /tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/cc1 -E -quiet -v -P
-D__USES_INITFINI__ test.c -mthumb -mfloat-abi=hard -mfpu=auto
-march=armv8-a+crc+simd -fpch-preprocess -dD
+COLLECT_GCC_OPTIONS='-save-temps' '-E' '-P' '-v' '-dD' '-mthumb'
'-mfloat-abi=hard' '-march=armv8-a+crc+simd'
+ /tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/cc1 -E -quiet -v -P
-D__USES_INITFINI__ test.c -mthumb -mfloat-abi=hard -march=armv8-a+crc+simd
-fpch-preprocess -dD
 ignoring nonexistent directory
"/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/sys-include"
 #include "..." search starts here:
 #include <...> search starts here:
@@ -466,4 +466,4 @@
 #define __USES_INITFINI__ 1

COMPILER_PATH=/tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/:/tmp/sh/rtems/6/lib/gcc/arm-rtems6/10.2.1/:/tmp/sh/rtems/6/lib/gcc/arm-rtems6/:/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/10.2.1/:/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/:/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/

LIBRARY_PATH=/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/10.2.1/:/tmp/sh/rtems/6/lib64/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/lib/
-COLLECT_GCC_OPTIONS='-save-temps' '-E' '-P' '-v' '-dD' '-mthumb'
'-mfloat-abi=hard' '-mfpu=auto' '-march=armv8-a+crc+simd'
+COLLECT_GCC_OPTIONS='-save-temps' '-E' '-P' '-v' '-dD' 

[Bug ada/98134] [11 Regression] bootstrap error building gnat on mips64el-linux-gnu

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Eric Botcazou  ---
.

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

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #40 from Eric Botcazou  ---
*** Bug 98134 has been marked as a duplicate of this bug. ***

[Bug libstdc++/93121] std::bit_cast missing

[klaus.doldinger64 at googlemail dot com via Gcc-bugs]

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

--- Comment #12 from Wilhelm M  ---
The following does not work:

# include 
# include 
# include 
# include 
# include 

using to_t   = std::array;

int main() {
constexpr std::byte from1[4]{};
constexpr auto v1 = std::bit_cast(from1);
return v1[0];
}

gives:

/usr/local/include/c++/11.0.0/bit: In function 'int main()':
/home/lmeier/Projekte/wmucpp/host/test88.cc:11:50:   in 'constexpr' expansion
of 'std::bit_cast, std::byte [4]>(from1)'
/usr/local/include/c++/11.0.0/bit:60:33: sorry, unimplemented:
'__builtin_bit_cast' cannot be constant evaluated because the argument cannot
be encoded
60 |   return __builtin_bit_cast(_To, __from);
| ^~~

[Bug c++/96675] [10 Regression] tautological-compare warning emitted for NTTP bitwise comparison

[giorgio.audrito at gmail dot com via Gcc-bugs]

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

Giorgio Audrito  changed:

   What|Removed |Added

 CC||giorgio.audrito at gmail dot 
com

--- Comment #4 from Giorgio Audrito  ---
I am having a similar problem (10.2.0) with a situation like this:

template 
using foo = std::integral_constant;

foo<1> ... foo<0>...

I read this issue will be fixed in 10.3, I guess my situation will be fixed
also?

[Bug tree-optimization/98123] if-to-switch tests fail on arm

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

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #4 from Christophe Lyon  ---
Sorry I didn't reply earlier because I didn't have the most recent trunk
results yet.

What revision should have fixed them?
With r11-5718 (g:4a3b9f48c3743c6737acdc93074d058c1603be2a) I still see:
FAIL: gcc.dg/tree-ssa/if-to-switch-4.c scan-tree-dump-not iftoswitch "Condition
chain"
FAIL: gcc.dg/tree-ssa/if-to-switch-6.c scan-tree-dump-not iftoswitch "Condition
chain"
FAIL: gcc.dg/tree-ssa/if-to-switch-8.c scan-tree-dump-not iftoswitch "Condition
chain"

[Bug c++/98136] New: [aarch64] Internal compiler error with large classes and virtual methods

[dark141 at gmail dot com via Gcc-bugs]

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

Bug ID: 98136
   Summary: [aarch64] Internal compiler error with large classes
and virtual methods
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dark141 at gmail dot com
  Target Milestone: ---

Created attachment 49676
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49676&action=edit
Test case

Combining virtual methods and large (>16Mb) structures results in an internal
compiler error:

$ aarch64-none-linux-gnu-g++ -o test t.cpp
t.cpp: In member function ‘virtual void
Deriv::_ZThn33554440_N5Deriv9AddInCallEv()’:
t.cpp:24:1: internal compiler error: in final_scan_insn_1, at final.c:3079
   24 | }
  | ^
0x90d6cd final_scan_insn_1
   
/tmp/dgboter/bbs/rhev-vm2--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-linux-gnu/build/src/gcc/gcc/final.c:3079
0x90d88b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
   
/tmp/dgboter/bbs/rhev-vm2--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-linux-gnu/build/src/gcc/gcc/final.c:3153
0x90db65 final_1
   
/tmp/dgboter/bbs/rhev-vm2--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-linux-gnu/build/src/gcc/gcc/final.c:2021
0xe8a720 aarch64_output_mi_thunk
   
/tmp/dgboter/bbs/rhev-vm2--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-linux-gnu/build/src/gcc/gcc/config/aarch64/aarch64.c:6050
0x8211d8 cgraph_node::expand_thunk(bool, bool)
   
/tmp/dgboter/bbs/rhev-vm2--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-linux-gnu/build/src/gcc/gcc/cgraphunit.c:1834
0x82209a cgraph_node::assemble_thunks_and_aliases()
   
/tmp/dgboter/bbs/rhev-vm2--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-linux-gnu/build/src/gcc/gcc/cgraphunit.c:2126
0x82206b cgraph_node::assemble_thunks_and_aliases()
   
/tmp/dgboter/bbs/rhev-vm2--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-linux-gnu/build/src/gcc/gcc/cgraphunit.c:2144
0x822233 cgraph_node::expand()
   
/tmp/dgboter/bbs/rhev-vm2--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-linux-gnu/build/src/gcc/gcc/cgraphunit.c:2263
0x82366b output_in_order
   
/tmp/dgboter/bbs/rhev-vm2--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-linux-gnu/build/src/gcc/gcc/cgraphunit.c:2442
0x82366b symbol_table::compile()
   
/tmp/dgboter/bbs/rhev-vm2--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-linux-gnu/build/src/gcc/gcc/cgraphunit.c:2686
0x8251e4 symbol_table::finalize_compilation_unit()
   
/tmp/dgboter/bbs/rhev-vm2--rhe6x86_64/buildbot/rhe6x86_64--aarch64-none-linux-gnu/build/src/gcc/gcc/cgraphunit.c:2865
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 

Using the ARM official 9.2 build. Also present in 10.2

[Bug testsuite/98123] if-to-switch tests fail on arm

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

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

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

https://gcc.gnu.org/g:485b40a5270cf50a7304a9e5cb8aff96bfa3d901

commit r11-5741-g485b40a5270cf50a7304a9e5cb8aff96bfa3d901
Author: Martin Liska 
Date:   Fri Dec 4 10:43:51 2020 +0100

testsuite: use param for if-to-switch tests

gcc/testsuite/ChangeLog:

PR testsuite/98123
* gcc.dg/tree-ssa/if-to-switch-4.c: Add param to make the test
stable on all architectures.
* gcc.dg/tree-ssa/if-to-switch-6.c: Likewise.
* gcc.dg/tree-ssa/if-to-switch-8.c: Likewise.

[Bug testsuite/98123] if-to-switch tests fail on arm

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Should be fixed now.

[Bug tree-optimization/98137] New: Could use SLP to vectorize if split_constant_offset were smarter

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

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

Bug ID: 98137
   Summary: Could use SLP to vectorize if split_constant_offset
were smarter
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

void
gemm_m10_n9_k17_ldA20_ldB20_ldC10_beta0_alignedA1_alignedC1_pfsigonly(const
double* __restrict__ A, const double* __restrict__ B, double* __restrict__ C,
const double* A_prefetch, const double* B_prefetch, const double* C_prefetch) {

  unsigned int l_m = 0;
  unsigned int l_n = 0;
  unsigned int l_k = 0;

  for ( l_n = 0; l_n < 9; l_n++ ) {
for ( l_m = 0; l_m < 10; l_m++ ) { C[(l_n*10)+l_m] = 0.0; }

for ( l_k = 0; l_k < 17; l_k++ ) {
  for ( l_m = 0; l_m < 10; l_m++ ) {
C[(l_n*10)+l_m] += A[(l_k*20)+l_m] * B[(l_n*20)+l_k];
  }
}
  }
}

is nicely vectorized with BB SLP when you make l_{m,n,k} signed but when
unsigned as above then split_constant_offset gives up when seeing

C + ((unsigned long)(_286 + 1) * 8)

but we even have nice range-info:

  # RANGE [0, 80] NONZERO 126
  _286 = l_n_189 * 10;
  # RANGE [0, 80] NONZERO 126
  _288 = (long unsigned int) _286;
  # RANGE [0, 640] NONZERO 1008
  _289 = _288 * 8;
  # PT = null { D.2428 } (nonlocal, restrict)
  _290 = C_37(D) + _289;

^^ C + ((unsigned long)(_286) * 8)

  # RANGE [1, 81] NONZERO 127
  _296 = _286 + 1;
  # RANGE [1, 81] NONZERO 127
  _297 = (long unsigned int) _296;
  # RANGE [8, 648] NONZERO 1016
  _298 = _297 * 8;
  # PT = { D.2428 } (nonlocal, restrict)
  _299 = C_37(D) + _298;

^^ C + ((unsigned long)(_286 + 1) * 8

giving up means DR group analysis doesn't relate them and we do not consider
SLP vectorization.

[Bug target/98136] [aarch64] Internal compiler error with large classes and virtual methods

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-12-04

--- Comment #1 from Martin Liška  ---
Confirmed, apparently, GCC 7 is fine.
I'm bisecting that right now.

[Bug target/98136] [8/9/10/11 Regression] [aarch64] Internal compiler error with large classes and virtual methods

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
Summary|[aarch64] Internal compiler |[8/9/10/11 Regression]
   |error with large classes|[aarch64] Internal compiler
   |and virtual methods |error with large classes
   ||and virtual methods

[Bug tree-optimization/98137] Could use SLP to vectorize if split_constant_offset were smarter

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2020-12-04
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Ah, so the issue is that

/* Split the unconverted operand and try to prove that
   wrapping isn't a problem.  */
tree tmp_var, tmp_off;
split_constant_offset (op0, &tmp_var, &tmp_off, cache, limit);

/* See whether we have an SSA_NAME whose range is known
   to be [A, B].  */
if (TREE_CODE (tmp_var) != SSA_NAME)
  return false;

we end up with tmp_var as MULT_EXPR (l_n_189 * 10).  We can fix that by
retaining the original code when splitting the constant offset returns zero.
While this makes us match up (_286 + 1) * 8 and (_286 + 2) * 8 it fails
to catch (_286 + 0) * 8 because that now is no longer expanded.

But we can use determine_value_range instead of get_value_range to also handle
expression trees.  That fixes the testcase.

[Bug tree-optimization/98137] Could use SLP to vectorize if split_constant_offset were smarter

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

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

--- Comment #2 from Richard Biener  ---
Created attachment 49677
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49677&action=edit
patch

I am testing the attached simple patch.

[Bug tree-optimization/96075] [8 Regression] bogus alignment for negative step grouped access

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

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

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

https://gcc.gnu.org/g:0f50805bb3b0924bab94bd85203370703af50f26

commit r10-9120-g0f50805bb3b0924bab94bd85203370703af50f26
Author: Richard Biener 
Date:   Fri Dec 4 11:39:44 2020 +0100

tree-optimization/96075 - adjust testcase

This adds an XFAIL when load-lanes can be used.

2020-12-04  Richard Biener  

PR tree-optimization/96075
* gcc.dg/vect/slp-46.c: Add XFAIL for load-lanes.

[Bug tree-optimization/96075] [8 Regression] bogus alignment for negative step grouped access

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

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

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

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

commit r9-9098-gd910ca0493455ffa84d4d934957cda1cb1588a25
Author: Richard Biener 
Date:   Fri Dec 4 11:39:44 2020 +0100

tree-optimization/96075 - adjust testcase

This adds an XFAIL when load-lanes can be used.

2020-12-04  Richard Biener  

PR tree-optimization/96075
* gcc.dg/vect/slp-46.c: Add XFAIL for load-lanes.

(cherry picked from commit 0f50805bb3b0924bab94bd85203370703af50f26)

[Bug libfortran/98129] Failure on reading big chunk of /dev/urandom

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

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-04

--- Comment #1 from Dominique d'Humieres  ---
WORKSFORME on Darwin even Sith n=10**9 (7s).

[Bug libstdc++/93121] std::bit_cast missing

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

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

--- Comment #13 from Jakub Jelinek  ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561119.html

[Bug tree-optimization/98138] New: BB vect fail to SLP one case

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

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

Bug ID: 98138
   Summary: BB vect fail to SLP one case
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linkw at gcc dot gnu.org
  Target Milestone: ---

Test case:

  extern void test(unsigned int t[4][4]);

  void foo(unsigned char *p1, int i1, unsigned char *p2, int i2)
  {
unsigned int tmp[4][4];
unsigned int a0, a1, a2, a3;

for (int i = 0; i < 4; i++, p1 += i1, p2 += i2) {
  a0 = (p1[0] - p2[0]) + ((p1[4] - p2[4]) << 16);
  a1 = (p1[1] - p2[1]) + ((p1[5] - p2[5]) << 16);
  a2 = (p1[2] - p2[2]) + ((p1[6] - p2[6]) << 16);
  a3 = (p1[3] - p2[3]) + ((p1[7] - p2[7]) << 16);

  int t0 = a0 + a1;
  int t1 = a0 - a1;
  int t2 = a2 + a3;
  int t3 = a2 - a3;

  tmp[i][0] = t0 + t2;
  tmp[i][2] = t0 - t2;
  tmp[i][1] = t1 + t3;
  tmp[i][3] = t1 - t3;
}
test(tmp);
  }

The expected code on ppc64le can look like:

  // p1 byte 0 to byte 7 
  d1_0_7 = load_dword(p1)
  // p1+i1 b0 to b7, rename it as 8 to 15   
  d1_8_15 = load_dword(p1 + i1)
  d1_16_23 = load_dword(p1 + 2*i1) 
  d1_24_31 = load_dword(p1 + 3*i1)

  V_d1_0_15 = construct_vec(d1_0_7,d1_8_15) // vector char
  V_d1_16_31 = construct_vec(d1_16_23,d1_24_31)
  V_d1_0_3_all = vperm(V_d1_0_15, V_d1_0_15, 
  {0 8 16 24 1 9 17 25 2 10 18 26 3 11 19 27})
  V_d1_4_7_all = vperm(V_d1_0_15, V_d1_0_15, 
  {4 12 20 28 5 13 21 29 6 14 22 30 7 15 23 31})

  // Do the similar for p2 with i2, get V_d2_0_3_all, V_d2_4_7_all

  // Do the subtraction together (all 4x4 bytes)
  V_sub1 = V_d1_0_3_all - V_d2_0_3_all
  V_sub2 = V_d1_4_7_all - V_d2_4_7_all

  // Do some unpack and get the promoted vector int
  V_a0_tmp = vec_promote(V_sub2, {0 1 2 3}) // vector int {b4 b12 b20 b28}
  V_a0_1 = V_a0_tmp << 16
  V_a0_0 = vec_promote(V_sub1, {0 1 2 3}).  // vector int {b0 b8 b16 b24}
  // vector int {a0_iter0, a0_iter1, a0_iter2, a0_iter3}
  V_a0 = V_a0_0 + V_a0_1

  // Get the similar for V_a1, V_a2, V_a3

  // Compute t0/t1/t2/t3
  // vector int {t0_iter0, t0_iter1, t0_iter2, t0_iter3}
  V_t0 = V_a0 + V_a1  
  V_t1 = V_a0 - V_a1
  V_t2 = V_a2 + V_a3
  V_t3 = V_a2 - V_a3

  // Compute tmps
  // vector int {tmp[0][0], tmp[1][0], tmp[2][0], tmp[3][0]}
  V_tmp0 = V_t0 + V_t2
  V_tmp2 = V_t0 - V_t2
  V_tmp1 = V_t1 + V_t3
  V_tmp3 = V_t1 - V_t3

  // Final construct the {tmp[0][0], tmp[0][1], tmp[0][2], tmp[0][3]} ...
  // with six further permutation on V_tmp0/V_tmp1/V_tmp2/V_tmp3

[Bug tree-optimization/98138] BB vect fail to SLP one case

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

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

--- Comment #1 from Kewen Lin  ---
Similar case is x264_pixel_satd_8x4 in x264
https://github.com/mirror/x264/blob/4121277b40a667665d4eea1726aefdc55d12d110/common/pixel.c#L288

[Bug c++/96675] [10 Regression] tautological-compare warning emitted for NTTP bitwise comparison

[giorgio.audrito at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Giorgio Audrito  ---
I add that a very similar problem happens with -Wtype-limits, I found this
minimal example:

template 
struct foo {
bool bar(unsigned y) {
return y < x;
}
};

int main() {
return foo<0>{}.bar(10);
}

I don't know if that has been addressed as well (should it be a separate bug
report?).

[Bug target/98100] ICE in expand_debug_locations, at cfgexpand.c:5610

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

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

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

https://gcc.gnu.org/g:704ccefb576dcf30b27a4b9bdacb6e15902f5307

commit r11-5743-g704ccefb576dcf30b27a4b9bdacb6e15902f5307
Author: Jakub Jelinek 
Date:   Fri Dec 4 12:18:21 2020 +0100

debug: Fix another vector DECL_MODE ICE [PR98100]

The PR88587 fix changes DECL_MODE of vars with vector type during
inlining/cloning
when the vars are copied, so that their DECL_MODE matches their TYPE_MODE
in
the new function.  Unfortunately, the following testcase still ICEs, the
var
isn't really used in the new function and so it isn't copied, but becomes
just a nonlocalized var.  So we can't adjust its DECL_MODE because it
appears in multiple functions and needs different modes in between them.
The following patch changes the DEBUG_INSN creation to use TYPE_MODE
instead
of DECL_MODE for vars with vector types.

2020-12-04  Jakub Jelinek  

PR target/98100
* cfgexpand.c (expand_gimple_basic_block): For vars with
vector type, use TYPE_MODE rather than DECL_MODE.

* gcc.target/i386/pr98100.c: New test.

[Bug target/98100] ICE in expand_debug_locations, at cfgexpand.c:5610

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

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

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk (so far).

[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
So, shouldn't the code match what the comment says?
  /* If the call is to a replaceable operator delete and results
 from a delete expression as opposed to a direct call to
 such operator, then we can treat it as free.  */
There is no check that it is a replaceable operator, that would mean
testing also
  && DECL_IS_REPLACEABLE_OPERATOR (fndecl)

[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79

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

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

--- Comment #4 from Jakub Jelinek  ---
That would mean:

--- gcc/testsuite/g++.dg/opt/pr98130.C.jj   2020-12-04 12:30:11.510988404
+0100
+++ gcc/testsuite/g++.dg/opt/pr98130.C  2020-12-04 12:33:05.663028984 +0100
@@ -0,0 +1,25 @@
+// PR c++/98130
+// { dg-do run { target c++11 } }
+// { dg-options "-O2" }
+
+#include 
+
+typedef int *T;
+
+static unsigned char storage[sizeof (T)] alignas (T);
+static T *p = (T *) storage;
+
+static inline __attribute__((__always_inline__)) void
+foo (T value)
+{
+  new (p) T(value);
+}
+
+int
+main ()
+{
+  int a;
+  foo (&a);
+  if (!*p)
+__builtin_abort ();
+}
--- gcc/gimple.c.jj 2020-11-26 01:14:47.528081989 +0100
+++ gcc/gimple.c2020-12-04 12:34:44.865911907 +0100
@@ -1514,11 +1514,12 @@ gimple_call_fnspec (const gcall *stmt)
  such operator, then we can treat it as free.  */
   if (fndecl
   && DECL_IS_OPERATOR_DELETE_P (fndecl)
+  && DECL_IS_REPLACEABLE_OPERATOR (fndecl)
   && gimple_call_from_new_or_delete (stmt))
 return ".co ";
   /* Similarly operator new can be treated as malloc.  */
   if (fndecl
-  && DECL_IS_OPERATOR_NEW_P (fndecl)
+  && DECL_IS_REPLACEABLE_OPERATOR_NEW_P (fndecl)
   && gimple_call_from_new_or_delete (stmt))
 return "mC";
   return "";

but the testcase is miscompiled even with that change, and we don't really
return ".co " nor "mC" on the testcase.

[Bug target/98136] [8/9/10/11 Regression] [aarch64] Internal compiler error with large classes and virtual methods since r8-5967-gf5470a77425a54efebfe1732488c40f05ef176d0

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9/10/11 Regression]
   |[aarch64] Internal compiler |[aarch64] Internal compiler
   |error with large classes|error with large classes
   |and virtual methods |and virtual methods since
   ||r8-5967-gf5470a77425a54efeb
   ||fe1732488c40f05ef176d0
 CC||alan.hayward at arm dot com,
   ||david.sherwood at arm dot com,
   ||rsandifo at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r8-5967-gf5470a77425a54efebfe1732488c40f05ef176d0.

[Bug target/98139] New: varasm.c fails to compile on AIX 7.2: -Werror=unused-variable

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

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

Bug ID: 98139
   Summary: varasm.c fails to compile on AIX 7.2:
-Werror=unused-variable
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: dje at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc-ibm-aix7.2.4.0
Target: powerpc-ibm-aix7.2.4.0
 Build: powerpc-ibm-aix7.2.4.0

I've just tried a bootstrap of current master with a self-compiled GCC 8.4.0 on
gcc119 in the cfarm. The build failed compiling varasm.c in stage2:

/home/ro/gcc/src/gcc-master/gcc/varasm.c: In function 'void
output_constant_pool
_contents(rtx_constant_pool*)':
/home/ro/gcc/src/gcc-master/gcc/varasm.c:4254:21: error: unused variable 'name'
[-Werror=unused-variable]
 4254 | const char *name = targetm.strip_name_encoding (XSTR
(desc->sym,
 0));
  |  

I've used the attached patch to finish the build.  It needs at last proper
formatting and wrapping the args in parens.

However, I wonder why there's no other report of this issue...

[Bug target/98136] [8/9/10/11 Regression] [aarch64] Internal compiler error with large classes and virtual methods since r8-5967-gf5470a77425a54efebfe1732488c40f05ef176d0

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/98139] varasm.c fails to compile on AIX 7.2: -Werror=unused-variable

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

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

--- Comment #1 from Rainer Orth  ---
Created attachment 49678
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49678&action=edit
Hacky patch.

[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #5 from Jan Hubicka  ---
> So, shouldn't the code match what the comment says?
>   /* If the call is to a replaceable operator delete and results
>  from a delete expression as opposed to a direct call to
>  such operator, then we can treat it as free.  */
> There is no check that it is a replaceable operator, that would mean
> testing also
>   && DECL_IS_REPLACEABLE_OPERATOR (fndecl)

I copied the test from find_func_aliases_for_call (including the
comment).  I will look into what is happening here.

Honza

[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors

[amodra at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Alan Modra  ---
(In reply to Alan Modra from comment #5)
> So the "o" flag symbol is one in the .opd section, rather than what would be
> correct here, .L._Z3foov.

Actually, that breakage happened recently with commit 694d4a6d0c4.  ie. it
looks like powerpc64 ELFv1 was broken by HJ's patch.  I tend to care more about
powerpc64 ELFv2, ie powerpc64le, which was broken prior to that patch.

[Bug c++/98122] [10/11 Regression] Accessing union member through pointer-to-member is not a constant expression

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
--- gcc/cp/constexpr.c.jj   2020-12-03 15:43:00.491620290 +0100
+++ gcc/cp/constexpr.c  2020-12-04 13:02:06.874418746 +0100
@@ -4679,7 +4679,8 @@ cxx_fold_indirect_ref_1 (location_t loc,
}
 }
   /* ((foo *)&struct_with_foo_field)[x] => COMPONENT_REF */
-  else if (TREE_CODE (optype) == RECORD_TYPE)
+  else if (TREE_CODE (optype) == RECORD_TYPE
+  || TREE_CODE (optype) == UNION_TYPE)
 {
   for (tree field = TYPE_FIELDS (optype);
   field; field = DECL_CHAIN (field))
would fix this, but wonder if for unions we don't need to take into account the
currently active member.

In:
union U { int a; char b; };

constexpr bool
foo ()
{
  U f { .b = 42 };
  constexpr auto m = &U::a;
  return (f.*m) == 42;
}

static_assert (foo (), "");
we even with the patch properly reject it:
pr98122-2.C:11:20: error: non-constant condition for static assertion
   11 | static_assert (foo (), "");
  |^~
pr98122-2.C:11:20:   in ‘constexpr’ expansion of ‘foo()’
pr98122-2.C:11:20: error: accessing ‘U::a’ member instead of initialized ‘U::b’
member in constant expression

But:
union U { int a; int b; };

constexpr bool
foo ()
{
  U f { .b = 42 };
  constexpr auto m = &U::b;
  return (f.*m) == 42;
}

static_assert (foo (), "");
is rejected too and I think it should be accepted.
So I guess for UNION_TYPEs we need to first try the active member and only then
fall back to what the code would do after the above patch.

[Bug tree-optimization/98138] BB vect fail to SLP one case

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

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

--- Comment #2 from Richard Biener  ---
So the expected vectorization builds vectors

 { tmp[0][0], tmp[1][0], tmp[2][0], tmp[3][0] }

that's not SLP, SLP tries to build the

 { tmp[i][0], tmp[i][1], tmp[i][2], tmp[i][3] }

vector and "succeeds" - the SLP tree turns out to be
highly inefficient though.  So for the stores your desire
is to see an interleaving scheme with VF 4 (the number of
iterations).  But interleaving fails because it would require
a VF of 16 and there are not enough iteration in the loop.

The classical SLP scheme degenerates (also due to the plus/minus
mixed ops) to uniform vectors as we venture beyond the a{0,2} {+,-} a{1,3}
expression.

Starting SLP discovery from the grouped loads would get things going
up to the above same expression.

So not sure what's the best approach to this case.  The testcase
can be simplified still showing the SLP discovery issue:

extern void test(unsigned int t[4][4]);

void foo(int *p1, int i1, int *p2, int i2)
{
  unsigned int tmp[4][4];
  unsigned int a0, a1, a2, a3;

  for (int i = 0; i < 4; i++, p1 += i1, p2 += i2) {
  a0 = (p1[0] - p2[0]);
  a1 = (p1[1] - p2[1]);
  a2 = (p1[2] - p2[2]);
  a3 = (p1[3] - p2[3]);

  int t0 = a0 + a1;
  int t1 = a0 - a1;
  int t2 = a2 + a3;
  int t3 = a2 - a3;

  tmp[i][0] = t0 + t2;
  tmp[i][2] = t0 - t2;
  tmp[i][1] = t1 + t3;
  tmp[i][3] = t1 - t3;
  }
  test(tmp);
}

So it's basically SLP discovery degenerating to an interleaving scheme
on the load side but not actually "implementing" it.

[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79

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

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

--- Comment #6 from Richard Biener  ---
(In reply to Jan Hubicka from comment #5)
> > So, shouldn't the code match what the comment says?
> >   /* If the call is to a replaceable operator delete and results
> >  from a delete expression as opposed to a direct call to
> >  such operator, then we can treat it as free.  */
> > There is no check that it is a replaceable operator, that would mean
> > testing also
> >   && DECL_IS_REPLACEABLE_OPERATOR (fndecl)
> 
> I copied the test from find_func_aliases_for_call (including the
> comment).  I will look into what is happening here.
> 
> Honza

But it's only used for delete there.

[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79

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

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

--- Comment #7 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #4)
> That would mean:
> 
> --- gcc/testsuite/g++.dg/opt/pr98130.C.jj 2020-12-04 12:30:11.510988404 
> +0100
> +++ gcc/testsuite/g++.dg/opt/pr98130.C2020-12-04 12:33:05.663028984 
> +0100
> @@ -0,0 +1,25 @@
> +// PR c++/98130
> +// { dg-do run { target c++11 } }
> +// { dg-options "-O2" }
> +
> +#include 
> +
> +typedef int *T;
> +
> +static unsigned char storage[sizeof (T)] alignas (T);
> +static T *p = (T *) storage;
> +
> +static inline __attribute__((__always_inline__)) void
> +foo (T value)
> +{
> +  new (p) T(value);
> +}
> +
> +int
> +main ()
> +{
> +  int a;
> +  foo (&a);
> +  if (!*p)
> +__builtin_abort ();
> +}
> --- gcc/gimple.c.jj   2020-11-26 01:14:47.528081989 +0100
> +++ gcc/gimple.c  2020-12-04 12:34:44.865911907 +0100
> @@ -1514,11 +1514,12 @@ gimple_call_fnspec (const gcall *stmt)
>   such operator, then we can treat it as free.  */
>if (fndecl
>&& DECL_IS_OPERATOR_DELETE_P (fndecl)
> +  && DECL_IS_REPLACEABLE_OPERATOR (fndecl)
>&& gimple_call_from_new_or_delete (stmt))
>  return ".co ";
>/* Similarly operator new can be treated as malloc.  */
>if (fndecl
> -  && DECL_IS_OPERATOR_NEW_P (fndecl)
> +  && DECL_IS_REPLACEABLE_OPERATOR_NEW_P (fndecl)
>&& gimple_call_from_new_or_delete (stmt))
>  return "mC";
>return "";
> 
> but the testcase is miscompiled even with that change, and we don't really
> return ".co " nor "mC" on the testcase.

The fix works for me?  Note I think we don't need the extra check on
the delete case.

[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79

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

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

--- Comment #8 from Jakub Jelinek  ---
Oops, yes, dunno why it didn't work for me before, confirmed now that it works
with the patch and fails without.

I think we want it even for the operator delete case, I believe the C++
standard only constraints how the replaceable operators work, not arbitrary
user operator new/delete/new[]/delete[] operators.

[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79

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

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

--- Comment #9 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #8)
> Oops, yes, dunno why it didn't work for me before, confirmed now that it
> works with the patch and fails without.
> 
> I think we want it even for the operator delete case, I believe the C++
> standard only constraints how the replaceable operators work, not arbitrary
> user operator new/delete/new[]/delete[] operators.

I bet it's pretty similar to what we have for -fallocation-dce:
valid_new_delete_pair_p?

[Bug libfortran/98129] Failure on reading big chunk of /dev/urandom

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

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

--- Comment #2 from Thomas Koenig  ---
The problem seems to be related to an early return from the read system call:

strace -e trace=open,read,close ./a.out
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\v\2\0\0\0\0\0"...,
832) = 832
close(3)= 0
close(3)= 0
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\217\0\0\0\0\0\0"...,
832) = 832
close(3)= 0
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260/\0\0\0\0\0\0"...,
832) = 832
close(3)= 0
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@*\0\0\0\0\0\0"..., 832)
= 832
close(3)= 0
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`D\2\0\0\0\0\0"..., 832)
= 832
close(3)= 0
read(3,
":\312\275\302\373|\204[c`\20\275\230\205\326@\255Mj\263-qd\336\30\300\2G\326\215\333J"...,
4000) = 33554431
At line 9 of file read.f90
Fortran runtime error: End of file

Error termination. Backtrace:
close(5)= 0
close(5)= 0
close(6)= 0
close(5)= 0
close(5)= 0
close(5)= 0
close(6)= 0
close(5)= 0
close(6)= 0
close(5)= 0
#0  0x7fd9847c572f in read_block_direct
at ../../../trunk/libgfortran/io/transfer.c:664
#1  0x7fd9847c572f in unformatted_read
at ../../../trunk/libgfortran/io/transfer.c:1127
#2  0x400bf3 in ???
#3  0x400c9c in ???
#4  0x7fd983a46349 in __libc_start_main
at ../csu/libc-start.c:308
#5  0x400909 in ???
at ../sysdeps/x86_64/start.S:120
#6  0x in ???
close(4)= 0
close(3)= 0
+++ exited with 2 +++

[Bug target/98140] New: Reused register by xsmincdp leads to wrong NaN propagation on Power9

[alexander.grund--- via Gcc-bugs]

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

Bug ID: 98140
   Summary: Reused register by xsmincdp leads to wrong NaN
propagation on Power9
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.gr...@tu-dresden.de
  Target Milestone: ---

Created attachment 49679
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49679&action=edit
(preprocessed) source code to reproduce issue

Summary: xsmincdp instructions are generated in a form like `xsmincdp b,a,b`
for code that looks like `(a > b) ? b : a`

I was debugging an issue in PyTorch
(https://github.com/pytorch/pytorch/issues/48591) where I encountered the
following problem:

A clamp function is used which looks like this:

c[i] = a[i] < min_vec[i] ? min_vec[i] : (a[i] > max_vec[i] ? max_vec[i] :
a[i]);

This is used in very complex code using multiple levels of C++ templates,
lambdas and such and uses a combination of manually unrolled loops and
unroll-friendly loops (i.e. the above is called in a loop with a fixed trip
count of 8)

The generated ASM code has this (using objdump):
c[i] = a[i] < min_vec[i] ? min_vec[i] : (a[i] > max_vec[i] ? max_vec[i] :
a[i]);
   8e970:   20 00 fe cb lfd f31,32(r30)
   8e974:   00 f8 9c ff fcmpu   cr7,f28,f31
   8e978:   0c 00 9c 41 blt cr7,8e984 
   8e97c:   40 00 fe cb lfd f31,64(r30)
   8e980:   40 fc fc f3 xsmincdp vs31,vs28,vs31
   8e984:   28 00 9e cb lfd f28,40(r30)


So I assume f28/vs28 contains a[i] and vs31 contains max_vec[i], so the
instruction generated looks like `xsmincdp max_vec,a,max_vec` which on NaN will
return max_vec. However in the source code a should be returned due to the
condition evaluating to false when a NaN is involved.

Reproducing this is tricky, as it depends on many conditions. From my
observations I assume some register pressure is required and even some other
function also calling that code, so maybe some side effects from there. Using
GCC 10.2.0 I wasn't able to reproduce this as the codegen is slightly
different: Seemingly it notices that max_vec contains the same value for all i
and reuses a single register:
 324:   00 70 1f fc fcmpu   cr0,f31,f14
 328:   90 f8 a0 fe fmr f21,f31
 32c:   08 00 81 41 bgt 334
 330:   40 74 be f2 xsmincdp vs21,vs30,vs14
 334:   00 78 1f fc fcmpu   cr0,f31,f15
 338:   90 f8 c0 fe fmr f22,f31
 33c:   08 00 81 41 bgt 344
 340:   40 7c de f2 xsmincdp vs22,vs30,vs15

I'm attaching some source code which can be compiled using PyTorch 1.7.0 and 2
examples of preprocessed code which yield the above when compiled using `g++ 
-mcpu=power9 -g -std=gnu++14 -O3`

[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79

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

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

--- Comment #10 from Jakub Jelinek  ---
valid_new_delete_pair_p checks the extra constraints C++ has, like that if you
allocate with a particular replaceable operator new, you can free it only with
those and those replaceable operator delete and not others.

[Bug fortran/98141] New: Segmentation fault with empty string sourced allocation

[davidhneill at gmail dot com via Gcc-bugs]

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

Bug ID: 98141
   Summary: Segmentation fault with empty string sourced
allocation
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: davidhneill at gmail dot com
  Target Milestone: ---

The following example produces a segmentation fault on a sourced allocation
from the empty string to an unlimited polymorphic allocatable. This also
happens when the source is a 0-length character array instead of the empty
string literal.

The segfault is present in all versions I've tried: 7.5.0, 8.4.0, 9.3.0, 10.2.0

$ cat empty_string_segfault.f90 

module foo
  type, public :: any_scalar
class(*), allocatable :: value
  contains
procedure :: alloc
  end type
contains
  subroutine alloc (this, value)
class(any_scalar), intent(out) :: this
class(*), intent(in) :: value
allocate(this%value, source=value)
  end subroutine alloc
end module foo

program prog
  use foo
  type(any_scalar) :: s1, s2, s3
  character(len=0) :: c
  call s1%alloc(' ') !! No problem
  call s2%alloc('')  !! Segfault
  call s3%alloc(c)   !! Segfault
end program

$ gfortran -Wall -Wextra -g empty_string_segfault.f90
$ ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.


My system is Ubuntu 20.04 on Intel hardware with all gfortran versions
installed directly from the Ubuntu repositories.

[Bug libfortran/98129] Failure on reading big chunk of /dev/urandom

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

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

--- Comment #3 from Thomas Koenig  ---
The problem seems to be that we assume that a short read is always
an EOF, in read_block_direct:

  if (unlikely ((ssize_t) nbytes != have_read_record))
{
  /* Short read,  e.g. if we hit EOF.  For stream files,
   we have to set the end-of-file condition.  */
  hit_eof (dtp);
}
  return;
}

[Bug target/98139] varasm.c fails to compile on AIX 7.2: -Werror=unused-variable

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

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

--- Comment #2 from David Edelsohn  ---
I bootstrap GCC on AIX with, and the instructions in the CompileFarm wiki
recommend, --disable-werror.

If that currently is the only problem, we're lucky.  I don't know that this
hack is better.  Shrug.

[Bug tree-optimization/98069] [8/9/10/11 Regression] Miscompilation with -O3 since r8-2380-g2d7744d4ef93bfff

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

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

--- Comment #5 from Richard Biener  ---
The proposed fix for PR98137 might also expose more cases like this (which
maybe is a good thing for coverage).

[Bug c++/98122] [10/11 Regression] Accessing union member through pointer-to-member is not a constant expression

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 49680
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49680&action=edit
gcc11-pr98122.patch

Untested fix.

[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79

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

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

--- Comment #11 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #8)
> Oops, yes, dunno why it didn't work for me before, confirmed now that it
> works with the patch and fails without.
> 
> I think we want it even for the operator delete case, I believe the C++
> standard only constraints how the replaceable operators work, not arbitrary
> user operator new/delete/new[]/delete[] operators.

Note we already require to see a new/delete _expression_ and IIRC any delete
expression will make the contents undefined (see my discussion with Jason on
this topic).  But yes, we have to preserve other side-effects so the ".c"
part is probably bogus, the PTA code treats it as "..X ", "..o " would
still make 'this' receive pointers.  So we probably cannot model 'delete'
beavior exactly but "..o " is probably good enough.  Attempts to break it
welcome, of course.

[Bug target/98139] varasm.c fails to compile on AIX 7.2: -Werror=unused-variable

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Guess the hack already is how xcoff.h defines ASM_OUTPUT_DEF.  Of course the
middle-end should have an alternate way to tell whether a target has alias
support - maybe it already has and the code is just no longer required.

So yeah, why not (the patch).

[Bug target/98139] varasm.c fails to compile on AIX 7.2: -Werror=unused-variable

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from David Edelsohn  ---
> I bootstrap GCC on AIX with, and the instructions in the CompileFarm wiki
> recommend, --disable-werror.

Ah, I missed that.  It's the only instance of target-specific build
instructions in the Wiki.  Shouldn't this go to install.texi, too,
unless it's expected to be fixed before GCC 11?

> If that currently is the only problem, we're lucky.  I don't know that this
> hack is better.  Shrug.

I only tested C,C++, but a couple of months ago I tried with Ada
included and didn't have the issue at all (expect for PR ada/95549).

The big advantage of doing it automatically (either similarly to my
hack, variations of which have been used in the past when target macros
ignore one or more of their args, or by enabling --disable-werror by
default for AIX) is that you avoid wasted time: every time a developer
runs into this, he either starts to hunt down the issue (when she's
diligent) or moves on in disgust (the majority, I guess).

[Bug target/98139] varasm.c fails to compile on AIX 7.2: -Werror=unused-variable

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

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

--- Comment #5 from David Edelsohn  ---
It has nothing to do with the proper way to install GCC on AIX.

It was not the only -Werror failure on AIX.  That is why I said, if that's the
only problem, we're lucky.  The -Werror failures change.

The patch is okay, but it doesn't remove the need to recommend
--disable-werror.

[Bug c++/98142] New: fstrict-enums optimization applied only for unscoped enums with unfixed underlying type

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 98142
   Summary: fstrict-enums optimization applied only for unscoped
enums with unfixed underlying type
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider this simple example

namespace N4 {
enum E {
A, B, C, D
};

bool compare_logical(E x) { return (x == E::B) || (x == E::D); }
}

Compiled with -O3 -fstrict-enums, gcc 10.2 emits:

N4::compare_logical(N4::E):
mov eax, edi
and eax, 1
ret

As desired. I am telling gcc to make an assumption about the range of values,
and it is optimizing based on the fact that 5 is not a valid enumerator.
Fantastic.

However, any other definition of E, whether it's scoped:

enum class E {
A, B, C, D
};

Or it has a fixed underlying type:

enum E : unsigned {
A, B, C, D
};

or both:

enum class E : unsigned {
A, B, C, D
};

in all cases emits the same alternative code:

N3::compare_logical(N3::E):
and edi, -3
cmp edi, 1
seteal
ret

It does this extra work to be able to reject, for instance, the value 5. But
I'm trying to tell the optimizer that this does not happen.

Full example on compiler explorer: https://godbolt.org/z/Tq58hK

Can this optimization be extended to cover these additional cases, or is there
some reason it cannot?

[Bug target/97981] [11 regression] 32-bit x86 'gcc.dg/atomic/c11-atomic-exec-1.c' execution test

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||muecker at gwdg dot de
  Known to fail||11.0
  Known to work||10.2.0
   Keywords|needs-bisection |
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=98029

--- Comment #2 from Martin Liška  ---
Confirmed, started with r11-5188-g32934a4f45a72144.

There's reduced test-case:

$ cat atomic.i
int main(void) {
  static volatile _Atomic(double) a, b = (double)((0));
  if ((a = b) != ((double)((0
__builtin_abort();

  return 0;
}

$ gcc -g atomic.i -m32 -c -O2 && gcc-10 -m32 -latomic atomic.o && valgrind
./a.out
==2400== Memcheck, a memory error detector
==2400== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2400== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==2400== Command: ./a.out
==2400== 
==2400== Conditional jump or move depends on uninitialised value(s)
==2400==at 0x8049081: main (atomic.i:3)
==2400== 
==2400== Conditional jump or move depends on uninitialised value(s)
==2400==at 0x8049087: main (atomic.i:3)
==2400== 
==2400== 
==2400== Process terminating with default action of signal 6 (SIGABRT): dumping
core
==2400==at 0x40C17D6: raise (in /lib/libc-2.32.so)
==2400==by 0x40A9313: abort (in /lib/libc-2.32.so)
==2400==by 0x8049054: main.cold (atomic.i:4)
==2400==by 0x40AAF75: (below main) (in /lib/libc-2.32.so)
==2400== 
==2400== HEAP SUMMARY:
==2400== in use at exit: 0 bytes in 0 blocks
==2400==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2400== 
==2400== All heap blocks were freed -- no leaks are possible
==2400== 
==2400== Use --track-origins=yes to see where uninitialised values come from
==2400== For lists of detected and suppressed errors, rerun with: -s
==2400== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Aborted (core dumped)

[Bug target/97981] [11 regression] 32-bit x86 'gcc.dg/atomic/c11-atomic-exec-1.c' execution test since r11-5188-g32934a4f45a72144

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

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

--- Comment #3 from Martin Liška  ---
The revision causes the following diff in GENERIC:

@@ -10,8 +10,8 @@
 static atomic volatile double a;
 static atomic volatile double b = 0.0;
   # DEBUG BEGIN STMT;
-  if (TARGET_EXPR (__atomic_load_8 ((const volatile void *) &b, 5)))>>;
-  __atomic_store_8 ((volatile void *) &a, VIEW_CONVERT_EXPR(D.1886), 5);, D.1886 != 0.0;)
+  if (TARGET_EXPR ;
+  __atomic_store_8 ((volatile void *) &a, VIEW_CONVERT_EXPR(D.1885), 5);, D.1885 != 0.0;)
 {
   # DEBUG BEGIN STMT;
   __builtin_abort ();

[Bug c++/98142] fstrict-enums optimization applied only for unscoped enums with unfixed underlying type

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I don't see how it could be extended to the case with the fixed underlying
type,
std::byte
is
enum class byte : unsigned char {};
yet it needs to support all the 0 to (unsigned char)~0 values even with
-fstrict-enums.

[Bug sanitizer/97868] warn about using fences with TSAN

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

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

--- Comment #2 from Martin Liška  ---
Created upstream issue: https://github.com/google/sanitizers/issues/1352.

[Bug c++/98142] fstrict-enums optimization applied only for unscoped enums with unfixed underlying type

[barry.revzin at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Barry Revzin  ---
That is a great point.

I guess in general this is kind of a scary optimization, since it doesn't seem
like it's really a global thing? Perhaps this calls for an attribute?

[[gnu::i_promise_on_penalty_of_ub_that_only_these_values_are_used]]
enum class E : unsigned int { A, B, C, D };

Or, you know, [[gnu::strict_enum]] or something.

[Bug rtl-optimization/97540] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-4202-g4de7b010038933dd

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Liška  ---
Then it's fixed.

[Bug c++/96749] [coroutines] unexpected 'warning: statement has no effect [-Wunused-value]'

[max at duempel dot org via Gcc-bugs]

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

Max Kellermann  changed:

   What|Removed |Added

 CC||max at duempel dot org

--- Comment #2 from Max Kellermann  ---
Created attachment 49681
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49681&action=edit
Another variant of the bug

I confirm this bug with "gcc version 10.2.0 (Debian 10.2.0-19)", and I have
found another variant of it; in my sample source, using a "struct" return type
triggers the warning, but built-in types do not.

[Bug c++/98142] fstrict-enums optimization applied only for unscoped enums with unfixed underlying type

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Maybe.

[Bug fortran/97224] [8/9/10/11 Regression] SPECCPU 2006 Gamess fails to build after g:e5a76af3a2f3324efc60b4b2778ffb29d5c377bc

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Status|NEW |WAITING

--- Comment #11 from Martin Liška  ---
@Taram: Is it still a problem that you can't build the benchmark?
I don't see the problem.

[Bug c++/95192] [11 Regression] ICE: tree check: expected tree_list, have error_mark in handle_assume_aligned_attribute, at c-family/c-attribs.c:2996

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #2)
> In cp/parser.c, we have code that avoids building attributes with
> error_mark_node values (instead just use error_mark_node as the attributes).
> 
> So, I wonder if we shouldn't do that in tsubst_attributes too, like:
> --- gcc/cp/pt.c.jj2020-11-18 09:40:09.618663053 +0100
> +++ gcc/cp/pt.c   2020-11-18 15:47:26.584181671 +0100
> @@ -11502,6 +11502,8 @@ tsubst_attribute (tree t, tree *decl_p,
>tree chain
>   = tsubst_expr (TREE_CHAIN (val), args, complain, in_decl,
>  /*integral_constant_expression_p=*/false);
> +  if (chain == error_mark_node)
> + return error_mark_node;
>if (chain != TREE_CHAIN (val))
>   val = tree_cons (NULL_TREE, TREE_VALUE (val), chain);
>  }
> @@ -11524,8 +11526,12 @@ tsubst_attribute (tree t, tree *decl_p,
>return list;
>  }
>else
> -val = tsubst_expr (val, args, complain, in_decl,
> -/*integral_constant_expression_p=*/false);
> +{
> +  val = tsubst_expr (val, args, complain, in_decl,
> +  /*integral_constant_expression_p=*/false);
> +  if (val == error_mark_node)
> + return val;
> +}
>  
>if (val != TREE_VALUE (t))
>  return build_tree_list (TREE_PURPOSE (t), val);
> 
> Except that we accept the testcase then rather than reject - the unification
> is done with complain == 0...

Are you planning Jakub to send the patch candidate to the mailing list?

[Bug c++/95192] [11 Regression] ICE: tree check: expected tree_list, have error_mark in handle_assume_aligned_attribute, at c-family/c-attribs.c:2996

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

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

--- Comment #4 from Jakub Jelinek  ---
No, because it isn't sufficient, I believe we need to reject it rather than
accept it.

[Bug target/98143] New: arm: missed vectorization with MVE compared to Neon

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

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

Bug ID: 98143
   Summary: arm: missed vectorization with MVE compared to Neon
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

While working on enabling auto-vectorization for MVE, I noticed a missed
optimization compared to Neon:

#include 
uint16_t *dest;
void func()
{
  int i;
  for (i=0;i<16;i++)
dest[i]=3;
}

Compiled with -O3 -S -dp -mfloat-abi=hard -mfpu=auto -mcpu=cortex-a9 -mthumb:
func:
movwr3, #:lower16:.LANCHOR0 @ 15[c=4 l=4]  *thumb2_movsi_vfp/4
vmov.i16q8, #3  @ v8hi  @ 7 [c=4 l=4]  *neon_movv8hi/2
movtr3, #:upper16:.LANCHOR0 @ 16[c=4 l=4]  *arm_movt/0
ldr r3, [r3]@ 14[c=12 l=4]  *thumb2_movsi_vfp/5
vst1.16 {q8}, [r3]! @ 8 [c=8 l=4]  *movmisalignv8hi_neon_store
vst1.16 {q8}, [r3]  @ 11[c=8 l=4]  *movmisalignv8hi_neon_store
bx  lr  @ 44[c=8 l=4]  *thumb2_return

Compiled with -O3 -S -dp -mfloat-abi=hard -mfpu=auto -march=armv8.1-m.main+mve
-mthumb:
func:
movsr2, #3  @ 7 [c=4 l=2]  *thumb2_movsi_shortim
ldr r3, .L3 @ 5 [c=12 l=4]  *thumb2_movsi_vfp/5
ldr r3, [r3]@ 6 [c=12 l=4]  *thumb2_movsi_vfp/5
strhr2, [r3]@ movhi @ 9 [c=4 l=4]  *thumb2_movhi_vfp/4
strhr2, [r3, #2]@ movhi @ 12[c=4 l=4]  *thumb2_movhi_vfp/4
strhr2, [r3, #4]@ movhi @ 15[c=4 l=4]  *thumb2_movhi_vfp/4
strhr2, [r3, #6]@ movhi @ 18[c=4 l=4]  *thumb2_movhi_vfp/4
strhr2, [r3, #8]@ movhi @ 21[c=4 l=4]  *thumb2_movhi_vfp/4
strhr2, [r3, #10]   @ movhi @ 24[c=4 l=4]  *thumb2_movhi_vfp/4
strhr2, [r3, #12]   @ movhi @ 27[c=4 l=4]  *thumb2_movhi_vfp/4
strhr2, [r3, #14]   @ movhi @ 30[c=4 l=4]  *thumb2_movhi_vfp/4
strhr2, [r3, #16]   @ movhi @ 33[c=4 l=4]  *thumb2_movhi_vfp/4
strhr2, [r3, #18]   @ movhi @ 36[c=4 l=4]  *thumb2_movhi_vfp/4
strhr2, [r3, #20]   @ movhi @ 39[c=4 l=4]  *thumb2_movhi_vfp/4
strhr2, [r3, #22]   @ movhi @ 42[c=4 l=4]  *thumb2_movhi_vfp/4
strhr2, [r3, #24]   @ movhi @ 45[c=4 l=4]  *thumb2_movhi_vfp/4
strhr2, [r3, #26]   @ movhi @ 48[c=4 l=4]  *thumb2_movhi_vfp/4
strhr2, [r3, #28]   @ movhi @ 51[c=4 l=4]  *thumb2_movhi_vfp/4
strhr2, [r3, #30]   @ movhi @ 54[c=4 l=4]  *thumb2_movhi_vfp/4
bx  lr  @ 84[c=8 l=4]  *thumb2_return



This PR is about building the const, as the problems with stores are probably
part of PR97875.

In summry, with Neon we build the constant vector with:
vmov.i16q8, #3  @ v8hi  @ 7 [c=4 l=4]  *neon_movv8hi/2
but with MVE:
movsr2, #3  @ 7 [c=4 l=2]  *thumb2_movsi_shortim
and then store it as 16-bits value as many times as needed.

I haven't managed to understand why we can't make use of mve.md's mve_mov
where there is an alternative with "Dm", which should work?

[Bug rtl-optimization/98144] New: REE needs 6GB DF memory when compiling insn-extract.c with RTL checking enabled

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

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

Bug ID: 98144
   Summary: REE needs 6GB DF memory when compiling insn-extract.c
with RTL checking enabled
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

otherwise it doesn't do much with all this DF analysis.

 ree:   0.07 (  0%)   0.00 (  0%)   0.05 (  0%)
   75k (  0%)
...
 TOTAL  :  26.43  5.86 32.32   
 1655M
26.44user 5.91system 0:32.36elapsed 99%CPU (0avgtext+0avgdata
408maxresident)k
0inputs+0outputs (0major+2139837minor)pagefaults 0swaps


it does

  /* Construct DU chain to get all reaching definitions of each
 extension instruction.  */
  df_set_flags (DF_RD_PRUNE_DEAD_DEFS);
  df_chain_add_problem (DF_UD_CHAIN + DF_DU_CHAIN);
  df_mir_add_problem ();
  df_analyze ();

and the MIR problem causes it to explode.

[Bug rtl-optimization/98144] REE needs 6GB DF memory when compiling insn-extract.c with RTL checking enabled

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

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

--- Comment #1 from Richard Biener  ---
Created attachment 49682
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49682&action=edit
preprocessed insn-extract

This is x86_64 insn-extract when configured with --enable-checking=yes,rtl

[Bug rtl-optimization/98144] REE needs 6GB DF memory when compiling insn-extract.c with RTL checking enabled

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Maybe RTL SSA is a good fit for REE.

[Bug c/98145] New: On Windows .exe extension is missing when searching/calling mkoffload

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

Bug ID: 98145
   Summary: On Windows .exe extension is missing when
searching/calling mkoffload
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brechtsanders at users dot sourceforge.net
  Target Milestone: ---

I was trying to get nvptx offloading to work on Windows/MinGW-w64, and got the
following output when testing the resulting build:

lto-wrapper.exe: fatal error: could not find accel/nvptx-none/mkoffload in
d:/prog/winlibs64-10.2.0-8.0.0/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/10.2.0/;d:/prog/winlibs64-10.2.0-8.0.0/mingw64/bin/../libexec/gcc/;d:/prog/winlibs64-10.2.0-8.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/
(consider using '-B')
compilation terminated.

It looks to me like gcc/lto-wrapper.c needs to be fixed so it looks for
mkoffload.exe instead of just mkoffload on Windows.

Probably something like this but with some additional checks to only add the
.exe on the Windows platform:
patch -ulbf gcc/lto-wrapper.c << EOF
@@ -827,6 +827,6 @@
   char *suffix
-= XALLOCAVEC (char, sizeof ("/accel//mkoffload") + strlen (target));
+= XALLOCAVEC (char, sizeof ("/accel//mkoffload.exe") + strlen (target));
   strcpy (suffix, "/accel/");
   strcat (suffix, target);
-  strcat (suffix, "/mkoffload");
+  strcat (suffix, "/mkoffload.exe");

EOF

[Bug tree-optimization/97270] [11 Regression] ICE in do_store_flag, at expr.c:12247 since r11-1445-g502d63b6d61415

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Can't reproduce any longer.

[Bug target/98146] New: [11 Regression] section type conflict when "used" attribute is applied to decl with specific section

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

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

Bug ID: 98146
   Summary: [11 Regression] section type conflict when "used"
attribute is applied to decl with specific section
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jozefl at gcc dot gnu.org
  Target Milestone: ---

For targets that support the SHF_GNU_RETAIN ELF section flag, the "used"
attribute will set the internal GCC SECTION_RETAIN flag on the section
containing the "used" decl.

If a "used" decl, and a decl without "used" both specify the same section with
the "section" attribute, GCC will emit an error:

$ cat tester.c
int __attribute__((section(".data.foo"))) foo1 = 1;
int __attribute__((used,section(".data.foo"))) foo2 = 2;

$ gcc -S tester.c
tester.c:2:48: error: 'foo2' causes a section type conflict with 'foo1'
2 | int __attribute__((used,section(".data.foo"))) foo2 = 2;
  |^~~~
tester.c:1:43: note: 'foo1' was declared here
1 | int __attribute__((section(".data.foo"))) foo1 = 1;
  |   ^~~~

This was originally reported in glibc PR 27002, but is actually a GCC bug.

[Bug tree-optimization/96226] Failure to optimize shift+not to rotate

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 49683
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49683&action=edit
gcc11-pr96226.patch

Untested fix.

[Bug target/98121] [11 Regression] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION

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

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

Jozef Lawrynowicz  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #11 from Jozef Lawrynowicz  ---
I'm going to resolve this as WONTFIX since we're not going to change the fact
that the "used" attribute applies SHF_GNU_RETAIN.

There are no section flag conflicts when a declaration that has the "used"
attribute applied interfaces with a section defined in assembler code. The
assembler will keep sections with different SHF_GNU_RETAIN states separate.

There was a GCC bug causing section flag conflicts in one specific situation,
that is tracked in PR target/98146.

[Bug c++/98142] fstrict-enums optimization applied only for unscoped enums with unfixed underlying type

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Barry Revzin from comment #2)
> I guess in general this is kind of a scary optimization, since it doesn't
> seem like it's really a global thing? Perhaps this calls for an attribute?
> 
> [[gnu::i_promise_on_penalty_of_ub_that_only_these_values_are_used]]
> enum class E : unsigned int { A, B, C, D };
> 
> Or, you know, [[gnu::strict_enum]] or something.

It couldn't be called "strict_enum". The -fstrict-enums flag means assume no
invalid values, i.e. nothing outside the valid values of the enum type. For any
enum type with a fixed underlying type, all values of the underlying type are
valid values of the enum type, so there are no invalid values. So "strict_enum"
as the attribute name would be contradicting the meaning of -fstrict-enums.

So purely on that basis, the better name would be
"i_promise_on_penalty_of_ub_that_only_these_values_are_used"

[Bug c++/98142] fstrict-enums optimization applied only for unscoped enums with unfixed underlying type

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

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

--- Comment #5 from Jakub Jelinek  ---
Perhaps spell it as gnu::exhaustive_enum then or something similar?

[Bug c++/98142] fstrict-enums optimization applied only for unscoped enums with unfixed underlying type

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Barry Revzin from comment #0)
> As desired. I am telling gcc to make an assumption about the range of
> values, and it is optimizing based on the fact that 5 is not a valid
> enumerator.

N.B. it has nothing to do with whether it's an enumerator.

Given enum E2 { zero, two=2 } this has the same range of valid values, and so
E2(1) and E2(3) are valid, even though there are no enumerators with those
values, and E2(3) has a higher value than two.

The only enumerators that matter are the ones with the minimum and maximum
values, as those determine the range of valid values as per [dcl.enum] p8. All
other enumerators are just named constants, they have no bearing on the valid
values or optimizations.

All values within the enum's range are valid, whether there is an enumerator
with that value or not.

What you're asking for is not how C++ enumeration types work, although it is
how many, many people think they work, or want them to work.

[Bug c++/98142] fstrict-enums optimization applied only for unscoped enums with unfixed underlying type

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #5)
> Perhaps spell it as gnu::exhaustive_enum then or something similar?

I like that.

It would be much stricter than -fstrict-enums as it would say that you won't
create E2(1) or E2(3) even though those are valid values.

[Bug target/98147] New: [11 Regression] ICE in emit_library_call_value_1, at calls.c:5296 since r11-5725-g442b6fb7c09a39577261de90413cc4db366f1c5f

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

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

Bug ID: 98147
   Summary: [11 Regression] ICE in emit_library_call_value_1, at
calls.c:5296 since
r11-5725-g442b6fb7c09a39577261de90413cc4db366f1c5f
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: aarch64-linux-gnu

Since the revision, the following fails:

$ cat clear_cache.c
char buffer[32] = "Bla bla";
int main() {
  __builtin___clear_cache(buffer, buffer+32);
  return 0;
}

$ aarch64-linux-gnu-gcc clear_cache.c -c -mabi=ilp32
during RTL pass: expand
clear_cache.c: In function ‘main’:
clear_cache.c:3:3: internal compiler error: in emit_library_call_value_1, at
calls.c:5296
3 |   __builtin___clear_cache(buffer, buffer+32);
  |   ^~
0x65f200 emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
machine_mode, int, std::pair*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/calls.c:5296
0x791810 emit_library_call(rtx_def*, libcall_type, machine_mode, rtx_def*,
machine_mode, rtx_def*, machine_mode)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/rtl.h:4195
0x791810 default_emit_call_builtin___clear_cache(rtx_def*, rtx_def*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/builtins.c:7782
0x7a1747 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/builtins.c:9729
0x8be8df expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.c:11249
0x7c256e expand_expr
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/expr.h:282
0x7c256e expand_call_stmt
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:2831
0x7c256e expand_gimple_stmt_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:3835
0x7c256e expand_gimple_stmt
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:3999
0x7c80f7 expand_gimple_basic_block
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:6040
0x7c80f7 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/cfgexpand.c:6724
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/98147] [11 Regression] ICE in emit_library_call_value_1, at calls.c:5296 since r11-5725-g442b6fb7c09a39577261de90413cc4db366f1c5f

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Priority|P3  |P1
   Last reconfirmed||2020-12-04
  Known to work||10.2.0
  Known to fail||11.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug libfortran/98129] Failure on reading big chunk of /dev/urandom

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
WORKSFORME on i386-*-freebsd with 'n = 10**m' and m = 1, 2, 3, ..., 8.  On this
system with ' n = 10**9', I get

mobile:kargl[248] gfcx -o z -O a.f90 && ./z
In file 'a.f90', around line 8: Error allocating 40 bytes: Cannot
allocate memory

So, it looks target specific.  Please change the component libgfortran to
whatever target you are using.

[Bug c++/98116] [11 Regression] ICE in strip_typedefs, at cp/tree.c:1744 since r11-5663-g329ae1d7751346ba

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
I think there's an existing defect that my array changes made more prevalent.

This testcase ICEs with and without my changes, when additional checking is
enabled:

./cc1plus -std=c++20 pr98116.C --param=hash-table-verification-limit=1000
-fchecking=2

We're getting confused comparing template aliases that map to the same type.

[Bug target/97981] [11 regression] 32-bit x86 'gcc.dg/atomic/c11-atomic-exec-1.c' execution test since r11-5188-g32934a4f45a72144

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #4 from Martin Uecker  ---
I think the code to drop qualifiers needs to be moved below the check for
atomic. I will look into it. (I wonder why this passed checks for me).

[Bug target/98140] Reused register by xsmincdp leads to wrong NaN propagation on Power9

[alexander.grund--- via Gcc-bugs]

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

--- Comment #1 from Alexander Grund  ---
It looks like this was fixed in 10.1 by this commit
https://github.com/gcc-mirror/gcc/commit/37e0df8a9be5a8232f4ccb73cdadb02121ba523f

However the codegen looks worse:

 390:   20 00 9e c3 lfs f28,32(r30)
 394:   00 e0 9e ff fcmpu   cr7,f30,f28
 398:   10 00 9c 41 blt cr7,3a8
 39c:   40 00 9e c3 lfs f28,64(r30)
 3a0:   58 e0 1e f0 xscmpgtdp vs0,vs30,vs28
 3a4:   30 e0 9e f3 xxsel   vs28,vs30,vs28,vs0

When switching an (a > b) ? b : a to an xsmincdp, the arguments must be swapped
to honor the NaN rules. This would allow this to be used for the `HONOR_NANS
(compare_mode)` case. However it still ignores signed zeros. Maybe xsmindp
would be a better fit as it preserves the signed zeros. Only downside I see is
that it converts sNan to qNan which may be an issue.

[Bug libfortran/98129] Failure on reading big chunk of /dev/urandom

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

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

Thomas Koenig  changed:

   What|Removed |Added

 Target||x86_64-pc-linux-gnu

--- Comment #5 from Thomas Koenig  ---
Question... on your respective systems, could you strace or truss it and find
if there is a short read?

On Linux, there seems to be a limitation of how many bytes
a read from /dev/urandom returns, and we assume that this is
an end of file.

However, this is not correct - we can only safely assume eof if
read() returns zero bytes.

[Bug fortran/98141] Segmentation fault with empty string sourced allocation

[davidhneill at gmail dot com via Gcc-bugs]

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

--- Comment #1 from David Neill Asanza  ---
Here are even shorter examples:

$ cat short01.f90

program short01
  class(*), allocatable :: a, b, c
  character(len=0) :: s
  allocate(a, source=s)  !! No problem
  allocate(character(len=0)::b)
  allocate(c, source=b)  !! Segfault
end program

$ cat short02.f90

program short02
  class(*), allocatable :: a, b
  allocate(a, source='')  !! No problem
  allocate(b, source=a)   !! Segfault
end program


So it seems the underlying issue is the sourced allocation from a 0-length
unlimited polymorphic type.

[Bug c/98145] On Windows .exe extension is missing when searching/calling mkoffload

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #1 from Brecht Sanders  
---
Closer investigation shows the issue probably not (or not only) cause by the
.exe extension:

This is the error:
lto-wrapper.exe: fatal error: could not find accel/nvptx-none/mkoffload.exe in
d:/prog/winlibs32-10.2.0-8.0.0/mingw32/bin/../libexec/gcc/i686-w64-mingw32/10.2.0/;d:/prog/winlibs32-10.2.0-8.0.0/mingw32/bin/../libexec/gcc/;d:/prog/winlibs32-10.2.0-8.0.0/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/
(consider using '-B')
d:/prog/winlibs32-10.2.0-8.0.0/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/ld.exe:
error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status

But the file does exist:
ls -l
'd:/prog/winlibs32-10.2.0-8.0.0/mingw32/bin/../libexec/gcc/i686-w64-mingw32/10.2.0/accel/nvptx-none/mkoffload.exe'
-rwxr-xr-x 1 brecht None 609294 Dec  4 17:14
d:/prog/winlibs32-10.2.0-8.0.0/mingw32/bin/../libexec/gcc/i686-w64-mingw32/10.2.0/accel/nvptx-none/mkoffload.exe

So the question remains: why is lto-wrapper not able to find the file that is
obviously there where it's looking?

[Bug tree-optimization/96232] Failure to optimize bool pattern equivalent to minus 1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2020-12-04
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 49684
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49684&action=edit
gcc11-pr96232.patch

Untested fix.

[Bug c++/98116] [11 Regression] ICE in strip_typedefs, at cp/tree.c:1744 since r11-5663-g329ae1d7751346ba

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

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

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

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

commit r11-5745-g5a26d4a204c8a462a7e0a1a86bb2f25ecd470aad
Author: Nathan Sidwell 
Date:   Fri Dec 4 08:34:41 2020 -0800

c++: Revert dependent-array changes [PR 98116]

The changes reverted here are exposing an existing problem with alias
template comparisons.  The typename_type changes are also incomplete,
possibly for similar reasons.  It seems safer to revert them, fix the
underlying issue and then move forwards.

The testcases is adjusted to more robustly check the specialization
table, and ICEs with and without the c++ changes.

Revert:
62fb1b9e0da c++: Fix array type dependency [PR 98107]
07589ca2b2c c++: typename_type structural comparison
29ae1d7751 c++: Extend build_array_type API

PR c++/98116
gcc/cp/
* cp-tree.h (comparing_typenames): Delete.
(cplus_build_array_type): Remove default parm.
* pt.c (comparing_typenames): Delete.
(spec_hasher::equal): Don't increment it.
* tree.c (set_array_type_canon): Remove dep parm.
(build_cplus_array_type): Remove dep parm changes.
(cp_build_qualified_type_real): Remove dependent array type
changes.
(strip_typedefs): Likewise.
* typeck.c (structural_comptypes): Revert comparing_typename
changes.
gcc/testsuite/
* g++.dg/template/pr98116.C: Enable robust checking.

[Bug target/94743] IRQ handler doesn't save scratch VFP registers

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

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #25 from Christophe Lyon  ---
Un-assigning myself: I do not plan to work more on this for the moment.

[Bug libstdc++/93121] std::bit_cast missing

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

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

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

https://gcc.gnu.org/g:33be07be9e46f15b9556521050356c47460651ee

commit r11-5746-g33be07be9e46f15b9556521050356c47460651ee
Author: Jakub Jelinek 
Date:   Fri Dec 4 18:00:54 2020 +0100

fold-const: Don't use build_constructor for non-aggregate types in
native_encode_initializer [PR93121]

The following testcase is rejected, because when trying to encode a zeroing
CONSTRUCTOR, the code was using build_constructor to build initializers for
the elements but when recursing the function handles CONSTRUCTOR only for
aggregate types.

The following patch fixes that by using build_zero_cst instead for
non-aggregates.  Another option would be add handling CONSTRUCTOR for
non-aggregates in native_encode_initializer.  Or we can do both, I guess
the middle-end generally doesn't like CONSTRUCTORs for scalar variables,
but
am not 100% sure if the FE doesn't produce those sometimes.

2020-12-04  Jakub Jelinek  

PR libstdc++/93121
* fold-const.c (native_encode_initializer): Use build_zero_cst
instead of build_constructor.

* g++.dg/cpp2a/bit-cast6.C: New test.

[Bug tree-optimization/96226] Failure to optimize shift+not to rotate

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

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

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

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

commit r11-5747-gac2a6962b91128e700ee52db686dcdb2bab93790
Author: Jakub Jelinek 
Date:   Fri Dec 4 18:44:31 2020 +0100

i386: Add combine splitters to allow combining multiple insns into reg1 =
const; reg2 = rotate (reg1, reg3 & cst) [PR96226]

As mentioned in the PR, we can combine ~(1 << x) into -2 r<< x, but we give
up in the ~(1 << (x & 31)) cases, as *3_mask* don't
allow
immediate operand 1 and find_split_point prefers to split (x & 31) instead
of the constant.

With these combine splitters we help combine decide how to split those
insns.

2020-12-04  Jakub Jelinek  

PR target/96226
* config/i386/i386.md (splitter after *3_mask,
splitter after *3_mask_1): New combine
splitters.

* gcc.target/i386/pr96226.c: New test.

[Bug tree-optimization/96226] Failure to optimize shift+not to rotate

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed for GCC 11+.

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

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

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

Bug 96226 Summary: Failure to optimize shift+not to rotate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96226

   What|Removed |Added

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

[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79

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

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

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

https://gcc.gnu.org/g:78c4a9feceaccf487516aa1eff417e0741556e10

commit r11-5748-g78c4a9feceaccf487516aa1eff417e0741556e10
Author: Jakub Jelinek 
Date:   Fri Dec 4 19:10:56 2020 +0100

gimple: Return fnspec only for replaceable new/delete operators called from
new/delete [PR98130]

As mentioned in the PR, we shouldn't treat non-replaceable operator
new/delete (e.g. with the placement new) as replaceable ones.

There is some pending discussion that perhaps operator delete called from
delete if not replaceable should return some other fnspec, but can we
handle
that incrementally, fix this wrong-code and then deal with a missed
optimization?  I really don't know what exactly should be returned.

2020-12-04  Jakub Jelinek  

PR c++/98130
* gimple.c (gimple_call_fnspec): Only return ".co " for replaceable
operator delete or ".mC" for replaceable operator new called from
new/delete.

* g++.dg/opt/pr98130.C: New test.

[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79

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

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

--- Comment #13 from Jakub Jelinek  ---
wrong-code should be now fixed, keeping open if Richard or Honza don't want to
improve handling of non-replaceable delete operators.

[Bug libfortran/98129] Failure on reading big chunk of /dev/urandom

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #5)
> Question... on your respective systems, could you strace or truss it and find
> if there is a short read?
> 
> On Linux, there seems to be a limitation of how many bytes
> a read from /dev/urandom returns, and we assume that this is
> an end of file.
> 
> However, this is not correct - we can only safely assume eof if
> read() returns zero bytes.

Well, the test completes so I would expect that there isn't a short
read.  I modified the program to write to 'txt.dat' and get the 
expected file sizes for various 'n = 10**m' values.  FreeBSD does
not have strace, but ktrace suggests that the read/write occur
as expected.

Looking at the FreeBSD manpage, I find

  The /dev/urandom interface returns bytes regardless of the amount of
  entropy available.  It does not block on a read request due to lack
  of entropy.

Does urandom block on your system, and is this interpreted as a short
read?

[Bug libfortran/98129] Failure on reading big chunk of /dev/urandom

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #7 from anlauf at gcc dot gnu.org ---
Intel and PGI/Nvidia work w/o problems on my Linux system.
We might try to solve it in a similar way.

[Bug debug/98148] New: [AArch64] Wrong location expression for function entry values

[luis.machado at linaro dot org via Gcc-bugs]

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

Bug ID: 98148
   Summary: [AArch64] Wrong location expression for function entry
values
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luis.machado at linaro dot org
  Target Milestone: ---
  Host: aarch64-linux
Target: aarch64-linux

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

Right now I have only verified this on Ubuntu 18.04's GCC 7.5.0, while
executing GDB's testsuite for ada.

It seems the generation of debug information for entry values is off somehow.

I've attaching the ELF file.

Reproduction steps:

gdb foo -ex "break callee.increment" -ex "run" -ex "frame"

It should display the following:

#0  callee.increment (val=val@entry=99.0, msg=...)

But, instead, it shows the following:

#0  callee.increment (val=99.0, val@entry=9.18340949e-41, msg=...)

The fact that "val" and "val@entry" are displayed separately and that they have
different values shows that the information for "val@entry" is wrong.

In fact, if you move up a frame, we'll see that val is not the correct value...

#1  0xb814 in caller.verbose_increment (val=9.18340949e-41,
msg=...)

It would be nice to test a master GCC, but I don't have a way to build it right
now.

[Bug debug/98148] [AArch64] Wrong location expression for function entry values

[luis.machado at linaro dot org via Gcc-bugs]

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

--- Comment #1 from Luis Machado  ---
You can find the sources for this testcase in binutils-gdb repo, at
gdb/testsuite/gdb.ada/O2_float_param.

[Bug debug/98148] [AArch64] Wrong location expression for function entry values

[luis.machado at linaro dot org via Gcc-bugs]

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

--- Comment #2 from Luis Machado  ---
In my particular example, The DWARF information tells us the value is at the
following expression...

<11ac>   DW_AT_GNU_call_site_value: 6 byte block: 8d ec 0 f6 4 2d  
(DW_OP_breg29 (x29): 108; DW_OP_GNU_deref_type: 4 <0x10e8>)

So, basically *($x29+108).

But I've found the correct value in *($x29+60). The actual value (a float) was
passed via v0 though.

[Bug tree-optimization/91191] vrp and boolean arguments

[law at redhat dot com via Gcc-bugs]

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

--- Comment #5 from Jeffrey A. Law  ---
The best way to think about V_C_E is that it's the same bits, just viewed in a
different type whereas a cast can do things like sign/zero extension,
truncation of floating point values to integers, etc).

[Bug middle-end/94600] Ignored volatile specifier on loop unrolling and bitfield misoptimization

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Hans-Peter Nilsson :

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

commit r11-5749-geb79f4db49c5f5a807555e9d374524664eb537bf
Author: Hans-Peter Nilsson 
Date:   Fri Dec 4 20:27:23 2020 +0100

doc/implement-c.texi: About same-as-scalar-type volatile aggregate
accesses, PR94600

We say very little about reads and writes to aggregate /
compound objects, just scalar objects (i.e. assignments don't
cause reads).  Let's lets say something safe about aggregate
objects, but only for those that are the same size as a scalar
type.

There's an equal-sounding section (Volatiles) in extend.texi,
but this seems a more appropriate place, as specifying the
behavior of a standard qualifier.

gcc:

2020-12-04  Hans-Peter Nilsson  
Martin Sebor  

PR middle-end/94600
* doc/implement-c.texi (Qualifiers implementation): Add blurb
about access to the whole of a volatile aggregate object, only for
same-size as a scalar object.