The following makes sure to clear loops number of iterations when
outlining them as part of a SESE region as can happen with
auto-parallelization. The referenced SSA names become stale otherwise.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
PR tree-optimization/107865
Hi Haochen,
Sorry for the late review.
on 2022/10/11 15:38, HAO CHEN GUI wrote:
> Hi,
> This patch modifies the help function which generates permute index for
> vector byte reversion and generates permute index directly for little endian
> targets. It saves one "xxlnor" instructions on P8 litt
Update in V3:
Remove !flag_signaling_nans since there's already HONOR_NANS (BFmode).
Here's the patch:
After supporting real __bf16, the implementation of _mm_cvtsbh_ss went
wrong.
The patch add a builtin to generate pslld for the intrinsic, also
extendbfsf2 is supported with pslld when !HONOR_N
Based on the discussions in previous mails:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607139.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607197.html
I will update the patch accordingly, and then submit a new version.
BR,
Jeff (Jiufu)
Jiufu Guo writes:
> Hi,
>
>
Hi Richard,
Thanks a lot for your comments!
Richard Biener writes:
> On Wed, 23 Nov 2022, Jiufu Guo wrote:
>
>> Hi Jeff,
>>
>> Thanks a lot for your comments!
>
> Sorry for the late response ...
>
>> Jeff Law writes:
>>
>> > On 11/20/22 20:07, Jiufu Guo wrote:
>> >> Jiufu Guo writes:
>> >
Hi Richard,
on 2022/11/23 00:08, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> Many thanks for your review comments!
>>
> on 2022/8/24 16:17, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> As discussed in PR98125, -fpatchable-function-entry with
>> SECTION
This patch is a followup to my not-yet-reviewed patch
[PATCH v4] OpenMP: Generate SIMD clones for functions with "declare target"
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606218.html
In comments on a previous iteration of that patch, I was asked to do
something to delete unused
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/html/manual/bugs.html: Regenerate.
* doc/xml/manual/intro.xml: Document LWG 3656 change.
* include/std/bit (__bit_width, bit_width): Return int.
* testsuite/26_numerics/bit/bit.pow.two/lw
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This copies the better tests from gcc-12 to trunk.
libstdc++-v3/ChangeLog:
PR libstdc++/106201
* testsuite/27_io/filesystem/iterators/106201.cc: Improve test.
* testsuite/experimental/filesystem/iterators/106201.cc: New test
If a char * global was initialized with a rvalue from
`gcc_jit_context_new_string_literal` containing a format string,
dumping the context causes libgccjit to SIGSEGV due to an improperly
constructed call to vasprintf. The following code snippet can reproduce
the crash:
int main(int argc, char **a
Hi Harald,
please find attached an obvious patch by Steve for a technical
regression that resulted from improvements in error recovery
of bad uses of associate.
Regtested on x86_64-pc-linux-gnu.
Will commit soon unless there are comments.
Obvious enough, I think. Thanks!
As a sidenote: th
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Wednesday, November 23, 2022 4:18 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; Marcus Shawcroft
>> ; Kyrylo Tkachov
>> Subject: Re: [PATCH]AArch64 sve2: Fix expansio
> -Original Message-
> From: Richard Sandiford
> Sent: Wednesday, November 23, 2022 4:18 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH]AArch64 sve2: Fix expansion of division [PR107830]
>
> Tam
The nvptx reverse-offload code mishandled the case that there was a reverse
offload function that isn't called inside a target region. In that case,
the linker did not include GOMP_target_ext and the global variable it uses.
But the plugin-nvptx.c code expected that the latter is present.
Found v
On 11/11/2022 21:50, Ramana Radhakrishnan via Gcc-patches wrote:
On Thu, Nov 10, 2022 at 7:46 PM Ramana Radhakrishnan
wrote:
On Thu, Nov 10, 2022 at 6:03 PM Richard Earnshaw
wrote:
On 10/11/2022 17:21, Richard Earnshaw via Gcc-patches wrote:
On 08/11/2022 18:20, Ramana Radhakrishnan
> -Original Message-
> From: Andrea Corallo
> Sent: Thursday, November 24, 2022 2:44 PM
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
>
> Subject: [PATCH 35/35 V2] arm: improve tests for vsetq_lane*
>
> Kyrylo Tkachov writes:
>
> [...]
>
> >> diff --git a/gc
>> How did you test the patch? If you bootstrapped it and ran the
>> testsuite then it's OK.
Yes, i ran testsuite and bootstrapped and everything seemed OK, but i missed
fail of tests gcc.dg/Warray-bounds-34.c and gcc.dg/Warray-bounds-43.c, so Franz
is right. After that I fixed the regexps in dg
Kyrylo Tkachov writes:
[...]
>> diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vsetq_lane_f16.c
>> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/vsetq_lane_f16.c
>> index e03e9620528..b5c9f4d5eb8 100644
>> --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/vsetq_lane_f16.c
>> +++ b/gcc/
Martin Liška writes:
> On 11/8/22 14:22, Gaius Mulley wrote:
>> Martin Liška writes:
>>
>> should be good - I'll complete the rst output in the scripts,
>
> Hi.
>
Hi Martin,
> As you probably noticed, the Sphinx migration didn't go well.
Yes, sorry to see this didn't happen. Thank you for y
Hi Jakub,
> * testsuite/libgomp.c-c++-common/icv-4.c: Bugfix.
Better say what exactly you changed in words.
Changed.
> --- a/gcc/gimplify.cc
> +++ b/gcc/gimplify.cc
> @@ -14153,7 +14153,7 @@ optimize_target_teams (tree target, gimple_seq
*pre_p)
>struct gimplify_omp_ctx *target_ctx
Ping x 2
Ramana
On Thu, 17 Nov 2022, 20:15 Ramana Radhakrishnan,
wrote:
> On Fri, Nov 11, 2022 at 9:50 PM Ramana Radhakrishnan
> wrote:
> >
> > On Thu, Nov 10, 2022 at 7:46 PM Ramana Radhakrishnan
> > wrote:
> > >
> > > On Thu, Nov 10, 2022 at 6:03 PM Richard Earnshaw
> > > wrote:
> > > >
>
Sorry for the very long delay in reviewing this.
Wilco Dijkstra writes:
> Hi Richard,
>
> Here is the immediate cleanup splitoff from the previous patch:
>
> Simplify, refactor and improve various move immediate functions.
> Allow 32-bit MOVZ/N as a valid 64-bit immediate which removes special
>
Hi,
I had a question and I figured I'd easier to ask before I spend more time
implementing it 😊
I had noticed that one of the other reasons that cbranch and the other optabs
like cmov explicitly
emit the compare separately and use combine to match up the final form is for
ifcvt.
In particular
Updated list as follow up to last ping at
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601162.html
Recent patches:
Sandra's (Tue Nov 15 04:46:15 GMT 2022)
[PATCH v4] OpenMP: Generate SIMD clones for functions with "declare target"
https://gcc.gnu.org/pipermail/gcc-patches/2022-Nove
On 11/8/22 14:22, Gaius Mulley wrote:
> Martin Liška writes:
>
>> 1) I would prefer using ' instead of ":
>>
>> $ flake8 ./gcc/m2/tools-src/tidydates.py
>> ...
>> ./gcc/m2/tools-src/tidydates.py:124:30: Q000 Double quotes found but single
>> quotes preferred
>> ./gcc/m2/tools-src/tidydates.py:12
On Thu, Nov 24, 2022 at 4:53 PM Jakub Jelinek wrote:
>
> On Thu, Nov 24, 2022 at 09:22:00AM +0800, liuhongt via Gcc-patches wrote:
> > --- a/gcc/config/i386/i386.md
> > +++ b/gcc/config/i386/i386.md
> > @@ -130,6 +130,7 @@ (define_c_enum "unspec" [
> >;; For AVX/AVX512F support
> >UNSPEC_S
On Tue, Nov 22, 2022 at 10:09:06AM -0500, Jason Merrill wrote:
> > Though, shall we have those [on|off] options at all?
> > Those are inconsistent with all other boolean options gcc has.
> > Every other boolean option is -fwhatever for it being on
> > and -fno-whatever for it being off, shouldn't t
* Jakub Jelinek:
> On Thu, Nov 24, 2022 at 11:01:40AM +0100, Florian Weimer via Gcc-patches
> wrote:
>> * Joseph Myers:
>>
>> > On Tue, 22 Nov 2022, Florian Weimer via Gcc-patches wrote:
>> >
>> >> Without this change, finish_declspecs cannot tell that whether there
>> >> was an erroneous type s
On Mon, Nov 21, 2022 at 4:53 PM Andrew Carlotti wrote:
>
> On Mon, Nov 14, 2022 at 04:10:22PM +0100, Richard Biener wrote:
> > On Fri, Nov 11, 2022 at 7:53 PM Andrew Carlotti via Gcc-patches
> > wrote:
> > >
> > > This recognises patterns of the form:
> > > while (n) { n >>= 1 }
> > >
> > > This
On Thu, Nov 24, 2022 at 11:01:40AM +0100, Florian Weimer via Gcc-patches wrote:
> * Joseph Myers:
>
> > On Tue, 22 Nov 2022, Florian Weimer via Gcc-patches wrote:
> >
> >> Without this change, finish_declspecs cannot tell that whether there
> >> was an erroneous type specified, or no type at all.
On Thu, Nov 24, 2022 at 8:25 AM HAO CHEN GUI wrote:
>
> Hi Richard,
>
>
> 在 2022/11/24 4:06, Richard Biener 写道:
> > Wouldn't we usually either add an optab or try to recog a canonical
> > RTL form instead of adding a new target hook for things like this?
>
> Thanks so much for your comments. Pleas
On Thu, 24 Nov 2022, Jakub Jelinek wrote:
> Hi!
>
> asan_emit_stack_protection and functions it calls have various asserts that
> verify sanity of the stack protection instrumentation. But, that
> verification can easily fail if we've diagnosed a frame offset overflow.
> asan_emit_stack_protecti
From: Eric Botcazou
We cannot generate a call to memset for an aggregate with an Others choice
when the target of the assignment has a storage model with Copy_To routine.
gcc/ada/
* gcc-interface/trans.cc (gnat_to_gnu) : Add
assertion that memset is not supposed to be used when
From: Justin Squirek
This patch corrects an issue in the compiler whereby unprefixed discriminants
appearing in protected subprograms were unable to be properly resolved -
leading to spurious resolution errors.
gcc/ada/
* sem_ch8.adb
(Find_Direct_Name): Remove bypass to reanalyz
Richard Biener writes:
> On Mon, Oct 10, 2022 at 5:35 PM Gaius Mulley via Gcc-patches
> wrote:
>>
>>
>>
>> This patch set consists of the libgm2 makefile, autoconf sources
>> necessary to build the libm2pim, libm2iso, libm2min, libm2cor
>> and libm2log.
>
> This looks OK. I suppose it was also
* Joseph Myers:
> On Tue, 22 Nov 2022, Florian Weimer via Gcc-patches wrote:
>
>> Without this change, finish_declspecs cannot tell that whether there
>> was an erroneous type specified, or no type at all. This may result
>> in additional diagnostics for implicit ints, or missing diagnostics
>> f
Am 2022-11-23 um 21:11 schrieb Richard Biener via Gcc-patches:
On Wed, Nov 23, 2022 at 3:08 PM Iskander Shakirzyanov via Gcc-patches
wrote:
Hi!
Sorry for the initially missing description.
The following patch changes the definition of -Warray-bounds to an Alias to
-Warray-bounds=1. This is ne
Hi,
When assigning a parameter to a variable, or assigning a variable to
return value with struct type, "block move" are used to expand
the assignment. It would be better to use the register mode according
to the target/ABI to move the blocks. And then this would raise more
opportunities for othe
Hi!
On Thu, Nov 24, 2022 at 09:37:54AM +0800, haochen.jiang wrote:
> 8a0fce6a51915c29584427fd376b40073c328090 is the first bad commit
> commit 8a0fce6a51915c29584427fd376b40073c328090
> Author: Jakub Jelinek
> Date: Wed Nov 23 19:09:31 2022 +0100
>
> c: Fix compile time hog in c_genericize
On Thu, 24 Nov 2022 at 09:20, Jakub Jelinek wrote:
>
> Hi!
>
> As mentioned in the PR, Solaris apparently can handle right
> printf ("%.0Lf\n", 1e+202L * __DBL_MAX__);
> which prints 511 chars long number, but can't handle
> printf ("%.0Lf\n", 1e+203L * __DBL_MAX__);
> nor
> printf ("%.0Lf\n", __LD
On Thu, 24 Nov 2022 at 09:23, Jakub Jelinek wrote:
>
> Hi!
>
> Upstream fast_float came up with a cheaper test for
> fegetround () == FE_TONEAREST using one float addition, one subtraction
> and one comparison. If we know we are rounding to nearest, we can use
> fast path in more cases as before.
Hi!
asan_emit_stack_protection and functions it calls have various asserts that
verify sanity of the stack protection instrumentation. But, that
verification can easily fail if we've diagnosed a frame offset overflow.
asan_emit_stack_protection just emits some extra code in the prologue,
if we've
"Kewen.Lin" writes:
> Hi,
>
> As the test case in PR107412 shows, we can fold IFN .LEN_{LOAD,
> STORE} into normal vector load/store if the given length is known
> to be equal to the length of the whole vector. It would help to
> improve overall cycles as normally the latency of vector access
> w
Hi!
Upstream fast_float came up with a cheaper test for
fegetround () == FE_TONEAREST using one float addition, one subtraction
and one comparison. If we know we are rounding to nearest, we can use
fast path in more cases as before.
The following patch merges those changes into libstdc++.
Bootst
The current handlings in rs6000_emit_vector_compare is a bit
complicated to me, especially after we emit vector float
comparison insn with the given code directly. So it's better
to refactor the handlings of vector integer comparison here.
This is part 4, it's to rework the handlings on GE/GEU/LE
The current handlings in rs6000_emit_vector_compare is a bit
complicated to me, especially after we emit vector float
comparison insn with the given code directly. So it's better
to refactor the handlings of vector integer comparison here.
This is part 1, it's to remove the helper function
rs6000
Hi!
As mentioned in the PR, Solaris apparently can handle right
printf ("%.0Lf\n", 1e+202L * __DBL_MAX__);
which prints 511 chars long number, but can't handle
printf ("%.0Lf\n", 1e+203L * __DBL_MAX__);
nor
printf ("%.0Lf\n", __LDBL_MAX__);
properly, instead of printing 512 chars long number for t
All kinds of vector float comparison operators have been
supported in a rtl comparison pattern as vector.md, we can
just emit an rtx comparison insn with the given comparison
operator in function rs6000_emit_vector_compare instead of
checking and handling the reverse condition cases.
This is part
All kinds of vector float comparison operators have been
supported in a rtl comparison pattern as vector.md, we can
just emit an rtx comparison insn with the given comparison
operator in function rs6000_emit_vector_compare instead of
checking and handling the reverse condition cases.
This is part
The current handlings in rs6000_emit_vector_compare is a bit
complicated to me, especially after we emit vector float
comparison insn with the given code directly. So it's better
to refactor the handlings of vector integer comparison here.
This is part 3, it's to refactor the handlings on NE.
Thi
All kinds of vector float comparison operators have been
supported in a rtl comparison pattern as vector.md, we can
just emit an rtx comparison insn with the given comparison
operator in function rs6000_emit_vector_compare instead of
checking and handling the reverse condition cases.
This is part
The current handlings in rs6000_emit_vector_compare is a bit
complicated to me, especially after we emit vector float
comparison insn with the given code directly. So it's better
to refactor the handlings of vector integer comparison here.
This is part 5, it's to refactor all the handlings of vec
The current handlings in rs6000_emit_vector_compare is a bit
complicated to me, especially after we emit vector float
comparison insn with the given code directly. So it's better
to refactor the handlings of vector integer comparison here.
This is part 2, it's to refactor the handlings on LT and
All kinds of vector float comparison operators have been
supported in a rtl comparison pattern as vector.md, we can
just emit an rtx comparison insn with the given comparison
operator in function rs6000_emit_vector_compare instead of
checking and handling the reverse condition cases.
This is part
Hi,
Following Segher's suggestion, this patch series is to rework
function rs6000_emit_vector_compare for vector float and int
in multiple steps, it's based on the previous attempts [1][2].
As mentioned in [1], the need to rework this for float is to
make a centralized place for vector float compa
Hi!
The following testcase ICEs, because OpenMP lowering for shared clause
on l variable with REFERENCE_TYPE creates POINTER_TYPE to REFERENCE_TYPE.
The reason is that the automatic variable has non-trivial construction
(reference to a lambda) and -fmerge-all-constants is on and so TREE_READONLY
i
On Linux/x86_64,
8caf155a3d6e23e47bf55068ad23c23d4655a054 is the first bad commit
commit 8caf155a3d6e23e47bf55068ad23c23d4655a054
Author: Hongyu Wang
Date: Sat Nov 19 09:38:00 2022 +0800
i386: Only enable small loop unrolling in backend [PR 107692]
caused
FAIL: gcc.dg/guality/loop-1.c
On Thu, Nov 24, 2022 at 09:22:00AM +0800, liuhongt via Gcc-patches wrote:
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -130,6 +130,7 @@ (define_c_enum "unspec" [
>;; For AVX/AVX512F support
>UNSPEC_SCALEF
>UNSPEC_PCMP
> + UNSPEC_CVTBFSF
>
>;; Generic math
> The motivation of this patch is to correct the wrong estimation of
>> the number of instructions needed for loading a 64bit constant in
>> rv32 in the current cost model(riscv_interger_cost). According to
>> the current implementation, if a constant requires more than 3
>> instructions(riscv_cons
59 matches
Mail list logo
