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
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 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.
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
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
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
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
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
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
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
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
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
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
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
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
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):
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
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
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...
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
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
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.
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
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
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
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:
*
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
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.
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
*
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
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.
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:
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:
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
---
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,
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
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
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
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
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
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
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
>
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
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, "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
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
This adds a few early outs to value_replacement that I noticed
while rewriting this to use match-and-simplify but could be committed
seperately.
* virtual operands won't change so return early for them
* special case `A ? B : B` as that is already just `B`
Also moves the check for NE/EQ earlier
I noticed that single_non_singleton_phi_for_edges could
return a phi whos entry are all the same for the edge.
This happens only if there was a single phis in the first place.
Also gimple_seq_singleton_p walks the sequence to see if it the one
element in the sequence so there is removing that
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}
Ready push to trunk.
gcc/ChangeLog:
PR target/113090
* config/i386/i386-expand.cc
(expand_vec_perm_punpckldq_pshuf): New function.
(ix86_expand_vec_perm_const_1): Try
expand_vec_perm_punpckldq_pshuf
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
gcc/ChangeLog:
PR target/113079
* config/i386/mmx.md (usdot_prodv8qi): New expander.
(sdot_prodv8qi): Ditto.
(udot_prodv8qi): Ditto.
(usdot_prodv4hi): Ditto.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ready push to trunk.
gcc/ChangeLog:
* config/i386/sse.md (usdot_prodv*qi): Extend to VI1_AVX512
with vpmaddwd when avxvnni/avx512vnni is not available.
---
gcc/config/i386/sse.md | 55
51 matches
Mail list logo
