On 4/28/23 11:23, Florian Weimer wrote:
> * Martin Liška:
>
>> On 4/26/23 20:31, Florian Weimer wrote:
>>> * Martin Liška:
>>>
On 11/15/22 16:47, Martin Liška wrote:
> Hi.
>
> I've just pushed libsanitizer update that was tested on x86_64-linux and
> ppc64le-linux systems.
>>
Thanks all for comments. Summary what I have learned from the mail thread as
below. Please feel free to correct me if any mistake.
1. The RVV VMSET has tail policy and the high bits of target register can be
overridden to 1 or retain the value they held according to the ISA.
2. The semantics of
On Tue, Nov 15, 2022 at 7:47 AM Martin Liška wrote:
>
> Hi.
>
> I've just pushed libsanitizer update that was tested on x86_64-linux and
> ppc64le-linux systems.
> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with
> abidiff.
This broke hwasan on aarch64. See https://gcc.
On 11/30/22 10:18, apinski--- via Gcc-patches wrote:
From: Andrew Pinski
The problem here is the code which handles {"a"} is supposed
to handle the case where the is something after the string but
it only handles the case where there is another string so
we go down the other path and error o
On 11/30/22 10:18, apinski--- via Gcc-patches wrote:
From: Andrew Pinski
So char arrays are not the only type that be initialized from {"a"}.
We can have wchar_t (L"") and char16_t (u"") types too. So let's
print out the type of the array instead of just saying char.
Note in the testsuite I
On 12/5/22 06:43, Joakim Nohlgård wrote:
Fall back to ld -r if ld -shared fails during configure. The check for
HAVE_LD_RO_RW_SECTION_MIXING can fail on targets where ld does not
support shared objects, even though the answer to the test should be
'read-write'. One such target is riscv64-unkno
On 4/28/23 12:45, Hans Boehm wrote:
We're certainly pushing for the same ABI (A.6 + trailing fence on store)
in LLVM as well. I'm about to upload a pull request for the psABI
document that describes this version of the ABI, and a bit of the
rationale for it. I'll attach the current draft her
On 4/28/23 15:42, Hans Boehm wrote:
The concern with making the new behavior non-default is of course that
the generated code will eventually end up on an A.7-capable platform.
Yea, certainly a significant concern in general, though probably not for
Ventana. I expect we'll have folks rebuild
On 1/12/23 09:02, Longjun Luo via Gcc-patches wrote:
From 0821df518b264e754d698d399f98be1a62945e32 Mon Sep 17 00:00:00 2001
From: Longjun Luo
Date: Thu, 12 Jan 2023 23:59:54 +0800
Subject: [PATCH] libcpp: suppress builtin macro redefined warnings for
__LINE__
As implied in
gcc.gnu.org/leg
On 3/16/23 21:39, Jiufu Guo wrote:
Hi,
When assigning a parameter to a variable, or assigning a variable to
return value with struct type, and the parameter/return is passed
through registers.
For this kind of case, it would be better to use the nature mode of
the registers to move the conten
On 4/28/23 11:02, Andrew Pinski via Gcc-patches wrote:
While moving working on moving
cond_removal_in_builtin_zero_pattern to match, I noticed
that functions were not allowed to move as we reject all
non-assignments.
This changes to allowing a few calls which are known not
to throw/trap. Right
On 4/28/23 11:02, Andrew Pinski via Gcc-patches wrote:
This adds the patterns for
POPCOUNT BSWAP FFS PARITY CLZ and CTZ.
For "a != 0 ? FUNC(a) : CST".
CLRSB, CLRSBL, and CLRSBLL will be moved next.
Note this is not enough to remove
cond_removal_in_builtin_zero_pattern as we need to handle
the
Similarly to libasan.so, libhwasan.so also utilizes some
of the symbols from lsan library.
PR sanitizer/109674
libsanitizer/ChangeLog:
* hwasan/Makefile.am: Depend on liblsan.
* hwasan/Makefile.in: Re-generate.
---
libsanitizer/hwasan/Makefile.am | 2 +-
libsanitizer/hwa
On 4/19/23 21:58, liuhongt via Gcc-patches wrote:
Use swap_communattive_operands_p for canonicalization. When both value
has same operand precedence value, then first bit in the mask should
select first operand.
The canonicalization should help backends for pattern match. .i.e. x86
backend ha
gcc/testsuite/ChangeLog:
* c-c++-common/hwasan/asan-pr70541.c: Adjust wording of expected
output.
* c-c++-common/hwasan/heap-overflow.c: Likewise.
* c-c++-common/hwasan/sanity-check-pure-c.c: Likewise.
* c-c++-common/hwasan/use-after-free.c: Likewise.
---
g
On 4/28/23 04:44, Tamar Christina via Gcc-patches wrote:
Hi All,
This updates the build system to split up match.pd files into chunks of 10.
This also introduces a new flag --with-matchpd-partitions which can be used to
change the number of partitions.
For the analysis of why 10 please look
On 4/23/23 10:47, Segher Boessenkool wrote:
This minimal patch enables LRA for all targets. It does not clean up
the target code, nor does it do anything to generic code: it just
deletes all target definitions of TARGET_LRA_P.
There are three kinds of changes:
1) Targets that already always
Ok for 12.3 ?
Am Mittwoch, dem 19.04.2023 um 18:39 +0200 schrieb Martin Uecker:
> Ok to cherrypick for 12? It is in GCC 13 and fixes an
> annoying ICE.
>
> Martin
>
>
>
> Here is a fix for PR105660.
>
> Bootstrapped and regression tested on x86-64.
>
>
> Fix ICE related to implicit
This ports the clrsb builtin part of builtin_zero_pattern
to match.pd. A simple pattern to port.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* match.pd (a != 0 ? CLRSB(a) : CST -> CLRSB(a)): New
pattern.
---
gcc/match.pd | 8
1 fi
When I added diamond shaped form bb to match_simplify_replacement,
I copied the code to move the statement rather than factoring it
out to a new function. This does the refactoring to a new function
to avoid the duplicated code. It will make adding support for having
two statements to move easier (
While looking at differences between what minmax_replacement
and match_simplify_replacement does. I noticed that they sometimes
chose different edges to remove. I decided we should be able to do
better and be able to remove both empty basic blocks in the
case of match_simplify_replacement as that m
When I converted xstormy16's neghi2 pattern from a define_expand to a
define_insn, I forgot that define_expand implicitly produces a
sequence of instructions, but a define_insn is an implicit parallel,
thereby messing up the clobber (reg:BI CARRY_REG), which can then cause
an ICE in the auto-gener
On 4/30/23 12:30, Jeff Law wrote:
On 1/12/23 09:02, Longjun Luo via Gcc-patches wrote:
From 0821df518b264e754d698d399f98be1a62945e32 Mon Sep 17 00:00:00 2001
From: Longjun Luo
Date: Thu, 12 Jan 2023 23:59:54 +0800
Subject: [PATCH] libcpp: suppress builtin macro redefined warnings for
__
On Sun, Apr 30, 2023 at 4:15 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 4/30/23 12:30, Jeff Law wrote:
> >
> >
> > On 1/12/23 09:02, Longjun Luo via Gcc-patches wrote:
> >> From 0821df518b264e754d698d399f98be1a62945e32 Mon Sep 17 00:00:00 2001
> >> From: Longjun Luo
> >> Date: Thu, 12 Jan 202
gcc/ChangeLog:
* tree-ssa-loop-niter.cc (refine_value_range_using_guard): Remove
kind() call.
(determine_value_range): Same.
(record_nonwrapping_iv): Same.
(infer_loop_bounds_from_signedness): Same.
(scev_var_range_cant_overflow): Same.
* tre
gcc/ChangeLog:
* value-range.cc (irange::irange_set_anti_range): Remove uses of
tree_lower_bound and tree_upper_bound.
(irange::verify_range): Same.
(irange::operator==): Same.
(irange::singleton_p): Same.
* value-range.h (irange::tree_lower_bound):
gcc/ChangeLog:
* vr-values.cc (check_for_binary_op_overflow): Tidy up by using
ranger API.
(compare_ranges): Delete.
(compare_range_with_value): Delete.
(bounds_of_var_in_loop): Tidy up by using ranger API.
(simplify_using_ranges::fold_cond_with_ops)
[tl;dr: This is a rewrite of value-range-storage.* such that global
ranges and the internal ranger cache can use the same efficient
storage mechanism. It is optimized such that when wide_ints are
dropped into irange, the copying back and forth from storage will be
very fast, while being able to ho
Now that anti-ranges are no more and iranges contain wide_ints instead
of trees, various cleanups are possible. This is one of a handful of
patches improving the performance of irange::set() which is not on a
hot path, but quite sensitive because it is so pervasive.
gcc/ChangeLog:
* gimp
This patch removes all uses of vrp_val_{min,max} in favor for a
irange_val_* which are wide_int based. This will leave only one use
of vrp_val_* which returns trees in range_of_ssa_name_with_loop_info()
because it needs to work with non-integers (floats, etc). In a
follow-up patch, this function
gcc/ChangeLog:
* value-range.cc (irange::irange_union): Rename to...
(irange::union_): ...this.
(irange::irange_intersect): Rename to...
(irange::intersect): ...this.
* value-range.h (irange::union_): Delete.
(irange::intersect): Delete.
---
gcc/val
gcc/ChangeLog:
* range-op.cc (update_known_bitmask): Adjust for irange containing
wide_ints internally.
* tree-ssanames.cc (set_nonzero_bits): Same.
* tree-ssanames.h (set_nonzero_bits): Same.
* value-range-storage.cc (irange_storage::set_irange): Same.
gcc/ChangeLog:
* vr-values.cc (bounds_of_var_in_loop): Convert to irange API.
---
gcc/vr-values.cc | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/gcc/vr-values.cc b/gcc/vr-values.cc
index 7f623102ac6..3d28198f9f5 100644
--- a/gcc/vr-values.cc
+++ b/gcc/vr-value
Little by little, bounds_of_var_in_loop() has grown into an
unmaintainable mess. This patch rewrites the code to use the relevant
APIs as well as refactor it to make it more readable.
gcc/ChangeLog:
* gimple-range-fold.cc (tree_lower_bound): Delete.
(tree_upper_bound): Delete.
irange::set_nonzero is used everywhere and benefits immensely from
inlining.
gcc/ChangeLog:
* value-range.h (irange::set_nonzero): Inline.
---
gcc/value-range.h | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/gcc/value-range.h b/gcc/value-range.h
This converts the irange API to use wide_ints exclusively, along with
its users.
This patch will slow down VRP, as there will be more useless
wide_int to tree conversions. However, this slowdown is only
temporary, as a follow-up patch will convert the internal
representation of iranges to wide_in
gcc/ChangeLog:
* value-range.h (class int_range): Remove gt_ggc_mx and gt_pch_nx
friends.
---
gcc/value-range.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index 5cff50e6d03..ab8d7d3c5dc 100644
--- a/gcc/value-range.h
+++ b/gcc/val
37 matches
Mail list logo
