[rs6000 PATCH] PR target/105991: Recognize PLUS and XOR forms of rldimi.
This patch addresses PR target/105991 where a change to prefer representing
shifts and adds at the tree-level as multiplications, causes problems for
the rldimi patterns in the powerpc backend. The issue is that rs6000.md
models this pattern using IOR, and some variants that have the equivalent
PLUS or XOR in the RTL fail to match some *rotl4_insert patterns.
This is fixed in this patch by adding a define_insn_and_split to locally
canonicalize the PLUS and XOR forms to the backend's preferred IOR form.
An alternative fix might be for the RTL optimizers to define a canonical
form for these plus_xor_ior equivalent expressions, but the logical
choice might be plus (which may appear in an addressing mode), and such
a change may require a number of tweaks to update various backends
(i.e. a more intrusive change than the one proposed here).
Many thanks for Marek Polacek for bootstrapping and regression testing
this change without problems. Hopefully the new testcase is portable
across powerpc's effective-targets. Ok for mainline?
2022-06-17 Roger Sayle
Marek Polacek
gcc/ChangeLog
PR target/105991
* config/rs6000/rs6000.md (plus_xor): New code iterator.
(*rotl3_insert_3_): New define_insn_and_split.
gcc/testsuite/ChangeLog
PR target/105991
* gcc.target/powerpc/pr105991.c: New test case.
Thanks in advance,
Roger
--
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index c55ee7e..695ec33 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -4188,6 +4188,23 @@
}
[(set_attr "type" "insert")])
+; Canonicalize the PLUS and XOR forms to IOR for rotl3_insert_3
+(define_code_iterator plus_xor [plus xor])
+
+(define_insn_and_split "*rotl3_insert_3_"
+ [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
+ (plus_xor:GPR
+ (and:GPR (match_operand:GPR 3 "gpc_reg_operand" "0")
+ (match_operand:GPR 4 "const_int_operand" "n"))
+ (ashift:GPR (match_operand:GPR 1 "gpc_reg_operand" "r")
+ (match_operand:SI 2 "const_int_operand" "n"]
+ "INTVAL (operands[2]) == exact_log2 (UINTVAL (operands[4]) + 1)"
+ "#"
+ "&& 1"
+ [(set (match_dup 0)
+ (ior:GPR (and:GPR (match_dup 3) (match_dup 4))
+(ashift:GPR (match_dup 1) (match_dup 2])
+
(define_code_iterator plus_ior_xor [plus ior xor])
(define_split
diff --git a/gcc/testsuite/gcc.target/powerpc/pr105991.c
b/gcc/testsuite/gcc.target/powerpc/pr105991.c
new file mode 100644
index 000..e853e53
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr105991.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+unsigned long long
+foo (unsigned long long value)
+{
+ value &= 0x;
+ value |= value << 32;
+ return value;
+}
+/* { dg-final { scan-assembler "rldimi" } } */
+
[Bug tree-optimization/106010] New: Miss vectorization for complex type copy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106010
Bug ID: 106010
Summary: Miss vectorization for complex type copy.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
This is from PR105923
void
foo (_Complex double *p, _Complex double* q)
{
for (int i = 0; i != 10; i++)
p[i] = q[i];
}
gcc generates
foo(double _Complex*, double _Complex*):
xor eax, eax
.L2:
vmovsd xmm1, QWORD PTR [rsi+rax]
vmovsd xmm0, QWORD PTR [rsi+8+rax]
vmovsd QWORD PTR [rdi+rax], xmm1
vmovsd QWORD PTR [rdi+8+rax], xmm0
add rax, 16
cmp rax, 160
jne .L2
ret
llvm generates:
foo(double _Complex*, double _Complex*): #
@foo(double _Complex*, double _Complex*)
xor eax, eax
.LBB0_1:# =>This Inner Loop Header: Depth=1
movups xmm0, xmmword ptr [rsi + rax]
movups xmmword ptr [rdi + rax], xmm0
add rax, 16
cmp rax, 160
jne .LBB0_1
ret
vectorizer failed because get_related_vectype_for_scalar_type failed for
complex type.
[Bug c++/106009] [modules] internal compiler error: in mark_by_value, at cp/module.cc:4775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106009 --- Comment #1 from John Smith --- Created attachment 53159 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53159=edit preprocessed with -save-temps
[Bug c++/106009] New: [modules] internal compiler error: in mark_by_value, at cp/module.cc:4775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106009 Bug ID: 106009 Summary: [modules] internal compiler error: in mark_by_value, at cp/module.cc:4775 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: overlord624 at gmail dot com Target Milestone: --- Created attachment 53158 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53158=edit output with -freport-bug Trying to compile the spdlog library to a header unit causes an internal compiler error. Adding -save-temps to the parameters causes the same error, but the compiler claims the error is non-reproducible. No errors occur when the same header is included in the global module fragment of a regular module. $ g++-exp -freport-bug -fmodules-ts -std=c++20 -Wall -Wextra -pedantic -DSPDLOG_COMPILED_LIB -x c++-system-header spdlog/spdlog.h /usr/include/spdlog/spdlog.h: internal compiler error: in mark_by_value, at cp/module.cc:4775 0x7112a2 trees_out::mark_by_value(tree_node*) /media/extra/sources/gcc/gcc/cp/module.cc:4775 0xabe961 trees_out::mark_declaration(tree_node*, bool) /media/extra/sources/gcc/gcc/cp/module.cc:12245 0xabebd9 trees_out::mark_class_def(tree_node*) /media/extra/sources/gcc/gcc/cp/module.cc:11744 0xac859d depset::hash::find_dependencies(module_state*) /media/extra/sources/gcc/gcc/cp/module.cc:13126 0xac8cc0 module_state::write_begin(elf_out*, cpp_reader*, module_state_config&, unsigned int&) /media/extra/sources/gcc/gcc/cp/module.cc:17640 0xac9f84 finish_module_processing(cpp_reader*) /media/extra/sources/gcc/gcc/cp/module.cc:19962 0xa58c85 c_parse_final_cleanups() /media/extra/sources/gcc/gcc/cp/decl2.cc:5156 0xc7ab60 c_common_parse_file() /media/extra/sources/gcc/gcc/c-family/c-opts.cc:1253 Please submit a full bug report, with preprocessed source. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Preprocessed source stored into /tmp/cc4TWK1u.out file, please attach this to your bugreport. $ g++-exp -v Using built-in specs. COLLECT_GCC=g++-exp COLLECT_LTO_WRAPPER=/media/extra/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /media/extra/sources/gcc/configure --host=x86_64-pc-linux-gnu --prefix=/media/extra --disable-multilib --enable-threads --enable-tls --enable-languages=c,c++ --disable-nls Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20220616 (experimental) (GCC)
[Bug middle-end/106008] [11/12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106008 H.J. Lu changed: What|Removed |Added Version|12.0|11.2.1 Summary|[12 Regression] warning:|[11/12 Regression] warning: |‘(((char *)loadcmds.113_68 |‘(((char *)loadcmds.113_68 |+ _933 +|+ _933 + |16))[329406144173384849].ma |16))[329406144173384849].ma |pend’ may be used |pend’ may be used |uninitialized |uninitialized |[-Wmaybe-uninitialized] |[-Wmaybe-uninitialized] --- Comment #2 from H.J. Lu --- GCC 11 has the same issue.
[r13-1139 Regression] FAIL: 21_strings/basic_string/cons/char/105995.cc (test for excess errors) on Linux/x86_64
On Linux/x86_64,
98a0d72a610a87e8e383d366e50253ddcc9a51dd is the first bad commit
commit 98a0d72a610a87e8e383d366e50253ddcc9a51dd
Author: Jonathan Wakely
Date: Thu Jun 16 14:57:32 2022 +0100
libstdc++: Support constexpr global std::string for size < 15 [PR105995]
caused
FAIL: 21_strings/basic_string/cons/char/105995.cc (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r13-1139/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=21_strings/basic_string/cons/char/105995.cc
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=21_strings/basic_string/cons/char/105995.cc
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=21_strings/basic_string/cons/char/105995.cc
--target_board='unix{-m64}'"
$ cd {build_dir}/x86_64-linux/libstdc++-v3/testsuite && make check
RUNTESTFLAGS="conformance.exp=21_strings/basic_string/cons/char/105995.cc
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at skpgkp2 at gmail dot com)
[Bug tree-optimization/95821] Failure to optimize strchr to use memchr for string constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95821 --- Comment #4 from H.J. Lu --- Created attachment 53157 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53157=edit A patch
Re: [RFC] Warnings for cases where int promotion is unexpected and may cause bugs
Apologies, I didn't realize that my mail client doesn't
auto-wrap. Please find a wrapped copy of my original message below my
signature.
-Ani
On Thu, Jun 16, 2022, at 9:11 PM, Aniruddh Agarwal wrote:
> Hello,
>
> A colleague patched a prod-critical bug today caused by an overlooked
> implicit int promotion when adding uint8_t's. g++ (v12.1) doesn't
> report any warnings for it with all combinations of warnings flags that
> I've tried, so I thought I'd ask if:
>
> - there *is* already some combination of warning flags that *would*
> report a warning for this code
>
> - if not, then if there's any interest in work (which of course I'd be
> happy to contribute to) on detecting and flagging this sort of problem.
>
> A (much simplified) example which illustrates the bug:
> #+BEGIN_SRC cpp
> #include
>
> using std::uint8_t;
>
> bool foo(uint8_t a, uint8_t b, uint8_t c) {
> return (a + b) == c;
> }
> #+END_SRC
>
> Here's the problem: the expectation here is that "a + b" will have type
> uint8_t. So, for example it expects "foo(200, 200, 144)" to return
> "true".
>
> In reality, "a + b" implicitly promotes to an "int" and so we end up
> comparing 400 and 144, which returns false.
>
> (Side note, not immediately relevant: I'm not sure if this ends up
> being equivalent to calling something like a "bool operator==(int,
> uint8_t)" or if the RHS is also implicitly promoted to an int before
> the comparison. This is irrelevant for the immediate example because
> the end result is the same in either case, but I would appreciate it if
> someone can shed light on what the standard has to say on this for
> future reference.)
>
> A correct implementation of the expected behavior is instead therefore:
> #+BEGIN_SRC cpp
> #include
>
> using std::uint8_t;
>
> bool foo(uint8_t a, uint8_t b, uint8_t c) {
> return static_cast(a + b) == c;
> }
> #+END_SRC
>
> Does anyone else find this very surprising, and as I asked above, does
> it seem worthwhile to try to flag code like in the first snippet? I
> don't know what gcc's general policy on trying to warn about code like
> this is. The new theoretical warning would be in the spirit of
> -Wconversion.
>
> -Ani
[RFC] Warnings for cases where int promotion is unexpected and may cause bugs
Hello,
A colleague patched a prod-critical bug today caused by an overlooked implicit
int promotion when adding uint8_t's. g++ (v12.1) doesn't report any warnings
for it with all combinations of warnings flags that I've tried, so I thought
I'd ask if:
- there *is* already some combination of warning flags that *would* report a
warning for this code
- if not, then if there's any interest in work (which of course I'd be happy to
contribute to) on detecting and flagging this sort of problem.
A (much simplified) example which illustrates the bug:
#+BEGIN_SRC cpp
#include
using std::uint8_t;
bool foo(uint8_t a, uint8_t b, uint8_t c) {
return (a + b) == c;
}
#+END_SRC
Here's the problem: the expectation here is that "a + b" will have type
uint8_t. So, for example it expects "foo(200, 200, 144)" to return "true".
In reality, "a + b" implicitly promotes to an "int" and so we end up comparing
400 and 144, which returns false.
(Side note, not immediately relevant: I'm not sure if this ends up being
equivalent to calling something like a "bool operator==(int, uint8_t)" or if
the RHS is also implicitly promoted to an int before the comparison. This is
irrelevant for the immediate example because the end result is the same in
either case, but I would appreciate it if someone can shed light on what the
standard has to say on this for future reference.)
A correct implementation of the expected behavior is instead therefore:
#+BEGIN_SRC cpp
#include
using std::uint8_t;
bool foo(uint8_t a, uint8_t b, uint8_t c) {
return static_cast(a + b) == c;
}
#+END_SRC
Does anyone else find this very surprising, and as I asked above, does it seem
worthwhile to try to flag code like in the first snippet? I don't know what
gcc's general policy on trying to warn about code like this is. The new
theoretical warning would be in the spirit of -Wconversion.
-Ani
[PATCH] libgompd: Fix sizes in OMPD support and add local ICVs finctions.
libgomp/ChangeLog
2022-06-17 Mohamed Atef
* ompd-helper.h (DEREFERENCE, ACCESS_VALUE): New macros.
(gompd_get_proc_bind): Change the returned value from ompd_word_t
to const char *.
(gompd_get_max_task_priority): Fix format.
(gompd_stringize_gompd_enabled): Removed.
(gompd_get_gompd_enabled): New function prototype.
* ompd-helper.c (gompd_get_affinity_format): Call CHECK_RET.
Fix format in gompd_enabled GET_VALUE.
(gompd_stringize_gompd_enabled): Removed.
(gompd_get_nthread, gompd_get_thread_limit, gompd_get_run_sched,
gompd_get_run_sched_chunk_size, gompd_get_default_device,
gompd_get_dynamic, gompd_get_max_active_levels, gompd_get_proc_bind,
gompd_is_final,
gompd_is_implicit, gompd_get_team_size): New functions.
(gompd_get_gompd_enabled): Change the returned value from
ompd_word_t to const char *.
* ompd-init.c (ompd_process_initialize): Use sizeof_short instead of
sizeof_long_long in GET_VALUE argument.
* ompd-support.h: Change type from __UINT64_TYPE__ to unsigned short.
(GOMPD_FOREACH_ACCESS): Add entries for gomp_task kind
and final_task and gomp_team nthreads.
* ompd-support.c (gompd_get_offset, gompd_get_sizeof_member,
gompd_get_size, OMPD_SECTION): Define.
(gompd_access_gomp_thread_handle,
gompd_sizeof_gomp_thread_handle): New variables.
(gompd_state): Change type from __UNIT64_TYPE__ to
unsigned short.
(gompd_load): Remove gompd_init_access, gompd_init_sizeof_members,
gompd_init_sizes, gompd_access_gomp_thread_handle,
gompd_sizeof_gomp_thread_handle.
* ompd-icv.c (ompd_get_icv_from_scope): Add thread_handle,
task_handle and parallel_handle. Fix format in ashandle definition.
Call gompd_get_nthread, gompd_get_thread_limit, gomp_get_run_shed,
gompd_get_run_sched_chunk_size, gompd_get_default_device,
gompd_get_dynamic, gompd_get_max_active_levels, gompd_get_proc_bind,
gompd_is_final,
gompd_is_implicit,
and gompd_get_team_size.
(ompd_get_icv_string_from_scope): Fix format in ashandle definition.
Add task_handle. Call gompd_get_gompd_enabled, and
gompd_get_proc_bind. Remove the call to
gompd_stringize_gompd_enabled.
diff --git a/libgomp/ompd-helper.c b/libgomp/ompd-helper.c
index a488ba7df2e..9762b48dff8 100644
--- a/libgomp/ompd-helper.c
+++ b/libgomp/ompd-helper.c
@@ -116,6 +116,7 @@ gompd_get_affinity_format (ompd_address_space_handle_t *ah,
const char **string)
char *temp_str;
ompd_word_t addr;
ret = callbacks->alloc_memory (len + 1, (void **) _str);
+ CHECK_RET (ret);
temp_str[len] = '\0';
ompd_address_t symbol_addr = {OMPD_SEGMENT_UNSPECIFIED, 0};
ret = callbacks->symbol_addr_lookup (ah->context, NULL,
@@ -237,7 +238,7 @@ gompd_get_gompd_enabled (ompd_address_space_handle_t *ah,
const char **string)
ompd_rc_t ret;
ompd_address_t symbol_addr = {OMPD_SEGMENT_UNSPECIFIED, 0};
GET_VALUE (ah->context, NULL, "gompd_enabled", temp, temp,
- target_sizes.sizeof_int, 1, ret, symbol_addr);
+target_sizes.sizeof_int, 1, ret, symbol_addr);
static const char *temp_string = "disabled";
if (temp == 1)
temp_string = "enabled";
@@ -246,15 +247,363 @@ gompd_get_gompd_enabled (ompd_address_space_handle_t
*ah, const char **string)
*string = temp_string;
return ret;
}
+/* End of global ICVs functions. */
+/* Get per thread ICVs. */
ompd_rc_t
-gompd_stringize_gompd_enabled (ompd_address_space_handle_t *ah,
- const char **string)
+gompd_get_nthread (ompd_thread_handle_t *thread_handle,
+ ompd_word_t *nthreads_var)
{
- return gompd_get_gompd_enabled (ah, string);
+ /* gomp_thread->task->gomp_task_icv.nthreads_var. */
+ if (thread_handle == NULL)
+return ompd_rc_stale_handle;
+ if (nthreads_var == NULL)
+return ompd_rc_bad_input;
+ CHECK (thread_handle->ah);
+
+ ompd_word_t res = 0;
+ ompd_address_t symbol_addr = thread_handle->th;
+ ompd_word_t temp_offset;
+ ompd_address_t temp_sym_addr;
+ ompd_addr_t temp_addr;
+ ompd_address_space_context_t *context = thread_handle->ah->context;
+ ompd_thread_context_t *t_context = thread_handle->thread_context;
+ ompd_rc_t ret;
+ /* gomp_thread->task. */
+ ACCESS_VALUE (context, t_context, "gompd_access_gomp_thread_task",
+ temp_offset, 1, ret, symbol_addr, temp_sym_addr, temp_addr);
+ /* gomp_thread->task->task_icv. */
+ ACCESS_VALUE (context, t_context, "gompd_access_gomp_task_icv", temp_offset,
+ 1, ret, symbol_addr, temp_sym_addr, temp_addr);
+ /* gomp_thread->task->task_icv.nthreads_var. */
+ ACCESS_VALUE (context, t_context, "gompd_access_gomp_task_icv_nthreads_var",
+ temp_offset, 0, ret, symbol_addr, temp_sym_addr, temp_addr);
+ DEREFERENCE (context, t_context, symbol_addr, target_sizes.sizeof_long_long,
+ 1, res, ret, 0);
+ *nthreads_var = res;
+ return ompd_rc_ok;
}
-/* End of global ICVs functions. */
+ompd_rc_t
+gompd_get_default_device (ompd_thread_handle_t *thread_handle,
+ ompd_word_t *default_device_var)
+{
+ /*
gcc-10-20220616 is now available
Snapshot gcc-10-20220616 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20220616/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision 20ece449e06f2d0dd0c50db0203d13b4e4ff2d96 You'll find: gcc-10-20220616.tar.xz Complete GCC SHA256=908afcde078b1e6ba5355044cbff6e5c9de54ea5059a34e070805b58d4650a73 SHA1=b64b4262e78e0cf81354fb86f5ce07bc7ca360e9 Diffs from 10-20220609 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug middle-end/106008] [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106008
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-06-16
--- Comment #1 from H.J. Lu ---
Simply change the cost of integer store makes the warnings to go away:
diff --git a/gcc/config/i386/x86-tune-costs.h
b/gcc/config/i386/x86-tune-costs.h
index 6c9066c84cc..b83bb79c065 100644
--- a/gcc/config/i386/x86-tune-costs.h
+++ b/gcc/config/i386/x86-tune-costs.h
@@ -3276,7 +3276,11 @@ struct processor_costs generic_cost = {
{6, 6, 6}, /* cost of loading integer registers
in QImode, HImode and SImode.
Relative to reg-reg move (2). */
+#if 0
{6, 6, 6}, /* cost of storing integer registers */
+#else
+ {8, 8, 8}, /* cost of storing integer registers */
+#endif
{6, 6, 6, 10, 15}, /* cost of loading SSE register
in 32bit, 64bit, 128bit, 256bit and 512bit */
{6, 6, 6, 10, 15}, /* cost of storing SSE register
[committed] gimple-ssa-warn-access.cc: add missing auto_diagnostic_group
Whilst working on SARIF output I noticed some places where followup notes
weren't being properly associated with their warnings in
gcc/gimple-ssa-warn-access.cc.
Fixed thusly.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1147-g6ab98d8b58fe4d.
gcc/ChangeLog:
* gimple-ssa-warn-access.cc (warn_string_no_nul): Add
auto_diagnostic_group to group any warning with its note.
(maybe_warn_for_bound): Likewise.
(check_access): Likewise.
(warn_dealloc_offset): Likewise.
(pass_waccess::maybe_warn_memmodel): Likewise.
(pass_waccess::maybe_check_dealloc_call): Likewise.
(pass_waccess::warn_invalid_pointer): Likewise.
(pass_waccess::check_dangling_stores): Likewise.
Signed-off-by: David Malcolm
---
gcc/gimple-ssa-warn-access.cc | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
index 00f65858b0c..eb9297a2bb2 100644
--- a/gcc/gimple-ssa-warn-access.cc
+++ b/gcc/gimple-ssa-warn-access.cc
@@ -160,6 +160,8 @@ warn_string_no_nul (location_t loc, GimpleOrTree expr,
const char *fname,
(unsigned long long) bndrng[1].to_uhwi ());
}
+ auto_diagnostic_group d;
+
const tree maxobjsize = max_object_size ();
const wide_int maxsiz = wi::to_wide (maxobjsize);
if (expr)
@@ -718,6 +720,7 @@ maybe_warn_for_bound (opt_code opt, location_t loc,
GimpleOrTree exp, tree func,
maybe = false;
}
+ auto_diagnostic_group d;
if (tree_int_cst_lt (maxobjsize, bndrng[0]))
{
if (bndrng[0] == bndrng[1])
@@ -1387,6 +1390,7 @@ check_access (GimpleOrTree exp, tree dstwrite,
&& warning_suppressed_p (pad->dst.ref, opt)))
return false;
+ auto_diagnostic_group d;
location_t loc = get_location (exp);
bool warned = false;
if (dstwrite == slen && at_least_one)
@@ -1505,6 +1509,7 @@ check_access (GimpleOrTree exp, tree dstwrite,
const bool read
= mode == access_read_only || mode == access_read_write;
const bool maybe = pad && pad->dst.parmarray;
+ auto_diagnostic_group d;
if (warn_for_access (loc, func, exp, opt, range, slen, false, read,
maybe))
{
@@ -2019,6 +2024,7 @@ warn_dealloc_offset (location_t loc, gimple *call, const
access_ref )
(long long)aref.offrng[1].to_shwi ());
}
+ auto_diagnostic_group d;
if (!warning_at (loc, OPT_Wfree_nonheap_object,
"%qD called on pointer %qE with nonzero offset%s",
dealloc_decl, aref.ref, offstr))
@@ -2902,6 +2908,7 @@ pass_waccess::maybe_warn_memmodel (gimple *stmt, tree
ord_sucs,
if (!is_valid)
{
bool warned = false;
+ auto_diagnostic_group d;
if (const char *modname = memmodel_name (sucs))
warned = warning_at (loc, OPT_Winvalid_memory_model,
"invalid memory model %qs for %qD",
@@ -2935,6 +2942,7 @@ pass_waccess::maybe_warn_memmodel (gimple *stmt, tree
ord_sucs,
{
/* If both memory model arguments are valid but their combination
is not, use their names in the warning. */
+ auto_diagnostic_group d;
if (!warning_at (loc, OPT_Winvalid_memory_model,
"invalid failure memory model %qs for %qD",
failname, fndecl))
@@ -2955,6 +2963,7 @@ pass_waccess::maybe_warn_memmodel (gimple *stmt, tree
ord_sucs,
{
/* If both memory model arguments are valid but their combination
is not, use their names in the warning. */
+ auto_diagnostic_group d;
if (!warning_at (loc, OPT_Winvalid_memory_model,
"failure memory model %qs cannot be stronger "
"than success memory model %qs for %qD",
@@ -3684,13 +3693,16 @@ pass_waccess::maybe_check_dealloc_call (gcall *call)
if (DECL_P (ref) || EXPR_P (ref))
{
/* Diagnose freeing a declared object. */
- if (aref.ref_declared ()
- && warning_at (loc, OPT_Wfree_nonheap_object,
-"%qD called on unallocated object %qD",
-dealloc_decl, ref))
+ if (aref.ref_declared ())
{
- inform (get_location (ref), "declared here");
- return;
+ auto_diagnostic_group d;
+ if (warning_at (loc, OPT_Wfree_nonheap_object,
+ "%qD called on unallocated object %qD",
+ dealloc_decl, ref))
+ {
+ inform (get_location (ref), "declared here");
+ return;
+ }
}
/* Diagnose freeing a pointer that includes a positive offset.
@@ -3702,6 +3714,7 @@ pass_waccess::maybe_check_dealloc_call (gcall *call)
}
else if (CONSTANT_CLASS_P (ref))
{
+
[committed] c-decl: fix "inform" grouping and conditionalization
Whilst working on SARIF output I noticed some places where followup notes
weren't being properly associated with their errors/warnings in c-decl.cc.
Whilst fixing those I noticed some places where we "inform" after a
"warning" without checking that the warning was actually emitted.
Fixed the various issues seen in gcc/c/c-decl.cc thusly.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1146-gd3e0da54c16e53.
gcc/c/ChangeLog:
* c-decl.cc (implicitly_declare): Add auto_diagnostic_group to
group the warning with any note.
(warn_about_goto): Likewise to group error or warning with note.
Bail out if the warning wasn't emitted, to avoid emitting orphan
notes.
(lookup_label_for_goto): Add auto_diagnostic_group to
group the error with the note.
(check_earlier_gotos): Likewise.
(c_check_switch_jump_warnings): Likewise for any error/warning.
Conditionalize emission of the notes.
(diagnose_uninitialized_cst_member): Likewise for warning,
conditionalizing emission of the note.
(grokdeclarator): Add auto_diagnostic_group to group the "array
type has incomplete element type" error with any note.
(parser_xref_tag): Add auto_diagnostic_group to group warnings
with their notes. Conditionalize emission of notes.
(start_struct): Add auto_diagnostic_group to group the
"redefinition of" errors with any note.
(start_enum): Likewise for "redeclaration of %" error.
(check_for_loop_decls): Likewise for pre-C99 error.
Signed-off-by: David Malcolm
---
gcc/c/c-decl.cc | 65 -
1 file changed, 42 insertions(+), 23 deletions(-)
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 5266a61b859..ae8990c138f 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -3697,6 +3697,7 @@ implicitly_declare (location_t loc, tree functionid)
(TREE_TYPE (decl)));
if (!comptypes (newtype, TREE_TYPE (decl)))
{
+ auto_diagnostic_group d;
bool warned = warning_at (loc,
OPT_Wbuiltin_declaration_mismatch,
"incompatible implicit "
@@ -3890,12 +3891,14 @@ lookup_label (tree name)
static void
warn_about_goto (location_t goto_loc, tree label, tree decl)
{
+ auto_diagnostic_group d;
if (variably_modified_type_p (TREE_TYPE (decl), NULL_TREE))
error_at (goto_loc,
"jump into scope of identifier with variably modified type");
else
-warning_at (goto_loc, OPT_Wjump_misses_init,
- "jump skips variable initialization");
+if (!warning_at (goto_loc, OPT_Wjump_misses_init,
+"jump skips variable initialization"))
+ return;
inform (DECL_SOURCE_LOCATION (label), "label %qD defined here", label);
inform (DECL_SOURCE_LOCATION (decl), "%qD declared here", decl);
}
@@ -3950,6 +3953,7 @@ lookup_label_for_goto (location_t loc, tree name)
if (label_vars->label_bindings.left_stmt_expr)
{
+ auto_diagnostic_group d;
error_at (loc, "jump into statement expression");
inform (DECL_SOURCE_LOCATION (label), "label %qD defined here", label);
}
@@ -4040,6 +4044,7 @@ check_earlier_gotos (tree label, struct c_label_vars*
label_vars)
if (g->goto_bindings.stmt_exprs > 0)
{
+ auto_diagnostic_group d;
error_at (g->loc, "jump into statement expression");
inform (DECL_SOURCE_LOCATION (label), "label %qD defined here",
label);
@@ -4159,19 +4164,26 @@ c_check_switch_jump_warnings (struct c_spot_bindings
*switch_bindings,
{
if (decl_jump_unsafe (b->decl))
{
+ auto_diagnostic_group d;
+ bool emitted;
if (variably_modified_type_p (TREE_TYPE (b->decl), NULL_TREE))
{
saw_error = true;
error_at (case_loc,
("switch jumps into scope of identifier with "
"variably modified type"));
+ emitted = true;
}
else
- warning_at (case_loc, OPT_Wjump_misses_init,
- "switch jumps over variable initialization");
- inform (switch_loc, "switch starts here");
- inform (DECL_SOURCE_LOCATION (b->decl), "%qD declared here",
- b->decl);
+ emitted
+ = warning_at (case_loc, OPT_Wjump_misses_init,
+ "switch jumps over variable initialization");
+ if (emitted)
+ {
+ inform (switch_loc, "switch starts here");
+ inform (DECL_SOURCE_LOCATION (b->decl), "%qD declared here",
+
[committed] analyzer: associate -Wanalyzer-va-arg-type-mismatch with CWE-686
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1145-gf0da5f0a316131.
gcc/analyzer/ChangeLog:
* varargs.cc (va_arg_type_mismatch::emit): Associate the warning
with CWE-686 ("Function Call With Incorrect Argument Type").
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/stdarg-1.c
(__analyzer_called_by_test_type_mismatch_1): Verify that
-Wanalyzer-va-arg-type-mismatch is associated with CWE-686.
Signed-off-by: David Malcolm
---
gcc/analyzer/varargs.cc | 13 -
gcc/testsuite/gcc.dg/analyzer/stdarg-1.c | 2 +-
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/gcc/analyzer/varargs.cc b/gcc/analyzer/varargs.cc
index 3baba7988c1..c92a56dd2f9 100644
--- a/gcc/analyzer/varargs.cc
+++ b/gcc/analyzer/varargs.cc
@@ -857,12 +857,15 @@ public:
bool emit (rich_location *rich_loc) final override
{
auto_diagnostic_group d;
+diagnostic_metadata m;
+/* "CWE-686: Function Call With Incorrect Argument Type". */
+m.add_cwe (686);
bool warned
- = warning_at (rich_loc, get_controlling_option (),
- "% expected %qT but received %qT"
- " for variadic argument %i of %qE",
- m_expected_type, m_actual_type,
- get_variadic_index_for_diagnostic (), m_va_list_tree);
+ = warning_meta (rich_loc, m, get_controlling_option (),
+ "% expected %qT but received %qT"
+ " for variadic argument %i of %qE",
+ m_expected_type, m_actual_type,
+ get_variadic_index_for_diagnostic (), m_va_list_tree);
return warned;
}
diff --git a/gcc/testsuite/gcc.dg/analyzer/stdarg-1.c
b/gcc/testsuite/gcc.dg/analyzer/stdarg-1.c
index 41935f74cc3..f23d28c5b89 100644
--- a/gcc/testsuite/gcc.dg/analyzer/stdarg-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/stdarg-1.c
@@ -195,7 +195,7 @@ __analyzer_called_by_test_type_mismatch_1 (int placeholder,
...)
__builtin_va_list ap;
__builtin_va_start (ap, placeholder);
- i = __builtin_va_arg (ap, int); /* { dg-warning "'va_arg' expected 'int' but
received '\[^\n\r\]*' for variadic argument 1 of 'ap'" } */
+ i = __builtin_va_arg (ap, int); /* { dg-warning "'va_arg' expected 'int' but
received '\[^\n\r\]*' for variadic argument 1 of 'ap' \\\[CWE-686\\\]" } */
__builtin_va_end (ap);
}
--
2.26.3
[committed] analyzer: associate -Wanalyzer-va-list-exhausted with CWE-685
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1144-gf443024bca7c1a.
gcc/analyzer/ChangeLog:
* varargs.cc: Include "diagnostic-metadata.h".
(va_list_exhausted::emit): Associate the warning with
CWE-685 ("Function Call With Incorrect Number of Arguments").
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/stdarg-1.c
(__analyzer_called_by_test_not_enough_args): Verify that
-Wanalyzer-va-list-exhausted is associated with CWE-685.
Signed-off-by: David Malcolm
---
gcc/analyzer/varargs.cc | 10 +++---
gcc/testsuite/gcc.dg/analyzer/stdarg-1.c | 2 +-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/gcc/analyzer/varargs.cc b/gcc/analyzer/varargs.cc
index 846a0b1e3ff..3baba7988c1 100644
--- a/gcc/analyzer/varargs.cc
+++ b/gcc/analyzer/varargs.cc
@@ -50,6 +50,7 @@ along with GCC; see the file COPYING3. If not see
#include "sbitmap.h"
#include "analyzer/diagnostic-manager.h"
#include "analyzer/exploded-graph.h"
+#include "diagnostic-metadata.h"
#if ENABLE_ANALYZER
@@ -903,9 +904,12 @@ public:
bool emit (rich_location *rich_loc) final override
{
auto_diagnostic_group d;
-bool warned = warning_at (rich_loc, get_controlling_option (),
- "%qE has no more arguments (%i consumed)",
- m_va_list_tree, get_num_consumed ());
+diagnostic_metadata m;
+/* CWE-685: Function Call With Incorrect Number of Arguments. */
+m.add_cwe (685);
+bool warned = warning_meta (rich_loc, m, get_controlling_option (),
+ "%qE has no more arguments (%i consumed)",
+ m_va_list_tree, get_num_consumed ());
return warned;
}
diff --git a/gcc/testsuite/gcc.dg/analyzer/stdarg-1.c
b/gcc/testsuite/gcc.dg/analyzer/stdarg-1.c
index 295f0efb74d..41935f74cc3 100644
--- a/gcc/testsuite/gcc.dg/analyzer/stdarg-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/stdarg-1.c
@@ -76,7 +76,7 @@ __analyzer_called_by_test_not_enough_args (int placeholder,
...)
s = __builtin_va_arg (ap, char *);
__analyzer_eval (s[0] == 'f'); /* { dg-warning "TRUE" } */
- i = __builtin_va_arg (ap, int); /* { dg-warning "'ap' has no more arguments
\\(1 consumed\\)" } */
+ i = __builtin_va_arg (ap, int); /* { dg-warning "'ap' has no more arguments
\\(1 consumed\\) \\\[CWE-685\\\]" } */
__builtin_va_end (ap);
}
--
2.26.3
[committed] analyzer: associate -Wanalyzer-double-fclose with CWE-1341
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1143-g065d191893234c.
gcc/analyzer/ChangeLog:
* sm-file.cc (double_fclose::emit): Associate the warning with
CWE-1341 ("Multiple Releases of Same Resource or Handle").
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/file-1.c (test_1): Verify that double-fclose is
associated with CWE-1341.
Signed-off-by: David Malcolm
---
gcc/analyzer/sm-file.cc| 9 ++---
gcc/testsuite/gcc.dg/analyzer/file-1.c | 2 +-
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/gcc/analyzer/sm-file.cc b/gcc/analyzer/sm-file.cc
index 8514af19766..f6cb29c7806 100644
--- a/gcc/analyzer/sm-file.cc
+++ b/gcc/analyzer/sm-file.cc
@@ -178,9 +178,12 @@ public:
bool emit (rich_location *rich_loc) final override
{
-return warning_at (rich_loc, get_controlling_option (),
- "double % of FILE %qE",
- m_arg);
+diagnostic_metadata m;
+/* CWE-1341: Multiple Releases of Same Resource or Handle. */
+m.add_cwe (1341);
+return warning_meta (rich_loc, m, get_controlling_option (),
+"double % of FILE %qE",
+m_arg);
}
label_text describe_state_change (const evdesc::state_change )
diff --git a/gcc/testsuite/gcc.dg/analyzer/file-1.c
b/gcc/testsuite/gcc.dg/analyzer/file-1.c
index e8d934331fd..316cbb3d868 100644
--- a/gcc/testsuite/gcc.dg/analyzer/file-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/file-1.c
@@ -14,7 +14,7 @@ test_1 (const char *path)
fclose (f); /* { dg-message "\\(4\\) \\.\\.\\.to here" "to here" } */
/* { dg-message "\\(5\\) first 'fclose' here" "first fclose" { target *-*-*
} .-1 } */
- fclose (f); /* { dg-warning "double 'fclose' of FILE 'f'" "warning" } */
+ fclose (f); /* { dg-warning "double 'fclose' of FILE 'f' \\\[CWE-1341\\\]"
"warning" } */
/* { dg-message "second 'fclose' here; first 'fclose' was at \\(5\\)"
"second fclose" { target *-*-* } .-1 } */
}
--
2.26.3
Re: [PATCH RFA] ubsan: default to trap on unreachable at -O0 and -Og [PR104642]
On Thu, Jun 16, 2022 at 09:32:02PM +0100, Jonathan Wakely wrote: > It looks like clang has addressed this deficiency now: > > https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#usage Thanks, will study how it works tomorrow. Jakub
Re: [PATCH RFA] ubsan: default to trap on unreachable at -O0 and -Og [PR104642]
On Tue, 14 Jun 2022, 12:44 Jakub Jelinek, wrote: > On Mon, Jun 13, 2022 at 03:53:13PM -0400, Jason Merrill via Gcc-patches > wrote: > > When not optimizing, we can't do anything useful with unreachability in > > terms of code performance, so we might as well improve debugging by > turning > > __builtin_unreachable into a trap. In the PR richi suggested > introducing an > > -funreachable-traps flag for this, but this functionality is already > > implemented as -fsanitize=unreachable > -fsanitize-undefined-trap-on-error, we > > just need to set those flags by default. > > > > I think it also makes sense to do this when we're explicitly optimizing > for > > the debugging experience. > > > > I then needed to make options-save handle -fsanitize and > > -fsanitize-undefined-trap-on-error; since -fsanitize is has custom > parsing, > > that meant handling it explicitly in the awk scripts. I also noticed we > > weren't setting it in opts_set. > > > > Do we still want -funreachable-traps as an alias (or separate flag) for > this > > behavior that doesn't mention the sanitizer? > > I do not like doing it this way, -fsanitize-undefined-trap-on-error is > (unfortunately for compatibility with llvm misdesign, users should have > ways to control which of the enabled sanitizers should be handled which > way, > where the 3 ways are runtime diagnostics without abort, runtime diagnostics > with abort and __builtin_trap ()) an all or nothing option which affects > all > the sanitizers. It looks like clang has addressed this deficiency now: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#usage You can choose a different outcome for different checks. They also have a smaller, intended-for-production runtime now: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#minimal-runtime
[pushed] opts: fix opts_set->x_flag_sanitize
While working on PR104642 I noticed this wasn't getting set. Tested x86_64-pc-linux-gnu, applying to trunk as obvious. gcc/ChangeLog: * opts.cc (common_handle_option) [OPT_fsanitize_]: Set opts_set->x_flag_sanitize. --- gcc/opts.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/opts.cc b/gcc/opts.cc index bf06a55456a..55859f549ba 100644 --- a/gcc/opts.cc +++ b/gcc/opts.cc @@ -2613,6 +2613,7 @@ common_handle_option (struct gcc_options *opts, break; case OPT_fsanitize_: + opts_set->x_flag_sanitize = true; opts->x_flag_sanitize = parse_sanitizer_options (arg, loc, code, opts->x_flag_sanitize, value, true); base-commit: d89e64d4cbf5a4c3b8de120257da68944f31e759 -- 2.27.0
[PATCH] c: Extend the -Wpadded message with actual padding size
When the compiler warns about padding struct to alignment boundary, it
now also informs the user about the size of the alignment that needs to
be added to get rid of the warning.
This removes the need of using pahole or similar tools, or manually
determining the padding size.
Tested on x86_64-pc-linux-gnu.
gcc/ChangeLog:
* stor-layout.cc (finalize_record_size): Improve warning message
Signed-off-by: Vit Kabele
---
gcc/stor-layout.cc | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/gcc/stor-layout.cc b/gcc/stor-layout.cc
index 765f22f68b9..57ddb001780 100644
--- a/gcc/stor-layout.cc
+++ b/gcc/stor-layout.cc
@@ -1781,7 +1781,14 @@ finalize_record_size (record_layout_info rli)
&& simple_cst_equal (unpadded_size, TYPE_SIZE (rli->t)) == 0
&& input_location != BUILTINS_LOCATION
&& !TYPE_ARTIFICIAL (rli->t))
-warning (OPT_Wpadded, "padding struct size to alignment boundary");
+ {
+ tree padding_size
+ = size_binop (MINUS_EXPR,
+ TYPE_SIZE_UNIT (rli->t), unpadded_size_unit);
+ warning (OPT_Wpadded,
+ "padding struct size to alignment boundary with %E bytes",
+ padding_size);
+ }
if (warn_packed && TREE_CODE (rli->t) == RECORD_TYPE
&& TYPE_PACKED (rli->t) && ! rli->packed_maybe_necessary
--
2.30.2
Go patch committed: Skip stubs for ambiguous direct iface methods
This patch to the Go frontend by Михаил Аблакатов (Mikhail Ablakatov) avoids generating stubs for ambiguous direct interface methods. The current implementation checks whether it has to generate a stub method for a promoted method of an embedded struct field in Type::build_stub_methods(). If the promoted method is ambiguous it's simply skipped. But struct types that can fit in an interface value (e.g. structs that consist of a single pointer field) get a second chance in Type::build_direct_iface_stub_methods(). This patch adds the same check used by Type::build_stub_methods() to Type::build_direct_iface_stub_methods(). Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. This fixes https://go.dev/issue/52870. The test case is https://go.dev/cl/412535. Committed to mainline. Ian 79d599b057cca42b84303ae25c7ab9f43e9f5eac diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE index aeada9f8d0c..0cda305c648 100644 --- a/gcc/go/gofrontend/MERGE +++ b/gcc/go/gofrontend/MERGE @@ -1,4 +1,4 @@ -bbb3a4347714faee620dc205674510a0f20b81ae +8db6b78110f84e22c409f334aeaefb80a8b39917 The first line of this file holds the git revision number of the last merge done from the gofrontend repository. diff --git a/gcc/go/gofrontend/types.cc b/gcc/go/gofrontend/types.cc index a8e309041e7..eb3afd94682 100644 --- a/gcc/go/gofrontend/types.cc +++ b/gcc/go/gofrontend/types.cc @@ -11891,7 +11891,7 @@ Type::build_direct_iface_stub_methods(Gogo* gogo, const Type* type, need_stub = true; if (!in_heap && !m->is_value_method()) need_stub = true; - if (!need_stub) + if (!need_stub || m->is_ambiguous()) continue; Type* receiver_type = const_cast(type);
[Bug libstdc++/101482] operator== for basic_string and __versa_string should check sizes first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101482 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |13.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed now, thanks for the report.
[Bug libstdc++/105995] QoI: constexpr basic_string variable must use all of its SSO buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105995 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Jonathan Wakely --- Fixed for GCC 13, thanks for the report.
[committed] libstdc++: Support constexpr global std::string for size < 15 [PR105995]
Tested x86_64-linux, pushed to trunk.
-- >8 --
I don't think this is required by the standard, but it's easy to
support.
libstdc++-v3/ChangeLog:
PR libstdc++/105995
* include/bits/basic_string.h (_M_use_local_data): Initialize
the entire SSO buffer.
* testsuite/21_strings/basic_string/cons/char/105995.cc: New test.
---
libstdc++-v3/include/bits/basic_string.h | 3 ++-
.../21_strings/basic_string/cons/char/105995.cc | 9 +
2 files changed, 11 insertions(+), 1 deletion(-)
create mode 100644
libstdc++-v3/testsuite/21_strings/basic_string/cons/char/105995.cc
diff --git a/libstdc++-v3/include/bits/basic_string.h
b/libstdc++-v3/include/bits/basic_string.h
index 57247e306dc..b04fba95678 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -352,7 +352,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
{
#if __cpp_lib_is_constant_evaluated
if (std::is_constant_evaluated())
- _M_local_buf[0] = _CharT();
+ for (_CharT& __c : _M_local_buf)
+ __c = _CharT();
#endif
return _M_local_data();
}
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/105995.cc
b/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/105995.cc
new file mode 100644
index 000..aa8bcba3dca
--- /dev/null
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/105995.cc
@@ -0,0 +1,9 @@
+// { dg-options "-std=gnu++20" }
+// { dg-do compile { target c++20 } }
+// { dg-require-effective-target cxx11_abi }
+
+// PR libstdc++/105995
+// Not required by the standard, but supported for QoI.
+constexpr std::string pr105995_empty;
+constexpr std::string pr105995_partial = "0";
+constexpr std::string pr105995_full = "0123456789abcde";
--
2.34.3
[committed] libstdc++: Apply r13-1096-g6abe341558abec change to vstring too [PR101482]
Tested x86_64-linux, pushed to trunk.
-- >8 --
As recently done for std::basic_string, __gnu_cxx::__versa_string
equality comparisons can check lengths first for any character type and
traits type, not only for std::char_traits.
libstdc++-v3/ChangeLog:
PR libstdc++/101482
* include/ext/vstring.h (operator==): Always check lengths
before comparing.
---
libstdc++-v3/include/ext/vstring.h | 49 ++
1 file changed, 22 insertions(+), 27 deletions(-)
diff --git a/libstdc++-v3/include/ext/vstring.h
b/libstdc++-v3/include/ext/vstring.h
index 4406695919d..47cbabf24f1 100644
--- a/libstdc++-v3/include/ext/vstring.h
+++ b/libstdc++-v3/include/ext/vstring.h
@@ -2338,31 +2338,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
inline bool
operator==(const __versa_string<_CharT, _Traits, _Alloc, _Base>& __lhs,
const __versa_string<_CharT, _Traits, _Alloc, _Base>& __rhs)
-{ return __lhs.compare(__rhs) == 0; }
-
- template class _Base>
-inline typename __enable_if::__value, bool>::__type
-operator==(const __versa_string<_CharT, std::char_traits<_CharT>,
- std::allocator<_CharT>, _Base>& __lhs,
- const __versa_string<_CharT, std::char_traits<_CharT>,
- std::allocator<_CharT>, _Base>& __rhs)
-{ return (__lhs.size() == __rhs.size()
- && !std::char_traits<_CharT>::compare(__lhs.data(), __rhs.data(),
- __lhs.size())); }
-
- /**
- * @brief Test equivalence of C string and string.
- * @param __lhs C string.
- * @param __rhs String.
- * @return True if @a __rhs.compare(@a __lhs) == 0. False otherwise.
- */
- template class _Base>
-inline bool
-operator==(const _CharT* __lhs,
- const __versa_string<_CharT, _Traits, _Alloc, _Base>& __rhs)
-{ return __rhs.compare(__lhs) == 0; }
+{
+ return __lhs.size() == __rhs.size()
+ && !_Traits::compare(__lhs.data(), __rhs.data(), __lhs.size());
+}
/**
* @brief Test equivalence of string and C string.
@@ -2375,7 +2354,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
inline bool
operator==(const __versa_string<_CharT, _Traits, _Alloc, _Base>& __lhs,
const _CharT* __rhs)
-{ return __lhs.compare(__rhs) == 0; }
+{
+ return __lhs.size() == _Traits::length(__rhs)
+ && !_Traits::compare(__lhs.data(), __rhs, __lhs.size());
+}
+
+ /**
+ * @brief Test equivalence of C string and string.
+ * @param __lhs C string.
+ * @param __rhs String.
+ * @return True if @a __rhs.compare(@a __lhs) == 0. False otherwise.
+ */
+ template class _Base>
+inline bool
+operator==(const _CharT* __lhs,
+ const __versa_string<_CharT, _Traits, _Alloc, _Base>& __rhs)
+{ return __rhs == __lhs; }
// operator !=
/**
@@ -2402,7 +2397,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
inline bool
operator!=(const _CharT* __lhs,
const __versa_string<_CharT, _Traits, _Alloc, _Base>& __rhs)
-{ return !(__lhs == __rhs); }
+{ return !(__rhs == __lhs); }
/**
* @brief Test difference of string and C string.
--
2.34.3
[Bug libstdc++/105995] QoI: constexpr basic_string variable must use all of its SSO buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105995 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:98a0d72a610a87e8e383d366e50253ddcc9a51dd commit r13-1139-g98a0d72a610a87e8e383d366e50253ddcc9a51dd Author: Jonathan Wakely Date: Thu Jun 16 14:57:32 2022 +0100 libstdc++: Support constexpr global std::string for size < 15 [PR105995] I don't think this is required by the standard, but it's easy to support. libstdc++-v3/ChangeLog: PR libstdc++/105995 * include/bits/basic_string.h (_M_use_local_data): Initialize the entire SSO buffer. * testsuite/21_strings/basic_string/cons/char/105995.cc: New test.
[Bug libstdc++/101482] operator== for basic_string and __versa_string should check sizes first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101482 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:51309d1158b85560a975819260776c0ca68fd142 commit r13-1138-g51309d1158b85560a975819260776c0ca68fd142 Author: Jonathan Wakely Date: Thu Jun 16 11:02:11 2022 +0100 libstdc++: Apply r13-1096-g6abe341558abec change to vstring too [PR101482] As recently done for std::basic_string, __gnu_cxx::__versa_string equality comparisons can check lengths first for any character type and traits type, not only for std::char_traits. libstdc++-v3/ChangeLog: PR libstdc++/101482 * include/ext/vstring.h (operator==): Always check lengths before comparing.
[Bug middle-end/106008] New: [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106008 Bug ID: 106008 Summary: [12 Regression] warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- Created attachment 53156 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53156=edit A testcase When building glibc master branch with -mavx512f, I got [hjl@gnu-tgl-2 tmp]$ gcc -O2 -march=x86-64 -S -Wall x.i -mavx512f dl-load.c: In function ‘_dl_map_object_from_fd.constprop’: dl-load.c:1158:30: warning: ‘(((char *)loadcmds.113_68 + _933 + 16))[329406144173384849].mapend’ may be used uninitialized [-Wmaybe-uninitialized] [hjl@gnu-tgl-2 tmp]$ The code looks like struct loadcmd *c = [nloadcmds++]; c->mapstart = ALIGN_DOWN (ph->p_vaddr, GLRO(dl_pagesize)); c->mapend = ALIGN_UP (ph->p_vaddr + ph->p_filesz, GLRO(dl_pagesize)); c->dataend = ph->p_vaddr + ph->p_filesz; c->allocend = ph->p_vaddr + ph->p_memsz; /* Remember the maximum p_align. */ if (powerof2 (ph->p_align) && ph->p_align > p_align_max) p_align_max = ph->p_align; c->mapoff = ALIGN_DOWN (ph->p_offset, GLRO(dl_pagesize)); /* Determine whether there is a gap between the last segment and this one. */ if (nloadcmds > 1 && c[-1].mapend != c->mapstart) has_holes = true; c[-1].mapend should always be initialized.
Re: [PATCH 1/2]AArch64 Add fallback case using sdot for usdot
Richard Sandiford via Gcc-patches writes:
> Tamar Christina writes:
>> Hi All,
>>
>> The usdot operation is common in video encoder and decoders including some of
>> the most widely used ones.
>>
>> This patch adds a +dotprod version of the optab as a fallback for when you do
>> have sdot but not usdot available.
>>
>> The fallback works by adding a bias to the unsigned argument to convert it to
>> a signed value and then correcting for the bias later on.
>>
>> Essentially it relies on (x - 128)y + 128y == xy where x is unsigned and y is
>> signed (assuming both are 8-bit values). Because the range of a signed byte
>> is
>> only to 127 we split the bias correction into:
>>
>>(x - 128)y + 127y + y
>
> I bet you knew this question was coming, but: this technique
> isn't target-specific, so wouldn't it be better to handle it in
> tree-vect-patterns.cc instead?
Also, how about doing (x - 128)y + 64y + 64y instead, to reduce
the number of hoisted constants?
Thanks,
Richard
> Thanks,
> Richard
>
>> Concretely for:
>>
>> #define N 480
>> #define SIGNEDNESS_1 unsigned
>> #define SIGNEDNESS_2 signed
>> #define SIGNEDNESS_3 signed
>> #define SIGNEDNESS_4 unsigned
>>
>> SIGNEDNESS_1 int __attribute__ ((noipa))
>> f (SIGNEDNESS_1 int res, SIGNEDNESS_3 char *restrict a,
>>SIGNEDNESS_4 char *restrict b)
>> {
>> for (__INTPTR_TYPE__ i = 0; i < N; ++i)
>> {
>> int av = a[i];
>> int bv = b[i];
>> SIGNEDNESS_2 short mult = av * bv;
>> res += mult;
>> }
>> return res;
>> }
>>
>> we generate:
>>
>> moviv5.16b, 0x7f
>> mov x3, 0
>> moviv4.16b, 0x1
>> moviv3.16b, 0xff80
>> moviv0.4s, 0
>> .L2:
>> ldr q2, [x2, x3]
>> ldr q1, [x1, x3]
>> add x3, x3, 16
>> sub v2.16b, v2.16b, v3.16b
>> sdotv0.4s, v2.16b, v1.16b
>> sdotv0.4s, v5.16b, v1.16b
>> sdotv0.4s, v4.16b, v1.16b
>> cmp x3, 480
>> bne .L2
>>
>> instead of:
>>
>> moviv0.4s, 0
>> mov x3, 0
>> .L2:
>> ldr q2, [x1, x3]
>> ldr q1, [x2, x3]
>> add x3, x3, 16
>> sxtlv4.8h, v2.8b
>> sxtl2 v3.8h, v2.16b
>> uxtlv2.8h, v1.8b
>> uxtl2 v1.8h, v1.16b
>> mul v2.8h, v2.8h, v4.8h
>> mul v1.8h, v1.8h, v3.8h
>> saddw v0.4s, v0.4s, v2.4h
>> saddw2 v0.4s, v0.4s, v2.8h
>> saddw v0.4s, v0.4s, v1.4h
>> saddw2 v0.4s, v0.4s, v1.8h
>> cmp x3, 480
>> bne .L2
>>
>> The new sequence is significantly faster as the operations it uses are well
>> optimized. Note that execution tests are already in the mid-end testsuite.
>>
>> Thanks to James Greenhalgh for the tip-off.
>>
>> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>>
>> Ok for master?
>>
>> Thanks,
>> Tamar
>>
>> gcc/ChangeLog:
>>
>> * config/aarch64/aarch64-simd.md (usdot_prod): Generate fallback
>> or call original isns ...
>> (usdot_prod_insn): ...here.
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/aarch64/simd/vusdot-autovec-2.c: New test.
>>
>> --- inline copy of patch --
>> diff --git a/gcc/config/aarch64/aarch64-simd.md
>> b/gcc/config/aarch64/aarch64-simd.md
>> index
>> cf2f4badacc594df9ecf06de3f8ea570ef9e0ff2..235a6fa371e471816284e3383e8564e9cf643a74
>> 100644
>> --- a/gcc/config/aarch64/aarch64-simd.md
>> +++ b/gcc/config/aarch64/aarch64-simd.md
>> @@ -623,7 +623,7 @@ (define_insn "dot_prod"
>>
>> ;; These instructions map to the __builtins for the Armv8.6-a I8MM usdot
>> ;; (vector) Dot Product operation and the vectorized optab.
>> -(define_insn "usdot_prod"
>> +(define_insn "usdot_prod_insn"
>>[(set (match_operand:VS 0 "register_operand" "=w")
>> (plus:VS
>>(unspec:VS [(match_operand: 1 "register_operand" "w")
>> @@ -635,6 +635,43 @@ (define_insn "usdot_prod"
>>[(set_attr "type" "neon_dot")]
>> )
>>
>> +;; usdot auto-vec fallback code
>> +(define_expand "usdot_prod"
>> + [(set (match_operand:VS 0 "register_operand")
>> +(plus:VS
>> + (unspec:VS [(match_operand: 1 "register_operand")
>> + (match_operand: 2 "register_operand")]
>> + UNSPEC_USDOT)
>> + (match_operand:VS 3 "register_operand")))]
>> + "TARGET_DOTPROD || TARGET_I8MM"
>> +{
>> + if (TARGET_I8MM)
>> +{
>> + emit_insn (gen_usdot_prod_insn (operands[0], operands[1],
>> + operands[2], operands[3]));
>> + DONE;
>> +}
>> +
>> + machine_mode elemmode = GET_MODE_INNER (mode);
>> + HOST_WIDE_INT val = 1 << (GET_MODE_BITSIZE (elemmode).to_constant () - 1);
>> + rtx signbit = gen_int_mode (val, elemmode);
>> + rtx t1 = gen_reg_rtx (mode);
>> + rtx t2 = gen_reg_rtx (mode);
>> + rtx tmp = gen_reg_rtx (mode);
>> + rtx c1 = gen_const_vec_duplicate (mode,
>> +gen_int_mode
c++: Elide inactive initializer fns from init array
There's no point adding no-op initializer fns (that a module might
have) to the static initializer list. Also, we can add any objc
initializer call to a partial initializer function and simplify some
control flow.
nathan
--
Nathan SidwellFrom c970d0072e3f962afa278e28f918fdcd1b3e755c Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Thu, 16 Jun 2022 10:14:56 -0700
Subject: [PATCH] c++: Elide inactive initializer fns from init array
There's no point adding no-op initializer fns (that a module might
have) to the static initializer list. Also, we can add any objc
initializer call to a partial initializer function and simplify some
control flow.
gcc/cp/
* decl2.cc (finish_objects): Add startp parameter, adjust.
(generate_ctor_or_dtor_function): Detect empty fn, and don't
generate unnecessary code. Remove objc startup here ...
(c_parse_final_cleanyps): ... do it here.
gcc/testsuite/
* g++.dg/modules/init-2_b.C: Add init check.
* g++.dg/modules/init-2_c.C: Add init check.
---
gcc/cp/decl2.cc | 97 +
gcc/testsuite/g++.dg/modules/init-2_b.C | 1 +
gcc/testsuite/g++.dg/modules/init-2_c.C | 1 +
3 files changed, 53 insertions(+), 46 deletions(-)
diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
index 0c4492f7354..3737e5f010c 100644
--- a/gcc/cp/decl2.cc
+++ b/gcc/cp/decl2.cc
@@ -56,7 +56,7 @@ int raw_dump_id;
extern cpp_reader *parse_in;
static tree start_objects (bool, unsigned, bool);
-static tree finish_objects (bool, unsigned, tree);
+static tree finish_objects (bool, unsigned, tree, bool = true);
static tree start_partial_init_fini_fn (bool, unsigned, unsigned);
static void finish_partial_init_fini_fn (tree);
static void emit_partial_init_fini_fn (bool, unsigned, tree,
@@ -3932,16 +3932,19 @@ start_objects (bool initp, unsigned priority, bool has_body)
return body;
}
-/* Finish a global constructor or destructor. */
+/* Finish a global constructor or destructor. Add it to the global
+ ctors or dtors, if STARTP is true. */
static tree
-finish_objects (bool initp, unsigned priority, tree body)
+finish_objects (bool initp, unsigned priority, tree body, bool startp)
{
/* Finish up. */
finish_compound_stmt (body);
tree fn = finish_function (/*inline_p=*/false);
- if (initp)
+ if (!startp)
+; // Neither ctor nor dtor I be.
+ else if (initp)
{
DECL_STATIC_CONSTRUCTOR (fn) = 1;
decl_init_priority_insert (fn, priority);
@@ -4307,58 +4310,54 @@ write_out_vars (tree vars)
}
}
-/* Generate a static constructor (if CONSTRUCTOR_P) or destructor
- (otherwise) that will initialize all global objects with static
- storage duration having the indicated PRIORITY. */
+/* Generate a static constructor or destructor that calls the given
+ init/fini fns at the indicated priority. */
static void
generate_ctor_or_dtor_function (bool initp, unsigned priority,
tree fns, location_t locus)
{
input_location = locus;
-
tree body = start_objects (initp, priority, bool (fns));
- /* To make sure dynamic construction doesn't access globals from other
- compilation units where they might not be yet constructed, for
- -fsanitize=address insert __asan_before_dynamic_init call that
- prevents access to either all global variables that need construction
- in other compilation units, or at least those that haven't been
- initialized yet. Variables that need dynamic construction in
- the current compilation unit are kept accessible. */
- if (initp && (flag_sanitize & SANITIZE_ADDRESS))
-finish_expr_stmt (asan_dynamic_init_call (/*after_p=*/false));
-
- if (initp && priority == DEFAULT_INIT_PRIORITY
- && c_dialect_objc () && objc_static_init_needed_p ())
-/* For Objective-C++, we may need to initialize metadata found in
- this module. This must be done _before_ any other static
- initializations. */
-objc_generate_static_init_call (NULL_TREE);
-
- /* Call the static init/fini functions. */
- for (tree node = fns; node; node = TREE_CHAIN (node))
+ if (fns)
{
- tree fn = TREE_PURPOSE (node);
+ /* To make sure dynamic construction doesn't access globals from
+ other compilation units where they might not be yet
+ constructed, for -fsanitize=address insert
+ __asan_before_dynamic_init call that prevents access to
+ either all global variables that need construction in other
+ compilation units, or at least those that haven't been
+ initialized yet. Variables that need dynamic construction in
+ the current compilation unit are kept accessible. */
+ if (initp && (flag_sanitize & SANITIZE_ADDRESS))
+ finish_expr_stmt (asan_dynamic_init_call (/*after_p=*/false));
- // We should never find a pure or constant cdtor.
- gcc_checking_assert (!(flags_from_decl_or_type (fn)
- & (ECF_CONST | ECF_PURE)));
+ /* Call the static init/fini functions. */
+ for (tree node = fns; node; node =
[COMMITTED] Clear invariant bit for inferred ranges.
When checking the results of moving the vrp1 pass to ranger, we
triggered a failure where a non-null was not being propagated properly
by the ranger inferring code.
When an ssa_name never occurs in an outgoing range in any block, it is
marked as invariant and its range is not tracked in the cache. If we
register an inferred range such as non-zero on such a name, it needs to
be removed from the invariant list so we can begin tracking its range.
This patch adds a flag to the set_invariant routine so it can be either
set or cleared. When we register an inferred range, we make it no longer
invariant.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 6c849e2fab3f682b715a81cb4ccc792f20c00eeb Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Thu, 16 Jun 2022 12:44:33 -0400
Subject: [PATCH 2/2] Clear invariant bit for inferred ranges.
The range of an invariant SSA (no outgoing edge range anywhere) is not tracked.
If an inferred range is registered, remove the invariant flag.
* gimple-range-cache.cc (ranger_cache::apply_inferred_ranges): If name
was invaraint before, clear the invariant bit.
* gimple-range-gori.cc (gori_map::set_range_invariant): Add a flag.
* gimple-range-gori.h (gori_map::set_range_invariant): Adjust prototype.
---
gcc/gimple-range-cache.cc | 7 ++-
gcc/gimple-range-gori.cc | 10 +++---
gcc/gimple-range-gori.h | 2 +-
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc
index f3494363a10..5df744184c4 100644
--- a/gcc/gimple-range-cache.cc
+++ b/gcc/gimple-range-cache.cc
@@ -1474,7 +1474,12 @@ ranger_cache::apply_inferred_ranges (gimple *s)
if (!m_on_entry.get_bb_range (r, name, bb))
exit_range (r, name, bb, RFD_READ_ONLY);
if (r.intersect (infer.range (x)))
- m_on_entry.set_bb_range (name, bb, r);
+ {
+ m_on_entry.set_bb_range (name, bb, r);
+ // If this range was invariant before, remove invariance.
+ if (!m_gori.has_edge_range_p (name))
+ m_gori.set_range_invariant (name, false);
+ }
}
}
}
diff --git a/gcc/gimple-range-gori.cc b/gcc/gimple-range-gori.cc
index 0a3e54eae4e..a43e44c841e 100644
--- a/gcc/gimple-range-gori.cc
+++ b/gcc/gimple-range-gori.cc
@@ -499,12 +499,16 @@ gori_map::is_export_p (tree name, basic_block bb)
return bitmap_bit_p (exports (bb), SSA_NAME_VERSION (name));
}
-// Clear the m_maybe_variant bit so ranges will not be tracked for NAME.
+// Set or clear the m_maybe_variant bit to determine if ranges will be tracked
+// for NAME. A clear bit means they will NOT be tracked.
void
-gori_map::set_range_invariant (tree name)
+gori_map::set_range_invariant (tree name, bool invariant)
{
- bitmap_clear_bit (m_maybe_variant, SSA_NAME_VERSION (name));
+ if (invariant)
+bitmap_clear_bit (m_maybe_variant, SSA_NAME_VERSION (name));
+ else
+bitmap_set_bit (m_maybe_variant, SSA_NAME_VERSION (name));
}
// Return true if NAME is an import to block BB.
diff --git a/gcc/gimple-range-gori.h b/gcc/gimple-range-gori.h
index f5f691fe424..3d57ab94624 100644
--- a/gcc/gimple-range-gori.h
+++ b/gcc/gimple-range-gori.h
@@ -94,7 +94,7 @@ public:
bool is_import_p (tree name, basic_block bb);
bitmap exports (basic_block bb);
bitmap imports (basic_block bb);
- void set_range_invariant (tree name);
+ void set_range_invariant (tree name, bool invariant = true);
void dump (FILE *f);
void dump (FILE *f, basic_block bb, bool verbose = true);
--
2.17.2
[COMMITTED] Propagator should call value_of_stmt.
When evaluating the LHS of a stmt, its more efficient/better to call
value_of_stmt directly rather than value_of_expr. The value_of_*
routines are not quite as efficient as the range_of routines, plus
value_of_expr will check if its a LHS, and invoke value_of_stmt if it is.
This in fact speeds VRP up by about 1.5%... it bypasses some other stuff
the value_of_expr checks that is not necessary.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 5b1594dc2d053803ae98ae39f76fbd71f35cb657 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Thu, 31 Mar 2022 09:36:59 -0400
Subject: [PATCH 1/2] Propagator should call value_of_stmt.
When evaluating the LHS of a stmt, its more efficent/better to call
value_of_stmt directly rather than value_of_expr.
* tree-ssa-propagate.cc (before_dom_children): Call value_of_stmt.
---
gcc/tree-ssa-propagate.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/tree-ssa-propagate.cc b/gcc/tree-ssa-propagate.cc
index c10ffd91766..5983f029364 100644
--- a/gcc/tree-ssa-propagate.cc
+++ b/gcc/tree-ssa-propagate.cc
@@ -813,7 +813,7 @@ substitute_and_fold_dom_walker::before_dom_children (basic_block bb)
tree lhs = gimple_get_lhs (stmt);
if (lhs && TREE_CODE (lhs) == SSA_NAME)
{
- tree sprime = substitute_and_fold_engine->value_of_expr (lhs, stmt);
+ tree sprime = substitute_and_fold_engine->value_of_stmt (stmt, lhs);
if (sprime
&& sprime != lhs
&& may_propagate_copy (lhs, sprime)
--
2.17.2
[Bug c++/106001] [12/13 Regression] ICE: expected expression 'static_cast(1)' of kind static_cast_expr since r12-1128-gef8176e0fac935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106001 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 53155 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53155=edit gcc13-pr106001.patch Untested fix.
[Bug tree-optimization/103798] memchr with a (small) constant string should be expanded inline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103798 --- Comment #2 from H.J. Lu --- Created attachment 53154 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53154=edit A patch Like this?
[Bug target/105991] [12/13 Regression] rldicl+sldi+add generated instead of rldimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105991 --- Comment #3 from Marek Polacek --- Regtest/bootstrap passed on powerpc64le-unknown-linux-gnu. I did not test Ada.
[Bug c++/106001] [12/13 Regression] ICE: expected expression 'static_cast(1)' of kind static_cast_expr since r12-1128-gef8176e0fac935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106001
--- Comment #2 from Jakub Jelinek ---
Actually valid testcase:
typedef int V __attribute__((vector_size (2 * sizeof (int;
template
void
foo ()
{
V v {};
v = __builtin_shufflevector (v, v, static_cast(1),
static_cast(0));
}
void
bar ()
{
foo <0> ();
}
[Bug analyzer/106007] New: RFE: analyzer should complain about exec/system of tainted args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106007 Bug ID: 106007 Summary: RFE: analyzer should complain about exec/system of tainted args Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- The analyzer should complain if tainted args are passed to any of the following without sanitization (probably not an exhaustive list): int execl(const char *pathname, const char *arg, ... /* (char *) NULL */); int execlp(const char *file, const char *arg, ... /* (char *) NULL */); int execle(const char *pathname, const char *arg, ... /*, (char *) NULL, char * const envp[] */); int execv(const char *pathname, char *const argv[]); int execvp(const char *file, char *const argv[]); int execvpe(const char *file, char *const argv[], char *const envp[]); int execve(const char *pathname, char *const argv[], char *const envp[]); int execveat(int dirfd, const char *pathname, char *const argv[], char *const envp[], int flags); int fexecve(int fd, char *const argv[], char *const envp[]); int system(const char *command); Could have/reuse an attribute for this, or hardcode it.
[Bug analyzer/106006] New: RFE: analyzer should treat data from a socket as "tainted"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106006 Bug ID: 106006 Summary: RFE: analyzer should treat data from a socket as "tainted" Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- These functions should taint the buffers they write to: ssize_t recv(int sockfd, void *buf, size_t len, int flags); ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags, struct sockaddr *src_addr, socklen_t *addrlen); ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags); Perhaps we could add/reuse an attribute for this, or hardcode the knowledge in the analyzer.
Re: gomp_affinity_format_len
On Thu, Jun 16, 2022 at 06:00:47PM +0200, Mohamed Atef wrote: > I cant't get the value of "gomp_affinity_format_let" I used the plugin but > it only gives 0 value. if you noticed in the gompd_get_affinity_format i > used 100 for the length of the affinity format. gomp_affinity_format_len is just an internal var holding how many bytes have been allocated for the gomp_affinity_format pointer. Unless you use OMP_AFFINITY_FORMAT env var or call omp_set_affinity_format, it will be 0. Jakub
[Bug fortran/106005] New: (F2023) Support for REDUCTION clause in DO CONCURRENT loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005 Bug ID: 106005 Summary: (F2023) Support for REDUCTION clause in DO CONCURRENT loop Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: wileamyp at outlook dot com Target Milestone: --- GFortran 12.1.0 refuses to compile the following valid code under Fortran 2023. $ cat dc-reduce.f90 PROGRAM dcreduce INTEGER, PARAMETER :: n = 10 INTEGER :: ivec(n) ivec = [( i, i = 1, n )] ival = 0 DO CONCURRENT (i=1:n) REDUCE(+:ival) ival = ival + ivec(i) END DO PRINT *, ival END PROGRAM $ gfortran --version GNU Fortran (Spack GCC) 12.1.0 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gfortran dc-reduce.f90 dc-reduce.f90:7:24: 7 | DO CONCURRENT (i=1:n) REDUCE(+:ival) |1 Error: Syntax error in DO statement at (1) dc-reduce.f90:9:5: 9 | END DO | 1 Error: Expecting END PROGRAM statement at (1) At the time of writing, only NVIDIA nvfortran compiles this successfully and gives the correct result. Tested with nvfortran 22.5. $ nvfortran --version nvfortran 22.5-0 64-bit target on x86-64 Linux -tp zen2 NVIDIA Compilers and Tools Copyright (c) 2022, NVIDIA CORPORATION & AFFILIATES. All rights reserved. $ nvfortran dc-reduce.f90 $ ./a.out 55
[Bug target/106004] New: [13 Regression] ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in arm_print_operand, at config/arm/arm.cc:24202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106004
Bug ID: 106004
Summary: [13 Regression] ICE: RTL check: expected elt 0 type
'i' or 'n', have 'w' (rtx const_int) in
arm_print_operand, at config/arm/arm.cc:24202
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: build, ice-checking, ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: armv7a-hardfloat-linux-gnueabi
Created attachment 53153
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53153=edit
reduced testcase (from sanitizer_deadlock_detector1.cpp)
This currently breaks build with RTL checking enabled.
Compiler output:
$ /repo/build-gcc-trunk-armv7a-hardfloat/./gcc/cc1plus -O -march=armv7-a+vfpv4
testcase.C
bool DeadlockDetector::nodeBelongsToCurrentEpoch() void MutexEnsureID()
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 1176k} {heap 1176k}
{heap 1176k} {heap 1460k} {heap 2124k}
{heap 2124k} {heap 2124k}Streaming LTO
{heap 2124k} {heap 2124k} {heap
2124k} {heap 2124k} {heap 2124k} {heap 2124k}
{heap 2124k} {heap 2124k} {heap
2124k} {heap 2124k}Assembling functions:
void MutexEnsureID()during RTL pass: final
testcase.C: In function 'void MutexEnsureID()':
testcase.C:19:1: internal compiler error: RTL check: expected elt 0 type 'i' or
'n', have 'w' (rtx const_int) in arm_print_operand, at config/arm/arm.cc:24202
19 | }
| ^
0x804c80 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
/repo/gcc-trunk/gcc/rtl.cc:907
0x8ccae3 arm_print_operand
/repo/gcc-trunk/gcc/config/arm/arm.cc:24202
0xfbbc31 output_operand(rtx_def*, int)
/repo/gcc-trunk/gcc/final.cc:3677
0xfbca83 output_asm_insn(char const*, rtx_def**)
/repo/gcc-trunk/gcc/final.cc:3570
0xfc28fc output_asm_insn(char const*, rtx_def**)
/repo/gcc-trunk/gcc/final.cc:3466
0xfc28fc final_scan_insn_1
/repo/gcc-trunk/gcc/final.cc:2894
0xfc2d0b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/repo/gcc-trunk/gcc/final.cc:2940
0xfc2e04 final_1
/repo/gcc-trunk/gcc/final.cc:1997
0xfc3b56 rest_of_handle_final
/repo/gcc-trunk/gcc/final.cc:4285
0xfc3b56 execute
/repo/gcc-trunk/gcc/final.cc:4363
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ /repo/build-gcc-trunk-armv7a-hardfloat/./gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/repo/build-gcc-trunk-armv7a-hardfloat/./gcc/xgcc
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-float=hard --with-fpu=vfpv4
--with-arch=armv7-a --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-1134-20220616143736-g9642d07c35f-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220616 (experimental) (GCC)
Re: [PATCH 1/2]AArch64 Add fallback case using sdot for usdot
Tamar Christina writes:
> Hi All,
>
> The usdot operation is common in video encoder and decoders including some of
> the most widely used ones.
>
> This patch adds a +dotprod version of the optab as a fallback for when you do
> have sdot but not usdot available.
>
> The fallback works by adding a bias to the unsigned argument to convert it to
> a signed value and then correcting for the bias later on.
>
> Essentially it relies on (x - 128)y + 128y == xy where x is unsigned and y is
> signed (assuming both are 8-bit values). Because the range of a signed byte
> is
> only to 127 we split the bias correction into:
>
>(x - 128)y + 127y + y
I bet you knew this question was coming, but: this technique
isn't target-specific, so wouldn't it be better to handle it in
tree-vect-patterns.cc instead?
Thanks,
Richard
> Concretely for:
>
> #define N 480
> #define SIGNEDNESS_1 unsigned
> #define SIGNEDNESS_2 signed
> #define SIGNEDNESS_3 signed
> #define SIGNEDNESS_4 unsigned
>
> SIGNEDNESS_1 int __attribute__ ((noipa))
> f (SIGNEDNESS_1 int res, SIGNEDNESS_3 char *restrict a,
>SIGNEDNESS_4 char *restrict b)
> {
> for (__INTPTR_TYPE__ i = 0; i < N; ++i)
> {
> int av = a[i];
> int bv = b[i];
> SIGNEDNESS_2 short mult = av * bv;
> res += mult;
> }
> return res;
> }
>
> we generate:
>
> moviv5.16b, 0x7f
> mov x3, 0
> moviv4.16b, 0x1
> moviv3.16b, 0xff80
> moviv0.4s, 0
> .L2:
> ldr q2, [x2, x3]
> ldr q1, [x1, x3]
> add x3, x3, 16
> sub v2.16b, v2.16b, v3.16b
> sdotv0.4s, v2.16b, v1.16b
> sdotv0.4s, v5.16b, v1.16b
> sdotv0.4s, v4.16b, v1.16b
> cmp x3, 480
> bne .L2
>
> instead of:
>
> moviv0.4s, 0
> mov x3, 0
> .L2:
> ldr q2, [x1, x3]
> ldr q1, [x2, x3]
> add x3, x3, 16
> sxtlv4.8h, v2.8b
> sxtl2 v3.8h, v2.16b
> uxtlv2.8h, v1.8b
> uxtl2 v1.8h, v1.16b
> mul v2.8h, v2.8h, v4.8h
> mul v1.8h, v1.8h, v3.8h
> saddw v0.4s, v0.4s, v2.4h
> saddw2 v0.4s, v0.4s, v2.8h
> saddw v0.4s, v0.4s, v1.4h
> saddw2 v0.4s, v0.4s, v1.8h
> cmp x3, 480
> bne .L2
>
> The new sequence is significantly faster as the operations it uses are well
> optimized. Note that execution tests are already in the mid-end testsuite.
>
> Thanks to James Greenhalgh for the tip-off.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
>
> Ok for master?
>
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-simd.md (usdot_prod): Generate fallback
> or call original isns ...
> (usdot_prod_insn): ...here.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/aarch64/simd/vusdot-autovec-2.c: New test.
>
> --- inline copy of patch --
> diff --git a/gcc/config/aarch64/aarch64-simd.md
> b/gcc/config/aarch64/aarch64-simd.md
> index
> cf2f4badacc594df9ecf06de3f8ea570ef9e0ff2..235a6fa371e471816284e3383e8564e9cf643a74
> 100644
> --- a/gcc/config/aarch64/aarch64-simd.md
> +++ b/gcc/config/aarch64/aarch64-simd.md
> @@ -623,7 +623,7 @@ (define_insn "dot_prod"
>
> ;; These instructions map to the __builtins for the Armv8.6-a I8MM usdot
> ;; (vector) Dot Product operation and the vectorized optab.
> -(define_insn "usdot_prod"
> +(define_insn "usdot_prod_insn"
>[(set (match_operand:VS 0 "register_operand" "=w")
> (plus:VS
> (unspec:VS [(match_operand: 1 "register_operand" "w")
> @@ -635,6 +635,43 @@ (define_insn "usdot_prod"
>[(set_attr "type" "neon_dot")]
> )
>
> +;; usdot auto-vec fallback code
> +(define_expand "usdot_prod"
> + [(set (match_operand:VS 0 "register_operand")
> + (plus:VS
> + (unspec:VS [(match_operand: 1 "register_operand")
> + (match_operand: 2 "register_operand")]
> + UNSPEC_USDOT)
> + (match_operand:VS 3 "register_operand")))]
> + "TARGET_DOTPROD || TARGET_I8MM"
> +{
> + if (TARGET_I8MM)
> +{
> + emit_insn (gen_usdot_prod_insn (operands[0], operands[1],
> + operands[2], operands[3]));
> + DONE;
> +}
> +
> + machine_mode elemmode = GET_MODE_INNER (mode);
> + HOST_WIDE_INT val = 1 << (GET_MODE_BITSIZE (elemmode).to_constant () - 1);
> + rtx signbit = gen_int_mode (val, elemmode);
> + rtx t1 = gen_reg_rtx (mode);
> + rtx t2 = gen_reg_rtx (mode);
> + rtx tmp = gen_reg_rtx (mode);
> + rtx c1 = gen_const_vec_duplicate (mode,
> + gen_int_mode (val - 1, elemmode));
> + rtx c2 = gen_const_vec_duplicate (mode, gen_int_mode (1,
> elemmode));
> + rtx dup = gen_const_vec_duplicate (mode, signbit);
> + c1 = force_reg (mode, c1);
> + c2 = force_reg (mode, c2);
> + dup = force_reg (mode, dup);
> + emit_insn (gen_sub3 (tmp, operands[1], dup));
>
Re: gomp_affinity_format_len
I cant't get the value of "gomp_affinity_format_let" I used the plugin but it only gives 0 value. if you noticed in the gompd_get_affinity_format i used 100 for the length of the affinity format. Mohamed. في الخميس، ١٦ يونيو، ٢٠٢٢ ٥:٤٦ م Mohamed Atef كتب: > Sorry i found it in affinity-fmt.c > > في الخميس، ١٦ يونيو، ٢٠٢٢ ٥:٤١ م Mohamed Atef > كتب: > >> Hello, >>this variable doesn't take value. It's always zero. >> Is this intended? >> >> Mohamed >> >
Re: gomp_affinity_format_len
Sorry i found it in affinity-fmt.c في الخميس، ١٦ يونيو، ٢٠٢٢ ٥:٤١ م Mohamed Atef كتب: > Hello, >this variable doesn't take value. It's always zero. > Is this intended? > > Mohamed >
gomp_affinity_format_len
Hello, this variable doesn't take value. It's always zero. Is this intended? Mohamed
[Bug c++/105996] [10/11/12/13 Regression] reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105996 --- Comment #3 from Jakub Jelinek --- Or can we say just call cp_convert instead of build_reinterpret_cast in that case?
[Bug target/105992] memcmp(p, q, 7) == 0 can be optimized better on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105992 --- Comment #3 from H.J. Lu --- (In reply to Hongtao.liu from comment #1) > I'm wondering would targetm.overlap_op_by_pieces_p helps here. The code is generated by targetm.overlap_op_by_pieces_p. It compares 4 byte at a time with branches.
[Bug c++/105996] [10/11/12/13 Regression] reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105996
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
The problem is that build_ptrmemfunc in
9587 if (TREE_CODE (pfn) != PTRMEM_CST)
9588{
9589 if (same_type_p (to_type, pfn_type))
9590return pfn;
9591 else if (integer_zerop (n) && TREE_CODE (pfn) != CONSTRUCTOR)
9592return build_reinterpret_cast (input_location, to_type,
pfn,
9593 complain);
9594}
calls build_reintepret_cast from void (A::*)() typed pfn to void (B::*)() type,
and when we then constant expression evaluate it, we reject it because
reinterpret_cast is not a core constant expression as per
https://eel.is/c++draft/expr.const#5.16
Now, is this reinterpret cast just some implementation detail under the hood in
which we should somehow arrange for REINTERPRET_CAST_P bit not be set (or
afterwards remove it)?
[Bug analyzer/106003] RFE: -fanalyzer could complain about misuse of file-descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003 --- Comment #1 from David Malcolm --- See also this mailing list thread: https://gcc.gnu.org/pipermail/gcc/2022-June/238801.html
Re: GSoC: Getting started
On Wed, 2022-06-01 at 14:50 -0400, David Malcolm wrote: > On Wed, 2022-06-01 at 23:22 +0530, Mir Immad wrote: > > HI everyone, > > > > I'm Immad Mir -- one of the GSoC students this year. I'll be working > > on > > adding static analysis support for POSIX file description APIs this > > summer. > > Welcome Immad - I'm looking forward to helping you on this project. > > For reference, I think you posted an initial prototype of this work > earlier this year here: > https://gcc.gnu.org/pipermail/gcc/2022-January/238192.html > https://gcc.gnu.org/pipermail/gcc/2022-February/238215.html > > > > > The plan is to let the static analyzer know about the FD APIs through > > the > > use of function attributes, although initially we might hardcode the > > logic > > to get started working. I'm looking for the suggestions on this from > > the > > people who have experience working with file-descriptors. > > We talked about this off-list; I think next steps could be: > > (1) get your initial prototype working again, hardcoding the names of > the functions for simplicity at first > > (2) find a list of system calls (e.g. those implemented on Linux), and > see which ones relate to file descriptors e.g. acquiring them, using > them, releasing them, and duplicating them. Look for patterns of usage > that could be expressed using function attributes. Probably ignore > "ioctl" for now. > > (3) probably talk to glibc's developers about this, since glibc > provides headers that wrap system calls, which would want to use the > attributes if we provide them > > (4) implement the attributes, so that the analyzer doesn't have > hardcoded function names, and can instead rely on function attributes. > GCC's attributes are implemented in gcc/c-family/c-attribs.cc; see the > big c_common_attribute_table array, which associates the string names > of the attrbutes with properties, including a handler callback. These > either set flags of a decl, or the attribute itself is appended to a > singly-linked list on that decl (for those things that don't directly > relate to fields of a decl). > > I believe Siddhesh Poyarekar has been looking at attributes from the > glibc side of things, so I'm CCing him in case he has input on this. > > I'm wondering if other people on this list have ideas for projects that > make heavy use of syscalls/file-descriptors that would benefit from > having this analyzer feature. Maybe systemd? > > Welcome again; hope this makes sense and is helpful > Dave I've gone ahead and filed an RFE bug in our bugzilla to help track this work: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003 Immad: you should probably assign that bug to yourself. Do you have an account yet for bugzilla? See: https://gcc.gnu.org/gitwrite.html#authenticated for info on how to get an account on sourceware.org/gcc.gnu.org I can be your sponsor. Once you have that, I think you automatically get a usern...@gcc.gnu.org account that you can use to login to the GCC bugzilla. Dave
Re: [PATCH][wwwdocs] gcc-13: add arm star-mc1 cpu
On Thu, 16 Jun 2022, Chung-Ju Wu wrote: > Recently we added arm star-mc1 cpu support to upstream: > https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596379.html > > It would be great if we can describe it on gcc-13 changes.html as well. > Attached is the patch for gcc-wwwdocs repository. Looks good to me (from the wwwdocs side), thank you! Gerald
[Bug analyzer/106003] New: RFE: -fanalyzer could complain about misuse of file-descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
Bug ID: 106003
Summary: RFE: -fanalyzer could complain about misuse of
file-descriptors
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
-fanalyzer could be extended to check POSIX file-descriptor APIs ("int" rather
than FILE *).
e.g.
- check for FD leaks
- check for double "close" of a FD (CWE-1341, I believe)
- check for read/write of a closed descriptor
- check for read/write of a descriptor opened for just writing/reading
etc
Immad Mir is looking at this for GSoC 2022.
Example of a "double file-descriptor close" bug:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13351
albeit in C++.
[Bug target/105992] memcmp(p, q, 7) == 0 can be optimized better on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105992 --- Comment #2 from H.J. Lu --- (In reply to Hongtao.liu from comment #1) > I'm wondering would targetm.overlap_op_by_pieces_p helps here. It is related to PR 103798.
[statistics.cc] Emit asm name of function with -fdump-statistics-asmname
Hi,
I just noticed -fdump-statistics supports asmname sub-option, which
according to the doc states:
"If DECL_ASSEMBLER_NAME has been set for a given decl, use that in the dump
instead of DECL_NAME. Its primary use is ease of use working backward from
mangled names in the assembly file."
When passed -fdump-statistics-asmname, the dump however still contains the
original name of functions. The patch modifies statistics.cc to emit asm
name of function instead. Also for C++, it helps to better disambiguate
overloaded function names in the stats dump file.
I have attached stats dump for a simple test-case.
Does it look OK ?
Thanks,
Prathamesh
diff --git a/gcc/statistics.cc b/gcc/statistics.cc
index 0d596e34189..ff4f9cc7fb6 100644
--- a/gcc/statistics.cc
+++ b/gcc/statistics.cc
@@ -25,6 +25,7 @@ along with GCC; see the file COPYING3. If not see
#include "tree-pass.h"
#include "context.h"
#include "pass_manager.h"
+#include "tree.h"
static int statistics_dump_nr;
static dump_flags_t statistics_dump_flags;
@@ -113,6 +114,21 @@ curr_statistics_hash (void)
return statistics_hashes[idx];
}
+/* Helper function to return asmname or name of FN
+ depending on whether asmname option is set. */
+
+static const char *
+get_function_name (struct function *fn)
+{
+ if (statistics_dump_flags & TDF_ASMNAME)
+{
+ tree asmname = decl_assembler_name (fn->decl);
+ if (asmname)
+ return IDENTIFIER_POINTER (asmname);
+}
+ return function_name (fn);
+}
+
/* Helper for statistics_fini_pass. Print the counter difference
since the last dump for the pass dump files. */
@@ -152,7 +168,7 @@ statistics_fini_pass_2 (statistics_counter **slot,
current_pass->static_pass_number,
current_pass->name,
counter->id, counter->val,
-current_function_name (),
+get_function_name (cfun),
count);
else
fprintf (statistics_dump_file,
@@ -160,7 +176,7 @@ statistics_fini_pass_2 (statistics_counter **slot,
current_pass->static_pass_number,
current_pass->name,
counter->id,
-current_function_name (),
+get_function_name (cfun),
count);
counter->prev_dumped_count = counter->count;
return 1;
@@ -329,7 +345,7 @@ statistics_counter_event (struct function *fn, const char
*id, int incr)
current_pass ? current_pass->static_pass_number : -1,
current_pass ? current_pass->name : "none",
id,
- function_name (fn),
+ get_function_name (fn),
incr);
}
@@ -359,5 +375,5 @@ statistics_histogram_event (struct function *fn, const char
*id, int val)
current_pass->static_pass_number,
current_pass->name,
id, val,
- function_name (fn));
+ get_function_name (fn));
}
foo.cpp
Description: Binary data
29 ssa "unused VAR_DECLs removed" "foo" 1
47 fre "RPO blocks" "foo" 1
47 fre "RPO iterations == 10" "foo" 1
47 fre "RPO blocks visited" "foo" 1
47 fre "RPO blocks executable" "foo" 1
47 fre "RPO block visited times == 1" "foo" 1
47 fre "RPO num avail == 1" "foo" 1
47 fre "RPO num values == 3" "foo" 1
47 fre "RPO num lattice == 3" "foo" 1
47 fre "RPO num values == 2" "foo" 1
47 fre "RPO blocks" "foo" 1
47 fre "RPO iterations == 10" "foo" 1
47 fre "RPO num lattice == 2" "foo" 1
47 fre "RPO blocks visited" "foo" 1
47 fre "RPO blocks executable" "foo" 1
47 fre "RPO block visited times == 1" "foo" 1
47 fre "RPO num avail == 1" "foo" 1
120 fre "RPO blocks" "foo" 1
120 fre "RPO iterations == 10" "foo" 1
120 fre "RPO blocks visited" "foo" 1
120 fre "RPO blocks executable" "foo" 1
120 fre "RPO block visited times == 1" "foo" 1
120 fre "RPO num avail == 1" "foo" 1
120 fre "RPO num values == 3" "foo" 1
120 fre "RPO num lattice == 3" "foo" 1
151 pre "RPO blocks" "foo" 1
151 pre "RPO iterations == 10" "foo" 1
151 pre "compute_antic iterations == 2" "foo" 1
151 pre "RPO blocks visited" "foo" 1
151 pre "RPO blocks executable" "foo" 1
151 pre "RPO block visited times == 1" "foo" 1
151 pre "RPO num avail == 1" "foo" 1
151 pre "RPO num values == 3" "foo" 1
151 pre "RPO num lattice == 3" "foo" 1
151 pre "insert iterations == 1" "foo" 1
201 fre "RPO blocks" "foo" 1
201 fre "RPO iterations == 10" "foo" 1
201 fre "RPO blocks visited" "foo" 1
201 fre "RPO blocks executable" "foo" 1
201 fre "RPO block visited times == 1" "foo" 1
201 fre "RPO num avail == 1" "foo" 1
201 fre "RPO num values == 3" "foo" 1
201 fre "RPO num lattice == 3" "foo" 1
293 combine "two-insn combine" "foo" 2
120 fre "RPO num values == 2" "foo" 1
120 fre "RPO blocks" "foo" 1
120 fre "RPO iterations == 10" "foo" 1
120 fre "RPO num lattice == 2" "foo" 1
120 fre "RPO blocks visited" "foo" 1
120 fre "RPO blocks executable" "foo" 1
120 fre "RPO block visited times == 1" "foo" 1
120 fre "RPO num avail == 1" "foo" 1
151 pre "RPO num values == 2" "foo" 1
151 pre "RPO blocks" "foo" 1
151 pre "RPO iterations == 10" "foo"
[Bug target/105991] [12/13 Regression] rldicl+sldi+add generated instead of rldimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105991 --- Comment #2 from Marek Polacek --- (In reply to Roger Sayle from comment #1) > The following patch appears to correct this for me on a cross-compiler to > powerpcle64, but it's tricky for me to do a full bootstrap/regression test. Thanks for the patch. I'm testing it and will report back the results.
[Bug middle-end/105998] [10/11/12/13 Regression] ICE: in as_a, at machmode.h:365 with vector arithmetics since r9-1971-g315aa691f486bf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105998 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Component|c++ |middle-end
[Bug analyzer/105888] RFE: -fanalyzer should complain when an on-stack address escapes/outlives the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105888 --- Comment #1 from David Malcolm --- See also CWE-562: Return of Stack Variable Address https://cwe.mitre.org/data/definitions/562.html
[Bug tree-optimization/105973] Wrong branch prediction for if (COND) { if(x) noreturn1(); else noreturn2(); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105973 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-06-16 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Martin Liška --- I can try implementing that.
[Bug rtl-optimization/105988] [10/11/12/13 Regression] ICE in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1064 since r6-4873-gebedc9a3414d8422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105988 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression] |ICE in |ICE in |linemap_ordinary_map_lookup |linemap_ordinary_map_lookup |, at|, at |libcpp/line-map.cc:1064 |libcpp/line-map.cc:1064 ||since ||r6-4873-gebedc9a3414d8422 Ever confirmed|0 |1 Last reconfirmed||2022-06-16 CC||dmalcolm at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- (In reply to G. Steinmetz from comment #1) > Starts with r6 and file gcc.dg/torture/pr56034.c, etc. : > (starts with r7 without option -fno-tree-dce) Started with r6-4873-gebedc9a3414d8422.
[Bug target/105980] [11/12/13 Regression] ICE in final_scan_insn_1, at final.cc:2811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC||andi-gcc at firstfloor dot org,
||marxin at gcc dot gnu.org
Last reconfirmed||2022-06-16
Ever confirmed|0 |1
--- Comment #1 from Martin Liška ---
Reduced to something like:
struct A {
virtual ~A();
};
struct B : virtual A {};
void bar() { B(); }
It's there since the beginning as we emitted an invalid assembly:
/tmp/ccw0I6Qv.s:178: Error: `.LTHUNK0@GOTOFF(%bh)' is not a valid base/index
expression
/tmp/ccw0I6Qv.s:235: Error: `.LTHUNK1@GOTOFF(%bh)' is not a valid base/index
expression
[Bug tree-optimization/105820] [13 Regression] ICE in invert, at value-range.cc:1971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105820 --- Comment #4 from Andrew Macleod --- Well, thats not really the problem here. We are casting [irange] gimple_code [2, 2] to a gimple_code, and getting: [irange] gimple_code VARYING Couple of issues.. one, we shouldnt bother casting anything if the types are already the same... but still.. the result is incorrect. Tracing it down, it looks like during the casting process, we call: operator_cast::inside_domain_p so see if a min == 2, max == 2, is inside the range of[irange] gimple_code VARYING. THe routine returns false because with strict enum on, we get the min and max of the domain from: wide_int domain_min = wi::to_wide (vrp_val_min (range.type ())); wide_int domain_max = wi::to_wide (vrp_val_max (range.type ()));, which boils down to TYPE_MIN_VALUE (gimple_code) and TYPE_MAX_VALUE (gimple_code) p range.type () $29 = (tree_node *) 0x7fffe9f77c78 (gdb) p print_generic_expr (stderr, $29, 0) gimple_code (gdb) p print_generic_expr (stderr, $29->type_non_common.minval, 0) 0 (gdb) p print_generic_expr (stderr, $29->type_non_common.maxval, 0) 1 So the min value for the enum is set correctly to 0, but the max is set to 1... thus the routine determines that [2, 2] is not within the range of [0, 1] and returns varying.. It seems like the max value for the enum is not being set correctly? If I check right at the point of the failure: (gdb) frame 1 #1 0x01c9c4fe in irange::invert (this=0x7fff1570) at /home/gcc/master/gcc/gcc/value-range.cc:2185 2185 gcc_checking_assert (!undefined_p () && !varying_p ()); (gdb) p type() $42 = (tree_node *) 0x7fffe9f77c78 (gdb) p print_generic_expr (stderr, type(), 0) gimple_code (gdb) p print_generic_expr (stderr, type()->type_non_common.maxval, 0) 1
[Bug c/105972] [12/13 Regression] ICE in lower_stmt, at gimple-low.cc:312 since r12-4608-gb4702276615ff8d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105972 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Keywords|needs-bisection | Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Summary|[12/13 Regression] ICE in |[12/13 Regression] ICE in |lower_stmt, at |lower_stmt, at |gimple-low.cc:312 |gimple-low.cc:312 since ||r12-4608-gb4702276615ff8d4 --- Comment #2 from Martin Liška --- Started with my revision r12-4608-gb4702276615ff8d4, I'll take a look.
[Bug ipa/105978] ICE: nodes with unreleased memory found since r9-4254-g12485662c00914ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105978 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-06-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|ICE: nodes with unreleased |ICE: nodes with unreleased |memory found|memory found since ||r9-4254-g12485662c00914ed --- Comment #1 from Martin Liška --- Started with r9-4254-g12485662c00914ed.
[Bug analyzer/105892] RFE: -fanalyzer could complain about pointer subtraction of pointers to different memory chunks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105892 --- Comment #1 from David Malcolm --- See also CWE 469: https://cwe.mitre.org/data/definitions/469.html
[Bug analyzer/106000] RFE: -fanalyzer should complain about definite buffer overflows/underflows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106000 --- Comment #2 from David Malcolm --- See also: https://cwe.mitre.org/data/definitions/468.html
[Bug analyzer/105900] RFE: -fanalyzer could check malloc sizes when casting the result to a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105900 --- Comment #2 from David Malcolm --- See also: https://cwe.mitre.org/data/definitions/467.html
[Bug rtl-optimization/105952] [12/13 Regression] ICE in sel_redirect_edge_and_branch, at sel-sched-ir.cc:5680
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105952 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-06-16 --- Comment #1 from Martin Liška --- Started with r12-7687-g3a7ba8fd0cda3878, but it likely revealed it.
[Bug c++/106001] [12/13 Regression] ICE: nexpected expression 'static_cast(1)' of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106001 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|[12 Regression] ICE:|[12/13 Regression] ICE: |nexpected expression|nexpected expression |'static_cast(1)' of |'static_cast(1)' of |kind static_cast_expr |kind static_cast_expr CC||mpolacek at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Last reconfirmed||2022-06-16 Target Milestone|--- |12.2 --- Comment #1 from Marek Polacek --- Started with r12-1128-gef8176e0fac935 commit ef8176e0fac935c095cc39f4ecdfd43cdb8cb3f3 Author: Richard Biener Date: Fri May 21 11:33:30 2021 +0200 c++/88601 - [C/C++] __builtin_shufflevector support
[Bug tree-optimization/105940] suggested_unroll_factor applying place looks wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940 Kewen Lin changed: What|Removed |Added Attachment #53126|0 |1 is obsolete|| --- Comment #7 from Kewen Lin --- Created attachment 53152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53152=edit Tested patch but fail with SPEC build
[Bug tree-optimization/105940] suggested_unroll_factor applying place looks wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105940 --- Comment #6 from Kewen Lin --- (In reply to Kewen Lin from comment #4) > (In reply to Richard Biener from comment #2) > > (In reply to Kewen Lin from comment #1) > > > Created attachment 53126 [details] > > > move_applying > > > > LGTM (maybe the suggested unroll factor should be only applied if the > > suggestion was from a matching with/without SLP analysis, or in fact > > vect_analyze_loop_1 should communicate that down - disabling SLP when > > the one suggesting unrolling did the re-analysis). > > Oops, just noticed the nice suggestion. Will make a follow up patch for > this. > It would looks like: > when working out suggested unroll factor, save slp decision into one > passed down variable from vect_analyze_loop_1. > when applying suggested unroll factor, if the save slp is false, directly > ignore slp handlings, otherwise, go the normal slp path but won't start over > for slp off. I tested one patch which was bootstrapped and regress-tested on x86, aarch64 and powerpc64le, but found some failures on SPEC2017 run with rs6000 hackings, the reason to fail is that we can save reduction chain in vect_is_simple_reduction for further analysis in SLP detection, if we aggressively skip SLP related analyses in vect_analyze_loop_2, there is ICE in vectorizable_reduction if (REDUC_GROUP_FIRST_ELEMENT (stmt_info)) gcc_assert (slp_node && REDUC_GROUP_FIRST_ELEMENT (stmt_info) == stmt_info); There seem to be some alternatives: 1) check if applying_suggested_uf && !slp_done_for_suggested_uf initially in vect_analyze_loop_2, if yes, pass slp disabled information down to vect_is_simple_reduction, not to save reduction chain for later slp analysis (not existed). 2) before we are going to do the slp related analyses (vect_analyze_slp etc.), check if applying_suggested_uf && !slp_done_for_suggested_uf, if yes, dissolve LOOP_VINFO_REDUCTION_CHAINS(loop_info). 3) for the case applying_suggested_uf && !slp_done_for_suggested_uf, we still let it go through slp related analyses but not applying suggested unroll factor, only applying for its retry without slp. 3) is simple but seems to be the worst since we still do some useless analyses. 1) can save the reduction chain handlings, seems to be the best, not sure if it's too intrusive, and if there are some similar needs (in future) to do so. 2) is similar to 1), it's to add one common place to undo those previous analysis results which are only for slp analyses and can cause unexpected result if we don't undo it. Any suggestions on this?
[Bug tree-optimization/105990] Dead code elimination failed at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105990 John Klein changed: What|Removed |Added CC||Painololo at protonmail dot com --- Comment #2 from John Klein --- Thanks for the decision.
[PATCH]middle-end simplify complex if expressions where comparisons are inverse of one another.
Hi All,
This optimizes the following sequence
((a < b) & c) | ((a >= b) & d)
into
(a < b ? c : d) & 1
for scalar. On vector we can omit the & 1.
This changes the code generation from
zoo2:
cmp w0, w1
csetw0, lt
csetw1, ge
and w0, w0, w2
and w1, w1, w3
orr w0, w0, w1
ret
into
cmp w0, w1
cselw0, w2, w3, lt
and w0, w0, 1
ret
and significantly reduces the number of selects we have to do in the vector
code.
Bootstrapped Regtested on aarch64-none-linux-gnu,
x86_64-pc-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* fold-const.cc (inverse_conditions_p): Traverse if SSA_NAME.
* match.pd: Add new rule.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/if-compare_1.c: New test.
* gcc.target/aarch64/if-compare_2.c: New test.
--- inline copy of patch --
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index
39a5a52958d87497f301826e706886b290771a2d..f180599b90150acd3ed895a64280aa3255061256
100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -2833,15 +2833,38 @@ compcode_to_comparison (enum comparison_code code)
bool
inverse_conditions_p (const_tree cond1, const_tree cond2)
{
- return (COMPARISON_CLASS_P (cond1)
- && COMPARISON_CLASS_P (cond2)
- && (invert_tree_comparison
- (TREE_CODE (cond1),
- HONOR_NANS (TREE_OPERAND (cond1, 0))) == TREE_CODE (cond2))
- && operand_equal_p (TREE_OPERAND (cond1, 0),
- TREE_OPERAND (cond2, 0), 0)
- && operand_equal_p (TREE_OPERAND (cond1, 1),
- TREE_OPERAND (cond2, 1), 0));
+ if (COMPARISON_CLASS_P (cond1)
+ && COMPARISON_CLASS_P (cond2)
+ && (invert_tree_comparison
+ (TREE_CODE (cond1),
+ HONOR_NANS (TREE_OPERAND (cond1, 0))) == TREE_CODE (cond2))
+ && operand_equal_p (TREE_OPERAND (cond1, 0),
+ TREE_OPERAND (cond2, 0), 0)
+ && operand_equal_p (TREE_OPERAND (cond1, 1),
+ TREE_OPERAND (cond2, 1), 0))
+return true;
+
+ if (TREE_CODE (cond1) == SSA_NAME
+ && TREE_CODE (cond2) == SSA_NAME)
+{
+ gimple *gcond1 = SSA_NAME_DEF_STMT (cond1);
+ gimple *gcond2 = SSA_NAME_DEF_STMT (cond2);
+ if (!is_gimple_assign (gcond1) || !is_gimple_assign (gcond2))
+ return false;
+
+ tree_code code1 = gimple_assign_rhs_code (gcond1);
+ tree_code code2 = gimple_assign_rhs_code (gcond2);
+ return TREE_CODE_CLASS (code1) == tcc_comparison
+&& TREE_CODE_CLASS (code2) == tcc_comparison
+&& invert_tree_comparison (code1,
+ HONOR_NANS (gimple_arg (gcond1, 0))) == code2
+&& operand_equal_p (gimple_arg (gcond1, 0),
+gimple_arg (gcond2, 0), 0)
+&& operand_equal_p (gimple_arg (gcond1, 1),
+gimple_arg (gcond2, 1), 0);
+}
+
+ return false;
}
/* Return a tree for the comparison which is the combination of
diff --git a/gcc/match.pd b/gcc/match.pd
index
6d691d302b339c0e4556b40af158b5208c12d08f..bad49dd348add751d9ec1e3023e34d9ac123194f
100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1160,6 +1160,32 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(convert (bit_and (negate (convert:utype { pmop[0]; }))
(convert:utype @1)))
+/* Fold (((a < b) & c) | ((a >= b) & d)) into (a < b ? c : d) & 1. */
+(simplify
+ (bit_ior
+ (bit_and:c (convert? @0) @2)
+ (bit_and:c (convert? @1) @3))
+ (if (inverse_conditions_p (@0, @1)
+ /* The scalar version has to be canonicalized after vectorization
+ because it makes unconditional loads conditional ones, which
+ means we lose vectorization because the loads may trap. */
+ && canonicalize_math_after_vectorization_p ())
+(bit_and (cond @0 @2 @3) { build_each_one_cst (type); })))
+(simplify
+ (bit_ior
+ (bit_and:c (convert? (vec_cond:s @0 @4 integer_zerop)) @2)
+ (bit_and:c (convert? (vec_cond:s @1 @4 integer_zerop)) @3))
+ (if (inverse_conditions_p (@0, @1)
+ && integer_onep (@4))
+(bit_and (vec_cond @0 @2 @3) @4)))
+/* Fold (((a < b) & c) | ((a >= b) & d)) into a < b ? c : d. */
+(simplify
+ (bit_ior
+ (bit_and:c (convert? (vec_cond:s @0 integer_minus_onep integer_zerop)) @2)
+ (bit_and:c (convert? (vec_cond:s @1 integer_minus_onep integer_zerop)) @3))
+ (if (inverse_conditions_p (@0, @1))
+(vec_cond @0 @2 @3)))
+
/* X % Y is smaller than Y. */
(for cmp (lt ge)
(simplify
diff --git a/gcc/testsuite/gcc.target/aarch64/if-compare_1.c
b/gcc/testsuite/gcc.target/aarch64/if-compare_1.c
new file mode 100644
index
..05a1292fa90c70b14a7985122f43711f55d047ea
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/if-compare_1.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* {
[Bug analyzer/106000] RFE: -fanalyzer should complain about definite buffer overflows/underflows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106000 John Klein changed: What|Removed |Added CC||Painololo at protonmail dot com --- Comment #1 from John Klein --- Thanks for the decision. Saw a similar one at https://www.wildtornado.casino/games/casino_slots/.
[Bug lto/105877] GNU strip breaks -flto -g .o files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105877 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-06-16
[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X' since r12-954-g84fd1b5dff70cd74
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105925
Martin Liška changed:
What|Removed |Added
Summary|[11/12/13 Regression] Could |[11/12/13 Regression] Could
|not convert '{{0, 0.0}}'|not convert '{{0, 0.0}}'
|from '' to 'X' |initializer list>' to 'X'
||since
||r12-954-g84fd1b5dff70cd74
Keywords|needs-bisection |
CC||jason at gcc dot gnu.org
--- Comment #3 from Martin Liška ---
Started with r12-954-g84fd1b5dff70cd74.
[Bug analyzer/101837] [11/12 Regression] ICE with -O3 -fsanitize=undefined -fanalyzer since r11-7941-ge4bb1bd60a9fd1be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101837 Martin Liška changed: What|Removed |Added CC||girgias at php dot net --- Comment #6 from Martin Liška --- *** Bug 105919 has been marked as a duplicate of this bug. ***
[Bug analyzer/105919] Internal compiler error when using -fanalyzer on php-src
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105919 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 101837 ***
[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105925 Martin Liška changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|NEW Last reconfirmed||2022-06-16 Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Sorry, wrong bug.
[Bug analyzer/101837] [11/12 Regression] ICE with -O3 -fsanitize=undefined -fanalyzer since r11-7941-ge4bb1bd60a9fd1be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101837 Martin Liška changed: What|Removed |Added CC||jehova at existiert dot net --- Comment #5 from Martin Liška --- *** Bug 105925 has been marked as a duplicate of this bug. ***
[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105925 Martin Liška changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 101837 ***
[Bug c/106002] New: RFE: complain about incorrect checks of return values (CWE-253)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106002
Bug ID: 106002
Summary: RFE: complain about incorrect checks of return values
(CWE-253)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Some APIs return NULL to signify an error; others return a negative int. It's
possible to mess up by confusing these.
We currently don't warn at -Wall on these:
#include
#include
extern void do_something_with (void *);
int test_1 (void)
{
void *tmp = malloc(1024);
if (tmp < 0 )
return -1;
do_something_with (tmp);
free (tmp);
return 0;
}
int test_2 (void)
{
char buf[256];
if (fgets (buf, sizeof (buf), stdin) < 0)
return -1;
do_something_with (buf);
return 0;
}
where both error checks are testing for < 0, when they should be checking for
NULL; looks to me like we ought to warn for this.
I'm not sure if it's possible to reliably warn for the opposite error without
lots of false positives (checking for pointer NULL, rather than int 0?)
Filing against "c" since I think this could probably happen in the frontends
rather than the analyzer.
See CWE-253:
https://cwe.mitre.org/data/definitions/253.html
[Bug c++/105921] internal compiler error: in cp_parser_template_id, at cp/parser.cc:18362
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105921 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-06-16 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org
Re: [PATCH RFA] ubsan: default to trap on unreachable at -O0 and -Og [PR104642]
On Wed, Jun 15, 2022 at 04:38:49PM -0400, Jason Merrill wrote:
> > I do not like doing it this way, -fsanitize-undefined-trap-on-error is
> > (unfortunately for compatibility with llvm misdesign, users should have
> > ways to control which of the enabled sanitizers should be handled which way,
> > where the 3 ways are runtime diagnostics without abort, runtime diagnostics
> > with abort and __builtin_trap ()) an all or nothing option which affects all
> > the sanitizers.
>
> Makes sense. The first is -fsanitize-recover=, I think, the second is the
> default, and perhaps the third could be -fsanitize-trap=?
-f{,no-}sanitize-recover= is a bitmask, whether some sanitizer recovers or
not. The default is that ubsan sanitizers except for unreachable and return
default to recover on and similarly kasan and hwkasan, other sanitizers
default to no recover.
If we add -f{,no-}sanitize-trap= similar way, we'd need to figure out
what it means if a both bits are set (i.e. we are asked to recover and trap
at the same time). We could error, or silently prefer trap over recover,
etc.
And we'd need to define interaction with -fsanitize-undefined-trap-on-error,
would that be effectively an alias for -fsanitize-trap=all (but if so,
we'd need the silent trap takes priority over recover way)?
> > Furthermore, handling it the UBSan way means we slow down the compiler
> > (enable a bunch of extra passes, like sanopt, ubsan), which is undesirable
> > e.g. for -O0 compilation speed.
>
> The ubsan pass is not enabled for unreachable|return. sanopt does a single
You're right.
> pass over the function to rewrite __builtin_unreachable, but that doesn't
> seem like much overhead.
But I think we are trying to avoid hard any kind of unnecessary whole IL
extra walks, especially for -O0.
> > So, I think -funreachable-traps should be a separate flag and not an alias,
> > enabled by default for -O0 and -Og, which would be handled elsewhere
> > (I'd say e.g. in fold_builtin_0 and perhaps gimple_fold_builtin too to
> > avoid allocating trees unnecessary)
>
> I tried this approach, but it misses some __builtin_unreachable calls added
> by e.g. execute_fixup_cfg; it seems they never get folded by any subsequent
> pass.
We could also expand BUILT_IN_UNREACHABLE as BUILT_IN_TRAP during expansion
to catch whatever isn't caught by folding.
> > and would be done if
> > flag_unreachable_traps && !sanitize_flag_p (SANITIZE_UNREACHABLE),
> > just replacing that __builtin_unreachable call with __builtin_trap.
> > For the function ends in fact under those conditions we could emit
> > __builtin_trap right away instead of emitting __builtin_unreachable
> > and waiting on folding it later to __builtin_trap.
>
> Sure, but I generally prefer to change fewer places.
I'd say this would be very small change and the fastest + most reliable.
Simply replace all builtin_decl_implicit (BUILT_IN_UNREACHABLE) calls
with builtin_decl_unreachable () (12 of them) and define
tree
builtin_decl_unreachable ()
{
enum built_in_function fncode = BUILT_IN_UNREACHABLE;
if (sanitize_flag_p (SANITIZE_UNREACHABLE))
{
if (flag_sanitize_undefined_trap_on_error)
fncode = BUILT_IN_TRAP;
/* Otherwise we want __builtin_unreachable () later folded into
__ubsan_handle_builtin_unreachable with extra args. */
}
else if (flag_unreachable_traps)
fncode = BUILT_IN_TRAP;
return builtin_decl_implicit (fncode);
}
and that's it (well, also in build_common_builtin_nodes
declare __builtin_trap for FEs that don't do that - like it is done
for __builtin_unreachable).
Jakub
[Bug c++/105998] [10/11/12/13 Regression] ICE: in as_a, at machmode.h:365 with vector arithmetics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105998 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Last reconfirmed||2022-06-16 Status|UNCONFIRMED |NEW Target Milestone|--- |10.4 --- Comment #1 from Marek Polacek --- Started with commit 315aa691f486bfe71bae0a5fc8828db26daebb56 Author: Jakub Jelinek Date: Mon Jul 23 09:48:56 2018 +0200 re PR c++/86569 (-Wnonnull-compare affects code generation since r233684) PR c++/86569 * cp-gimplify.c (cp_fold): Don't fold comparisons into other kind of expressions other than INTEGER_CST regardless of TREE_NO_WARNING or warn_nonnull_compare. * g++.dg/warn/Wnonnull-compare-9.C: New test. From-SVN: r262928
[Bug c++/105912] internal compiler error: in extract_call_expr, at cp/call.cc:7114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105912 Martin Liška changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- (In reply to Marek Polacek from comment #3) > The ICE started with r277733 > > commit f968ef9b8df2bc2287e5e7e87299e5a2a44e8c94 > Author: Jakub Jelinek > Date: Sat Nov 2 00:28:20 2019 +0100 > > PR c++/88335 - Implement P1073R3: Immediate functions @Marek: Please add to CC author of a revision you bisected to.
[Bug middle-end/105902] Documentation for the RTL front-end was never added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105902 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-06-16 CC||marxin at gcc dot gnu.org
[Bug c++/106001] New: [12 Regression] ICE: nexpected expression 'static_cast(1)' of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106001
Bug ID: 106001
Summary: [12 Regression] ICE: nexpected expression
'static_cast(1)' of kind static_cast_expr
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with the gcc-12 branch 20220616 on x86_64-linux-gnu, building the spoa
package:
$ cat simd_alignment_engine_dispatch.ii
template void _mmxxx_prefix_max() {
char simde__tmp_a__0 =
__builtin_shufflevector(simde__tmp_a__0, 0, static_cast(1))
$ LANG=C g++ -c -msse2 -O0 -std=c++11 simd_alignment_engine_dispatch.ii
simd_alignment_engine_dispatch.ii: In function 'void _mmxxx_prefix_max()':
simd_alignment_engine_dispatch.ii:3:71: internal compiler error: unexpected
expression 'static_cast(1)' of kind static_cast_expr
3 | __builtin_shufflevector(simde__tmp_a__0, 0, static_cast(1))
| ^
0x6d9b71 cxx_eval_constant_expression
../../src/gcc/cp/constexpr.cc:7587
0x6d9ec0 cxx_eval_outermost_constant_expr
../../src/gcc/cp/constexpr.cc:7824
0x6dd267 maybe_constant_value(tree_node*, tree_node*, bool)
../../src/gcc/cp/constexpr.cc:8103
0x867381 build_x_shufflevector(unsigned int, vec*,
int)
../../src/gcc/cp/typeck.cc:6337
0x7cf33e cp_parser_postfix_expression
../../src/gcc/cp/parser.cc:7496
0x7b8096 cp_parser_binary_expression
../../src/gcc/cp/parser.cc:10035
0x7b889e cp_parser_assignment_expression
../../src/gcc/cp/parser.cc:10339
0x7ba3c9 cp_parser_constant_expression
../../src/gcc/cp/parser.cc:10642
0x7ba461 cp_parser_initializer_clause
../../src/gcc/cp/parser.cc:25223
0x7bd44c cp_parser_initializer
../../src/gcc/cp/parser.cc:25163
0x7eaf5f cp_parser_init_declarator
../../src/gcc/cp/parser.cc:22773
0x7c73b8 cp_parser_simple_declaration
../../src/gcc/cp/parser.cc:15280
0x7c8fe0 cp_parser_declaration_statement
../../src/gcc/cp/parser.cc:14361
0x7c97cc cp_parser_statement
../../src/gcc/cp/parser.cc:12446
0x7ca6ed cp_parser_statement_seq_opt
../../src/gcc/cp/parser.cc:12850
0x7ca79f cp_parser_compound_statement
../../src/gcc/cp/parser.cc:12802
0x7e91c3 cp_parser_function_body
../../src/gcc/cp/parser.cc:25069
0x7e91c3 cp_parser_ctor_initializer_opt_and_function_body
../../src/gcc/cp/parser.cc:25120
0x7ea30e cp_parser_function_definition_after_declarator
../../src/gcc/cp/parser.cc:31252
0x7eb376 cp_parser_function_definition_from_specifiers_and_declarator
../../src/gcc/cp/parser.cc:31168
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
// Target: x86_64-linux-gnu
// Configured with: ../src/configure -v --with-pkgversion='Debian 12.1.0-4'
--with-bugurl=file:/
//usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --p
refix=/usr --with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --ena
ble-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug -
-enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable
-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checki
ng=release --with-target-system-zlib=auto --enable-objc-gc=auto
--enable-multiarch --disable-wer
ror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-m
ultilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-8ErGg2/gcc-12-12.1
.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-8ErGg2/gcc-12-12.1.0/debian/tmp-gcn/usr
--en
able-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
// Thread model: posix
// Supported LTO compression algorithms: zlib zstd
// gcc version 12.1.0 (Debian 12.1.0-4)
[Bug analyzer/106000] New: RFE: -fanalyzer should complain about definite buffer overflows/underflows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106000 Bug ID: 106000 Summary: RFE: -fanalyzer should complain about definite buffer overflows/underflows Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Blocks: 105887 Target Milestone: --- I attempted to implement buffer-overflow (and underflow) detection for GCC 12, trying to categorize all region accesses as either: (a) definitely in-bounds (b) definitely out-of-bounds (c) possibly out-of-bounds Unfortunately my implementation led to a "wall of noise" level of warnings from (c). It now strikes me that we could at least implement warnings for (b) - where we can see definite problems, and that this might be at least somewhat useful. Compare with: https://clang.llvm.org/docs/analyzer/checkers.html#alpha-security-arraybound-c https://clang.llvm.org/docs/analyzer/checkers.html#alpha-security-arrayboundv2-c Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105887 [Bug 105887] [meta-bug] clang analyzer warnings that GCC's -fanalyzer could implement
[Bug rtl-optimization/105822] ICE in maybe_record_trace_start, at dwarf2cfi.cc:2579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105822 Martin Liška changed: What|Removed |Added CC||aoliva at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r13-380-g90a8eab4a1292430.
[Bug analyzer/105900] RFE: -fanalyzer could check malloc sizes when casting the result to a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105900 --- Comment #1 from David Malcolm --- See https://cwe.mitre.org/data/definitions/131.html e.g. example 5. See also: https://clang.llvm.org/docs/analyzer/checkers.html#alpha-security-mallocoverflow-c (CWE 131's example 2 has a case of this)
[Bug fortran/105807] ICE / error when defining a class containing polymorphic components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105807 Martin Liška changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r12-4464-g017665f63047ce47, it was rejected before the revision.
[Bug target/105981] [10/11/12 regression] Wrong code from gen_cpymem_ldrd_strd() with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|10.5|10.4 --- Comment #7 from Richard Earnshaw --- Fixed on all active release branches.
[Bug c++/105798] Add new -Wshadow for data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105798 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2022-06-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug target/105981] [10/11/12 regression] Wrong code from gen_cpymem_ldrd_strd() with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:20ece449e06f2d0dd0c50db0203d13b4e4ff2d96 commit r10-10850-g20ece449e06f2d0dd0c50db0203d13b4e4ff2d96 Author: Richard Earnshaw Date: Wed Jun 15 16:07:20 2022 +0100 arm: big-endian issue in gen_cpymem_ldrd_strd [PR105981] The code in gen_cpymem_ldrd_strd has been incorrect for big-endian since r230663. The problem is that we use gen_lowpart, etc. to split the 64-bit quantity, but fail to account for the fact that these routines are really dealing with 64-bit /values/ and in big-endian the ordering of the sub-registers changes. To fix this, I've renamed the conceptually misnamed low_reg and hi_reg as first_reg and second_reg, and then used different logic for big-endian targets to initialize these values. This makes the logic clearer than trying to think about high bits and low bits. gcc/ChangeLog: PR target/105981 * config/arm/arm.c (gen_cpymem_ldrd_strd): Rename low_reg and hi_reg to first_reg and second_reg respectively. Initialize them correctly when generating big-endian code. (cherry picked from commit 8aaa948059a8b5f0a62ad010d0aa6346b7ac9cd3)
[Bug target/105981] [10/11/12 regression] Wrong code from gen_cpymem_ldrd_strd() with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:2a9c9ed732d6a7f4565a286bdeb953f08fbe8fb9 commit r11-10074-g2a9c9ed732d6a7f4565a286bdeb953f08fbe8fb9 Author: Richard Earnshaw Date: Wed Jun 15 16:07:20 2022 +0100 arm: big-endian issue in gen_cpymem_ldrd_strd [PR105981] The code in gen_cpymem_ldrd_strd has been incorrect for big-endian since r230663. The problem is that we use gen_lowpart, etc. to split the 64-bit quantity, but fail to account for the fact that these routines are really dealing with 64-bit /values/ and in big-endian the ordering of the sub-registers changes. To fix this, I've renamed the conceptually misnamed low_reg and hi_reg as first_reg and second_reg, and then used different logic for big-endian targets to initialize these values. This makes the logic clearer than trying to think about high bits and low bits. gcc/ChangeLog: PR target/105981 * config/arm/arm.c (gen_cpymem_ldrd_strd): Rename low_reg and hi_reg to first_reg and second_reg respectively. Initialize them correctly when generating big-endian code. (cherry picked from commit 8aaa948059a8b5f0a62ad010d0aa6346b7ac9cd3)
[Bug target/105981] [10/11/12 regression] Wrong code from gen_cpymem_ldrd_strd() with -mbig-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:723c1d6284ca9f79cc35bf7bf49f391417773f83 commit r12-8488-g723c1d6284ca9f79cc35bf7bf49f391417773f83 Author: Richard Earnshaw Date: Wed Jun 15 16:07:20 2022 +0100 arm: big-endian issue in gen_cpymem_ldrd_strd [PR105981] The code in gen_cpymem_ldrd_strd has been incorrect for big-endian since r230663. The problem is that we use gen_lowpart, etc. to split the 64-bit quantity, but fail to account for the fact that these routines are really dealing with 64-bit /values/ and in big-endian the ordering of the sub-registers changes. To fix this, I've renamed the conceptually misnamed low_reg and hi_reg as first_reg and second_reg, and then used different logic for big-endian targets to initialize these values. This makes the logic clearer than trying to think about high bits and low bits. gcc/ChangeLog: PR target/105981 * config/arm/arm.cc (gen_cpymem_ldrd_strd): Rename low_reg and hi_reg to first_reg and second_reg respectively. Initialize them correctly when generating big-endian code. (cherry picked from commit 8aaa948059a8b5f0a62ad010d0aa6346b7ac9cd3)
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 105983, which changed state. Bug 105983 Summary: Failure to optimize (b != 0) && (a >= b) as well as the same pattern with binary and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/105983] Failure to optimize (b != 0) && (a >= b) as well as the same pattern with binary and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug middle-end/105984] [13 Regression] wrong code with __builtin_mul_overflow_p() at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105984 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed, thanks for the report.
