Now that vrange_storage is in its own file, I think it's prudent to
move all the vrange allocator code there since it's all related.
The users of value-range.h do not need to know the implementation
details of the storage facilities.
Tested and benchmarked on x86-64 Linux.
gcc/ChangeLog:
On Sat, 2022-07-02 at 19:38 -0400, David Malcolm wrote:
> On Sun, 2022-07-03 at 01:20 +0200, Tim Lange wrote:
> > Hi,
> >
> > thanks for the mail! Embarrassingly, I did not account for the
> > different
> > sizes types may have on different systems. I've switched all
> > testcases
> > to the fixed
On 2 July 2022 14:47:01 CEST, Mikael Morin wrote:
>Le 02/07/2022 à 13:18, Thomas Koenig a écrit :
>>
>> One thought: If we have to bite the bullet and break the ABI, why not go
>> all the way and use the C descriptors in ISO_Fortran_binding.h as
>> gfortran's native format?
>>
>As far as I know,
Hi all,
I revised my patch according to all your reviews.
Regtested on x86_64-pc-linux-gnu.
BRs,
Haochen
> -Original Message-
> From: Liu, Hongtao
> Sent: Thursday, June 30, 2022 4:57 PM
> To: Uros Bizjak ; Jiang, Haochen
>
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] i386: Ex
Tested on x86-64 Linux.
gcc/ChangeLog:
* ipa-cp.cc (ipcp_vr_lattice::meet_with_1): Use operator!=.
* ipa-prop.cc (struct ipa_vr_ggc_hash_traits): Same.
* tree-ssa-loop-unswitch.cc (struct unswitch_predicate): Use set
with two arguments.
(find_unswitching_pr
On Fri, 1 Jul 2022, Martin Jambor wrote:
> Hi,
>
> As the testcase in PR 105860 shows, the code that tries to re-use the
> handled_component chains in SRA can be horribly confused by unions,
> where it thinks it has found a compatible structure under which it can
> chain the references, but in fa
On Mon, Jul 4, 2022 at 7:10 AM Jiang, Haochen wrote:
>
> Hi all,
>
> I revised my patch according to all your reviews.
>
> Regtested on x86_64-pc-linux-gnu.
OK.
Thanks,
Uros.
>
> BRs,
> Haochen
>
> > -Original Message-
> > From: Liu, Hongtao
> > Sent: Thursday, June 30, 2022 4:57 PM
>
在 2022/7/3 上午11:06, Xi Ruoyao 写道:
On Sat, 2022-07-02 at 16:35 +0800, Lulu Cheng wrote:
在 2022/7/2 下午4:24, Xi Ruoyao 写道:
I'll commit the patch with the hook removed after another regtest on
loongarch64-linux-gnu. I just rebuilt the entire system on my
3A5000,
so I need some time to set it up.
Hi,
This patch fails TImode for all 128-bit logical operation expanders. So
TImode splits to two DI registers during expand. Potential optimizations can
be taken after expand pass. Originally, the TImode logical operations are
split after reload pass. It's too late. The test case illustrates it.
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597158.html
Thanks.
On 24/6/2022 上午 10:02, HAO CHEN GUI wrote:
> Hi,
> This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
> Tests show that outputs of xs[min/max]dp are consistent with the standard
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597020.html
Thanks.
On 22/6/2022 下午 4:26, HAO CHEN GUI wrote:
> Hi,
> This patch uses CC instead of CCFP for all BCD operations. Thus, infinite
> math flag has no impact on BCD operations. To support BCD overflow and
>
On Fri, Jul 1, 2022 at 5:32 PM Martin Sebor wrote:
>
> On 7/1/22 08:01, Qing Zhao wrote:
> >
> >
> >> On Jul 1, 2022, at 8:59 AM, Jakub Jelinek wrote:
> >>
> >> On Fri, Jul 01, 2022 at 12:55:08PM +, Qing Zhao wrote:
> >>> If so, comparing to the current implemenation to have all the checking
On Fri, Jul 1, 2022 at 5:59 PM Andrew Carlotti wrote:
>
> On Fri, Jul 01, 2022 at 08:42:15AM +0200, Richard Biener wrote:
> > On Thu, Jun 30, 2022 at 6:04 PM Andrew Carlotti via Gcc-patches
> > wrote:
> > > diff --git a/gcc/config/aarch64/aarch64-builtins.cc
> > > b/gcc/config/aarch64/aarch64-bu
On Mon, 2022-07-04 at 14:25 +0800, Lulu Cheng wrote:
> > How do you think about the suggestion from Richard about a backport into
> > gcc-12 branch? Normally we don't backport behavior changes, but making
> > 12.1 the only exception seems compelling.
>
> I agree with you and Richard.
>
> Thanks
The high part of the symbol address is invalid for the constant pool. In
function rs6000_cannot_force_const_mem, we already return true for
"HIGH with UNSPEC" rtx. During debug GCC, I found that
rs6000_cannot_force_const_mem is called for some other HIGH code rtx
expressions which also indicate the
15 matches
Mail list logo