[Bug gcov-profile/96534] New: keep gcov intermediate format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96534 Bug ID: 96534 Summary: keep gcov intermediate format Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: xlwu at synopsys dot com CC: marxin at gcc dot gnu.org Target Milestone: --- since gcc9, the gcov did not support intermediate format and replace with json format , our application deeply depend on intermediate format , is it possible to restore the intermediate format ? or could you let me know any workaround ? background : I am a software engineer from SNPS , we have an application that extract all file+functions and it's related lines per test case, and we save this data into DB which help us to predict the test to verify when RnD updated any lines in source code before their check in. we call this application as "smart regression". now , when gcov move to json file, it increase the size a lot which affect the efficiency to parse the data , what's worse, we had to revise our code to support the new json format while we need to support the old format in the same time , as our company have many products and each product have many live branches , some of them still using gcc6 version. I tried to use older gcov version on the new gcc instructed gcda and gcno file , it did not work.
[Bug c++/96533] New: ICE with -Wunused-parameter when using three-way comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96533
Bug ID: 96533
Summary: ICE with -Wunused-parameter when using three-way
comparison
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: natattak at gmail dot com
Target Milestone: ---
Minimal example:
#include
#include
struct S {
// making it a member fixes the issue
friend auto operator<=>(S, S) = default;
};
// removing 'rhs' fixes the issue
template
auto operator<(Lhs&&, Rhs&& rhs) {
return true;
}
int main() {
// using operator< directly fixes the issue
//return S{} < S{};
return std::less{}(S{}, S{});
}
Compiled with `g++ -std=c++20 -Wunused-parameter`. Output:
'
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #33 from Ian Lance Taylor ---
> There are actually only 32 signals, however mksigtab.sh adds a signal at 0
> "SIGNONE: no trap", which makes 33 signals in sigtable. Freebsd sets _NSIG
> to 32 for 33 signals, counting from 0 vice 1. mksysinfo.sh pulls the value
> for _NSIG directly from signal.h. Seems the only way to fix is by modifying
> signal.h
32 signals implies signal numbers 0 to 31. The error says that len(sigtable)
is 33, implying that mksigtab.sh found signal 32 somewhere. Where did that
come from?
(Changing signal.h is not going to be the right approach.)
> BTW, removing the "_thread" definition results in the following.
>
> runtime_sysinfo.go:516:36: error: use of undefined type '_thread'
> 516 | type _cv_waitq struct { tqh_first *_thread; tqh_last **_thread; }
> |^
>
> However, I don't see any other references to "__cv_waitq" in the code.
Add it to the fgrep -v in mkrsysinfo.sh. The names like _thread and _cv_waitq
are coming from system header files, not from Go code.
[Bug target/96532] [m68k] gcc 10.x generates calls to memset even for very small amounts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96532 --- Comment #2 from Thorsten Otto --- Created attachment 49030 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49030=edit Assembler output produced by gcc 7.1.0
[Bug target/96532] [m68k] gcc 10.x generates calls to memset even for very small amounts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96532 --- Comment #1 from Thorsten Otto --- Created attachment 49029 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49029=edit Asembler output produced by gcc 10
[Bug target/96532] New: [m68k] gcc 10.x generates calls to memset even for very small amounts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96532
Bug ID: 96532
Summary: [m68k] gcc 10.x generates calls to memset even for
very small amounts
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
Created attachment 49028
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49028=edit
Sample program
Starting with gcc 10.x, the attached small sample generates library calls to
memset, although it could determine that at most 4 bytes have to be set.
The compiler was generated from a vanilla releases/gcc-10 branch, with a
configuration of:
configure --target=m68k-elf '--prefix=/usr' '--libdir=/usr/lib64'
'--bindir=/usr/bin' '--libexecdir=${libdir}' 'CFLAGS_FOR_BUILD=-O2
-fomit-frame-pointer' 'CFLAGS=-O2 -fomit-frame-pointer' 'CXXFLAGS_FOR_BUILD=-O2
-fomit-frame-pointer' 'CXXFLAGS=-O2 -fomit-frame-pointer' 'BOOT_CFLAGS=-O2
-fomit-frame-pointer' 'CFLAGS_FOR_TARGET=-O2 -fomit-frame-pointer'
'CXXFLAGS_FOR_TARGET=-O2 -fomit-frame-pointer' 'LDFLAGS_FOR_BUILD=' 'LDFLAGS='
'--disable-libvtv' '--disable-libmpx' '--disable-libcc1' '--disable-werror'
'--with-gxx-include-dir=/usr/m68k-elf/sys-root/usr/include/c++/10'
'--with-default-libstdcxx-abi=gcc4-compatible' '--with-gcc-major-version-only'
'--with-gcc' '--with-gnu-as' '--with-gnu-ld' '--with-system-zlib'
'--disable-libgomp' '--without-newlib' '--disable-libstdcxx-pch'
'--disable-threads' '--disable-win32-registry' '--disable-lto' '--enable-ssp'
'--enable-libssp' '--disable-plugin' '--disable-decimal-float' '--disable-nls'
'--with-libiconv-prefix=/usr' '--with-libintl-prefix=/usr'
'--with-sysroot=/usr/m68k-elf/sys-root' 'CC=gcc' 'CXX=g++'
'--enable-languages=c'
Attached are the sample, the assembler output produced by gcc 10, and also the
assembler output of gcc-7.1.0
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #32 from Curtis Hamilton ---
(In reply to Ian Lance Taylor from comment #31)
> > runtime: len(sigtable)=33 _NSIG=32
> > fatal error: bad sigtable len
>
> This error means that the sigtable generated by mksigtab.sh does not match
> the value of _NSIG in the file generated by mksysinfo.sh. You'll need to
> figure out why there is a discrepancy and resolve it.
There are actually only 32 signals, however mksigtab.sh adds a signal at 0
"SIGNONE: no trap", which makes 33 signals in sigtable. Freebsd sets _NSIG to
32 for 33 signals, counting from 0 vice 1. mksysinfo.sh pulls the value for
_NSIG directly from signal.h. Seems the only way to fix is by modifying
signal.h
BTW, removing the "_thread" definition results in the following.
runtime_sysinfo.go:516:36: error: use of undefined type '_thread'
516 | type _cv_waitq struct { tqh_first *_thread; tqh_last **_thread; }
|^
However, I don't see any other references to "__cv_waitq" in the code.
[Bug c++/96531] New: ICE for concepts here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96531
Bug ID: 96531
Summary: ICE for concepts here.
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
#include
#include
template struct pack {};
template struct uv : std::false_type {};
template struct uv> {
using type = pack;
};
template
concept is_any_of_impl_4 = requires(pack) {
requires (std::same_as || ...);
};
inline std::variant v;
template
requires is_any_of_impl_4::type>
void bar() {}
int main() {
bar();
}
https://godbolt.org/z/WPdePT
: In instantiation of 'void bar() [with T = int]':
:22:14: required from here
:12:14: internal compiler error: in tsubst_pack_expansion, at
cp/pt.c:12924
12 | requires (std::same_as || ...);
| ~^~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004 --- Comment #46 from john henning --- Created attachment 49027 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49027=edit More testing 7-aug-2020
[Bug middle-end/82004] [8 Regression] SPEC CPU2017 628.pop2_s miscompare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004 --- Comment #45 from john henning --- I had promised to do some more testing. There were miscompares during the training run (thus causing the build to fail) using -Ofast -flto -fprofile-generate/-fprofile-use on aarch64 with GCC 8.2, 9.3, and 10.1 and on x86_64 with GCC 8.3, 9.3, and 10.1. The above succeeded with GCC 7.3 on both aarch64 and x86_64. The attachment 628.pop2.moretests.7aug2020.txt digs into 10.1 a bit deeper (posted as an attachment to reduce the chances of unwanted line wraps or white space mangling for the tables)
[Bug fortran/96486] get_environment_variable crashes for environment variables that are empty strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #27 from Harald van Dijk --- (In reply to Steve Kargl from comment #24) > On Fri, Aug 07, 2020 at 08:35:49PM +, jussilehtola at fedoraproject dot > org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 > > > > --- Comment #21 from Susi Lehtola > > --- > > to repeat: libgfortran crashes when you try to read an environment variable > > that is an empty string, in the case you have preallocated an array that is > > the > > proper size i.e. zero characters. > > to repeat: I cannot reproduce your issue. It does not crash. > It exits with a runtime error. It seems pretty clear to me that that runtime error is what "crash" refers to. If you are merely wondering why a runtime error does not result in a backtrace being printed for you: the default GCC 6+ behaviour is that runtime errors cause a backtrace to be printed, but this can be changed by -fbacktrace/-fno-backtrace compiler options and the GFORTRAN_ERROR_BACKTRACE runtime environment variable. That is irrelevant to this bug though: the fact that this program results in a runtime error is what this bug is about, not which details get printed as a result of that runtime error. Your output shows that you did manage to reproduce the issue just fine.
[Bug fortran/96486] get_environment_variable crashes for environment variables that are empty strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
--- Comment #26 from Steve Kargl ---
On Fri, Aug 07, 2020 at 09:55:06PM +, sch...@linux-m68k.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
>
> --- Comment #25 from Andreas Schwab ---
> But why does it error out? It shouldn't!
>
You'll have to ask Paul Brook why he chose to issue an error.
% svn annotate libgfortran/intrinsic/env.c
...
85656 pbrook if (value != NULL)
85656 pbrook {
85656 pbrook if (value_len < 1)
85656 pbrook runtime_error ("Zero-length string passed as value to "
85656 pbrook "get_environment_variable.");
85656 pbrook else
85656 pbrook memset (value, ' ', value_len); /* Blank the string.
*/
85656 pbrook }
IIRC, r85656 is tree-ssa becoming pre-gcc 4.0.0.
[Bug fortran/96486] get_environment_variable crashes for environment variables that are empty strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #25 from Andreas Schwab --- But why does it error out? It shouldn't!
[Bug target/96530] MMA built-ins reject typedefs of MMA types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96530 Peter Bergner changed: What|Removed |Added Target||powerpc*-*-* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-08-07 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org CC||dje at gcc dot gnu.org, ||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Keywords||rejects-valid --- Comment #1 from Peter Bergner --- Confirmed and mine.
[Bug target/96530] New: MMA built-ins reject typedefs of MMA types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96530
Bug ID: 96530
Summary: MMA built-ins reject typedefs of MMA types
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
We need to accept typedefs of MMA types too:
typedef __vector_quad vquad_t;
void
foo (__vector_quad *dst)
{
__builtin_mma_xxsetaccz (dst);
}
void
bar (vquad_t *dst)
{
__builtin_mma_xxsetaccz (dst);
}
bergner@pike:~/gcc/BUGS$ gcc -S -O2 -mcpu=power10 bug.c
bug.c: In function ‘bar’:
bug.c:12:3: error: invalid conversion from type ‘* __vector_quad’
12 | __builtin_mma_xxsetaccz (dst);
| ^~~
[Bug testsuite/96525] new test gcc.target/powerpc/pr96493.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525
--- Comment #3 from Peter Bergner ---
(In reply to Peter Bergner from comment #2)
> Ah, you probably are and this issue is the test case probably needs a:
>
> /* { dg-require-effective-target power10_ok } */
>
> To ensure we have a working power10 enabled binutils.
Actually, this is a dg-do run test case, so we need:
/* { dg-require-effective-target power10_hw } */
[Bug fortran/96486] get_environment_variable crashes for environment variables that are empty strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #24 from Steve Kargl --- On Fri, Aug 07, 2020 at 08:35:49PM +, jussilehtola at fedoraproject dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 > > --- Comment #21 from Susi Lehtola --- > to repeat: libgfortran crashes when you try to read an environment variable > that is an empty string, in the case you have preallocated an array that is > the > proper size i.e. zero characters. to repeat: I cannot reproduce your issue. It does not crash. It exits with a runtime error. % setenv HOSTNAME % gfcx -o z b.f90 % ./z Fortran runtime error: Zero-length string passed as value to get_environment_variable. That's it. No crash.
[Bug fortran/96486] get_environment_variable crashes for environment variables that are empty strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #23 from Susi Lehtola --- The expected result is that the program does not crash, since a zero-size character array is enough to fit an empty string.
[Bug fortran/96486] get_environment_variable crashes for environment variables that are empty strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 Susi Lehtola changed: What|Removed |Added Summary|get_environment_variable|get_environment_variable |fails for zero-length |crashes for environment |values |variables that are empty ||strings --- Comment #22 from Susi Lehtola --- to repeat: libgfortran crashes when you try to read an environment variable that is an empty string, in the case you have preallocated an array that is the proper size i.e. zero characters. I don't get any more backtrace than what I've reported above; I guess gdb doesn't debug libgfortran intrinsics by default. The procedure I used was $ gfortran -g -Wall readvar2.f90 $ export HOSTNAME= $ gdb ./a.out (gdb) r Starting program: /tmp/a.out Fortran runtime error: Zero-length string passed as value to get_environment_variable. Error termination. Backtrace: #0 0x401267 in zerolen_value at /tmp/readvar2.f90:17 #1 0x4012c4 in main at /tmp/readvar2.f90:22 [Inferior 1 (process 152269) exited with code 02]
[Bug testsuite/96525] new test gcc.target/powerpc/pr96493.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525
--- Comment #2 from Peter Bergner ---
Ah, you probably are and this issue is the test case probably needs a:
/* { dg-require-effective-target power10_ok } */
To ensure we have a working power10 enabled binutils.
[Bug fortran/96486] get_environment_variable fails for zero-length values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #21 from Susi Lehtola --- to repeat: libgfortran crashes when you try to read an environment variable that is an empty string, in the case you have preallocated an array that is the proper size i.e. zero characters. I don't get any more backtrace than what I've reported above; I guess gdb doesn't debug libgfortran intrinsics by default. The procedure I used was $ gfortran -g -Wall readvar2.f90 $ export HOSTNAME= $ gdb ./a.out (gdb) r Starting program: /tmp/a.out Fortran runtime error: Zero-length string passed as value to get_environment_variable. Error termination. Backtrace: #0 0x401267 in zerolen_value at /tmp/readvar2.f90:17 #1 0x4012c4 in main at /tmp/readvar2.f90:22 [Inferior 1 (process 152269) exited with code 02]
[Bug testsuite/96525] new test gcc.target/powerpc/pr96493.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525 --- Comment #1 from Peter Bergner --- This is an assembler error saying it doesn't know about .machine "power10". Are you sure you're not using an old binutils?
[Bug c/96527] __builtin_va_arg_pack_len produces error in documented sample code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96527 --- Comment #3 from Jakub Jelinek --- The extern inline __attribute__((__gnu_inline__)) usecase comes from actual code (e.g. glibc) where it is used this way a lot, I'm not aware of anybody using static inline __attribute__((__always_inline__)) together with these.
[Bug libstdc++/96303] [10/11 Regression] Ambiguous overload for operator!= for std::__debug::bitset compiled with -std=c++20 and -pedantic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96303 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for 10.3, thanks for the report.
[Bug libstdc++/96303] [10/11 Regression] Ambiguous overload for operator!= for std::__debug::bitset compiled with -std=c++20 and -pedantic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96303 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7e26e4fbd4ee618dd991c6bbf3c5403aa90d2192 commit r10-8592-g7e26e4fbd4ee618dd991c6bbf3c5403aa90d2192 Author: Jonathan Wakely Date: Fri Aug 7 20:29:11 2020 +0100 libstdc++: Fix ambiguous comparisons in __gnu_debug::bitset [PR 96303] With -pedantic the debug mode bitset has an ambiguous equality comparison operator, because it tries to compare the non-debug base to the debug object. The base object can be converted to another debug bitset, making the same operator== a candidate again. The fix is to do the comparison on both base objects, so the operator for the derived type isn't a candidate. For the inequality operator the same change should be done, but that operator can be removed entirely for C++20 because it can be synthesized by the compiler. I don't think either equality or inequality operators are really needed, because the public _GLIBCXX_STD_C::bitset base class cam always be compared using its own comparison operators. I'm not changing that here though. libstdc++-v3/ChangeLog: PR libstdc++/96303 * include/debug/bitset (bitset::operator==): Call _M_base() on right operand. (bitset::operator!=): Likewise, but don't define it at all when default comparisons are supported by the compiler. * testsuite/23_containers/bitset/operations/96303.cc: New test. (cherry picked from commit de1e3b8795e507c3cfa5b62984272628ca62a9bd)
[Bug c/96527] __builtin_va_arg_pack_len produces error in documented sample code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96527 --- Comment #2 from Bruno Haible --- Created attachment 49026 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49026=edit Corrected test case I see. A corrected test case is attached. I wanted to avoid __gnu_inline__ because that's an attribute that is known to have caused trouble with GCC 4.2.x / 4.3.x. Nowadays, the preferred attribute is 'inline' from ISO C11. And I got in trouble with the 'extern' modifier while doing that... How about changing the example in the documentation to use static inline __attribute__((__always_inline__)) instead of extern inline __attribute__((__gnu_inline__)) ?
[Bug c++/96529] New: GCC applies C language linkage to instantiations from abbreviated function templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96529
Bug ID: 96529
Summary: GCC applies C language linkage to instantiations from
abbreviated function templates
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
GCC appears to be treating the instantiated specialization of the abbreviated
function template `g` as if it is a function named `g` whose name has C
language linkage.
[dcl.link] does not appear to apply language linkage to the names of
specializations of function templates.
Note: Nor does [dcl.link] apply language linkage to the names of templates (as
opposed to the type that a specialization of the template would have).
Compiler Explorer link: https://godbolt.org/z/s5875s
### SOURCE ():
extern "C" {
void g(auto) {}
void g(void) { g(42); }
}
### COMPILER INVOCATION:
g++ -std=c++20 -Wall -Wextra -pedantic-errors -xc++ - -c -o /dev/null
### ACTUAL OUTPUT:
/tmp/cc2TjgyX.s: Assembler messages:
/tmp/cc2TjgyX.s:25: Error: symbol `g' is already defined
/tmp/cc2TjgyX.s: Error: .size expression for g does not evaluate to a constant
### EXPECTED OUTPUT:
(clean compile)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200805 (experimental) (GCC)
[Bug libstdc++/96303] [10/11 Regression] Ambiguous overload for operator!= for std::__debug::bitset compiled with -std=c++20 and -pedantic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96303 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:de1e3b8795e507c3cfa5b62984272628ca62a9bd commit r11-2611-gde1e3b8795e507c3cfa5b62984272628ca62a9bd Author: Jonathan Wakely Date: Fri Aug 7 20:29:11 2020 +0100 libstdc++: Fix ambiguous comparisons in __gnu_debug::bitset [PR 96303] With -pedantic the debug mode bitset has an ambiguous equality comparison operator, because it tries to compare the non-debug base to the debug object. The base object can be converted to another debug bitset, making the same operator== a candidate again. The fix is to do the comparison on both base objects, so the operator for the derived type isn't a candidate. For the inequality operator the same change should be done, but that operator can be removed entirely for C++20 because it can be synthesized by the compiler. I don't think either equality or inequality operators are really needed, because the public _GLIBCXX_STD_C::bitset base class cam always be compared using its own comparison operators. I'm not changing that here though. libstdc++-v3/ChangeLog: PR libstdc++/96303 * include/debug/bitset (bitset::operator==): Call _M_base() on right operand. (bitset::operator!=): Likewise, but don't define it at all when default comparisons are supported by the compiler. * testsuite/23_containers/bitset/operations/96303.cc: New test.
[Bug c++/96409] A lambda with a template parameter list inside the template function using C++20 nested requirements clauses occurs internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96409 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/96410] A lambda with a template parameter list inside the template function using C++20 requires clauses is not usable in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96410 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/96526] New built-in needed to implement std::strong_order total order on floating point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96526 --- Comment #1 from joseph at codesourcery dot com --- You could define __builtin_totalorder functions, but watch out for the change made to totalorder functions following a TS 18661-1 clarification request, from floating-point argument types to pointer argument types (so you'd need to handle all the cases of libm not having the functions, libm having them with the old prototypes as in glibc 2.25 through 2.30, libm having them with the new prototypes as in glibc 2.31 and later).
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #31 from Ian Lance Taylor --- > runtime: len(sigtable)=33 _NSIG=32 > fatal error: bad sigtable len This error means that the sigtable generated by mksigtab.sh does not match the value of _NSIG in the file generated by mksysinfo.sh. You'll need to figure out why there is a discrepancy and resolve it.
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #30 from Curtis Hamilton --- Ian, I've made progress with building the frontend but I have an issue with implementing Syscall9 needed by libgo/go/os/wait_wait6.go. I tried adding the file "syscall_freebsd_ppc64.go" containing the following: func Syscall9(trap, a1, a2, a3, a4, a5, a6, a7, a8, a9 uintptr) (r1, r2 uintptr, err Errno) that gets me past the initial error. But now I get the below error when linking gotools. gmake[6]: Leaving directory '/usr/ports/lang/gcc10/work/.build/powerpc64-portbld-freebsd12.1/libgo' gmake[5]: Leaving directory '/usr/ports/lang/gcc10/work/.build/powerpc64-portbld-freebsd12.1/libgo' gmake[4]: Leaving directory '/usr/ports/lang/gcc10/work/.build/powerpc64-portbld-freebsd12.1/libgo' gmake[4]: Entering directory '/usr/ports/lang/gcc10/work/.build/gotools' /usr/ports/lang/gcc10/work/.build/./gcc/gccgo -B/usr/ports/lang/gcc10/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd12.1/bin/ -B/usr/local/powerpc64-portbld-freebsd12.1/lib/ -isystem /usr/local/powerpc64-portbld-freebsd12.1/include -isystem /usr/local/powerpc64-portbld-freebsd12.1/sys-include -g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -I ../powerpc64-portbld-freebsd12.1/libgo -static-libstdc++ -static-libgcc -L ../powerpc64-portbld-freebsd12.1/libgo -L ../powerpc64-portbld-freebsd12.1/libgo/.libs -o go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/go/alldocs.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/go/go11.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/go/main.go ../powerpc64-portbld-freebsd12.1/libgo/libgotool.a /usr/ports/lang/gcc10/work/.build/./gcc/gccgo -B/usr/ports/lang/gcc10/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd12.1/bin/ -B/usr/local/powerpc64-portbld-freebsd12.1/lib/ -isystem /usr/local/powerpc64-portbld-freebsd12.1/include -isystem /usr/local/powerpc64-portbld-freebsd12.1/sys-include -g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -I ../powerpc64-portbld-freebsd12.1/libgo -static-libstdc++ -static-libgcc -L ../powerpc64-portbld-freebsd12.1/libgo -L ../powerpc64-portbld-freebsd12.1/libgo/.libs -o gofmt /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/gofmt/doc.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/gofmt/gofmt.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/gofmt/internal.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/gofmt/rewrite.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/gofmt/simplify.go ../powerpc64-portbld-freebsd12.1/libgo/libgotool.a /usr/ports/lang/gcc10/work/.build/./gcc/gccgo -B/usr/ports/lang/gcc10/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd12.1/bin/ -B/usr/local/powerpc64-portbld-freebsd12.1/lib/ -isystem /usr/local/powerpc64-portbld-freebsd12.1/include -isystem /usr/local/powerpc64-portbld-freebsd12.1/sys-include -g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -I ../powerpc64-portbld-freebsd12.1/libgo -static-libstdc++ -static-libgcc -L ../powerpc64-portbld-freebsd12.1/libgo -L ../powerpc64-portbld-freebsd12.1/libgo/.libs -o vet /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/vet/doc.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/vet/main.go ../powerpc64-portbld-freebsd12.1/libgo/libgotool.a /usr/ports/lang/gcc10/work/.build/./gcc/gccgo -B/usr/ports/lang/gcc10/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd12.1/bin/ -B/usr/local/powerpc64-portbld-freebsd12.1/lib/ -isystem /usr/local/powerpc64-portbld-freebsd12.1/include -isystem /usr/local/powerpc64-portbld-freebsd12.1/sys-include -g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -I ../powerpc64-portbld-freebsd12.1/libgo -static-libstdc++ -static-libgcc -L ../powerpc64-portbld-freebsd12.1/libgo -L ../powerpc64-portbld-freebsd12.1/libgo/.libs -o buildid /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/buildid/buildid.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/buildid/doc.go ../powerpc64-portbld-freebsd12.1/libgo/libgotool.a /usr/ports/lang/gcc10/work/.build/./gcc/gccgo -B/usr/ports/lang/gcc10/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd12.1/bin/ -B/usr/local/powerpc64-portbld-freebsd12.1/lib/ -isystem /usr/local/powerpc64-portbld-freebsd12.1/include -isystem /usr/local/powerpc64-portbld-freebsd12.1/sys-include -g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -I ../powerpc64-portbld-freebsd12.1/libgo -static-libstdc++ -static-libgcc -L ../powerpc64-portbld-freebsd12.1/libgo -L ../powerpc64-portbld-freebsd12.1/libgo/.libs -o test2json /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/test2json/main.go ../powerpc64-portbld-freebsd12.1/libgo/libgotool.a /usr/local/bin/ld: ../powerpc64-portbld-freebsd12.1/libgo/.libs/libgo.so: undefined reference to `syscall.Syscall9' /usr/local/bin/ld: ../powerpc64-portbld-freebsd12.1/libgo/.libs/libgo.so:
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #29 from Ian Lance Taylor --- The runtime_sysinfo.go is manually generated by mkrsysinfo.sh. I don't know where the _thread definition is coming from, but probably the simplest approach is to remove it via the list of grep -v call nears the start of mkrsysinfo.sh.
[Bug c++/96523] variable templates of constant types have incorrect linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96523 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-08-07 Status|UNCONFIRMED |NEW
[Bug libstdc++/55713] std::tuple incorrectly is convertible to "ElementType" when it is an empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713 --- Comment #6 from Jonathan Wakely --- Created attachment 49025 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49025=edit Replace inheritance with data member using [[no_unique_address]] This fixes this bug and all the "See Also" ones, but there's an ICE for the testcases from PR 94062. That ICE is tracked by PR 93711. Once that's fixed I'll fix all these tuple issues.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 79982, which changed state. Bug 79982 Summary: Compiler crashes when using illegal concepts (nested requirements) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79982 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/79982] Compiler crashes when using illegal concepts (nested requirements)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79982 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |10.0 --- Comment #2 from Jonathan Wakely --- Fixed by r276764, i.e. "Update the concepts implementation to conform to C++20"
[Bug tree-optimization/96512] wrong code generated with avx512 intrinsics in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96512 --- Comment #3 from N Schaeffer --- (In reply to Richard Biener from comment #2) > With trunk and GCC 10 I see > > vbroadcastsdzmm0, QWORD PTR [8+r8*8] > > can you check newer GCC? GCC 8.4 is out since some time already and I do > remember some fixes to intrinsics. I've tested with GCC 9.1 and 10.1 which do not seem affected. However, it is a very sneaky bug. On the larger original function, the workaround was to compile with -fno-tree-pre On the bug demonstrator, the bug shows up already at -O1 and hence -fno-tree-pre has no effect. I fear the issue may still be around, waiting for the right conditions to show up. So if someone can understand where it comes from in this bug demonstrator with gcc 8.3.0, it may be possible to ensure it is fixed "forever". It may also be an issue on particular installations, mixing several compilers, as godbolt with gcc 8.3 does not produce wrong assembly. Is there a possibility that a wrong immintrin.h is used ? How can I see what path is used for a #include ?
[Bug target/96528] New: [11 Regression] vector comparisons on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96528
Bug ID: 96528
Summary: [11 Regression] vector comparisons on ARM
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: arm-none-linux-gnueabihf
(see the discussion after
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551468.html )
I am using a compiler configured with --target=arm-none-linux-gnueabihf
--with-float=hard --with-cpu=cortex-a9 --with-fpu=neon-fp16
typedef unsigned int vec __attribute__((vector_size(16)));
typedef int vi __attribute__((vector_size(16)));
vi f(vec a,vec b){
return a==5 | b==7;
}
Compiling with -O yields very long scalar code. Adding -fno-tree-forwprop gets
back the nice, vector code. (at higher optimization levels, one may also need
to disable vrp)
This is due to the fact that while the ARM target handles VEC_COND_EXPR just fine, it does not handle a plain v == w that is not fed directly to
a VEC_COND_EXPR. I was surprised to notice that "grep vec_cmp" gives a number
of lines in the aarch64/ directory, but none in arm/, while AFAIK those neon
instructions are the same. Would it be possible to implement this on ARM as
well? Other middle-end options are also possible, but the difference with
aarch64 makes it tempting to handle it in the target.
[Bug c/96527] __builtin_va_arg_pack_len produces error in documented sample code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96527
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||jakub at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Jakub Jelinek ---
The error is correct. __builtin_va_arg_pack_len or __builtin_va_arg_pack can't
work in functions that are not inlined.
And the documentation you refer to is clear about it for both:
"It can be used only in inline functions that are always inlined, never
compiled as a separate function, such as those using __attribute__
((__always_inline__)) or __attribute__ ((__gnu_inline__)) extern inline
functions."
So, either you need to compile with -fgnu-inline, or have the gnu_inline
attribute on it if it is extern inline, or it must be only inline and not
extern inline for the standard C.
extern inline __attribute__ ((__gnu_inline__)) is the mode it was designed for,
if it can be inline, you use something that accesses the ... arguments,
otherwise either you have a guarantee it will never be called out of line, or
there is some external definition which will not use these builtins and will
handle ... normally through va_{list,start,arg,end}.
[Bug c++/80750] [concepts] noexcept specifier operands are allowed but ignored in compound requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80750
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |10.0
Keywords||accepts-invalid
--- Comment #3 from Jonathan Wakely ---
This seems to be fixed, the operand of the noexcept is diagnosed now:
80750.C:2:45: error: expected ';' before '(' token
2 | concept C = requires { { T::smf() } noexcept(false); };
| ^
| ;
80750.C:9:15: error: static assertion failed
9 | static_assert(C);
| ^
80750.C:9:15: note: constraints not satisfied
80750.C:2:9: required by the constraints of 'template concept const
bool C'
80750.C:2:13: in requirements [with T = S1]
80750.C:2:32: note: 'S1::smf()' is not 'noexcept'
2 | concept C = requires { { T::smf() } noexcept(false); };
| ~~^~
It started to be rejected with r276764 "Update the concepts implementation to
conform to C++20"
Here's an updated testcase which was previously accepted and is now rejected:
template
concept C = requires { { T::smf() } noexcept(false); };
struct S1 {
static void smf();
};
struct S2 {
static void smf() noexcept;
};
static_assert(!C);
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 80750, which changed state. Bug 80750 Summary: [concepts] noexcept specifier operands are allowed but ignored in compound requirements https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80750 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/81198] [concepts] Same type constraints not enforced for constrained-type-specifiers specified in trailing return types of abbreviated functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81198 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||accepts-invalid Ever confirmed|0 |1 Last reconfirmed||2020-08-07
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #28 from Curtis Hamilton ---
(In reply to Ian Lance Taylor from comment #27)
> What is the complete contents of your new file? You showed just a
> declaration; is there a function body there as well?
That's what I was missing. I now have it working, here's the complete contents
of the file.
package syscall
// We can't use the gc-syntax .s files for gccgo. On the plus side
// much of the functionality can be written directly in Go.
func Syscall9(trap, a1, a2, a3, a4, a5, a6, a7, a8, a9 uintptr) (r1, r2
uintptr, err Errno) {
Entersyscall()
r, r2, errno := Syscall9(trap, a1, a2, a3, a4, a5, a6, a7, a8, a9)
Exitsyscall()
return r, 0, Errno(errno)
}
func syscall9(uintptr, uintptr, uintptr, uintptr, uintptr, uintptr, uintptr,
uintptr, uintptr, uintptr) (uintptr, uintptr, Errno)
Also, there was an earlier error that I manually changed. Any idea on how to
fix the below:
runtime_sysinfo.go:580:6: error: invalid recursive type
580 | type _thread _thread
|
[Bug c++/92139] Segmentation fault on constraints verification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92139 --- Comment #2 from Jonathan Wakely --- Mateusz, the testcase wasn't attached. Are you still able to provide it? If not we'll have to close this.
[Bug c++/92431] ICE with spaceship in constexpr evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92431 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > This is incomplete because std::strong_order doesn't support > floating-point types. See PR 96526 regarding that. > The partial_order and weak_order tests use VERIFY instead of > static_assert because of PR 92431. Some of those VERIFYs have been changed to static_assert in r11-2609
[Bug c/96527] New: __builtin_va_arg_pack_len produces error in documented sample code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96527 Bug ID: 96527 Summary: __builtin_va_arg_pack_len produces error in documented sample code Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- Created attachment 49024 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49024=edit Test case The only documented example of __builtin_va_arg_pack_len, in https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Constructing-Calls.html , produces an error "invalid use of '__builtin_va_arg_pack_len ()'" when actually used. Test case foo.c is attached. GCC 5.5.0, 6.5.0, 7.5.0, 8.4.0, 9.3.0, 10.2.0 all produce an error: $ gcc -O2 -Wall -S foo.c foo.c: In function 'myopen': foo.c:7:7: error: invalid use of '__builtin_va_arg_pack_len ()' 7 | if (__builtin_va_arg_pack_len () > 1) | ^~~~
[Bug c++/92431] ICE with spaceship in constexpr evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92431 --- Comment #5 from Jonathan Wakely --- This was fixed by r10-6572-dfffecb802681fbdb56629d3bdd96491ac660be0 c++: Fix static initialization from <=>. Constant evaluation of genericize_spaceship produced a CONSTRUCTOR, which we then wanted to bind to a reference, which we can't do. So wrap the result in a TARGET_EXPR so we get something with an address. We also need to handle treating the result of cxx_eval_binary_expression as a glvalue for SPACESHIP_EXPR. My earlier change to add uid_sensitive to maybe_constant_value was wrong; we don't even look at the cache when manifestly_const_eval, and I failed to adjust the later call to cxx_eval_outermost_constant_expr. gcc/cp/ChangeLog 2020-02-11 Jason Merrill PR c++/93650 PR c++/90691 * constexpr.c (maybe_constant_value): Correct earlier change. (cxx_eval_binary_expression) [SPACESHIP_EXPR]: Pass lval through. * method.c (genericize_spaceship): Wrap result in TARGET_EXPR.
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #27 from Ian Lance Taylor --- What is the complete contents of your new file? You showed just a declaration; is there a function body there as well?
[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
--- Comment #9 from Jonathan Wakely ---
Another one:
struct A { A(const A&) = delete; };
A f();
struct C
{
[[no_unique_address]] A a;
};
C c{f()};
during RTL pass: expand
ice.C: In function 'void __static_initialization_and_destruction_0(int, int)':
ice.C:10:8: internal compiler error: in assign_temp, at function.c:984
10 | C c{f()};
|^
0x6f9772 assign_temp(tree_node*, int, int)
/home/jwakely/src/gcc/gcc/gcc/function.c:984
0xb56653 expand_call(tree_node*, rtx_def*, int)
/home/jwakely/src/gcc/gcc/gcc/calls.c:3750
0xc87aaa expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/jwakely/src/gcc/gcc/gcc/expr.c:11240
0xc9a133 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/jwakely/src/gcc/gcc/gcc/expr.c:8474
0xc9a133 expand_normal
/home/jwakely/src/gcc/gcc/gcc/expr.h:288
0xc9a133 store_field
/home/jwakely/src/gcc/gcc/gcc/expr.c:7213
0xc966d6 expand_assignment(tree_node*, tree_node*, bool)
/home/jwakely/src/gcc/gcc/gcc/expr.c:5448
0xb66553 expand_call_stmt
/home/jwakely/src/gcc/gcc/gcc/cfgexpand.c:2701
0xb66553 expand_gimple_stmt_1
/home/jwakely/src/gcc/gcc/gcc/cfgexpand.c:3682
0xb66553 expand_gimple_stmt
/home/jwakely/src/gcc/gcc/gcc/cfgexpand.c:3847
0xb6bd9a expand_gimple_basic_block
/home/jwakely/src/gcc/gcc/gcc/cfgexpand.c:5888
0xb6d846 execute
/home/jwakely/src/gcc/gcc/gcc/cfgexpand.c:6572
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/96408] C++20 new attribute [[no_unique_address]] occurs internal compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96408 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Jonathan Wakely --- Looks like a duplicate of PR 93711 *** This bug has been marked as a duplicate of bug 93711 ***
[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 Jonathan Wakely changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #8 from Jonathan Wakely --- *** Bug 96408 has been marked as a duplicate of this bug. ***
[Bug c++/96526] New: New built-in needed to implement std::strong_order total order on floating point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96526 Bug ID: 96526 Summary: New built-in needed to implement std::strong_order total order on floating point types Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- https://wg21.link/cmp.alg#1.3 requires a total order for floating point types, which includes ordering NaNs and infinities, and must be usable in constant expressions. The most robust way to do that is probably to make the compiler know how to do it, possibly using mpfr_total_order_p from MPFR 4.1.0.
[Bug testsuite/96525] New: new test gcc.target/powerpc/pr96493.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525 Bug ID: 96525 Summary: new test gcc.target/powerpc/pr96493.c fails Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:f8ac30f1653ff69706c35af6d725f1d330600f11, r11-2603 This was on a power 8: Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr96493.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -mdejagnu-cpu=power8 -O2 -lm -o ./pr96493.exe(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/pr96493.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -mdejagnu-cpu=power8 -O2 -lm -o ./pr96493.exe /tmp/ccrh64Cq.s: Assembler messages: /tmp/ccrh64Cq.s:33: Error: invalid machine `power10' compiler exited with status 1 Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled1054367.cc -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -S -o exceptions_enabled1054367.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled1054367.cc -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -S -o exceptions_enabled1054367.s FAIL: gcc.target/powerpc/pr96493.c (test for excess errors) Excess errors: /tmp/ccrh64Cq.s:33: Error: invalid machine `power10' UNRESOLVED: gcc.target/powerpc/pr96493.c compilation failed to produce executable
[Bug tree-optimization/96522] [9/10/11 Regression] Incorrect with with -O -fno-tree-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96522 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/96522] [9/10/11 Regression] Incorrect with with -O -fno-tree-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96522
--- Comment #2 from Jakub Jelinek ---
Slightly adjusted testcase that aborts if miscompiled:
/* { dg-do run } */
/* { dg-options "-O -fno-tree-pta" } */
__attribute__((noipa)) void
bar (void)
{
volatile int v = 1;
if (v)
__builtin_abort ();
}
__attribute__((noipa)) void
baz (void)
{
}
__attribute__((noipa)) void
foo (int n, double *p, double *x)
{
if (n < 10 && p != 0)
for (int i = 0; i < 10; i++)
if (x[0] < p[i])
x[i] = 0;
if (p != 0)
bar ();
else
baz ();
}
int
main ()
{
double arr[10];
foo (1000, 0, arr);
return 0;
}
Note, with -O1 neither evrp nor vrp{1,2} are done, but this happens during
dom3.
What I see happening is that we have
_7 = p_16(D) + _6;
in the IL and as it is used in a block guarded with p != 0, we determine (but
don't store for the p_16(D) SSA_NAME that p_16(D) at that point must be
non-NULL and so (IMO correctly) set _7 to be non-NULL in the vr info as well as
SSA_NAME_PTR_INFO. The problem is that during ivopts rewrite_use_address calls
copy_ref_info when copying ref info from *_7 to a TARGET_MEM_REF
MEM[base: p_16(D), index: ivtmp.17_24, offset: 0B] and that in turn will do:
1018 /* We can transfer points-to information from an old pointer
1019 or decl base to the new one. */
1020 if (new_ptr_base
1021 && TREE_CODE (new_ptr_base) == SSA_NAME
1022 && !SSA_NAME_PTR_INFO (new_ptr_base))
I bet the intent is that if new_ptr_base has been a newly created SSA_NAME,
then it is ok to copy the info (maybe), and for other cases without the
-fno-tree-pta the existing SSA_NAMEs will likely have SSA_NAME_PTR_INFO
non-NULL.
Anyway, even if it would be ok to copy the points-to info that way, I think it
isn't ok to copy whether the pointer can be NULL or not.
So, either the condition should include && flag_tree_pta, or at least do
reset_flow_sensitive_info (new_ptr_info). Or maybe callers of copy_ref_info
should pass in a flag whether the new_ptr_info is a freshly created SSA_NAME
(in that case like e.g. in slsr it is probably ok to do what it does ATM), or
not (and then either not do it at all, or do the reset_flow_sensitive_info on
it afterwards, thus forget alignment and non-NULL info that could be only in a
particular region and not valid elsewhere.
[Bug c++/96524] missing warning constructing a larger object in a smaller multidimensional array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96524 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96511, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94195 --- Comment #1 from Martin Sebor --- It looks as though warn_placement_new_too_small() simply doesn't take into consideration milti-dimensional arrays. The missing -Warray-bounds warning is for the same reason as pr94195.
[Bug middle-end/94195] missing warning reading a smaller object via an lvalue of a larger type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94195 Martin Sebor changed: What|Removed |Added Ever confirmed|0 |1 Known to fail||10.2.0, 11.0, 8.4.0, 9.3.0 Last reconfirmed||2020-08-07 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Martin Sebor --- My patch for pr50584 includes code to handle this case as well.
[Bug fortran/96486] get_environment_variable fails for zero-length values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #20 from Steve Kargl --- On Fri, Aug 07, 2020 at 01:14:04PM +, jussilehtola at fedoraproject dot org wrote: > > It already was reproduced in comment #9? > There is clearly a language barrier. At this point, I have no idea what you think the issue is, and I don't care. Good luck getting anyone else to look this bug report.
[Bug c++/96516] template + __attribute__((copy)) produce compiler errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96516 --- Comment #4 from sagebar at web dot de --- (In reply to sagebar from comment #3) > ..., _any_ attribute that > can be inherited via copy() can be made template-conditional in c++: Also note that I've tested if gcc (`-x c') allows multiple copy attributes on the same declaration, and it appears to do allow this, meaning that deferring attribute copy until template instantiation should be made functional for 0-N copy attributes, rather than 0-1: gcc currently allows multiple __attribute__((copy)) within the same declaration: ``` __attribute__((returns_nonnull)) void *func_with_returns_nonnull(); __attribute__((malloc)) void *func_with_malloc(); __attribute__(( copy(func_with_returns_nonnull), copy(func_with_malloc))) void *func_with_both(); #define SASS(x) static_assert(x, #x) SASS(__builtin_has_attribute(func_with_returns_nonnull, returns_nonnull)); SASS(!__builtin_has_attribute(func_with_returns_nonnull, malloc)); SASS(!__builtin_has_attribute(func_with_malloc, returns_nonnull)); SASS(__builtin_has_attribute(func_with_malloc, malloc)); SASS(__builtin_has_attribute(func_with_both, returns_nonnull)); SASS(__builtin_has_attribute(func_with_both, malloc)); ```
[Bug c++/96524] New: missing warning constructing a larger object in a smaller multidimensional array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96524
Bug ID: 96524
Summary: missing warning constructing a larger object in a
smaller multidimensional array
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Only the first of the two functions is diagnosed for attempting to construct an
int object in an array of size 1. The equivalent attempt in g() involving a
multidimensional array with insufficient size is not diagnosed, either by
-Wplacement-new or later by -Warray-bounds (or -Wstringop-overflow, although
this warning is only meant to trigger for char accesses).
$ cat t.C && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout t.C
void* operator new (__SIZE_TYPE__, void *p) { return p; }
char a[1];
char b[1][1];
void f ()
{
new ([0]) int (123); // warning (good)
}
void g ()
{
new ([0][0]) int (456); // no warning
}
t.C: In function ‘void f()’:
t.C:8:8: warning: placement new constructing an object of type ‘int’ and size
‘4’ in a region of type ‘char [1]’ and size ‘1’ [-Wplacement-new=]
8 | new ([0]) int (123); // warning (good)
|^
;; Function operator new (_ZnwmPv, funcdef_no=0, decl_uid=2337, cgraph_uid=1,
symbol_order=0)
operator new (long unsigned int D.2335, void * p)
{
[local count: 1073741824]:
return p_1(D);
}
t.C:8:23: warning: writing 4 bytes into a region of size 1
[-Wstringop-overflow=]
8 | new ([0]) int (123); // warning (good)
| ^
t.C:3:6: note: at offset 0 to object ‘a’ with size 1 declared here
3 | char a[1];
| ^
;; Function f (_Z1fv, funcdef_no=1, decl_uid=2341, cgraph_uid=2,
symbol_order=3)
f ()
{
[local count: 1073741824]:
MEM[(int *)] = 123;
return;
}
;; Function g (_Z1gv, funcdef_no=2, decl_uid=2346, cgraph_uid=3,
symbol_order=4)
g ()
{
[local count: 1073741824]:
MEM[(int *)] = 456;
return;
}
[Bug c++/96516] template + __attribute__((copy)) produce compiler errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96516
--- Comment #3 from sagebar at web dot de ---
No problem. Also: What you just said made me realize that once
__attribute__((copy)) works correctly with templates, _any_ attribute that can
be inherited via copy() can be made template-conditional in c++:
```
template struct conditional_returns_nonnull {
static __attribute__((returns_nonnull)) void *func(void);
};
template<> struct conditional_returns_nonnull {
static void *func(void);
};
template __attribute__((copy(conditional_returns_nonnull::func)))
void *function_with_conditional_returns_nonnull_attribute();
#define SASS(x) static_assert(x, #x)
SASS(!__builtin_has_attribute(
conditional_returns_nonnull::func,
returns_nonnull));
SASS(__builtin_has_attribute(
conditional_returns_nonnull::func,
returns_nonnull));
SASS(!__builtin_has_attribute(
function_with_conditional_returns_nonnull_attribute,
returns_nonnull));
SASS(__builtin_has_attribute(
function_with_conditional_returns_nonnull_attribute,
returns_nonnull));
```
Currently, this doesn't compile due to the last `static_assert()' failing
(Which I'm guessing is due to the same bug)
-> So I guess: Here's another test
[Bug c++/96523] variable templates of constant types have incorrect linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96523 --- Comment #1 from Nathan Sidwell --- Created attachment 49023 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49023=edit testcase part 2
[Bug c++/96523] New: variable templates of constant types have incorrect linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96523 Bug ID: 96523 Summary: variable templates of constant types have incorrect linkage Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- Created attachment 49022 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49022=edit testcase part 1 non-template namespace-scope variables of constant type get internal linkage. We're doing the same for template-variables, which is wrong. The attached two sources should link and run w/o error. The executable returns 2 as the two instantiations of CONST each has internal linkage. devvm293:110>./cc1plus var-1_a.C -quiet devvm293:111>./cc1plus var-1_b.C -quiet devvm293:112>g++ var-1_*.s devvm293:113>./a.out (2)devvm293:114> [basic.link]/3: A name having namespace scope (6.4.6) has internal linkage if it is the name of (3.1) — a variable, variable template, function, or function template that is explicitly declared static; or (3.2) — a non-template variable of non-volatile const-qualified type, unless ... [Note: An instantiated variable template that has const-qualified type can have external or module linkage, even if not declared extern. — end note] working on a fix, but would like confirmation of bug
[Bug c++/96511] Incorrect placement-new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96511
Martin Sebor changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail||10.2.0, 11.0, 8.4.0, 9.3.0
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-08-07
CC||msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
Confirmed. To determine the final offset the warning multiplies the offset in
a POINTER_PLUS expression by the elements size the same way it does the index
in an ARRAY_REF expression. The latter is correct but the former isn't.
A simplified test case:
$ cat pr96511.C && gcc -S -Wall -Wextra pr96511.C
void* operator new (__SIZE_TYPE__, void *p) { return p; }
void g ()
{
int a[2];
new ([0] + 1) int;
}
pr96511.C: In function ‘void g()’:
pr96511.C:7:14: warning: placement new constructing an object of type ‘int’ and
size ‘4’ in a region of type ‘int [2]’ and size ‘0’ [-Wplacement-new=]
7 | new ([0] + 1) int;
|~~^~~
[Bug c++/87729] Please include -Woverloaded-virtual in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87729 --- Comment #5 from xantares09 at hotmail dot com --- still there with 10.1, see attached patch
[Bug c++/87729] Please include -Woverloaded-virtual in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87729 xantares09 at hotmail dot com changed: What|Removed |Added CC||xantares09 at hotmail dot com --- Comment #4 from xantares09 at hotmail dot com --- Created attachment 49021 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49021=edit enable -Woverloaded-virtual by -Wall
[Bug tree-optimization/96522] [9/10/11 Regression] Incorrect with with -O -fno-tree-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96522 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |9.4 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 Summary|Incorrect with with -O |[9/10/11 Regression] |-fno-tree-pta |Incorrect with with -O ||-fno-tree-pta Last reconfirmed||2020-08-07 --- Comment #1 from Jakub Jelinek --- Started with r263662 aka r9-2475-g4864297f7858617a5fe406d3651a46446b41db7a
[Bug tree-optimization/96522] New: Incorrect with with -O -fno-tree-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96522 Bug ID: 96522 Summary: Incorrect with with -O -fno-tree-pta Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: trt at alumni dot duke.edu Target Milestone: --- Created attachment 49020 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49020=edit demo of flaw in no-tree-pta The attached program t.c, when compiled with # gcc (GCC) 10.2.0 gcc t.c -O -fno-tree-pta has this output: I think p is non-NULL I think p is non-NULL But it is obvious that p is NULL
[Bug c++/96521] New: Suggest signal.h missing include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96521
Bug ID: 96521
Summary: Suggest signal.h missing include
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
Hello
Could g++ suggest signal.h?
int main()
{
raise(SIGSEGV);
}
#1 with x86-64 gcc (trunk)
: In function 'int main()':
:3:11: error: 'SIGSEGV' was not declared in this scope
3 | raise(SIGSEGV);
| ^~~
:3:5: error: 'raise' was not declared in this scope
3 | raise(SIGSEGV);
| ^
Compiler returned: 1
[Bug target/96520] New: [nvptx] Fix set insn component order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96520
Bug ID: 96520
Summary: [nvptx] Fix set insn component order
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
I noticed that we emit:
...
set.u32.eq.u64 %r31,%r26,2147483648;
...
But the ptx isa specifies:
...
set.CmpOp{.ftz}.dtype.stype d, a, b;
...
so we should emit instead:
...
set.eq.u32.u64 %r31,%r26,2147483648;
...
[Bug debug/96472] ICE: c++: dwarf2out_abstract_function, at dwarf2out.c: -g -fdebug-types-section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96472
Richard Biener changed:
What|Removed |Added
Keywords|needs-reduction |ice-on-valid-code
--- Comment #2 from Richard Biener ---
template class b;
template struct B;
template struct B> { using d = c; };
class f {
public:
f(char *);
~f();
};
template struct g { typedef typename B::d d; };
template > class h : g {};
void i() {
typedef struct {
f j;
} k;
h a;
k{""};
}
guess the templates can be simplified manually a bit.
[Bug testsuite/96519] New: [11 regression] new test case gcc.dg/ia64-sync-5.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96519
Bug ID: 96519
Summary: [11 regression] new test case gcc.dg/ia64-sync-5.c
fails
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:6339f93279b24b5a61eeed2a5040b8b2a0d3ab42, r11-2605
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/gcc/
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/ia64-sync-5.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -ansi -pedantic-errors -lm
-o ./ia64-sync-5.exe
PASS: gcc.dg/ia64-sync-5.c (test for excess errors)
. . .
Execution timeout is: 300
spawn [open ...]
FAIL: gcc.dg/ia64-sync-5.c execution test
testcase /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/dg.exp completed in
0 seconds
=== gcc Summary ===
# of expected passes1
# of unexpected failures1
(gdb) run
Starting program: /home/seurer/gcc/git/build/gcc-test/./ia64-sync-5.exe
Program received signal SIGABRT, Aborted.
0x3fffb7cd258c in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:55
55return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) where
#0 0x3fffb7cd258c in __GI_raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:55
#1 0x3fffb7cd4778 in __GI_abort () at abort.c:90
#2 0x16f4 in do_qi () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/ia64-sync-5.c:25
#3 0x1a44 in main () at
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/ia64-sync-5.c:74
static void
do_qi (void)
{
if (__sync_val_compare_and_swap(AC+0, -30, -115) != -30)
abort (); // line 25
...
[Bug c++/96516] template + __attribute__((copy)) produce compiler errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96516 --- Comment #2 from Martin Sebor --- Thank you for taking the time to put together all the test cases and reporting the problem, by the way!
[Bug c++/96516] template + __attribute__((copy)) produce compiler errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96516
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Last reconfirmed||2020-08-07
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
I think the C++ front end needs to hold off applying the copy attribute until
the template it's on is instantiated. This is hardcoded for other attributes
but not for copy, so it won't work very well with templates.
This doesn't work correctly either (although probably for a different reason):
template
__attribute__((returns_nonnull)) T foo () { return T (); }
__attribute__((copy (foo))) void* bar () { return 0; }
t.C:4:47: warning: ‘copy’ attribute ignored on a declaration of a different
kind than referenced symbol [-Wattributes]
4 | __attribute__((copy (foo))) void* bar () { return 0; }
| ^
[Bug target/96493] powerpc local call linkage failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493 Peter Bergner changed: What|Removed |Added Target Milestone|--- |10.3 --- Comment #4 from Peter Bergner --- (In reply to Alan Modra from comment #2) > Yes, it is a bug present in any gcc version supporting pcrel. Ok, then I'm setting the target milestone to GCC 10.3.
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #26 from Curtis Hamilton --- Ian, I've made progress with building the frontend but I have an issue with implementing Syscall9 needed by libgo/go/os/wait_wait6.go. I tried adding the file "syscall_freebsd_ppc64.go" containing the following: func Syscall9(trap, a1, a2, a3, a4, a5, a6, a7, a8, a9 uintptr) (r1, r2 uintptr, err Errno) that gets me past the initial error. But now I get the below error when linking gotools. gmake[6]: Leaving directory '/usr/ports/lang/gcc10/work/.build/powerpc64-portbld-freebsd12.1/libgo' gmake[5]: Leaving directory '/usr/ports/lang/gcc10/work/.build/powerpc64-portbld-freebsd12.1/libgo' gmake[4]: Leaving directory '/usr/ports/lang/gcc10/work/.build/powerpc64-portbld-freebsd12.1/libgo' gmake[4]: Entering directory '/usr/ports/lang/gcc10/work/.build/gotools' /usr/ports/lang/gcc10/work/.build/./gcc/gccgo -B/usr/ports/lang/gcc10/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd12.1/bin/ -B/usr/local/powerpc64-portbld-freebsd12.1/lib/ -isystem /usr/local/powerpc64-portbld-freebsd12.1/include -isystem /usr/local/powerpc64-portbld-freebsd12.1/sys-include -g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -I ../powerpc64-portbld-freebsd12.1/libgo -static-libstdc++ -static-libgcc -L ../powerpc64-portbld-freebsd12.1/libgo -L ../powerpc64-portbld-freebsd12.1/libgo/.libs -o go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/go/alldocs.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/go/go11.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/go/main.go ../powerpc64-portbld-freebsd12.1/libgo/libgotool.a /usr/ports/lang/gcc10/work/.build/./gcc/gccgo -B/usr/ports/lang/gcc10/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd12.1/bin/ -B/usr/local/powerpc64-portbld-freebsd12.1/lib/ -isystem /usr/local/powerpc64-portbld-freebsd12.1/include -isystem /usr/local/powerpc64-portbld-freebsd12.1/sys-include -g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -I ../powerpc64-portbld-freebsd12.1/libgo -static-libstdc++ -static-libgcc -L ../powerpc64-portbld-freebsd12.1/libgo -L ../powerpc64-portbld-freebsd12.1/libgo/.libs -o gofmt /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/gofmt/doc.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/gofmt/gofmt.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/gofmt/internal.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/gofmt/rewrite.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/gofmt/simplify.go ../powerpc64-portbld-freebsd12.1/libgo/libgotool.a /usr/ports/lang/gcc10/work/.build/./gcc/gccgo -B/usr/ports/lang/gcc10/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd12.1/bin/ -B/usr/local/powerpc64-portbld-freebsd12.1/lib/ -isystem /usr/local/powerpc64-portbld-freebsd12.1/include -isystem /usr/local/powerpc64-portbld-freebsd12.1/sys-include -g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -I ../powerpc64-portbld-freebsd12.1/libgo -static-libstdc++ -static-libgcc -L ../powerpc64-portbld-freebsd12.1/libgo -L ../powerpc64-portbld-freebsd12.1/libgo/.libs -o vet /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/vet/doc.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/vet/main.go ../powerpc64-portbld-freebsd12.1/libgo/libgotool.a /usr/ports/lang/gcc10/work/.build/./gcc/gccgo -B/usr/ports/lang/gcc10/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd12.1/bin/ -B/usr/local/powerpc64-portbld-freebsd12.1/lib/ -isystem /usr/local/powerpc64-portbld-freebsd12.1/include -isystem /usr/local/powerpc64-portbld-freebsd12.1/sys-include -g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -I ../powerpc64-portbld-freebsd12.1/libgo -static-libstdc++ -static-libgcc -L ../powerpc64-portbld-freebsd12.1/libgo -L ../powerpc64-portbld-freebsd12.1/libgo/.libs -o buildid /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/buildid/buildid.go /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/buildid/doc.go ../powerpc64-portbld-freebsd12.1/libgo/libgotool.a /usr/ports/lang/gcc10/work/.build/./gcc/gccgo -B/usr/ports/lang/gcc10/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd12.1/bin/ -B/usr/local/powerpc64-portbld-freebsd12.1/lib/ -isystem /usr/local/powerpc64-portbld-freebsd12.1/include -isystem /usr/local/powerpc64-portbld-freebsd12.1/sys-include -g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -I ../powerpc64-portbld-freebsd12.1/libgo -static-libstdc++ -static-libgcc -L ../powerpc64-portbld-freebsd12.1/libgo -L ../powerpc64-portbld-freebsd12.1/libgo/.libs -o test2json /usr/ports/lang/gcc10/work/gcc-10.1.0/gotools/../libgo/go/cmd/test2json/main.go ../powerpc64-portbld-freebsd12.1/libgo/libgotool.a /usr/local/bin/ld: ../powerpc64-portbld-freebsd12.1/libgo/.libs/libgo.so: undefined reference to `syscall.Syscall9' /usr/local/bin/ld: ../powerpc64-portbld-freebsd12.1/libgo/.libs/libgo.so:
[Bug fortran/96486] get_environment_variable fails for zero-length values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #19 from Susi Lehtola --- (In reply to Steve Kargl from comment #17) > On Thu, Aug 06, 2020 at 08:33:12PM +, jussilehtola at fedoraproject dot > org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 > > > > --- Comment #16 from Susi Lehtola > > --- > > Yes, then I installed missing libgfortran debuginfos and the backtrace > > shortened to > > > > #0 0x401267 in zerolen_value > > at /tmp/readvar2.f90:17 > > #1 0x4012c4 in main > > at /tmp/readvar2.f90:22 > > > > I cannot reproduce the issue. It already was reproduced in comment #9? The issue is not that the environment variable has not been set, but rather that it is set to an empty string.
[Bug c++/96282] [8/9/10 Regression] internal compiler error: in output_constructor_regular_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96282 Patrick Palka changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |internal compiler error: in |internal compiler error: in |output_constructor_regular_ |output_constructor_regular_ |field |field --- Comment #7 from Patrick Palka --- Fixed for GCC 11 so far.
[Bug target/96402] [8/9/10/11 Regression] Wrong code with -moutline-atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96402 Tamar Christina changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Tamar Christina --- backports done.
[Bug target/96402] [8/9/10/11 Regression] Wrong code with -moutline-atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96402 --- Comment #12 from CVS Commits --- The releases/gcc-8 branch has been updated by Tamar Christina : https://gcc.gnu.org/g:3e2d69ee245e5a44c53cae27a797b97ba529eb72 commit r8-10396-g3e2d69ee245e5a44c53cae27a797b97ba529eb72 Author: Jakub Jelinek Date: Mon Aug 3 22:55:28 2020 +0200 aarch64: Fix up __aarch64_cas16_acq_rel fallback As mentioned in the PR, the fallback path when LSE is unavailable writes incorrect registers to the memory if the previous content compares equal to x0, x1 - it writes copy of x0, x1 from the start of function, but it should write x2, x3. 2020-08-03 Jakub Jelinek PR target/96402 * config/aarch64/lse.S (__aarch64_cas16_acq_rel): Use x2, x3 instead of x(tmp0), x(tmp1) in STXP arguments. * gcc.target/aarch64/pr96402.c: New test. (cherry picked from commit 90b43856fdff7d96d93d22970eca8a86c56e0ddc)
[Bug target/96402] [8/9/10/11 Regression] Wrong code with -moutline-atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96402 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Tamar Christina : https://gcc.gnu.org/g:4e91af9877df9e6b28ea8e50ae9445590363d5b0 commit r9-8796-g4e91af9877df9e6b28ea8e50ae9445590363d5b0 Author: Jakub Jelinek Date: Mon Aug 3 22:55:28 2020 +0200 aarch64: Fix up __aarch64_cas16_acq_rel fallback As mentioned in the PR, the fallback path when LSE is unavailable writes incorrect registers to the memory if the previous content compares equal to x0, x1 - it writes copy of x0, x1 from the start of function, but it should write x2, x3. 2020-08-03 Jakub Jelinek PR target/96402 * config/aarch64/lse.S (__aarch64_cas16_acq_rel): Use x2, x3 instead of x(tmp0), x(tmp1) in STXP arguments. * gcc.target/aarch64/pr96402.c: New test. (cherry picked from commit 90b43856fdff7d96d93d22970eca8a86c56e0ddc)
[Bug c++/96497] Compare std::variant with int using C++20 <=> is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96497 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 49019 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49019=edit gcc11-pr96497.patch Untested fix.
[Bug c++/96518] g++ suggests a weird function when there's a lowercase mistake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96518 Albert Astals Cid changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Albert Astals Cid --- Cool, thanks :)
[Bug libstdc++/93245] std::experimental::filesystem::path::generic_string() doesn't normalize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93245 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |8.5 Status|ASSIGNED|RESOLVED --- Comment #4 from Jonathan Wakely --- Fixed for 8.5 and 9.4 too.
[Bug libstdc++/94242] filesystem::path::generic_string() only works with std::allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94242 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for 8.5 and 9.4 too.
[Bug libstdc++/94242] filesystem::path::generic_string() only works with std::allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94242 --- Comment #3 from CVS Commits --- The releases/gcc-8 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:39a5a04daa09c711caeb6aaff12f1d03406fe29f commit r8-10392-g39a5a04daa09c711caeb6aaff12f1d03406fe29f Author: Jonathan Wakely Date: Sat Mar 21 21:51:07 2020 + libstdc++: Fix path::generic_string allocator handling (PR 94242) It's not possible to construct a path::string_type from an allocator of a different type. Create the correct specialization of basic_string, and adjust path::_S_str_convert to use a basic_string_view so that it is independent of the allocator type. PR libstdc++/94242 * include/bits/fs_path.h (path::_S_str_convert): Replace first parameter with basic_string_view so that strings with different allocators can be accepted. (path::generic_string()): Use basic_string object that uses the right allocator type. * testsuite/27_io/filesystem/path/generic/94242.cc: New test. * testsuite/27_io/filesystem/path/generic/generic_string.cc: Improve test coverage. (cherry picked from commit 9fc985118d9f5014afc1caf32a411ee5803fba61)
[Bug libstdc++/93245] std::experimental::filesystem::path::generic_string() doesn't normalize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93245 --- Comment #3 from CVS Commits --- The releases/gcc-8 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:01cbd26b022cc9d4eaf26287b48299acfce80348 commit r8-10393-g01cbd26b022cc9d4eaf26287b48299acfce80348 Author: Jonathan Wakely Date: Sat Mar 21 22:11:44 2020 + libstdc++: Fix experimental::path::generic_string (PR 93245) This function was unimplemented, simply returning the native format string instead. PR libstdc++/93245 * include/experimental/bits/fs_path.h (path::generic_string()): Return the generic format not the native format. * testsuite/experimental/filesystem/path/generic/generic_string.cc: Improve test coverage. (cherry picked from commit a577c0c26931090e7c25e56ef5ffc807627961ec)
[Bug c++/96518] g++ suggests a weird function when there's a lowercase mistake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96518 --- Comment #1 from Jonathan Wakely --- This is already fixed for GCC 11: diag.C: In function 'int main(int, char**)': diag.C:39:17: error: 'class Foo' has no member named 'getParent'; did you mean 'GetParent'? 39 | Foo *f3 = f.getParent(); | ^ | GetParent
[Bug target/96191] aarch64 stack_protect_test canary leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:3e40be9cc92d3fa117be7f4fab07cedeed8361a2 commit r9-8795-g3e40be9cc92d3fa117be7f4fab07cedeed8361a2 Author: Richard Sandiford Date: Fri Aug 7 12:17:37 2020 +0100 arm: Clear canary value after stack_protect_test [PR96191] The stack_protect_test patterns were leaving the canary value in the temporary register, meaning that it was often still in registers on return from the function. An attacker might therefore have been able to use it to defeat stack-smash protection for a later function. gcc/ PR target/96191 * config/arm/arm.md (arm_stack_protect_test_insn): Zero out operand 2 after use. * config/arm/thumb1.md (thumb1_stack_protect_test_insn): Likewise. gcc/testsuite/ * gcc.target/arm/stack-protector-1.c: New test. * gcc.target/arm/stack-protector-2.c: Likewise. (cherry picked from commit 6a3f3e08723063ea2dadb7ddf503f02972a724e2)
[Bug target/96191] aarch64 stack_protect_test canary leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:5380912a17ea09a8996720fb62b1a70c16c8f9f2 commit r9-8794-g5380912a17ea09a8996720fb62b1a70c16c8f9f2 Author: Richard Sandiford Date: Fri Aug 7 12:17:37 2020 +0100 aarch64: Clear canary value after stack_protect_test [PR96191] The stack_protect_test patterns were leaving the canary value in the temporary register, meaning that it was often still in registers on return from the function. An attacker might therefore have been able to use it to defeat stack-smash protection for a later function. gcc/ PR target/96191 * config/aarch64/aarch64.md (stack_protect_test_): Set the CC register directly, instead of a GPR. Replace the original GPR destination with an extra scratch register. Zero out operand 3 after use. (stack_protect_test): Update accordingly. gcc/testsuite/ PR target/96191 * gcc.target/aarch64/stack-protector-1.c: New test. * gcc.target/aarch64/stack-protector-2.c: Likewise. (cherry picked from commit fe1a26429038d7cd17abc53f96a6f3e2639b605f)
[Bug target/96191] aarch64 stack_protect_test canary leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:8f6b7c9796035ad8b2cdfbce5d3d11dd4b81fad7 commit r10-8584-g8f6b7c9796035ad8b2cdfbce5d3d11dd4b81fad7 Author: Richard Sandiford Date: Fri Aug 7 12:15:02 2020 +0100 arm: Clear canary value after stack_protect_test [PR96191] The stack_protect_test patterns were leaving the canary value in the temporary register, meaning that it was often still in registers on return from the function. An attacker might therefore have been able to use it to defeat stack-smash protection for a later function. gcc/ PR target/96191 * config/arm/arm.md (arm_stack_protect_test_insn): Zero out operand 2 after use. * config/arm/thumb1.md (thumb1_stack_protect_test_insn): Likewise. gcc/testsuite/ * gcc.target/arm/stack-protector-1.c: New test. * gcc.target/arm/stack-protector-2.c: Likewise. (cherry picked from commit 6a3f3e08723063ea2dadb7ddf503f02972a724e2)
[Bug target/96191] aarch64 stack_protect_test canary leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:bab5fdaf9abb1236a7a56258d1d36265068b4827 commit r10-8583-gbab5fdaf9abb1236a7a56258d1d36265068b4827 Author: Richard Sandiford Date: Fri Aug 7 12:15:01 2020 +0100 aarch64: Clear canary value after stack_protect_test [PR96191] The stack_protect_test patterns were leaving the canary value in the temporary register, meaning that it was often still in registers on return from the function. An attacker might therefore have been able to use it to defeat stack-smash protection for a later function. gcc/ PR target/96191 * config/aarch64/aarch64.md (stack_protect_test_): Set the CC register directly, instead of a GPR. Replace the original GPR destination with an extra scratch register. Zero out operand 3 after use. (stack_protect_test): Update accordingly. gcc/testsuite/ PR target/96191 * gcc.target/aarch64/stack-protector-1.c: New test. * gcc.target/aarch64/stack-protector-2.c: Likewise. (cherry picked from commit fe1a26429038d7cd17abc53f96a6f3e2639b605f)
[Bug c++/96518] New: g++ suggests a weird function when there's a lowercase mistake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96518
Bug ID: 96518
Summary: g++ suggests a weird function when there's a lowercase
mistake
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: albert.astals.cid at kdab dot com
Target Milestone: ---
With the code
class Foo {
public:
void SetParent(Foo *f)
{
parent = f;
}
Foo *GetParent()
{
return parent;
}
Foo *parent = nullptr;
};
int main(int argc, char **argv)
{
Foo f;
Foo f2;
Foo *f3 = f.getParent();
}
g++ tells me
main.cpp: In function ‘int main(int, char**)’:
main.cpp:21:17: error: ‘class Foo’ has no member named ‘getParent’; did you
mean ‘SetParent’?
21 | Foo *f3 = f.getParent();
| ^
| SetParent
I find it weird that it recommends SetParent instead of GetParent given that
GetParent is closer lexycographically (and that one actually returns a Foo *
and the other doesn't)
[Bug libstdc++/93245] std::experimental::filesystem::path::generic_string() doesn't normalize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93245 --- Comment #2 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:88f2b72e77fea11803b761f4fb569d83266e1d9e commit r9-8793-g88f2b72e77fea11803b761f4fb569d83266e1d9e Author: Jonathan Wakely Date: Sat Mar 21 22:11:44 2020 + libstdc++: Fix experimental::path::generic_string (PR 93245) This function was unimplemented, simply returning the native format string instead. PR libstdc++/93245 * include/experimental/bits/fs_path.h (path::generic_string()): Return the generic format path, not the native one. * testsuite/experimental/filesystem/path/generic/generic_string.cc: Improve test coverage. (cherry picked from commit a577c0c26931090e7c25e56ef5ffc807627961ec)
[Bug libstdc++/94242] filesystem::path::generic_string() only works with std::allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94242 --- Comment #2 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e7406c364496dae51ef294b5720923fe4a1dfccb commit r9-8792-ge7406c364496dae51ef294b5720923fe4a1dfccb Author: Jonathan Wakely Date: Sat Mar 21 21:51:07 2020 + libstdc++: Fix path::generic_string allocator handling (PR 94242) It's not possible to construct a path::string_type from an allocator of a different type. Create the correct specialization of basic_string, and adjust path::_S_str_convert to use a basic_string_view so that it is independent of the allocator type. PR libstdc++/94242 * include/bits/fs_path.h (path::_S_str_convert): Replace first parameter with basic_string_view so that strings with different allocators can be accepted. (path::generic_string()): Use basic_string object that uses the right allocator type. * testsuite/27_io/filesystem/path/generic/94242.cc: New test. * testsuite/27_io/filesystem/path/generic/generic_string.cc: Improve test coverage. (cherry picked from commit 9fc985118d9f5014afc1caf32a411ee5803fba61)
[Bug libstdc++/94498] std::basic_string_view::copy not qualified constexpr in c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94498 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|9.4 |10.0 --- Comment #2 from Jonathan Wakely --- I was going to backport this to gcc-9 but it requires std::copy to be constexpr, and I do not plan to backport that. So fixed for gcc-10.
[Bug tree-optimization/96514] [9/10 Regression] ICE: verify_flow_info failed (error: control flow in the middle of basic block 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96514 Richard Biener changed: What|Removed |Added Known to work||11.0 Summary|[9/10/11 Regression] ICE: |[9/10 Regression] ICE: |verify_flow_info failed |verify_flow_info failed |(error: control flow in the |(error: control flow in the |middle of basic block 3)|middle of basic block 3) --- Comment #3 from Richard Biener --- Fixed on trunk sofar. The possible missed-optimization prevails.
[Bug tree-optimization/96514] [9/10/11 Regression] ICE: verify_flow_info failed (error: control flow in the middle of basic block 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96514 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:c3f94f5786a014515c09c7852db228c74adf51e5 commit r11-2607-gc3f94f5786a014515c09c7852db228c74adf51e5 Author: Richard Biener Date: Fri Aug 7 10:16:05 2020 +0200 tree-optimization/96514 - avoid if-converting control-altering calls This avoids if-converting when encountering control-altering calls. 2020-08-07 Richard Biener PR tree-optimization/96514 * tree-if-conv.c (if_convertible_bb_p): If the last stmt is a call that is control-altering, fail. * gcc.dg/pr96514.c: New testcase.
