[Bug c/96253] decimal floating point missing on ARM

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Target||aarch64, arm

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c++/96257] [11 Regression] ICE in cp_parser_skip_to_pragma_eol, at cp/parser.c:3948

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug sanitizer/96259] New: Regression warning on GCC 10

[freddy77 at gmail dot com]

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

Bug ID: 96259
   Summary: Regression warning on GCC 10
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddy77 at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

I found this issue updating a software from Fedora 31 to Fedora 32. I manage to
reproduce the problem with this main.c file:


struct DataIn {
   int type;
   int dummy;
};

struct DataOut {
   struct DataIn in;
};

void func(struct DataOut *data)
{
   if (data->in.type) {
   __builtin_memset(&(data->in), 0, sizeof(struct DataIn));
   }
}


and using this command line:

   gcc -Warray-bounds=2 -Werror -O2 -fsanitize=address -c main.c

this is reporting:


: In function 'void func(DataOut*)':
:15:24: error: 'void* __builtin_memset(void*, int, long unsigned int)'
offset [4, 7] from the object at 'data' is out of the bounds of referenced
subobject 'DataIn::type' with type 'int' at offset 0 [-Werror=array-bounds]
   15 |__builtin_memset(&(data->in), 0, sizeof(struct DataIn));
  |^~~
:4:8: note: subobject 'DataIn::type' declared here
4 |int type;
  |^~~~
cc1plus: all warnings being treated as errors
Compiler returned: 1


I reproduced the issue using https://godbolt.org/ so I verified that this
happens with GCC 10.1 but not with GCC 9.3. It seems related to:
- nested structure
- having a "if" in the code
- "-Warray-bounds=2"
- "-fsanitize=address"

I know "-Warray-bounds=2" could have false positive but it's still a
regression.

[Bug target/92892] [AARCH64] TBL-based permutations can be implemented more efficiently for 2-element vectors

[rsandifo at gcc dot gnu.org]

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

Bug 82199 Summary: __builtin_shuffle sometimes should produce zip1 rather than 
TBL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82199

   What|Removed |Added

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

[Bug middle-end/88670] [meta-bug] generic vector extension issues

[rsandifo at gcc dot gnu.org]

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

Bug 82199 Summary: __builtin_shuffle sometimes should produce zip1 rather than 
TBL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82199

   What|Removed |Added

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

[Bug target/82199] __builtin_shuffle sometimes should produce zip1 rather than TBL

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.

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

[rsandifo at gcc dot gnu.org]

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

Bug 93720 Summary: [10/11 Regression] vector creation from two parts of two 
vectors produces TBL rather than ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93720

   What|Removed |Added

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

[Bug target/93720] [10/11 Regression] vector creation from two parts of two vectors produces TBL rather than ins

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||rsandifo at gcc dot gnu.org
 Status|ASSIGNED|RESOLVED

--- Comment #14 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.

[Bug target/96260] New: RISC-V: -fsanitize=kernel-address is not available after gcc10

[green.hu at gmail dot com]

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

Bug ID: 96260
   Summary: RISC-V: -fsanitize=kernel-address is not available
after gcc10
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: green.hu at gmail dot com
  Target Milestone: ---
Target: riscv64

It used to work to build riscv64 Linux kernel with this option
"-fsanitize=kernel-address" for KASAN in gcc9 however it doesn't work in gcc10.

cc1: warning: '-fsanitize=address' and '-fsanitize=kernel-address' are not
supported for this target

[Bug target/93720] [10/11 Regression] vector creation from two parts of two vectors produces TBL rather than ins

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|10.2|11.0

[Bug target/96260] RISC-V: -fsanitize=kernel-address is not available after gcc10

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Depends on||91441

--- Comment #1 from Andreas Schwab  ---
See PR91441.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91441
[Bug 91441] ICE in asan_shadow_offset at asan.c:342 on riscv64 target

[Bug debug/96261] New: -fcompare-debug failure (length) with -Os -fno-gcse-lm -fnon-call-exceptions

[zsojka at seznam dot cz]

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

Bug ID: 96261
   Summary: -fcompare-debug failure (length) with -Os -fno-gcse-lm
-fnon-call-exceptions
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 48902
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48902&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os -fno-gcse-lm -fnon-call-exceptions
-fcompare-debug testcase.C
x86_64-pc-linux-gnu-gcc: error: testcase.C: '-fcompare-debug' failure (length)

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-2246-20200721142816-gc850a642e1d-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-2246-20200721142816-gc850a642e1d-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200721 (experimental) (GCC)

[Bug target/96262] New: [11 Regression] ICE: in decompose, at rtl.h:2280 with -O -mavx512bw

[zsojka at seznam dot cz]

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

Bug ID: 96262
   Summary: [11 Regression] ICE: in decompose, at rtl.h:2280 with
-O -mavx512bw
   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: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 48903
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48903&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mavx512bw testcase.c 
during RTL pass: combine
testcase.c: In function 'foo':
testcase.c:7:1: internal compiler error: in decompose, at rtl.h:2280
7 | }
  | ^
0x7267b9 wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
/repo/gcc-trunk/gcc/rtl.h:2280
0x7267b9 wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
/repo/gcc-trunk/gcc/wide-int.h:1024
0x7267b9 generic_wide_int
>::generic_wide_int >(std::pair const&)
/repo/gcc-trunk/gcc/wide-int.h:782
0x7267b9 simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/repo/gcc-trunk/gcc/simplify-rtx.c:1793
0x10ad410 simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/repo/gcc-trunk/gcc/simplify-rtx.c:868
0x10b0c6e simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/repo/gcc-trunk/gcc/simplify-rtx.c:1765
0x10ad410 simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/repo/gcc-trunk/gcc/simplify-rtx.c:868
0x1af73b5 combine_simplify_rtx
/repo/gcc-trunk/gcc/combine.c:5785
0x1afa007 subst
/repo/gcc-trunk/gcc/combine.c:5725
0x1afa16e subst
/repo/gcc-trunk/gcc/combine.c:5658
0x1afa16e subst
/repo/gcc-trunk/gcc/combine.c:5658
0x1afc126 try_combine
/repo/gcc-trunk/gcc/combine.c:3451
0x1b04f14 combine_instructions
/repo/gcc-trunk/gcc/combine.c:1324
0x1b04f14 rest_of_handle_combine
/repo/gcc-trunk/gcc/combine.c:15068
0x1b04f14 execute
/repo/gcc-trunk/gcc/combine.c:15113
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-2246-20200721142816-gc850a642e1d-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-2246-20200721142816-gc850a642e1d-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200721 (experimental) (GCC)

[Bug target/96263] New: [10/11 Regression] ICE: in lra_assign, at lra-assigns.c:1648 with -O -flive-range-shrinkage -fnon-call-exceptions -msse4 --param=max-sched-ready-insns=1

[zsojka at seznam dot cz]

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

Bug ID: 96263
   Summary: [10/11 Regression] ICE: in lra_assign, at
lra-assigns.c:1648 with -O -flive-range-shrinkage
-fnon-call-exceptions -msse4
--param=max-sched-ready-insns=1
   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: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 48904
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48904&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -flive-range-shrinkage -fnon-call-exceptions
-msse4 --param=max-sched-ready-insns=1 testcase.c 
testcase.c: In function 'm':
testcase.c:12:1: warning: AVX512F vector return without AVX512F enabled changes
the ABI [-Wpsabi]
   12 | a m(unsigned short n, __int128 o) {
  | ^
during RTL pass: reload
testcase.c:27:1: internal compiler error: in lra_assign, at lra-assigns.c:1648
   27 | }
  | ^
0xefe25b lra_assign(bool&)
/repo/gcc-trunk/gcc/lra-assigns.c:1648
0xef7f3c lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.c:2465
0xea7949 do_reload
/repo/gcc-trunk/gcc/ira.c:5525
0xea7949 execute
/repo/gcc-trunk/gcc/ira.c:5711
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-2246-20200721142816-gc850a642e1d-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-2246-20200721142816-gc850a642e1d-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200721 (experimental) (GCC)

[Bug rtl-optimization/96264] New: [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter

[zsojka at seznam dot cz]

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

Bug ID: 96264
   Summary: [10/11 Regression] wrong code with -Os
-fno-forward-propagate -fschedule-insns -fno-tree-ter
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: powerpc64le-unknown-linux-gnu

Created attachment 48905
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48905&action=edit
reduced testcase

$ powerpc64le-unknown-linux-gnu-gcc -Os -fno-forward-propagate -fschedule-insns
-fno-tree-ter testcase.c -static
$ ./a.out 
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
(using qemu userspace emulation)

I am unable to find why is the generated code wrong; it might be also a qemu
error.

$ powerpc64le-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-2246-20200721142816-gc850a642e1d-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu
--with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-2246-20200721142816-gc850a642e1d-checking-yes-rtl-df-extra-powerpc64le
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200721 (experimental) (GCC)

[Bug target/96260] RISC-V: -fsanitize=kernel-address is not available after gcc10

[kito at gcc dot gnu.org]

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

Kito Cheng  changed:

   What|Removed |Added

 CC||kito at gcc dot gnu.org

--- Comment #2 from Kito Cheng  ---
Yeah, seems like I fix PR91441 in wrong way.

[Bug target/96265] New: building nvptx-none on platforms other than x86_64-linux-gnu, e.g. aarch64-linux-gnu and powerpc64le-linux-gnu

[doko at debian dot org]

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

Bug ID: 96265
   Summary: building nvptx-none on platforms other than
x86_64-linux-gnu, e.g. aarch64-linux-gnu and
powerpc64le-linux-gnu
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

The nvptx-target usually is built on x86_64-linux-gnu, but searching the web
you'll see that these GPUs are also used in aarch64-linux-gnu and
powerpc64le-linux-gnu systems.

building the nvptx offload compiler on powerpc64le, you see reasonable test
results for libgomp,  and I see at last one powerpc64le related commit:

2015-10-09  James Norris  

* config/rs6000/rs6000.c (rs6000_offload_options): New.
(TARGET_OFFLOAD_OPTIONS): New.

However adding an aarch64_offload_options hook doesn't look that well for
AArch64, there are still two type of issues triggered in the testsuite:

FAIL: libgomp.c/../libgomp.c-c++-common/for-11.c (test for excess errors)
Excess errors:
lto1: fatal error: nvptx-none - 0-bit integer numbers unsupported (mode 'SI')


and:

NRESOLVED: libgomp.c/../libgomp.c-c++-common/for-9.c compilation failed to
produce executable
UNSUPPORTED: libgomp.c/../libgomp.c-c++-common/function-not-offloaded-aux.c

spawn -ignore SIGHUP /home/ubuntu/gcc-10-10.1.0/build/./gcc/xgcc
-B/home/ubuntu/gcc-10-10.1.0/build/./gcc/ -B/usr/aarch64-linux-gnu/b
in/ -B/usr/aarch64-linux-gnu/lib/ -isystem /usr/aarch64-linux-gnu/include
-isystem /usr/aarch64-linux-gnu/sys-include -isystem /home/
ubuntu/gcc-10-10.1.0/build/sys-include -fchecking=1
offload_device_nonshared_as411951.c
-B/home/ubuntu/gcc-10-10.1.0/build/aarch64-li
nux-gnu/./libgomp/
-B/home/ubuntu/gcc-10-10.1.0/build/aarch64-linux-gnu/./libgomp/.libs
-I/home/ubuntu/gcc-10-10.1.0/build/aarch64-li
nux-gnu/./libgomp -I../../../../src/libgomp/testsuite/../../include
-I../../../../src/libgomp/testsuite/.. -Lno -fmessage-length=0 -f
no-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never
-B/home/ubuntu/gcc-10-10.1.0/debian/tmp-nvptx/usr/libexec/gcc/aarch64-li
nux-gnu/10 -B/home/ubuntu/gcc-10-10.1.0/debian/tmp-nvptx/usr/bin -fopenmp
-L/home/ubuntu/gcc-10-10.1.0/build/aarch64-linux-gnu/./libg
omp/.libs -lm -o offload_device_nonshared_as411951.exe
lto1: internal compiler error: bytecode stream: string too long for the string
table
0x62559f string_for_index
../../src-nvptx/gcc/data-streamer-in.c:53
0x62559f bp_unpack_indexed_string(data_in*, bitpack_d*, unsigned int*)
../../src-nvptx/gcc/data-streamer-in.c:97
0x87a39b lto_input_mode_table(lto_file_decl_data*)
../../src-nvptx/gcc/lto-streamer-in.c:1685
0x5a076f lto_file_finalize
../../src-nvptx/gcc/lto/lto-common.c:2217
0x5a076f lto_create_files_from_ids
../../src-nvptx/gcc/lto/lto-common.c:2240
0x5a076f lto_file_read
../../src-nvptx/gcc/lto/lto-common.c:2295
0x5a076f read_cgraph_and_symbols(unsigned int, char const**)
../../src-nvptx/gcc/lto/lto-common.c:2747
0x58f523 lto_main()
../../src-nvptx/gcc/lto/lto.c:625
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug c++/96266] New: Macro defined as enum in parens resolves to 1

[ethouris at gmail dot com]

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

Bug ID: 96266
   Summary: Macro defined as enum in parens resolves to 1
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ethouris at gmail dot com
  Target Milestone: ---

Created attachment 48906
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48906&action=edit
Preprocessed C++ file with example.

I'm attaching a quite long preprocessed file, but all "simplified examples"
didn't reproduce it. I'm not even sure if this is a bug or a feature (maybe
something related to resolving into `defined()` pp function), but it definitely
works not according to the intention.

This can also be my mistake, but if so, I'm completely unable to find it
despite best efforts.

In short:
1. There's an enum defined, one value is, say, `UPDATE = 0x10`
2. There's a macro defined: `#define ETONLY (UPDATE)`
3. The variable is passed as `int x = 0x11`.
4. The expression `x & ETONLY` resolves to... 1 (not 0x10).

Workaround:
1. Define `ETONLY` as `(0 | UPDATE)`
2. Expression `x & int(ETONLY)` resolves correctly to 0x10.

Tested on gcc 7.5 and some older, including 4.4.

[Bug c++/96266] Macro defined as enum in parens resolves to 1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I think it is just testcase bug.
In particular the
inline bool operator&(int flags, SRT_EPOLL_OPT eflg)
{ 
return (flags & int(eflg)) != 0;
}
operator is a very bad idea, because then any of the & operations where you
expect it to work like it would without the operator behave differently.

[Bug libfortran/93567] G edit descriptor uses E instead of F editing in rounding mode UP

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> It gets complicated quickly with all the corner cases. 

I tried to simplify, but I did find anything simpler and working.

> Last line of the added logic needs a space before the 0

Yes.

I have learnt enough git to follow the GCC evolution, but I am not ready (yet?)
to do any commit.

[Bug fortran/88080] Add warning if IMPLICIT NONE is missing

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-21
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
IMO it is a coding policy. If one want to enforce implicit none, (s)he uses 
-fimplicit-none.

I am in favor to close this PR as WONTFIX.

[Bug c++/96266] Macro defined as enum in parens resolves to 1

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Michal Malecki from comment #0)
> I'm attaching a quite long preprocessed file, but all "simplified examples"
> didn't reproduce it.

Of course they do. This has nothing to do with macros or parentheses.


#include 

enum SRT_EPOLL_OPT
{
   SRT_EPOLL_UPDATE = 0x10,
};

inline bool operator&(int flags, SRT_EPOLL_OPT eflg)
{
return (flags & int(eflg)) != 0;
}

using namespace std;

int main() {

int evts = 0x11;

int et_evts = (evts & SRT_EPOLL_UPDATE);

 cout << (SRT_EPOLL_UPDATE) << " " << et_evts << " " << evts << endl;
}


As Jakub said, your operator& is used here and is doing exactly what you told
it to do, returning a bool.

[Bug gcov-profile/96267] New: gcov-tool merge more coverage data error.

[dongjianqiang2 at huawei dot com]

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

Bug ID: 96267
   Summary: gcov-tool merge more coverage data error.
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dongjianqiang2 at huawei dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48907
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48907&action=edit
gcda files

Hi, I use a cross compiler using a cross compiler (--build=x86_64-suse-linux
--host=x86_64-suse-linux --target=aarch64_be-linux-gnu) gcov-tool to merge tree
profiles generated by big endian machine. 
gcov-tool merge dir1 dir2 -o dir12
gcov-tool merge dir3 dir12 -o dir123

I am confronted with "./main.gcda:incorrect gcov version xx vs yyy"
error.

known to fail on all active branches.

[Bug sanitizer/96259] Regression warning on GCC 10

[freddy77 at gmail dot com]

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

--- Comment #1 from Frediano Ziglio  ---
The commit introducing this regression is:

commit 6889a3acfeed47265886676c6d43b04ef799fb82
Author: Martin Sebor 
Date:   Thu Sep 19 22:15:34 2019 +

PR middle-end/91631 - buffer overflow into an array member of a declared
object not detected

...

From-SVN: r275981

[Bug gcov-profile/96267] gcov-tool merge more coverage data error.

[dongjianqiang2 at huawei dot com]

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

--- Comment #1 from John Dong  ---
Created attachment 48908
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48908&action=edit
add missing IN_GCOV_TOOL macro

hmmm refer to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95332
Fix missing IN_GCOV_TOOL macro. please review it.

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[dave.anglin at bell dot net]

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

--- Comment #31 from dave.anglin at bell dot net ---
On 2020-07-13 7:20 a.m., redi at gcc dot gnu.org wrote:
> Dave, did you test this for the gcc-8 branch? Do you still want it backported
> to that branch?
Yes please.  The patch applies cleanly on the gcc-8 branch.  Then, we can close
this PR.

Thanks,
Dave

[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.2

[Bug target/96263] [10/11 Regression] ICE: in lra_assign, at lra-assigns.c:1648 with -O -flive-range-shrinkage -fnon-call-exceptions -msse4 --param=max-sched-ready-insns=1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ra
   Target Milestone|--- |10.2

[Bug target/96262] [11 Regression] ICE: in decompose, at rtl.h:2280 with -O -mavx512bw

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug target/96260] [10/11 Regression] RISC-V: -fsanitize=kernel-address is not available after gcc10

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.2
Summary|RISC-V: |[10/11 Regression] RISC-V:
   |-fsanitize=kernel-address   |-fsanitize=kernel-address
   |is not available after  |is not available after
   |gcc10   |gcc10

[Bug sanitizer/96259] [10/11 Regression] warning on GCC 10

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.2
Summary|Regression warning on GCC   |[10/11 Regression] warning
   |10  |on GCC 10
   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[cvs-commit at gcc dot gnu.org]

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

--- Comment #32 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:

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

commit r8-10367-gc54d4e218f18c66ce1ad9d7e7762357fd7edacb7
Author: Jonathan Wakely 
Date:   Mon Jan 28 23:58:57 2019 +

PR libstdc++/68737 Do not use vsnprintf on HPUX

It doesn't conform to the spec, so use vsprintf with a large buffer
instead.

PR libstdc++/68737
* config/locale/generic/c_locale.h (__convert_from_v)
[_GLIBCXX_USE_C99_STDIO]: Also check
_GLIBCXX_HAVE_BROKEN_VSNPRINTF.
* config/os/hpux/os_defines.h: Define
_GLIBCXX_HAVE_BROKEN_VSNPRINTF.
* include/bits/locale_facets.tcc (num_put::_M_insert_float)
[_GLIBCXX_USE_C99_STDIO]: Also check
_GLIBCXX_HAVE_BROKEN_VSNPRINTF.

(cherry picked from commit c98f255154798847bdd1fc6ce33266c1a1ddc13a)

[Bug c++/96268] New: class-type NTTP CTAD for string-literal aggregate fails on aggregate initialization

[wjwray at gmail dot com]

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

Bug ID: 96268
   Summary: class-type NTTP CTAD for string-literal aggregate
fails on aggregate initialization
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wjwray at gmail dot com
  Target Milestone: ---

I understand that gcc is ahead of the standard in its implementation of class-
type NTTP, along with CTAD and accepting braced init-lists as template Args.
Thanks for implementing it. This bug is an edge case in the handling of a
braced string literal argument for a 'static string' - a motivating use case. 

Example code on Compiler Explorer https://godbolt.org/z/sMWhbx

Given this 'static_string' implementation, as an aggregate (no constructors):

  template 
  struct static_string { char chars[N]; /* operator<=> */ };

  template 
  static_string(char const(&)[N]) -> static_string;

A variable can be deduced and initialized from braced string-literal:

  static_string hi = {"hi"}; // Accepted

(Aggregate-init of char array from string-literal being a special case.)
However, this same braced string-literal fails as a class-type NTTP:

  template  struct name {};

  using Hi = name<{"hi"}>; // Reject, should accept?

It appears to CTAD-deduce correctly then fail on the aggregate initialization:

  error: could not convert '{"hi"}' from '
  to 'static_string<3>'
  | name<{"hi"}>;
  |^
  ||
  |

[Bug fortran/94599] Invalid constructor for derived types with recursive allocatable components

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from at least GCC7.

[Bug fortran/96255] [F2018] Implement optional type spec for index in DO CONCURRENT

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

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

Will Schmidt  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #19 from Will Schmidt  ---
closed.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

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

Will Schmidt  changed:

   What|Removed |Added

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

--- Comment #18 from Will Schmidt  ---
fix committed, should be done here.   Thanks.

[Bug libstdc++/96269] New: optional comparison with nullopt fails

[sshannin at gmail dot com]

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

Bug ID: 96269
   Summary: optional comparison with nullopt fails
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sshannin at gmail dot com
  Target Milestone: ---

Consider the following:

seth@dev6:~/tmp$ cat opt.cpp
#include 

struct X {
  template 
  bool operator==(const T&) {
return false;
  }
};

bool foo() {
  std::optional x;
#ifndef FLIP
  return x == std::nullopt;
#else
  return std::nullopt == x;
#endif
}

With gcc 9.1.0, this compiles regardless of whether or not FLIP is defined.

With gcc 10.1.0 however, the FLIP variant does not compile.

seth@dev6:~/tmp$ /toolchain15/bin/g++ -c -o opt.o opt.cpp --std=c++20
seth@dev6:~/tmp$ /toolchain15/bin/g++ -c -o opt.o opt.cpp --std=c++20 -DFLIP
In file included from opt.cpp:1:
/toolchain15/include/c++/10.1.0/optional: In instantiation of ‘constexpr
std::__optional_relop_t() == declval<_Tp>()))>
std::operator==(const _Up&, const std::optional<_Tp>&) [with _Tp = X; _Up =
std::nullopt_t; std::__optional_relop_t() ==
declval<_Tp>()))> = bool; decltype ((declval<_Up>() == declval<_Tp>())) =
bool]’
...etc...

It's a tad hard for me to keep track of which overloads are supposed to
exist/how they're supposed to resolve and I think introduction of <=> was
expected to change behavior here a bit, so I'm not actually sure if this is
supposed to compile still.

seth@dev6:~/tmp$ /toolchain15/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/toolchain15/bin/g++
COLLECT_LTO_WRAPPER=/toolchain15/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc_10_1_0/configure --prefix=/toolchain15
--enable-languages=c,c++,fortran --enable-lto --disable-plugin
--program-suffix=-10.1.0 --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC)

[Bug c++/96257] [11 Regression] ICE in cp_parser_skip_to_pragma_eol, at cp/parser.c:3948

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-07-21
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r11-2106-gf0d0be62db5ba030283fa8189211830d09dfb467

[Bug sanitizer/96259] [10/11 Regression] warning on GCC 10

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Martin Sebor  ---
Confirmed.  The warning works as designed.  The cause of the problem, as in a
number of other similar cases that have been reported recently (including
pr94655 with the same root cause), is FRE substituting a smaller member for a
larger member at the same address.  Before fre4 the IL corresponds to the
access in the source code:

func (struct DataOut * data)
{
  int _1;
  struct DataIn * _2;
  int * _7;

   [local count: 1073741824]:
  _7 = &data_5(D)->in.type;
  .ASAN_CHECK (6, _7, 4, 4);
  _1 = data_5(D)->in.type;
  if (_1 != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 354334800]:
  _2 = &data_5(D)->in;  <<< destination
  __builtin_memset (_2, 0, 8);  <<< okay

   [local count: 1073741824]:
  return;
}

Then fre4 turns the above into:

func (struct DataOut * data)
{
  int _1;
  int * _7;

   [local count: 1073741824]:
  _7 = &data_5(D)->in.type; <<< destination
  .ASAN_CHECK (6, _7, 4, 4);
  _1 = data_5(D)->in.type;
  if (_1 != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 354334800]:
  __builtin_memset (_7, 0, 8);  <<< warning

   [local count: 1073741824]:
  return;

}

There is nothing the warning can do to differentiate the result of this
transformation from a bug in the source code.  To avoid compromising the
utility of the warning, either the transformation needs to change or the IL
needs to somehow/somewhere preserve the original destination of the access.  (I
plan to look into the former.)

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

[Bug tree-optimization/94655] [10/11 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||freddy77 at gmail dot com

--- Comment #10 from Martin Sebor  ---
*** Bug 96259 has been marked as a duplicate of this bug. ***

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-07-21
 CC||mpolacek at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Seems to have started with r11-2137-g765fbbf9bb398560f45987ea9858dfaaefff5ce0

[Bug fortran/88080] Add warning if IMPLICIT NONE is missing

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #2)
> IMO it is a coding policy. If one want to enforce implicit none, (s)he uses 
> -fimplicit-none.
> 
> I am in favor to close this PR as WONTFIX.

+1

[Bug c++/96241] [9/10/11 Regression] ICE in verify_ctor_sanity

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-07-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
It used to compile, then since r269003 I see

96241.C:19:3: error: accessing value of ‘‘result_decl’ not supported by
dump_expr’ through a ‘s’ glvalue in a constant expression
   19 | }();
  |   ^

and since r10-6437-g0712ea6313bc44f9ae8feb235c1b02c92cdd0527

internal compiler error: in verify_ctor_sanity, at cp/constexpr.c:3987
   19 | }();
  | ^
0x9a4a50 verify_ctor_sanity
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:3987
0x9a4dd2 cxx_eval_bare_aggregate
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:4030
0x9ae1ad cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6216
0x9a3459 cxx_eval_array_reference
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:3660
0x9adde5 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6140
0x9a34f3 cxx_eval_component_reference
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:3677
0x9ade7c cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6155
0x9a710e cxx_eval_indirect_ref
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:4545
0x9ad7a6 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5979
0x9ae322 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6251
0x9a0e76 cxx_eval_binary_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:3027
0x9add07 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6117
0x9ae322 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6251
0x9a905e cxx_eval_store_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:4777
0x9ad0dd cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5858
0x9adc4d cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6063
0x9ae322 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6251
0x9ae322 cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:6251
0x9a9d7f cxx_eval_store_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5038
0x9ad0dd cxx_eval_constant_expression
/home/mpolacek/src/gcc/gcc/cp/constexpr.c:5858

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #33 from Jonathan Wakely  ---
Also fixed for 8.5.0 now.

[Bug libstdc++/96269] optional comparison with nullopt fails

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Your operator== should be const-qualified.

[Bug c++/96268] class-type NTTP CTAD for string-literal aggregate fails on aggregate initialization

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
I suppose it should work.

[Bug c++/96268] class-type NTTP CTAD for string-literal aggregate fails on aggregate initialization

[wjwray at gmail dot com]

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

--- Comment #2 from Will Wray  ---
Thanks Marek (and thanks again for implementing it) - it does seem so.
I've asked around a little - tcanens and brevzin point to a core issue
to do with NTTP CTAD but didn't offer an opinion or encourage this bug.

It is specific to the case of an aggregate implementation, of course;
adding a constructor from char array enables initialization from either
braced string-literal, bare string-literal or constexpr char array.

Note: if this aggregate init of NTTP from string-literal is accepted
then it provides a technique to distinguish between a string-literal
and an array of char const (exercise for reader) (P1997 proposes to
enable aggregate init of char array from char array which would then
break this distinction, by generalising from the special case.)

[Bug fortran/94070] Assumed-rank arrays – bounds mishandled, SIZE/SHAPE/UBOUND/LBOUND

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-21
   Priority|P3  |P4
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #5 from Dominique d'Humieres  ---
Confirmed.

[Bug libfortran/93592] Invalid UP/DOWN rounding with EN descriptor

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
Created attachment 48909
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48909&action=edit
Extensive test with RZ and EN

[Bug libfortran/93592] Invalid UP/DOWN rounding with EN descriptor

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
Created attachment 48910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48910&action=edit
Extensive test with RN and EN

[Bug libfortran/93592] Invalid UP/DOWN rounding with EN descriptor

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #7 from Dominique d'Humieres  ---
Could someone used to git commit the fix and the tests and back port them to
all the active branches?

[Bug target/96247] -falign-functions=0 works wrongly

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
There is an interplay between -falign-functions and the aligned function
attribute so changes to one (either the implementation or the documentation)
should be reviewed for an impact on the other and vice versa.

Attribute aligned is documented to require "an integer constant power of 2,"
with other values, including zero, being ignored with a warning.  Keeping the
option in sync with the attribute (and warning on the same set on invalid
arguments) seems like a good approach to me.

[Bug libgomp/93305] [OpenACC] 'acc_shutdown' vs. active data lifetimes

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   See Also||https://github.com/OpenACC/
   ||openacc-spec/issues/102
   Last reconfirmed|2020-01-20 00:00:00 |2020-7-21

--- Comment #1 from Thomas Schwinge  ---
(In reply to Thomas Schwinge from comment #0)
> It's less clear what should happen when after an 'acc_shutdown' we then
> again (implicitly/explicitly) 'acc_init': how/which state gets restored?

Discussion in  is relevant.

[Bug c++/96268] class-type NTTP CTAD for string-literal aggregate fails on aggregate initialization

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
name<{"hi"}> would work if convert_nontype_argument called digest_init for the
CONSTRUCTOR.  This reminds me of another PR where I wanted to add such a
digest_init call, but in the end wound up doing something different.
Obviously, we don't want to open the door too wide here.

[Bug c/96270] New: stdarg malfunction with -m32 and -Os

[drh at sqlite dot org]

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

Bug ID: 96270
   Summary: stdarg malfunction with -m32 and -Os
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drh at sqlite dot org
  Target Milestone: ---

gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2), the Default install on ubuntu 20.04

A long long int varargs parameter goes in as 0xfff7 but comes out as
0x. In other words, bit 35 is getting set somehow.  (The "7"
changes to an "f".) This only happens with -m32 and one of -O2 or -Os.  It
works correctly with -O0, -O1 or without -m32.

Test program "b1.c" shown below.  To compile and run:

 gcc -Os -m32 b1.c && ./a.out 1

The test program:

//
#include 
#include 
#include 
struct val {
  union {
double r;
long long int i;
  } u;
  unsigned char type;
};
void f1(const char *b, ...){
  long long int v;
  va_list ap;
  va_start(ap, b);
  v = va_arg(ap, long long int);
  printf("IN f1:   %016llx\n", v);
  va_end(ap);
}
void f2(struct val *p){
  if( p->type & 0x01 ){
f1("1",p->u.i);
  }else{
f1("3",p->u.r);
  }
}
int main(int argc, char **argv){
  int i;
  struct val x;
  x.u.i = -2251799813685249LL;
  for(i=1; i

[Bug c++/96197] Excess memory consumption, positive correlation with the size of a constexpr array

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick Palka  ---
Looking into it.

[Bug libstdc++/96269] optional comparison with nullopt fails

[sshannin at gmail dot com]

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

--- Comment #2 from sshannin at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> Your operator== should be const-qualified.

I don't disagree. I can also fully remove the operator== and it compiles as
well (why should the presence of the non-const operator== cause the comparison
with nullopt in one direction to instantiate it).

But yeah, I lost something in my reduction in there. I think the main point is
that one direction of the comparison instantiates the templated operator== and
the other doesn't.

Consider this version of X instead, which avoids the const issues:
struct X {
  int y;

  template 
  bool operator==(const T&o) const {
return y == o.summary();
  }
};

We again end up instantiating X's operator== (even though we wouldn't call it)
in the FLIP case (and thus fail to compile), but in the non-flip case
everything seems fine.

[Bug c/96270] stdarg malfunction with -m32 and -Os

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
I can reproduce on x86_64 with gcc-7/8/9/10/11 -Os -m32, disappears with -O2. 
gcc-11 -fsanitize=undefined gives no diagnostic and also masks the error. 
gcc-6 and older work (tested back to 4.1.2).  I cannot reproduce on powerpc64
or m68k.

[Bug tree-optimization/96271] New: Failure to optimize memcmp of doubles to avoid going through memory

[gabravier at gmail dot com]

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

Bug ID: 96271
   Summary: Failure to optimize memcmp of doubles to avoid going
through memory
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

bool f(double a, double b)
{
   return memcmp(&a, &b, sizeof(double)) == 0;
}

With -O3, LLVM outputs this :

f(double, double):
  movq rax, xmm0
  movq rcx, xmm1
  cmp rax, rcx
  sete al
  ret

GCC outputs this:

f(double, double):
  movsd QWORD PTR [rsp-8], xmm0
  movsd QWORD PTR [rsp-16], xmm1
  mov rax, QWORD PTR [rsp-16]
  cmp QWORD PTR [rsp-8], rax
  sete al
  ret

[Bug c/96270] [8/9/10/11 Regression] stdarg malfunction with -m32 and -Os

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-21
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|stdarg malfunction with |[8/9/10/11 Regression]
   |-m32 and -Os|stdarg malfunction with
   ||-m32 and -Os
   Target Milestone|--- |8.5
 Status|UNCONFIRMED |NEW

--- Comment #2 from Jakub Jelinek  ---
Changed with r241329.
And the difference between that and the previous revision is
@@ -26,25 +26,25 @@ f2 (struct val * p)
 {
   unsigned char _1;
   unsigned char _8;
-  long long int pretmp_11;
-  double _12;
+  double pretmp_11;
+  long long int _12;

   :
   _1 = p_6(D)->type;
   _8 = _1 & 1;
-  pretmp_11 = p_6(D)->u.i;
+  pretmp_11 = p_6(D)->u.r;
   if (_8 != 0)
 goto ;
   else
 goto ;

   :
-  f1 ("1", pretmp_11); [tail call]
+  _12 = VIEW_CONVERT_EXPR(pretmp_11);
+  f1 ("1", _12); [tail call]
   goto ;

   :
-  _12 = VIEW_CONVERT_EXPR(pretmp_11);
-  f1 ("3", _12); [tail call]
+  f1 ("3", pretmp_11); [tail call]

   :
   return;

Using a floating point type to hold the pretmp when it also contains
non-floating point values (or other floating point types) looks wrong.

[Bug c++/96257] [11 Regression] ICE in cp_parser_skip_to_pragma_eol, at cp/parser.c:3948

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from Nathan Sidwell  ---
shouldn't that test add -fopenmp to the options?

[Bug c++/96257] [11 Regression] ICE in cp_parser_skip_to_pragma_eol, at cp/parser.c:3948

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
I think gomp.exp adds -fopenmp -Wno-hsa automatically.

[Bug tree-optimization/96272] New: Failure to optimize overflow check

[gabravier at gmail dot com]

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

Bug ID: 96272
   Summary: Failure to optimize overflow check
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

static inline unsigned f(unsigned a, unsigned b)
{
if (b > UINT_MAX - a)
return UINT_MAX;

return a + b;
}

With -O3, LLVM outputs this:

f(unsigned int, unsigned int):
  add edi, esi
  mov eax, -1
  cmovae eax, edi
  ret

GCC outputs this:

f(unsigned int, unsigned int):
  mov eax, edi
  not eax
  add edi, esi
  cmp eax, esi
  mov eax, -1
  cmovnb eax, edi
  ret

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:02363d5fdb862a11e6e65ac5b0d1f5ee0c422dc3

commit r11-2255-g02363d5fdb862a11e6e65ac5b0d1f5ee0c422dc3
Author: Uros Bizjak 
Date:   Tue Jul 21 20:22:05 2020 +0200

i386: Fix insn conditions of mfence patterns [PR95750]

2020-07-21  Uroš Bizjak  

gcc/ChangeLog:
PR target/95750
* config/i386/sync.md (mfence_sse2): Enable for
TARGET_64BIT and TARGET_SSE2.
(mfence_nosse): Always enable.

[Bug target/96271] Failure to optimize memcmp of doubles to avoid going through memory

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |target

--- Comment #1 from Andrew Pinski  ---
Did you try -march=intel ?

[Bug c++/96251] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #3 from Iain Sandoe  ---
thanks for the report

[Bug middle-end/95988] New: [10/11 Regression] Bogus -Warray-bounds/-Wstringop-overflow warning with loop

[pinskia at gcc dot gnu.org]

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

Bug ID: 95988
   Summary: [10/11 Regression] Bogus
-Warray-bounds/-Wstringop-overflow warning  with loop
   Product: gcc
   Version: 10.0
Status: NEW
  Keywords: diagnostic
  Severity: normal
  Priority: P2
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Depends on: 94655
  Target Milestone: 10.2
  Target Milestone: 10.2
CC: msebor at gcc dot gnu.org
  Last reconfirmed: 2020-06-30
Status: NEW
  Priority: P2
Ever confirmed: 1
Depends on: 94655

Compile with -O2 -W -Wall:

void f(int*);
void g(int*);
struct  sched_group_t {
  int lock;
  struct {
   char name[32 + 1];
   int aa;
  } group[(3 + 9)];
} ;
struct sched_global_t {
 char t[(3 + 9)][3];
 struct sched_group_t sched_group;
};

struct sched_global_t *sched_global;

int hh(const char *name)
{
 struct sched_group_t *sched_group = &sched_global->sched_group;
 int i;

 g(&sched_group->lock);

 for (i = 3; i < (3 + 9); i++) {
  if (!sched_group->group[i].aa) 
  {
   char *grp_name = sched_group->group[i].name;
__builtin_strncpy(grp_name, name, 32 - 1);
grp_name[32 - 1] = 0;
   break;
  }
 }
 f(&sched_group->lock);
 return 0;
}

--- CUT ---
t.c: In function ‘hh’:
t.c:28:5: warning: ‘__builtin_strncpy’ offset [124, 484] is out of the bounds
[0, 4] [-Warray-bounds]
   28 | __builtin_strncpy(grp_name, name, 32 - 1);
  | ^
t.c:29:22: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   29 | grp_name[32 - 1] = 0;
  | ~^~~
t.c:4:7: note: at offset 155 to object ‘lock’ with size 4 declared here
4 |   int lock;
  |   ^~~~

--- Comment #1 from Andrew Pinski  ---
The problem is related to &sched_global->sched_group and
&sched_global->sched_group->lock are at the same location, so GCC seems to
select the MEM for &sched_global->sched_group->lock for both. THIS is just a
diagnostic issue of the warning.

--- Comment #2 from Andrew Pinski  ---
Note unlike other -Warray-bounds/-Wstringop-overflow warnings, there is no
flexiable array in effect here.  Rather it is due to using the offset for
sched_global->sched_group and sched_global->sched_group.lock issue.

--- Comment #3 from Andrew Pinski  ---
I should mention this was reduced from upstream ODP
(https://opendataplane.org/) Linux generic version.

--- Comment #4 from Andrew Pinski  ---
I think this is related to PR 94655.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655
[Bug 94655] [10/11 Regression] Implicit assignment operator triggers
stringop-overflow warning since r10-5451-gef29b12cfbb4979a

[Bug libfortran/93592] Invalid UP/DOWN rounding with EN descriptor

[anlauf at gcc dot gnu.org]

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #7)
> Could someone used to git commit the fix and the tests and back port them to
> all the active branches?

I think the normal procedure would be to submit this for review first.

[Bug c++/96003] [11 Regression] spurious -Wnonnull calling a member on the result of static_cast

[sbergman at redhat dot com]

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

--- Comment #11 from Stephan Bergmann  ---
(In reply to Martin Sebor from comment #10)
> Patch for the static cast:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550231.html

LibreOffice runs into the same issue, but while the above patch fixes my first
reduced test case

> $ cat test1.cc
> struct S1 {};
> struct S2: S1 {};
> struct S3: S1 {};
> struct S4: S2, S3 { void f(); };
> void g(S3 * p) { static_cast(p)->f(); }

it does not fix the second

> $ cat test2.cc
> struct S1 { virtual ~S1(); };
> struct S2 { virtual ~S2(); };
> struct S3: S1, S2 { void f() const; };
> void g(S2 * p) { static_cast(p)->f(); }

> $ g++ -Wnonnull -fsyntax-only test2.cc
> test2.cc: In function ‘void g(S2*)’:
> test2.cc:4:48: warning: ‘this’ pointer null [-Wnonnull]
> 4 | void g(S2 * p) { static_cast(p)->f(); }
>   |^
> test2.cc:3:26: note: in a call to non-static member function ‘void S3::f() 
> const’
> 3 | struct S3: S1, S2 { void f() const; };
>   |  ^

[Bug c++/96257] [11 Regression] ICE in cp_parser_skip_to_pragma_eol, at cp/parser.c:3948

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Yeah (unless overridden).

[Bug fortran/89574] [8/9/10/11 Regression] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3792

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:28f2a080cc27531a8c78aec9f44aeff4961c2a4c

commit r11-2256-g28f2a080cc27531a8c78aec9f44aeff4961c2a4c
Author: Harald Anlauf 
Date:   Tue Jul 21 21:37:30 2020 +0200

PR fortran/89574 - ICE in conv_function_val, at fortran/trans-expr.c:3792

When checking for an external procedure from the same file, do not
consider symbols from different modules.

gcc/fortran/
PR fortran/89574
* trans-decl.c (gfc_get_extern_function_decl): Check whether a
symbol belongs to a different module.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[rafael at espindo dot la]

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

--- Comment #31 from Rafael Avila de Espindola  ---
Hi Iain,

Any update on this? If there is any way I can help, please let me know. It has
been a decade since I looked into gcc, but I should still be able to test
patches or implement small side changes.

[Bug fortran/96255] [F2018] Implement optional type spec for index in DO CONCURRENT

[jvdelisle at charter dot net]

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

--- Comment #4 from jvdelisle at charter dot net ---
(In reply to kargl from comment #1)
> This is related to PR78219.
> 
> If someone takes up the challenge, then this show accept only
> standard conforming type specs.  That is, INTEGER*4 should be
> rejected.  This means one should use the method introduced in
> array.c(gfc_match_array_constructor) for code to match
> a type spec in an array constructor.  Looks like a copy and
> paste with an additional check for INTEGER.

Agree 200%, tired of people implementing the bad.

[Bug fortran/96255] [F2018] Implement optional type spec for index in DO CONCURRENT

[jvdelisle at charter dot net]

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

--- Comment #5 from jvdelisle at charter dot net ---
(In reply to kargl from comment #2)
> This issue depends on the fix for FORALL.  In gfc_match_do in the concurrent
> section, one gets to 
> 
>   m = match_forall_header (&head, &mask);
> 
> to match the control portion of the statement.

Although we need to support forall, it is interesting that the standards
committe i going to deprecate it, if they have not done so already. Not
encouraged to be used for sure. Also they will be adding features to DO
CONCUURENT which look useful to me.

[Bug c++/96257] [11 Regression] ICE in cp_parser_skip_to_pragma_eol, at cp/parser.c:3948

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
Fixed 4d6e94960aa

The reason I didn't originally see this is it's a C testcase, not a C++ one :)

[Bug c++/96197] Excess memory consumption, positive correlation with the size of a constexpr array

[tridacnid at gmail dot com]

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

Joe Burzinski  changed:

   What|Removed |Added

 CC||tridacnid at gmail dot com

--- Comment #6 from Joe Burzinski  ---
gcc 8.3.1

I just ran into almost this exact scenario. We use constexpr for catching
inconsistencies at compile time and a recent conversion of 50ish arrays of 100
elements takes an unknown amount of time to compile (I killed the build as I
ate into my last GB of swap) and used ~46GB of RAM + ~16GB of swap. I'm unable
to test on a later version of gcc but plugging the test case into godbolt
compiles on clang but runs out of memory when using gcc 10.1 and trunk.

I was able to trim the case down to get it to a compile time of 33s using ~24GB
of memory. The same trimmed down case compiles in less than a second and a
couple hundred MB of memory with clang10 for comparison.

[Bug middle-end/95988] [10/11 Regression] Bogus -Warray-bounds/-Wstringop-overflow warning with loop

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Blocks||56456
 Status|NEW |RESOLVED

--- Comment #5 from Martin Sebor  ---
Yes, it's a duplicate of pr94655 (and pr96259 reported just this morning).

The warning in this case is based on the following IL:

  _2 = &MEM[(struct sched_group_t *)sched_global.0_1 + 36B].lock;
  ...
 _4 = (sizetype) i_19;
  _5 = _4 * 40;
  _18 = _5 + 4;
  grp_name_10 = _2 + _18;
  __builtin_strncpy (grp_name_10, name_11(D), 31);
  MEM[(char *)grp_name_10 + 31B] = 0;

specifically grp_name_10 pointing to the lock member plus an offset it
determines is out of the bounds of the member for all elements of the enclosing
array.

The apparently out of bounds destination is substituted for the in bounds one
in the source by the PRE pass.  Just prior to it, the IL is:

  _4 = (sizetype) i_19;
  _5 = _4 * 40;
  _18 = _5 + 4;
  _17 = &MEM[(struct sched_group_t *)sched_global.0_1 + 36B];
  grp_name_10 = _17 + _18;
  __builtin_strncpy (grp_name_10, name_11(D), 31);
  MEM[(char *)grp_name_10 + 31B] = 0;

which doesn't provide a justification for the warning.  All middle end warnings
that attempt to detect invalid/out of bounds accesses (e.g., -Warray-bounds and
-Wstringo-overflow and others) rely on the subject (ether object or subobject)
in expressions like ARRAY_REF, COMPONENT_REF, and MEM_REF corresponding to the
source.  Transformations that break that assumption lead to false positives. 
To avoid compromising the utility of the warnings, either the transformations
need to change (e.g., to use MEM_REF (base, offset) rather than COMPONENT_REF
(MEM_REF ...)) or the IL needs to somehow/somewhere preserve the original
destination of the access.  (I plan to look into the former.)  Otherwise, the
only way to avoid issuing the warning would be to give up analyzing anything
with a MEM_REF in it.  Since MEM_REFs are pervasive in the IL (all but the most
trivial pointer accesses are transformed into one) this would reduce the
effectiveness of the warnings to just the trivial subset of code.

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug tree-optimization/94655] [10/11 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #11 from Martin Sebor  ---
*** Bug 95988 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 95988 Summary: [10/11 Regression] Bogus -Warray-bounds/-Wstringop-overflow 
warning  with loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95988

   What|Removed |Added

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

[Bug fortran/96255] [F2018] Implement optional type spec for index in DO CONCURRENT

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Tue, Jul 21, 2020 at 07:44:16PM +, jvdelisle at charter dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255
> 
> --- Comment #5 from jvdelisle at charter dot net ---
> (In reply to kargl from comment #2)
> > This issue depends on the fix for FORALL.  In gfc_match_do in the concurrent
> > section, one gets to 
> > 
> >   m = match_forall_header (&head, &mask);
> > 
> > to match the control portion of the statement.
> 
> Although we need to support forall, it is interesting that the standards
> committe i going to deprecate it, if they have not done so already. Not
> encouraged to be used for sure. Also they will be adding features to DO
> CONCUURENT which look useful to me.
> 

do current (JUNK HERE)


forall (JUNK HERE)

The JUNK HERE is parsed by the same code; namely, match_forall_header().

So, if one fixes do current, then one fixes forall.

PS: J3 has an interesting discussion that suggests that do current
is also broken.

[Bug c++/96273] New: ice in extract_insn, at recog.c:2294, unrecognizable insn:

[dcb314 at hotmail dot com]

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

Bug ID: 96273
   Summary: ice in extract_insn, at recog.c:2294, unrecognizable
insn:
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 48911
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48911&action=edit
gzipped C++ source code

The attached C++ code does this with today's gcc trunk:

splat.cpp:1637:1: error: unrecognizable insn:
(insn 1137 1136 1138 163 (set (mem/v:BLK (scratch:DI) [0  A8])
(unspec:BLK [
(mem/v:BLK (scratch:DI) [0  A8])
] UNSPEC_MFENCE)) -1
 (nil))
during RTL pass: vregs
splat.cpp:1637:1: internal compiler error: in extract_insn, at recog.c:2294
0xef8b46 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../trunk.git/gcc/rtl-error.c:108
0xef8b6b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../trunk.git/gcc/rtl-error.c:116
0xebf423 extract_insn(rtx_insn*)
../../trunk.git/gcc/recog.c:2294

Flags -O3 -march=native required. native is Piledriver. I'll
have a go at reducing the code.

This code used to work at date 20200719, so someone has broken
something in the last day or two.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[iains at gcc dot gnu.org]

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

--- Comment #32 from Iain Sandoe  ---
(In reply to Rafael Avila de Espindola from comment #31)
> Hi Iain,
> 
> Any update on this? If there is any way I can help, please let me know. It
> has been a decade since I looked into gcc, but I should still be able to
> test patches or implement small side changes.

I was working on a wider problem, now need to re-analyze this.

A quick look says we have a similar issue to one already solved (that was
duplicate use of a dtor).  When we switch sanitize off, the gimple generated
correctly re-loads the this pointer for both the catch and finally clauses.

When sanitize=undefined is on, it seems to conclude (incorrectly) that a temp
loaded for the catch clause can be re-used for the finally clause.  Not sure at
present where the error is creeping in.

(so from my quick test, your case passes without -fsanitize=undefined, the
DTORs run correctly - no abort() .. and it fails with the sanitiser engaged
because the DTOR gets a nonsense this ptr.

[Bug c++/96003] [11 Regression] spurious -Wnonnull calling a member on the result of static_cast

[msebor at gcc dot gnu.org]

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

--- Comment #12 from Martin Sebor  ---
Thanks for the test case.  In it, the no-warning bit set on the conditional
expression to avoid the warning is cleared before the expression reaches the
warning code.  The culprit seems to be the cp_fold_convert() function called on
the expression: it rebuilds the COND_EXPR but fails to propagate the no-warning
bit.  The change below fixes it but I wouldn't be surprised if this wasn't the
only instance where the no-warning bit might get stripped from an expression.

diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 300d959278b..67153e3f484 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -8754,6 +8754,7 @@ fold_unary_loc (location_t loc, enum tree_code code, tree
type, tree op0)
arg02 = fold_build1_loc (loc, code, type,
 fold_convert_loc (loc,
   TREE_TYPE (op0), arg02));
+ bool nowarn = TREE_NO_WARNING (op0);
  tem = fold_build3_loc (loc, COND_EXPR, type, TREE_OPERAND (arg0, 0),
 arg01, arg02);

@@ -8788,6 +8789,8 @@ fold_unary_loc (location_t loc, enum tree_code code, tree
type, tree op0)
  TREE_OPERAND (TREE_OPERAND (tem, 1), 0),
  TREE_OPERAND (TREE_OPERAND (tem, 2),
0)));
+ if (nowarn)
+   TREE_NO_WARNING (tem) = true;
  return tem;
}
}

[Bug tree-optimization/94655] [10/11 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |major

[Bug target/96273] ice in extract_insn, at recog.c:2294, unrecognizable insn:

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Reduced C++ code:

int b, c, e;
int d[1];
void f() {
  int a;
  for (;;) {
c = 0;
for (; c <= 1000; b += 10, c++) {
  a = 0;
  for (; a < 10; a++)
if (b)
  e += d[b] = e;
}
  }
}

[Bug testsuite/96274] New: [11 regression] gcc.target/powerpc/convert-fp-128.c breaks on power 9 after r11-2206

[seurer at gcc dot gnu.org]

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

Bug ID: 96274
   Summary: [11 regression] gcc.target/powerpc/convert-fp-128.c
breaks on power 9 after r11-2206
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:8a8c2573568aa17ada6163f90991701bc4470976, r11-2206

r11-2206 broke one test case on power 9 (only):

make -k check-gcc RUNTESTFLAGS=powerpc.exp=gcc.target/powerpc/convert-fp-128.c
FAIL: gcc.target/powerpc/convert-fp-128.c scan-assembler-times \\mbl\\M 27
# of expected passes38
# of unexpected failures1

Other power Xs:

# of expected passes39

[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Peter Bergner :

https://gcc.gnu.org/g:699f9c0cc1bcc8acfd78c02315c963bf790c874d

commit r11-2258-g699f9c0cc1bcc8acfd78c02315c963bf790c874d
Author: Peter Bergner 
Date:   Tue Jul 21 16:20:33 2020 -0500

rs6000: Update test case count when compiling for power9

2020-07-21  Peter Bergner  

gcc/testsuite/
PR target/92488
* gcc.target/powerpc/convert-fp-128.c (bl): Update POWER9 count.

[Bug middle-end/84051] [7/8/9 Regression] missing -Warray-bounds on an out-of-bounds access via an array pointer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Testing a simple enhancement teaching gimple-array-bounds.cc how to detect this
case.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 84051 Summary: [7/8/9 Regression] missing -Warray-bounds on an 
out-of-bounds access via an array pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84051

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|WONTFIX |---

[Bug libfortran/93567] G edit descriptor uses E instead of F editing in rounding mode UP

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
Simpler patch with comments

--- ../_clean/libgfortran/io/write_float.def2020-06-13 03:11:55.0
+0200
+++ libgfortran/io/write_float.def  2020-07-21 23:03:08.0 +0200
@@ -987,16 +987,19 @@ determine_en_precision (st_parameter_dt 
  w = default_width;\
  d = precision;\
}\
+  /* The switch between FMT_E and FMT_F is based on the absolute value.  \
+ Set r=0 for rounding toward zero and r = 1 otherwise.  \
+If (exp_d - m) == 1 there is no rounding needed.  */\
   switch (dtp->u.p.current_unit->round_status)\
{\
  case ROUND_ZERO:\
-   r = sign_bit ? 1.0 : 0.0;\
+   r = 0.0;\
break;\
  case ROUND_UP:\
-   r = 1.0;\
+   r = sign_bit ? 0.0 : 1.0;\
break;\
  case ROUND_DOWN:\
-   r = 0.0;\
+   r = sign_bit ? 1.0 : 0.0;\
break;\
  default:\
break;\
@@ -1004,7 +1007,8 @@ determine_en_precision (st_parameter_dt 
   exp_d = calculate_exp_ ## x (d);\
   r_sc = (1 - r / exp_d);\
   temp = 0.1 * r_sc;\
-  if ((m > 0.0 && ((m < temp) || (r >= (exp_d - m\
+  if ((m > 0.0 && ((m < temp) || (r < 1 && r >= (exp_d - m))\
+ || (r == 1 && 1 > (exp_d - m\
  || ((m == 0.0) && !(compile_options.allow_std\
  & (GFC_STD_F2003 | GFC_STD_F2008)))\
  ||  d == 0)\

[Bug testsuite/96274] [11 regression] gcc.target/powerpc/convert-fp-128.c breaks on power 9 after r11-2206

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

   Last reconfirmed||2020-7-21
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Peter Bergner  ---
Confirmed.  I have already pushed an obvious patch to fix the test case asm
count when compiled on power9.

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

[iii at linux dot ibm.com]

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

--- Comment #16 from Ilya Leoshkevich  ---
I finally managed to reproduce this by doing `./configure
--host=aarch64-none-linux-gnu` on gcc113. The problem is that `CXX_FOR_BUILD`
doesn't seem to be set correctly - normally it's `g++-4.8.1 -std=gnu++11`, but
in this case it's just `g++`. I'm currently trying to wrap my head around
autotools build setup in order to figure out where exactly things went wrong.

[Bug target/96271] Failure to optimize memcmp of doubles to avoid going through memory

[gabravier at gmail dot com]

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

--- Comment #2 from Gabriel Ravier  ---
What do you mean ? -march=intel doesn't exist and I have tried -mtune=intel, I
see no difference in the handling of this regardless of any -march/tune flags
(I've tried : none, -march=nocona, -march=tigerlake, -mtune=intel,
-march=znver2), unless there is somehow a big problem with `movq r64, xmm` on
all x86-64 processors, this should be considered a bug.

[Bug libfortran/93592] Invalid UP/DOWN rounding with EN descriptor

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
Patch submitted at https://gcc.gnu.org/pipermail/fortran/2020-July/054769.html.

[Bug libfortran/93567] G edit descriptor uses E instead of F editing in rounding mode UP

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
patch submitted at https://gcc.gnu.org/pipermail/fortran/2020-July/054770.html.

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
This should now work too:

  int (&&r)[3] = static_cast(42);
  int (&&r2)[1] = static_cast(42);

and in both cases the reference declarations lifetime-extend the array
temporary.

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2259-g0a9d711df36b42b6494b73a90c7ebf050e904493
Author: Sunil K Pandey 
Date:   Fri Jul 17 19:42:09 2020 -0700

Add TARGET_LOWER_LOCAL_DECL_ALIGNMENT [PR95237]

Default for this hook is NOP. For x86, in 32 bit mode, this hook
sets alignment of long long on stack to 32 bits if preferred stack
boundary is 32 bits.

  - This patch prevents lowering of alignment from following macros.
LOCAL_ALIGNMENT
STACK_SLOT_ALIGNMENT
LOCAL_DECL_ALIGNMENT
  - This patch fixes
gcc.target/i386/pr69454-2.c
gcc.target/i386/stackalign/longlong-1.c
  - Regression test on x86-64, no new fail introduced.

Tested on x86-64.

gcc/c/ChangeLog:

PR target/95237
* c-decl.c (finish_decl): Call target hook
lower_local_decl_alignment to lower local decl alignment.

gcc/ChangeLog:

PR target/95237
* config/i386/i386-protos.h (ix86_local_alignment): Add
another function parameter may_lower alignment. Default is
false.
* config/i386/i386.c (ix86_lower_local_decl_alignment): New
function.
(ix86_local_alignment): Amend ix86_local_alignment to accept
another parameter may_lower. If may_lower is true, new align
may be lower than incoming alignment. If may_lower is false,
new align will be greater or equal to incoming alignment.
(TARGET_LOWER_LOCAL_DECL_ALIGNMENT): Define.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (TARGET_LOWER_LOCAL_DECL_ALIGNMENT): New
hook.
* target.def (lower_local_decl_alignment): New hook.

gcc/cp/ChangeLog:

PR target/95237
* decl.c (cp_finish_decl): Call target hook
lower_local_decl_alignment to lower local decl alignment.

gcc/testsuite/ChangeLog:

PR target/95237
* c-c++-common/pr95237-1.c: New test.
* c-c++-common/pr95237-2.c: New test.
* c-c++-common/pr95237-3.c: New test.
* c-c++-common/pr95237-4.c: New test.
* c-c++-common/pr95237-5.c: New test.
* c-c++-common/pr95237-6.c: New test.
* c-c++-common/pr95237-7.c: New test.
* c-c++-common/pr95237-8.c: New test.
* c-c++-common/pr95237-9.c: New test.

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #22 from H.J. Lu  ---
Fixed.