[Bug bootstrap/96735] --enable-maintainer-mode broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96735 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2020-08-22 --- Comment #3 from Thomas Koenig --- Hm, did I run the make from within the gcc directory? Have to see if this re-occurs...
[Bug target/96744] New: [11 Regression] FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96744 Bug ID: 96744 Summary: [11 Regression] FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution test Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: crazylht at gmail dot com Target Milestone: --- Target: x86-84 On Linux/x86 without AVX512, r11-2796 caused: FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c execution test FAIL: gcc.target/i386/avx512bitalgvl-vpopcntw-1.c execution test FAIL: gcc.target/i386/avx512bitalgvl-vpshufbitqmb-1.c execution test FAIL: gcc.target/i386/avx512bitalg-vpopcntb-1.c execution test FAIL: gcc.target/i386/avx512bitalg-vpopcntw-1.c execution test FAIL: gcc.target/i386/avx512bitalg-vpshufbitqmb-1.c execution test FAIL: gcc.target/i386/avx512f-gf2p8affineinvqb-2.c execution test FAIL: gcc.target/i386/avx512f-gf2p8affineqb-2.c execution test FAIL: gcc.target/i386/avx512f-gf2p8mulb-2.c execution test FAIL: gcc.target/i386/avx512f-vpcompressb-2.c execution test FAIL: gcc.target/i386/avx512f-vpcompressw-2.c execution test FAIL: gcc.target/i386/avx512f-vpexpandb-2.c execution test FAIL: gcc.target/i386/avx512f-vpexpandw-2.c execution test FAIL: gcc.target/i386/avx512f-vpshldd-2.c execution test FAIL: gcc.target/i386/avx512f-vpshldq-2.c execution test FAIL: gcc.target/i386/avx512f-vpshldvd-2.c execution test FAIL: gcc.target/i386/avx512f-vpshldvq-2.c execution test FAIL: gcc.target/i386/avx512f-vpshldvw-2.c execution test FAIL: gcc.target/i386/avx512f-vpshrdd-2.c execution test FAIL: gcc.target/i386/avx512f-vpshrdq-2.c execution test FAIL: gcc.target/i386/avx512f-vpshrdvd-2.c execution test FAIL: gcc.target/i386/avx512f-vpshrdvq-2.c execution test FAIL: gcc.target/i386/avx512f-vpshrdvw-2.c execution test FAIL: gcc.target/i386/avx512f-vpshrdw-2.c execution test FAIL: gcc.target/i386/avx512vbmi-vpermb-2.c execution test FAIL: gcc.target/i386/avx512vbmi-vpermi2b-2.c execution test FAIL: gcc.target/i386/avx512vbmi-vpermt2b-2.c execution test FAIL: gcc.target/i386/avx512vbmi-vpmultishiftqb-2.c execution test FAIL: gcc.target/i386/avx512vl-gf2p8affineinvqb-2.c execution test FAIL: gcc.target/i386/avx512vl-gf2p8affineqb-2.c execution test FAIL: gcc.target/i386/avx512vl-gf2p8mulb-2.c execution test FAIL: gcc.target/i386/avx512vl-vpclmulqdq-2.c execution test FAIL: gcc.target/i386/avx512vl-vpcompressb-2.c execution test FAIL: gcc.target/i386/avx512vl-vpcompressw-2.c execution test FAIL: gcc.target/i386/avx512vl-vpermb-2.c execution test FAIL: gcc.target/i386/avx512vl-vpermi2b-2.c execution test FAIL: gcc.target/i386/avx512vl-vpermt2b-2.c execution test FAIL: gcc.target/i386/avx512vl-vpexpandb-2.c execution test FAIL: gcc.target/i386/avx512vl-vpexpandw-2.c execution test FAIL: gcc.target/i386/avx512vl-vpmultishiftqb-2.c execution test FAIL: gcc.target/i386/avx512vl-vpshldd-2.c execution test FAIL: gcc.target/i386/avx512vl-vpshldq-2.c execution test FAIL: gcc.target/i386/avx512vl-vpshldvd-2.c execution test FAIL: gcc.target/i386/avx512vl-vpshldvq-2.c execution test FAIL: gcc.target/i386/avx512vl-vpshldvw-2.c execution test FAIL: gcc.target/i386/avx512vl-vpshrdd-2.c execution test FAIL: gcc.target/i386/avx512vl-vpshrdq-2.c execution test FAIL: gcc.target/i386/avx512vl-vpshrdvd-2.c execution test FAIL: gcc.target/i386/avx512vl-vpshrdvq-2.c execution test FAIL: gcc.target/i386/avx512vl-vpshrdvw-2.c execution test FAIL: gcc.target/i386/avx512vl-vpshrdw-2.c execution test FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntd-1.c execution test
[Bug c++/96745] New: [concepts] internal compiler error: in type_memfn_rqual, at cp/typeck.c:10389
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96745
Bug ID: 96745
Summary: [concepts] internal compiler error: in
type_memfn_rqual, at cp/typeck.c:10389
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: src at andyf dot de
Target Milestone: ---
Hello,
the following code gives an internal compiler error.
template
struct Test {
~Test() requires true {}
~Test() requires true && true {}
};
Test t;
Error:
: In instantiation of 'struct Test':
:7:11: required from here
:2:8: internal compiler error: in type_memfn_rqual, at
cp/typeck.c:10389
2 | struct Test {
|^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug analyzer/94851] -fanalyzer erroneously reporting NULL dereference - simple test case attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94851 --- Comment #6 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:df2b78d407a3fe8685343f7249b9c31c7e3af44d commit r11-2807-gdf2b78d407a3fe8685343f7249b9c31c7e3af44d Author: David Malcolm Date: Sat Aug 22 06:30:17 2020 -0400 analyzer: fix NULL deref false positives [PR94851] PR analyzer/94851 reports various false "NULL dereference" diagnostics. The first case (comment #1) affects GCC 10.2 but no longer affects trunk; I believe it was fixed by the state rewrite of r11-2694-g808f4dfeb3a95f50f15e71148e5c1067f90a126d. The patch adds a regression test for this case. The other cases (comment #3 and comment #4) still affect trunk. In both cases, the && in a conditional is optimized to bitwise & _1 = p_4 != 0B; _2 = p_4 != q_6(D); _3 = _1 & _2; and the analyzer fails to fold this for the case where one (or both) of the conditionals is false, and thus erroneously considers the path where "p" is non-NULL despite being passed a NULL value. Fix this by implementing folding for this case. gcc/analyzer/ChangeLog: PR analyzer/94851 * region-model-manager.cc (region_model_manager::maybe_fold_binop): Fold bitwise "& 0" to 0. gcc/testsuite/ChangeLog: PR analyzer/94851 * gcc.dg/analyzer/pr94851-1.c: New test. * gcc.dg/analyzer/pr94851-3.c: New test. * gcc.dg/analyzer/pr94851-4.c: New test.
[Bug analyzer/94851] -fanalyzer erroneously reporting NULL dereference - simple test case attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94851 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from David Malcolm --- Thanks for reporting these. These false positives should now be fixed in git (for GCC 11); see the above commit.
[Bug c++/96746] New: Type Casting in template function should not be type-dependent if the type of the conversion result is not type-dependent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96746
Bug ID: 96746
Summary: Type Casting in template function should not be
type-dependent if the type of the conversion result is
not type-dependent.
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: masamitsu.murase at gmail dot com
Target Milestone: ---
The following code compiles fine with GCC 11.0, but I think that it should not
compile
because of the mismatch of the argument type of "func_with_int_arg" at (*1) .
#include
void func_with_int_arg(int) {}
template
std::enable_if_t::value>
func(T arg)
{
func_with_int_arg(static_cast(arg)); // (*1)
}
template
std::enable_if_t::value>
func(T) {}
int main(int, char **)
{
func(1); // Instantiate func
}
According to C++17 specification, "static_cast(arg)" is NOT
type-dependent.
because "int*" is not dependent.
"17.6.2.2 Type-dependent expressions" says as follows:
Expressions of the following forms are type-dependent only if the type
specified by the type-id, simple-type-specifier or new-type-id is
dependent,
even if any subexpression is type-dependent:
...(snip)...
dynamic_cast (expression)
static_cast (expression)
const_cast (expression)
...(snip)...
Therefore, "func_with_int_arg(static_cast(arg));" at (*1) should cause a
hard error
instead of a substitution failure.
By the way, the above code does not compile fine with Clang 12.0.
The error message is:
sample.cpp:9:9: error: no matching function for call to 'func_with_int_arg'
func_with_int_arg(static_cast(arg)); // (*1)
^
sample.cpp:3:10: note: candidate function not viable: no known conversion
from 'int *' to 'int' for 1st argument; dereference the argument with *
void func_with_int_arg(int) {}
^
1 error generated.
Regards,
Murase
[Bug tree-optimization/96654] Failure to optimize vectorized conversion to `int` with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96654 --- Comment #2 from Marc Glisse --- gcc doesn't seem very fond of using 2 different vector bitsizes at the same time, so VEC_PACK_FIX_TRUNC_EXPR takes 2 vectors of 2 double and gives one vector of 4 int. At the RTL level, we have a vec_concat:V4DF of 2 V2DF adjacent in memory, but nothing knows to turn that into a single load. (the conversion itself of 4 double to int is fine)
[Bug c/96747] New: -Wshadow accepts included extern variable shadowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96747 Bug ID: 96747 Summary: -Wshadow accepts included extern variable shadowing Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: matous-dev at criptext dot com Target Milestone: --- Created attachment 49098 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49098&action=edit -save-temps *.i output When I compile the attached code with gcc -Wshadow ./gcc-shadow-test.c it passes with no output/warnings. The warning about shadowing is displayed properly by g++, clang and clang++ and the first print() actually proves that gcc does see the "environ" variable from unistd.h but ignores it when resolving shadowing. gcc -v: Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-10.2.0/work/gcc-10.2.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/10.2.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/10.2.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/10.2.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/10.2.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include/g++-v10 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/10.2.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 10.2.0 p1' --disable-esp --enable-libstdcxx-time --with-build-config=bootstrap-lto --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-systemtap --enable-vtable-verify --with-zstd --enable-lto --without-isl --enable-default-pie --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.0 (Gentoo 10.2.0 p1)
[Bug c/96748] New: ICE in get_default_value, at tree-ssa-ccp.c:311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96748 Bug ID: 96748 Summary: ICE in get_default_value, at tree-ssa-ccp.c:311 Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: manuel.lauss at googlemail dot com Target Milestone: --- The attached unreduced testcase, isolated from wireshark-3.2.6, ICEs in get_default_value, at tree-ssa-ccp.c:311, with current 10.2.1 branch. It goes away with -O1 or when dropping -fno-strict-overflow at -O2 or higher. # gcc -fno-strict-overflow -O2 -c packet-ieee80211.i during GIMPLE pass: ccp /tmp-ram/portage/net-analyzer/wireshark-3.2.6/work/wireshark-3.2.6/epan/dissectors/packet-ieee80211.c: In function 'dissect_quiet_time_period.constprop': /tmp-ram/portage/net-analyzer/wireshark-3.2.6/work/wireshark-3.2.6/epan/dissectors/packet-ieee80211.c:12484:1: internal compiler error: in get_default_value, at tree-ssa-ccp.c:311 12484 | dissect_quiet_time_period(tvbuff_t *tvb, packet_info *pinfo _U_, | ^ 0x7fcac1d5adc9 __libc_start_main ../csu/libc-start.c:314 Please submit a full bug report, with preprocessed source if appropriate. # gcc --version gcc (Gentoo 10.2.1 p1) 10.2.1 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug fortran/96737] ICE when compiling module and submodule in same file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96737 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Dominique d'Humieres --- I see the error if I compile the test with -g.
[Bug tree-optimization/96748] ICE in get_default_value, at tree-ssa-ccp.c:311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96748 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2020-08-23 --- Comment #1 from Andrew Pinski --- >The attached unreduced testcase It did NOT attach. Maybe it is a bit too big. Maybe try to compress it.
[Bug middle-end/96733] std::clamp for floats and doubles produces worse code than a combo of std::min / std::max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96733 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/96748] ICE in get_default_value, at tree-ssa-ccp.c:311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96748 --- Comment #2 from Manuel Lauss --- Created attachment 49099 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49099&action=edit gzipped testcase Apologies, find the gzip compressed test source attached.
[Bug tree-optimization/96748] ICE in get_default_value, at tree-ssa-ccp.c:311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96748 Andrew Pinski changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0
[Bug c++/96749] New: [coroutines] unexpected 'warning: statement has no effect [-Wunused-value]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96749
Bug ID: 96749
Summary: [coroutines] unexpected 'warning: statement has no
effect [-Wunused-value]'
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bazhenov.dn at gmail dot com
Target Milestone: ---
C++ compiler throws unexpected 'statement with no effect' warning at the ending
brace of a coroutine function when it utilizes co_await expression returning
non-void value which is used as an rvalue within operators '+=', '-=', '*=',
etc.
The warning doesn't appear if the co_await expression is used as an rvalue
within simple assignment ('=') to a temporary variable and then the latter used
within '+=' or other operation.
The attached test code is composed to reveal the issue but is not meant to do
any job. The "#if" alternative in the code can be used to show how warning
disappears.
In a case of meaningful code which causes the warning the code works as
expected.
- g++ version:
g++ (GCC) 11.0.0 20200822 (experimental)
- configure pameters:
configure --disable-multilib
- system:
Linux beauty 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020
x86_64 x86_64 x86_64 GNU/Linux
- compiler command:
g++ -std=c++20 -O0 -g -Wall -fcoroutines -o test test.cpp
[Bug c++/96749] [coroutines] unexpected 'warning: statement has no effect [-Wunused-value]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96749 --- Comment #1 from Dmitry Bazhenov --- Created attachment 49101 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49101&action=edit statement-has-no-effect.cpp Code snippet revealing the problem.
[Bug c++/96750] New: 10-12% performance decrease in benchmark going from GCC8 to GCC9/GCC10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96750 Bug ID: 96750 Summary: 10-12% performance decrease in benchmark going from GCC8 to GCC9/GCC10 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mattreecebentley at gmail dot com Target Milestone: --- Created attachment 49102 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49102&action=edit Compiler output Have recently been working on a new version of the plf::colony container (plflib.org) and found GCC9 was giving ~10% worse performance on average in a given benchmark than GCC8. Further investigation found GCC10 was just as bad. The effect is repeatable across architectures - I've tested on xubuntu, windows running nuwen mingw, and on Core2 and Haswell CPUs, with and without -march=native specified. Compiler flags are: -O2;-march=native;-std=c++17 Code presented is with an absolute minimum use-case - other benchmarks have not shown such strong performance differences - including both simpler and more complex tests. So I cannot reduce further, please do not ask me to do so. The benchmark in question inserts into a container initially then iterates over container elements repeatedly, randomly erasing and/or inserting new elements. Compilers/environments used: Xubuntu 20: GCC8.4, GCC9.3, GCC10.0.1 Windows 7: Nuwen mingw GCC8.2, nuwen mingw GCC9.2 The attached code output is from the Xubuntu environment. Any questions let me know. I will help where I can, but my knowledge of assembly is limited. Information on code components: Nanotimer is a ~nanosecond-precision sub-timeslice cross-platform timer. Colony is a bucket-array-like unordered sequence container. The attached zip contains the build logs and compiler preprocessed outputs for GCC 8.4, 9.3 and 10.0.1 Thanks- Mat
