e setting isn't
explicitly provided as:
if (rs6000_tune_index >= 0)
tune_index = rs6000_tune_index;
else if (cpu_index >= 0)
rs6000_tune_index = tune_index = cpu_index;
As PR106345 shows, GCC can use an explicit tune setting when it's
configured, even if there is one "-mdejagnu
u-tune= usage should filter all -mtune= options.
>> It should not filter out any -mcpu= options.
>
> Like this:
>
> diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
> index 3b8941a8658..26874943795 100644
> --- a/gcc/config/rs6000/rs6000.h
me testing coverage like:
NA->PASS: gcc.target/powerpc/pr92398.p9+.c
NA->PASS: gcc.target/powerpc/pr93453-1.c
Tested as before.
v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598602.html
v2: Use dummy function instead of dummy int as Segher suggested.
Segher, does this v2 look
Hi Jeff,
on 2022/7/19 22:30, Jiufu Guo wrote:
> Hi,
>
> In patch https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597712.html,
> test case was not added. After more check, a testcase is added for it.
>
Good to see that you constructed one actual test case, nice! :)
> Th
Dear sir,
I've tried to contact you via LinkedIn but wasn't successful.
Is there any number i can reach you?
*Michael Kim|CIC Canada*
file inside the front-end folder?
Note thanks to Thomas Schwinge and Mark Wielaard, we are keeping a branch up to
date with our code on:
https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/devel/rust/master
but this is not rebased ontop of gcc head.
Let me know if I have sent these pa
From: Philip Herron
This adds the nessecary target hooks for the arm target.
gcc/ChangeLog:
* config.gcc: add rust_target_objs for arm
gcc/config/arm/ChangeLog:
* arm-protos.h: define arm_rust_target_cpu_info
* arm-rust.cc: new file to generate info
* arm.h
From: Philip Herron
This is a skeleton front-end which is used so we can ensure each patch is
buildable:
gcc/rust/ChangeLog:
* Make-lang.in
* config-lang.in
* lang-specs.h
* lang.opt
* rust-lang.cc
* rustspec.cc
---
gcc/rust/Make-lang.in | 308
From: Philip Herron
This patch introduces a new set of interfaces to define the target info as
expected by the rust front-end. It takes advantage of the information
within gcc/config/target directories which gets called by the front-end
to populate rust front-end datastructures by calling into
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594699.html
BR,
Kewen
>
>> on 2022/5/13 13:29, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>> PR105485 exposes that new builtin function framework doesn't handle
>>> unre
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595208.html
BR,
Kewen
>>> Hi,
>>>
>>> As PR104482 shown, it's one regression about the handlings when
>>> the argument number is more than the one of built-in function
>>> pro
Hi,
Gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597286.html
BR,
Kewen
on 2022/6/27 10:47, Kewen.Lin via Gcc-patches wrote:
> Hi Segher!
>
> on 2022/6/25 00:49, Segher Boessenkool wrote:
>> Hi!
>>
>> On Fri, Jun 24, 2022 at 09:03:59AM +0800, Kewen.
From: Sören Tempel
On 32-bit systems, musl only defines SYS_timer_settime32 not
SYS_timer_settime. This causes the following compilation error:
os_linux.go:251:30: error: reference to undefined name
'_SYS_timer_settime'
251 | return int32(syscall(_SYS_timer_set
> Is this okay for trunk? Any recommendations? Thanks a lot.
>
> ChangeLog
> 2022-07-22 Haochen Gui
>
> gcc/
> PR target/103109
> * config/rs6000/rs6000.md (maddditi4): New pattern for
> multiply-add.
> (madddi4_low
t; empty TU problem.
> https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598744.html
>
aha, I'm going to push it if Segher doesn't have further comments. :)
> Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
> Is this okay for trunk? Any recommen
gimple.h:4594)
FAIL: g++.dg/warn/uninit-pr105562.C -std=gnu++20 (test for excess errors)
FAIL: gfortran.dg/make_unit.f90 -O1 (internal compiler error: in
gimple_phi_arg, at gimple.h:4594)
FAIL: gfortran.dg/make_unit.f90 -O1 (test for excess errors)
with GCC configured with
../../gcc/configure
x86_64-pc-linux-gnu{-m32,}.
There's some cases observed in SPEC2017, but no big performance impact.
Any comments?
gcc/ChangeLog:
PR tree-optimization/103144
* tree-vect-loop.cc (vect_is_nonlinear_iv_evolution): New function.
(vect_analyze_scalar_cycles_1): Detect n
d and tested on powerpc64-linux BE and LE with no regressions.
> Is this okay for trunk? Any recommendations? Thanks a lot.
This patch is OK, thanks!
BR,
Kewen
>
> ChangeLog
> 2022-08-04 Haochen Gui
>
> gcc/testsuite/
> * lib/target-supports.exp (check_p9modulo_hw_avai
.
Committed as obvious after a build for risc32-elf configured with
--with-arch=rv32imac_zba_zbb_zbc_zbs.
Thanks,
Andrew Pinski
gcc/ChangeLog:
* config/riscv/predicates.md (splittable_const_int_operand):
Remove the check for TARGET_64BIT for single bit const values.
---
gcc/config/riscv
t2
FAIL: libstdc++-prettyprinters/cxx11.cc print rtpl
FAIL: libstdc++-prettyprinters/cxx11.cc print tpl
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-1956/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with
/cmpti2.c scan-assembler-times xorq 4
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-1982/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
From: Andrew Pinski
Since this testcase is not exactly SSA specific and it would
be a good idea to compile this at more than just at -O1, moving
it to gcc.c-torture/compile would do that.
Committed as obvious after a test on x86_64-linux-gnu.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa
.
Note this updates gcc.dg/pr87052.c where we had:
const char d[0] = { };
And was expecting a store to d but after this, there is no store
as the decl's type is zero in size.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
PR middle-end/1
tivec_vmrghb_direct can be mapped into vmrghb or vmrglb, this looks
misleading. Maybe we can add the corresponding _direct_le and _direct_be
versions, both are mapped into the same insn but have different RTL
patterns. Looking forward to Segher's and David's suggestions.
> gcc/Cha
for the low-part generation.
> 2 A runnable testcase replaces the original compiling case.
> 3 Fixes indention problems.
>
> Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
> Is this okay for trunk? Any recommendations? Thanks a lot.
>
> ChangeLog
entry foo,.-foo
nop
Bootstrapped and regtested on powerpc64-linux-gnu P7 & P8,
and powerpc64le-linux-gnu P9 & P10.
Is it ok for trunk?
BR,
Kewen
-
PR target/99888
PR target/105649
gcc/ChangeLog:
* config/rs6000/rs60
ed on powerpc64-linux-gnu P7 & P8,
and powerpc64le-linux-gnu P9 & P10.
I'll push this soon if no objections.
BR,
Kewen
-
gcc/ChangeLog:
* config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Fix the
oversight on ENB_CELL by simplifying with rs6000_bu
Hi,
r10-631 had renamed rs6000_global_entry_point_needed_p to
rs6000_global_entry_point_prologue_needed_p. This is to
remove the stale function declaration.
Bootstrapped and regtested on powerpc64-linux-gnu P8 and
powerpc64le-linux-gnu P9 and P10.
I'll push this soon.
BR,
Kewen
----
Hi Segher,
Thanks for the review comments!
on 2022/8/9 18:35, Segher Boessenkool wrote:
> Hi!
>
>> + /* As ELFv2 ABI shows, the allowable bytes past the global entry
>> + point are 0, 4, 8, 16, 32 and 64. Considering there are two
>> + non-prefixed instructions for global e
on 2022/8/10 05:34, Segher Boessenkool wrote:
> On Tue, Aug 09, 2022 at 11:14:16AM +0800, Kewen.Lin wrote:
>> on 2022/8/8 14:04, HAO CHEN GUI wrote:
>>> +/* { dg-do run { target { has_arch_ppc64 } } } */
>>> +/* { dg-options "-O2 -mdejagnu-cpu=power9 -save-temps" } */
>>> +/* { dg-require-effective
on 2022/8/10 05:10, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Aug 09, 2022 at 08:51:59PM +0800, Kewen.Lin wrote:
>> on 2022/8/9 18:35, Segher Boessenkool wrote:
+/* As ELFv2 ABI shows, the allowable bytes past the global entry
+ point are 0, 4, 8, 16, 32 and 64. Considering
the incoming regs to scalar pseudo(s).
(copying the incoming registers to stack would be optimized out by rtl
passes.
Yes, it would be better to avoid generating them.)
But I'm not too familiar with the innards of parameter/return
value initial RTL expansion. I hope somebody else ca
o handle PTImode types. PTImode attribute helps in generating
> even/odd register pairs on 128 bits.
>
> 2023-07-20 Jeevitha Palanisamy
>
> gcc/
> PR target/110411
> * config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add fields
> to hold PTImode t
n vsx_quad_dform_memory_operand to allow OOmode and
> quad_address_p already handles less than size 16.
>
> 2023-07-19 Jeevitha Palanisamy
>
> gcc/
> PR target/110411
> * config/rs6000/mma.md (define_insn_and_split movoo): Disallow
> AltiVec address in mov
DR 2386 updated the tuple_size requirements for structured binding and
it now requires tuple_size to be considered only if
std::tuple_size names a complete class type with member value. GCC
before this patch does not follow the updated requrements, and this
patch is intended to implement it
Hi,
Gentle ping...
On 2023-07-18 22:05, Jiufu Guo wrote:
Hi,
Integer expression "(X - N * M) / N" can be optimized to "X / N - M"
if there is no wrap/overflow/underflow and "X - N * M" has the same
sign with "X".
Compare the previous version:
https:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.c:
In function ‘matmul_i1_avx512f’:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.c:1781:1:
internal compiler error: RTL check: expected
Similar like r14-2786-gade30fad6669e5, the patch is for V4HF/V2HFmode.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR target/110762
* config/i386/mmx.md (3): Changed from define_insn
to define_expand and break into
Hi Carl,
Sorry for the late review.
on 2023/8/2 02:29, Carl Love wrote:
>
> GCC maintainers:
>
> Ver 2: Re-worked the test vec-cmpne.c to create a compile only test
> verify the instruction generation and a runnable test to verify the
> built-in functionality. Retested th
s tweaked, also okay for all affected
release branches after burn-in time, thanks!
BR,
Kewen
> quad_address_p already handles less than size 16.
>
> 2023-07-19 Jeevitha Palanisamy
>
> gcc/
> PR target/110411
> * config/rs6000/mma.md (define_insn_and_split m
Hi,
Gentle ping this series:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607146.html
BR,
Kewen
>>> on 2022/11/24 17:15, Kewen Lin wrote:
>>>> Hi,
>>>>
>>>> Following Segher's suggestion, this patch series is to rework
>>>
Hi,
I'd like to gentle ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614818.html
BR,
Kewen
>> on 2023/3/29 15:18, Kewen.Lin via Gcc-patches wrote:
>>> Hi,
>>>
>>> By addressing Alexander's comments, against v1 this
>>>
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609993.html
BR,
Kewen
> on 2023/1/16 17:08, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> As Honza pointed out in [1], the current uses of function
>> optimize_function_for_speed_p in rs60
Hi Richi,
on 2023/6/30 17:13, Kewen.Lin via Gcc-patches wrote:
> Hi Richi,
>
> Thanks for your review!
>
> on 2023/6/30 16:56, Richard Biener wrote:
>> On Fri, Jun 30, 2023 at 7:38 AM Kewen.Lin wrote:
>>>
>>> Hi,
>>>
>>> As PR110248 sh
llvm forks Phoebe and Craig.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk and backport?
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_available_features): Check
EAX for valid subleaf before use CPUID.
---
gcc/common/config/i386/cpui
d after Sandy Bridge was originally released.
This is causing avxvnniint16 to be incorrectly enabled with
-march=native on these CPUs.
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_available_features): Check
EAX for valid subleaf before use CPUID.
---
gcc/common/co
This minor fix is preapproved in [1].
Committed to trunk.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626758.html
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_available_features):
Rename local variable subleaf_level to max_subleaf_level.
---
gcc/common
Hi Carl,
on 2023/8/8 01:50, Carl Love wrote:
>
> GCC maintainers:
>
> Ver 3: Updated description to make it clear the patch fixes the
> confusion on the availability of the builtins. Fixed the dg-require-
> effective-target on the test cases and the dg-options. Change the
Hi,
on 2023/7/20 12:35, jeevitha via Gcc-patches wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> When the user specifies PTImode as an attribute, it breaks. Created
> a tree node to handle PTImode types. PTImode
On Fri, 2023-08-04 at 09:16 -0400, Vladimir Makarov wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> The following patch fixes a problem found by LRA port for avr target.
> The problem description is in the commit message.
>
> The patch wa
Also add ix86_partial_vec_fp_math to to condition of V2HF/V4HF named
patterns in order to avoid generation of partial vector V8HFmode
trapping instructions.
Bootstrapped and regtseted on x86_64-pc-linux-gnu{-m32,}
Ok for trunk?
gcc/ChangeLog:
PR target/110832
* config/i386
on for all gather/scatter instructions. The options is
interpreted by driver to 3 tunes.
bootstrapped and regtested on x86_64-pc-linux-gnu.
Ok for trunk?
gcc/ChangeLog:
* config/i386/i386.h (DRIVER_SELF_SPECS): Add
GATHER_SCATTER_DRIVER_SELF_SPECS.
(GATHER_SCATTER_DRIV
ather generation in autovectorization but uses
gather scalar emulation instead.
Ready push to trunk and backport.
any comments?
gcc/ChangeLog:
* config/i386/i386-options.cc (m_GDS): New macro.
* config/i386/x86-tune.def (X86_TUNE_USE_GATHER_2PARTS): Don't
enable
Rename original use_gather to use_gather_8parts, Support
-mtune-ctrl={,^}use_gather to set/clear tune features
use_gather_{2parts, 4parts, 8parts}. Support the new option -mgather
as alias of -mtune-ctrl=, use_gather, ^use_gather.
Similar for use_scatter.
How about this version?
gcc/ChangeLog
DR 2386 updated the tuple_size requirements for structured binding and
it now requires tuple_size to be considered only if
std::tuple_size names a complete class type with member value. GCC
before this patch does not follow the updated requrements, and this
patch is intended to implement it
-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
* config/i386/i386.md (movdf_internal): Generate vmovapd instead of
vmovsd when moving DFmode between SSE_REGS.
(movhi_internal): Generate vmovdqa instead of vmovsh when
moving HImode between SSE_REGS.
(mov_internal
hich
> helps eliminate redundant zero extend.
>
> Compared to last version, the main change is to put the word index
> checking in the split condition of "*vsx_extract_v4si_w023". Also modified
> some comments.
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/62538
Hi,
on 2023/8/14 15:53, Jan-Benedict Glaw wrote:
> On Fri, 2023-06-30 13:46:40 +0800, Kewen.Lin via Gcc-patches
> wrote:
>> Bootstrapped and regtested on x86_64-redhat-linux and
>> powerpc64{,le}-linux-gnu.
>>
>> Is it ok for trunk?
> [...]
>
>> diff
-
> juzhe.zh...@rivai.ai
>
>
> *From:* Richard Biener <mailto:rguent...@suse.de>
> *Date:* 2023-08-14 14:53
> *To:* Ju-Zhe Zhong <mailto:juzhe.zh...@rivai.ai>
> *CC:* gcc-patches <mailto:gcc-patches@gcc.gnu.org>; richard.sandiford
> <mai
ks on VMAT_INVARIANT. There should be no functional
changes.
Bootstrapped and regtested on x86_64-redhat-linux,
aarch64-linux-gnu and powerpc64{,le}-linux-gnu.
gcc/ChangeLog:
* tree-vect-stmts.cc (vectorizable_load): Remove some useless checks
on VMAT_INVARIANT.
---
gcc/tree
emove
some unreachable code. Also remove the corresponding
handlings in the final loop nest.
Bootstrapped and regtested on x86_64-redhat-linux,
aarch64-linux-gnu and powerpc64{,le}-linux-gnu.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623329.html
gcc/ChangeLog:
* tree-vect-stm
some
unreachable code. Also remove the corresponding handlings
in the final loop nest.
Bootstrapped and regtested on x86_64-redhat-linux,
aarch64-linux-gnu and powerpc64{,le}-linux-gnu.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623329.html
Is it ok for trunk?
BR,
Kewen
-----
ct_var_idx_p is supposed to check if the backend
> supports extracting a variable index.
OK, it sounds that this new capability needs to further check with
function can_vec_extract_var_idx_p to ensure the ifn expanding work
as expected. I re-spined by adding the below as your comments:
diff --
Hi Carl,
on 2023/8/9 23:52, Carl Love wrote:
>
> GCC maintainers:
>
> The following patch adds four built-ins for the decimal floating point
> (DFP) quantize instructions on rs6000. The built-ins are for 64-bit
> and 128-bit DFP operands.
>
> The patch also adds
posting to you. Thanks!
BR,
Kewen
-
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index bc3063c3615..5ae9f69c7eb 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -32,6 +32,8 @@ along with GCC; see the file COPYING3. If not see
#include "tree-pass.h&qu
RE_LANES)
{
...
}
else
{
...
}
Then the else arm is fully re-indented.
The other patch on VMAT_GATHER_SCATTER looks a bit better since
it doesn't need re-indenting.
BR,
Kewen
>
> Thanks,
> Richard.
>
>> [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-
loop nest.
>>
>> Bootstrapped and regtested on x86_64-redhat-linux,
>> aarch64-linux-gnu and powerpc64{,le}-linux-gnu.
>>
>> [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623329.html
>>
>> Is it ok for trunk?
>>
>> BR,
>> Kewen
>>
up some useless
>>>> set up code for the case of VMAT_GATHER_SCATTER, remove some
>>>> unreachable code. Also remove the corresponding handlings
>>>> in the final loop nest.
>>>>
>>>> Bootstrapped and regtested on x86_64-redhat-linux,
>&
, the build can fail if these dependencies
are not ready. So this patch is to teach this dependence.
Thank Jan-Benedict Glaw for testing this!
gcc/ChangeLog:
* Makefile.in (RECOG_H): Add $(TREE_H) as dependence.
---
gcc/Makefile.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion
gcc.dg/vect/pr71416-1.c compilation failed to produce executable
> UNRESOLVED: gcc.dg/vect/vect-reduc-pattern-3.c -flto -ffat-lto-objects
> compilation failed to produce executable
>
> I've randomely picked pr50451.c and ran gcc against it which results in:
>
> during GIM
R_SCATTER, remove some
>>>>>> unreachable code. Also remove the corresponding handlings
>>>>>> in the final loop nest.
>>>>>>
>>>>>> Bootstrapped and regtested on x86_64-redhat-linux,
>>>>>> aarch64-linux-gnu a
gt;>>>>>>> of function vectorizable_load to its own loop. Basically
>>>>>>>> it duplicates the final loop nest, clean up some useless
>>>>>>>> set up code for the case of VMAT_GATHER_SCATTER, remove some
>>>&g
on 2023/8/15 17:13, Richard Sandiford wrote:
> Richard Biener writes:
>>> OK, fair enough. So the idea is: see where we end up and then try to
>>> improve/factor the APIs in a less peephole way?
>>
>> Yeah, I think that's the only good way forward.
>
> OK, no objection from me. Sorry for holdin
r14-3215, serial built and verified all passed;
Is it ok for trunk?
BR,
Kewen
-
PR bootstrap/111021
gcc/ChangeLog:
* Makefile.in (TM_P_H2): New variable for tm_p.h dependence.
---
gcc/Makefile.in | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/Mak
on 2023/8/16 10:31, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR111021 shows, the below ${port}-protos.h include tree.h
> for code_helper and tree_code:
>
> arm/arm-protos.h:#include "tree.h"
> cris/cris-protos.h:#include "tree.h" (H-P removed th
v1,0(a0)
ret
to,
shortcut_for_riscv_vrsub_case_1_32:
vl1re32.v v1,0(a1)
vsetvli zero,a2,e32,m1,ta,ma
vnot.v v1,v1
vs1r.v v1,0(a0)
ret
gcc/ChangeLog:
* simplify-rtx.cc (simplify_context::simplify_binary_operation_1):
Get -1 with
on 2023/8/17 11:11, Peter Bergner wrote:
> On 8/16/23 7:19 PM, Carl Love wrote:
>> +(define_insn "dfp_dquan_"
>> + [(set (match_operand:DDTD 0 "gpc_reg_operand" "=d")
>> +(unspec:DDTD [(match_operand:DDTD 1 "gpc_reg_operand" "d")
>> + (match_operand:DDTD 2 "gpc_reg_operand
Hi Carl,
on 2023/8/17 08:19, Carl Love wrote:
>
> GCC maintainers:
>
> Version 2, renamed the built-in instances. Changed the name of the
> overloaded built-in. Added the missing documentation for the new
> built-ins. Fixed typos. Changed name of the test. Updated the
-3215;
2) reproduced the build failure with serial build;
3) applied this patch, serially built and verified all passed;
4) added back r14-3215, serially built and verified all passed;
Also bootstrapped and regtested on x86_64-redhat-linux and
powerpc64{,le}-linux-gnu.
Is it ok for trunk
their uses and
restrict the scope for some of them etc.
It's a pre-patch for upcoming vectorizable_store re-structuring
for costing.
Bootstrapped and regtested on x86_64-redhat-linux,
aarch64-linux-gnu and powerpc64{,le}-linux-gnu.
Is it ok for trunk?
BR,
Kewen
-
gcc/ChangeLog:
execution
failure (it is also causing a crash when building libgcc for avr)
(insn 108 15 3 3 (set (mem/c:SI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [3 %sfp+1 S4 A8])
(reg:SI 4 r4 [orig:46 f.3_4 ] [46]))
"/home/i41766/code/personal/gcc/gcc/testsuite/gcc.c-tor
Hi Segher,
As discussed on "~" vs. "-", "~" is correct for this patch.
I updated the patch according to Kewen's comments.
If ok, I would commit to trunk.
BR,
Jeff (Jiufu Guo)
On 2023-07-04 11:28, Kewen.Lin wrote:
Hi Jeff,
on 2023/7/4 10:18, Jiufu Gu
Alderlake-N is E-core only, add it as an alias of Alderlake.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Any comments?
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (get_intel_cpu): Detect
Alderlake-N.
* common/config/i386/i386-common.cc (alias_table
---
htdocs/gcc-14/changes.html | 4
1 file changed, 4 insertions(+)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index eae25f1a..2c888660 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -151,6 +151,10 @@ a work-in-progress.
-march
gcc/testsuite/ChangeLog:
* gcc.target/i386/avx512f-pr88464-2.c: Add -mgather to
options.
* gcc.target/i386/avx512f-pr88464-3.c: Ditto.
* gcc.target/i386/avx512f-pr88464-4.c: Ditto.
* gcc.target/i386/avx512f-pr88464-6.c: Ditto.
* gcc.target/i386
Hello,
Hope you are doing well with the family.
I noticed on LinkedIn.
Can I share an idea here?
irmed it's bootstrapped and regress-tested on
powerpc64le-linux-gnu P9/P10. Thanks!
BR,
Kewen
>
> Co-Authored-By: Kewen.Lin
>
> gcc/ChangeLog:
>
> * tree-vect-loop.cc (vect_verify_loop_lens): Add exists check.
> (vectorizable_live_operation): Add live vect
targets that do not
> officially support it. Disable PCREL for targets that do not support it.
>
> 2023-08-21 Jeevitha Palanisamy
>
> gcc/
> PR target/111045
> * config/rs6000/rs6000.cc (rs6000_option_override_internal): Disable
> PCREL
> for unsuppo
Commit as an abvious fix.
gcc/testsuite/ChangeLog:
* gcc.target/i386/invariant-ternlog-1.c: Only scan %rdx under
TARGET_64BIT.
---
gcc/testsuite/gcc.target/i386/invariant-ternlog-1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target
rapped and regtested on x86_64-redhat-linux,
aarch64-linux-gnu and powerpc64{,le}-linux-gnu.
Is it ok for trunk?
BR,
Kewen
-
gcc/ChangeLog:
* tree-vect-data-refs.cc (vect_set_group_last_element): New function.
(vect_analyze_group_access): Call ne
-linux-gnu and powerpc64{,le}-linux-gnu.
Is it ok for trunk?
BR,
Kewen
-
gcc/ChangeLog:
* tree-vect-stmts.cc (vectorizable_store): Remove vec oprnds,
adjust vec result_chain, vec_oprnd with auto_vec, and adjust
gvec_oprnds with auto_delete_vec.
---
gcc/tree-vect
ok for trunk?
BR,
Kewen
-
gcc/ChangeLog:
* tree-vect-stmts.cc (vectorizable_store): Move the handlings on
VMAT_LOAD_STORE_LANES in the final loop nest to its own loop,
and update the final nest accordingly.
---
gcc/tree-vect-stmts.cc | 732
te:
> > > On 26/04/23, 5:51 PM, "Richard Biener" > > <mailto:richard.guent...@gmail.com>> wrote:
> > > > On Wed, Apr 26, 2023 at 12:56 PM > > > <mailto:senthilkumar.selva...@microchip.com>> wrote:
> > > > > On Wed
/set_union/constrained.cc (test for excess errors)
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-1873/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet
Hi Carl,
on 2023/6/16 00:00, Carl Love wrote:
> On Tue, 2023-06-13 at 11:24 +0800, Kewen.Lin wrote:
>> Hi Carl,
>>
>> on 2023/5/31 04:41, Carl Love wrote:
>>> GCC maintainers:
>>>
>>> The following patch fixes the first argument in the builtin
>
Hi Carl,
on 2023/6/16 00:00, Carl Love wrote:
> GCC maintainers:
>
> Version 2, fixed various typos. Updated the change log body to say the
> instruction counts were updated. The instruction counts changed as a
> result of changing the first argument of the vec_replace_unaligned
Hi Carl,
on 2023/6/17 01:57, Carl Love wrote:
> Kewen, GCC maintainers:
>
> Version 5, Tested the patch on P9 BE per request. Fixed up test case
> to get the correct expected values for BE and LE. Fixed typos.
> Updated the doc/extend.texi to clarify the vector arguments. Chan
Hi Carl,
on 2023/5/31 04:46, Carl Love wrote:
> GCC maintainers:
>
> The following patch takes the tests in vsx-vector-6-p7.h, vsx-vector-
> 6-p8.h, vsx-vector-6-p9.h and reorganizes them into a series of smaller
> test files by functionality rather than processor version.
>
Hi Hongtao,
on 2023/6/14 16:17, Hongtao Liu wrote:
> On Tue, Jun 13, 2023 at 10:07 AM Kewen Lin via Gcc-patches
> wrote:
>>
>> This patch adjusts the cost handling on
>> VMAT_CONTIGUOUS_PERMUTE in function vectorizable_load. We
>> don't call function v
Hi Carl,
on 2023/6/20 02:54, Carl Love wrote:
>
> Kewen, GCC maintainers:
>
> Version 6, Fixed missing change log entry. Changed builtin id names as
> requested. Missed making the change on the last version. Fixed
> comment in the three test cases. Reran regression suite
501 - 600 of 41351 matches
Mail list logo
