On Apr 23, 2024, "Kewen.Lin" wrote:
>> -/* { dg-do run } */
>> +/* { dg-do compile { target { ! vsx_hw } } } */
>> +/* { dg-do run { target vsx_hw } } */
>> /* { dg-require-effective-target powerpc_vsx_ok } */
> Nit: It's useless to check powerpc_vsx_ok for vsx_hw, so powerpc_vsx_ok check
> can
On Apr 23, 2024, "Kewen.Lin" wrote:
>> --- a/gcc/testsuite/gcc.dg/torture/pr91323.c
>> +++ b/gcc/testsuite/gcc.dg/torture/pr91323.c
>> @@ -1,4 +1,5 @@
>> -/* { dg-do run } */
>> +/* { dg-do run { xfail powerpc*-*-* } } */
>> +/* The ppc xfail is because of PR target/58684. */
> OK, though the p
On Apr 23, 2024, Iain Sandoe wrote:
>>> --- a/gcc/testsuite/gcc.target/powerpc/pr46728-10.c
>>> +++ b/gcc/testsuite/gcc.target/powerpc/pr46728-10.c
>>> @@ -1,6 +1,7 @@
>>> /* { dg-do run } */
>>> /* { dg-skip-if "-mpowerpc-gpopt not supported" { powerpc*-*-darwin* } } */
>>> /* { dg-options "-O2
On Apr 23, 2024, Hans-Peter Nilsson wrote:
> (We could also fix the predicate description to actually say
> "for all floating-point modes" and/or split the predicate into
> mode-specific variants, etc. ;-)
Yeah, I suppose that could make sense.
> MMIX has sqrtdf2 but not sqrtsf2, and the latt
On Apr 24, 2024, "Kewen.Lin" wrote:
> For !has_arch_pwr7 case, it still adopts peeling but as the comment (one line
> above)
> shows the original intention of this case is to expect not profitable for
> peeling
> so it's not expected to be handled here, can we just tweak the loop bound
> inste
On Sun, Apr 28, 2024 at 7:47 AM liuhongt wrote:
>
> So when both source operand and dest operand require avx512 MASK_REGS, RA
> can allocate MASK_REGS register instead of GPR to avoid reload it from
> GPR to MASK_REGS.
> It's similar as what did for logic patterns.
>
> Bootstrapped and regtested o
On Apr 23, 2024, "Kewen.Lin" wrote:
> This patch seemed to miss to CC gcc-patches list. :)
Oops, sorry, thanks for catching that.
Here it is. FTR, you've already responded suggesting an apparent
preference for addressing PR105359, but since I meant to contribute it,
I'm reposting is to gcc-pat
The fact that both options accept negative forms suggests that maybe
they aren't negative forms of each other. They are, but that isn't
clear even by examining common.opt. Use NegativeAlias to make it
abundantly clear.
The 'Optimization' keyword next to freg-struct-return was the only
thing th
This patch adds the smin/smax RTL mode for the
min/max.fmt instructions.
Also, since the min/max.fmt instrucions applies to the
IEEE 754-2008 "minNum" and "maxNum" operations, this
patch also provides the new "fmin3" and
"fmax3" modes.
gcc/ChangeLog:
* config/mips/i6400.md (i6400_fpu_min
This patch fixes PR tree-optimization/113673, a P2 ice-on-valid regression
caused by load merging of (ptr[0]<<8)+ptr[1] when -ftrapv has been
specified. When the operator is | or ^ this is safe, but for addition
of signed integer types, a trap may be generated/required, so merging this
idiom into
Hi,
on 2024/4/28 16:14, Alexandre Oliva wrote:
> On Apr 24, 2024, "Kewen.Lin" wrote:
>
>> For !has_arch_pwr7 case, it still adopts peeling but as the comment (one
>> line above)
>> shows the original intention of this case is to expect not profitable for
>> peeling
>> so it's not expected to b
Hi,
on 2024/4/28 16:20, Alexandre Oliva wrote:
> On Apr 23, 2024, "Kewen.Lin" wrote:
>
>> This patch seemed to miss to CC gcc-patches list. :)
>
> Oops, sorry, thanks for catching that.
>
> Here it is. FTR, you've already responded suggesting an apparent
> preference for addressing PR105359,
gcc/ChangeLog:
* doc/contrib.texi: Update David Binderman's entry.
Pushed.
Gerald
---
gcc/doc/contrib.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/contrib.texi b/gcc/doc/contrib.texi
index 2a15fd05883..32e89d6df25 100644
--- a/gcc/doc/contrib.texi
Kinding ping for SAT_ADD.
Pan
-Original Message-
From: Li, Pan2
Sent: Sunday, April 7, 2024 3:03 PM
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; Wang, Yanzhang
; tamar.christ...@arm.com; richard.guent...@gmail.com;
Liu, Hongtao ; Li, Pan2
Subject: [PATC
Kindly ping^^ for this ice fix.
Pan
-Original Message-
From: Li, Pan2
Sent: Thursday, April 18, 2024 9:46 AM
To: Jeff Law ; Robin Dapp ;
gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com;
Liu, Hongtao
Subject: RE: [PATCH v2] DSE: Bugfi
On Thu, Apr 25, 2024 at 1:15 PM Björn Schäpers wrote:
>
> > Attached is the combined version of the two patches, only implementing the
> > variant with the tlhelp32 API.
> >
> > Tested on x86 and x86_64 windows.
> >
> > Kind regards,
> > Björn.
>
> A friendly ping.
Thanks. Committed as follows.
PR target/113179.
In `store_bit_field_using_insv`, we just use SUBREG if value_mode
>= op_mode, while in some ports, a sign_extend will be needed,
such as MIPS64:
If either GPR rs or GPR rt does not contain sign-extended 32-bit
values (bits 63..31 equal), then the result of the operation is
Fix some Value_Range's that we know ahead of time will be only
integers. This avoids using the polymorphic Value_Range unnecessarily
gcc/ChangeLog:
* gimple-ssa-warn-access.cc (check_nul_terminated_array): Make
Value_Range an int_range.
(memmodel_to_uhwi): Same
* tree-ss
Now that we have a vrange storage class to save ranges in long-term
memory, there is no need for GTY markers for any of the vrange
classes, since they should never live in GC.
gcc/ChangeLog:
* value-range-storage.h: Remove friends.
* value-range.cc (gt_ggc_mx): Remove.
(gt
Any range can theoretically have a bitmask of set bits. This patch
moves the bitmask accessors to the base class. This cleans up some
users in IPA*, and will provide a cleaner interface when prange is in
place.
gcc/ChangeLog:
* ipa-cp.cc (propagate_bits_across_jump_function): Access bit
This patch adds vrange::lbound() and vrange::ubound() that return
trees. These can be used in generic code that is type agnostic, and
avoids special casing for pointers and integers in places where we
handle both. It also cleans up a wart in the Value_Range class.
gcc/ChangeLog:
* tree-
prange will also have bitmasks, so it will need to use get_bitmask_from_range.
gcc/ChangeLog:
* value-range.cc (get_bitmask_from_range): Move out of irange class.
(irange::get_bitmask): Call function instead of internal method.
* value-range.h (class irange): Remove get_bi
Richi mentioned in PR113476 that it would be cleaner to move the
destructor from int_range to the base class. Although this isn't
strictly necessary, as there are no users, it is good to future proof
things, and the overall impact is miniscule.
gcc/ChangeLog:
* value-range.h (vrange::~vr
We have a sanity check in the irange storage code to make sure that
reading back a cache entry we have just written to yields exactly the
same range. There's no need to do this only for integers. This patch
moves the code to a more generic place.
However, doing so tickles a latent bug in the fra
Move some code out of the irange pretty printers so it can be shared
with pointers.
gcc/ChangeLog:
* value-range-pretty-print.cc (print_int_bound): New.
(print_irange_bitmasks): New.
(vrange_printer::print_irange_bound): Remove.
(vrange_printer::print_irange_bitmas
Make range_includes_zero_p take an argument instead of a pointer for
consistency in the range-op code.
gcc/ChangeLog:
* gimple-range-op.cc (cfn_clz::fold_range): Change
range_includes_zero_p argument to a reference.
(cfn_ctz::fold_range): Same.
* range-op.cc (opera
In preparation for prange, make get_legacy_range take a generic
vrange, not just an irange.
gcc/ChangeLog:
* value-range.cc (get_legacy_range): Make static and add another
version of get_legacy_range that takes a vrange.
* value-range.h (class irange): Remove unnecessary f
Explicitly make vrange an abstract class. This involves fleshing out
the unsupported_range overrides which we were inheriting by default
from vrange.
gcc/ChangeLog:
* value-range.cc (unsupported_range::accept): Move down.
(vrange::contains_p): Rename to...
(unsupported_r
Accept a vrange, as this will be used for either integers or pointers.
gcc/ChangeLog:
* value-range.h (range_includes_zero_p): Accept vrange.
---
gcc/value-range.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index ede90a4
Remove legacy range_zero and range_nonzero as they return by value,
which make it not work in a separate irange and prange world. Also,
we already have set_zero and set_nonzero methods in vrange.
gcc/ChangeLog:
* range-op-ptr.cc (pointer_plus_operator::wi_fold): Use method
range
There are some irange uses that should be Value_Range, because they
can be either integers or pointers. This will become a problem when
prange comes live.
gcc/ChangeLog:
* tree-ssa-loop-split.cc (split_at_bb_p): Make int_range a Value_Range.
* tree-ssa-strlen.cc (get_range): Same
Conditional operators are always boolean, regardless of their
operands. Getting the type wrong is not currently a problem, but will
be when prange's can no longer store an integer.
gcc/ChangeLog:
* vr-values.cc (simplify_using_ranges::fold_cond_with_ops): Remove
type from range_t
As per the documentation, irange_bitmask must have the unknown bits in
the mask set to 0 in the value field. Even though we say we must have
normalized value/mask bits, we don't enforce it, opting to normalize
on the fly in union and intersect. Avoiding this lazy enforcing as
well as the extra sa
In this cycle, we will be contributing ranges for pointers (prange),
to disambiguate pointers from integers in a range. Initially they
will behave exactly as they do now, with just two integer end points
and a bitmask, but eventually we will track points-to info in a less
hacky manner than what we
The polymorphic Value_Range object takes a tree type at construction
so it can determine what type of range to use (currently irange or
frange). It seems a few of the types are slightly off. This isn't a
problem now, because IPA only cares about integers and pointers, which
can both live in an ir
Hi All,
Could this be looked at quickly? The timing of this regression is more than
a little embarrassing on the eve of the 14.1 release. The testcase and the
comment in gfc_trans_class_init_assign explain what this problem is all
about and how the patch fixes it.
OK for 15-branch and backporting
The extension parsing table entries for a range of Zic* extensions
does not match the mask definition in riscv.opt.
This results in broken TARGET_ZIC* macros, because the values of
riscv_zi_subext and riscv_zicmo_subext are set wrong.
This patch fixes this by moving Zic64b into riscv_zicmo_subext
This commit changes the Makefiles generated by lto-wrapper to no longer use
the "mv" and "touch" shell commands. These don't exist on Windows, so when the
Makefile attempts to call them, it results in errors like:
The system cannot find the file specified.
This problem only manifested when calling
This commit adds a new option to the driver that truncates one file after
linking.
Tested likeso:
$ gcc hello.c -c
$ du -h hello.o
4.0K hello.o
$ gcc hello.o -truncate hello.o
$ ./a.out
Hello world
$ du -h hello.o
$ 0 hello.o
$ gcc hello.o -truncate
gcc: error: missing filename after '-trunca
29 Apr 2024 12:16:26 am Peter Damianov :
This commit adds a new option to the driver that truncates one file
after
linking.
Tested likeso:
$ gcc hello.c -c
$ du -h hello.o
4.0K hello.o
$ gcc hello.o -truncate hello.o
$ ./a.out
Hello world
$ du -h hello.o
$ 0 hello.o
$ gcc hello.o -truncat
Signed-off-by: Peter Damianov
---
Fixes these warnings:
../../gcc/gcc/../libgcc/libgcov-util.c: In function 'void tag_counters(unsigned
int, int)':
../../gcc/gcc/../libgcc/libgcov-util.c:214:59: warning: 'void* calloc(size_t,
size_t)' sizes specified with 'sizeof' in the earlier argument and n
Jeff Law 于2024年1月3日周三 01:00写道：
>
>
>
> On 1/1/24 09:48, YunQiang Su wrote:
> > When building multilib libraries, CC/CXX etc are set with an option
> > -B*/lib/, instead of -B/lib/.
> > This will make some trouble in some case, for example building
> > cross toolchain based on Debian's cross packag
Xi Ruoyao 于2024年3月26日周二 18:10写道：
>
> On Tue, 2024-03-26 at 11:15 +0800, YunQiang Su wrote:
>
> /* snip */
>
> > With -ffinite-math-only -fno-signed-zeros, it does work with
> > x >= y ? x : y
> > while without `-ffinite-math-only -fno-signed-zeros`, it cannot.
> > @Xi Ruoyao Is it expected by
I will apply this patch.
While we still have a problem about
```
float max(float a, float b) { return a>=b?a:b; }
```
If it is compiled with `-ffinite-math-only -fsigned-zeros -O2
-mips32r6 -mabi=32`,
`max.s` can be used.
The max.fmt/min.fmt of MIPSr6 can process +0/-0 correctly.
OK for trunk, and my understanding is that flag isn't really used in
code gen yet, so it's not necessary to port to GCC 14 branch?
On Mon, Apr 29, 2024 at 7:05 AM Christoph Müllner
wrote:
>
> The extension parsing table entries for a range of Zic* extensions
> does not match the mask definition i
Hi, Han.
GCC 14 is branch out. You can commit it to trunk (GCC 15).
juzhe.zh...@rivai.ai
From: demin.han
Date: 2024-04-02 16:30
To: gcc-patches
CC: juzhe.zhong; kito.cheng; pan2.li; jeffreyalaw; rdapp.gcc
Subject: [PATCH v2] RISC-V: Refine the condition for add additional vars in RVV
cost mo
On Apr 28, 2024, "Kewen.Lin" wrote:
> Nit: Maybe add a prefix "testsuite: ".
ACK
>>
>> From: Kewen Lin
> Thanks, you can just drop this. :)
I've turned it into Co-Authored-By, since you insist.
But unfortunately with the patch it still fails when testing for
-mcpu=power7 on ppc64le-linux-
On Apr 28, 2024, "Kewen.Lin" wrote:
> OK, from this perspective IMHO it seems more clear to adopt xfail
> with effective target long_double_64bit?
*nod*, yeah, that makes sense.
I'm going to travel this week, to speak at FSF's LibrePlanet conference,
so I'll look into massaging the patch into t
> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> index 0519e0679ed..bad23ea487f 100644
> --- a/gcc/config/riscv/riscv.cc
> +++ b/gcc/config/riscv/riscv.cc
> @@ -2786,6 +2786,44 @@ riscv_v_adjust_scalable_frame (rtx target, poly_int64
> offset, bool epilogue)
>REG_NOTES (i
While moving value replacement part of PHIOPT over
to use match-and-simplify, I ran into the case where
we would have an undef use that was conditional become
unconditional. This prevents that. I can't remember at this
point what the testcase was though.
Bootstrapped and tested on x86_64-linux-gnu
50 matches
Mail list logo
