Hi,
As mentioned in PR106550, since pli could support 34bits immediate, we could
use less instructions(3insn would be ok) to build 64bits constant with pli.
For example, for constant 0x020805006106003, we could generate it with:
asm code1:
pli 9,101736451 (0x6106003)
sldi 9,9,32
paddi 9,9, 213000
On 8/10/22 08:56, Richard Biener wrote:
> C++ standard library includes have to go through system.h (#define
> INCLUDE_STRING).
Oh, yeah. That means I need to rely on the flat header files :/
>
> Does the API really have to use std::string?
I would like to. My main motivation is std::string::rf
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
On Wed, Aug 10, 2022 at 9:17 AM Martin Liška wrote:
>
> On 8/10/22 08:56, Richard Biener wrote:
> > C++ standard library includes have to go through system.h (#define
> > INCLUDE_STRING).
>
> Oh, yeah. That means I need to rely on the flat header files :/
>
> >
> > Does the API really have to use
On 8/10/22 09:47, Richard Biener wrote:
> On Wed, Aug 10, 2022 at 9:17 AM Martin Liška wrote:
>>
>> On 8/10/22 08:56, Richard Biener wrote:
>>> C++ standard library includes have to go through system.h (#define
>>> INCLUDE_STRING).
>>
>> Oh, yeah. That means I need to rely on the flat header files
On Wed, 10 Aug 2022, Richard Biener wrote:
> On Tue, 9 Aug 2022, Andrew MacLeod wrote:
>
> >
> > On 8/9/22 09:01, Richard Biener wrote:
> > > This revisits how we compute imports later used for the ranger path
> > > query during backwards threading. The compute_imports function
> > > of the pat
On Wed, Aug 10, 2022 at 11:30 AM Martin Liška wrote:
>
> On 8/10/22 09:47, Richard Biener wrote:
> > On Wed, Aug 10, 2022 at 9:17 AM Martin Liška wrote:
> >>
> >> On 8/10/22 08:56, Richard Biener wrote:
> >>> C++ standard library includes have to go through system.h (#define
> >>> INCLUDE_STRING)
On Tue, Aug 9, 2022 at 2:02 PM Martin Liška wrote:
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> PR lto/106328
>
> gcc/ChangeLog:
>
> * jobserver.h (struct jobserver_info): Add pipefd.
> (jobserv
On 8/10/22 12:52, Richard Biener wrote:
> If it's not a template and the methods not inline won't we get multiple
> definition errors when this include file is included in multiple places
> from an executable? opts-common.cc might be a good place to
> stuff it, and opts.h to declare (if it were no
On 8/10/22 12:47, Richard Biener wrote:
> Yeah, fair enough.
I'm going to install the v3 where I renamed jobserver.h
and moved the ctor implementation to opts-common.cc.
Cheers,
MartinFrom 6f3abcb3fa26f6ed719450f6bc70b2b37179973a Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 9 Aug 2022
On 8/9/22 14:00, Martin Liška wrote:
> |Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready
> to be installed? Thanks, Martin|
Sending v2 where I renamed the file. I'm going to install it as the original
fifo support
patch was already approved by Richi.
Cheers,
MartinFr
On Wed, Jul 27, 2022 at 11:33:29AM +0200, Jakub Jelinek via Gcc-patches wrote:
> The following patch is partially a workaround for bogus warnings
> when the compiler isn't able to fold _M_disjunct call into constant
> false, but also an optimization attempt - assuming _M_disjunct (__s)
> is rare, t
On Wed, 2022-08-03 at 12:20 +0200, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> dg.exp=pr104612.c fails with an ICE on s390x, because copysignv2sf3
> produces an insn that vsel is supposed to recognize, but can't,
> because it's not defined
On Wed, Aug 10, 2022 at 1:11 PM Martin Liška wrote:
>
> On 8/10/22 12:47, Richard Biener wrote:
> > Yeah, fair enough.
>
> I'm going to install the v3 where I renamed jobserver.h
> and moved the ctor implementation to opts-common.cc.
For the record, the v3 series is OK
> Cheers,
> Martin
The following fixes the use of compute_imports from the backwards
threader which ends up accessing stale m_path from a previous
threading attempt. The fix is to pass in the path explicitely
(and not the exit), and initializing it with the exit around this
call from the backwards threader. That un
This fixes a mistake in typing a local variable in the symbolic
shift routine.
Bootstrap & regtest pending on x86_64-unknown-linux-gnu.
PR tree-optimization/106513
* gimple-ssa-store-merging.cc (do_shift_rotate): Use uint64_t
for head_marker.
* gcc.dg/torture/pr10
On Wed, Aug 10, 2022 at 03:47:10PM +0200, Richard Biener via Gcc-patches wrote:
> This fixes a mistake in typing a local variable in the symbolic
> shift routine.
>
> Bootstrap & regtest pending on x86_64-unknown-linux-gnu.
>
> PR tree-optimization/106513
> * gimple-ssa-store-merging.
This patch is updating all soft-fp from glibc, most changes are
copyright years update, removing "Contributed by" lines and update URL for
license, and changes other than those update are adding conversion
function between IEEE half and 32-bit/64-bit integer, those functions are
required by RISC-V
> if you convert the "int m;" locals into an extern global, like in
> comment #0 of bug 106551, does that still trigger the crash on the
> unpatched sm-fd.cc?
Yes, it does, since m would be in "m_start" state. I'm sending an updated
patch.
Thanks
Immad.
On Wed, Aug 10, 2022 at 1:32 AM David Mal
This patch fixes the ICE caused by valid_to_unchecked_state,
at analyzer/sm-fd.cc by handling the m_start state in
check_for_dup.
Tested lightly on x86_64.
gcc/analyzer/ChangeLog:
PR analyzer/106551
* sm-fd.cc (check_for_dup): handle the m_start
state when transitioning th
I'm still on vacation, but I figured I'd mention a few things to
either unblock you, or move the conversation along.
On Wed, Aug 10, 2022 at 8:45 AM Richard Biener wrote:
>
> On Tue, 9 Aug 2022, Andrew MacLeod wrote:
>
> >
> > On 8/9/22 09:01, Richard Biener wrote:
> > > This revisits how we comp
This patch set implements Zfh and Zfhmin, adds soft-float for _Float16, and
enables _Float16 type in C++ mode.
Zfh and Zfhmin are extensions for IEEE half precision, both are ratified in
Jan. 2022[1]
v2 Changes:
Fix mangling for C++ mode to fit the RISC-V psABI spec.
[1]
https://github.com/r
RISC-V decide use _Float16 as primary IEEE half precision type, and this
already become part of psABI, this patch has added folloing support for
_Float16:
- Soft-float support for _Float16.
- Make sure _Float16 available on C++ mode.
- Name mangling for _Float16 on C++ mode.
gcc/ChangeLog
Zfh and Zfhmin are extensions for IEEE half precision, both are ratified
in Jan. 2022[1]:
- Zfh has full set of operation like F or D for single or double precision.
- Zfhmin has only provide minimal support for half precision operation,
like conversion, load, store and move instructions.
[1]
LGTM, thanks!
On Sun, Aug 7, 2022 at 3:42 AM Palmer Dabbelt wrote:
>
> These two patterns were independent, but exactly match the semantics of
> X. Replace them with a single paramaterized pattern. Thanks to Andrew
> for pointing this one out over IRC.
>
> gcc/ChangeLog
>
> * config/ris
LGTM, that's apparently some kind of copy & paste error (from *slt
pattern) when we add this pattern.
On Sun, Aug 7, 2022 at 3:42 AM Palmer Dabbelt wrote:
>
> There's no operand 2 here, so referencing it doesn't make sense. I
> couldn't find a way to trigger bad assembly output so I don't have a
Hello,
I have one more question/comment about array_slice. Ever since I
started to use it...
On Fri, Nov 13 2020, Richard Sandiford via Gcc-patches wrote:
> A later patch wants to be able to pass around subarray views of an
> existing array. The standard class to do that is std::span, but it's
On Wed, Aug 10, 2022 at 12:46 PM Richard Biener wrote:
>
> On Wed, 10 Aug 2022, Richard Biener wrote:
>
> > On Tue, 9 Aug 2022, Andrew MacLeod wrote:
> >
> > >
> > > On 8/9/22 09:01, Richard Biener wrote:
> > > > This revisits how we compute imports later used for the ranger path
> > > > query dur
Looks good to me.
Thanks.
Aldy
On Wed, Aug 10, 2022 at 3:01 PM Richard Biener wrote:
>
> The following fixes the use of compute_imports from the backwards
> threader which ends up accessing stale m_path from a previous
> threading attempt. The fix is to pass in the path explicitely
> (and not t
Oh, and if it wasn't clear from an earlier message. I'm OK (and
thankful) for everything you're doing in this space, especially if you
stay on top of the threading counts from patch to patch, and you get
your gori questions answered by Andrew ;-). No sense in you getting
blocked, since you seem t
Hi!
On Wed, Aug 10, 2022 at 03:11:23PM +0800, Jiufu Guo wrote:
> As mentioned in PR106550, since pli could support 34bits immediate, we could
> use less instructions(3insn would be ok) to build 64bits constant with pli.
>
> For example, for constant 0x020805006106003, we could generate it with:
>
On Wed, 2022-08-10 at 20:34 +0530, Mir Immad wrote:
> > if you convert the "int m;" locals into an extern global, like in
> > comment #0 of bug 106551, does that still trigger the crash on the
> > unpatched sm-fd.cc?
>
> Yes, it does, since m would be in "m_start" state. I'm sending an
> updated
On Wed, Aug 10, 2022 at 02:23:27AM -0400, Michael Meissner wrote:
> On Fri, Aug 05, 2022 at 01:19:05PM -0500, Segher Boessenkool wrote:
> > On Thu, Jul 28, 2022 at 12:43:49AM -0400, Michael Meissner wrote:
> > > These patches lay the foundation for a set of follow-on patches that will
> > > change
On Wed, Aug 10, 2022 at 02:39:02PM +0800, Xionghu Luo wrote:
> On 2022/8/9 11:01, Kewen.Lin wrote:
> >I have some concern on those changed "altivec_*_direct", IMHO the suffix
> >"_direct" is normally to indicate the define_insn is mapped to the
> >corresponding hw insn directly. With this change,
This patch adds a simplification to match.pd that was discussed on the
thread for pr106243. It simplifies the pattern, abs(x) & 1, to x & 1.
There are also tests for the simplification in this patch. I couldn't
figure out how to get abs to work with vectors. If a test for that is
necessary, could
> Can you please rebase and see if your patch
> does fix it?
No, the patch that I sent did not attempt to fix this. Now that I have made
the correction, XFAIL in fd-uninit-1.c has changed to XPASS.
Should i remove the dg-bogus warning from fd-uninit-1.c test_1?
Thanks.
Immad.
On Wed, Aug 10,
Hi!
Sorry for the tardiness.
On Fri, Jul 22, 2022 at 03:07:55PM +0800, HAO CHEN GUI wrote:
> This patch creates a new function - change_pseudo_and_mask. If recog fails,
> the function converts a single pseudo to the pseudo AND with a mask if the
> outer operator is IOR/XOR/PLUS and inner operat
Here is another patch to complete __gnu_debug::basic_string<> Standard
conformity. This one is adding the missing compare overloads.
I also would like to propose to change how __gnu_debug::basic_string<>
is tested. I considered activating checks when
_GLIBCXX_ASSERTIONS is defined but it turn
On Wed, 2022-08-10 at 22:51 +0530, Mir Immad wrote:
> > Can you please rebase and see if your patch
> > does fix it?
>
> No, the patch that I sent did not attempt to fix this. Now that I
> have made
> the correction, XFAIL in fd-uninit-1.c has changed to XPASS.
Great - that means that, with your
Hi everyone
For my v2 of the patches, I've been spending a lot of time ensuring
each patch is buildable. It would end up being simpler if it was
possible if each patch did not have to be like this so I could split
up the front-end in more patches. Does this make sense? In theory,
when everything g
On Wed, 2022-08-10 at 19:56 +0100, Philip Herron wrote:
> Hi everyone
>
> For my v2 of the patches, I've been spending a lot of time ensuring
> each patch is buildable. It would end up being simpler if it was
> possible if each patch did not have to be like this so I could split
> up the front-end
Hi Lance,
Thanks for your contribution - looks like your first one to GCC ?
The patch looks good to me, though it should probably go through a
full test suite run on arm-linux-gnueabihf and get a ChangeLog - see
here for more https://gcc.gnu.org/contribute.html#patches.
This is probably small en
Hi,
As mentioned in the bug report, I reopened this bug since the previous patch:
commit r13-1875-gff26f0ba68fe6e870f315d0601b596f889b89680
Author: Richard Biener
Date: Thu Jul 28 10:07:32 2022 +0200
middle-end/106457 - improve array_at_struct_end_p for array objects
Array references
LGTM.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2022-08-10 23:44
To: gcc-patches; kito.cheng; jim.wilson.gcc; palmer; andrew; juzhe.zhong; joseph
CC: Kito Cheng
Subject: [PATCH v2 2/2] RISC-V: Support zfh and zfhmin extension
Zfh and Zfhmin are extensions for IEEE half precision, both are r
On 8/8/22 12:06, Marek Polacek wrote:
On Sat, Aug 06, 2022 at 03:29:05PM -0700, Jason Merrill wrote:
On 7/26/22 14:31, Marek Polacek wrote:
On Tue, Jul 26, 2022 at 04:24:18PM -0400, Jason Merrill wrote:
On 7/26/22 15:03, Marek Polacek wrote:
Since r11-5188-g32934a4f45a721, we drop qualifiers
Hi Segher,
Really appreciate your review comments.
On 11/8/2022 上午 1:38, Segher Boessenkool wrote:
> Hi!
>
> Sorry for the tardiness.
>
> On Fri, Jul 22, 2022 at 03:07:55PM +0800, HAO CHEN GUI wrote:
>> This patch creates a new function - change_pseudo_and_mask. If recog fails,
>> the functi
LGTM, thanks :)
On Fri, Jul 29, 2022 at 3:52 AM Maciej W. Rozycki wrote:
>
> Complement commit 7915f6551343 ("RISC-V/testsuite: constraint some of
> tests to hard_float") and also restrict the remaining `fmin'/`fmax'
> tests to hard-float test configurations.
>
> gcc/testsuite/
>
LGTM, but with a nit, I don't get set.w but get an andi like below, so
maybe we should also scan-assembler-not andi? feel free to commit that
directly with that fix
```asm
sleu:
sgtua0,a0,a1# 9 [c=4 l=4] *sgtu_disi
xoria0,a0,1 # 10[c=4 l=4] *xorsi3_internal/
On 8/10/22 13:42, Ilya Leoshkevich wrote:
> On Wed, 2022-08-03 at 12:20 +0200, Ilya Leoshkevich wrote:
>> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>>
>>
>>
>> dg.exp=pr104612.c fails with an ICE on s390x, because copysignv2sf3
>> produces an insn that vsel is supposed to re
On 2022/8/11 01:07, Segher Boessenkool wrote:
On Wed, Aug 10, 2022 at 02:39:02PM +0800, Xionghu Luo wrote:
On 2022/8/9 11:01, Kewen.Lin wrote:
I have some concern on those changed "altivec_*_direct", IMHO the suffix
"_direct" is normally to indicate the define_insn is mapped to the
correspon
On Wed, Aug 10, 2022 at 6:04 PM Martin Jambor wrote:
>
> Hello,
>
> I have one more question/comment about array_slice. Ever since I
> started to use it...
>
> On Fri, Nov 13 2020, Richard Sandiford via Gcc-patches wrote:
> > A later patch wants to be able to pass around subarray views of an
> >
52 matches
Mail list logo
