[Bug bootstrap/95712] configure-target-libgcc fails on s390x target because xgcc is not being built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712 --- Comment #10 from Alexander Egorenkov --- When i add the dependency in Makefile manually, then the parallel build works. Regards
[Bug bootstrap/95712] configure-target-libgcc fails on s390x target because xgcc is not being built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712 --- Comment #9 from Alexander Egorenkov --- Created attachment 48751 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48751&action=edit top gcc Makefile
[Bug bootstrap/95712] configure-target-libgcc fails on s390x target because xgcc is not being built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712 --- Comment #8 from Alexander Egorenkov --- $ make --version GNU Make 4.1 Built for s390x-ibm-linux-gnu In my top Makefile the dependecny on maybe-all-gcc is missing: configure-target-libgcc: ... I attached the top Makefile.
[Bug c++/95725] Confusing error diagnostic in an invalid template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725 --- Comment #7 from Haoxin Tu --- By the way, can you take a look at bug 95597 and bug 95659? I think GCC should accept the first case and shouldn't miss the error message in the second code. Those cases are different from this report.
[Bug c++/95735] New: ICE on invalid non-type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95735
Bug ID: 95735
Summary: ICE on invalid non-type template argument
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/v7iLPn.
```C++
template
requires requires { F(); }
bool v{};
void f() {
int x;
static_assert(v);
}
```
: In function 'void f()':
:7:19: error: parse error in template argument list
7 | static_assert(v);
| ^~~~
:7:19: error: template argument 1 is invalid
:7: confused by earlier errors, bailing out
Compiler returned: 1
Less silly example: https://godbolt.org/z/-bWfJ4.
```C++
template
requires requires { F(); }
bool v{};
void f() {
int x;
static_assert(v<[&] { x++; }>);
}
```
: In function 'void f()':
:7:19: error: 'f()::{x}' is not a
constant expression
7 | static_assert(v<[&] { x++; }>);
| ^~~
:7: confused by earlier errors, bailing out
Compiler returned: 1
[Bug target/95732] Use CPU dispatching to support mixing -fcf-protection with -mindirect-branch and -mfunction-return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95732 --- Comment #1 from Joseph C. Sible --- Thinking about this a bit more, it's a win for performance even if we ignore CET completely. In particular, it would let a single binary use retpolines only on CPUs that have the Spectre vulnerabilities that they mitigate.
[Bug c++/86441] instantiate_class_template() unable to re-execute constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86441
Boris Kolpackov changed:
What|Removed |Added
Version|8.1.0 |10.1.0
--- Comment #2 from Boris Kolpackov ---
I am running into what I believe is the same issue with GCC 10.1.0 and a
static_assert in shared_ptr's default ctor. Here is the code:
#include
struct object1
{
};
struct object2
{
std::shared_ptr o1;
};
If a plugin calls locate_ctor() for object2, it ends up with the following
error:
In file included from /usr/local/gcc10/include/c++/10.1.0/bits/move.h:57,
from /usr/local/gcc10/include/c++/10.1.0/bits/stl_pair.h:59,
from
/usr/local/gcc10/include/c++/10.1.0/bits/stl_algobase.h:64,
from
/usr/local/gcc10/include/c++/10.1.0/bits/char_traits.h:39,
from /usr/local/gcc10/include/c++/10.1.0/string:40,
from :7:
/usr/local/gcc10/include/c++/10.1.0/type_traits: In instantiation of ‘struct
std::is_default_constructible’:
/usr/local/gcc10/include/c++/10.1.0/type_traits:143:12: required from ‘struct
std::__and_,
std::is_default_constructible,
std::__not_,
std::__is_implicitly_default_constructible > > >’
/usr/local/gcc10/include/c++/10.1.0/bits/stl_pair.h:244:59: required by
substitution of ‘template,
std::is_default_constructible<_Dp>,
std::__not_,
std::__is_implicitly_default_constructible<_U2> > > >::value, bool>::type
> constexpr std::pair::pair() [with _U1 = int; _U2 = int;
typename std::enable_if,
std::is_default_constructible<_Dp>,
std::__not_,
std::__is_implicitly_default_constructible<_U2> > > >::value, bool>::type
= ]’
test3.hxx:47:31: required from here
/usr/local/gcc10/include/c++/10.1.0/type_traits:918:52: error: non-constant
condition for static assertion
918 |
static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
|
~~~^~~~
/usr/local/gcc10/include/c++/10.1.0/type_traits:918: confused by earlier
errors, bailing out
The stack trace for the same invocation (obtained with -dH) is as follows:
#0 0x7f8843fc4428 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
#1 0x7f8843fc602a in __GI_abort () at abort.c:89
#2 0x0229fc95 in real_abort () at
../../gcc-10.1.0/gcc/diagnostic.c:1911
#3 0x0229baf3 in diagnostic_action_after_output (context=0x332c5e0
, diag_kind=DK_ERROR) at
../../gcc-10.1.0/gcc/diagnostic.c:564
#4 0x0229d1fb in diagnostic_report_diagnostic (context=0x332c5e0
, diagnostic=0x7ffd503c5f20) at
../../gcc-10.1.0/gcc/diagnostic.c:1179
#5 0x0229d7bb in diagnostic_impl (richloc=0x7ffd503c5fb0,
metadata=0x0, opt=-1, gmsgid=0x2390648 "non-constant condition for static
assertion", ap=0x7ffd503c5f98,
kind=DK_ERROR) at ../../gcc-10.1.0/gcc/diagnostic.c:1316
#6 0x0229ed0d in error (gmsgid=0x2390648 "non-constant condition for
static assertion") at ../../gcc-10.1.0/gcc/diagnostic.c:1612
#7 0x00b2445a in finish_static_assert (condition=0x7f883e0178c0,
message=0x7f8841d1cbb0, location=2147484459, member_p=true) at
../../gcc-10.1.0/gcc/cp/semantics.c:9699
#8 0x00ac5f33 in instantiate_class_template_1 (type=0x7f883e030348) at
../../gcc-10.1.0/gcc/cp/pt.c:11823
#9 0x00ac66e2 in instantiate_class_template (type=0x7f883e030348) at
../../gcc-10.1.0/gcc/cp/pt.c:12101
#10 0x00b46487 in complete_type (type=0x7f883e030348) at
../../gcc-10.1.0/gcc/cp/typeck.c:137
#11 0x00b04bf7 in lookup_member (xbasetype=0x0, name=0x7f8843a89040,
protect=2, want_type=false, complain=3, afi=0x0) at
../../gcc-10.1.0/gcc/cp/search.c:1129
#12 0x00a39487 in lookup_qualified_name (scope=0x7f883e030348,
name=0x7f8843a89040, prefer_type=0, complain=false, find_hidden=false)
at ../../gcc-10.1.0/gcc/cp/name-lookup.c:6023
#13 0x00ad18bf in tsubst_qualified_id (qualified_id=0x7f8841db2af0,
args=0x7f883e0177e0, complain=1, in_decl=0x0, done=true, address_p=false)
at ../../gcc-10.1.0/gcc/cp/pt.c:16158
#14 0x00adc40c in tsubst_copy_and_build (t=0x7f8841db2af0,
args=0x7f883e0177e0, complain=1, in_decl=0x0, function_p=false,
integral_constant_expression_p=true)
at ../../gcc-10.1.0/gcc/cp/pt.c:19449
#15 0x00ada2d1 in tsubst_expr (t=0x7f8841db2af0, args=0x7f883e0177e0,
complain=1, in_decl=0x0, integral_constant_expression_p=true) at
../../gcc-10.1.0/gcc/cp/pt.c:18738
#16 0x00ac678e in tsubst_template_arg (t=0x7f8841db2af0,
args=0x7f883e0177e0, complain=1, in_decl=0x0) at
../../gcc-10.1.0/gcc/cp/pt.c:12119
#17 0x00ac8e09 in tsubst_template_args (t=0x7f8841da56c0,
args=0x7f883e0177e0, complain=1, in_decl=0x0) at
../../gcc-10.1.0/gcc/cp/pt.c:13168
#18 0x00ac9672 in tsubst_aggr_type (t=0x7f8841db3e70,
args=0x7f883e0177e0, complain=1, in_decl=0x0, entering_scope=1) at
../../gc
[Bug bootstrap/95712] configure-target-libgcc fails on s390x target because xgcc is not being built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712 Andrew Pinski changed: What|Removed |Added Keywords||build Component|libgcc |bootstrap --- Comment #7 from Andrew Pinski --- @if gcc-no-bootstrap configure-target-libgcc: maybe-all-gcc ... @endif gcc-no-bootstrap What version of GNU make are you using? Can you attach the toplevel Makefile? I checked the version that is generated for aarch64-linux-gnu that I configured for and it has: # Generic dependencies for target modules on host stuff, especially gcc configure-target-libgcc: maybe-all-gcc ...
[Bug bootstrap/95734] New: [11 regression] lots of ICEs after r11-1445
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95734 Bug ID: 95734 Summary: [11 regression] lots of ICEs after r11-1445 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- g:502d63b6d6141597bb18fd23c87736a1b384cf8f, r11-1445 This also appears to break bootstrap for powerpc64 > FAIL: gcc.dg/vmx/5-11.c -O0 (internal compiler error) > FAIL: gcc.dg/vmx/5-11.c -O0 (test for excess errors) > FAIL: gcc.dg/vmx/5-11.c -O1 (internal compiler error) > FAIL: gcc.dg/vmx/5-11.c -O1 (test for excess errors) > FAIL: gcc.dg/vmx/5-11.c -O2 (internal compiler error) > FAIL: gcc.dg/vmx/5-11.c -O2 (test for excess errors) > FAIL: gcc.dg/vmx/5-11.c -O2 -flto -fno-use-linker-plugin > -flto-partition=none (internal compiler error) > FAIL: gcc.dg/vmx/5-11.c -O2 -flto -fno-use-linker-plugin > -flto-partition=none (test for excess errors) > FAIL: gcc.dg/vmx/5-11.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects > (internal compiler error) > FAIL: gcc.dg/vmx/5-11.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects > (test for excess errors) > FAIL: gcc.dg/vmx/5-11.c -O3 -g (internal compiler error) > FAIL: gcc.dg/vmx/5-11.c -O3 -g (test for excess errors) > FAIL: gcc.dg/vmx/5-11.c -Os (internal compiler error) > FAIL: gcc.dg/vmx/5-11.c -Os (test for excess errors) > FAIL: gcc.dg/vmx/debug-4.c -O0 (internal compiler error) > FAIL: gcc.dg/vmx/debug-4.c -O0 (test for excess errors) > FAIL: gcc.dg/vmx/debug-4.c -O1 (internal compiler error) > FAIL: gcc.dg/vmx/debug-4.c -O1 (test for excess errors) > FAIL: gcc.dg/vmx/debug-4.c -O2 (internal compiler error) > FAIL: gcc.dg/vmx/debug-4.c -O2 (test for excess errors) > FAIL: gcc.dg/vmx/debug-4.c -O2 -flto -fno-use-linker-plugin > -flto-partition=none (internal compiler error) > FAIL: gcc.dg/vmx/debug-4.c -O2 -flto -fno-use-linker-plugin > -flto-partition=none (test for excess errors) > FAIL: gcc.dg/vmx/debug-4.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects (internal compiler error) > FAIL: gcc.dg/vmx/debug-4.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects (test for excess errors) > FAIL: gcc.dg/vmx/debug-4.c -O3 -g (internal compiler error) > FAIL: gcc.dg/vmx/debug-4.c -O3 -g (test for excess errors) > FAIL: gcc.dg/vmx/debug-4.c -Os (internal compiler error) > FAIL: gcc.dg/vmx/debug-4.c -Os (test for excess errors) > FAIL: gcc.dg/vmx/gcc-bug-f.c -O0 (internal compiler error) > FAIL: gcc.dg/vmx/gcc-bug-f.c -O0 (test for excess errors) > FAIL: gcc.dg/vmx/gcc-bug-f.c -O1 (internal compiler error) > FAIL: gcc.dg/vmx/gcc-bug-f.c -O1 (test for excess errors) > FAIL: gcc.dg/vmx/gcc-bug-f.c -O2 (internal compiler error) > FAIL: gcc.dg/vmx/gcc-bug-f.c -O2 (test for excess errors) > FAIL: gcc.dg/vmx/gcc-bug-f.c -O2 -flto -fno-use-linker-plugin > -flto-partition=none (internal compiler error) > FAIL: gcc.dg/vmx/gcc-bug-f.c -O2 -flto -fno-use-linker-plugin > -flto-partition=none (test for excess errors) > FAIL: gcc.dg/vmx/gcc-bug-f.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects (internal compiler error) > FAIL: gcc.dg/vmx/gcc-bug-f.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects (test for excess errors) > FAIL: gcc.dg/vmx/gcc-bug-f.c -O3 -g (internal compiler error) > FAIL: gcc.dg/vmx/gcc-bug-f.c -O3 -g (test for excess errors) > FAIL: gcc.dg/vmx/gcc-bug-f.c -Os (internal compiler error) > FAIL: gcc.dg/vmx/gcc-bug-f.c -Os (test for excess errors) > FAIL: gcc.dg/vmx/gcc-bug-g.c -O0 (internal compiler error) > FAIL: gcc.dg/vmx/gcc-bug-g.c -O0 (test for excess errors) > FAIL: gcc.dg/vmx/gcc-bug-g.c -O1 (internal compiler error) > FAIL: gcc.dg/vmx/gcc-bug-g.c -O1 (test for excess errors) > FAIL: gcc.dg/vmx/gcc-bug-g.c -O2 (internal compiler error) > FAIL: gcc.dg/vmx/gcc-bug-g.c -O2 (test for excess errors) > FAIL: gcc.dg/vmx/gcc-bug-g.c -O2 -flto -fno-use-linker-plugin > -flto-partition=none (internal compiler error) > FAIL: gcc.dg/vmx/gcc-bug-g.c -O2 -flto -fno-use-linker-plugin > -flto-partition=none (test for excess errors) > FAIL: gcc.dg/vmx/gcc-bug-g.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects (internal compiler error) > FAIL: gcc.dg/vmx/gcc-bug-g.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects (test for excess errors) > FAIL: gcc.dg/vmx/gcc-bug-g.c -O3 -g (internal compiler error) > FAIL: gcc.dg/vmx/gcc-bug-g.c -O3 -g (test for excess errors) > FAIL: gcc.dg/vmx/gcc-bug-g.c -Os (internal compiler error) > FAIL: gcc.dg/vmx/gcc-bug-g.c -Os (test for excess errors) > FAIL: gcc.dg/vmx/ops.c -O0 (internal compiler error) > FAIL: gcc.dg/vmx/ops.c -O0 (test for excess errors) > FAIL: gcc.dg/vmx/ops.c -O1 (internal
[Bug c++/95725] Confusing error diagnostic in an invalid template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725 --- Comment #6 from Haoxin Tu --- Hi, there. I hold the view that the compiler should have good fault tolerance, which means giving an input(even invalid), the compiler might emit appropriate error message diagnostics so that we can fix them into valid code according to the diagnostics. I have tested in both GCC and Clang, the results show that GCC has lots of unrelated diagnostic messages than Clang. In this report, GCC-trunk seems ok, but GCC-9 emits too many duplicated error messages. So I guess there might something not correct in FE. Finally, I am wondering if those cases are useful for the GCC community? If not, I will stop reporting similar test cases (invalid code but let GCC get confused while parsing it). Thank you all!
[Bug regression/95733] New: Building on PowerPC 64 Tests Fail With GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95733
Bug ID: 95733
Summary: Building on PowerPC 64 Tests Fail With GCC 11
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: xerofoify at gmail dot com
Target Milestone: ---
After building gcc as such:
../gcc/configure --enable-lanuages=c,c++ --enable-threads -disable-multilibs
--enable-checking=yes --prefix=/home/xerofoify/obdjir
it fails on running tests with make -k check with:
=== libgomp Summary ===
# of expected passes7764
# of expected failures 4
# of unsupported tests 573
make[4]: Leaving directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp/testsuite'
make[3]: Leaving directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp/testsuite'
make[3]: Entering directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp'
:
:
:
make DO=all multi-do # make
make[4]: Entering directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp'
if [ -z "" ]; then \
true; \
else \
rootpre=`${PWDCMD-pwd}`/; export rootpre; \
srcrootpre=`cd ../../../gcc/libgomp; ${PWDCMD-pwd}`/; export srcrootpre; \
lib=`echo "${rootpre}" | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
compiler="/home/xerofoify/obdjir/./gcc/xgcc -B/home/xerofoify/obdjir/./gcc/
-B/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/bin/
-B/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/lib/ -isystem
/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/include -isystem
/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/sys-include "; \
for i in `${compiler} --print-multi-lib 2>/dev/null`; do \
dir=`echo $i | sed -e 's/;.*$//'`; \
if [ "${dir}" = "." ]; then \
true; \
else \
if [ -d ../${dir}/${lib} ]; then \
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
if (cd ../${dir}/${lib}; make \
CFLAGS="-g -O2 ${flags}" \
CCASFLAGS=" ${flags}" \
FCFLAGS="-L. -Wall -L../libgfortran ${flags}" \
FFLAGS=" ${flags}" \
ADAFLAGS=" ${flags}" \
prefix="/home/xerofoify/obdjir" \
exec_prefix="/home/xerofoify/obdjir" \
GOCFLAGS="-O2 -g ${flags}" \
GDCFLAGS="-O2 -g ${flags}" \
CXXFLAGS="-g -O2 -D_GNU_SOURCE ${flags}" \
LIBCFLAGS="-g -O2 ${flags}" \
LIBCXXFLAGS="-g -O2 -D_GNU_SOURCE
-fno-implicit-templates ${flags}" \
LDFLAGS=" ${flags}" \
MULTIFLAGS="${flags}" \
DESTDIR="" \
INSTALL="/usr/bin/install -c" \
INSTALL_DATA="/usr/bin/install -c -m 644" \
INSTALL_PROGRAM="/usr/bin/install -c" \
INSTALL_SCRIPT="/usr/bin/install -c" \
all); then \
true; \
else \
exit 1; \
fi; \
else true; \
fi; \
fi; \
done; \
fi
make[4]: Leaving directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp'
make[3]: Leaving directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp'
make[2]: Leaving directory
`/home/xerofoify/obdjir/powerpc64le-unknown-linux-gnu/libgomp'
make[1]: Leaving directory `/home/xerofoify/obdjir'
make: *** [do-check] Error 2
make: Target `check' not remade because of errors.
[xerofoify@gcc2-power8 obdjir]$ cd bin
[xerofoify@gcc2-power8 bin]$ ./g++ -v
Using built-in specs.
COLLECT_GCC=./g++
COLLECT_LTO_WRAPPER=/home/xerofoify/obdjir/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: ../gcc/configure --enable-lanuages=c,c++ --enable-threads
-disable-multilibs --enable-checking=yes --prefix=/home/xerofoify/obdjir
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200613 (experimental) (GCC)
OpenMP should be enabled by default with C++ and therefore this seems to be a
regression.
[Bug tree-optimization/94969] [8/10 Regression] Invalid loop distribution since r8-2390-gdfbddbeb1ca912c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969 --- Comment #16 from bin cheng --- (In reply to Richard Biener from comment #15) > I don't see the commit on the GCC 10 branch nor the GCC 8 branch. Master > and GCC 9 are fixed though. Will backport the 10 and 8, thanks for reminding.
[Bug target/95732] New: Use CPU dispatching to support mixing -fcf-protection with -mindirect-branch and -mfunction-return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95732 Bug ID: 95732 Summary: Use CPU dispatching to support mixing -fcf-protection with -mindirect-branch and -mfunction-return Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: josephcsible at gmail dot com Target Milestone: --- Target: x86_64 The thunks generated by -mindirect-branch and -mfunction-return should do CPU dispatching à la "ifunc". We should generate one path for CPUs with CET and one without. The path without CET should stay like it is today. Intel claims that their CPUs that support CET no longer need Spectre mitigations. For as long as this remains true, the path with CET should just be "jmp *%rax" and "ret". If this ends up turning out to be false, then we should instead use the "incsspq", "rdsspq", and "wrssq" instructions to make the shadow stack match what we do in the real stack. (We can't just do this unconditionally, since unlike "endbr64", those instructions aren't all NOPs on older CPUs.) This change will allow the same binary to run safely on Spectre-vulnerable CPUs and still get the benefits of CET on new CPUs, without needing programs to all supply their own external thunks.
[Bug c++/95725] Confusing error diagnostic in an invalid template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725 --- Comment #5 from Jonathan Wakely --- Garbage in, garbage out.
[Bug c++/95725] Confusing error diagnostic in an invalid template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- (In reply to Martin Sebor from comment #3) > The diagnostic is usually for false positive/negative warnings or wrong > information in diagnostic messages. It's not normally used for internal > compiler errors. But I don't see an ICE on trunk with this test case, just > errors (so diagnostic would seem appropriate). At the same time, the latest > GCC output seems reasonable. Clang prints something similar: > > pr95725.C:1:20: error: expected expression > template ^ > pr95725.C:1:22: error: expected expression > template ^ > pr95725.C:1:22: error: expected ',' or '>' in template-parameter-list > pr95725.C:1:22: warning: declaration does not declare anything > [-Wmissing-declarations] > 1 warning and 3 errors generated. > > I'm not sure there's a lot to improve here. Agreed. As I said in bug 95723, I'm on the verge of closing these reports as WONFIX or INVALID or something similar.
[Bug c++/95723] GCC get confused while parsing a code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95723 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- This code is so hopelessly broken that I'm not sure how we could generate better diagnostics. clang doesn't issue anything better. I'm tempted to WONTFIX this.
[Bug c++/93711] [9/10/11 Regression] ICE: [[no_unique_address] when constructing via template helper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93711 Marek Polacek changed: What|Removed |Added Summary|ICE: [[no_unique_address] |[9/10/11 Regression] ICE: |when constructing via |[[no_unique_address] when |template helper |constructing via template ||helper CC||mpolacek at gcc dot gnu.org Last reconfirmed||2020-06-17 Status|UNCONFIRMED |NEW Target Milestone|--- |9.4 Ever confirmed|0 |1 --- Comment #4 from Marek Polacek --- Same backtrace as bug 90254 but it didn't start with the same revision. This one started with r264813.
[Bug c++/95728] [11 Regression] tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95728 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- ...which also generates a better diagnostic than gcc 10 & older.
[Bug c++/95728] [11 Regression] tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95728
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Target Milestone|--- |11.0
--- Comment #1 from Marek Polacek ---
Since the introduction of tsubst_tree_list we now return a naked
error_mark_node rather than an error_mark_node wrapped in a TREE_LIST. So
tsubst_copy_and_build/NEW_EXPR ICEs:
19654 tree placement = RECUR (TREE_OPERAND (t, 0)); // now a naked
error_mark_node
...
19668 for (; placement != NULL_TREE; placement = TREE_CHAIN
(placement)) // crash
A simple
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -19633,6 +19660,8 @@ tsubst_copy_and_build (tree t,
if (placement == NULL_TREE)
placement_vec = NULL;
+ else if (placement == error_mark_node)
+ RETURN (error_mark_node);
else
{
placement_vec = make_tree_vector ();
should fix this.
[Bug lto/94848] [Offloading][LTO] error due to only partially eliminated var / -ftree-pre causes link errors | libgomp.fortran/use_device_ptr-optional-3.f90 failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:61c896d84bdefbfffa7573a8af89119d4db7b3de commit r10-8319-g61c896d84bdefbfffa7573a8af89119d4db7b3de Author: Thomas Schwinge Date: Tue Jan 7 17:40:14 2020 +0100 Add 'dg-do run' to 'libgomp.fortran/use_device_ptr-optional-3.f90' [PR94848] Fix-up for r279858/commit f760c0c77fe350616da9dbeaea16442b0acfb09c "Fortran] OpenMP/OpenACC â fix more issues with OPTIONAL". With offloading enabled, we then saw: PASS: libgomp.fortran/use_device_ptr-optional-3.f90 -O0 (test for excess errors) PASS: libgomp.fortran/use_device_ptr-optional-3.f90 -O0 execution test PASS: libgomp.fortran/use_device_ptr-optional-3.f90 -O1 (test for excess errors) PASS: libgomp.fortran/use_device_ptr-optional-3.f90 -O1 execution test FAIL: libgomp.fortran/use_device_ptr-optional-3.f90 -O2 (test for excess errors) UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90 -O2 compilation failed to produce executable FAIL: libgomp.fortran/use_device_ptr-optional-3.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions compilation failed to produce executable FAIL: libgomp.fortran/use_device_ptr-optional-3.f90 -O3 -g (test for excess errors) UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90 -O3 -g compilation failed to produce executable FAIL: libgomp.fortran/use_device_ptr-optional-3.f90 -Os (test for excess errors) UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90 -Os compilation failed to produce executable ... due to: /tmp/cciVc43I.o:(.gnu.offload_vars+0x10): undefined reference to `A.12.4064' [...] ..., but after the recent PR94848, PR95551 changes, that problem is now gone. libgomp/ PR lto/94848 * testsuite/libgomp.fortran/use_device_ptr-optional-3.f90: Add 'dg-do run'. (cherry picked from commit 5864930754f63e2dcef9606f2514ae20e80f436e)
[Bug lto/94848] [Offloading][LTO] error due to only partially eliminated var / -ftree-pre causes link errors | libgomp.fortran/use_device_ptr-optional-3.f90 failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848 --- Comment #6 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:5864930754f63e2dcef9606f2514ae20e80f436e commit r11-1466-g5864930754f63e2dcef9606f2514ae20e80f436e Author: Thomas Schwinge Date: Tue Jan 7 17:40:14 2020 +0100 Add 'dg-do run' to 'libgomp.fortran/use_device_ptr-optional-3.f90' [PR94848] Fix-up for r279858/commit f760c0c77fe350616da9dbeaea16442b0acfb09c "Fortran] OpenMP/OpenACC â fix more issues with OPTIONAL". With offloading enabled, we then saw: PASS: libgomp.fortran/use_device_ptr-optional-3.f90 -O0 (test for excess errors) PASS: libgomp.fortran/use_device_ptr-optional-3.f90 -O0 execution test PASS: libgomp.fortran/use_device_ptr-optional-3.f90 -O1 (test for excess errors) PASS: libgomp.fortran/use_device_ptr-optional-3.f90 -O1 execution test FAIL: libgomp.fortran/use_device_ptr-optional-3.f90 -O2 (test for excess errors) UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90 -O2 compilation failed to produce executable FAIL: libgomp.fortran/use_device_ptr-optional-3.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions compilation failed to produce executable FAIL: libgomp.fortran/use_device_ptr-optional-3.f90 -O3 -g (test for excess errors) UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90 -O3 -g compilation failed to produce executable FAIL: libgomp.fortran/use_device_ptr-optional-3.f90 -Os (test for excess errors) UNRESOLVED: libgomp.fortran/use_device_ptr-optional-3.f90 -Os compilation failed to produce executable ... due to: /tmp/cciVc43I.o:(.gnu.offload_vars+0x10): undefined reference to `A.12.4064' [...] ..., but after the recent PR94848, PR95551 changes, that problem is now gone. libgomp/ PR lto/94848 * testsuite/libgomp.fortran/use_device_ptr-optional-3.f90: Add 'dg-do run'.
[Bug tree-optimization/95729] Failure to optimize away certain returns when the condition to reach them is a calculation that already results in that value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95729 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/95731] New: Faiilure to optimize a >= 0 && b >= 0 to (a | b) >= 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95731
Bug ID: 95731
Summary: Faiilure to optimize a >= 0 && b >= 0 to (a | b) >= 0
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(int a, int b)
{
return a >= 0 && b >= 0;
}
This can be optimized to `return (a | b) >= 0;`. LLVM does this transformation,
but GCC does not.
[Bug libstdc++/94540] stack overflow populating std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94540 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |11.0 --- Comment #2 from Jonathan Wakely --- Fixed in master.
[Bug target/95730] GCN offloading ICEs after commit fe7ebef7fe4f9acb79658ed9db0749b07efc3105 "Add support for __builtin_bswap128"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95730 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-06-17 Status|UNCONFIRMED |NEW --- Comment #2 from Eric Botcazou --- The error_mark_node very likely comes from: DEF_PRIMITIVE_TYPE (BT_UINT128, uint128_type_node ? uint128_type_node : error_mark_node) but this is a standard idiom in builtin-types.def so rather strange indeed. I gather that targetm.scalar_mode_supported_p (TImode) returns false for GCN?
[Bug libstdc++/94540] stack overflow populating std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94540 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:632183ddcc8f3aead8b4fc63c4ab59a42ef9ad00 commit r11-1464-g632183ddcc8f3aead8b4fc63c4ab59a42ef9ad00 Author: Jonathan Wakely Date: Wed Jun 17 22:49:06 2020 +0100 libstdc++: Avoid stack overflow in std::vector (PR 94540) The std::__uninitialized_default_n algorithm used by std::vector creates an initial object as a local variable then copies that into the destination range. If the object is too large for the stack this crashes. We should create the first object directly into the destination and then copy it from there. This doesn't fix the bug for C++98, because in that case the initial value is created as a default argument of the vector constructor i.e. in the user's code, not inside libstdc++. We can't prevent that. PR libstdc++/94540 * include/bits/stl_uninitialized.h (__uninitialized_default_1): Construct the first value at *__first instead of on the stack. (__uninitialized_default_n_1): Likewise. Improve comments on several of the non-standard algorithms. * testsuite/20_util/specialized_algorithms/uninitialized_default/94540.cc: New test. * testsuite/20_util/specialized_algorithms/uninitialized_default_n/94540.cc: New test. * testsuite/20_util/specialized_algorithms/uninitialized_value_construct/94540.cc: New test. * testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/94540.cc: New test. * testsuite/23_containers/vector/cons/94540.cc: New test.
[Bug target/95730] GCN offloading ICEs after commit fe7ebef7fe4f9acb79658ed9db0749b07efc3105 "Add support for __builtin_bswap128"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95730 --- Comment #1 from Andrew Stubbs --- GCN uses TImode for a few special purposes, but lacks real TImode support. (Basically, it allows TImode loads and stores for the SLP fake vectorization, and there's one instruction that needs two DImode values in consecutive registers.) Probably this is a GCN-specific issue, and we should be finding another way to handle the quasi-128-bit values.
[Bug fortran/95710] ICE in gfc_type_is_extensible, at fortran/resolve.c:8848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95710
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
Tested against z1.f90. Untested otherwise. I don't use CLASSes.
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -8798,6 +8798,9 @@ resolve_select (gfc_code *code, bool select_type)
bool
gfc_type_is_extensible (gfc_symbol *sym)
{
+ if (!sym)
+return false;
+
return !(sym->attr.is_bind_c || sym->attr.sequence
|| (sym->attr.is_class
&& sym->components->ts.u.derived->attr.unlimited_polymorphic));
@@ -12595,9 +12599,13 @@ resolve_fl_var_and_proc (gfc_symbol *sym, int mp_flag)
&& !UNLIMITED_POLY (sym)
&& !gfc_type_is_extensible (CLASS_DATA (sym)->ts.u.derived))
{
- gfc_error ("Type %qs of CLASS variable %qs at %L is not extensible",
-CLASS_DATA (sym)->ts.u.derived->name, sym->name,
-&sym->declared_at);
+ if (CLASS_DATA (sym)->ts.u.derived)
+ gfc_error ("Type %qs of CLASS variable %qs at %L is not
extensible",
+CLASS_DATA (sym)->ts.u.derived->name,
+ sym->name, &sym->declared_at);
+ else
+ gfc_error ("CLASS variable %qs at %L is not extensible",
+ sym->name, &sym->declared_at);
return false;
}
[Bug c++/95727] Add [[gnu::poison]] attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95727 --- Comment #1 from Andrew Pinski --- pragma poison actually does one step further, it poisons it during the preprocessing stage. What you are proposing is slightly different. It is more deprecated attribute but slightly different.
[Bug target/95730] New: GCN offloading ICEs after commit fe7ebef7fe4f9acb79658ed9db0749b07efc3105 "Add support for __builtin_bswap128"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95730 Bug ID: 95730 Summary: GCN offloading ICEs after commit fe7ebef7fe4f9acb79658ed9db0749b07efc3105 "Add support for __builtin_bswap128" Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: openacc, openmp Severity: normal Priority: P3 Component: target Assignee: ams at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org, jules at gcc dot gnu.org Target Milestone: --- Target: gcn For a few libgomp test cases, the recent commit fe7ebef7fe4f9acb79658ed9db0749b07efc3105 "Add support for __builtin_bswap128" is causing ICE regressions with GCN offloading (only, apparently: not seen for Intel MIC (emulated), or nvptx offloading): 'libgomp.fortran/pr90779.f90': lto1: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in lto_input_tree_1, at lto-streamer-in.c:1561 #0 internal_error (gmsgid=0x163f958 "tree check: expected class %qs, have %qs (%s) in %s, at %s:%d") at [...]/source-gcc/gcc/diagnostic.c:1706 #1 0x0055f2fd in tree_class_check_failed (node=0x767b4960, cl=, file=, line=, function=) at [...]/source-gcc/gcc/tree.c:9738 #2 0x009d7886 in tree_class_check (__g=, __l=1561, __f=0x15d1208 "[...]/source-gcc/gcc/lto-streamer-in.c", __class=tcc_type, __t=0x767b4960) at [...]/source-gcc/gcc/tree.h:3424 #3 lto_input_tree_1 (ib=0x7fffd080, data_in=0x1dd4860, tag=, hash=) at [...]/source-gcc/gcc/lto-streamer-in.c:1561 #4 0x005d84b6 in lto_read_decls (resolutions=..., data=0x1e3a630, decl_data=0x77fee090) at [...]/source-gcc/gcc/lto/lto-common.c:1955 #5 lto_file_finalize (file=0x1d8c900, order=0, file_data=0x77fee090) at [...]/source-gcc/gcc/lto/lto-common.c:2267 #6 lto_create_files_from_ids (order=0, count=, file_data=0x77fee090, file=0x1d8c900) at [...]/source-gcc/gcc/lto/lto-common.c:2277 #7 lto_file_read (count=, resolution_file=, file=) at [...]/source-gcc/gcc/lto/lto-common.c:2332 #8 read_cgraph_and_symbols (nfiles=, fnames=) at [...]/source-gcc/gcc/lto/lto-common.c:2784 #9 0x005b9c23 in lto_main () at [...]/source-gcc/gcc/lto/lto.c:625 #10 0x00b7f6ff in compile_file () at [...]/source-gcc/gcc/toplev.c:458 #11 0x0059302c in do_compile () at [...]/source-gcc/gcc/toplev.c:2307 #12 toplev::main (this=this@entry=0x7fffd240, argc=argc@entry=19, argv=0x1d766e0, argv@entry=0x7fffd348) at [...]/source-gcc/gcc/toplev.c:2446 #13 0x00595ac7 in main (argc=19, argv=0x7fffd348) at [...]/source-gcc/gcc/main.c:39 (gdb) frame 3 #3 lto_input_tree_1 (ib=0x7fffd080, data_in=0x1dd4860, tag=, hash=) at [...]/source-gcc/gcc/lto-streamer-in.c:1561 1561 gcc_assert (TYPE_PRECISION (type) <= MAX_BITSIZE_MODE_ANY_INT); (gdb) print type $1 = (tree) 0x767b4960 (gdb) call debug_tree(type) 'libgomp.oacc-c-c++-common/firstprivate-mappings-1.c': lto1: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in lto_fixup_prevailing_type, at lto/lto-common.c:993 #0 internal_error (gmsgid=0x163f958 "tree check: expected class %qs, have %qs (%s) in %s, at %s:%d") at [...]/source-gcc/gcc/diagnostic.c:1706 #1 0x0055f2fd in tree_class_check_failed (node=0x767b4960, cl=, file=, line=, function=) at [...]/source-gcc/gcc/tree.c:9738 #2 0x005d7724 in tree_class_check (__g=, __l=993, __f=0x1559cc8 "[...]/source-gcc/gcc/lto/lto-common.c", __class=tcc_type, __t=) at [...]/source-gcc/gcc/tree.h:3424 #3 lto_fixup_prevailing_type (t=0x76883b28) at [...]/source-gcc/gcc/lto/lto-common.c:993 #4 process_new_tree (t=t@entry=0x76883b28, hm=hm@entry=0x7fffd0b0, index=index@entry=467, total=total@entry=0x7fffd048, data_in=data_in@entry=0x1e37560) at [...]/source-gcc/gcc/lto/lto-common.c:1817 #5 0x005d8e24 in lto_read_decls (resolutions=..., data=0x1e44f50, decl_data=0x77fee090) at [...]/source-gcc/gcc/lto/lto-common.c:1938 #6 lto_file_finalize (file=0x1d8bc30, order=0, file_data=0x77fee090) at [...]/source-gcc/gcc/lto/lto-common.c:2267 #7 lto_create_files_from_ids (order=0, count=, file_data=0x77fee090, file=0x1d8bc30) at [...]/source-gcc/gcc/lto/lto-common.c:2277 #8 lto_file_read (count=, resolution_file=, file=) at [...]/source-gcc/gcc/lto/lto-common.c:2332 #9 read_cgraph_and_symbols (nfiles=, fnames=) at [...]/source-gcc/gcc/lto/lto-common.c:2784 #10 0x005b9c23 in lto_main () at [...]/source-gcc/gcc/lto/lto.c:625 #11 0x00b7f6ff in compile_file () at [...]/source-gcc/gcc/toplev.c:458 #12 0x0059302c in do_compile () at [...]/source-gcc/gcc/toplev.c:2307 #13 toplev::m
[Bug tree-optimization/95729] New: Failure to optimize away certain returns when the condition to reach them is a calculation that already results in that value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95729
Bug ID: 95729
Summary: Failure to optimize away certain returns when the
condition to reach them is a calculation that already
results in that value
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: ---
int f(int a, int b)
{
if (a != b)
return a - b;
else
return 0;
}
This can be optimized to `return a - b;`. This optimization is done by LLVM,
but not by GCC.
[Bug middle-end/86349] diagnose string overflow for allocations of non-constant sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86349 Martin Sebor changed: What|Removed |Added Blocks||88443 Known to fail||7.3.0, 8.2.0, 9.2.0 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Known to work||10.1.0 Component|tree-optimization |middle-end Target Milestone|--- |10.0 Resolution|--- |FIXED --- Comment #1 from Martin Sebor --- Done in GCC 10: $ gcc -O2 -S -Wall -Wextra pr86349.c pr86349.c: In function ‘f’: pr86349.c:5:3: warning: ‘__builtin_strcpy’ writing one too many bytes into a region of a size that depends on ‘strlen’ [-Wstringop-overflow=] 5 | __builtin_strcpy (p, s); | ^~~ pr86349.c:4:13: note: at offset 0 to an object allocated by ‘__builtin_malloc’ here 4 | char *p = __builtin_malloc (n); | ^~~~ Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 86349, which changed state. Bug 86349 Summary: diagnose string overflow for allocations of non-constant sizes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86349 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug libgcc/95712] configure-target-libgcc fails on s390x target because xgcc is not being built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95712 Alexander Egorenkov changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #6 from Alexander Egorenkov --- Ok, i understand, therefore, i reproduced the problem without buildroot. My steps: $ mkdir compiler $ cd compiler $ tar xvjf gmp-6.1.0.tar.bz2 $ cd gmp-6.1.0 $ ./configure --prefix=$HOME/compiler/install --disable-shared $ make -j81 $ make install $ cd .. $ tar xvjf mpfr-3.1.4.tar.bz2 $ cd mpfr-3.1.4 $ ./configure --prefix=$HOME/compiler/install --disable-shared --with-gmp=$HOME/compiler/install $ make -j81 $ make install $ cd .. $ tar xvzf mpc-1.0.3.tar.gz $ cd mpc-1.0.3 $ ./configure --prefix=$HOME/compiler/install --disable-shared --with-gmp=$HOME/compiler/install --with-mpfr=$HOME/compiler/install $ make -j81 $ make install $ cd .. $ tar xvzf gcc-9.3.0.tar.xz $ mkdir build-gcc $ cd build-gcc $ ../gcc-9.3.0/configure --prefix=$HOME/compiler/install --enable-shared --disable-static \ --disable-gtk-doc --disable-gtk-doc-html --disable-doc --disable-docs \ --disable-documentation --disable-debug --with-xmlto=no --with-fop=no \ --disable-nls --disable-dependency-tracking --target=s390x-buildroot-linux-gnu \ --enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib \ --disable-decimal-float --with-gmp=$HOME/compiler/install \ --with-mpc=$HOME/compiler/install --with-mpfr=$HOME/compiler/install \ --with-pkgversion="Buildroot 2020.08-git-g2d8407f8ab" \ --with-bugurl="http://bugs.buildroot.net/"; --disable-libquadmath --enable-tls \ --enable-threads --without-isl --without-cloog --with-arch="z196" \ --with-long-double-128 --enable-languages=c --disable-shared --without-headers \ --disable-threads --with-newlib --disable-largefile $ make -j81 gcc_cv_libc_provides_ssp=yes all-gcc all-target-libgcc The above steps were executed manually w/o any buildroot infrastructure. And i get the same problem, almost the same commands are executed by buildroot. Again, xgcc is not being built and libgcc fails. I patched nothing, everything was vanilla. What i did notice, is that everything seems to work fine and the make commands succeeds, if i drop "-j81" in the last step. I did all these steps on a s390x machine with 80 cores, it is a highly parallel machine. So the issue seems to depend on it somehow, my guess is that maybe some dependencies are not correctly done in libgcc Makefile ? Another workaround i found is to split the last maske command into 2 like this: $ make -j81 all-gcc $ make -j81 all-target-libgcc This seems to fix it also. I'm ready to do more test if required. I really want to fix it, it is very annoying and blocking me. Regards
[Bug fortran/95088] ICE in gfc_build_class_symbol, at fortran/class.c:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95088 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on master for GCC-11, and backported to 10-branch. Backporting further would require backports of other work, so not done. Thanks for the report!
[Bug fortran/95088] ICE in gfc_build_class_symbol, at fortran/class.c:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95088 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:55838f7fbd6e0131c2cc38e0eb903551c7fd2401 commit r10-8316-g55838f7fbd6e0131c2cc38e0eb903551c7fd2401 Author: Harald Anlauf Date: Sun Jun 14 16:12:47 2020 +0200 PR fortran/95088 - Buffer overflows with PDTs, submodules and long symbols With PDTs (parameterized derived types) and submodules, name mangling results in variably long internal symbols. Instead of using a fixed-size intermediate buffer, which is actually not really needed, just use a pointer to strings. 2020-06-14 Harald Anlauf gcc/fortran/ PR fortran/95088 * class.c (get_unique_type_string): Replace use of fixed size buffer by internally passing a pointer to strings. (cherry picked from commit 3ee9d82484bdc0ae5b1b21f4a3d8ff46d40e36fd)
[Bug c++/95728] New: [11 Regression] tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95728
Bug ID: 95728
Summary: [11 Regression] tree check: expected tree_list, have
error_mark in tsubst_copy_and_build, at cp/pt.c:19594
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
The code below is invalid (attempting to cast const T* to void*) but dies with
an ICE since r11-423:
PR c++/93286 - ICE with __is_constructible and variadic template.
My GCC 10 patch for 93286 fixed the missing piece in tsubst's handling of
lists vs. that in tsubst_copy_and_build, but it would be better to share
the
code between them.
template
void
construct(T* p)
{ ::new(static_cast(p)) T; }
template
void
f(const T* t)
{
construct(t);
}
int main()
{
int i[1];
f(i);
}
ice.cc: In instantiation of 'void construct(T*) [with T = const int]':
ice.cc:10:12: required from 'void f(const T*) [with T = int]'
ice.cc:16:6: required from here
ice.cc:4:11: error: invalid 'static_cast' from type 'const int*' to type
'void*'
4 | { ::new(static_cast(p)) T; }
| ^
ice.cc:4:5: internal compiler error: tree check: expected tree_list, have
error_mark in tsubst_copy_and_build, at cp/pt.c:19640
4 | { ::new(static_cast(p)) T; }
| ^~
0x81ac46 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/jwakely/src/gcc/gcc/gcc/tree.c:9685
0x67d317 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/jwakely/src/gcc/gcc/gcc/tree.h:3301
0x67d317 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:19640
0xa91287 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:18772
0xa93ab7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:17879
0xa92db1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:18173
0xa90ba1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:17834
0xa90ba1 instantiate_decl(tree_node*, bool, bool)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:25653
0xac281b instantiate_pending_templates(int)
/home/jwakely/src/gcc/gcc/gcc/cp/pt.c:25769
0x9cb4e0 c_parse_final_cleanups()
/home/jwakely/src/gcc/gcc/gcc/cp/decl2.c:4899
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/95728] [11 Regression] tree check: expected tree_list, have error_mark in tsubst_copy_and_build, at cp/pt.c:19594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95728 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-06-17 Ever confirmed|0 |1 Known to fail||11.0 Status|UNCONFIRMED |NEW Known to work||10.1.0
[Bug c++/95727] New: Add [[gnu::poison]] attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95727
Bug ID: 95727
Summary: Add [[gnu::poison]] attribute
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
GCC supports a pragma for poisoning a variable, but it doesn't respect scope.
It seems useful to be able to poison a variable for the remainder of a scope
(maybe because it's been moved and any further use would be an error), or it's
a pointer that has been invalidated by delete).
This seems to be a good fit for an attribute, because in a program which
doesn't use the variable again after that point it would make no difference
whether the compiler supports the attribute or ignores it.
void f(int*);
void g()
{
int* p = new int();
f(p);
[[poison]] p;
{
void* p; // ok, not the same p
}
int i = *p; // error, variable was poisoned
}
It would need to be OK for an implicit destructor to run for poisoned
variables, it should only affect explicit uses of the name in the user code.
I'm not sure if it makes sense to allow poisoning non-local variables in a
given scope ... it could do. Limiting it to local variables (including function
parameters) seems reasonable initially.
A related idea is to mark a variable as read-only from a certain point, so that
it can't be written to, can't have non-const member functions called on it, and
can't have non-const references bound to it.
[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726 --- Comment #3 from Jakub Jelinek --- (In reply to rsand...@gcc.gnu.org from comment #2) > They mangle differently, and e.g.: > > void f(float32x4_t); > void f(V); > > aren't ODR equivalent. But a lot of code relies on the GNU vector > extensions being available for float32x4_t as well as V, and on V > and float32x4_t being mutually and implicitly interconvertible. But if they mangle differently, then structural_comptypes shouldn't treat them as same types.
[Bug fortran/95687] ICE in get_unique_hashed_string, at fortran/class.c:508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95687 --- Comment #4 from anlauf at gcc dot gnu.org --- Updated / corrected patch posted for review: https://gcc.gnu.org/pipermail/fortran/2020-June/054548.html
[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726 --- Comment #2 from rsandifo at gcc dot gnu.org --- (In reply to Jason Merrill from comment #1) > Does the aarch64 port expect __Float32x4_t type to be considered equivalent > to the GNU vector type or not? If so, why use build_distinct_type_copy over > build_variant_type_copy? If not, they might want to set TYPE_INDIVISIBLE_P > so that structural_comptypes treats them as different. They mangle differently, and e.g.: void f(float32x4_t); void f(V); aren't ODR equivalent. But a lot of code relies on the GNU vector extensions being available for float32x4_t as well as V, and on V and float32x4_t being mutually and implicitly interconvertible.
[Bug fortran/95707] ICE in finish_equivalences, at fortran/trans-common.c:1319
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95707 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from anlauf at gcc dot gnu.org --- Patch posted for review: https://gcc.gnu.org/pipermail/fortran/2020-June/054549.html
[Bug c++/66159] bogus warning for alias-declaration using elaborated-type-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66159 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Jonathan Wakely --- Fixed on master.
[Bug c++/66159] bogus warning for alias-declaration using elaborated-type-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66159 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d392babbeb6cb531ab8b1ec68fde9ffd36373a6e commit r11-1459-gd392babbeb6cb531ab8b1ec68fde9ffd36373a6e Author: Jonathan Wakely Date: Wed Jun 17 20:26:13 2020 +0100 c++: Fix bogus "does not declare anything" warning (PR 66159) G++ gives a bogus warning for 'struct A; using B = struct ::A;' complaining that the elaborated-type-specifier doesn't declare anything. That's true, but it's not trying to declare struct ::A, just refer to it unambiguously. Do not emit the warning unless we're actually parsing a declaration. gcc/cp/ChangeLog: PR c++/66159 * parser.c (cp_parser_elaborated_type_specifier): Do not warn unless in a declaration. gcc/testsuite/ChangeLog: PR c++/66159 * g++.dg/warn/forward-inner.C: Check alias-declaration using elaborated-type-specifier.
[Bug tree-optimization/95199] Remove extra variable created for memory reference in loop vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||rsandifo at gcc dot gnu.org --- Comment #11 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/95199] Remove extra variable created for memory reference in loop vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95199 --- Comment #10 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:4a31a8add56d49867c187d90b3a89e97634543c2 commit r11-1458-g4a31a8add56d49867c187d90b3a89e97634543c2 Author: Kaipeng Zhou Date: Wed Jun 17 20:19:16 2020 +0100 vect: CSE for bump and offset in strided load/store operations. Every time "vect_get_strided_load_store_ops" is called, new bump and offset variables and a series of stmts are created. And IVOPTs is not able to eliminate them. The patch use "cse_and_gimplify_to_preheader" to CSE them. 2020-06-17 Bin Cheng Kaipeng Zhou PR tree-optimization/95199 * tree-vect-stmts.c: Eliminate common stmts for bump and offset in strided load/store operations and remove redundant code. 2020-06-17 Bin Cheng Kaipeng Zhou PR tree-optimization/95199 * gcc.target/aarch64/sve/pr95199.c: New test.
[Bug target/95722] libatomic crashes on __atomic_load of const object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95722 James Y Knight changed: What|Removed |Added CC||foom at fuhm dot net --- Comment #1 from James Y Knight --- The fix would be to have libatomic use a lock instead of the lock-free cmpxchg16b instruction to implement atomic_load. But I think this is impossible without causing incompatibility with older GCCs. Older versions of GCC (before GCC 7), and Clang to this day, emitted cmpxchg16b inline for a 16-byte atomic load when you compile with -mcx16. And thus, unfortunately, I think if libatomic switched to a lock now, it would not be compatible with those older programs.
[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726 Jason Merrill changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-06-17
[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726 --- Comment #1 from Jason Merrill --- Does the aarch64 port expect __Float32x4_t type to be considered equivalent to the GNU vector type or not? If so, why use build_distinct_type_copy over build_variant_type_copy? If not, they might want to set TYPE_INDIVISIBLE_P so that structural_comptypes treats them as different.
[Bug c/95378] __atomic_load will write to objects of cv-qualified types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95378 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jonathan Wakely --- Fixed on master.
[Bug c++/95726] New: ICE with aarch64 __Float32x4_t as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
Bug ID: 95726
Summary: ICE with aarch64 __Float32x4_t as template argument
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Following test ICEs on aarch64-linux:
// { dg-do compile }
// { dg-options "--param=hash-table-verification-limit=500 -O2" }
typedef __Float32x4_t float32x4_t;
typedef float V [[gnu::vector_size(4 * sizeof (float))]];
template
int
foo ()
{
return 0;
}
int
bar ()
{
return foo () + foo <__Float32x4_t> () + foo () + foo
();
}
On 10.x branch I can reproduce the ICE even on a large unreduceable source
without that extra argument.
The function template is specialized twice, once with and
once with <__Float32x4_t>.
The former vector type is:
elt:1
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea7742a0 precision:32
pointer_to_this reference_to_this
>
type_6 V4SF size unit-size
align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea85cf18 nunits:4>>
(and has TYPE_CANONICAL itself), while the other one is some vector type
created by the aarch64 backend:
elt:1
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea7742a0 precision:32
pointer_to_this reference_to_this
>
type_6 V4SF size unit-size
align:128 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
nunits:4>>
(and has NULL TYPE_CANONICAL).
In iterative_hash_template_arg for these VECTOR_TYPEs we end up:
default:
if (tree canonical = TYPE_CANONICAL (arg))
val = iterative_hash_object (TYPE_HASH (canonical), val);
and thus hash it differently between vector(4) float and __Float32x4_t.
But spec_hasher::equal calls comp_template_args for that and that in turn calls
same_type_p on those and
structural_comptypes is called because one of those lacks TYPE_CANONICAL, and
there it does:
case VECTOR_TYPE:
if (gnu_vector_type_p (t1) != gnu_vector_type_p (t2)
|| maybe_ne (TYPE_VECTOR_SUBPARTS (t1), TYPE_VECTOR_SUBPARTS (t2))
|| !same_type_p (TREE_TYPE (t1), TREE_TYPE (t2)))
return false;
and considers the two the same.
Because it hashed differently, it is added twice into the hash table, and when
we are unlucky, the two hash values modulo the size of the hash table are
equal,
so we have two different specializations (instantiations?) for the same thing
and the check that retrieve_specialization returns the one we are considering
fails.
2020-06-17 Jakub Jelinek
* pt.c (iterative_hash_template_arg): Handle VECTOR_TYPE.
--- gcc/cp/pt.c.jj 2020-06-17 18:48:53.506617982 +0200
+++ gcc/cp/pt.c 2020-06-17 19:34:28.551298600 +0200
@@ -1924,10 +1924,21 @@ iterative_hash_template_arg (tree arg, h
}
break;
- case DECLTYPE_TYPE:
+ case DECLTYPE_TYPE:
val = iterative_hash_template_arg (DECLTYPE_TYPE_EXPR (arg), val);
break;
+ case VECTOR_TYPE:
+ {
+ bool gnu_vec = gnu_vector_type_p (arg);
+ val = iterative_hash_object (gnu_vec, val);
+ val = iterative_hash_template_arg (TREE_TYPE (arg), val);
+ inchash::hash hstate (val);
+ hstate.add_poly_int (TYPE_VECTOR_SUBPARTS (arg));
+ val = hstate.end ();
+ }
+ break;
+
default:
if (tree canonical = TYPE_CANONICAL (arg))
val = iterative_hash_object (TYPE_HASH (canonical), val);
fixes this for me, but I wonder if we don't need to handle at least
POINTER_TYPE and REFERENCE_TYPE too, because if a template argument
is not a vector type, but e.g. a pointer to vector or reference to vector, due
to the magic backend VECTOR_TYPEs with no TYPE_CANONICAL
pointers to them will also have structural equality and thus would hash
differently from pointers/references to the C++ FE created vector types.
The __Float32x4_t type is created in aarch64_init_simd_builtin_types using
build_distinct_type_copy and
explicitly requests structural equality:
aarch64_simd_types[i].itype
= build_distinct_type_copy
(build_vector_type (eltype, GET_MODE_NUNITS (mode)));
SET_TYPE_STRUCTURAL_EQUALITY (aarch64_simd_types[i].itype);
For POINTER_TYPE/REFERENCE_TYPE, we could do:
case REFERENCE_TYPE:
{
bool rval = TYPE_REF_IS_RVALUE (arg);
val = iterative_hash_object (rval, val);
}
/* FALLTHRU */
case POINTER_TYPE:
{
machine_mode mode = TYPE_MODE (arg);
val = iterative_hash_object (mode, val);
val = iterative_hash_template_
[Bug c++/95725] Confusing error diagnostic in an invalid template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- The diagnostic is usually for false positive/negative warnings or wrong information in diagnostic messages. It's not normally used for internal compiler errors. But I don't see an ICE on trunk with this test case, just errors (so diagnostic would seem appropriate). At the same time, the latest GCC output seems reasonable. Clang prints something similar: pr95725.C:1:20: error: expected expression template ' in template-parameter-list pr95725.C:1:22: warning: declaration does not declare anything [-Wmissing-declarations] 1 warning and 3 errors generated. I'm not sure there's a lot to improve here.
[Bug c++/95724] bogue error : "expected '{' before ')' token"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95724 --- Comment #3 from Martin Liška --- (In reply to Haoxin Tu from comment #2) > (In reply to Martin Liška from comment #1) > > For the next time, can you please add 'ice-on-invalid-code' keyword? > > I got it. So sorry for my mistake! It's not a mistake, I just wanted to inform you that it's very unlikely that we'll fix it. We have a lot of these issues..
[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700 --- Comment #8 from Ilya Leoshkevich --- Created attachment 48750 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48750&action=edit proposed patch (tests are running)
[Bug c++/95508] [10 Regression] ICE on unexpected expression implicit_conv_expr since r10-7096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95508 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug c++/95508] [10 Regression] ICE on unexpected expression implicit_conv_expr since r10-7096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95508 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:1bab254fd30c2b94a675b9057349fc80946375b1 commit r10-8315-g1bab254fd30c2b94a675b9057349fc80946375b1 Author: Marek Polacek Date: Wed Jun 17 14:38:05 2020 -0400 c++: ICE with IMPLICIT_CONV_EXPR in array subscript [PR95508] Since r10-7096 convert_like, when called in a template, creates an IMPLICIT_CONV_EXPR when we're converting to/from array type. In this test, we have e[f], and we're converting f (of type class A) to int, so convert_like in build_new_op_1 created the IMPLICIT_CONV_EXPR that got into cp_build_array_ref which calls maybe_constant_value. My patch above failed to adjust this spot to call fold_non_dependent_expr instead, which can handle codes like I_C_E in a template. Fixed by using a new function maybe_fold_non_dependent_expr, which, if the expr can't be evaluated to a constant, returns the original expression. gcc/cp/ChangeLog: PR c++/95508 * constexpr.c (maybe_fold_non_dependent_expr): New. * cp-tree.h (maybe_fold_non_dependent_expr): Declare. * typeck.c (cp_build_array_ref): Call maybe_fold_non_dependent_expr instead of maybe_constant_value. gcc/testsuite/ChangeLog: PR c++/95508 * g++.dg/template/conv16.C: New test.
[Bug c++/95724] bogue error : "expected '{' before ')' token"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95724 --- Comment #2 from Haoxin Tu --- (In reply to Martin Liška from comment #1) > For the next time, can you please add 'ice-on-invalid-code' keyword? I got it. So sorry for my mistake!
[Bug c++/95725] Confusing error diagnostic in an invalid template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725 --- Comment #2 from Haoxin Tu --- (In reply to Martin Liška from comment #1) > For the next time, can you please add 'ice-on-invalid-code' keyword? Ok, so sorry it's my fault. But this is a diagnostic issue I think? I will add "diagnostic" keywords next time.
[Bug c++/95723] GCC get confused while parsing a code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95723 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #2 from Martin Liška --- Note that we have a gazillion of error recovery issues for C++ FE.
[Bug c++/95725] Confusing error diagnostic in an invalid template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- For the next time, can you please add 'ice-on-invalid-code' keyword?
[Bug c++/95724] bogue error : "expected '{' before ')' token"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95724 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- For the next time, can you please add 'ice-on-invalid-code' keyword?
[Bug c++/95723] GCC get confused while parsing a code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95723 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- For the next time, can you please add 'ice-on-invalid-code' keyword?
[Bug fortran/95709] [9/10/11 Regression] ICE in gfc_resolve_code, at fortran/resolve.c:11807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95709
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -11740,7 +11740,8 @@ start:
case EXEC_GOTO:
if (code->expr1 != NULL)
{
- if (code->expr1->ts.type != BT_INTEGER)
+ if (code->expr1->expr_type == EXPR_CONSTANT
+ || code->expr1->ts.type != BT_INTEGER)
gfc_error ("ASSIGNED GOTO statement at %L requires an "
"INTEGER variable", &code->expr1->where);
else if (code->expr1->symtree->n.sym->attr.assign != 1)
[Bug c++/95725] New: Confusing error diagnostic in an invalid template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95725 Bug ID: 95725 Summary: Confusing error diagnostic in an invalid template Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: haoxintu at gmail dot com Target Milestone: --- This code test.cc, makes GCC get confused while parsing. $cat test.cc template ’ before ‘;’ token test.cc:1:22: error: expected unqualified-id before ‘;’ token $g++-10 -w -c test.cc test.cc:1:20: error: expected primary-expression before ‘=’ token 1 | template ’ before ‘;’ token 1 | template ’ before ‘decltype’ 1 | template
[Bug target/95704] PPC: int128 shifts should be implemented branchless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704 --- Comment #6 from Segher Boessenkool --- 13 insns, but the longest chain is 4. As I said, not totally awful, and much better than the branchy code (which does not predict well, for more general inputs anyway).
[Bug c++/93711] ICE: [[no_unique_address] when constructing via template helper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93711
Lénárd Szolnoki changed:
What|Removed |Added
CC||leni536 at gmail dot com
--- Comment #3 from Lénárd Szolnoki ---
A smaller example:
struct S {
S(S&&) = delete;
};
S foo();
struct A {
[[no_unique_address]] S s = foo();
};
A a{};
Version:
11.0.0 20200616
Command line options:
-std=c++20 -Wall -Wextra -pedantic
Diagnostics:
during RTL pass: expand
: In function 'void __static_initialization_and_destruction_0(int,
int)':
:11:5: internal compiler error: in assign_temp, at function.c:984
11 | A a{};
| ^
[Bug c++/95724] New: bogue error : "expected '{' before ')' token"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95724
Bug ID: 95724
Summary: bogue error : "expected '{' before ')' token"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code test.cc, GCC-trunk get a bogus error message and then get confused
with following code parsing.
$cat test.cc
template <(union : decltype(a = 0)>)
$g++-trunk -w -c test.cc
test.cc:1:11: error: expected identifier before ‘(’ token
1 | template <(union : decltype(a = 0)>)
| ^
test.cc:1:29: error: ‘a’ was not declared in this scope
1 | template <(union : decltype(a = 0)>)
| ^
test.cc:1:29: error: ‘a’ was not declared in this scope
test.cc:1:34: error: expected ‘{’ before ‘)’ token
1 | template <(union : decltype(a = 0)>)
| ^
test.cc:1:36: error: expected unqualified-id before ‘)’ token
1 | template <(union : decltype(a = 0)>)
|^
$g++-10 -w -c test.cc
test.cc:1:11: error: expected identifier before ‘(’ token
1 | template <(union : decltype(a = 0)>)
| ^
test.cc:1:29: error: ‘a’ was not declared in this scope
1 | template <(union : decltype(a = 0)>)
| ^
test.cc:1:29: error: ‘a’ was not declared in this scope
test.cc:1:35: error: expected ‘{’ before ‘>’ token
1 | template <(union : decltype(a = 0)>)
| ^
test.cc:1:35: error: expected ‘,’ or ‘...’ before ‘>’ token
test.cc:1:36: error: expected ‘>’ at end of input
1 | template <(union : decltype(a = 0)>)
|^
test.cc:1:36: error: expected unqualified-id at end of input
I guess GCC-trunk emits the bogus error message "expected ‘{’ before ‘)’
token", and the following error messages are inconsistent with GCC-10. So,
GCC-trunk might have something wrong with while parsing this code.
[Bug tree-optimization/94969] [8/10 Regression] Invalid loop distribution since r8-2390-gdfbddbeb1ca912c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969 Richard Biener changed: What|Removed |Added Resolution|FIXED |--- Known to work||9.3.1 Status|CLOSED |ASSIGNED Known to fail||10.1.0 Summary|[8/9/10/11 Regression] |[8/10 Regression] Invalid |Invalid loop distribution |loop distribution since |since |r8-2390-gdfbddbeb1ca912c9 |r8-2390-gdfbddbeb1ca912c9 | --- Comment #15 from Richard Biener --- I don't see the commit on the GCC 10 branch nor the GCC 8 branch. Master and GCC 9 are fixed though.
[Bug c++/95723] New: GCC get confused while parsing a code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95723 Bug ID: 95723 Summary: GCC get confused while parsing a code Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: haoxintu at gmail dot com Target Milestone: --- This code test.cc, GCC might get confused in parsing. $cat test.cc template friend foo ( decltype (b=c $g++-trunk -w test.cc test.cc:1:12: error: ‘a’ has not been declared 1 | template friend foo( decltype (b=c |^ test.cc:1:14: error: ‘friend’ used outside of class 1 | template friend foo( decltype (b=c | ^~ | -- test.cc:1:36: error: ‘b’ was not declared in this scope 1 | template friend foo( decltype (b=c |^ test.cc:1:36: error: ‘b’ was not declared in this scope test.cc:1:38: error: ‘c’ was not declared in this scope 1 | template friend foo( decltype (b=c | ^ test.cc:2: error: expected ‘,’ or ‘...’ at end of input test.cc:1:39: error: expected ‘)’ at end of input 1 | template friend foo( decltype (b=c |~ ^ | ) test.cc:2: error: expected initializer at end of input $g++-10 -w test.cc test.cc:1:12: error: ‘a’ has not been declared 1 | template friend foo( decltype (b=c |^ test.cc:1:14: error: ‘friend’ used outside of class 1 | template friend foo( decltype (b=c | ^~ | -- test.cc:1:36: error: ‘b’ was not declared in this scope 1 | template friend foo( decltype (b=c |^ test.cc:1:36: error: ‘b’ was not declared in this scope test.cc:1:38: error: ‘c’ was not declared in this scope 1 | template friend foo( decltype (b=c | ^ test.cc:1:36: error: ‘b’ was not declared in this scope 1 | template friend foo( decltype (b=c |^ test.cc:1:36: error: ‘b’ was not declared in this scope test.cc:1:38: error: ‘c’ was not declared in this scope 1 | template friend foo( decltype (b=c | ^ test.cc:1:36: error: ‘b’ was not declared in this scope 1 | template friend foo( decltype (b=c |^ test.cc:1:36: error: ‘b’ was not declared in this scope test.cc:1:38: error: ‘c’ was not declared in this scope 1 | template friend foo( decltype (b=c | ^ test.cc:1:21: error: ISO C++ forbids declaration of ‘foo’ with no type [-fpermissive] 1 | template friend foo( decltype (b=c | ^~~ test.cc:1:36: error: ‘b’ was not declared in this scope 1 | template friend foo( decltype (b=c |^ test.cc:1:36: error: ‘b’ was not declared in this scope test.cc:1:38: error: ‘c’ was not declared in this scope 1 | template friend foo( decltype (b=c | ^ test.cc:1:39: error: expected ‘)’ at end of input 1 | template friend foo( decltype (b=c | ~ ~^ | ) test.cc:1:26: error: expected primary-expression before ‘decltype’ 1 | template friend foo( decltype (b=c | ^ test.cc:1:39: error: expected ‘;’ at end of input 1 | template friend foo( decltype (b=c | ~^ | ; I am sure that some error messages in GCC-10 are duplicated. I am also wondering why GCC-trunk emits "error: expected initializer at end of input", that's so confusing.
[Bug fortran/95718] [8/9/10/11 Regression] Wrong pointer associated status without initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95718 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- 16.5.2.2 Pointer association status A pointer may have a pointer association status of associated, disassociated, or undefined. Its association status may change during execution of a program. Unless a pointer is initialized (explicitly or by default), it has an initial association status of undefined. A pointer may be initialized to have an association status of disassociated or associated. 13.7.16 ASSOCIATED (POINTER [, TARGET]) POINTER shall be a pointer. It may be of any type or may be a procedure pointer. Its pointer association status shall not be undefined. Your program is invalid.
[Bug tree-optimization/94969] [8/9/10/11 Regression] Invalid loop distribution since r8-2390-gdfbddbeb1ca912c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969 Andreas Krebbel changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #14 from Andreas Krebbel --- Closing
[Bug tree-optimization/94969] [8/9/10/11 Regression] Invalid loop distribution since r8-2390-gdfbddbeb1ca912c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969 Andreas Krebbel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Andreas Krebbel --- Fixed by Bin Cheng. Thanks!
[Bug target/95704] PPC: int128 shifts should be implemented branchless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704 --- Comment #5 from Jens Seifert --- Power9 code is branchfree but not good at all. _Z3shloy: .LFB0: .cfi_startproc addi 8,5,-64 subfic 6,5,63 srdi 10,3,1 li 7,0 sld 4,4,5 sld 5,3,5 cmpwi 7,8,0 srd 10,10,6 sld 3,3,8 or 4,10,4 isel 5,5,7,28 isel 4,4,3,28 mr 3,5 blr 13 instructions.
[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398 --- Comment #47 from Jiu Fu Guo --- memcmp is using wider reading in glibc; strncmp does not use wider reading. memcmp is using "void *" as arguments, while strncmp is "char *".
[Bug testsuite/95706] New test case gfortran.dg/pr95690.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95706 --- Comment #3 from rguenther at suse dot de --- On Wed, 17 Jun 2020, seurer at linux dot vnet.ibm.com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95706 > > --- Comment #2 from Bill Seurer --- > No idea, sorry. Is that the problem? Supposed to be an error but on a > different line? Yes. On line 5, see the dg-error marker.
[Bug testsuite/95706] New test case gfortran.dg/pr95690.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95706 --- Comment #2 from Bill Seurer --- No idea, sorry. Is that the problem? Supposed to be an error but on a different line?
[Bug other/95722] New: libatomic crashes on __atomic_load of const object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95722
Bug ID: 95722
Summary: libatomic crashes on __atomic_load of const object
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: luis at luismarques dot eu
Target Milestone: ---
With this code in `test.c`:
```
struct S {
int x;
int y;
int z;
};
int main() {
__attribute__((aligned(16))) static const _Atomic struct S a;
struct S b;
b = a;
}
```
On x86_64 I get:
```
$ gcc test.c -latomic && ./a.out
Segmentation fault (core dumped)
```
It crashes on a `lock cmpxchg16b` with the address of `a`, so I imagine the
libatomic implementation is dispatching to an optimized __atomic_load case
where the code assumes it can get a (mutable) lock from the object itself, and
when it tries to acquire that lock it writes to `.rodata`, causing the crash.
[Bug target/95704] PPC: int128 shifts should be implemented branchless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704 --- Comment #4 from Segher Boessenkool --- It no longer generates that rldicl in GCC 9 (or GCC 10). You do get straight-line code already if you use -mcpu=power9, btw (isel; and not totally awful code, but it isn't super of course).
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 68093, which changed state. Bug 68093 Summary: [concepts] friend function declarations that differ only by constraints are rejected as redefinitions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68093 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/68093] [concepts] friend function declarations that differ only by constraints are rejected as redefinitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68093 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |10.0 Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org --- Comment #6 from Patrick Palka --- Looks like this is fully fixed as of GCC 10.
[Bug c++/95508] [10 Regression] ICE on unexpected expression implicit_conv_expr since r10-7096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95508 Marek Polacek changed: What|Removed |Added Summary|[10/11 Regression] ICE on |[10 Regression] ICE on |unexpected expression |unexpected expression |implicit_conv_expr since|implicit_conv_expr since |r10-7096|r10-7096 --- Comment #3 from Marek Polacek --- Fixed on trunk, testing 10 now.
[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700 --- Comment #7 from Ilya Leoshkevich --- Would it be OK then to replace last arguments of functions with __attribute__((sentinel)) from NULLs to nullptrs? I can make a patch for this.
[Bug c++/95508] [10/11 Regression] ICE on unexpected expression implicit_conv_expr since r10-7096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95508 --- Comment #2 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:ae2ebf011fec926e003645c33c07a03619ea216a commit r11-1449-gae2ebf011fec926e003645c33c07a03619ea216a Author: Marek Polacek Date: Wed Jun 17 09:19:02 2020 -0400 c++: ICE with IMPLICIT_CONV_EXPR in array subscript [PR95508] Since r10-7096 convert_like, when called in a template, creates an IMPLICIT_CONV_EXPR when we're converting to/from array type. In this test, we have e[f], and we're converting f (of type class A) to int, so convert_like in build_new_op_1 created the IMPLICIT_CONV_EXPR that got into cp_build_array_ref which calls maybe_constant_value. My patch above failed to adjust this spot to call fold_non_dependent_expr instead, which can handle codes like I_C_E in a template. Fixed by using a new function maybe_fold_non_dependent_expr, which, if the expr can't be evaluated to a constant, returns the original expression. gcc/cp/ChangeLog: PR c++/95508 * constexpr.c (maybe_fold_non_dependent_expr): New. * cp-tree.h (maybe_fold_non_dependent_expr): Declare. * typeck.c (cp_build_array_ref): Call maybe_fold_non_dependent_expr instead of maybe_constant_value. gcc/testsuite/ChangeLog: PR c++/95508 * g++.dg/template/conv16.C: New test.
[Bug testsuite/95716] g++.dg/ext/pr85503.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95716 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Patrick Palka --- Fixed.
[Bug testsuite/95716] g++.dg/ext/pr85503.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95716 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:4d2b0866d760f822c137b69f14d1c51fc760ce53 commit r11-1448-g4d2b0866d760f822c137b69f14d1c51fc760ce53 Author: Patrick Palka Date: Wed Jun 17 09:09:53 2020 -0400 Fix use of inaccessible member in pr85503.C [PR95716] The recent PR41437 fix exposed a latent use of an inaccessible member in the below testcase. gcc/testsuite/ChangeLog: PR testsuite/95716 * g++.dg/ext/pr85503.C: Give ai::cv public access.
[Bug fortran/95710] ICE in gfc_type_is_extensible, at fortran/resolve.c:8848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95710 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2020-06-17 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Priority|P3 |P4 --- Comment #1 from Dominique d'Humieres --- Confirmed. No submodule in r5.
[Bug target/95704] PPC: int128 shifts should be implemented branchless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704 --- Comment #3 from Jens Seifert --- GCC 8.3 generates: _Z3shloy: .LFB0: .cfi_startproc addi 9,5,-64 cmpwi 7,9,0 blt 7,.L2 sld 4,3,9 li 3,0 blr .p2align 4,,15 .L2: srdi 9,3,1 subfic 10,5,63 sld 4,4,5 srd 9,9,10 sld 3,3,5 or 4,9,4 blr .long 0 .byte 0,9,0,0,0,0,0,0 .cfi_endproc 8 instructions if taking L2. The branch free code I propsed: _Z15shl_branch_lessoy: .LFB1: .cfi_startproc rldicl 5,5,0,32 subfic 9,5,64 addi 10,5,-64 sld 10,3,10 srd 9,3,9 sld 4,4,5 or 9,9,10 or 4,9,4 sld 3,3,5 blr 8 instructions no branch. Almost everything can be executed in parallel. rldicl 5,5,0,32 gets added by gcc, which is not necessary.
[Bug tree-optimization/95717] [9/10 Regression] ICE during GIMPLE pass: vect: verify_ssa failed since r9-5325-gf25507d041de4df6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95717 Richard Biener changed: What|Removed |Added Summary|[9/10/11 Regression] ICE|[9/10 Regression] ICE |during GIMPLE pass: vect: |during GIMPLE pass: vect: |verify_ssa failed since |verify_ssa failed since |r9-5325-gf25507d041de4df6 |r9-5325-gf25507d041de4df6 Known to work||11.0 Known to fail||10.1.0 --- Comment #6 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/95717] [9/10/11 Regression] ICE during GIMPLE pass: vect: verify_ssa failed since r9-5325-gf25507d041de4df6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95717 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:d0909f5858ad81e6d8b73fa6193be19cb5e6ed7b commit r11-1447-gd0909f5858ad81e6d8b73fa6193be19cb5e6ed7b Author: Richard Biener Date: Wed Jun 17 14:57:59 2020 +0200 tree-optimization/95717 - fix SSA update for vectorizer epilogue This fixes yet another issue with the custom SSA updating in the vectorizer when we copy from the non-if-converted loop. We must not mess with current defs before we updated the BB copies. 2020-06-17 Richard Biener PR tree-optimization/95717 * tree-vect-loop-manip.c (slpeel_tree_duplicate_loop_to_edge_cfg): Move BB SSA updating before exit/latch PHI current def copying. * g++.dg/torture/pr95717.C: New testcase.
[Bug fortran/95709] [9/10/11 Regression] ICE in gfc_resolve_code, at fortran/resolve.c:11807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95709 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-06-17
[Bug target/95704] PPC: int128 shifts should be implemented branchless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95704 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||segher at gcc dot gnu.org Last reconfirmed||2020-06-17 --- Comment #2 from Segher Boessenkool --- (In reply to Jens Seifert from comment #0) > PowerPC processors don't like branches and branch mispredicts lead to large > overhead. While that is of course true, the situation isn't worse than on other CPUs. The situation here is exactly analogous to 64-bit shifts with -m32. Fixed distance shifts (and rotates) generate pretty much ideal code already (sometimes it could save a "mr" insn, by reordering more -- that is because the rl*imi insns use a register as both input and output). > shift left/right unsigned __in128 can be implemented in 8 instructions which > can be processed on 2 pipelines almost in parallel leading to ~5 cycle > latency on Power 7 and 8. > shift right algebraic __int128 can be implemented in 10 instructions. > Overall comparable in latency of the branching code. This can be done better, using the fact that shifts over 64..127 bits are defined just fine for 64-bit power shift insns. > The unnecessary rldicl 8,5,0,32 at the beginning of the routines are also > not necessary. I see no rldicl? Confirmed.
[Bug testsuite/95716] g++.dg/ext/pr85503.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95716 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-06-17 --- Comment #1 from Patrick Palka --- Looking into it.
[Bug c/95699] __builtin_constant_p inconsistencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95699 --- Comment #9 from Jakub Jelinek --- Created attachment 48749 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48749&action=edit gcc11-pr95699.patch Untested patch to improve the minmax optimization.
[Bug tree-optimization/95717] [9/10/11 Regression] ICE during GIMPLE pass: vect: verify_ssa failed since r9-5325-gf25507d041de4df6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95717
--- Comment #4 from Richard Biener ---
The bogus def is set via
if (scalar_loop != loop)
{
/* If we copied from SCALAR_LOOP rather than LOOP, SSA_NAMEs from
SCALAR_LOOP will have current_def set to SSA_NAMEs in the new_loop,
but LOOP will not. slpeel_update_phi_nodes_for_guard{1,2} expects
the LOOP SSA_NAMEs (on the exit edge and edge from latch to
header) to have current_def set, so copy them over. */
slpeel_duplicate_current_defs_from_edges (single_exit (scalar_loop),
exit);
because that interferes with the renaming process. The if-conversion
applied the missed optimization to the to-be vectorized loop introducing
a LC PHI (required for the not if-converted copy) which has one invariant
and one non-invariant arg.
So we have to do that copying after renaming in the BBs. That seems to work,
testing patch.
[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:9efbb03616f556dcceabe364f734b5b11fb13587 commit r11-1446-g9efbb03616f556dcceabe364f734b5b11fb13587 Author: Martin Liska Date: Wed Jun 17 13:42:20 2020 +0200 testsuite: clean up .gcov files in test-suite. gcc/testsuite/ChangeLog: PR testsuite/95720 * gcc.misc-tests/gcov-pr94029.c: Remove not needed remove-gcda. * lib/gcov.exp: Delete properly .gcov files.
[Bug bootstrap/95721] [11 Regression] bootstrap failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95721 Andreas Krebbel changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andreas Krebbel --- This should be fixed with: commit 929fd91ba975eebf9e57f7f092041271dcaf0c34 Author: Stefan Schulze Frielinghaus Date: Thu Jun 4 13:50:49 2020 +0200 S/390: Emit vector alignment hints for z13 if AS accepts them Since 87cb9423add vector alignment hints are emitted for target z13, too. This patch changes this behaviour in the sense that alignment hints are only emitted for target z13 if the assembler accepts them. gcc/ChangeLog: * config.in: Regenerate. * config/s390/s390.c (print_operand): Emit vector alignment hints for target z13, if AS accepts them. For other targets the logic stays the same. * config/s390/s390.h (TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS): Define macro. * configure: Regenerate. * configure.ac: Check HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS_ON_Z13.
[Bug bootstrap/95721] New: [11 Regression] bootstrap failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95721 Bug ID: 95721 Summary: [11 Regression] bootstrap failure on s390x-linux-gnu Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- trunk 20200616 fails to build on s390x-linux-gnu. /tmp/ccc8NlUQ.s:46: Error: junk at end of line: `,3' /tmp/ccc8NlUQ.s:49: Error: junk at end of line: `,3' make[5]: *** [Makefile:501: _absvdi2.o] Error 1 make[5]: *** Waiting for unfinished jobs /tmp/ccwYynXs.s: Assembler messages: /tmp/ccwYynXs.s:38: Error: junk at end of line: `,3' /tmp/ccwYynXs.s:40: Error: junk at end of line: `,3' /tmp/ccwYynXs.s:42: Error: junk at end of line: `,3' /tmp/ccwYynXs.s:55: Error: junk at end of line: `,3' /tmp/ccwYynXs.s:64: Error: junk at end of line: `,3' make[5]: *** [Makefile:501: _addvdi3.o] Error 1 make[5]: Leaving directory '/<>/build/s390x-linux-gnu/libgcc' not seen --with-arch=zEC12 seen with --with-arch=z13 --with-tune=z15
[Bug c/95699] __builtin_constant_p inconsistencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95699
--- Comment #8 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #6)
> I don't see why that should be considered a bug.
> All the tests are using __builtin_constant_p in a way that it wasn't
> designed for, where it changes the behavior of the program whether it
> evaluates to 0 or 1.
Well, this was just meant to be a simplified testcase and to easily see whether
__builtin_constant_p gave true or false. But in GMP's longlong.h file (used by
GNU MPFR), there is similar code for aarch64, where the assembly code is
different whether the variable is regarded as a constant or not:
#define sub_ddmmss(sh, sl, ah, al, bh, bl) \
do { \
if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000) \
__asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
: "=r,r" (sh), "=&r,&r" (sl) \
: "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)), \
"r,Z" ((UDItype)(al)), "rI,r" (-(UDItype)(bl))
__CLOBBER_CC);\
else\
__asm__ ("subs\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
: "=r,r" (sh), "=&r,&r" (sl) \
: "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)), \
"r,Z" ((UDItype)(al)), "rI,r" ((UDItype)(bl))
__CLOBBER_CC);\
} while(0);
The assembly code is actually buggy in the "if" case (this was how one could
find out that there was a difference between GCC 9, where the "if" case was
selected, and GCC 10, where the "else" case was selected), but I doubt that GCC
is aware about this bug:
https://sympa.inria.fr/sympa/arc/mpfr/2020-06/msg00052.html
https://sympa.inria.fr/sympa/arc/mpfr/2020-06/msg00059.html
I suppose that the general goal of this test using __builtin_constant_p is to
have faster assembly code when some value is known at compile time. So the
intent (with the fixed assembly code[*]) is to have the same behavior, but have
faster code if possible. This is what we got with GCC 9, but this is no longer
the case with GCC 10.
[*] https://gmplib.org/list-archives/gmp-bugs/2020-June/004807.html
[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |11.0 Last reconfirmed||2020-06-17 CC||aoliva at gcc dot gnu.org Ever confirmed|0 |1 Summary|New dump output filename|[11 Regression] New dump |strategy invalidates tests |output filename strategy ||invalidates tests --- Comment #1 from Richard Biener --- Indeed that part of the testsuite needs to be adapted but the change was deliberate (and good).
