[Bug tree-optimization/98845] [9/10/11/12 Regression] ICE: SSA corruption (Unable to coalesce ssa_names 2 and 23 which are marked as MUST COALESCE.) since r6-528-g465770e43996a132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98845 Arseny Solokha changed: What|Removed |Added Summary|[9/10/11 Regression] ICE: |[9/10/11/12 Regression] |SSA corruption (Unable to |ICE: SSA corruption (Unable |coalesce ssa_names 2 and 23 |to coalesce ssa_names 2 and |which are marked as MUST|23 which are marked as MUST |COALESCE.) since|COALESCE.) since |r6-528-g465770e43996a132|r6-528-g465770e43996a132 --- Comment #11 from Arseny Solokha --- It should be labeled [12 Regression] again, then, as the issue is still there on trunk.
[Bug c/104962] Compilier can not find files to link a simple MYSQL app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104962
--- Comment #2 from James Murphy ---
Created attachment 52639
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52639=edit
client1.c
/*
* client1.c
*
*
* from Paul DuBois MySQL page 225
*
*
*
*/
#include
#include
#define def_host_name "localhost"/* host to connect to */
#define def_user_name "cpp" /* user name */
#define def_password"n6532l" /* user password */
#define def_db_name NULL /* database to connect to */
MYSQL *conn;/* pointer to connect handler */
int main (int argc, char *argv[])
{
conn = mysql_init(NULL);
mysql_real_connect ( conn, /* pointer to
connection handler */
def_host_name, /* host
to connect to*/
def_user_name, /* user
name */
def_password, /* user
password */
def_db_name,/*
database to connect to*/
0,
/* port (using default) */
NULL, /*
socket (use default) */
0
/* flags (none) */
);
mysql_close(conn);
exit(0);
}
[Bug c/104962] Compilier can not find files to link a simple MYSQL app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104962 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- This is best asked on the mailing list gcc-h...@gcc.gnu.org (or maybe even the binutils mailing list since it is about ld not finding the libraries, GCC does not control the linker).
[Bug c/104962] New: Compilier can not find files to link a simple MYSQL app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104962 Bug ID: 104962 Summary: Compilier can not find files to link a simple MYSQL app Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: murphy_535 at hotmail dot com Target Milestone: --- gcc client1.c -I"C:\Program Files\MySQL\MySQL Server 8.0\include" -L"C:\Program Files\MySQL\MySQL Server 8.0\lib" -lmysqlclient client1.c is taken from a textbook. It compiles in Visual Studio 2022 with no problem once the libraries are set. I am an inexperienced user of the gcc compiler.
[Bug fortran/96983] [11/12 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #40 from CVS Commits --- The releases/gcc-11 branch has been updated by Michael Meissner : https://gcc.gnu.org/g:9baf563a176c4ea5a2a1606397ac09e16776d1ae commit r11-9665-g9baf563a176c4ea5a2a1606397ac09e16776d1ae Author: Michael Meissner Date: Wed Mar 16 21:58:54 2022 -0400 Backport PR fortran/96983 patch to GCC 11. I applied a patch on the trunk in April 22nd, 2021 that fixes an issue (PR fortran/66983) where we could fail for 128-bit floating point types because we don't have a built-in function that is equivalent to llround for 128-bit integer types. Instead, the patch does a round operation followed by conversion to the appropriate integer size if we don't have the specialized round to specific integer type built-in functions. When I checked in the change, I was told to wait until after GCC 11.1 shipped before doing the backport. I forgot about the change until recently. Before checking it in, I did bootstraps and ran regression tests on: 1) little endian power9 using 128-bit IBM long double 2) little endian power9 using 128-bit IEEE long double 3) big endian power8 (both 64-bit and 32-bit) (and) 4) x86_64 native build There were no new regressions. The test gfortran.dg/pr96711.f90 now passes on PowerPC. In the 10 months or so since the change was made on the trunk, the code in build_round_expr did not change. 2022-03-16 Michael Meissner gcc/fortran/ PR fortran/96983 * trans-intrinsic.c (build_round_expr): If int type is larger than long long, do the round and convert to the integer type. Do not try to find a floating point type the exact size of the integer type. Backport patch from 2021-04-22 on the trunk.
[Bug c/98198] [11/12 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in decl_or_type_attrs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98198 --- Comment #7 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:4565a07a646949e6ce30a08c60484afe1fed0ac1 commit r12-7681-g4565a07a646949e6ce30a08c60484afe1fed0ac1 Author: Roger Sayle Date: Wed Mar 16 23:20:34 2022 + PR c/98198: ICE-on-invalid-code error recovery. This is Christophe Lyon's fix to PR c/98198, an ICE-on-invalid-code regression affecting mainline, and a suitable testcase. Tested on x86_64-pc-linux-gnu with make bootstrap and make -k check with no new failures. Ok for mainline? 2022-03-16 Christophe Lyon Roger Sayle gcc/c-family/ChangeLog PR c/98198 * c-attribs.cc (decl_or_type_attrs): Add error_mark_node check. gcc/testsuite/ChangeLog PR c/98198 * gcc.dg/pr98198.c: New test case.
[Bug tree-optimization/101895] [11 Regression] SLP Vectorizer change pushes VEC_PERM_EXPR into bad location spoiling further optimization opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101895 --- Comment #9 from Jeffrey A. Law --- Yea, no need to backport this.
[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 Julius Werner changed: What|Removed |Added CC||jwerner at chromium dot org --- Comment #32 from Julius Werner --- I second Kees' request to please (permanently) add a flag to disable this inference and prevent GCC from making any assumptions about object sizes for pointers cast from integers. Ideally it should be a separate one-off flag rather than a level that needs to be set for a variety of individual warnings. This is affecting almost every systems programming project there is and going against 40 years of common C practice. The standard has never really specified a way to do MMIO hardware accesses, yet it's something we need to do in practice and casting integer literals to pointers is one of the main ways we do it. I don't think it's reasonable to suddenly start in 2022 to prosecute a "violation" that has been this prevalent for decades in programming practice. If you want to make these new safety checks available for those who want them that's fine, but please retain the option to stick with the existing behavior for those projects where this really causes a ton more problems than it could ever solve.
[Bug c++/82235] Copy ctor is not found for copying array of an object when it's marked explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82235 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org
[Bug rtl-optimization/104961] [9/10/11/12 Regression] compilation never (?) finishes at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104961
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2022-03-16
Priority|P3 |P2
CC||mpolacek at gcc dot gnu.org
Target Milestone|--- |9.5
Summary|compilation never (?) |[9/10/11/12 Regression]
|finishes at -Og |compilation never (?)
||finishes at -Og
Status|UNCONFIRMED |NEW
--- Comment #1 from Marek Polacek ---
Confirmed. Started with
commit 7293e3f58edb7535d826c85160b9fa6d4132ffea
Author: Vladimir Makarov
Date: Fri Mar 16 18:48:26 2018 +
re PR target/84876 (ICE on invalid code in lra_assign at
gcc/lra-assigns.c:1601 since r258504)
2018-03-16 Vladimir Makarov
PR target/84876
* lra-assigns.c (lra_split_hard_reg_for): Don't use
regno_allocno_class_array and sorted_pseudos.
* lra-constraints.c (spill_hard_reg_in_range): Ignore hard regs in
insns where regno is used.
2018-03-16 Vladimir Makarov
PR target/84876
* gcc.target/i386/pr84876.c: New test.
From-SVN: r258602
which fixed an ICE:
/home/mpolacek/q.c: In function ‘foo’:
/home/mpolacek/q.c:12:1: error: unable to find a register to spill
}
^
/home/mpolacek/q.c:12:1: error: this is the insn:
(insn 15 32 33 2 (parallel [
(set (reg/v:TI 105 [orig:91 j ] [91])
(mult:TI (zero_extend:TI (subreg/j:DI (reg/v:TI 105 [orig:91 j
] [91]) 0))
(zero_extend:TI (reg:DI 102 [ i.0_1 ]
(clobber (reg:CC 17 flags))
]) "/home/mpolacek/q.c":8 356 {*umulditi3_1}
(expr_list:REG_DEAD (reg:DI 102 [ i.0_1 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
during RTL pass: reload
/home/mpolacek/q.c:12:1: internal compiler error: in lra_split_hard_reg_for, at
lra-assigns.c:1805
unrecognized DWARF version in .debug_info at 6
0xf1752d _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0xd773ae lra_split_hard_reg_for()
../../gcc/lra-assigns.c:1805
0xd6fcb8 lra(_IO_FILE*)
../../gcc/lra.c:2507
0xd17143 do_reload
../../gcc/ira.c:5465
0xd17636 execute
../../gcc/ira.c:5649
Compiled fine with GCC 5 -> regression.
[Bug target/104957] [nvptx] Use .alias directive (available starting ptx isa version 6.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104957 --- Comment #3 from Tom de Vries --- The OvO testsuite, when run at -O2 passes, because it inlines all .alias instances. But at -O0, it doesn't. With -foffload=-malias that's fixed.
[Bug rtl-optimization/104961] New: compilation never (?) finishes at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104961 Bug ID: 104961 Summary: compilation never (?) finishes at -Og Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: compile-time-hog, memory-hog Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 52638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52638=edit reduced testcase Compiler output: $ time x86_64-pc-linux-gnu-gcc -O testcase.c -c real0m0.034s user0m0.028s sys 0m0.007s $ time x86_64-pc-linux-gnu-gcc -Og testcase.c -c ^C real2m5.070s user0m0.001s sys 0m0.000s The compilation doesn't seem to ever finish. The cc1 binary is just eating more memory over time. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7654-20220315102422-gda24fce323e-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-7654-20220315102422-gda24fce323e-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220315 (experimental) (GCC)
[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103407 --- Comment #13 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:2f26b26721d5f8a6ac874fc23e18e1b03d207990 commit r12-7679-g2f26b26721d5f8a6ac874fc23e18e1b03d207990 Author: Jonathan Wakely Date: Wed Mar 16 20:35:47 2022 + libstdc++: Fix symbol versioning for Solaris 11.3 [PR103407] The new std::from_chars implementation means that those symbols are now defined on Solaris 11.3, which lacks uselocale. They were not present in gcc-11, but the linker script gives them the GLIBCXX_3.4.29 symbol version because that is the version where they appeared for systems with uselocale. This makes the version for those symbols depend on whether uselocale is available or not, so that they get version GLIBCXX_3.4.30 on targets where they weren't defined in gcc-11. In order to avoid needing separate ABI baseline files for Solaris 11.3 and 11.4, the ABI checker program now treats the floating-point std::from_chars overloads as undesignated if they are not found in the baseline symbols file. This means they can be left out of the SOlaris baseline without causing the check-abi target to fail. libstdc++-v3/ChangeLog: PR libstdc++/103407 * config/abi/pre/gnu.ver: Make version for std::from_chars depend on HAVE_USELOCALE macro. * testsuite/util/testsuite_abi.cc (compare_symbols): Treat std::from_chars for floating-point types as undesignated if not found in the baseline symbols file.
[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #31 from Martin Sebor --- I suppose we could move this warning under level 2 until this is handled better. -Warray-bounds already has two levels with level 2 being more noisy, and it might be useful to add a level to -Wstringop-overread as well. As I mentioned in comment #25 and elsewhere, I envisioned that code would annotate these hardwired addresses somehow, ideally using an attribute like addr or the Keil compiler's at (see below), or until one is added, using a workaround like your absolute_pointer(). I realize it means work, but I believe with the attribute the gain in type safety would make it worthwhile. Is that something the kernel developers could be trained to start using? (In full disclosure, I don't expect to have the cycles to work on the attribute anytime soon.) https://www.keil.com/support/man/docs/armcc/armcc_chr1359124981140.htm
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540 --- Comment #21 from Eyal Rozenberg --- (In reply to Jonathan Wakely from comment #20) > No, but "the first non-pure, non-inline virtual function in the class" is > easy for the user to find. Well, yes, granted, that would be a huge improvement. But then, is binutils allowed to make that assumption about the ABI? ... actually, never mind. Even if it isn't, they could still write something like "The probable cause is a lack of definition of the first virtual method in the class which isn't inline nor pure-virtual".
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540 --- Comment #20 from Jonathan Wakely --- No, but "the first non-pure, non-inline virtual function in the class" is easy for the user to find.
[Bug middle-end/100775] ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with -mthumb -fzero-call-used-regs=used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775 --- Comment #8 from qinzhao at gcc dot gnu.org --- fixed in gcc11 too.
[Bug middle-end/100775] ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with -mthumb -fzero-call-used-regs=used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Qing Zhao : https://gcc.gnu.org/g:9b1faeb5bfef258780e313aa8302a43f98f3b442 commit r11-9663-g9b1faeb5bfef258780e313aa8302a43f98f3b442 Author: Qing Zhao Date: Wed Mar 16 20:18:54 2022 + middle-end/100775 - updating the reg use in exit block for -fzero-call-used-regs GCC11 backport. In the pass_zero_call_used_regs, when updating dataflow info after adding the register zeroing sequence in the epilogue of the function, we should call "df_update_exit_block_uses" to update the register use information in the exit block to include all the registers that have been zeroed. gcc/ChangeLog: PR middle-end/100775 * function.c (gen_call_used_regs_seq): Call df_update_exit_block_uses when updating df. gcc/testsuite/ChangeLog: PR middle-end/100775 * gcc.target/arm/pr100775.c: New test.
[Bug other/42540] c++ error message [vtable undefined] is unhelpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540 --- Comment #19 from Eyal Rozenberg --- (In reply to Jonathan Wakely from comment #17) Ok, have read the wiki page. > The linker could easily say that, with no changes from GCC. Is the signature, or name, of the "key function" present in compiled object files which have seen the class definition? If the answer is yes, we could just go ahead and file a bug against binutils...
[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 Kees Cook changed: What|Removed |Added CC||kees at outflux dot net --- Comment #30 from Kees Cook --- The Linux kernel is seeing more and more of these warnings and it's becoming a bit of a burden. For example: https://lore.kernel.org/linux-hardening/20220227195918.705219-1-keesc...@chromium.org Given that this is a regression in behavior, and the kernel is not alone in tripping over this (9 duplicate bugs reported here already), can this be given greater priority? Would it be possible to add an option to just disable the "constant is a NULL pointer" logic directly?
[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943 --- Comment #47 from Andrew Macleod --- Created attachment 52637 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52637=edit new patch I am working on a alternative cache for GCC 13, but along the way, I have changes to the ranger_cache::range_from_dom() routine. The original version gave up when it hit a block which had outgoing edges. The new version is smarter and basically goes back until it finds a cache entry, and then intersects all outgoing edge between the two places. It also removes the recursion , and does not SET any cache values during the lookup (making it a true query). The net effect of this is significant improvements in cache performance because its used far less, but there is more time spend doing calculations. This bootstraps and passes all regression tests. we do miss out on a few minor opportunities (30 out of 4400 in all of EVRP over the GCC source) which occur as a result of updated values not being propagated properly as the cache is no longer "full" like it was before. IN GCC 13 I will address this, but I thought you might be interested in trying this patch against this PR. In building 380 GCC source files, I see the following avg speedups evrp : -22.57% VRP2 : -5.4% thread_jumps_full : -14.16% total : -0.44% So it is not insignificant. It is likely to be most effective in large CFGs. This is *total* compile time percent speed up for the 5 most significant cases: expr.ii -2.62% lra-constraints.ii -3.75% caller-save.ii -3.98% reload.ii -4.04% optabs.ii -5.05% EVRP isolated speedups (yes, these are *percetage* speedup) expr.ii -62.38 simplify-rtx.ii -65.97 lra-constraints.ii -67.87 reload.ii trunk -68.67 caller-save.ii trunk -71.93 optabs.ii trunk -78.69 I think those times are probably worth the odd miss. Anyway, next time you are checking performance for this PR maybe also try this patch and see how it performs.
[Bug testsuite/104960] New: [12 regression] several test cases fail after r12-7670-gf6fb661ea8ac7e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104960 Bug ID: 104960 Summary: [12 regression] several test cases fail after r12-7670-gf6fb661ea8ac7e Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:f6fb661ea8ac7e17c6924719de6219f002c4efef, r12-7670-gf6fb661ea8ac7e Maybe these test cases need updating? FAIL: g++.dg/tree-ssa/pr86544.C -std=gnu++14 scan-tree-dump-times phiopt4 "if" 0 FAIL: g++.dg/tree-ssa/pr86544.C -std=gnu++17 scan-tree-dump-times phiopt4 "if" 0 FAIL: g++.dg/tree-ssa/pr86544.C -std=gnu++20 scan-tree-dump-times phiopt4 "if" 0 FAIL: g++.dg/tree-ssa/pr86544.C -std=gnu++98 scan-tree-dump-times phiopt4 "if" 0 FAIL: gcc.dg/tree-ssa/phi-opt-21.c scan-tree-dump phiopt4 "converted to straightline code" FAIL: gcc.dg/tree-ssa/popcount3.c scan-tree-dump-times phiopt4 "if" 0 FAIL: gcc.dg/tree-ssa/pr18134.c scan-tree-dump-times optimized "= a_..D. != 0" 1 FAIL: gcc.dg/tree-ssa/pr96480.c scan-tree-dump optimized " = _[0-9]* <= 3;" FAIL: gcc.dg/tree-ssa/sccp-2.c scan-tree-dump-times optimized "bb" 1 FAIL: gcc.dg/tree-ssa/ssa-hoist-4.c scan-tree-dump-times optimized "MAX_EXPR" 1 commit f6fb661ea8ac7e17c6924719de6219f002c4efef (HEAD, refs/bisect/bad) Author: Richard Biener Date: Wed Mar 16 13:39:31 2022 +0100 tree-optimization/102008 - restore if-conversion of adjacent loads
[Bug analyzer/104955] Analyzer slowdown with many diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104955 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:7fd6e36ea9aa8575841ff1da08b4aebc0298abe2 commit r12-7677-g7fd6e36ea9aa8575841ff1da08b4aebc0298abe2 Author: David Malcolm Date: Wed Mar 16 10:54:44 2022 -0400 analyzer: early rejection of disabled warnings [PR104955] Avoid generating execution paths for warnings that are ultimately rejected due to -Wno-analyzer-* flags. This improves the test case from taking at least several minutes (before I killed it) to taking under a second. This doesn't fix the slowdown seen in PR analyzer/104955 with large numbers of warnings when the warnings are still enabled. gcc/analyzer/ChangeLog: PR analyzer/104955 * diagnostic-manager.cc (get_emission_location): New. (diagnostic_manager::diagnostic_manager): Initialize m_num_disabled_diagnostics. (diagnostic_manager::add_diagnostic): Reject diagnostics that will eventually be rejected due to being disabled. (diagnostic_manager::emit_saved_diagnostics): Log the number of disabled diagnostics. (diagnostic_manager::emit_saved_diagnostic): Split out logic for determining emission location to get_emission_location. * diagnostic-manager.h (diagnostic_manager::m_num_disabled_diagnostics): New field. * engine.cc (stale_jmp_buf::get_controlling_option): New. (stale_jmp_buf::emit): Use it. * pending-diagnostic.h (pending_diagnostic::get_controlling_option): New vfunc. * region-model.cc (poisoned_value_diagnostic::get_controlling_option): New. (poisoned_value_diagnostic::emit): Use it. (shift_count_negative_diagnostic::get_controlling_option): New. (shift_count_negative_diagnostic::emit): Use it. (shift_count_overflow_diagnostic::get_controlling_option): New. (shift_count_overflow_diagnostic::emit): Use it. (dump_path_diagnostic::get_controlling_option): New. (dump_path_diagnostic::emit): Use it. (write_to_const_diagnostic::get_controlling_option): New. (write_to_const_diagnostic::emit): Use it. (write_to_string_literal_diagnostic::get_controlling_option): New. (write_to_string_literal_diagnostic::emit): Use it. * sm-file.cc (double_fclose::get_controlling_option): New. (double_fclose::emit): Use it. (file_leak::get_controlling_option): New. (file_leak::emit): Use it. * sm-malloc.cc (mismatching_deallocation::get_controlling_option): New. (mismatching_deallocation::emit): Use it. (double_free::get_controlling_option): New. (double_free::emit): Use it. (possible_null_deref::get_controlling_option): New. (possible_null_deref::emit): Use it. (possible_null_arg::get_controlling_option): New. (possible_null_arg::emit): Use it. (null_deref::get_controlling_option): New. (null_deref::emit): Use it. (null_arg::get_controlling_option): New. (null_arg::emit): Use it. (use_after_free::get_controlling_option): New. (use_after_free::emit): Use it. (malloc_leak::get_controlling_option): New. (malloc_leak::emit): Use it. (free_of_non_heap::get_controlling_option): New. (free_of_non_heap::emit): Use it. * sm-pattern-test.cc (pattern_match::get_controlling_option): New. (pattern_match::emit): Use it. * sm-sensitive.cc (exposure_through_output_file::get_controlling_option): New. (exposure_through_output_file::emit): Use it. * sm-signal.cc (signal_unsafe_call::get_controlling_option): New. (signal_unsafe_call::emit): Use it. * sm-taint.cc (tainted_array_index::get_controlling_option): New. (tainted_array_index::emit): Use it. (tainted_offset::get_controlling_option): New. (tainted_offset::emit): Use it. (tainted_size::get_controlling_option): New. (tainted_size::emit): Use it. (tainted_divisor::get_controlling_option): New. (tainted_divisor::emit): Use it. (tainted_allocation_size::get_controlling_option): New. (tainted_allocation_size::emit): Use it. gcc/testsuite/ChangeLog: * gcc.dg/analyzer/many-disabled-diagnostics.c: New test. * gcc.dg/plugin/analyzer_gil_plugin.c (gil_diagnostic::get_controlling_option): New. (double_save_thread::emit): Use it. (fncall_without_gil::emit): Likewise.
[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103407
--- Comment #12 from Jonathan Wakely ---
I tried this instead, but I think this still counts as "binding the same symbol
to different versions", and didn't work:
#if defined __sun__ && defined _GLIBCXX_HAVE_USELOCALE
#if defined(_GLIBCXX_SYMVER_SUN) && defined(_GLIBCXX_SHARED) \
&& defined(_GLIBCXX_HAVE_AS_SYMVER_DIRECTIVE)
// Solaris 11.4 supports uselocale, so std::from_chars is present since gcc-11
// with symbol version GLIBCXX_3.4.29. Solaris 11.3 does not support uselocale
// so std::from_chars is not present until gcc-12, with version GLIBCXX_3.4.30.
// Define aliases so that code linked on Solaris 11.3 runs on 11.4 too.
from_chars_result
__from_chars_compat(const char* first, const char* last,
double& value, chars_format fmt) noexcept
{ return std::from_chars(first, last, value, fmt); }
asm(".symver _ZSt19__from_chars_compatPKcS0_RdSt12chars_format,
_ZSt10from_charsPKcS0_RdSt12chars_formaT@GLIBCXX_3.4.30");
from_chars_result
__from_chars_compat(const char* first, const char* last,
long double& value, chars_format fmt) noexcept
{ return std::from_chars(first, last, value, fmt); }
asm(".symver _ZSt19__from_chars_compatPKcS0_ReSt12chars_format,
_ZSt10from_charsPKcS0_ReSt12chars_formaT@GLIBCXX_3.4.30");
from_chars_result
__from_chars_compat(const char* first, const char* last,
float& value, chars_format fmt) noexcept
{ return std::from_chars(first, last, value, fmt); }
asm(".symver _ZSt19__from_chars_compatPKcS0_RfSt12chars_format,
_ZSt10from_charsPKcS0_RfSt12chars_formaT@GLIBCXX_3.4.30");
#endif
#endif
This does get compiled, but I don't see those @GLIBCXX_3.4.30 symbols in the
DSO. Maybe I'm missing something that would make them exported as global
symbols, or maybe this just can't be done on Solaris.
[Bug c++/86974] Support Clang's require_constant_initialization attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86974 --- Comment #10 from Jakub Jelinek --- One can't take __has_cpp_attribute support for granted, so perhaps that needs to be wrapped inside ifdef.
[Bug c++/86974] Support Clang's require_constant_initialization attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86974 --- Comment #9 from Jonathan Wakely --- Oops, the second #if should be #elif
[Bug c++/86974] Support Clang's require_constant_initialization attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86974 --- Comment #8 from Jonathan Wakely --- libstdc++ sources do this: #if __has_cpp_attribute(clang::require_constant_initialization) # define __constinit [[clang::require_constant_initialization]] #endif An alternative that doesn't use reserved names and so is suitable for user code would be: #if __cpp_constinit # define CONSTINIT constinit #if __has_cpp_attribute(clang::require_constant_initialization) # define CONSTINIT [[clang::require_constant_initialization]] #elif __GNUC__ >= 10 # define CONSTINIT __constinit #else # define CONSTINIT #endif And then: CONSTINIT S2 objx;
[Bug c++/86974] Support Clang's require_constant_initialization attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86974 --- Comment #7 from Marc Mutz --- Fantastic! Thanks for the tip!
[Bug c++/86974] Support Clang's require_constant_initialization attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86974 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- GCC does support __constinit as an alternate spelling of constinit, and while constinit is only available in -std=c++20 and later, __constinit is available even in C++11.
[Bug c++/86974] Support Clang's require_constant_initialization attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86974 Marc Mutz changed: What|Removed |Added CC||marc.mutz at hotmail dot com --- Comment #5 from Marc Mutz --- Not really superseded by constinit. constinit is only available in C++20. If you want constinit, you get all of C++20. OTOH, [[clang::require_constant_initialization]] works all the way back to C++11.
[Bug tree-optimization/104959] New: nested lambda capture pack by ref will load from nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104959
Bug ID: 104959
Summary: nested lambda capture pack by ref will load from
nullptr
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andij.cr at gmail dot com
Target Milestone: ---
testcase:
#include
template
auto line = [](Ts &&...args) {
if constexpr (sizeof...(Ts) != 0) {
([&] { assert( != nullptr); }(), ...);
}
};
int main() { line<10>(false); }
compiling and executing this with
g++ 10.3 -std=c++20 -O1 -fsanitize=undefined
will trigger the assertion.
this code is a reduction of a more complex code, where the bug caused a crash.
compiling with -O0 or with GCC 11 will not trigger the assertion.
each template, lambda, if constexpr (sizeof...) seems to be necessary
to trigger the bug
the assert needs to be here to trigger the load of args
using a different method (e.g. using args in an expression)
will also trigger -Wuninitialized
compiler explorer link:
https://gcc.godbolt.org/z/W7EMTP4W8
note that in the assembly __assert_fail is called directly
this seems similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68177
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938
[Bug middle-end/104492] [12 Regression] Bogus dangling pointer warning at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104492 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #7 from Martin Sebor --- So the CLOBBER semantics correspond more closely to those of a C++ destructor than to a deallocation call. It would be helpful to document these things.
[Bug middle-end/104958] missing -Wdangling-pointer leaking local address through struct member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104958 Martin Sebor changed: What|Removed |Added Last reconfirmed||2022-03-16 Keywords||diagnostic Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Blocks||104077 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104077 [Bug 104077] bogus/missing -Wdangling-pointer
[Bug middle-end/104958] New: missing -Wdangling-pointer leaking local address through struct member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104958
Bug ID: 104958
Summary: missing -Wdangling-pointer leaking local address
through struct member
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
As discussed in
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590230.html both
functions in the following test case leak the address of the local variable to
their caller and should trigger a -Wdangling pointer but only one of them does.
The patch submitted to implement this missing functionality was deferred until
GCC 13:
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20220210/2641dce0/attachment-0003.bin
$ cat x.c && gcc -S -Wall x.c
struct S { void *p; };
void f (struct S *p)
{
int j;
p->p = // -Wdangling-pointer
}
struct S g (void)
{
int i;
struct S s = { }; // missing -Wdangling-pointer
return s;
}
x.c: In function ‘f’:
x.c:6:8: warning: storing the address of local variable ‘j’ in ‘*p.p’
[-Wdangling-pointer=]
6 | p->p = // -Wdangling-pointer
| ~^~~~
x.c:5:7: note: ‘j’ declared here
5 | int j;
| ^
x.c:5:7: note: ‘p’ declared here
[Bug target/104957] [nvptx] Use .alias directive (available starting ptx isa version 6.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104957 --- Comment #2 from Tom de Vries --- So, what do we get after specifying -malias -mptx=6.3? Alias attribute only for functions, not variables. No support for weak alias (allowing this does compile, but we run into execution fails in gcc.dg/globalalias.c and gcc.dg/pr77587.c). No support for aliases of weak functions. We can't detect this in the compiler, so we'll run into linker error "error: Function test with .weak scope cannot be aliased".
[Bug target/104957] [nvptx] Use .alias directive (available starting ptx isa version 6.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104957 --- Comment #1 from Tom de Vries --- Created attachment 52636 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52636=edit Tentative patch Patch that I'm currently working on. Adds -malias, off by default. It's off by default because when doing a build with libgomp and malias on by default, libgomp uses .alias a few times, and that ends up in a linker error "Internal error: reference to deleted section" with OvO test-cases (haven't tried others) This may be a driver error, or incorrect usage of the .alias directive. The answer might be found by playing around with .alias in cuda examples. Things I tried manually in the ptx were: - resolving the .alias: this worked - enforcing order: function definition, alias declaration, alias definition to precisely match example in ptx manual: didn't work.
[Bug tree-optimization/104941] [12 Regression] ICE error: invalid (pointer) operands ‘minus_expr’ since r12-6482-g06bc1b0c539e3a60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104941 Siddhesh Poyarekar changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Siddhesh Poyarekar --- Fixed.
[Bug tree-optimization/104941] [12 Regression] ICE error: invalid (pointer) operands ‘minus_expr’ since r12-6482-g06bc1b0c539e3a60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104941 --- Comment #2 from CVS Commits --- The master branch has been updated by Siddhesh Poyarekar : https://gcc.gnu.org/g:beb12c62eaec37ed0ee5a251ca0907d965d413b2 commit r12-7675-gbeb12c62eaec37ed0ee5a251ca0907d965d413b2 Author: Siddhesh Poyarekar Date: Wed Mar 16 20:45:47 2022 +0530 tree-optimization/104941: Actually assign the conversion result Assign the result of fold_convert to offset. Also make the useless conversion check lighter since the two way check is not needed here. gcc/ChangeLog: PR tree-optimization/104941 * tree-object-size.cc (size_for_offset): Make useless conversion check lighter and assign result of fold_convert to OFFSET. gcc/testsuite/ChangeLog: PR tree-optimization/104941 * gcc.dg/builtin-dynamic-object-size-0.c (S1, S2): New structs. (test_alloc_nested_structs, g): New functions. (main): Call test_alloc_nested_structs. Signed-off-by: Siddhesh Poyarekar
[Bug target/104957] New: [nvptx] Use .alias directive (available starting ptx isa version 6.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104957 Bug ID: 104957 Summary: [nvptx] Use .alias directive (available starting ptx isa version 6.3) Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- [ There is a number of nvptx PRs open about alias support. The focus of this PR is $subject, rather than supporting some specific source construct. ] So, we have an .alias directive in ptx, can we use it for something? Ideally, we'd use the .alias directive for all our needs, but it's too limited for that. OTOH, currently we just error out on any .alias usage in the source code, so we could try to add an implementation that only errors out for things it doesn't support.
[Bug tree-optimization/104935] [12 Regression] 554.roms_r ELF binary increased with r12-7612-g69619acd8d9b5856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104935 --- Comment #3 from Richard Biener --- So in 554.roms_r I see cases (like for mod_grid.F90:allocate_grid) where we now vectorize more V4DI stores from a CTOR of scalars which reduces code size so jump-threading now goes wild (from DOM threading), threading across the long repetition of if (div == 0) ; else ... = ... / div; if (div == 0) ; else ... = ... / div; where the vectorized blob is now smaller than the threading threshold. For extract_sta.F90 we now vectorize two more loops with low VF (high VF is not profitable) but using only strided loads (they are reductions) which has extra size cost on the scalar epilogues plus we are vectorizing conditional reductions here. It doesn't look overly bad here. There's also a TU with a size win btw, but overall we vectorize more.
[Bug c++/104956] New: ICE with -fmodules-ts unordered_set and map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104956
Bug ID: 104956
Summary: ICE with -fmodules-ts unordered_set and map
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: john2.718281828459045235360287 at gmail dot com
Target Milestone: ---
Created attachment 52635
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52635=edit
bug.ii
## SOURCE FILE
$ cat bug.cpp
#include
void f (std::unordered_set& s)
{
s.insert (nullptr);
}
#include
std::map< int, int> x;
## COMPILATION
$ g++-11 -save-temps -fmodules-ts -std=gnu++20 -c bug.cpp
g++-11: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
## VERSION
$ gcc-11 -v
Using built-in specs.
COLLECT_GCC=gcc-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.2.0-7ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --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-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Ubuntu 11.2.0-7ubuntu2)
[Bug target/104882] [12 Regression] MVE: Wrong code at -O2 since r12-1434-g046a3beb1673bf4a61c131373b6a5e84158e92bf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104882
Christophe Lyon changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2022-03-16
--- Comment #2 from Christophe Lyon ---
My understanding is that MVE's vmovn instructions do not work like Neon's.
If q0 = { 0x, 0x, 0x, 0 } ( 4x32 bits)
q1 = { 0x, 0x, 0x, 0x }
With Neon:
vmovn.i32 d4, q0 gives:
d4 = { 0x, 0x, 0x, 0 } (4x16 bits)
vmovn.i32 d5, q1 gives:
d5 = { 0x, 0x, 0x, 0x }
thus q2 = { 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0 }
But with MVE:
vmovnb.i32 q2, q0 gives:
q2 = { 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0 } (8x16 bits,
only the bottom bits of each 32 bits element are updated)
vmovnt.i32 q2, q1 then gives:
q2 = { 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0 } (only the
top bits are updated)
This means that the input should be shuffled before using MVE's vmovn[bt] to
have
q0 = { 0x, 0x, 0x, 0 }
q1 = { 0x, 0x, 0x, 0x }
since MVE's vmovn do not seem to naturally map to GCC's vec_pack_trunc
[Bug c++/104944] [9/10/11/12 Regression] incorrect alignas(void) accepted (with warning if templated)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104944 Marek Polacek changed: What|Removed |Added Target Milestone|--- |9.5 Status|NEW |ASSIGNED Priority|P3 |P2 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Mine then.
[Bug analyzer/104955] Analyzer slowdown with many diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104955 --- Comment #2 from David Malcolm --- I suspect that this issue is due to building a feasible_graph per saved diagnostic, thus leading to an O(N^2) where as the function gets bigger, each individual diagnostic requires more work. Perhaps fixable by amortizing the work, by sharing one feasible_graph for all diagnostics in the diagnostic_manager.
[Bug analyzer/104955] Analyzer slowdown with many diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104955 --- Comment #1 from David Malcolm --- Also takes a long time with -Wno-analyzer-double-free; perhaps we ought to reject saved_diagnostics that will ultimately not be emitted.
[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954 David Malcolm changed: What|Removed |Added Depends on||104955 --- Comment #5 from David Malcolm --- (In reply to David Malcolm from comment #0) > (i.e. with various -Wno-analyzer-* flags; perhaps re-enabling these will > trigger the more extreme multihour slowdown) Perhaps this related to PR analyzer/104955 also? But if so, I think it's still checking feasibility even before rejecting the diagnostic due to the -Wno-analyzer-* option flag within diagnostic.cc. If that's the case we could reject such diagnostics earlier. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104955 [Bug 104955] Analyzer slowdown with many diagnostics
[Bug analyzer/104955] New: Analyzer slowdown with many diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104955
Bug ID: 104955
Summary: Analyzer slowdown with many diagnostics
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 following artificial testcase for -fanalyzer seems to take at least several
minutes; perhaps much more:
#define DOUBLE_FREE() \
do { \
void *p = __builtin_malloc (1024); \
__builtin_free (p); \
__builtin_free (p); \
} while (0)
#define DOUBLE_FREE_x_10() \
do { \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
DOUBLE_FREE(); \
} while (0)
#define DOUBLE_FREE_x_100() \
do { \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
DOUBLE_FREE_x_10(); \
} while (0)
#define DOUBLE_FREE_x_1000()\
do { \
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
DOUBLE_FREE_x_100();\
} while (0)
void test_1 (void)
{
DOUBLE_FREE_x_1000 ();
}
Breaking into it shows that it seems to be spending the bulk of its time
exploring paths to determine if they are feasible (despite the fact that
there's no control flow at all):
(gdb) bt
#0 0x00f22750 in hash_table, ana::binding_cluster*> >::hash_entry, false,
xcallocator>::find_slot_with_hash (this=this@entry=0x7fffc768,
comparable=@0x7fffc5f8: 0x292b5c0, hash=5396152,
insert=insert@entry=INSERT) at ../../src/gcc/hash-traits.h:186
#1 0x00f1b976 in hash_map,
ana::binding_cluster*> >::put (v=, k=@0x7fffc5f8: 0x292b5c0,
this=0x7fffc768) at ../../src/gcc/hash-traits.h:162
#2 ana::store::store (this=this@entry=0x7fffc768, other=...) at
../../src/gcc/analyzer/store.cc:2046
#3 0x00eeaecf in ana::region_model::region_model
(this=this@entry=0x7fffc760, other=...) at
../../src/gcc/analyzer/region-model.cc:260
#4 0x00eccf71 in ana::feasibility_state::feasibility_state
(this=0x7fffc760, other=...) at ../../src/gcc/analyzer/engine.cc:4478
#5 0x018a51f0 in ana::epath_finder::process_worklist_item
(this=, worklist=0x7fffc950, tg=..., fg=0x7fffc8a0,
target_enode=0x2bdcf60, diag_idx=305, out_best_path=0x7fffc858) at
../../src/gcc/analyzer/feasible-graph.h:96
#6 0x018a603c in ana::epath_finder::explore_feasible_paths
(this=0x7fffcb90, target_enode=0x2bdcf60, desc=0x1a64f09 "double_free",
diag_idx=305) at ../../src/gcc/analyzer/diagnostic-manager.cc:414
#7 0x018a6787 in ana::saved_diagnostic::calc_best_epath
(this=0x2bddbf0, pf=0x7fffcb90)
at ../../src/gcc/analyzer/diagnostic-manager.cc:736
#8 0x018aaece in ana::dedupe_winners::add
(this=this@entry=0x7fffcba0, logger=0x0, pf=pf@entry=0x7fffcb90,
sd=0x2bddbf0)
at ../../src/gcc/analyzer/diagnostic-manager.cc:1065
#9 0x018a7ece in ana::diagnostic_manager::emit_saved_diagnostics
(this=0x7fffcea0, eg=...)
at ../../src/gcc/analyzer/analyzer-logging.h:150
#10 0x00ed79ab in ana::impl_run_checkers (logger=logger@entry=0x0) at
../../src/gcc/analyzer/exploded-graph.h:857
#11 0x00ed8804 in ana::run_checkers () at
../../src/gcc/analyzer/analyzer-logging.h:150
[Bug tree-optimization/104931] [9/10/11 Regression] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 --- Comment #6 from Richard Biener --- Also confirmed the issue still happens on trunk when we revert this match.pd pattern.
[Bug target/104890] [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu (--enable-cet --with-arch-32=i686)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104890 --- Comment #14 from H.J. Lu --- Fixed for GCC 12 so far.
[Bug target/104890] [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu (--enable-cet --with-arch-32=i686)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104890
--- Comment #13 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:3117ffce4c1598a35e724138735b099262353358
commit r12-7673-g3117ffce4c1598a35e724138735b099262353358
Author: H.J. Lu
Date: Sun Mar 13 08:57:51 2022 -0700
x86: Also check _SOFT_FLOAT in
Push target("general-regs-only") in if x87 is enabled.
gcc/
PR target/104890
* config/i386/x86gprintrin.h: Also check _SOFT_FLOAT before
pushing target("general-regs-only").
gcc/testsuite/
PR target/104890
* gcc.target/i386/pr104890.c: New test.
[Bug tree-optimization/94675] [9/10/11/12 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 --- Comment #22 from Richard Biener --- (In reply to Xavier from comment #21) > The problem still happens with gcc 9.4.0 but it appears to be fixed with gcc > 10. I suppose that's with the original full testcase, I still see the diagnostic on the testcase from the description.
[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954 --- Comment #4 from David Malcolm --- Created attachment 52634 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52634=edit Gzipped preprocessed source, unreduced
[Bug tree-optimization/104931] [9/10/11 Regression] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931 Richard Biener changed: What|Removed |Added Summary|wrong-code with |[9/10/11 Regression] |number_of_iterations_lt_to_ |wrong-code with |ne |number_of_iterations_lt_to_ ||ne Priority|P3 |P2 Target Milestone|--- |9.5 Known to fail||9.3.1 Known to work||7.5.0 --- Comment #5 from Richard Biener --- Verified the issue also happens with GCC 9, it doesn't happen with GCC 7.
[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954
--- Comment #3 from David Malcolm ---
I'm also seeing states with dozens of bindings for touched regions for
__UNIQUE_ID_ddebugN for various N:
clusters within :: {, region: {__UNIQUE_ID_ddebug277, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug277) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug278, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug278) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug279, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug279) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug280, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug280) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug281, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug281) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug282, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug282) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug283, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug283) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug284, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug284) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug285, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug285) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug286, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug286) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug287, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug287) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug288, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug288) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug289, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug289) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug290, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug290) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug291, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug291) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug292, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug292) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug293, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug293) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug294, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug294) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug295, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug295) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug296, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug296) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug297, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug297) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug298, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug298) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug299, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug299) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug300, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug300) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug301, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug301) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug302, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug302) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug303, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug303) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug304, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug304) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug305, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug305) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug306, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (value_4(D));, __UNIQUE_ID_ddebug306) (ESCAPED)
(TOUCHED)}, region: {__UNIQUE_ID_ddebug307, value: CONJURED(D.56070 =
bw_int_to_fixed_nonconst (
where these seem to be coming from macro expansions of debug logging like this:
static void print_bw_calcs_dceip(struct dc_context *ctx,
[Bug c++/104944] [9/10/11/12 Regression] incorrect alignas(void) accepted (with warning if templated)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104944
Jonathan Wakely changed:
What|Removed |Added
Summary|incorrect alignas(void) |[9/10/11/12 Regression]
|accepted (with warning if |incorrect alignas(void)
|templated) |accepted (with warning if
||templated)
Known to fail||12.0, 5.1.0
CC||mpolacek at gcc dot gnu.org
Known to work||4.9.4
--- Comment #2 from Jonathan Wakely ---
Before GCC 5.1 the non-template case was rejected:
104944.C:1:22: error: requested alignment is not an integer constant
struct alignas(void) S{};
^
That changed with r210262:
Author: Marek Polacek
Date: Fri May 9 09:24:37 2014
re PR c/50459 (alignof doesn't work on plain old constant, works with
expressions containing it)
[Bug tree-optimization/104931] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931
--- Comment #4 from Richard Biener ---
(In reply to Richard Biener from comment #3)
> The bug was made latent by g:51d464b608b38b9e2007948d10b1e0f1dcec142c which
> ensured that
>
> /* If the loop exits immediately, there is nothing to do. */
> tree tem = fold_binary (code, boolean_type_node, iv0->base, iv1->base);
> if (tem && integer_zerop (tem))
> {
> if (!every_iteration)
> return false;
> niter->niter = build_int_cst (unsigned_type_for (type), 0);
> niter->max = 0;
> return true;
> }
>
> triggered, folding (_2 + 4294967272) + 12 < _2 + 4294967272 to false. That's
> the following part of the revision, and it probably triggers when doing
> expand_simple_operations.
>
> diff --git a/gcc/match.pd b/gcc/match.pd
> index 84c9b918041..f5dcbf32bc7 100644
> --- a/gcc/match.pd
> +++ b/gcc/match.pd
> @@ -2143,6 +2143,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> (simplify
>(pointer_plus (pointer_plus:s @0 @1) @3)
>(pointer_plus @0 (plus @1 @3)))
> +#if GENERIC
> +(simplify
> + (pointer_plus (convert:s (pointer_plus:s @0 @1)) @3)
> + (convert:type (pointer_plus @0 (plus @1 @3
> +#endif
>
> /* Pattern match
>
> It does seem to me that niter analysis relies on statically detecting
> not rolling loops, at least for the cases we assume no overflow happens
> and we use number_of_iterations_lt_to_ne. I can't convince myself that
> only INTEGER_CST appearant negative delta are problematic for
> pointer types (which we always assume to have no overflow), but that would
> be the most simplistic solution here. Still "negative" delta values should
> be problematic for all cases, and since we only restrict us to constant
> modulo, delta can also be non-constant.
I verified backporting the above fixes the issue. That's really the patch
I'm most comfortable with at this point ... :/
[Bug c++/104944] incorrect alignas(void) accepted (with warning if templated)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104944
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-03-16
Status|UNCONFIRMED |NEW
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=85979
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
(In reply to Björn Fahller from comment #0)
> The erroneous code:
>
> struct alignas(void) S{};
>
> Is accepted without any diagnostic with g++
> (Compiler-Explorer-Build-gcc-98cd717fca9f21625b9c79c9231c2e909d1d93a3-
> binutils-2.36.1) 12.0.1 20220306 (experimental)
>
> https://godbolt.org/z/q7das4G1W
Confirmed.
> With 'void' coming from a template, a confusing warning is issued:
>
> template
> struct alignas(T) S {};
>
> S s;
>
> The message is:
>
> In instantiation of 'struct S':
> :4:9: required from here
> :2:16: warning: invalid application of '__alignof__' to a void type
> [-Wpointer-arith]
> 2 | struct alignas(T) S {};
> |^
This is accepted with a warning (rather than an error) because of the
https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html extension.
> This is not entirely incorrect, but I believe most programmers would
> recognize that they have no `__alignof__` in their code, nor any pointer
> arithmetics.
That's PR 85979.
[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954
David Malcolm changed:
What|Removed |Added
Depends on||104943
--- Comment #2 from David Malcolm ---
Part of the slowdown may relate to PR analyzer/104943: "perf" shows lots of
time spent traversing state objects, and I'm seeing huge numbers of temporaries
that aren't getting purged. The state bindings show dozens of "region:
{, value: UNKNOWN(struct bw_fixed)}") presumably relating to struct
temporaries.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104943
[Bug 104943] Analyzer fails to purge state for local structs
[Bug c/104948] When '&&' present in a comparison, a warning should be generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104948 --- Comment #12 from Jonathan Wakely --- Yes, to be more precise: && produces an int (not a _Bool / bool) with value 0 or 1. _Bool (a.k.a bool) is a distinct type, which might be larger or smaller than int (the only actual requirement is "large enough to store the values 0 and 1"). The name 'bool' is currently just a macro for _Bool defined in but C23 might change it to a proper keyword: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2934.pdf
[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954 --- Comment #1 from Richard Biener --- Does not enabling sanitizer improve things?
[Bug analyzer/104954] New: Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954 Bug ID: 104954 Summary: Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c 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: --- According to my notes, attempting to build a Linux kernel with -fanalyzer, I found that building: drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c was taking over 15 hours; I think this was with a debug build of cc1. On testing this with trunk this week, I saw it take about 31 minutes on a debug build, and about 4 minutes on a release build. Am attaching preprocessed source. Compilation flags in use the 4 minute build (with release build of cc1): ./xgcc -B. -fanalyzer -S ../../src/dce_calcs.i -nostdinc -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -fno-jump-tables -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong -Wimplicit-fallthrough=5 -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-stack-clash-protection -g -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -fno-inline-functions-called-once -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -fanalyzer -Wno-analyzer-null-dereference -Wno-analyzer-use-of-uninitialized-value -Wno-array-bounds -Wno-analyzer-null-argument -Wno-analyzer-shift-count-overflow -Wno-analyzer-use-of-pointer-in-stale-stack-frame -Wno-analyzer-shift-count-negative -Wno-analyzer-write-to-const -Wno-use-after-free -fsanitize=kernel-address -fasan-shadow-offset=0xdc00 --param asan-globals=1 --param asan-instrumentation-with-call-threshold=1 --param asan-instrument-allocas=1 --param asan-stack=1 (i.e. with various -Wno-analyzer-* flags; perhaps re-enabling these will trigger the more extreme multihour slowdown)
[Bug rtl-optimization/68274] __builtin_unreachable pessimizes code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68274 Bug 68274 depends on bug 102008, which changed state. Bug 102008 Summary: [12 Regression] no cmov generated for loads next to each other https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102008 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/102008] [12 Regression] no cmov generated for loads next to each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102008 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Richard Biener --- Fixed.
[Bug rtl-optimization/102008] [12 Regression] no cmov generated for loads next to each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102008 --- Comment #9 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f6fb661ea8ac7e17c6924719de6219f002c4efef commit r12-7670-gf6fb661ea8ac7e17c6924719de6219f002c4efef Author: Richard Biener Date: Wed Mar 16 13:39:31 2022 +0100 tree-optimization/102008 - restore if-conversion of adjacent loads The following re-orders the newly added code sinking pass before the last phiopt pass which performs hoisting of adjacent loads with the intent to enable if-conversion on those. I've added the aarch64 specific testcase from the PR. 2022-03-16 Richard Biener PR tree-optimization/102008 * passes.def: Move the added code sinking pass before the preceeding phiopt pass. * gcc.target/aarch64/pr102008.c: New testcase.
[Bug c/104948] When '&&' present in a comparison, a warning should be generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104948 --- Comment #11 from Andreas Schwab --- The size of bool is target dependent (though only Darwin/ppc overrides it).
[Bug c/104948] When '&&' present in a comparison, a warning should be generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104948 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #9) > (In reply to dagelf from comment #8) > > Makes perfect sense now. && is "logical" in that it can only produce a bool, > > which in C is an int and anything except 0 or 1 is evaluated to false at > > compile time. > > No, in C bool is a distinct data type, and sizeof(bool) == 1. _Bool, that is. bool is when stdbool.h is included a define to _Bool. Though, && result is int in C, not _Bool, while in C++ bool.
[Bug rtl-optimization/102008] [12 Regression] no cmov generated for loads next to each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102008 --- Comment #8 from Richard Biener --- (In reply to Jakub Jelinek from comment #7) > Ok. Though, perhaps indeed trying to detect what phiopt optimizes and not > sinking that case would be long term best, so that we don't do the ping pong. Or, since the phiopt case is specifically for if-conversion (IIRC), only do this in the very last phiopt pass before RTL expansion and/or perform the if-conversion at the GIMPLE level via a COND_EXPR, thus actually do the if-conversion.
[Bug d/104953] [12 regression] Several gdc and libphobos tests FAIL on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104953 Rainer Orth changed: What|Removed |Added Target Milestone|--- |12.0
[Bug d/104953] New: [12 regression] Several gdc and libphobos tests FAIL on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104953
Bug ID: 104953
Summary: [12 regression] Several gdc and libphobos tests FAIL
on Solaris
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Target: *-*-solaris2.11
The recent dmd/druntime/phobos v2.099.0 import caused quite a number of
regressions on Solaris, sparc and x86, 32 and 64-bit:
+FAIL: gdc.test/compilable/dtorfields_deprecation.d output-exists
dtorfields_deprecation.s
compilable/dtorfields_deprecation.d:30:5: error: 'pure' constructor
'dtorfields_deprecation.Pure.this' cannot call impure destructor
'dtorfields_deprecation.Pure.~this'
compilable/dtorfields_deprecation.d:27:1: note: generated 'Pure.~this' is
impure because of the following field's destructors:
compilable/dtorfields_deprecation.d:29:13: note: - HasDtor member
compilable/dtorfields_deprecation.d:24:5: note:impure 'HasDtor.~this' is
declared here
compilable/dtorfields_deprecation.d:42:5: error: '@nogc' constructor
'dtorfields_deprecation.NoGC.this' cannot call non-@nogc destructor
'dtorfields_deprecation.NoGC.~this'
compilable/dtorfields_deprecation.d:39:1: note: generated 'NoGC.~this' is
non-@nogc because of the following field's destructors:
compilable/dtorfields_deprecation.d:41:13: note: - HasDtor member
compilable/dtorfields_deprecation.d:24:5: note:non-@nogc 'HasDtor.~this' is
declared here
compilable/dtorfields_deprecation.d:48:5: error: '@safe' constructor
'dtorfields_deprecation.Safe.this' cannot call '@system' destructor
'dtorfields_deprecation.Safe.~this'
compilable/dtorfields_deprecation.d:45:1: note:
'dtorfields_deprecation.Safe.~this' is declared here
compilable/dtorfields_deprecation.d:45:1: note: generated 'Safe.~this' is
@system because of the following field's destructors:
compilable/dtorfields_deprecation.d:47:13: note: - HasDtor member
compilable/dtorfields_deprecation.d:24:5: note:@system 'HasDtor.~this' is
declared here
+FAIL: gdc.test/compilable/test9565.d output-exists test9565.s
compilable/test9565.d:6:47: error: slice '[0..15]' exceeds array bounds
'[0..8]'
compilable/test9565.d:6:46: note: called from here: '__equals(s[0..m.length],
m)'
compilable/test9565.d:62:49: note: called from here: 'startsWith("arr[252]",
"arr[cast(ulong)")'
compilable/test9565.d:62:17: note: while evaluating: 'static
assert(startsWith("arr[252]", "arr[cast(ulong)"))'
compilable/test9565.d:6:47: error: slice '[0..15]' exceeds array bounds
'[0..8]'
compilable/test9565.d:6:46: note: called from here: '__equals(s[0..m.length],
m)'
compilable/test9565.d:68:45: note: called from here: 'startsWith("arr[252]",
"arr[cast(ulong)")'
compilable/test9565.d:68:13: note: while evaluating: 'static
assert(startsWith("arr[252]", "arr[cast(ulong)"))'
+UNRESOLVED: gdc.test/runnable/constfold.d compilation failed to produce
executable
+UNRESOLVED: gdc.test/runnable/constfold.d -shared-libphobos compilation
failed to produce executable
runnable/constfold.d:21:1: error: static assert: '127 == -1' is false
32 and 64-bit sparc and x86
+FAIL: libphobos.exceptions/assert_fail.d (test for excess errors)
+UNRESOLVED: libphobos.exceptions/assert_fail.d compilation failed to produce
executable
Excess errors:
/vol/gcc/src/hg/master/local/libphobos/testsuite/libphobos.exceptions/assert_fail.d:16:
error: uncaught CTFE exception
'core.exception.AssertError("Mismatch!\nExpected: <-128 != 127>\nActual: <128
!= 127>")'
/vol/gcc/src/hg/master/local/libphobos/testsuite/libphobos.exceptions/assert_fail.d:576:
note: called from here: 'main()'
+FAIL: libphobos.phobos/std/algorithm/searching.d execution test
core.exception.AssertError@/vol/gcc/src/hg/master/local/libphobos/testsuite/../src/std/algorithm/searching.d(1824):
Assertion failure
+FAIL: libphobos.phobos/std/bitmanip.d execution test
core.exception.AssertError@/vol/gcc/src/hg/master/local/libphobos/testsuite/../src/std/bitmanip.d(2910):
unittest failure
+FAIL: libphobos.phobos/std/conv.d (test for excess errors)
+UNRESOLVED: libphobos.phobos/std/conv.d compilation failed to produce
executable
Excess errors:
/vol/gcc/src/hg/master/local/libphobos/testsuite/../src/std/conv.d:1552: error:
static assert: "minimum value of T must be smaller than 0"
/vol/gcc/src/hg/master/local/libphobos/testsuite/../src/std/conv.d:224: note:
instantiated from here: 'toImpl!(byte, int)'
/vol/gcc/src/hg/master/local/libphobos/testsuite/../src/std/conv.d:268: note:
instantiated from here: 'to!int'
+FAIL: libphobos.phobos/std/format/internal/write.d (test for excess errors)
+UNRESOLVED: libphobos.phobos/std/format/internal/write.d compilation failed to
produce executable
Excess errors:
/vol/gcc/src/hg/master/local/libphobos/src/std/exception.d:518: error: uncaught
CTFE
[Bug c/104948] When '&&' present in a comparison, a warning should be generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104948
--- Comment #9 from Jonathan Wakely ---
(In reply to dagelf from comment #8)
> Makes perfect sense now. && is "logical" in that it can only produce a bool,
> which in C is an int and anything except 0 or 1 is evaluated to false at
> compile time.
No, in C bool is a distinct data type, and sizeof(bool) == 1.
Values of that type other than 0 or 1 result in undefined behaviour.
>
> There was a time when 'logical' and 'bitwise' were used interchangeably,
> based on the fact that 'boolean operators' work on 'boolean logic'.
>
> This is what lead me here:
>
> $ cat test.c
> int f(int a) {
> if ((a && 12) == 12 )
This will never be true.
The result of (a && 12) is either 0 or 1, and so never equal to 12.
> return 11;
> return 10;
> }
>
> $ gcc -c -O0 test.c && objdump -d test1.o
> test1.o: file format elf64-x86-64
> Disassembly of section .text:
> :
>0: 55 push %rbp
>1: 48 89 e5mov%rsp,%rbp
>4: 89 7d fcmov%edi,-0x4(%rbp)
>7: b8 00 00 00 00 mov$0xa,%eax
>c: 5d pop%rbp
>d: c3 retq
>
> With a single `&` it works as expected.
Your expectation is wrong.
>
> In my defence, when I last did a C course all boolean operators were
> bitwise.
I doubt that is true.
> I suddenly feel really old that even C has changed. Even the
> definition of 'logical' and 'bitwise' has changed.
I don't think that's true either.
> Compare to "warning: comparison of constant ‘12’ with non-bitwise boolean
> expression is always false [-Wbool-compare]" might lead to less confusion.
It would confuse people who know C, because "non-bitwise boolean expression" is
meaningless.
> When expecting the result of an '&&' evaluation to be a bitwise AND,
Your expectation is simply wrong, that's not how C works. We can't write
diagnostics to suit every potential misunderstanding of how C works.
The warning text is accurate and correct.
[Bug tree-optimization/104931] wrong-code with number_of_iterations_lt_to_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931
--- Comment #3 from Richard Biener ---
The bug was made latent by g:51d464b608b38b9e2007948d10b1e0f1dcec142c which
ensured that
/* If the loop exits immediately, there is nothing to do. */
tree tem = fold_binary (code, boolean_type_node, iv0->base, iv1->base);
if (tem && integer_zerop (tem))
{
if (!every_iteration)
return false;
niter->niter = build_int_cst (unsigned_type_for (type), 0);
niter->max = 0;
return true;
}
triggered, folding (_2 + 4294967272) + 12 < _2 + 4294967272 to false. That's
the following part of the revision, and it probably triggers when doing
expand_simple_operations.
diff --git a/gcc/match.pd b/gcc/match.pd
index 84c9b918041..f5dcbf32bc7 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2143,6 +2143,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(simplify
(pointer_plus (pointer_plus:s @0 @1) @3)
(pointer_plus @0 (plus @1 @3)))
+#if GENERIC
+(simplify
+ (pointer_plus (convert:s (pointer_plus:s @0 @1)) @3)
+ (convert:type (pointer_plus @0 (plus @1 @3
+#endif
/* Pattern match
It does seem to me that niter analysis relies on statically detecting
not rolling loops, at least for the cases we assume no overflow happens
and we use number_of_iterations_lt_to_ne. I can't convince myself that
only INTEGER_CST appearant negative delta are problematic for
pointer types (which we always assume to have no overflow), but that would
be the most simplistic solution here. Still "negative" delta values should
be problematic for all cases, and since we only restrict us to constant
modulo, delta can also be non-constant.
[Bug c++/96780] debuginfo for std::move and std::forward isn't useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780 --- Comment #16 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:e55c5e24b97ad8ddc44588da18e894c139e02c0a commit r12-7668-ge55c5e24b97ad8ddc44588da18e894c139e02c0a Author: Patrick Palka Date: Wed Mar 16 08:25:54 2022 -0400 c++: fold calls to std::move/forward [PR96780] A well-formed call to std::move/forward is equivalent to a cast, but the former being a function call means the compiler generates debug info, which persists even after the call gets inlined, for an operation that's never interesting to debug. This patch addresses this problem by folding calls to std::move/forward and other cast-like functions into simple casts as part of the frontend's general expression folding routine. This behavior is controlled by a new flag -ffold-simple-inlines, and otherwise by -fno-inline, so that users can enable this folding with -O0 (which implies -fno-inline). After this patch with -O2 and a non-checking compiler, debug info size for some testcases from range-v3 and cmcstl2 decreases by as much as ~10% and overall compile time and memory usage decreases by ~2%. PR c++/96780 gcc/ChangeLog: * doc/invoke.texi (C++ Dialect Options): Document -ffold-simple-inlines. gcc/c-family/ChangeLog: * c.opt: Add -ffold-simple-inlines. gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fold) : Fold calls to std::move/forward and other cast-like functions into simple casts. gcc/testsuite/ChangeLog: * g++.dg/opt/pr96780.C: New test.
[Bug c++/104765] Expression statement with a return in a lambda-parameter-default causes segfault when called in a different function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104765
--- Comment #6 from Aaron Ballman ---
(In reply to Marek Polacek from comment #4)
> My preference: prohibit any use of ({}) in default arguments.
That's my preference as well assuming it doesn't break a significant amount of
code (which I have no reason to believe it will).
[Bug target/104952] New: [nvptx][OpenMP] wrong code with OR / AND reduction ('reduction(||:' and '&&') with SIMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
Bug ID: 104952
Summary: [nvptx][OpenMP] wrong code with OR / AND reduction
('reduction(||:' and '&&') with SIMT
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, vries at gcc dot gnu.org
Target Milestone: ---
Target: nvptx-none
* Works when compiled with -O0
* Fails when compiled with -O1 → "result" is 0 instead of 1.
Observations:
* Issue occurs with '||' and '&&' – and for char/short/int/long.
* Note: -O1 implies that omp_max_vf() returns != 1
Thus, only with -O1 there is SIMT, which seems to cause the problem.
* When replacing 'reduction(||:' by
'reduction(|:' the code passes.
Regarding the latter: Given that the order is not determined (i.e. 'a || b'
and 'b || a' can occur), I think '||' can always be replaced by '|' in the
reduction.
@jakub: ^ does this make sense?
* * *
Long testcase is tests/5.0/loop/test_loop_reduction_or_device.c from
https://github.com/SOLLVE/sollve_vv/
[the ..._and_... ('&&') testcase fails in the same way.] — Short testcase is
below.
Short testcase (runs into abort with -O1, works with -O0 or with
"reduction:(|"):
* * *
int main () {
char arr[100];
int result = 0;
for (int i = 0; i < 100; ++i)
arr[i] = 0;
arr[5] = 1;
#pragma omp target parallel map(tofrom:arr,result)
#pragma omp loop reduction(||: result)
for (int i = 0; i < 100; ++i)
result = result || arr[i];
if (result != 1)
__builtin_abort ();
return 0;
}
[Bug c/104948] When '&&' present in a comparison, a warning should be generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104948
--- Comment #8 from dagelf ---
Makes perfect sense now. && is "logical" in that it can only produce a bool,
which in C is an int and anything except 0 or 1 is evaluated to false at
compile time.
There was a time when 'logical' and 'bitwise' were used interchangeably, based
on the fact that 'boolean operators' work on 'boolean logic'.
This is what lead me here:
$ cat test.c
int f(int a) {
if ((a && 12) == 12 )
return 11;
return 10;
}
$ gcc -c -O0 test.c && objdump -d test1.o
test1.o: file format elf64-x86-64
Disassembly of section .text:
:
0: 55 push %rbp
1: 48 89 e5mov%rsp,%rbp
4: 89 7d fcmov%edi,-0x4(%rbp)
7: b8 00 00 00 00 mov$0xa,%eax
c: 5d pop%rbp
d: c3 retq
With a single `&` it works as expected.
In my defence, when I last did a C course all boolean operators were bitwise. I
suddenly feel really old that even C has changed. Even the definition of
'logical' and 'bitwise' has changed.
Apologies for not testing the obvious '-Wall'.
Also apologies for just skimming over the output of icc, clang and msvc... I
just noticed that they include jumps where gcc didn't, so I was mistaken.
The optimizations are impressive.
Still, searching for the issues logged here with '&&' in an evaluation, does
point to the fact that the error message could be improved. Might I recommend
'non-bitwise boolean' in the message instead of just 'boolean'. Or even better,
add '(did you mean bitwise AND & instead of &&) if that's present.
$ gcc -Wall -c -O0 test.c
test1.c: In function ‘f’:
test1.c:5:22: warning: comparison of constant ‘12’ with boolean expression is
always false (Did you mean & instead of &&?) [-Wbool-compare]
Compare to "warning: comparison of constant ‘12’ with non-bitwise boolean
expression is always false [-Wbool-compare]" might lead to less confusion.
When expecting the result of an '&&' evaluation to be a bitwise AND, this
distinction can make a world of difference and could've pointed at least me in
the right direction.
[Bug tree-optimization/94675] [9/10/11/12 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 --- Comment #21 from Xavier --- The problem still happens with gcc 9.4.0 but it appears to be fixed with gcc 10.
[Bug tree-optimization/104942] [12 Regression] ICE in size_for_offset, at tree-object-size.cc:352 since r12-6482-g06bc1b0c539e3a60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104942 Siddhesh Poyarekar changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Siddhesh Poyarekar --- Fixed.
[Bug tree-optimization/104942] [12 Regression] ICE in size_for_offset, at tree-object-size.cc:352 since r12-6482-g06bc1b0c539e3a60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104942 --- Comment #1 from CVS Commits --- The master branch has been updated by Siddhesh Poyarekar : https://gcc.gnu.org/g:818e305ea692ebc6578fb40881887d45382f876b commit r12-7667-g818e305ea692ebc6578fb40881887d45382f876b Author: Siddhesh Poyarekar Date: Wed Mar 16 16:10:51 2022 +0530 tree-optimization/104942: Retain sizetype conversions till the end Retain the sizetype alloc_object_size to guarantee the assertion in size_for_offset and to avoid adding a conversion there. nop conversions are eliminated at the end anyway in dynamic object size computation. gcc/ChangeLog: PR tree-optimization/104942 * tree-object-size.cc (alloc_object_size): Remove STRIP_NOPS. gcc/testsuite/ChangeLog: PR tree-optimization/104942 * gcc.dg/builtin-dynamic-object-size-0.c (alloc_func_long, test_builtin_malloc_long): New functions. (main): Use it. Signed-off-by: Siddhesh Poyarekar
[Bug rtl-optimization/102008] [12 Regression] no cmov generated for loads next to each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102008 --- Comment #7 from Jakub Jelinek --- Ok. Though, perhaps indeed trying to detect what phiopt optimizes and not sinking that case would be long term best, so that we don't do the ping pong.
[Bug rtl-optimization/102008] [12 Regression] no cmov generated for loads next to each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102008 --- Comment #6 from Richard Biener --- (In reply to Jakub Jelinek from comment #5) > Wouldn't at least now simply disabling the "optimization" in the last sink > pass instance be safer? I don't see how that's easily done. Not sinking any loads would be as intrusive as doing pass-reordering, adding code to detect exactly the "two adjacent loads split into two places" would be quite elaborate.
[Bug target/104910] [10/11 Regression] ICE: internal consistency failure (error: invalid rtl sharing found in the insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104910 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] ICE: |[10/11 Regression] ICE: |internal consistency|internal consistency |failure (error: invalid rtl |failure (error: invalid rtl |sharing found in the insn) |sharing found in the insn) --- Comment #3 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/104910] [10/11/12 Regression] ICE: internal consistency failure (error: invalid rtl sharing found in the insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104910 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:952155629ca1a4dfe7c7b26e53d118a9b853ed4a commit r12-7666-g952155629ca1a4dfe7c7b26e53d118a9b853ed4a Author: Jakub Jelinek Date: Wed Mar 16 11:04:16 2022 +0100 aarch64: Fix up RTL sharing bug in aarch64_load_symref_appropriately [PR104910] We unshare all RTL created during expansion, but when aarch64_load_symref_appropriately is called after expansion like in the following testcases, we use imm in both HIGH and LO_SUM operands. If imm is some RTL that shouldn't be shared like a non-sharable CONST, we get at least with --enable-checking=rtl a checking ICE, otherwise might just get silently wrong code. The following patch fixes that by copying it if it can't be shared. 2022-03-16 Jakub Jelinek PR target/104910 * config/aarch64/aarch64.cc (aarch64_load_symref_appropriately): Copy imm rtx. * gcc.dg/pr104910.c: New test.
[Bug rtl-optimization/102008] [12 Regression] no cmov generated for loads next to each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102008 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Wouldn't at least now simply disabling the "optimization" in the last sink pass instance be safer?
[Bug rtl-optimization/102008] [12 Regression] no cmov generated for loads next to each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102008 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Richard Biener --- I'm going to test the re-scheduling now.
[Bug rtl-optimization/104950] GCC does not emit branchless code for load next to each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104950
--- Comment #6 from Hongtao.liu ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Hongtao.liu from comment #4)
> > (In reply to Richard Biener from comment #3)
> > > Ah, on aarch64 we get
> > >
> > > cmp w0, 0
> > > add x0, x1, 4
> > > cselx0, x0, x1, eq
> > > ldr w0, [x0]
> > >
> > > so we do not load from the possibly trapping mem. With the testcase I
> > > provided and -fno-tree-sink on x86_64 we get
> >
> > Not for this one
> >
> > float
> > foo (float a, float b, float *c, int i, int j)
> > {
> > return a > b ? c[i] : c[j];
> > }
>
> That one is recorded as PR
Just note -fno-tree-sink works for PR102008, but not for this case.
[Bug target/104453] [9/10 Regression] ICE: SIGSEGV in handled_component_p with truncated input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104453 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to work||10.3.1, 9.4.1 Known to fail|10.3.1, 9.4.1 |10.3.0, 9.4.0 --- Comment #7 from Richard Biener --- Fixed.
[Bug target/104453] [9/10 Regression] ICE: SIGSEGV in handled_component_p with truncated input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104453 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Biener : https://gcc.gnu.org/g:48fde80dea1fd59db34d0723427c41d0fb1ad951 commit r9-9985-g48fde80dea1fd59db34d0723427c41d0fb1ad951 Author: Richard Biener Date: Wed Feb 9 08:48:35 2022 +0100 target/104453 - guard call folding with NULL LHS This guards shift builtin folding to do nothing when there is no LHS, similar to what other foldings do. 2022-02-09 Richard Biener PR target/104453 * config/i386/i386.c (ix86_gimple_fold_builtin): Guard shift folding for NULL LHS. * gcc.target/i386/pr104453.c: New testcase. (cherry picked from commit 1c827873ed283df282f2df11dfe0ff607e07dab3)
[Bug c++/104734] -isystem hides -Woverloaded-virtual warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104734 Jonathan Wakely changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0
[Bug libstdc++/90388] Disabled hash specialization should not be invocable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90388 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely --- Fixed since 10.1
[Bug c++/104951] avx512fintrin.h(9146): error: identifier "__builtin_ia32_rndscaless_round" is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104951 --- Comment #2 from Andrew Pinski --- https://github.com/scale-snu/ckks-gpu-core/issues/1 https://stackoverflow.com/questions/60824242/suddenly-getting-builtin-ia32-sqrtsd-round-is-undefined-with-nvcc-gcc I think this is a bug in PaddlePaddle build system.
[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103743 --- Comment #5 from Jiu Fu Guo --- It would be also ok for the constant that only has 16bits in the middle: e.g. 0x09876000ULL, we can rotate the constant to 0x9876.
[Bug c++/104951] avx512fintrin.h(9146): error: identifier "__builtin_ia32_rndscaless_round" is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104951 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- That is not a diagnostic from GCC, most likely it comes from nvcc. That means it isn't a GCC bug but either nvcc or user's fault in using gcc intrinsics headers with a compiler that isn't able to deal with those.
[Bug libstdc++/102425] std::error_code() does not compare equal to std::error_condition()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102425 Jonathan Wakely changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #10 from Jonathan Wakely --- *** Bug 90370 has been marked as a duplicate of this bug. ***
[Bug libstdc++/90370] Does 0 correspond to a POSIX errno value for std::system_category?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90370 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #6 from Jonathan Wakely --- This was re-reported as PR 102425 and the C++ working draft has been clarified by https://wg21.link/lwg3598 *** This bug has been marked as a duplicate of bug 102425 ***
[Bug c++/104951] New: avx512fintrin.h(9146): error: identifier "__builtin_ia32_rndscaless_round" is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104951 Bug ID: 104951 Summary: avx512fintrin.h(9146): error: identifier "__builtin_ia32_rndscaless_round" is undefined Product: gcc Version: 9.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tansheng at spacesoftwares dot com Target Milestone: --- Compiler ERROR, I was trying to compile paddlepaddle (both v2.2 and 2.1) with gcc9.4.0, the following log give all the process and information. It seems this is a problem from the compiler, not from the definitions or flags of the project. - Basic information: 1）PaddlePaddle2.2.2 2）CPU：i5-11400H 3）GPU：NVIDIA GeForce RTX 3050 Laptop GPU, cuda_11.4.3_470.82.01_linux, cudnn-11.4-linux-x64-v8.2.4.15 4）system environment AsusLaptop TUF Gaming (FX506HCB) + Ubuntu20.04 + Python3.8.10 - GCC + make log: https://paddle-inference.readthedocs.io/en/latest/user_guides/source_compile.html#ubuntu-18-04 (1) down load and configure git clone https://github.com/PaddlePaddle/Paddle.git cd Paddle git checkout release/2.2 mkdir build_cuda && cd build_cuda cmake .. -DPY_VERSION=3 -DWITH_TESTING=OFF -DWITH_MKL=ON -DWITH_GPU=ON -DON_INFER=ON .. (2) make make -j12 [ 0%] Built target extern_gflags [ 1%] Built target extern_zlib [ 1%] Built target extern_lapack [ 1%] Built target extern_utf8proc [ 1%] Built target extern_warpctc [ 1%] Built target extern_dlpack [ 1%] Built target extern_boost [ 2%] Built target extern_threadpool [ 3%] Built target extern_eigen3 [ 3%] copy_if_different /home/mc/ocr/Paddle/build_cuda/paddle/fluid/operators/jit/kernels.h [ 3%] Built target copy_kernels_command [ 3%] copy_if_different /home/mc/ocr/Paddle/build_cuda/paddle/fluid/inference/api/paddle_inference_pass.h [ 3%] copy_if_different /home/mc/ocr/Paddle/build_cuda/paddle/fluid/pybind/pybind.h [ 3%] Built target download_externalError [ 3%] Built target extern_xbyak [ 3%] Built target extern_gloo [ 3%] Built target copy_paddle_inference_pass_command [ 3%] Built target copy_pybind_command [ 3%] Built target extern_cryptopp [ 3%] Built target extern_pocketfft [ 3%] Built target extern_protobuf [ 3%] Built target extern_pybind [ 4%] Built target extern_mkldnn [ 4%] Built target profiler_py_proto_init [ 4%] Built target extern_glog [ 4%] Built target extern_mklml Consolidate compiler generated dependencies of target heter_service_proto Consolidate compiler generated dependencies of target error_codes_proto [ 4%] Built target framework_py_proto_init Consolidate compiler generated dependencies of target data_feed_proto Consolidate compiler generated dependencies of target framework_proto Consolidate compiler generated dependencies of target external_error_proto Copy generated python proto into directory paddle/fluid/proto/profiler. [ 4%] Built target mkldnn_cmd [ 4%] Built target trainer_py_proto [ 5%] Built target distributed_strategy_py_proto [ 5%] Built target pass_desc_py_proto Consolidate compiler generated dependencies of target cudnn_workspace_helper Consolidate compiler generated dependencies of target mkldnn [ 5%] Built target mkldnn [ 5%] Built target profiler_py_proto [ 5%] Built target fleet_proto_init Consolidate compiler generated dependencies of target monitor Consolidate compiler generated dependencies of target version Consolidate compiler generated dependencies of target denormal Consolidate compiler generated dependencies of target shape_range_info_proto [ 5%] Built target cudnn_workspace_helper [ 5%] Built target version [ 5%] Built target denormal [ 5%] Built target error_codes_proto [ 5%] Built target heter_service_proto [ 5%] Built target framework_proto [ 5%] Built target data_feed_proto [ 5%] Built target external_error_proto Copy generated python proto into directory paddle/fluid/proto. [ 5%] Built target shape_range_info_proto Consolidate compiler generated dependencies of target timer Consolidate compiler generated dependencies of target pass_desc_proto [ 5%] Built target pass_desc_proto Consolidate compiler generated dependencies of target flags Consolidate compiler generated dependencies of target string_array Consolidate compiler generated dependencies of target op_def_proto [ 5%] Built target op_def_proto [ 5%] Built target monitor [ 5%] Built target timer Consolidate compiler generated dependencies of target zero_copy_tensor_dummy [ 6%] Built target zero_copy_tensor_dummy Consolidate compiler generated dependencies of target profiler_proto [ 6%] Built target profiler_proto Consolidate compiler generated dependencies of target trainer_desc_proto [ 6%] Built target trainer_desc_proto Consolidate compiler generated dependencies of target errors Consolidate compiler generated dependencies of target op_version_proto [ 6%] Built target errors [ 6%] Built target op_version_proto Consolidate
[Bug libstdc++/90233] std::hash()(INFINITY) == std::hash()(0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90233 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98781 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||ABI Last reconfirmed||2022-03-16
[Bug libstdc++/104945] std::hash ignores the top 32 bits when size_t is 32 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104945 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-03-16 Keywords||ABI See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98781 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug c/104948] When '&&' present in a comparison, a warning should be generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104948 --- Comment #7 from Jonathan Wakely --- Until you clear up your confusion, please stop leaving completely incorrect comments all over bugzilla.
[Bug rtl-optimization/104950] GCC does not emit branchless code for load next to each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104950
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=102008
--- Comment #5 from Andrew Pinski ---
(In reply to Hongtao.liu from comment #4)
> (In reply to Richard Biener from comment #3)
> > Ah, on aarch64 we get
> >
> > cmp w0, 0
> > add x0, x1, 4
> > cselx0, x0, x1, eq
> > ldr w0, [x0]
> >
> > so we do not load from the possibly trapping mem. With the testcase I
> > provided and -fno-tree-sink on x86_64 we get
>
> Not for this one
>
> float
> foo (float a, float b, float *c, int i, int j)
> {
> return a > b ? c[i] : c[j];
> }
That one is recorded as PR
[Bug rtl-optimization/104950] GCC does not emit branchless code for load next to each other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104950
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #4 from Hongtao.liu ---
(In reply to Richard Biener from comment #3)
> Ah, on aarch64 we get
>
> cmp w0, 0
> add x0, x1, 4
> cselx0, x0, x1, eq
> ldr w0, [x0]
>
> so we do not load from the possibly trapping mem. With the testcase I
> provided and -fno-tree-sink on x86_64 we get
Not for this one
float
foo (float a, float b, float *c, int i, int j)
{
return a > b ? c[i] : c[j];
}
gcc
vcomiss xmm0, xmm1
jbe .L6
movsx rsi, esi
vmovss xmm0, DWORD PTR [rdi+rsi*4]
ret
.L6:
movsx rdx, edx
vmovss xmm0, DWORD PTR [rdi+rdx*4]
ret
llvm
vucomissxmm0, xmm1
cmovbe esi, edx
movsxd rax, esi
vmovss xmm0, dword ptr [rdi + 4*rax]
ret
