[Bug tree-optimization/106010] New: Miss vectorization for complex type copy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106010
Bug ID: 106010
Summary: Miss vectorization for complex type copy.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
This is from PR105923
void
foo (_Complex double *p, _Complex double* q)
{
for (int i = 0; i != 10; i++)
p[i] = q[i];
}
gcc generates
foo(double _Complex*, double _Complex*):
xor eax, eax
.L2:
vmovsd xmm1, QWORD PTR [rsi+rax]
vmovsd xmm0, QWORD PTR [rsi+8+rax]
vmovsd QWORD PTR [rdi+rax], xmm1
vmovsd QWORD PTR [rdi+8+rax], xmm0
add rax, 16
cmp rax, 160
jne .L2
ret
llvm generates:
foo(double _Complex*, double _Complex*): #
@foo(double _Complex*, double _Complex*)
xor eax, eax
.LBB0_1:# =>This Inner Loop Header: Depth=1
movups xmm0, xmmword ptr [rsi + rax]
movups xmmword ptr [rdi + rax], xmm0
add rax, 16
cmp rax, 160
jne .LBB0_1
ret
vectorizer failed because get_related_vectype_for_scalar_type failed for
complex type.
[Bug c++/106009] [modules] internal compiler error: in mark_by_value, at cp/module.cc:4775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106009 --- Comment #1 from John Smith --- Created attachment 53159 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53159=edit preprocessed with -save-temps
[Bug c++/106009] New: [modules] internal compiler error: in mark_by_value, at cp/module.cc:4775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106009 Bug ID: 106009 Summary: [modules] internal compiler error: in mark_by_value, at cp/module.cc:4775 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: overlord624 at gmail dot com Target Milestone: --- Created attachment 53158 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53158=edit output with -freport-bug Trying to compile the spdlog library to a header unit causes an internal compiler error. Adding -save-temps to the parameters causes the same error, but the compiler claims the error is non-reproducible. No errors occur when the same header is included in the global module fragment of a regular module. $ g++-exp -freport-bug -fmodules-ts -std=c++20 -Wall -Wextra -pedantic -DSPDLOG_COMPILED_LIB -x c++-system-header spdlog/spdlog.h /usr/include/spdlog/spdlog.h: internal compiler error: in mark_by_value, at cp/module.cc:4775 0x7112a2 trees_out::mark_by_value(tree_node*) /media/extra/sources/gcc/gcc/cp/module.cc:4775 0xabe961 trees_out::mark_declaration(tree_node*, bool) /media/extra/sources/gcc/gcc/cp/module.cc:12245 0xabebd9 trees_out::mark_class_def(tree_node*) /media/extra/sources/gcc/gcc/cp/module.cc:11744 0xac859d depset::hash::find_dependencies(module_state*) /media/extra/sources/gcc/gcc/cp/module.cc:13126 0xac8cc0 module_state::write_begin(elf_out*, cpp_reader*, module_state_config&, unsigned int&) /media/extra/sources/gcc/gcc/cp/module.cc:17640 0xac9f84 finish_module_processing(cpp_reader*) /media/extra/sources/gcc/gcc/cp/module.cc:19962 0xa58c85 c_parse_final_cleanups() /media/extra/sources/gcc/gcc/cp/decl2.cc:5156 0xc7ab60 c_common_parse_file() /media/extra/sources/gcc/gcc/c-family/c-opts.cc:1253 Please submit a full bug report, with preprocessed source. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Preprocessed source stored into /tmp/cc4TWK1u.out file, please attach this to your bugreport. $ g++-exp -v Using built-in specs. COLLECT_GCC=g++-exp COLLECT_LTO_WRAPPER=/media/extra/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /media/extra/sources/gcc/configure --host=x86_64-pc-linux-gnu --prefix=/media/extra --disable-multilib --enable-threads --enable-tls --enable-languages=c,c++ --disable-nls Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20220616 (experimental) (GCC)
[Bug middle-end/106008] [11/12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106008 H.J. Lu changed: What|Removed |Added Version|12.0|11.2.1 Summary|[12 Regression] warning:|[11/12 Regression] warning: |‘(((char *)loadcmds.113_68 |‘(((char *)loadcmds.113_68 |+ _933 +|+ _933 + |16))[329406144173384849].ma |16))[329406144173384849].ma |pend’ may be used |pend’ may be used |uninitialized |uninitialized |[-Wmaybe-uninitialized] |[-Wmaybe-uninitialized] --- Comment #2 from H.J. Lu --- GCC 11 has the same issue.
[Bug tree-optimization/95821] Failure to optimize strchr to use memchr for string constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95821 --- Comment #4 from H.J. Lu --- Created attachment 53157 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53157=edit A patch
[Bug middle-end/106008] [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106008
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-06-16
--- Comment #1 from H.J. Lu ---
Simply change the cost of integer store makes the warnings to go away:
diff --git a/gcc/config/i386/x86-tune-costs.h
b/gcc/config/i386/x86-tune-costs.h
index 6c9066c84cc..b83bb79c065 100644
--- a/gcc/config/i386/x86-tune-costs.h
+++ b/gcc/config/i386/x86-tune-costs.h
@@ -3276,7 +3276,11 @@ struct processor_costs generic_cost = {
{6, 6, 6}, /* cost of loading integer registers
in QImode, HImode and SImode.
Relative to reg-reg move (2). */
+#if 0
{6, 6, 6}, /* cost of storing integer registers */
+#else
+ {8, 8, 8}, /* cost of storing integer registers */
+#endif
{6, 6, 6, 10, 15}, /* cost of loading SSE register
in 32bit, 64bit, 128bit, 256bit and 512bit */
{6, 6, 6, 10, 15}, /* cost of storing SSE register
[Bug libstdc++/101482] operator== for basic_string and __versa_string should check sizes first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101482 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |13.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed now, thanks for the report.
[Bug libstdc++/105995] QoI: constexpr basic_string variable must use all of its SSO buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105995 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Jonathan Wakely --- Fixed for GCC 13, thanks for the report.
[Bug libstdc++/105995] QoI: constexpr basic_string variable must use all of its SSO buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105995 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:98a0d72a610a87e8e383d366e50253ddcc9a51dd commit r13-1139-g98a0d72a610a87e8e383d366e50253ddcc9a51dd Author: Jonathan Wakely Date: Thu Jun 16 14:57:32 2022 +0100 libstdc++: Support constexpr global std::string for size < 15 [PR105995] I don't think this is required by the standard, but it's easy to support. libstdc++-v3/ChangeLog: PR libstdc++/105995 * include/bits/basic_string.h (_M_use_local_data): Initialize the entire SSO buffer. * testsuite/21_strings/basic_string/cons/char/105995.cc: New test.
[Bug libstdc++/101482] operator== for basic_string and __versa_string should check sizes first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101482 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:51309d1158b85560a975819260776c0ca68fd142 commit r13-1138-g51309d1158b85560a975819260776c0ca68fd142 Author: Jonathan Wakely Date: Thu Jun 16 11:02:11 2022 +0100 libstdc++: Apply r13-1096-g6abe341558abec change to vstring too [PR101482] As recently done for std::basic_string, __gnu_cxx::__versa_string equality comparisons can check lengths first for any character type and traits type, not only for std::char_traits. libstdc++-v3/ChangeLog: PR libstdc++/101482 * include/ext/vstring.h (operator==): Always check lengths before comparing.
[Bug middle-end/106008] New: [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106008 Bug ID: 106008 Summary: [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- Created attachment 53156 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53156=edit A testcase When building glibc master branch with -mavx512f, I got [hjl@gnu-tgl-2 tmp]$ gcc -O2 -march=x86-64 -S -Wall x.i -mavx512f dl-load.c: In function ‘_dl_map_object_from_fd.constprop’: dl-load.c:1158:30: warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] [hjl@gnu-tgl-2 tmp]$ The code looks like struct loadcmd *c = [nloadcmds++]; c->mapstart = ALIGN_DOWN (ph->p_vaddr, GLRO(dl_pagesize)); c->mapend = ALIGN_UP (ph->p_vaddr + ph->p_filesz, GLRO(dl_pagesize)); c->dataend = ph->p_vaddr + ph->p_filesz; c->allocend = ph->p_vaddr + ph->p_memsz; /* Remember the maximum p_align. */ if (powerof2 (ph->p_align) && ph->p_align > p_align_max) p_align_max = ph->p_align; c->mapoff = ALIGN_DOWN (ph->p_offset, GLRO(dl_pagesize)); /* Determine whether there is a gap between the last segment and this one. */ if (nloadcmds > 1 && c[-1].mapend != c->mapstart) has_holes = true; c[-1].mapend should always be initialized.
[Bug c++/106001] [12/13 Regression] ICE: expected expression 'static_cast(1)' of kind static_cast_expr since r12-1128-gef8176e0fac935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106001 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 53155 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53155=edit gcc13-pr106001.patch Untested fix.
[Bug tree-optimization/103798] memchr with a (small) constant string should be expanded inline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103798 --- Comment #2 from H.J. Lu --- Created attachment 53154 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53154=edit A patch Like this?
[Bug target/105991] [12/13 Regression] rldicl+sldi+add generated instead of rldimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105991 --- Comment #3 from Marek Polacek --- Regtest/bootstrap passed on powerpc64le-unknown-linux-gnu. I did not test Ada.
[Bug c++/106001] [12/13 Regression] ICE: expected expression 'static_cast(1)' of kind static_cast_expr since r12-1128-gef8176e0fac935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106001
--- Comment #2 from Jakub Jelinek ---
Actually valid testcase:
typedef int V __attribute__((vector_size (2 * sizeof (int;
template
void
foo ()
{
V v {};
v = __builtin_shufflevector (v, v, static_cast(1),
static_cast(0));
}
void
bar ()
{
foo <0> ();
}
[Bug analyzer/106007] New: RFE: analyzer should complain about exec/system of tainted args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106007 Bug ID: 106007 Summary: RFE: analyzer should complain about exec/system of tainted args Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- The analyzer should complain if tainted args are passed to any of the following without sanitization (probably not an exhaustive list): int execl(const char *pathname, const char *arg, ... /* (char *) NULL */); int execlp(const char *file, const char *arg, ... /* (char *) NULL */); int execle(const char *pathname, const char *arg, ... /*, (char *) NULL, char * const envp[] */); int execv(const char *pathname, char *const argv[]); int execvp(const char *file, char *const argv[]); int execvpe(const char *file, char *const argv[], char *const envp[]); int execve(const char *pathname, char *const argv[], char *const envp[]); int execveat(int dirfd, const char *pathname, char *const argv[], char *const envp[], int flags); int fexecve(int fd, char *const argv[], char *const envp[]); int system(const char *command); Could have/reuse an attribute for this, or hardcode it.
[Bug analyzer/106006] New: RFE: analyzer should treat data from a socket as "tainted"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106006 Bug ID: 106006 Summary: RFE: analyzer should treat data from a socket as "tainted" Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- These functions should taint the buffers they write to: ssize_t recv(int sockfd, void *buf, size_t len, int flags); ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags, struct sockaddr *src_addr, socklen_t *addrlen); ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags); Perhaps we could add/reuse an attribute for this, or hardcode the knowledge in the analyzer.
[Bug fortran/106005] New: (F2023) Support for REDUCTION clause in DO CONCURRENT loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005 Bug ID: 106005 Summary: (F2023) Support for REDUCTION clause in DO CONCURRENT loop Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: wileamyp at outlook dot com Target Milestone: --- GFortran 12.1.0 refuses to compile the following valid code under Fortran 2023. $ cat dc-reduce.f90 PROGRAM dcreduce INTEGER, PARAMETER :: n = 10 INTEGER :: ivec(n) ivec = [( i, i = 1, n )] ival = 0 DO CONCURRENT (i=1:n) REDUCE(+:ival) ival = ival + ivec(i) END DO PRINT *, ival END PROGRAM $ gfortran --version GNU Fortran (Spack GCC) 12.1.0 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gfortran dc-reduce.f90 dc-reduce.f90:7:24: 7 | DO CONCURRENT (i=1:n) REDUCE(+:ival) |1 Error: Syntax error in DO statement at (1) dc-reduce.f90:9:5: 9 | END DO | 1 Error: Expecting END PROGRAM statement at (1) At the time of writing, only NVIDIA nvfortran compiles this successfully and gives the correct result. Tested with nvfortran 22.5. $ nvfortran --version nvfortran 22.5-0 64-bit target on x86-64 Linux -tp zen2 NVIDIA Compilers and Tools Copyright (c) 2022, NVIDIA CORPORATION & AFFILIATES. All rights reserved. $ nvfortran dc-reduce.f90 $ ./a.out 55
[Bug target/106004] New: [13 Regression] ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in arm_print_operand, at config/arm/arm.cc:24202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106004
Bug ID: 106004
Summary: [13 Regression] ICE: RTL check: expected elt 0 type
'i' or 'n', have 'w' (rtx const_int) in
arm_print_operand, at config/arm/arm.cc:24202
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: build, ice-checking, ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: armv7a-hardfloat-linux-gnueabi
Created attachment 53153
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53153=edit
reduced testcase (from sanitizer_deadlock_detector1.cpp)
This currently breaks build with RTL checking enabled.
Compiler output:
$ /repo/build-gcc-trunk-armv7a-hardfloat/./gcc/cc1plus -O -march=armv7-a+vfpv4
testcase.C
bool DeadlockDetector::nodeBelongsToCurrentEpoch() void MutexEnsureID()
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 1176k} {heap 1176k}
{heap 1176k} {heap 1460k} {heap 2124k}
{heap 2124k} {heap 2124k}Streaming LTO
{heap 2124k} {heap 2124k} {heap
2124k} {heap 2124k} {heap 2124k} {heap 2124k}
{heap 2124k} {heap 2124k} {heap
2124k} {heap 2124k}Assembling functions:
void MutexEnsureID()during RTL pass: final
testcase.C: In function 'void MutexEnsureID()':
testcase.C:19:1: internal compiler error: RTL check: expected elt 0 type 'i' or
'n', have 'w' (rtx const_int) in arm_print_operand, at config/arm/arm.cc:24202
19 | }
| ^
0x804c80 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
/repo/gcc-trunk/gcc/rtl.cc:907
0x8ccae3 arm_print_operand
/repo/gcc-trunk/gcc/config/arm/arm.cc:24202
0xfbbc31 output_operand(rtx_def*, int)
/repo/gcc-trunk/gcc/final.cc:3677
0xfbca83 output_asm_insn(char const*, rtx_def**)
/repo/gcc-trunk/gcc/final.cc:3570
0xfc28fc output_asm_insn(char const*, rtx_def**)
/repo/gcc-trunk/gcc/final.cc:3466
0xfc28fc final_scan_insn_1
/repo/gcc-trunk/gcc/final.cc:2894
0xfc2d0b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/repo/gcc-trunk/gcc/final.cc:2940
0xfc2e04 final_1
/repo/gcc-trunk/gcc/final.cc:1997
0xfc3b56 rest_of_handle_final
/repo/gcc-trunk/gcc/final.cc:4285
0xfc3b56 execute
/repo/gcc-trunk/gcc/final.cc:4363
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ /repo/build-gcc-trunk-armv7a-hardfloat/./gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/repo/build-gcc-trunk-armv7a-hardfloat/./gcc/xgcc
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-float=hard --with-fpu=vfpv4
--with-arch=armv7-a --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-1134-20220616143736-g9642d07c35f-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220616 (experimental) (GCC)
[Bug c++/105996] [10/11/12/13 Regression] reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105996 --- Comment #3 from Jakub Jelinek --- Or can we say just call cp_convert instead of build_reinterpret_cast in that case?
[Bug target/105992] memcmp(p, q, 7) == 0 can be optimized better on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105992 --- Comment #3 from H.J. Lu --- (In reply to Hongtao.liu from comment #1) > I'm wondering would targetm.overlap_op_by_pieces_p helps here. The code is generated by targetm.overlap_op_by_pieces_p. It compares 4 byte at a time with branches.
[Bug c++/105996] [10/11/12/13 Regression] reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105996
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
The problem is that build_ptrmemfunc in
9587 if (TREE_CODE (pfn) != PTRMEM_CST)
9588{
9589 if (same_type_p (to_type, pfn_type))
9590return pfn;
9591 else if (integer_zerop (n) && TREE_CODE (pfn) != CONSTRUCTOR)
9592return build_reinterpret_cast (input_location, to_type,
pfn,
9593 complain);
9594}
calls build_reintepret_cast from void (A::*)() typed pfn to void (B::*)() type,
and when we then constant expression evaluate it, we reject it because
reinterpret_cast is not a core constant expression as per
https://eel.is/c++draft/expr.const#5.16
Now, is this reinterpret cast just some implementation detail under the hood in
which we should somehow arrange for REINTERPRET_CAST_P bit not be set (or
afterwards remove it)?
[Bug analyzer/106003] RFE: -fanalyzer could complain about misuse of file-descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003 --- Comment #1 from David Malcolm --- See also this mailing list thread: https://gcc.gnu.org/pipermail/gcc/2022-June/238801.html
[Bug analyzer/106003] New: RFE: -fanalyzer could complain about misuse of file-descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
Bug ID: 106003
Summary: RFE: -fanalyzer could complain about misuse of
file-descriptors
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
-fanalyzer could be extended to check POSIX file-descriptor APIs ("int" rather
than FILE *).
e.g.
- check for FD leaks
- check for double "close" of a FD (CWE-1341, I believe)
- check for read/write of a closed descriptor
- check for read/write of a descriptor opened for just writing/reading
etc
Immad Mir is looking at this for GSoC 2022.
Example of a "double file-descriptor close" bug:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13351
albeit in C++.
[Bug target/105992] memcmp(p, q, 7) == 0 can be optimized better on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105992 --- Comment #2 from H.J. Lu --- (In reply to Hongtao.liu from comment #1) > I'm wondering would targetm.overlap_op_by_pieces_p helps here. It is related to PR 103798.
[Bug target/105991] [12/13 Regression] rldicl+sldi+add generated instead of rldimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105991 --- Comment #2 from Marek Polacek --- (In reply to Roger Sayle from comment #1) > The following patch appears to correct this for me on a cross-compiler to > powerpcle64, but it's tricky for me to do a full bootstrap/regression test. Thanks for the patch. I'm testing it and will report back the results.
[Bug middle-end/105998] [10/11/12/13 Regression] ICE: in as_a, at machmode.h:365 with vector arithmetics since r9-1971-g315aa691f486bf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105998 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Component|c++ |middle-end
[Bug analyzer/105888] RFE: -fanalyzer should complain when an on-stack address escapes/outlives the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105888 --- Comment #1 from David Malcolm --- See also CWE-562: Return of Stack Variable Address https://cwe.mitre.org/data/definitions/562.html
[Bug tree-optimization/105973] Wrong branch prediction for if (COND) { if(x) noreturn1(); else noreturn2(); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105973 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-06-16 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Martin Liška --- I can try implementing that.
[Bug rtl-optimization/105988] [10/11/12/13 Regression] ICE in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1064 since r6-4873-gebedc9a3414d8422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105988 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression] |ICE in |ICE in |linemap_ordinary_map_lookup |linemap_ordinary_map_lookup |, at|, at |libcpp/line-map.cc:1064 |libcpp/line-map.cc:1064 ||since ||r6-4873-gebedc9a3414d8422 Ever confirmed|0 |1 Last reconfirmed||2022-06-16 CC||dmalcolm at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- (In reply to G. Steinmetz from comment #1) > Starts with r6 and file gcc.dg/torture/pr56034.c, etc. : > (starts with r7 without option -fno-tree-dce) Started with r6-4873-gebedc9a3414d8422.
[Bug target/105980] [11/12/13 Regression] ICE in final_scan_insn_1, at final.cc:2811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC||andi-gcc at firstfloor dot org,
||marxin at gcc dot gnu.org
Last reconfirmed||2022-06-16
Ever confirmed|0 |1
--- Comment #1 from Martin Liška ---
Reduced to something like:
struct A {
virtual ~A();
};
struct B : virtual A {};
void bar() { B(); }
It's there since the beginning as we emitted an invalid assembly:
/tmp/ccw0I6Qv.s:178: Error: `.LTHUNK0@GOTOFF(%bh)' is not a valid base/index
expression
/tmp/ccw0I6Qv.s:235: Error: `.LTHUNK1@GOTOFF(%bh)' is not a valid base/index
expression
[Bug tree-optimization/105820] [13 Regression] ICE in invert, at value-range.cc:1971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105820 --- Comment #4 from Andrew Macleod --- Well, thats not really the problem here. We are casting [irange] gimple_code [2, 2] to a gimple_code, and getting: [irange] gimple_code VARYING Couple of issues.. one, we shouldnt bother casting anything if the types are already the same... but still.. the result is incorrect. Tracing it down, it looks like during the casting process, we call: operator_cast::inside_domain_p so see if a min == 2, max == 2, is inside the range of[irange] gimple_code VARYING. THe routine returns false because with strict enum on, we get the min and max of the domain from: wide_int domain_min = wi::to_wide (vrp_val_min (range.type ())); wide_int domain_max = wi::to_wide (vrp_val_max (range.type ()));, which boils down to TYPE_MIN_VALUE (gimple_code) and TYPE_MAX_VALUE (gimple_code) p range.type () $29 = (tree_node *) 0x7fffe9f77c78 (gdb) p print_generic_expr (stderr, $29, 0) gimple_code (gdb) p print_generic_expr (stderr, $29->type_non_common.minval, 0) 0 (gdb) p print_generic_expr (stderr, $29->type_non_common.maxval, 0) 1 So the min value for the enum is set correctly to 0, but the max is set to 1... thus the routine determines that [2, 2] is not within the range of [0, 1] and returns varying.. It seems like the max value for the enum is not being set correctly? If I check right at the point of the failure: (gdb) frame 1 #1 0x01c9c4fe in irange::invert (this=0x7fff1570) at /home/gcc/master/gcc/gcc/value-range.cc:2185 2185 gcc_checking_assert (!undefined_p () && !varying_p ()); (gdb) p type() $42 = (tree_node *) 0x7fffe9f77c78 (gdb) p print_generic_expr (stderr, type(), 0) gimple_code (gdb) p print_generic_expr (stderr, type()->type_non_common.maxval, 0) 1
[Bug c/105972] [12/13 Regression] ICE in lower_stmt, at gimple-low.cc:312 since r12-4608-gb4702276615ff8d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105972 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Keywords|needs-bisection | Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Summary|[12/13 Regression] ICE in |[12/13 Regression] ICE in |lower_stmt, at |lower_stmt, at |gimple-low.cc:312 |gimple-low.cc:312 since ||r12-4608-gb4702276615ff8d4 --- Comment #2 from Martin Liška --- Started with my revision r12-4608-gb4702276615ff8d4, I'll take a look.
[Bug ipa/105978] ICE: nodes with unreleased memory found since r9-4254-g12485662c00914ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105978 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-06-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|ICE: nodes with unreleased |ICE: nodes with unreleased |memory found|memory found since ||r9-4254-g12485662c00914ed --- Comment #1 from Martin Liška --- Started with r9-4254-g12485662c00914ed.
[Bug analyzer/105892] RFE: -fanalyzer could complain about pointer subtraction of pointers to different memory chunks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105892 --- Comment #1 from David Malcolm --- See also CWE 469: https://cwe.mitre.org/data/definitions/469.html
[Bug analyzer/106000] RFE: -fanalyzer should complain about definite buffer overflows/underflows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106000 --- Comment #2 from David Malcolm --- See also: https://cwe.mitre.org/data/definitions/468.html
[Bug analyzer/105900] RFE: -fanalyzer could check malloc sizes when casting the result to a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105900 --- Comment #2 from David Malcolm --- See also: https://cwe.mitre.org/data/definitions/467.html
[Bug rtl-optimization/105952] [12/13 Regression] ICE in sel_redirect_edge_and_branch, at sel-sched-ir.cc:5680
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105952 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-06-16 --- Comment #1 from Martin Liška --- Started with r12-7687-g3a7ba8fd0cda3878, but it likely revealed it.
[Bug c++/106001] [12/13 Regression] ICE: nexpected expression 'static_cast(1)' of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106001 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|[12 Regression] ICE:|[12/13 Regression] ICE: |nexpected expression|nexpected expression |'static_cast(1)' of |'static_cast(1)' of |kind static_cast_expr |kind static_cast_expr CC||mpolacek at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Last reconfirmed||2022-06-16 Target Milestone|--- |12.2 --- Comment #1 from Marek Polacek --- Started with r12-1128-gef8176e0fac935 commit ef8176e0fac935c095cc39f4ecdfd43cdb8cb3f3 Author: Richard Biener Date: Fri May 21 11:33:30 2021 +0200 c++/88601 - [C/C++] __builtin_shufflevector support
[Bug tree-optimization/105940] suggested_unroll_factor applying place looks wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940 Kewen Lin changed: What|Removed |Added Attachment #53126|0 |1 is obsolete|| --- Comment #7 from Kewen Lin --- Created attachment 53152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53152=edit Tested patch but fail with SPEC build
[Bug tree-optimization/105940] suggested_unroll_factor applying place looks wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940 --- Comment #6 from Kewen Lin --- (In reply to Kewen Lin from comment #4) > (In reply to Richard Biener from comment #2) > > (In reply to Kewen Lin from comment #1) > > > Created attachment 53126 [details] > > > move_applying > > > > LGTM (maybe the suggested unroll factor should be only applied if the > > suggestion was from a matching with/without SLP analysis, or in fact > > vect_analyze_loop_1 should communicate that down - disabling SLP when > > the one suggesting unrolling did the re-analysis). > > Oops, just noticed the nice suggestion. Will make a follow up patch for > this. > It would looks like: > when working out suggested unroll factor, save slp decision into one > passed down variable from vect_analyze_loop_1. > when applying suggested unroll factor, if the save slp is false, directly > ignore slp handlings, otherwise, go the normal slp path but won't start over > for slp off. I tested one patch which was bootstrapped and regress-tested on x86, aarch64 and powerpc64le, but found some failures on SPEC2017 run with rs6000 hackings, the reason to fail is that we can save reduction chain in vect_is_simple_reduction for further analysis in SLP detection, if we aggressively skip SLP related analyses in vect_analyze_loop_2, there is ICE in vectorizable_reduction if (REDUC_GROUP_FIRST_ELEMENT (stmt_info)) gcc_assert (slp_node && REDUC_GROUP_FIRST_ELEMENT (stmt_info) == stmt_info); There seem to be some alternatives: 1) check if applying_suggested_uf && !slp_done_for_suggested_uf initially in vect_analyze_loop_2, if yes, pass slp disabled information down to vect_is_simple_reduction, not to save reduction chain for later slp analysis (not existed). 2) before we are going to do the slp related analyses (vect_analyze_slp etc.), check if applying_suggested_uf && !slp_done_for_suggested_uf, if yes, dissolve LOOP_VINFO_REDUCTION_CHAINS(loop_info). 3) for the case applying_suggested_uf && !slp_done_for_suggested_uf, we still let it go through slp related analyses but not applying suggested unroll factor, only applying for its retry without slp. 3) is simple but seems to be the worst since we still do some useless analyses. 1) can save the reduction chain handlings, seems to be the best, not sure if it's too intrusive, and if there are some similar needs (in future) to do so. 2) is similar to 1), it's to add one common place to undo those previous analysis results which are only for slp analyses and can cause unexpected result if we don't undo it. Any suggestions on this?
[Bug tree-optimization/105990] Dead code elimination failed at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105990 John Klein changed: What|Removed |Added CC||Painololo at protonmail dot com --- Comment #2 from John Klein --- Thanks for the decision.
[Bug analyzer/106000] RFE: -fanalyzer should complain about definite buffer overflows/underflows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106000 John Klein changed: What|Removed |Added CC||Painololo at protonmail dot com --- Comment #1 from John Klein --- Thanks for the decision. Saw a similar one at https://www.wildtornado.casino/games/casino_slots/.
[Bug lto/105877] GNU strip breaks -flto -g .o files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105877 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-06-16
[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X' since r12-954-g84fd1b5dff70cd74
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105925
Martin Liška changed:
What|Removed |Added
Summary|[11/12/13 Regression] Could |[11/12/13 Regression] Could
|not convert '{{0, 0.0}}'|not convert '{{0, 0.0}}'
|from '' to 'X' |initializer list>' to 'X'
||since
||r12-954-g84fd1b5dff70cd74
Keywords|needs-bisection |
CC||jason at gcc dot gnu.org
--- Comment #3 from Martin Liška ---
Started with r12-954-g84fd1b5dff70cd74.
[Bug analyzer/101837] [11/12 Regression] ICE with -O3 -fsanitize=undefined -fanalyzer since r11-7941-ge4bb1bd60a9fd1be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101837 Martin Liška changed: What|Removed |Added CC||girgias at php dot net --- Comment #6 from Martin Liška --- *** Bug 105919 has been marked as a duplicate of this bug. ***
[Bug analyzer/105919] Internal compiler error when using -fanalyzer on php-src
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105919 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 101837 ***
[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105925 Martin Liška changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|NEW Last reconfirmed||2022-06-16 Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Sorry, wrong bug.
[Bug analyzer/101837] [11/12 Regression] ICE with -O3 -fsanitize=undefined -fanalyzer since r11-7941-ge4bb1bd60a9fd1be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101837 Martin Liška changed: What|Removed |Added CC||jehova at existiert dot net --- Comment #5 from Martin Liška --- *** Bug 105925 has been marked as a duplicate of this bug. ***
[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105925 Martin Liška changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 101837 ***
[Bug c/106002] New: RFE: complain about incorrect checks of return values (CWE-253)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106002
Bug ID: 106002
Summary: RFE: complain about incorrect checks of return values
(CWE-253)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Some APIs return NULL to signify an error; others return a negative int. It's
possible to mess up by confusing these.
We currently don't warn at -Wall on these:
#include
#include
extern void do_something_with (void *);
int test_1 (void)
{
void *tmp = malloc(1024);
if (tmp < 0 )
return -1;
do_something_with (tmp);
free (tmp);
return 0;
}
int test_2 (void)
{
char buf[256];
if (fgets (buf, sizeof (buf), stdin) < 0)
return -1;
do_something_with (buf);
return 0;
}
where both error checks are testing for < 0, when they should be checking for
NULL; looks to me like we ought to warn for this.
I'm not sure if it's possible to reliably warn for the opposite error without
lots of false positives (checking for pointer NULL, rather than int 0?)
Filing against "c" since I think this could probably happen in the frontends
rather than the analyzer.
See CWE-253:
https://cwe.mitre.org/data/definitions/253.html
[Bug c++/105921] internal compiler error: in cp_parser_template_id, at cp/parser.cc:18362
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105921 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-06-16 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org
[Bug c++/105998] [10/11/12/13 Regression] ICE: in as_a, at machmode.h:365 with vector arithmetics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105998 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Last reconfirmed||2022-06-16 Status|UNCONFIRMED |NEW Target Milestone|--- |10.4 --- Comment #1 from Marek Polacek --- Started with commit 315aa691f486bfe71bae0a5fc8828db26daebb56 Author: Jakub Jelinek Date: Mon Jul 23 09:48:56 2018 +0200 re PR c++/86569 (-Wnonnull-compare affects code generation since r233684) PR c++/86569 * cp-gimplify.c (cp_fold): Don't fold comparisons into other kind of expressions other than INTEGER_CST regardless of TREE_NO_WARNING or warn_nonnull_compare. * g++.dg/warn/Wnonnull-compare-9.C: New test. From-SVN: r262928
[Bug c++/105912] internal compiler error: in extract_call_expr, at cp/call.cc:7114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105912 Martin Liška changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- (In reply to Marek Polacek from comment #3) > The ICE started with r277733 > > commit f968ef9b8df2bc2287e5e7e87299e5a2a44e8c94 > Author: Jakub Jelinek > Date: Sat Nov 2 00:28:20 2019 +0100 > > PR c++/88335 - Implement P1073R3: Immediate functions @Marek: Please add to CC author of a revision you bisected to.
[Bug middle-end/105902] Documentation for the RTL front-end was never added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105902 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-06-16 CC||marxin at gcc dot gnu.org
[Bug c++/106001] New: [12 Regression] ICE: nexpected expression 'static_cast(1)' of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106001
Bug ID: 106001
Summary: [12 Regression] ICE: nexpected expression
'static_cast(1)' of kind static_cast_expr
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with the gcc-12 branch 20220616 on x86_64-linux-gnu, building the spoa
package:
$ cat simd_alignment_engine_dispatch.ii
template void _mmxxx_prefix_max() {
char simde__tmp_a__0 =
__builtin_shufflevector(simde__tmp_a__0, 0, static_cast(1))
$ LANG=C g++ -c -msse2 -O0 -std=c++11 simd_alignment_engine_dispatch.ii
simd_alignment_engine_dispatch.ii: In function 'void _mmxxx_prefix_max()':
simd_alignment_engine_dispatch.ii:3:71: internal compiler error: unexpected
expression 'static_cast(1)' of kind static_cast_expr
3 | __builtin_shufflevector(simde__tmp_a__0, 0, static_cast(1))
| ^
0x6d9b71 cxx_eval_constant_expression
../../src/gcc/cp/constexpr.cc:7587
0x6d9ec0 cxx_eval_outermost_constant_expr
../../src/gcc/cp/constexpr.cc:7824
0x6dd267 maybe_constant_value(tree_node*, tree_node*, bool)
../../src/gcc/cp/constexpr.cc:8103
0x867381 build_x_shufflevector(unsigned int, vec*,
int)
../../src/gcc/cp/typeck.cc:6337
0x7cf33e cp_parser_postfix_expression
../../src/gcc/cp/parser.cc:7496
0x7b8096 cp_parser_binary_expression
../../src/gcc/cp/parser.cc:10035
0x7b889e cp_parser_assignment_expression
../../src/gcc/cp/parser.cc:10339
0x7ba3c9 cp_parser_constant_expression
../../src/gcc/cp/parser.cc:10642
0x7ba461 cp_parser_initializer_clause
../../src/gcc/cp/parser.cc:25223
0x7bd44c cp_parser_initializer
../../src/gcc/cp/parser.cc:25163
0x7eaf5f cp_parser_init_declarator
../../src/gcc/cp/parser.cc:22773
0x7c73b8 cp_parser_simple_declaration
../../src/gcc/cp/parser.cc:15280
0x7c8fe0 cp_parser_declaration_statement
../../src/gcc/cp/parser.cc:14361
0x7c97cc cp_parser_statement
../../src/gcc/cp/parser.cc:12446
0x7ca6ed cp_parser_statement_seq_opt
../../src/gcc/cp/parser.cc:12850
0x7ca79f cp_parser_compound_statement
../../src/gcc/cp/parser.cc:12802
0x7e91c3 cp_parser_function_body
../../src/gcc/cp/parser.cc:25069
0x7e91c3 cp_parser_ctor_initializer_opt_and_function_body
../../src/gcc/cp/parser.cc:25120
0x7ea30e cp_parser_function_definition_after_declarator
../../src/gcc/cp/parser.cc:31252
0x7eb376 cp_parser_function_definition_from_specifiers_and_declarator
../../src/gcc/cp/parser.cc:31168
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
// Target: x86_64-linux-gnu
// Configured with: ../src/configure -v --with-pkgversion='Debian 12.1.0-4'
--with-bugurl=file:/
//usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --p
refix=/usr --with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --ena
ble-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug -
-enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable
-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checki
ng=release --with-target-system-zlib=auto --enable-objc-gc=auto
--enable-multiarch --disable-wer
ror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-m
ultilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-8ErGg2/gcc-12-12.1
.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-8ErGg2/gcc-12-12.1.0/debian/tmp-gcn/usr
--en
able-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
// Thread model: posix
// Supported LTO compression algorithms: zlib zstd
// gcc version 12.1.0 (Debian 12.1.0-4)
[Bug analyzer/106000] New: RFE: -fanalyzer should complain about definite buffer overflows/underflows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106000 Bug ID: 106000 Summary: RFE: -fanalyzer should complain about definite buffer overflows/underflows Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Blocks: 105887 Target Milestone: --- I attempted to implement buffer-overflow (and underflow) detection for GCC 12, trying to categorize all region accesses as either: (a) definitely in-bounds (b) definitely out-of-bounds (c) possibly out-of-bounds Unfortunately my implementation led to a "wall of noise" level of warnings from (c). It now strikes me that we could at least implement warnings for (b) - where we can see definite problems, and that this might be at least somewhat useful. Compare with: https://clang.llvm.org/docs/analyzer/checkers.html#alpha-security-arraybound-c https://clang.llvm.org/docs/analyzer/checkers.html#alpha-security-arrayboundv2-c Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105887 [Bug 105887] [meta-bug] clang analyzer warnings that GCC's -fanalyzer could implement
[Bug rtl-optimization/105822] ICE in maybe_record_trace_start, at dwarf2cfi.cc:2579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105822 Martin Liška changed: What|Removed |Added CC||aoliva at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r13-380-g90a8eab4a1292430.
[Bug analyzer/105900] RFE: -fanalyzer could check malloc sizes when casting the result to a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105900 --- Comment #1 from David Malcolm --- See https://cwe.mitre.org/data/definitions/131.html e.g. example 5. See also: https://clang.llvm.org/docs/analyzer/checkers.html#alpha-security-mallocoverflow-c (CWE 131's example 2 has a case of this)
[Bug fortran/105807] ICE / error when defining a class containing polymorphic components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105807 Martin Liška changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r12-4464-g017665f63047ce47, it was rejected before the revision.
[Bug target/105981] [10/11/12 regression] Wrong code from gen_cpymem_ldrd_strd() with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|10.5|10.4 --- Comment #7 from Richard Earnshaw --- Fixed on all active release branches.
[Bug c++/105798] Add new -Wshadow for data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105798 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2022-06-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug target/105981] [10/11/12 regression] Wrong code from gen_cpymem_ldrd_strd() with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:20ece449e06f2d0dd0c50db0203d13b4e4ff2d96 commit r10-10850-g20ece449e06f2d0dd0c50db0203d13b4e4ff2d96 Author: Richard Earnshaw Date: Wed Jun 15 16:07:20 2022 +0100 arm: big-endian issue in gen_cpymem_ldrd_strd [PR105981] The code in gen_cpymem_ldrd_strd has been incorrect for big-endian since r230663. The problem is that we use gen_lowpart, etc. to split the 64-bit quantity, but fail to account for the fact that these routines are really dealing with 64-bit /values/ and in big-endian the ordering of the sub-registers changes. To fix this, I've renamed the conceptually misnamed low_reg and hi_reg as first_reg and second_reg, and then used different logic for big-endian targets to initialize these values. This makes the logic clearer than trying to think about high bits and low bits. gcc/ChangeLog: PR target/105981 * config/arm/arm.c (gen_cpymem_ldrd_strd): Rename low_reg and hi_reg to first_reg and second_reg respectively. Initialize them correctly when generating big-endian code. (cherry picked from commit 8aaa948059a8b5f0a62ad010d0aa6346b7ac9cd3)
[Bug target/105981] [10/11/12 regression] Wrong code from gen_cpymem_ldrd_strd() with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:2a9c9ed732d6a7f4565a286bdeb953f08fbe8fb9 commit r11-10074-g2a9c9ed732d6a7f4565a286bdeb953f08fbe8fb9 Author: Richard Earnshaw Date: Wed Jun 15 16:07:20 2022 +0100 arm: big-endian issue in gen_cpymem_ldrd_strd [PR105981] The code in gen_cpymem_ldrd_strd has been incorrect for big-endian since r230663. The problem is that we use gen_lowpart, etc. to split the 64-bit quantity, but fail to account for the fact that these routines are really dealing with 64-bit /values/ and in big-endian the ordering of the sub-registers changes. To fix this, I've renamed the conceptually misnamed low_reg and hi_reg as first_reg and second_reg, and then used different logic for big-endian targets to initialize these values. This makes the logic clearer than trying to think about high bits and low bits. gcc/ChangeLog: PR target/105981 * config/arm/arm.c (gen_cpymem_ldrd_strd): Rename low_reg and hi_reg to first_reg and second_reg respectively. Initialize them correctly when generating big-endian code. (cherry picked from commit 8aaa948059a8b5f0a62ad010d0aa6346b7ac9cd3)
[Bug target/105981] [10/11/12 regression] Wrong code from gen_cpymem_ldrd_strd() with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:723c1d6284ca9f79cc35bf7bf49f391417773f83 commit r12-8488-g723c1d6284ca9f79cc35bf7bf49f391417773f83 Author: Richard Earnshaw Date: Wed Jun 15 16:07:20 2022 +0100 arm: big-endian issue in gen_cpymem_ldrd_strd [PR105981] The code in gen_cpymem_ldrd_strd has been incorrect for big-endian since r230663. The problem is that we use gen_lowpart, etc. to split the 64-bit quantity, but fail to account for the fact that these routines are really dealing with 64-bit /values/ and in big-endian the ordering of the sub-registers changes. To fix this, I've renamed the conceptually misnamed low_reg and hi_reg as first_reg and second_reg, and then used different logic for big-endian targets to initialize these values. This makes the logic clearer than trying to think about high bits and low bits. gcc/ChangeLog: PR target/105981 * config/arm/arm.cc (gen_cpymem_ldrd_strd): Rename low_reg and hi_reg to first_reg and second_reg respectively. Initialize them correctly when generating big-endian code. (cherry picked from commit 8aaa948059a8b5f0a62ad010d0aa6346b7ac9cd3)
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 105983, which changed state. Bug 105983 Summary: Failure to optimize (b != 0) && (a >= b) as well as the same pattern with binary and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/105983] Failure to optimize (b != 0) && (a >= b) as well as the same pattern with binary and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug middle-end/105984] [13 Regression] wrong code with __builtin_mul_overflow_p() at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105984 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed, thanks for the report.
[Bug tree-optimization/105983] Failure to optimize (b != 0) && (a >= b) as well as the same pattern with binary and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9642d07c35f14b9917cd115e8a9f0210fbcdcf4f commit r13-1134-g9642d07c35f14b9917cd115e8a9f0210fbcdcf4f Author: Jakub Jelinek Date: Thu Jun 16 14:37:06 2022 +0200 match.pd: Improve y == MIN || x < y optimization [PR105983] On the following testcase, we only optimize bar where this optimization is performed at GENERIC folding time, but on GIMPLE it doesn't trigger anymore, as we actually don't see (bit_and (ne @1 min_value) (ge @0 @1)) but (bit_and (ne @1 min_value) (le @1 @0)) genmatch handles :c modifier not just on commutative operations, but also comparisons and in that case it means it swaps the comparison. 2022-06-16 Jakub Jelinek PR tree-optimization/105983 * match.pd (y == XXX_MIN || x < y -> x <= y - 1, y != XXX_MIN && x >= y -> x > y - 1): Use :cs instead of :s on non-equality comparisons. * gcc.dg/tree-ssa/pr105983.c: New test.
[Bug middle-end/105984] [13 Regression] wrong code with __builtin_mul_overflow_p() at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105984 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:74e6a40335765077e235269f19d2d9905d0d9e44 commit r13-1133-g74e6a40335765077e235269f19d2d9905d0d9e44 Author: Jakub Jelinek Date: Thu Jun 16 14:36:04 2022 +0200 match.pd: Fix up __builtin_mul_overflow_p signed type optimization [PR105984] Earlier in the simplification pattern, we require that @0 has compatible type to the type of IMAGPART_EXPR, but for @1 which is a non-zero constant all we require is that it the constant fits into that type. Later the code checks if the constant is negative, because when min / max values are divided by negative divisor, lo will be higher than hi. In the following testcase, @1 has unsigned char type, while @0 has int type, so @1 which is 254 is wi::neg_p and we were swapping lo and hi, even when @1 cast to int isn't negative. We could use tree_int_cst_sgn (@1) < 0 as the check instead and it would work both for narrower types of @1 and even same or wider ones, but I've noticed we probably don't want to call fold_convert (TREE_TYPE (@0), @1) twice and when we save that result in a temporary, we can just use wi::neg_p on that temporary. 2022-06-16 Jakub Jelinek PR tree-optimization/105984 * match.pd (__builtin_mul_overflow_p (x, cst, (stype) 0) -> x > stype_max / cst || x < stype_min / cst): fold_convert @1 to TREE_TYPE (@0) just once and test for negative divisor also on that folded constant instead of on @1. * gcc.c-torture/execute/pr105984.c: New test.
[Bug c++/105999] New: Wrong requires result inside lambda in a class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105999
Bug ID: 105999
Summary: Wrong requires result inside lambda in a class
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: egor.pugin at gmail dot com
Target Milestone: ---
Gives x instead of y on any latest compiler.
https://godbolt.org/z/6MrvMaPoK
#include
struct A {
void g(){}
void f() {
[]() {
//if constexpr (requires {this->g();}) {
if constexpr (requires {g();}) {
printf("x");
//g(); // cant call here
} else {
printf("y");
}
}();
}
};
int main() {
A{}.f();
}
[Bug libstdc++/105995] QoI: constexpr basic_string variable must use all of its SSO buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105995
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-06-16
Severity|normal |enhancement
--- Comment #4 from Jonathan Wakely ---
This makes it work:
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -352,7 +352,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
{
#if __cpp_lib_is_constant_evaluated
if (std::is_constant_evaluated())
- _M_local_buf[0] = _CharT();
+ for (_CharT& __c : _M_local_buf)
+ __c = _CharT();
#endif
return _M_local_data();
}
[Bug libstdc++/105995] QoI: constexpr basic_string variable must use all of its SSO buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105995 --- Comment #3 from Jonathan Wakely --- Right, you can only use std::string as a local variable in a constexpr function. I don't think it's expected to work as a constexpr variable.
[Bug c++/105996] [12/11/12/13 Regression] reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105996
Jonathan Wakely changed:
What|Removed |Added
Summary|reinterpret_cast in |[12/11/12/13 Regression]
|constexpr failure creating |reinterpret_cast in
|a pair with a function |constexpr failure creating
|pointer of class parent |a pair with a function
||pointer of class parent
Last reconfirmed||2022-06-16
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Known to fail||10.3.0, 11.3.0, 12.1.0,
||13.0, 8.1.0
CC||jakub at gcc dot gnu.org
Known to work||7.5.0
--- Comment #1 from Jonathan Wakely ---
Reduced:
template constexpr int make_pair(T&&, U&&) { return 0;
}
struct A {
void CB() {}
};
struct B : public A {
void Test() {
using MyCB = void (B::*)();
static constexpr auto p = make_pair(1, ::CB);
}
};
105996.C: In member function 'void B::Test()':
105996.C:10:53: error: a reinterpret_cast is not a constant expression
static constexpr auto p = make_pair(1, ::CB);
^~
Started to fail some time before r256448, probably
commit e99ef40892b598eeb3fa496cc472e111675d7f6c
Author: Jakub Jelinek
Date: Wed Jan 10 16:59:09 2018
re PR c++/81327 (cast to void* does not suppress -Wclass-memaccess)
PR c++/81327
* call.c (maybe_warn_class_memaccess): Add forward declaration.
Change last argument from tree * to const vec *,
adjust
args uses and check number of operands too. Don't strip away any
nops. Use maybe_constant_value when looking for INTEGER_CST args.
Deal with src argument not having pointer type. Check
tree_fits_uhwi_p before calling tree_to_uhwi. Remove useless
test.
(build_over_call): Call maybe_warn_class_memaccess here on the
original arguments.
(build_cxx_call): Rather than here on converted arguments.
* g++.dg/Wclass-memaccess-2.C: Don't expect a warning when
explicitly
cast to void *.
From-SVN: r256440
[Bug c++/105997] A possible optimization bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105997 --- Comment #6 from Andrew Pinski --- Also people who assume the compiler is broken ask them to try -fsanitize=address and other sanitizers really. Gcc does is more "sensitive" to undefined behavior and more bugs in the user code does happen.
[Bug c++/105997] A possible optimization bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105997 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #3) > If anybody wants to turn it into a proper bug report, the original commit > (and description) is at > https://github.com/zynaddsubfx/zynaddsubfx/commit/ > 22a5f8da76c16c47c3814eedaec8f9fe0ff4248b "Symptoms of the failed optimization include a partial copy of values with some corrupted or turned into null pointers." Sounds likely to be a lifetime issue with the std::string values e.g. trying to read them after the containing vector has been destroyed. But somebody has to provide a proper bug report to be sure. Please stop opening bug reports that are just a link to comments in github. If you want to investigate them yourself, great. But "Somebody said GCC broke their code" is not a valid bug report.
[Bug c++/105998] New: [10/11/12/13 Regression] ICE: in as_a, at machmode.h:365 with vector arithmetics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105998
Bug ID: 105998
Summary: [10/11/12/13 Regression] ICE: in as_a, at
machmode.h:365 with vector arithmetics
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Created attachment 53151
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53151=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-g++ testcase.C
testcase.C: In function 'void foo()':
testcase.C:8:44: internal compiler error: in as_a, at machmode.h:365
8 | long l = (long) ((0 | v) - ((V) { } == 0));
|^
0x90395f scalar_int_mode as_a(machine_mode)
/repo/gcc-trunk/gcc/machmode.h:365
0x904edf scalar_int_mode as_a(machine_mode)
/repo/gcc-trunk/gcc/tree.h:3630
0x904edf narrowing_initializer_constant_valid_p
/repo/gcc-trunk/gcc/varasm.cc:4720
0x19d616e initializer_constant_valid_p_1
/repo/gcc-trunk/gcc/varasm.cc:5022
0x19d70b1 initializer_constant_valid_p(tree_node*, tree_node*, bool)
/repo/gcc-trunk/gcc/varasm.cc:5054
0xe493be reduced_constant_expression_p(tree_node*)
/repo/gcc-trunk/gcc/cp/constexpr.cc:3100
0x109a807 store_init_value(tree_node*, tree_node*, vec**, int)
/repo/gcc-trunk/gcc/cp/typeck2.cc:935
0xe9f6c7 check_initializer
/repo/gcc-trunk/gcc/cp/decl.cc:7454
0xec5d41 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/repo/gcc-trunk/gcc/cp/decl.cc:8439
0xfb7a5c cp_parser_init_declarator
/repo/gcc-trunk/gcc/cp/parser.cc:22899
0xf914a3 cp_parser_simple_declaration
/repo/gcc-trunk/gcc/cp/parser.cc:15315
0xf931ad cp_parser_declaration_statement
/repo/gcc-trunk/gcc/cp/parser.cc:14394
0xf93a01 cp_parser_statement
/repo/gcc-trunk/gcc/cp/parser.cc:12471
0xf9491d cp_parser_statement_seq_opt
/repo/gcc-trunk/gcc/cp/parser.cc:12883
0xf949f8 cp_parser_compound_statement
/repo/gcc-trunk/gcc/cp/parser.cc:12835
0xfb4f35 cp_parser_function_body
/repo/gcc-trunk/gcc/cp/parser.cc:25184
0xfb4f35 cp_parser_ctor_initializer_opt_and_function_body
/repo/gcc-trunk/gcc/cp/parser.cc:25235
0xfb6ada cp_parser_function_definition_after_declarator
/repo/gcc-trunk/gcc/cp/parser.cc:31362
0xfb8060 cp_parser_function_definition_from_specifiers_and_declarator
/repo/gcc-trunk/gcc/cp/parser.cc:31279
0xfb8060 cp_parser_init_declarator
/repo/gcc-trunk/gcc/cp/parser.cc:22637
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/105997] A possible optimization bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105997 --- Comment #4 from Jonathan Wakely --- (In reply to Andreas Schwab from comment #2) > This line is definitely a bug in ZynAddSubFX: > > 1154:bool is_dir = fn->d_type & DT_DIR; > > d_type is not a bitfield. Not all systems even have a dirent::d_type field (POSIX doesn't require it).
[Bug c++/105997] A possible optimization bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105997 --- Comment #3 from Jonathan Wakely --- If anybody wants to turn it into a proper bug report, the original commit (and description) is at https://github.com/zynaddsubfx/zynaddsubfx/commit/22a5f8da76c16c47c3814eedaec8f9fe0ff4248b
[Bug c++/105997] A possible optimization bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105997 --- Comment #2 from Andreas Schwab --- This line is definitely a bug in ZynAddSubFX: 1154:bool is_dir = fn->d_type & DT_DIR; d_type is not a bitfield.
[Bug c++/105997] A possible optimization bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105997 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- This is not a valid bug report. https://gcc.gnu.org/bugs
[Bug target/105930] [12/13 Regression] Excessive stack spill generation on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105930 Arnd Bergmann changed: What|Removed |Added CC||arnd at linaro dot org --- Comment #19 from Arnd Bergmann --- I checked the other target architectures that are supported by the kernel to see if anything else is affected. Apparently only sparc32 has a similar issue with a frame size of 2280 bytes using gcc-10 or higher, compared to 600 to 800 bytes for gcc-4 through gcc-9.
[Bug libstdc++/101482] operator== for basic_string and __versa_string should check sizes first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101482 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-06-16 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Jonathan Wakely --- (In reply to Jiang An from comment #0) > It seems that the resolution should be generalized to all specializations of > basic_string (by removing the legacy operator== overload and SFINAE in the > new overload, which is already done by libc++ and msvc stl). Yes, https://wg21.link/lwg2852 clarified that we can do that. > IMO the > generalized resolution can also be applied to operator== for __versa_string. Yes I'll do that, thanks.
[Bug middle-end/105951] [12 Regression] ICE in emit_store_flag, at expmed.cc:6027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105951 Jakub Jelinek changed: What|Removed |Added Summary|[12/13 Regression] ICE in |[12 Regression] ICE in |emit_store_flag, at |emit_store_flag, at |expmed.cc:6027 |expmed.cc:6027 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 HaoChen Gui changed: What|Removed |Added Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |guihaoc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #18 from HaoChen Gui --- Fixed by r13-1131
[Bug middle-end/105951] [12/13 Regression] ICE in emit_store_flag, at expmed.cc:6027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105951
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:6a27c430468cb85454b19cef881a1422580657ff
commit r13-1132-g6a27c430468cb85454b19cef881a1422580657ff
Author: Jakub Jelinek
Date: Thu Jun 16 10:58:58 2022 +0200
expand: Fix up IFN_ATOMIC_{BIT*,*CMP_0} expansion [PR105951]
Both IFN_ATOMIC_BIT_TEST_AND_* and IFN_ATOMIC_*_FETCH_CMP_0 ifns
are matched if their corresponding optab is implemented for the particular
mode. The fact that those optabs are implemented doesn't guarantee
they will succeed though, they can just FAIL in their expansion.
The expansion in that case uses expand_atomic_fetch_op as fallback, but
as has been reported and and can be reproduced on the testcases,
even those can fail and we didn't have any fallback after that.
For IFN_ATOMIC_BIT_TEST_AND_* we actually have such calls. One is
done whenever we lost lhs of the ifn at some point in between matching
it in tree-ssa-ccp.cc and expansion. The following patch for that case
just falls through and expands as if there was a lhs, creates a temporary
for it. For the other expand_atomic_fetch_op call in the same expander
and for the only expand_atomic_fetch_op call in the other, this falls
back the hard way, by constructing a CALL_EXPR to the call from which
the ifn has been matched and expanding that. Either it is lucky and
manages
to expand inline, or it emits a libatomic API call.
So that we don't have to rediscover which builtin function to call in the
fallback, we record at tree-ssa-ccp.cc time gimple_call_fn (call) in
an extra argument to the ifn.
2022-06-16 Jakub Jelinek
PR middle-end/105951
* tree-ssa-ccp.cc (optimize_atomic_bit_test_and,
optimize_atomic_op_fetch_cmp_0): Remember gimple_call_fn (call)
as last argument to the internal functions.
* builtins.cc (expand_ifn_atomic_bit_test_and): Adjust for the
extra call argument to ifns. If expand_atomic_fetch_op fails for
the
lhs == NULL_TREE case, fall through into the optab code with
gen_reg_rtx (mode) as target. If second expand_atomic_fetch_op
fails, construct a CALL_EXPR and expand that.
(expand_ifn_atomic_op_fetch_cmp_0): Adjust for the extra call
argument
to ifns. If expand_atomic_fetch_op fails, construct a CALL_EXPR
and
expand that.
* gcc.target/i386/pr105951-1.c: New test.
* gcc.target/i386/pr105951-2.c: New test.
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 --- Comment #17 from CVS Commits --- The master branch has been updated by HaoChen Gui : https://gcc.gnu.org/g:8d1c6e7038b0c281ac2678f2f615806a7aac9174 commit r13-1131-g8d1c6e7038b0c281ac2678f2f615806a7aac9174 Author: Haochen Gui Date: Mon May 30 09:12:34 2022 +0800 rs6000: add V1TI into vector comparison expand [PR103316] This patch adds V1TI mode into a new mode iterator used in vector comparison,shift and rotation expands. It also merges some vector comparison, shift and rotation expands for V1T1 and other vector integer modes as they have the similar patterns. The expands for V1TI only are removed. gcc/ PR target/103316 * config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_builtin): Enable gimple folding for RS6000_BIF_VCMPEQUT, RS6000_BIF_VCMPNET, RS6000_BIF_CMPGE_1TI, RS6000_BIF_CMPGE_U1TI, RS6000_BIF_VCMPGTUT, RS6000_BIF_VCMPGTST, RS6000_BIF_CMPLE_1TI, RS6000_BIF_CMPLE_U1TI. * config/rs6000/vector.md (VEC_IC): New mode iterator. Add support for new Power10 V1TI instructions. (vec_cmp): Set mode iterator to VEC_IC. (vec_cmpu): Likewise. (vector_nlt): Set mode iterator to VEC_IC. (vector_nltv1ti): Remove. (vector_gtu): Set mode iterator to VEC_IC. (vector_gtuv1ti): Remove. (vector_nltu): Set mode iterator to VEC_IC. (vector_nltuv1ti): Remove. (vector_geu): Set mode iterator to VEC_IC. (vector_ngt): Likewise. (vector_ngtv1ti): Remove. (vector_ngtu): Set mode iterator to VEC_IC. (vector_ngtuv1ti): Remove. (vector_gtu__p): Set mode iterator to VEC_IC. (vector_gtu_v1ti_p): Remove. (vrotl3): Set mode iterator to VEC_IC. Emit insns for V1TI. (vrotlv1ti3): Remove. (vashr3): Set mode iterator to VEC_IC. Emit insns for V1TI. (vashrv1ti3): Remove. gcc/testsuite/ PR target/103316 * gcc.target/powerpc/pr103316.c: New. * gcc.target/powerpc/fold-vec-cmp-int128.c: New.
[Bug c++/105997] New: A possible optimization bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105997
Bug ID: 105997
Summary: A possible optimization bug
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
ZynAddSubFX is a musical synthesizer. I find a strange code in this project:
https://github.com/zynaddsubfx/zynaddsubfx/blob/master/src/Misc/MiddleWare.cpp
#if defined(__GNUC__) && !defined(__clang__) && !defined(__INTEL_COMPILER)
#pragma GCC push_options
#pragma GCC optimize("O0")
#endif
void gcc_10_1_0_is_dumb(const std::vector ,
const int N,
char *types,
rtosc_arg_t *args)
{
types[N] = 0;
for(int i=0; ihttps://github.com/zynaddsubfx/zynaddsubfx/commit/a1abae354e826802f8b6f990cae225d6fb06b2ac
"Disable gcc optimizations for a specific function
Due to a gcc opt bug a piece of code was put in a separate function to
prevent gcc from optimizing it. Later versions of gcc inlined the
function and the bug reappeared. So now we explicitly tell gcc to not
optimize it."
Is it real a GCC bug?
[Bug c++/105996] New: reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105996 Bug ID: 105996 Summary: reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jdapena at igalia dot com Target Milestone: --- Created attachment 53150 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53150=edit Test case When creating an std::pair with a parameter that is a function pointer of the parent class (but declared as function pointer of the same class), libstdc++ implementation will try to forward the pointer, even if it is the same type (see the attached example). This code is valid in Clang and MSVC, and was valid in GCC 5.x-7.x. This has been detected through Chromium development with errors to compile https://chromium.googlesource.com/chromium/src.git/+/refs/tags/105.0.5123.1/pdf/pdf_view_web_plugin.cc#879
[Bug driver/105564] Bad error for -ftrivial-auto-var-init without a choice argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105564 --- Comment #6 from Jonathan Wakely --- Nice, thanks
[Bug target/105991] [12/13 Regression] rldicl+sldi+add generated instead of rldimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105991 Roger Sayle changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-06-16 CC||roger at nextmovesoftware dot com Keywords||patch Status|UNCONFIRMED |NEW --- Comment #1 from Roger Sayle --- The following patch appears to correct this for me on a cross-compiler to powerpcle64, but it's tricky for me to do a full bootstrap/regression test. 2022-06-16 Roger Sayle gcc/ChangeLog PR target/105991 * config/rs6000/rs6000.md (plus_xor): New code iterator. (*rotl3_insert_3_): New define_insn_and_split. diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md index c55ee7e..695ec33 100644 --- a/gcc/config/rs6000/rs6000.md +++ b/gcc/config/rs6000/rs6000.md @@ -4188,6 +4188,23 @@ } [(set_attr "type" "insert")]) +; Canonicalize the PLUS and XOR forms to IOR for rotl3_insert_3 +(define_code_iterator plus_xor [plus xor]) + +(define_insn_and_split "*rotl3_insert_3_" + [(set (match_operand:GPR 0 "gpc_reg_operand" "=r") + (plus_xor:GPR + (and:GPR (match_operand:GPR 3 "gpc_reg_operand" "0") + (match_operand:GPR 4 "const_int_operand" "n")) + (ashift:GPR (match_operand:GPR 1 "gpc_reg_operand" "r") + (match_operand:SI 2 "const_int_operand" "n"] + "INTVAL (operands[2]) == exact_log2 (UINTVAL (operands[4]) + 1)" + "#" + "&& 1" + [(set (match_dup 0) + (ior:GPR (and:GPR (match_dup 3) (match_dup 4)) +(ashift:GPR (match_dup 1) (match_dup 2]) + (define_code_iterator plus_ior_xor [plus ior xor]) (define_split
[Bug target/105992] memcmp(p, q, 7) == 0 can be optimized better on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105992 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com, ||hjl.tools at gmail dot com --- Comment #1 from Hongtao.liu --- I'm wondering would targetm.overlap_op_by_pieces_p helps here.
[Bug target/104610] memcmp () == 0 can be optimized better for avx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104610 --- Comment #19 from Hongtao.liu --- I'm wondering would targetm.overlap_op_by_pieces_p helps here.
[Bug libstdc++/105995] QoI: constexpr basic_string variable must use all of its SSO buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105995 --- Comment #2 from Jiang An --- (In reply to Andrew Pinski from comment #1) > C++20 supports dynamic allocation for constexpr. Yeah, but a constexpr variable can't hold dynamically allocated memory. Dynamically allocated memory must be deallocated within its initialization.
[Bug libstdc++/105995] QoI: constexpr basic_string variable must use all of its SSO buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105995 --- Comment #1 from Andrew Pinski --- C++20 supports dynamic allocation for constexpr.
[Bug libstdc++/105995] New: QoI: constexpr basic_string variable must use all of its SSO buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105995
Bug ID: 105995
Summary: QoI: constexpr basic_string variable must use all of
its SSO buffer
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: de34 at live dot cn
Target Milestone: ---
The current implementation in libstdc++ only supports constexpr
std::basic_string variable of static storage duration which uses all of its SSO
buffer:
#include
constexpr std::string str15{"0123456789abcde"};
// constexpr std::string str14{"0123456789abcd"}; // error: should we support
this?
// constexpr std::string str16{"0123456789abcdef"}; // error: unsupportable
constexpr std::u16string u16str7{u"0123456"};
constexpr std::u32string u32str3{U"012"};
int main()
{
// constexpr std::string strdyn{"0123456789abcde"}; // error: unsupportable
}
Compiler Explorer links:
https://gcc.godbolt.org/z/cvbY1hK3G
https://gcc.godbolt.org/z/634888Y96
I think constexpr string variable that requires heap allocation is currently
unimplementable, and constexpr string variable of dynamic storage duration
can't be supported by libstdc++-v3 without ABI breakage now.
However, should we allow shorter strings to be stored into constexpr
basic_string variables? We can do this by always fully initializing the SSO
buffer (if it's used) during constant evluation.
[Bug target/105993] [13 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 with -O -mxop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105993 --- Comment #2 from Uroš Bizjak --- Created attachment 53149 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53149=edit Patch to fix the failure The patch fixes this particular failure by using (match_dup X). In general, rtx_equal_p should be used before reload (also with register_operand). REGNO on register_operand is valid only after reload (post-reload splitters and peephole2 patterns).
[Bug driver/105564] Bad error for -ftrivial-auto-var-init without a choice argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105564 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Liška --- Resolved on master.
[Bug driver/105564] Bad error for -ftrivial-auto-var-init without a choice argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105564 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:ab66fd016d8efa250c471692f826b07e4a55e237 commit r13-1128-gab66fd016d8efa250c471692f826b07e4a55e237 Author: Martin Liska Date: Wed May 11 16:07:25 2022 +0200 opts: improve option suggestion In case where we have 2 equally good candidates like -ftrivial-auto-var-init= -Wtrivial-auto-var-init for -ftrivial-auto-var-init, we should take the candidate that has a difference in trailing sign symbol. PR driver/105564 gcc/ChangeLog: * spellcheck.cc (test_find_closest_string): Add new test. * spellcheck.h (class best_match): Prefer a difference in trailing sign symbol.
[Bug libstdc++/101482] The resolution of #32907 is too restricted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101482 --- Comment #1 from Jiang An --- Partially fixed together with bug #62187.
