[Bug c++/108195] [13 Regression] Incorrect implicit conversion when assigning initializer_list to std::vector since r13-4564-gd081807d8d70e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108195 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 --- Comment #7 from Richard Biener --- (In reply to Jakub Jelinek from comment #6) > And COMPLEX_CST shouldn't probably appear because cplxlower1 runs before > dom2 and > VECTOR_CST because GIMPLE_CONDs need scalar conditions, not vector. > So maybe it is indeed enough to just punt on DECIMAL_FLOAT_TYPE_Ps. We do allow equality compares of whole vectors, so vectors still can appear.
[Bug modula2/108142] Many empty directories created in the build directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108142 --- Comment #3 from Gaius Mulley --- Thanks for the bug report - here is a proposed fix. I've moved all m2 related directories into gcc/m2 and directories are now created as required. Bootstrapped on GNU/Linux x86_64, due to the asynchronous nature of the builds I'll test on a variety of machines before posting patches to the mailing list. Anyway the work in progress patch follows as an attachment.
[Bug modula2/108142] Many empty directories created in the build directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108142 --- Comment #2 from Gaius Mulley --- Created attachment 54145 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54145=edit m2 remove empty directories from top build
[Bug tree-optimization/101854] [11 Regression] Invalid warning -Wstringop-overflow wrong argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101854
--- Comment #11 from nightstrike ---
(In reply to Martin Sebor from comment #9)
> Fixed for GCC 12. The patch is far too intrusive to backport but the
> following should fix the problem in GCC 11:
Would you mind applying it to 11? Thanks!
Also, I think in your diff below, there's "// A nonnull" that should be "/* A
nonnull"... / to *
> diff --git a/gcc/calls.c b/gcc/calls.c
> index fcb0d6dec69..f116923c890 100644
> --- a/gcc/calls.c
> +++ b/gcc/calls.c
> @@ -2295,14 +2295,15 @@ initialize_argument_information (int num_actuals
> ATTRIBUTE_UNUSED,
> operand for later processing. */
>if (attr_access *access = rdwr_idx.get (argpos))
> {
> + int idx = i - !!struct_value_addr_value;
> if (POINTER_TYPE_P (type))
> {
> - access->ptr = args[i].tree_value;
> + access->ptr = args[idx].tree_value;
> // A nonnull ACCESS->SIZE contains VLA bounds. */
> }
> else
> {
> - access->size = args[i].tree_value;
> + access->size = args[idx].tree_value;
> gcc_assert (access->ptr == NULL_TREE);
> }
> }
[Bug bootstrap/108186] Bootstrap comparison failure.gcc-12.2.0 differs gcc/plugin.o gcc/gcc.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108186 --- Comment #10 from AlexK --- (In reply to Richard Biener from comment #1) > can you try configuring with --without-build-config please? now there are 2 problems in libgo links 1) no ../libbacktrace/libbacktrace.la I had to change it to ../../libbacktrace/libbacktrace.la alexei@Aspire:gcc-12.2.0/build $ sed -i 's|\(../libbacktrace/libbacktrace.la\)|../\1|g' x86_64-pc-linux-gnu/libgo/Makefile 2) absent ../libatomic/libatomic_convenience.la and I have not found it there is build/x86_64-pc-linux-gnu/libffi/libffi_convenience.la but build/x86_64-pc-linux-gnu/labatomic directory is absent /bin/bash ./libtool --tag=CC --mode=link /mnt/Git/apt-build/build/gcc-12.2.0/build/./gcc/xgcc -B/mnt/Git/apt-build/build/gcc-12.2.0/build/./gcc/ -B/tools/gcc-12.2.0/x86_64-pc-linux-gnu/bin/ -B/tools/gcc-12.2.0/x86_64-pc-linux-gnu/lib/ -isystem /tools/gcc-12.2.0/x86_64-pc-linux-gnu/include -isystem /tools/gcc-12.2.0/x86_64-pc-linux-gnu/sys-include -fchecking=1 -fexceptions -fnon-call-exceptions -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -minline-all-stringops -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../libgo/../libgcc -I ../../../libgo/../libbacktrace -I ../../gcc/include -g -O2 -version-info 21:0:0 -pthread -L../libatomic/.libs-o libgo.la -rpath /tools/gcc-12.2.0/lib/../lib runtime/aeshash.lo runtime/go-assert.lo runtime/go-caller.lo runtime/go-callers.lo runtime/go-cgo.lo runtime/go-construct-map.lo runtime/go-ffi.lo runtime/go-fieldtrack.lo runtime/go-matherr.lo runtime/go-memclr.lo runtime/go-memmove.lo runtime/go-memequal.lo runtime/go-nanotime.lo runtime/go-now.lo runtime/go-nosys.lo runtime/go-reflect-call.lo runtime/go-setenv.lo runtime/go-signal.lo runtime/go-unsafe-pointer.lo runtime/go-unsetenv.lo runtime/go-unwind.lo runtime/go-varargs.lo runtime/env_posix.lo runtime/panic.lo runtime/print.lo runtime/proc.lo runtime/runtime_c.lo runtime/stack.lo runtime/yield.lo runtime/go-context.lo archive/tar.lo archive/zip.lo bufio.lo bytes.lo compress/bzip2.lo compress/flate.lo compress/gzip.lo compress/lzw.lo compress/zlib.lo container/heap.lo container/list.lo container/ring.lo context.lo crypto.lo crypto/aes.lo crypto/cipher.lo crypto/des.lo crypto/dsa.lo crypto/ecdsa.lo crypto/ed25519.lo crypto/ed25519/internal/edwards25519.lo crypto/ed25519/internal/edwards25519/field.lo crypto/elliptic.lo crypto/elliptic/internal/fiat.lo crypto/elliptic/internal/nistec.lo crypto/hmac.lo crypto/internal/randutil.lo crypto/internal/subtle.lo crypto/md5.lo crypto/rand.lo crypto/rc4.lo crypto/rsa.lo crypto/sha1.lo crypto/sha256.lo crypto/sha512.lo crypto/subtle.lo crypto/tls.lo crypto/x509.lo crypto/x509/pkix.lo database/sql.lo database/sql/driver.lo debug/buildinfo.lo debug/dwarf.lo debug/elf.lo debug/gosym.lo debug/macho.lo debug/pe.lo debug/plan9obj.lo embed.lo encoding.lo encoding/ascii85.lo encoding/asn1.lo encoding/base32.lo encoding/base64.lo encoding/binary.lo encoding/csv.lo encoding/gob.lo encoding/hex.lo encoding/json.lo encoding/pem.lo encoding/xml.lo errors.lo expvar.lo flag.lo fmt.lo go/ast.lo go/build.lo go/build/constraint.lo go/constant.lo go/doc.lo go/format.lo go/importer.lo go/internal/gccgoimporter.lo go/internal/gcimporter.lo go/internal/srcimporter.lo go/internal/typeparams.lo go/parser.lo go/printer.lo go/scanner.lo go/token.lo go/types.lo golang.org/x/crypto/chacha20.lo golang.org/x/crypto/chacha20poly1305.lo golang.org/x/crypto/cryptobyte.lo golang.org/x/crypto/cryptobyte/asn1.lo golang.org/x/crypto/curve25519.lo golang.org/x/crypto/curve25519/internal/field.lo golang.org/x/crypto/hkdf.lo golang.org/x/crypto/internal/poly1305.lo golang.org/x/crypto/internal/subtle.lo golang.org/x/crypto/poly1305.lo golang.org/x/net/dns/dnsmessage.lo golang.org/x/net/http/httpguts.lo golang.org/x/net/http/httpproxy.lo golang.org/x/net/http2/hpack.lo golang.org/x/net/idna.lo golang.org/x/net/nettest.lo golang.org/x/sys/cpu.lo golang.org/x/text/secure/bidirule.lo golang.org/x/text/transform.lo golang.org/x/text/unicode/bidi.lo golang.org/x/text/unicode/norm.lo hash.lo hash/adler32.lo hash/crc32.lo hash/crc64.lo hash/fnv.lo hash/maphash.lo html.lo html/template.lo image.lo image/color.lo image/color/palette.lo image/draw.lo image/gif.lo image/internal/imageutil.lo image/jpeg.lo image/png.lo index/suffixarray.lo internal/abi.lo internal/buildcfg.lo internal/bytealg.lo internal/cfg.lo internal/cpu.lo internal/execabs.lo internal/fmtsort.lo internal/fuzz.lo internal/goarch.lo internal/godebug.lo internal/goexperiment.lo internal/goos.lo internal/goroot.lo internal/goversion.lo internal/intern.lo internal/itoa.lo internal/lazyregexp.lo internal/lazytemplate.lo internal/nettrace.lo internal/obscuretestdata.lo internal/oserror.lo internal/poll.lo internal/profile.lo internal/race.lo internal/reflectlite.lo internal/singleflight.lo internal/syscall/execenv.lo internal/syscall/unix.lo internal/sysinfo.lo internal/testenv.lo
[Bug testsuite/108192] g++.dg/cet-notrack-1.C searching for wrong function on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192 --- Comment #2 from nightstrike --- (In reply to H.J. Lu from comment #1) > Since Windows doesn't support IBT, this test can be limited to Linux. I don't know what IBT is, but if I change the two printf's to puts(), the tests pass. So, maybe they don't have to be skipped?
[Bug bootstrap/108186] Bootstrap comparison failure.gcc-12.2.0 differs gcc/plugin.o gcc/gcc.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108186 --- Comment #9 from AlexK --- (In reply to Richard Biener from comment #1) > can you try configuring with --without-build-config please? that was my influence - I have compiled binutils with shared intl continue ...
[Bug bootstrap/108186] Bootstrap comparison failure.gcc-12.2.0 differs gcc/plugin.o gcc/gcc.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108186 --- Comment #8 from AlexK --- (In reply to Richard Biener from comment #1) > can you try configuring with --without-build-config please? make[2]: вход в каталог «/mnt/Git/apt-build/build/gcc-12.2.0/build/c++tools» /mnt/Git/apt-build/build/gcc-12.2.0/build/./gcc/xg++ -B/mnt/Git/apt-build/build/gcc-12.2.0/build/./gcc/ -nostdinc++ `if test -f /mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/scripts/testsuite_flags; then /bin/bash /mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/scripts/testsuite_flags --build-includes; else echo -funconfigured-libstdc++-v3 ; fi` -L/mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/tools/gcc-12.2.0/x86_64-pc-linux-gnu/bin/ -B/tools/gcc-12.2.0/x86_64-pc-linux-gnu/lib/ -isystem /tools/gcc-12.2.0/x86_64-pc-linux-gnu/include -isystem /tools/gcc-12.2.0/x86_64-pc-linux-gnu/sys-include -fchecking=1 -static-libstdc++ -static-libgcc -o g++-mapper-server server.o resolver.o ../libcody/libcody.a ../libiberty/libiberty.a /usr/local/bin/ld: /mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(functexcept.o): в функции «std::__throw_logic_error(char const*)»: /mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11/../../../../../libstdc++-v3/src/c++11/functexcept.cc:70: неопределённая ссылка на «libintl_gettext» /usr/local/bin/ld: /mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(functexcept.o): в функции «std::__throw_domain_error(char const*)»: /mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11/../../../../../libstdc++-v3/src/c++11/functexcept.cc:74: неопределённая ссылка на «libintl_gettext» /usr/local/bin/ld: /mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(functexcept.o): в функции «std::__throw_invalid_argument(char const*)»: /mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11/../../../../../libstdc++-v3/src/c++11/functexcept.cc:78: неопределённая ссылка на «libintl_gettext» /usr/local/bin/ld: /mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(functexcept.o): в функции «std::__throw_length_error(char const*)»: /mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11/../../../../../libstdc++-v3/src/c++11/functexcept.cc:82: неопределённая ссылка на «libintl_gettext» /usr/local/bin/ld: /mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(functexcept.o): в функции «std::__throw_out_of_range(char const*)»: /mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11/../../../../../libstdc++-v3/src/c++11/functexcept.cc:86: неопределённая ссылка на «libintl_gettext» /usr/local/bin/ld: /mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(functexcept.o):/mnt/Git/apt-build/build/gcc-12.2.0/build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++11/../../../../../libstdc++-v3/src/c++11/functexcept.cc:100: далее есть ещё неопределённые ссылки на «libintl_gettext» collect2: error: ld returned 1 exit status make[2]: *** [Makefile:95: g++-mapper-server] Ошибка 1 make[2]: выход из каталога «/mnt/Git/apt-build/build/gcc-12.2.0/build/c++tools» make[1]: *** [Makefile:14754: all-c++tools] Ошибка 2 make[1]: выход из каталога «/mnt/Git/apt-build/build/gcc-12.2.0/build» make: *** [Makefile:1074: all] Ошибка 2
[Bug bootstrap/108186] Bootstrap comparison failure.gcc-12.2.0 differs gcc/plugin.o gcc/gcc.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108186 --- Comment #7 from AlexK --- (In reply to Richard Biener from comment #1) > can you try configuring with --without-build-config please? I changed gcc/Makefile by sed -i 's/^ZSTD_LIB[ ]*=.*$/ZSTD_LIB = -lzstd/' gcc/Makefile and continued now I have undefined libintl in c++tools directory ./libstdc++-v3/src/c++11/functexcept.cc:70: неопределённая ссылка на «libintl_gettext» ..
[Bug c++/108047] [13 Regression] ICE: unexpected expression of kind implicit_conv_expr since r13-4564-gd081807d8d70e3e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047
--- Comment #6 from Sergei Trofimovich ---
Encountered very similar ICE, this time on toml library on this week's gcc-13
master. Reduced it down to the following:
// $ cat bug.cc
#include
#include
void format_underline(std::vector);
template
void parse_key_value_pair(void) { format_underline({""}); }
$ g++ -c bug.cc
...
bug.cc: In function 'void parse_key_value_pair()':
bug.cc:7:51: internal compiler error: unexpected expression
'(std::__cxx11::basic_string)""' of kind implicit_conv_expr
7 | void parse_key_value_pair(void) { format_underline({""}); }
| ^~
0x1cbb294 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x1cbbee6 internal_error(char const*, ...)
???:0
0x79c770 cxx_eval_constant_expression(constexpr_ctx const*, tree_node*,
value_cat, bool*, bool*, tree_node**)
???:0
0x7a1572 cxx_eval_outermost_constant_expr(tree_node*, bool, bool, bool, bool,
tree_node*)
???:0
0x7a52e6 maybe_constant_init_1(tree_node*, tree_node*, bool, bool)
???:0
0x77a767 build_user_type_conversion_1(tree_node*, tree_node*, int, int)
???:0
[Bug testsuite/101528] [11 regression] gcc.target/powerpc/int_128bit-runnable.c fails after r11-8743
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101528 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-21 --- Comment #5 from Marek Polacek --- Confirmed.
[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 --- Comment #43 from qinzhao at gcc dot gnu.org --- the related patch list for this work is (gcc13) 2a27ae32fabf85685758459d7ec284ccb95a 710c9676520dfd38b4bfdcc937ce026ed89921d6 ace0ae09332bbc6b95e084c2c2b17c466339ff76 b9ad850e86b863c24f6f4f5acf08d49944cc7bbe 1879e48f3d8595bc9e7f583bbd12df3c6f5c42dc
[Bug driver/108196] Incorrect binary search in find_opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108196 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from H.J. Lu --- It is a different issue.
[Bug driver/108196] Incorrect binary search in find_opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108196 --- Comment #1 from Andrew Pinski --- Can you give an example because this code has been there since r0-51440-gcf03fd63cd7fd8 (since at least 3.4.0). And exact match has been happening for a long time now.
[Bug driver/108196] New: Incorrect binary search in find_opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108196
Bug ID: 108196
Summary: Incorrect binary search in find_opt
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
opts-common.cc has
/* Find mn such this lexicographical inequality holds:
cl_options[mn] <= input < cl_options[mn + 1]. */
while (mx - mn > 1)
{
md = (mn + mx) / 2;
opt_len = cl_options[md].opt_len;
comp = strncmp (input, cl_options[md].opt_text + 1, opt_len);
if (comp < 0)
mx = md;
else
mn = md;
}
When md is the exact match, the search doesn't terminate and we may get the
wrong result.
[Bug tree-optimization/105532] [11/12 Regression] UBSAN: gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105532 Andrew Pinski changed: What|Removed |Added Summary|[11/12/13 Regression] |[11/12 Regression] UBSAN: |UBSAN: gcc/hwint.h:293:61: |gcc/hwint.h:293:61: runtime |runtime error: shift|error: shift exponent 64 is |exponent 64 is too large|too large for 64-bit type |for 64-bit type 'long |'long unsigned int' |unsigned int' | Known to fail|13.0| Known to work||13.0 --- Comment #9 from Andrew Pinski --- Fixed at least for GCC 13 (trunk). Still open for backporting.
[Bug tree-optimization/105532] [11/12/13 Regression] UBSAN: gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105532 --- Comment #8 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:193fccaa5c3525e979a989835c47c76d2c49d10c commit r13-4834-g193fccaa5c3525e979a989835c47c76d2c49d10c Author: Andrew Pinski Date: Wed Nov 2 15:56:31 2022 + Fix PR 105532: match.pd patterns calling tree_nonzero_bits with vector types Even though this PR was reported with an ubsan issue, the problem is tree_nonzero_bits is being called with an expression which is a vector type. This fixes three patterns I noticed which does that. And adds a testcase for one of the patterns. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions gcc/ChangeLog: PR tree-optimization/105532 * match.pd (~(X >> Y) -> ~X >> Y): Check if it is an integral type before calling tree_nonzero_bits. (popcount(X) + popcount(Y)): Likewise. (popcount(X)): Likewise. gcc/testsuite/ChangeLog: * gcc.c-torture/compile/vector-shift-1.c: New test.
[Bug c++/108099] [12/13 Regression] ICE with type alias with `signed __int128_t`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
--- Comment #11 from Ville Voutilainen ---
More cases that ICE:
template using AT = int;
using AA = AT;
template struct AT{};
using AA = AT;
template struct AT{};
AT x;
[Bug testsuite/108192] g++.dg/cet-notrack-1.C searching for wrong function on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192 --- Comment #1 from H.J. Lu --- Since Windows doesn't support IBT, this test can be limited to Linux.
[Bug tree-optimization/108187] False positive -Wfree-nonheap-object on impossible path with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108187 --- Comment #4 from Andrew Pinski --- (In reply to Ilya Maximets from comment #3) > > Clarification: I realized that dp_packet_use_afxdp() is part of a different > translation unit, so GCC doesn't have a chance to know what this function is > doing, hence it doesn't know that source is DPBUF_AFXDP. Though I don't know > how we can change that code to make GCC happy. We'll likely end up just > disabling a warning. > > > However, I'm not sure why the issue doesn't appear with -O0 then. > > I'm still not sure why this is happening though. Is there something > special about -O0 ? Yes the warning code only runs with optimization turned on ...
[Bug sanitizer/108106] [13 Regression] /usr/bin/ld: .libs/hwasan_setjmp_x86_64.o: relocation R_X86_64_PC32 against symbol `__interceptor_sigsetjmp' can not be used when making a shared object; recompi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108106 --- Comment #10 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608672.html
[Bug c++/108195] [13 Regression] Incorrect implicit conversion when assigning initializer_list to std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108195 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Interesting the code works correctly for C++20 mode ... Actually I made S's constructor constexpr and it made it work and not because of C++20 mode.
[Bug c++/108195] [13 Regression] Incorrect implicit conversion when assigning initializer_list to std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108195 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105838 --- Comment #2 from Andrew Pinski --- Interesting the code works correctly for C++20 mode ...
[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 --- Comment #6 from Jakub Jelinek --- And COMPLEX_CST shouldn't probably appear because cplxlower1 runs before dom2 and VECTOR_CST because GIMPLE_CONDs need scalar conditions, not vector. So maybe it is indeed enough to just punt on DECIMAL_FLOAT_TYPE_Ps.
[Bug c++/108195] [13 Regression] Incorrect implicit conversion when assigning initializer_list to std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108195 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|Incorrect implicit |[13 Regression] Incorrect |conversion when assigning |implicit conversion when |initializer_list to |assigning initializer_list |std::vector |to std::vector Ever confirmed|0 |1 Keywords||diagnostic, wrong-code Target Milestone|--- |13.0 Last reconfirmed||2022-12-21 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c/108194] GCC won't treat two compatible function types as compatible if any of them (or both of them) is declared _Noreturn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108194 Petr Skocik changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #5 from Petr Skocik --- (In reply to Andrew Pinski from comment #4) > Invalid as mentioned in r13-3135-gfa258f6894801a . I believe it's still a bug for pre-c2x __typeof. While it is GCC's prerogative to include _Noreturn/__attribute((noreturn)) into the type for its own __typeof (which, BTW, I think is better design than the standardized semantics), I think two otherwise compatible function types should still remain compatible if they both either have or don't have _Noreturn/__attribute((noreturn)). But treating `_Noreturn void NR_FN_A(void);` as INcompatible with `_Noreturn void NR_FN_B(void);` that's just wonky, IMO.
[Bug c++/108195] New: Incorrect implicit conversion when assigning initializer_list to std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108195
Bug ID: 108195
Summary: Incorrect implicit conversion when assigning
initializer_list to std::vector
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at al42and dot me
Target Milestone: ---
The following code compiles fine with Clang 15 and GCC 12 and outputs "3" when
run.
With GCC 13, it produces a warning about narrowing conversion and constructs a
vector of length 2.
$ cat test.cpp
#include
#include
struct S
{
S(bool) {}
};
int main()
{
std::vector v = { true, false, true };
std::cout << v.size() << std::endl;
}
$ g++ -std=c++17 test.cpp -o test
test.cpp: In function ‘int main()’:
test.cpp:11:44: warning: narrowing conversion of ‘(((void)const bool [3]{true,
false, true}), ((const bool*)(&)))’ from ‘const bool*’ to ‘bool’
[-Wnarrowing]
11 | std::vector v = { true, false, true };
|^
test.cpp:11:44: warning: narrowing conversion of ‘(((const
bool*)(&)) + 3)’ from ‘const bool*’ to ‘bool’ [-Wnarrowing]
$ ./test
2
Using a constructor instead of the assignment avoids this problem:
std::vector v { true, false, true }; // works fine
Creating an initializer_list separately is also ok:
std::initializer_list il = { true, false, true };
std::vector v = il; // no problem here, vector has three elements
Tested with GCC fdc7469cf597ec11229ddfc3e9c7a06f3d0fba9d. Bisection points to
d081807d8d70e3e87eae41e1560e54d503f4d465 (PR105838).
[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 --- Comment #5 from joseph at codesourcery dot com --- For DFP it's not just zero for which you can't infer an equivalence of values from an equality comparison; any finite value that can be represented with more than one quantum exponent (any value that can be represented with less precision than the type, unless it can only be represented with the largest or smallest possible quantum exponent) has the same property. So handling DFP zero here probably isn't enough to avoid bugs.
[Bug c/108194] GCC won't treat two compatible function types as compatible if any of them (or both of them) is declared _Noreturn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108194 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- Invalid as mentioned in r13-3135-gfa258f6894801a .
[Bug c/108194] GCC won't treat two compatible function types as compatible if any of them (or both of them) is declared _Noreturn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108194 --- Comment #3 from joseph at codesourcery dot com --- If you use typeof instead of __typeof, and -std=c2x, these types are treated as compatible. I deliberately kept the existing semantics for __typeof, and for typeof in pre-C2x modes, when implementing C2x typeof; see the commit message for commit fa258f6894801aef6785f0327594dc803da63fbd.
[Bug c++/107853] [10/11/12/13 Regression] variadic template with a variadic template friend with a requires of fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107853 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/108067] Miscompilation with friend function with parameter pack: mismatched argument pack lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108067 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #3 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 107853 ***
[Bug c++/107853] [10/11/12/13 Regression] variadic template with a variadic template friend with a requires of fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107853 Patrick Palka changed: What|Removed |Added CC||danakj at orodu dot net --- Comment #3 from Patrick Palka --- *** Bug 108066 has been marked as a duplicate of this bug. ***
[Bug c++/107853] [10/11/12/13 Regression] variadic template with a variadic template friend with a requires of fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107853 --- Comment #4 from Patrick Palka --- *** Bug 108067 has been marked as a duplicate of this bug. ***
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 108066, which changed state. Bug 108066 Summary: [10/11/12/13 Regression] ICE in use_pack_expansion_extra_args_p, at cp/pt.cc:12661 since r12-1094-gdb79713150f4f8b6 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108066 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE
[Bug c++/108066] [10/11/12/13 Regression] ICE in use_pack_expansion_extra_args_p, at cp/pt.cc:12661 since r12-1094-gdb79713150f4f8b6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108066 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 107853 ***
[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 54144 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54144=edit gcc13-pr108068.patch Untested fix.
[Bug c++/108179] [11/12/13 regression] ICE related to template template parameters in tsubst, at cp/pt.cc:15782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108179 Patrick Palka changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104107 Keywords|needs-bisection | --- Comment #2 from Patrick Palka --- Started with r12-7236-g2c3309e3d0f5cb
[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183 --- Comment #13 from Iain Sandoe --- oops - pasto on the power results: === gm2 Summary for unix/-m64 === # of expected passes11809 # of unexpected failures59 === gm2 Summary === # of expected passes23626 # of unexpected failures110 Compiler version: gcc gm2 Platform: powerpc-apple-darwin9
[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183 --- Comment #12 from Iain Sandoe --- With the change above (and adding an assert that the function is not defined/implemented) -- NOTE: plus a number of other hacks to workaround other PRs in progress ... we now have something more reasonable for m32 darwin. test time is large - primarily because a significant number of the fails are timeouts. === x86-64 Darwin with a 32b multilib. === gm2 Summary for unix/-m32 === # of expected passes11820 # of unexpected failures48 === gm2 Summary for unix/-m64 === # of expected passes11818 # of unexpected failures50 === gm2 Summary === # of expected passes23638 # of unexpected failures98 Compiler version: gcc gm2 Platform: x86_64-apple-darwin17 i686-darwin with a 64b multilib. === gm2 Summary for unix/-m32 === # of expected passes11833 # of unexpected failures35 === gm2 Summary for unix/-m64 === # of expected passes12957 # of unexpected failures63 === gm2 Summary === # of expected passes24790 # of unexpected failures98 Compiler version: gcc gm2 Platform: i686-apple-darwin9 = powerpc-darwin === gm2 Summary for unix/-m32 === # of expected passes11817 # of unexpected failures51 === gm2 Summary for unix/-m32 === # of expected passes11817 # of unexpected failures51
[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- This was added for PR44683 and I bet the reason it uses real_zerop is that we don't have other APIs, or at least ones that work on floating point types for it. I suppose short term we could use TREE_CODE (op0) == REAL_CST && TREE_REAL_CST (op0).cl != rvc_zero but the question is what to do for COMPLEX_CSTs and VECTOR_CSTs. I bet for COMPLEX_CSTs, we shouldn't infer anything if signed zeros are allowed and either real or imag or both parts are zero, for VECTOR_CSTs similarly if any elt is zero. For SSA_NAMEs eventually we could ask frange...
[Bug modula2/108142] Many empty directories created in the build directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108142 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |13.0 Last reconfirmed||2022-12-21 Ever confirmed|0 |1 CC||ebotcazou at gcc dot gnu.org --- Comment #1 from Eric Botcazou --- Seconded.
[Bug c/108079] [10/11/12/13 Regression] -Wunused-variable gives misleading duplicate warning for unused static local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108079 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 54143 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54143=edit gcc13-pr108079.patch Untested fix.
[Bug c/108079] [10/11/12/13 Regression] -Wunused-variable gives misleading duplicate warning for unused static local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108079 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Seems to have started with r6-1401-gd7438551ff5ffa0afeca2aa3efd13035b26bee34 One of the warnings is diagnosed by the FE (from pop_scope/poplevel), the other by cgraphunit (check_global_declaration).
[Bug target/99555] [OpenMP/nvptx] Execution-time hang for simple nested OpenMP 'target'/'parallel'/'task' constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555 --- Comment #18 from CVS Commits --- The master branch has been updated by Chung-Lin Tang : https://gcc.gnu.org/g:fdc7469cf597ec11229ddfc3e9c7a06f3d0fba9d commit r13-4832-gfdc7469cf597ec11229ddfc3e9c7a06f3d0fba9d Author: Chung-Lin Tang Date: Wed Dec 21 05:57:45 2022 -0800 nvptx: reimplement libgomp barriers [PR99555] Instead of trying to have the GPU do CPU-with-OS-like things, this new barriers implementation for NVPTX uses simplistic bar.* synchronization instructions. Tasks are processed after threads have joined, and only if team->task_count != 0 It is noted that: there might be a little bit of performance forfeited for cases where earlier arriving threads could've been used to process tasks ahead of other threads, but that has the requirement of implementing complex futex-wait/wake like behavior, which is what we're try to avoid with this patch. It is deemed that task processing is not what GPU target offloading is usually used for. Implementation highlight notes: 1. gomp_team_barrier_wake() is now an empty function (threads never "wake" in the usual manner) 2. gomp_team_barrier_cancel() now uses the "exit" PTX instruction. 3. gomp_barrier_wait_last() now is implemented using "bar.arrive" 4. gomp_team_barrier_wait_end()/gomp_team_barrier_wait_cancel_end(): The main synchronization is done using a 'bar.red' instruction. This reduces across all threads the condition (team->task_count != 0), to enable the task processing down below if any thread created a task. (this bar.red usage means that this patch is dependent on the prior NVPTX bar.red GCC patch) PR target/99555 libgomp/ChangeLog: * config/nvptx/bar.c (generation_to_barrier): Remove. (futex_wait,futex_wake,do_spin,do_wait): Remove. (GOMP_WAIT_H): Remove. (#include "../linux/bar.c"): Remove. (gomp_barrier_wait_end): New function. (gomp_barrier_wait): Likewise. (gomp_barrier_wait_last): Likewise. (gomp_team_barrier_wait_end): Likewise. (gomp_team_barrier_wait): Likewise. (gomp_team_barrier_wait_final): Likewise. (gomp_team_barrier_wait_cancel_end): Likewise. (gomp_team_barrier_wait_cancel): Likewise. (gomp_team_barrier_cancel): Likewise. * config/nvptx/bar.h (gomp_barrier_t): Remove waiters, lock fields. (gomp_barrier_init): Remove init of waiters, lock fields. (gomp_team_barrier_wake): Remove prototype, add new static inline function.
[Bug c++/107379] [13 regression] g++.dg/modules/adl-3_c.C and adl-4_b.C break as of r13-2887-gb04208895fed34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107379 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/107822] [13 Regression] Dead Code Elimination Regression at -Os (trunk vs. 12.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107822 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||aldyh at gcc dot gnu.org Known to fail||13.0 Known to work||12.2.1 Ever confirmed|0 |1 Priority|P3 |P1 Last reconfirmed||2022-12-21 --- Comment #1 from Richard Biener --- Confirmed. Same with -O2. Visiting conditional with predicate: if (c_13 != 0) With known ranges c_13: [irange] int [-INF, +INF] NONZERO 0x3 Predicate evaluates to: DON'T KNOW Not folded vs. handling the cycle PHI for c: [local count: 118111600]: b = 0; goto ; [100.00%] [local count: 955630225]: _1 = c_10 ^ 3; _2 = b.1_3 + 1; b = _2; [local count: 1073741824]: # c_10 = PHI <1(2), _1(3)> b.1_3 = b; if (b.1_3 <= 8) goto ; [89.00%] else goto ; [11.00%] [local count: 118111600]: # c_13 = PHI if (c_13 != 0) Value ranges after VRP: _1: int [1, 2] c_2: int [1, 2] this is yet another case where proper propagation is important. I'm questioning the idea that on-demand ranger is a good solution and replacing VRP1 was premature? I'm asking again as to what the plan was for cases like this? bit-CCP propagation arrives with Simulating statement: c_10 = PHI <1(2), _1(3)> Visiting PHI node: c_10 = PHI <1(2), _1(3)> Argument #0 (2 -> 4 executable) 1 Value: CONSTANT 1 Argument #1 (3 -> 4 executable) _1 Value: CONSTANT 0x0 (0x3) PHI node value: CONSTANT 0x0 (0x3) but it doesn't know that always either bit zero or one is set.
[Bug libstdc++/105730] [12/13 Regression] Issue with commit - Allow std::condition_variable waits to be cancelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105730 --- Comment #10 from Gleb Mazovetskiy --- The patch in Comment 8 fixes the issue for me!
[Bug tree-optimization/107888] [12/13 Regression] Missed min/max transformation in phiopt due to VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107888 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-21 --- Comment #3 from Richard Biener --- Confirmed at least.
[Bug tree-optimization/108166] [12/13 Regression] Wrong code with -O2 since r12-8078-ga42aa68bf1ad745a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108166 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 54142 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54142=edit gcc13-pr108166.patch Untested fix. I wouldn't change replace_phi_edge_with_variable, because even without the duplicate_ssa_name_range_info (say if new_tree already has SSA_NAME_RANGE_INFO) we'd be lying to the compiler. The right thing would be to union the global range of the phi result with the oarg INTEGER_CST, not sure how hard would that be.
[Bug c/107942] [10/11/12/13 Regression] Documentation of the volatile style for noreturn is gone and const style for const attribute is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107942 Richard Biener changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-21 --- Comment #7 from Richard Biener --- I wonder if we should remove this handling? (I think it's good the manual no longer suggests it) I suppose the standard doesn't give const or volatile qualification any semantics (or requires a diagnostic)
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||10walls at gmail dot com Last reconfirmed||2022-12-21 Priority|P3 |P1 Ever confirmed|0 |1 --- Comment #9 from Richard Biener --- Please try to work together to fix the build issue.
[Bug c/108194] GCC won't treat two compatible function types as compatible if any of them (or both of them) is declared _Noreturn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108194 --- Comment #2 from Andrew Pinski --- Note you are also using a gcc extension of __typeof so that could add it to the type.
[Bug libstdc++/105730] [12/13 Regression] Issue with commit - Allow std::condition_variable waits to be cancelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105730 --- Comment #9 from Jonathan Wakely --- (In reply to Gleb Mazovetskiy from comment #7) > Note that the 3.4.11 has a single @. > All the other symbols have @@. This is expected and entirely correct.
[Bug libstdc++/105730] [12/13 Regression] Issue with commit - Allow std::condition_variable waits to be cancelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105730
--- Comment #8 from Jonathan Wakely ---
I think this should solve the problem:
--- a/libstdc++-v3/src/c++11/compatibility-condvar.cc
+++ b/libstdc++-v3/src/c++11/compatibility-condvar.cc
@@ -67,6 +67,22 @@ _GLIBCXX_END_NAMESPACE_VERSION
&& defined(_GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT)
namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
{
+namespace
+{
+ std::__condvar std::condition_variable::* __base_member;
+
+ template
+struct cracker
+{
+ static std::__condvar std::condition_variable::* value;
+};
+ template
+std::__condvar std::condition_variable::*
+ cracker::value = __base_member = X;
+
+ template class cracker<::condition_variable::_M_cond>;
+}
+
struct __nothrow_wait_cv : std::condition_variable
{
void wait(std::unique_lock&) noexcept;
@@ -76,7 +92,7 @@ __attribute__((used))
void
__nothrow_wait_cv::wait(std::unique_lock& lock) noexcept
{
- this->condition_variable::wait(lock);
+ (this->*__base_member).wait(*lock.mutex());
}
} // namespace __gnu_cxx
[Bug middle-end/107991] [10/11/12/13 Regression] Extra mov instructions with ternary on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107991
--- Comment #5 from rsandifo at gcc dot gnu.org
---
>From a slightly old build, but it looks like we have a redundant move:
(insn 4 27 28 2 (set (reg/v:SI 85 [ i ])
(reg:SI 91)) "foo.c":9:31 83 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 91)
(nil)))
This causes problems because we can then assign different preferences
and costs to 85 and 91. 91 comes from input register SI and so prefers
SIREG while 85 feeds the result and so prefers AREG.
We should be able to cope better with this, will have a look in the new
year.
The output seems better with -fweb.
[Bug tree-optimization/108166] [12/13 Regression] Wrong code with -O2 since r12-8078-ga42aa68bf1ad745a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108166 --- Comment #6 from Richard Biener --- replace_phi_edge_with_variable assumes we replace things with the same value, if the new transform does something different because of the _uses_ of the value then it has to make sure to not copy range info in that function (add another argument to it?)
[Bug tree-optimization/108166] [12/13 Regression] Wrong code with -O2 since r12-8078-ga42aa68bf1ad745a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108166 --- Comment #5 from Richard Biener --- But we end up with [local count: 1073741824]: b.1_1 = b; if (b.1_1 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870913]: iftmp.3_14 = d; [local count: 966367640]: # RANGE [irange] int [-INF, -1][1, +INF] # iftmp.3_10 = PHI [local count: 1073741824]: # RANGE [irange] int [-INF, -1][1, +INF] # iftmp.2_9 = PHI _4 = iftmp.2_9 < 0; before CFG cleanup which does look wrong. Before the phiopt we have [local count: 966367640]: # iftmp.3_10 = PHI if (iftmp.3_10 != 0) goto ; [56.25%] else goto ; [43.75%] [local count: 536870913]: [local count: 1073741824]: # RANGE [irange] int [-INF, -1][1, +INF] # iftmp.2_9 = PHI _4 = iftmp.2_9 < 0; but clearly value-replacing the edge 5->6 with iftmp.3_10 is wrong (its zero, not 8 on that edge)?
[Bug c/108194] GCC won't treat two compatible function types as compatible if any of them (or both of them) is declared _Noreturn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108194 Richard Biener changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #1 from Richard Biener --- GCCs own __attribute__((noreturn)) goes into the type to make indirect calls annotatable.
[Bug tree-optimization/108166] [12/13 Regression] Wrong code with -O2 since r12-8078-ga42aa68bf1ad745a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108166 --- Comment #4 from Jakub Jelinek --- The phiopt2 optimization is: # iftmp.3_10 = PHI - if (iftmp.3_10 != 0) -goto ; [56.25%] - else -goto ; [43.75%] - - [local count: 536870913]: - - [local count: 1073741824]: - # iftmp.2_9 = PHI - _4 = iftmp.2_9 < 0; + _4 = iftmp.3_10 < 0; So, we have _4 = (iftmp.3_10 ?: 8) < 0 and the optimization optimizes that to _4 = iftmp.3_10 < 0. If iftmp.3_10 is non-zero, then it is the same comparison, if iftmp.3_10 is zero, then previously we'd set _4 to 8 < 0 and newly set it to 0 < 0, both are false. The problem is in global ranges I think, previously we had: # RANGE [irange] int [-INF, -1][1, +INF] # iftmp.2_9 = PHI which is correct, it was iftmp.3_10 ?: 8 which is always non-zero. But this rnage is moved to iftmp.3_10 after the optimization: # RANGE [irange] int [-INF, -1][1, +INF] # iftmp.3_10 = PHI which is incorrect, we don't know anything about iftmp.3_10 range there because d is VARYING.
[Bug c++/108179] [11/12/13 regression] ICE related to template template parameters in tsubst, at cp/pt.cc:15782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108179 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/108137] [12/13 Regression] ICE: segfault during GIMPLE pass: warn-printf since r12-523-g2254b3233b5bfa69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108137 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/108120] [10/11/12/13 Regression] ICE: in extract_insn, at recog.cc:2791 (on ARM with -mfpu=neon -freciprocal-math -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/108116] [12/13 Regression] ICE in check_noexcept_r, at cp/except.cc:1074 since r12-6897-gdec8d0e5fa00ceb2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108116 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug sanitizer/108106] [13 Regression] /usr/bin/ld: .libs/hwasan_setjmp_x86_64.o: relocation R_X86_64_PC32 against symbol `__interceptor_sigsetjmp' can not be used when making a shared object; recompi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108106 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/108099] [12/13 Regression] ICE with type alias with `signed __int128_t`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug libstdc++/105730] [12/13 Regression] Issue with commit - Allow std::condition_variable waits to be cancelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105730 --- Comment #7 from Gleb Mazovetskiy --- $ output/gcw0/host/bin/mipsel-gcw0-linux-uclibc-gcc-nm -gD output/gcw0/target/lib/libstdc++.so | grep condition_variable | grep wait 00084ecc T _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@GLIBCXX_3.4.11 000b2804 T _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@@GLIBCXX_3.4.30 Note that the 3.4.11 has a single @. All the other symbols have @@.
[Bug c/107994] [12/13 Regression] ICE in fold_convert_loc, at fold-const.cc:2606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107994 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:845b514e8a150447ba041294586af76a6ac05158 commit r13-4828-g845b514e8a150447ba041294586af76a6ac05158 Author: Richard Biener Date: Wed Dec 21 12:27:58 2022 +0100 middle-end/107994 - ICE after error with comparison gimplification The following avoids passing down error_mark_node to fold_convert. PR middle-end/107994 * gimplify.cc (gimplify_expr): Catch errorneous comparison operand.
[Bug tree-optimization/108068] [10/11/12/13 Regression] decimal floating point signed zero is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108068 Richard Biener changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Priority|P3 |P2 --- Comment #2 from Richard Biener --- Optimizing statement if (_5 != 0) Visiting conditional with predicate: if (_5 != 0) With known ranges _5: [unsupported_range] UNDEFINED Predicate evaluates to: DON'T KNOW LKUP STMT _5 ne_expr 0 0>>> COPY _5 = 0 COPY _5 = 0 the issue is we do bool can_infer_simple_equiv = !(HONOR_SIGNED_ZEROS (op1) && (TREE_CODE (op1) == SSA_NAME || real_zerop (op1))); but real_zerop is false for Decimal zero. That's because "Trailing zeroes matter for decimal float constants, so don't return 1 for them.". We'd need a real_maybe_zerop () for this usage. We have other !real_zerop checks in match.pd and elsewhere, those are susceptible as well. Joseph, do you think adding DECIMAL_FLOAT_MODE_P checks in users is what we want to do or do you think a real_nonzerop would be more appropriate here? I guess DOM want's to ask whether op1 may compare equal to zero.
[Bug libstdc++/105730] [12/13 Regression] Issue with commit - Allow std::condition_variable waits to be cancelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105730 --- Comment #6 from Jonathan Wakely --- It seems like a problem with symbol resolution either during linking, or when loading the dynamic library. The old _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@GLIBCXX_3.4.11 symbol is an alias for __gnu_cxx::__nothrow_wait_cv::wait which calls the new std::condition_variable::wait(unique_lock&)@@GLIBCXX_3.4.30 symbol. But here it's calling itself recursively, leading to a stack overflow segfault. The call from __gnu_cxx::__nothrow_wait_cv::wait *should* bind to the new symbol with version @@GLIBCXX_3.4.30 instead of the old one which is an alias to itself.
[Bug rtl-optimization/108193] [13 Regression] ICE in do_SUBST, at combine.cc:700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108193 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-12-21 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 54141 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54141=edit gcc13-pr108193.patch Untested fix. The last hunk in cse.cc is enough, the rest is just to avoid triggering UB during compilation on aarch64 with certain constants.
[Bug libstdc++/108188] Segfault in compatibility-condvar.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108188 --- Comment #3 from Gleb Mazovetskiy --- I am simply using buildroot to build everything, including gdb. binutils v2.38 ld.
[Bug c++/108066] [10/11/12/13 Regression] ICE in use_pack_expansion_extra_args_p, at cp/pt.cc:12661 since r12-1094-gdb79713150f4f8b6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108066 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Known to fail||10.4.1, 11.3.1, 12.2.1, ||13.0 Target Milestone|13.0|10.5 Known to work||10.4.0, 11.3.0, 12.2.0 Summary|[13 Regression] ICE in |[10/11/12/13 Regression] |use_pack_expansion_extra_ar |ICE in |gs_p, at cp/pt.cc:12661 |use_pack_expansion_extra_ar |since |gs_p, at cp/pt.cc:12661 |r12-1094-gdb79713150f4f8b6 |since ||r12-1094-gdb79713150f4f8b6
[Bug libstdc++/108188] Segfault in compatibility-condvar.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108188 --- Comment #2 from Jonathan Wakely --- Are you using lld to link or binutils' ld?
[Bug c/108060] [10/11/12/13 Regression] UBsan missed an out-of-bound bug at -O0 since r7-1900-g8a1b7b7fd75a3847
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108060
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Component|sanitizer |c
--- Comment #2 from Richard Biener ---
The frontend emits
{
b = -32768;
a[.UBSAN_BOUNDS (0B, SAVE_EXPR <(int) b>, 7);, SAVE_EXPR <(int) b>;] =
a[(int) b] | (int) c;
}
and appearantly expects that the side-effects of the LHS are evaluated before
the side-effects of the RHS. It also doesn't look at the RHS at all,
likely the instrumentation happens before GENERICizing the |= operator.
I think this is a frontend mistake.
The C++ frontend splits turns a[b] |= c into a[b] = a[b] | c before
instrumentation.
[Bug libstdc++/105730] [12/13 Regression] Issue with commit - Allow std::condition_variable waits to be cancelled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105730 Jonathan Wakely changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Jonathan Wakely --- Bug 108188 has a reproducer
[Bug tree-optimization/108187] False positive -Wfree-nonheap-object on impossible path with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108187 --- Comment #3 from Ilya Maximets --- (In reply to Ilya Maximets from comment #2) > (In reply to Richard Biener from comment #1) > > Well, between the store to ->source and the read from it is the call > > to dp_packet_use_afxdp which gets >packet as argument and thus > > needs to be treated as clobbering ->source. So GCC can indeed not know > > that ->source is DPBUF_AFXDP since the path is not provable impossible. > > dp_packet_use_afxdp doesn't even get a const struct dp_packet * argument > > (not that this would semantically change things in C). > > Hmm, dp_packet_use_afxdp() is the function that sets source to DPBUF_AFXDP > and initializes other parts of the structure. So, it cannot take a const > argument. If GCC just doesn't look inside the dp_packet_use_afxdp() function > at all here, then it will indeed not know that the source is DPBUF_AFXDP now. Clarification: I realized that dp_packet_use_afxdp() is part of a different translation unit, so GCC doesn't have a chance to know what this function is doing, hence it doesn't know that source is DPBUF_AFXDP. Though I don't know how we can change that code to make GCC happy. We'll likely end up just disabling a warning. > However, I'm not sure why the issue doesn't appear with -O0 then. I'm still not sure why this is happening though. Is there something special about -O0 ?
[Bug c++/108047] [13 Regression] ICE: unexpected expression of kind implicit_conv_expr since r13-4564-gd081807d8d70e3e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/108036] [11/12/13 Regression] Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 Richard Biener changed: What|Removed |Added Priority|P3 |P2 --- Comment #6 from Richard Biener --- I read Martins response on the mailing list as if special-casing T[0] would be OK and that this is simply missed right now.
[Bug ipa/108007] [10/11/12/13 Regression] wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Last reconfirmed|2022-12-07 00:00:00 |2022-12-21 --- Comment #6 from Richard Biener --- Martin, can you please have a look? Summary for node main/10: Returns value No parameter information. Summary for edge main/10->k/9: return value ignored Summary for node k/9: No parameter information. Summary for edge k/9->i/8: return value used only to compute caller return value Summary for node i/8: Returns value No parameter information. the k->i edge info looks misleading (the caller returns nothing), but the uses are all "dead". Eventually those dead stmts are now supposed to be cleaned up by the inliner because of the possibility of -fno-[tree-]dce, just in this case that isn't working? Not sure if really P2, but I guess return value removal isn't yet handled in that code path?
[Bug libstdc++/107814] [10/11/12 regression] experimental/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814 --- Comment #11 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:52daccd82cd71bd065826784ebb6eb04fa9b42af commit r12-9005-g52daccd82cd71bd065826784ebb6eb04fa9b42af Author: Jonathan Wakely Date: Tue Nov 22 19:15:53 2022 + libstdc++: Fix unsafe use of dirent::d_name [PR107814] Copy the fix for PR 104731 to the equivalent experimental::filesystem test. libstdc++-v3/ChangeLog: PR libstdc++/107814 * testsuite/experimental/filesystem/iterators/error_reporting.cc: Use a static buffer with space after it. (cherry picked from commit 1cac00d013856fea4cee0f13c4959c8e21afd2d9)
[Bug libstdc++/104731] 27_io/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104731 --- Comment #14 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:52daccd82cd71bd065826784ebb6eb04fa9b42af commit r12-9005-g52daccd82cd71bd065826784ebb6eb04fa9b42af Author: Jonathan Wakely Date: Tue Nov 22 19:15:53 2022 + libstdc++: Fix unsafe use of dirent::d_name [PR107814] Copy the fix for PR 104731 to the equivalent experimental::filesystem test. libstdc++-v3/ChangeLog: PR libstdc++/107814 * testsuite/experimental/filesystem/iterators/error_reporting.cc: Use a static buffer with space after it. (cherry picked from commit 1cac00d013856fea4cee0f13c4959c8e21afd2d9)
[Bug c++/105397] C++ modules vs -fvisibility option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105397 --- Comment #3 from Iain Sandoe --- the import places attributes at the end. so import module Foo [[]]; it would seem to be symmetrical to have: export import Foo [[...]]; export module Foo [[...]]; but, ts present, (if I read it correctly) it seems that the WD says export [[...]] module Foo; export [[...]] int bar (); which would then be weird with export [[...]] import Foo [[...]];
[Bug middle-end/107991] [10/11/12/13 Regression] Extra mov instructions with ternary on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107991 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Keywords|needs-bisection | --- Comment #4 from Richard Biener --- Martins change doesn't look very related to me, Richards one does though.
[Bug c/108194] New: GCC won't treat two compatible function types as compatible if any of them (or both of them) is declared _Noreturn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108194
Bug ID: 108194
Summary: GCC won't treat two compatible function types as
compatible if any of them (or both of them) is
declared _Noreturn
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
(same with __attribute((noreturn))) Example (https://godbolt.org/z/ePGd95sWz):
void FN_A(void);
void FN_B(void);
_Noreturn void NR_FN_A(void);
_Noreturn void NR_FN_B(void);
_Static_assert(_Generic((__typeof(*(FN_A))*){0}, __typeof(*(FN_B))*: 1), "");
//OK ✓
_Static_assert(_Generic((__typeof(*(NR_FN_A))*){0}, __typeof(*(NR_FN_B))*: 1),
""); //ERROR ✗
_Static_assert(_Generic((__typeof(*(FN_A))*){0}, __typeof(*(NR_FN_B))*: 1),
""); //ERROR ✗
As you can see from the Compiler Explorer link, clang accepts all three, which
is as it should be as per the standard, where _Noreturn is a function specifier
(https://port70.net/~nsz/c/c11/n1570.html#6.7.4), which means it shouldn't even
go into the type.
(Personally, I don't even mind it going into the type just as long as two
otherwise identical _Noreturn functio declarations are deemed as having the
same type).
Regards,
Petr Skocik
[Bug middle-end/107966] [10/11/12/13 Regression] option property Var(var) documentation seems cut off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107966 Richard Biener changed: What|Removed |Added Keywords||internal-improvement Priority|P3 |P4
[Bug ipa/107944] [11/12/13 Regression] ICE in cgraph_node::get_untransformed_body since r13-48-g27ee75dbe81bb7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107944 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||11.2.0, 12.1.0 Known to fail||11.3.0, 12.2.0, 13.0
[Bug ipa/108130] [13 Regression] LTO compile time hog seen on bootstrap-lto config since r13-4684-g7450b25566b7a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108130 --- Comment #3 from Martin Liška --- I noticed one more issue starting with this revision and it's linker error when building systemd-mini package: https://build.opensuse.org/package/live_build_log/home:marxin:home:marxin:gcc-periodic-testing-v2/systemd-mini/openSUSE_Tumbleweed/x86_64 [ 114s] /usr/bin/cc -o src/boot/efi/linuxx64.elf.stub -DGNU_EFI_USE_MS_ABI -DSD_BOOT -ffreestanding -fshort-wchar -fvisibility=hidden -I /home/abuild/rpmbuild/BUILD/systemd-v252.3+suse.40.gbf3fef9988/src/fundamental -I /home/abuild/rpmbuild/BUILD/systemd-v252.3+suse.40.gbf3fef9988/src/boot/efi -include src/boot/efi/efi_config.h -include version.h -isystem /usr/include/efi/x86_64 -isystem /usr/include/efi -std=gnu11 -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wdate-time -Wendif-labels -Werror=format=2 -Werror=format-signedness -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -Werror=int-conversion -Werror=overflow -Werror=override-init -Werror=return-type -Werror=shift-count-overflow -Werror=shift-overflow=2 -Werror=undef -Wfloat-equal -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op -Wmissing-include-dirs -Wmissing-noreturn -Wnested-externs -Wold-style-definition -Wpointer-arith -Wredundant-decls -Wshadow -Wstrict-aliasing=2 -Wstrict-prototypes -Wsuggest-attribute=noreturn -Wunused-function -Wwrite-strings -Wno-maybe-uninitialized -Wno-unused-result -ftrivial-auto-var-init=zero -fno-stack-protector -fno-strict-aliasing -fpic -fwide-exec-charset=UCS2 -O1 -mno-red-zone -mno-sse -mno-mmx -O2 -flto=auto -fuse-ld=bfd -L /usr/lib64 -nostdlib -T /usr/lib64/elf_x86_64_efi.lds -Wl,--build-id=sha1 -Wl,--fatal-warnings -Wl,--no-undefined -Wl,--warn-common -Wl,-Bsymbolic -z nocombreloc /usr/lib64/crt0-efi-x86_64.o -Wl,--no-warn-execstack -Wl,--no-warn-rwx-segments -pie -Wl,--no-dynamic-linker src/boot/efi/bootspec-fundamental.c.o src/boot/efi/efivars-fundamental.c.o src/boot/efi/sha256.c.o src/boot/efi/string-util-fundamental.c.o src/boot/efi/tpm-pcr.c.o src/boot/efi/assert.c.o src/boot/efi/console.c.o src/boot/efi/devicetree.c.o src/boot/efi/disk.c.o src/boot/efi/efi-string.c.o src/boot/efi/graphics.c.o src/boot/efi/initrd.c.o src/boot/efi/measure.c.o src/boot/efi/pe.c.o src/boot/efi/secure-boot.c.o src/boot/efi/ticks.c.o src/boot/efi/util.c.o src/boot/efi/cpio.c.o src/boot/efi/linux.c.o src/boot/efi/splash.c.o src/boot/efi/stub.c.o src/boot/efi/linux_x86.c.o -lefi -lgnuefi -lgcc [ 114s] /usr/bin/ld.bfd: /tmp/ccfbAVRm.ltrans0.ltrans.o: in function `locate_sections.constprop.0': [ 114s] :(.text+0x360c): undefined reference to `memcmp' [ 114s] collect2: error: ld returned 1 exit status note it's a freestanding environment and the symbol memcmp is defined by systemd. Note -flto-partition=one does not help us here. memcmp.part.0/2514 (memcmp.part.0) Type: function definition analyzed Visibility: semantic_interposition artificial References: Referring: Read from file: /tmp/ccnpwegs.ltrans0.o Function memcmp.part.0/2514 is inline copy in efi_main/1352 Clone of memcmp.part.0/2216 Unit id: 10 Function flags: count:29068074 (estimated locally) local split_part nonfreeing_fn Called by: memcmp.lto_priv.0/2513 (inlined) (29068074 (estimated locally),0.10 per call) Calls: memcmp.lto_priv.0/2513 (memcmp) Type: function definition analyzed Visibility: semantic_interposition public visibility:hidden References: Referring: Read from file: /tmp/ccnpwegs.ltrans0.o Function memcmp/2513 is inline copy in efi_main/1352 Clone of memcmp.lto_priv.0/503 Unit id: 10 Function flags: count:44042536 (estimated locally) local nonfreeing_fn Called by: is_direct_boot/1927 (inlined) (44042536 (estimated locally),0.15 per call) Calls: memcmp.part.0/2514 (inlined) (29068074 (estimated locally),0.10 per call) Unfortunately, I can't easily reduce a self-contained test-case. Please let me know on IRC and can debug it.
[Bug testsuite/108190] g++.target/i386/*pr54700*.C testcases fail on x86_64-mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190 --- Comment #6 from Marc Glisse --- Indeed, this looks like a common issue (at least with the x86 backend): the memory load is combined with the comparison before we try combining the comparison with the blend, and this last combination is then rejected because it expects a register, not memory. So either we are too eager in merging loads with instructions, or we reject instructions too early when we could still fix the operands with an extra load.
[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
--- Comment #8 from Richard Biener ---
Just to recap here, we inline fun3 via inline_always_inline_functions and
then early_inline_small_functions bails on the call because foo4
doesn't yet have a function summary:
/* We can encounter not-yet-analyzed function during
early inlining on callgraphs with strongly
connected components. */
ipa_fn_summary *s = ipa_fn_summaries->get (callee);
if (s == NULL || !s->inlinable || !e->inline_failed)
continue;
that's where the ordering constraint comes in. That's also a hard error
in can_inline_edge_p which does
else if (ipa_fn_summaries->get (callee) == NULL
|| !ipa_fn_summaries->get (callee)->inlinable)
{
e->inline_failed = CIF_FUNCTION_NOT_INLINABLE;
inlinable = false;
even if we'd try harder and re-do inline_always_inline_functions after
each inline step (up to max early inliner iterations). Maybe for QOI
we can handle this special case in ipa_reverse_postorder by putting
address-taken nodes without any calls last (we don't seem to have
indirect edges at this point to do a better job):
diff --git a/gcc/ipa-utils.cc b/gcc/ipa-utils.cc
index 67dd42f4faf..75e1387714e 100644
--- a/gcc/ipa-utils.cc
+++ b/gcc/ipa-utils.cc
@@ -294,7 +294,7 @@ ipa_reverse_postorder (struct cgraph_node **order)
for (pass = 0; pass < 2; pass++)
FOR_EACH_FUNCTION (node)
if (!node->aux
- && (pass
+ && ((pass && !(!node->callees && node->address_taken))
|| (!node->address_taken
&& !node->inlined_to
&& !node->alias && !node->thunk
@@ -346,7 +346,10 @@ ipa_reverse_postorder (struct cgraph_node **order)
}
free (stack);
FOR_EACH_FUNCTION (node)
-node->aux = NULL;
+if (!node->aux)
+ order[order_pos++] = node;
+else
+ node->aux = NULL;
return order_pos;
}
[Bug tree-optimization/108187] False positive -Wfree-nonheap-object on impossible path with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108187 --- Comment #2 from Ilya Maximets --- (In reply to Richard Biener from comment #1) > Well, between the store to ->source and the read from it is the call > to dp_packet_use_afxdp which gets >packet as argument and thus > needs to be treated as clobbering ->source. So GCC can indeed not know > that ->source is DPBUF_AFXDP since the path is not provable impossible. > dp_packet_use_afxdp doesn't even get a const struct dp_packet * argument > (not that this would semantically change things in C). Hmm, dp_packet_use_afxdp() is the function that sets source to DPBUF_AFXDP and initializes other parts of the structure. So, it cannot take a const argument. If GCC just doesn't look inside the dp_packet_use_afxdp() function at all here, then it will indeed not know that the source is DPBUF_AFXDP now. However, I'm not sure why the issue doesn't appear with -O0 then.
[Bug c++/107897] [13 Regression] mangling conflicts with a previous mangle since r13-3601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/107853] [10/11/12/13 Regression] variadic template with a variadic template friend with a requires of fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107853 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Version|unknown |13.0
[Bug target/102218] 128-bit atomic compare and exchange does not honor memory model on AArch64 and Arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102218 --- Comment #4 from Tamar Christina --- (In reply to ktkachov from comment #3) > Does this need to be backported to other release versions as it's a > wrong-code bug? Yes Ideally. I did ask for backport but was only approved for master.
[Bug libstdc++/107814] [10/11/12 regression] experimental/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814 Richard Biener changed: What|Removed |Added Known to work||13.0 Priority|P3 |P2 Summary|[13 regression] |[10/11/12 regression] |experimental/filesystem/ite |experimental/filesystem/ite |rators/error_reporting.cc |rators/error_reporting.cc |FAILs |FAILs --- Comment #10 from Richard Biener --- marking trunk as fixed but to be backported.
[Bug target/108191] Add support to usage of *intrin.h without -mavx512f -mavx512cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108191
--- Comment #7 from Jakub Jelinek ---
(In reply to 罗勇刚(Yonggang Luo) from comment #6)
> Is the following command are valid usage? It's compiled properly
No, this is invalid.
>
> ```
>
> // compile args: -fPIC -O2 -D__SSE3__=1 -D__SSSE3__=1 -D__SSE4_1__=1
> -D__SSE4_2__=1 -D__SSE4A__=1 -D__POPCNT__=1 -D__XSAVE__=1 -D__CRC32__=1
> -D__AVX__=1 -D__AVX2__=1 -D__FP_FAST_FMAF32=1 -D__FP_FAST_FMAF64=1
> -D__FP_FAST_FMAF=1 -D__FP_FAST_FMAF32x=1 -D__AVX512F__=1 -D__AVX512CD__=1
Only -fPIC -O2 here, none of the -D arguments, all of them are internal
GCC macros that shouldn't be redefined by users.
Plus it isn't needed.
> #include
>
> #pragma GCC push_options
> #pragma GCC target("avx512f")
> #pragma GCC target("avx512cd")
> #pragma GCC target("sse4a")
>
> #if defined(_MSC_VER)
> #include
> #else
> #include
> #endif
>
> #pragma GCC pop_options
You can do it, but for GCC it is completely useless, you can just
#include without anything further.
> #pragma GCC push_options
> #pragma GCC target("avx512f")
> #pragma GCC target("avx512cd")
> #pragma GCC target("sse4a")
This is certainly fine, but avx512f in there isn't needed, that is implied by
avx512cd.
Though, I don't see anything avx512cd nor sse4a-ish in there.
>
> void util_fadd_512(float *a, float *b, float *c) {
> /* a = b + c */
> __m512 av = _mm512_load_ps(a);
> __m512 bv = _mm512_load_ps(b);
> __m512 cv = _mm512_add_ps(av, bv);
> _mm512_store_ps(c, cv);
> }
> static inline int
> util_iround(float f)
> {
>__m128 m = _mm_set_ss(f);
>return _mm_cvtss_i32(m);
> }
>
> #pragma GCC pop_options
>
> int util_iround_outside(int x, float y) {
> return x + util_iround(y);
> }
> float util_fadd(float a, float b) {
>return a + b;
> }
> ```
That said, code with avx512cd etc. target won't inline into code without it.
[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #14 from Richard Biener ---
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 250782b1140..41f48c30bb9 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -2713,7 +2713,9 @@ gimplify_switch_expr (tree *expr_p, gimple_seq *pre_p)
bool old_in_switch_expr = gimplify_ctxp->in_switch_expr;
gimplify_ctxp->in_switch_expr = true;
+ gimple_push_condition ();
gimplify_stmt (_BODY (switch_expr), _body_seq);
+ gimple_pop_condition (pre_p);
gimplify_ctxp->in_switch_expr = old_in_switch_expr;
maybe_warn_switch_unreachable_and_auto_init (switch_body_seq);
"properly" adds early return predictors to switch returns and will result in
the same pessimization. Cutting off early return predictor generation will
make firewall2 produce via if-to-switch
:
dst_port_5 = MEM[(const uint16_t *)data_3(D) + 64B];
switch (dst_port_5) [INV], case 1: [INV], case 2:
[INV], case 3: [INV], case 15: [INV], case 23: [INV], case
42: [INV], case 45: [INV], case 47: [INV]>
:
:
:
# _2 = PHI <1(3), 0(2)>
:
return _2;
and retaining a bit test.
Note that after stripping predict hints it takes tail-merging to unify
the forwarders, this is not something done by CFG cleanup. That's
because in this case all forwarders have '1' as the PHI argument but
the single non-forwarder has '0'. CFG cleanup doesn't redirect
forwarders to duplicates. The default label doesn't have an
early return prediction (the return doesn't happen in conditional
context as far as gimplification is concerned). If it had a forwarder
as well which forwarder CFG cleanup would remove would be "random".
Note this all would still happen too late for the early switch conversion
pass.
It might be possible to alter the switch conversion heuristics in ::collect
to handle empty_block_p forwarders specially, counting the number of
forwarders with distinct m_final_bb PHI argument sets. Like with the
following.
diff --git a/gcc/tree-cfgcleanup.cc b/gcc/tree-cfgcleanup.cc
index b4869aee78d..38e40eca164 100644
--- a/gcc/tree-cfgcleanup.cc
+++ b/gcc/tree-cfgcleanup.cc
@@ -450,7 +450,7 @@ tree_forwarder_block_p (basic_block bb, bool phi_wanted)
those alternatives are equal in each of the PHI nodes, then return
true, else return false. */
-static bool
+bool
phi_alternatives_equal (basic_block dest, edge e1, edge e2)
{
int n1 = e1->dest_idx;
diff --git a/gcc/tree-switch-conversion.cc b/gcc/tree-switch-conversion.cc
index 1d75d7c7fc7..6d2889f6c5a 100644
--- a/gcc/tree-switch-conversion.cc
+++ b/gcc/tree-switch-conversion.cc
@@ -69,6 +69,9 @@ switch_conversion::switch_conversion (): m_final_bb (NULL),
{
}
+bool
+phi_alternatives_equal (basic_block dest, edge e1, edge e2);
+
/* Collection information about SWTCH statement. */
void
@@ -132,6 +135,8 @@ switch_conversion::collect (gswitch *swtch)
/* Require that all switch destinations are either that common
FINAL_BB or a forwarder to it, except for the default
case if contiguous range. */
+ auto_vec fw_edges;
+ m_uniq = 0;
if (m_final_bb)
FOR_EACH_EDGE (e, ei, m_switch_bb->succs)
{
@@ -141,7 +146,26 @@ switch_conversion::collect (gswitch *swtch)
if (single_pred_p (e->dest)
&& single_succ_p (e->dest)
&& single_succ (e->dest) == m_final_bb)
- continue;
+ {
+ if (empty_block_p (e->dest))
+ {
+ /* For empty blocks consider forwarders with equal
+ PHI arguments in m_final_bb as unique. */
+ for (unsigned i = 0; i < fw_edges.length (); ++i)
+ if (phi_alternatives_equal (m_final_bb, fw_edges[i], e))
+ break;
+ if (i == fw_edges.length ())
+ {
+ /* But limit the above possibly quadratic search. */
+ if (fw_edges.length () < 10)
+ fw_edges.quick_push (e);
+ m_uniq++;
+ }
+ }
+ else
+ m_uniq++;
+ continue;
+ }
if (e == e_default && m_contiguous_range)
{
@@ -168,11 +192,6 @@ switch_conversion::collect (gswitch *swtch)
&& ! tree_int_cst_equal (CASE_LOW (elt), CASE_HIGH (elt)))
m_count++;
}
-
- /* Get the number of unique non-default targets out of the GIMPLE_SWITCH
- block. Assume a CFG cleanup would have already removed degenerate
- switch statements, this allows us to just use EDGE_COUNT. */
- m_uniq = EDGE_COUNT (gimple_bb (swtch)->succs) - 1;
}
/* Checks whether the range given by individual case statements of the switch
[Bug bootstrap/108186] Bootstrap comparison failure.gcc-12.2.0 differs gcc/plugin.o gcc/gcc.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108186 --- Comment #6 from AlexK --- (In reply to Richard Biener from comment #1) > can you try configuring with --without-build-config please? /mnt/Git/apt-build/build/gcc-12.2.0/build $ ../configure --prefix=/tools/gcc-12.2.0 --without-build-config LD=ld --enable-gcov --enable-libssp --enable-bootstrap --enable-lto --with-isl=/usr/local --with-mpc=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local --with-system-zlib --enable-host-shared --disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++,fortran,objc,obj-c++,jit,go > my2.log configure: error: Building GCC requires GMP 4.2+, MPFR 3.1.0+ and MPC 0.8.0+. Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify their locations. Source code for these libraries can be found at their respective hosting sites as well as at https://gcc.gnu.org/pub/gcc/infrastructure/. See also http://gcc.gnu.org/install/prerequisites.html for additional info. If you obtained GMP, MPFR and/or MPC from a vendor distribution package, make sure that you have installed both the libraries and the header files. They may be located in separate packages. /mnt/Git/apt-build/build/gcc-12.2.0/build $ make libtool: install: warning: remember to run `libtool --finish /tools/gcc-12.2.0/libexec/gcc/x86_64-pc-linux-gnu/12.2.0' configure: WARNING: fixed-point is not supported for this target, ignored Links are now set up to build a native compiler for x86_64-pc-linux-gnu. ../../../libcpp/expr.cc: In function ‘unsigned int cpp_classify_number(cpp_reader*, const cpp_token*, const char**, location_t)’: ../../../libcpp/expr.cc:808:18: warning: format not a string literal and no format arguments [-Wformat-security] 808 |0, message); | ^ ../../../libcpp/expr.cc:811:39: warning: format not a string literal and no format arguments [-Wformat-security] 811 | virtual_location, 0, message); | ^ ../../../libcpp/expr.cc:821:34: warning: format not a string literal and no format arguments [-Wformat-security] 821 | virtual_location, 0, message); | ^ ../../../libcpp/macro.cc: In member function ‘vaopt_state::update_type vaopt_state::update(const cpp_token*)’: ../../../libcpp/macro.cc:186:23: warning: format not a string literal and no format arguments [-Wformat-security] 186 | vaopt_paste_error); | ^ ../../../libcpp/macro.cc:215:24: warning: format not a string literal and no format arguments [-Wformat-security] 215 | vaopt_paste_error); |^ ../../../libcpp/macro.cc: In function ‘cpp_macro* create_iso_definition(cpp_reader*)’: ../../../libcpp/macro.cc:3704:58: warning: format not a string literal and no format arguments [-Wformat-security] 3704 |cpp_error (pfile, CPP_DL_ERROR, paste_op_error_msg); | ^ ../../../libcpp/macro.cc:3719:58: warning: format not a string literal and no format arguments [-Wformat-security] 3719 |cpp_error (pfile, CPP_DL_ERROR, paste_op_error_msg); | ^ file: Compiled magic version [538] does not match with shared library magic version [543] ../../libcpp/expr.cc: In function ‘unsigned int cpp_classify_number(cpp_reader*, const cpp_token*, const char**, location_t)’: ../../libcpp/expr.cc:808:18: warning: format not a string literal and no format arguments [-Wformat-security] 808 |0, message); | ^ ../../libcpp/expr.cc:811:39: warning: format not a string literal and no format arguments [-Wformat-security] 811 | virtual_location, 0, message); | ^ ../../libcpp/expr.cc:821:34: warning: format not a string literal and no format arguments [-Wformat-security] 821 | virtual_location, 0, message); | ^ ../../libcpp/macro.cc: In member function ‘vaopt_state::update_type vaopt_state::update(const cpp_token*)’: ../../libcpp/macro.cc:186:23: warning: format not a string literal and no format arguments [-Wformat-security] 186 | vaopt_paste_error); | ^ ../../libcpp/macro.cc:215:24: warning: format not a string literal and no format arguments [-Wformat-security] 215 | vaopt_paste_error); |^ ../../libcpp/macro.cc: In function ‘cpp_macro* create_iso_definition(cpp_reader*)’: ../../libcpp/macro.cc:3704:58: warning: format not a string literal and no format arguments [-Wformat-security] 3704 |cpp_error (pfile, CPP_DL_ERROR, paste_op_error_msg); | ^ ../../libcpp/macro.cc:3719:58: warning: format not a string literal and no format arguments
[Bug bootstrap/108186] Bootstrap comparison failure.gcc-12.2.0 differs gcc/plugin.o gcc/gcc.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108186 --- Comment #5 from AlexK --- (In reply to Richard Biener from comment #1) > can you try configuring with --without-build-config please? first small error - zstd link I will change Makefile in gcc see mylog.tar.gz attachment
