在 2022/9/4 下午2:35, Xi Ruoyao 写道:
On Sun, 2022-09-04 at 11:22 +0800, Lulu Cheng wrote:
在 2022/9/4 上午10:51, Xi Ruoyao 写道:
On Sun, 2022-09-04 at 10:26 +0800, Lulu Cheng wrote:
If the above modifications are not added, the function call is:
bl %plt(test1)
now is :
bl test1
Regardin
On Sun, Sep 4, 2022 at 12:00 AM Lulu Cheng wrote:
>
>
> 在 2022/9/4 下午2:35, Xi Ruoyao 写道:
> > On Sun, 2022-09-04 at 11:22 +0800, Lulu Cheng wrote:
> >> 在 2022/9/4 上午10:51, Xi Ruoyao 写道:
> >>
> >>> On Sun, 2022-09-04 at 10:26 +0800, Lulu Cheng wrote:
> >>>
> If the above modifications are not a
Hi Arsen,
Thanks for the analysis, for working on this and the patch; the solution
overall seems the right one, but I have a suggestion on the implementation ...
> On 3 Sep 2022, at 21:57, Arsen Arsenović wrote:
>
> In the edge case of a coroutine not containing any locals, the ifcd/swch
> tem
v1 -> v2:
Move TARGET_DIRECT_EXTERN_ACCESS check from loongarch_classify_symbol to
loongarch_symbol_binds_local_p, so "%plt" is not output if
-mdirect-extern-access used.
-- >8 --
As a new target, LoongArch does not use copy relocation as it's
problematic in some circumstances. One bad conseque
On Sun, 2022-09-04 at 00:38 -0700, Fangrui Song wrote:
> On Sun, Sep 4, 2022 at 12:00 AM Lulu Cheng
> wrote:
> > I have thought about this problem. For example, there is no '%plt'
> > in
> > aarch64, but I think it can be added and easily distinguished at the
> > assembly code level,
> >
> > so
Okay, then I will delete those new warnings I added in the version 3 of the
patch.
Thanks.
Qing
> On Sep 1, 2022, at 2:11 AM, Richard Biener wrote:
>
> On Wed, 31 Aug 2022, Kees Cook wrote:
>
>> On Wed, Aug 31, 2022 at 08:35:12PM +, Qing Zhao wrote:
>>> One of the major purposes of the n
When unioning a known NAN and something else, we're dropping the
properties of the NAN, particularly the sign. This fixes the
oversight.
With this patch, we should be keeping the sign bit up to date, even in
the presence of NANs.
gcc/ChangeLog:
* value-range.cc (frange::union_): Do not
Hi,
The IEEE_MODES_TYPE type and the two functions that get and set it were added
in Fortran 2018. They can be implemented using the already existing
target-specific functions. A future optimization could, on some targets,
set/get all modes through one or two instructions only, but that would
On 9/1/22 12:53, David Faust wrote:
The eBPF loader expects to find BTF_KIND_VAR records for references to
extern const void symbols. We were mistakenly identifing these as
unsupported types, and as a result skipping emitting VAR records for
them.
Tested on bpf-unknown-none and x86_64, no known
Signed-off-by: Philipp Fent
---
libstdc++-v3/testsuite/libstdc++-prettyprinters/48362.cc | 2 +-
libstdc++-v3/testsuite/libstdc++-prettyprinters/cxx11.cc | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/48362.cc
b/libstdc++-
Signed-off-by: Philipp Fent
---
libstdc++-v3/python/libstdcxx/v6/printers.py | 37 +++
.../libstdc++-prettyprinters/debug.cc | 5 +++
.../libstdc++-prettyprinters/simple.cc| 5 +++
.../libstdc++-prettyprinters/simple11.cc | 5 +++
4 files changed, 52 inser
In the edge case of a coroutine not containing any locals, the ifcd/swch
temporaries would get added to the coroutine frame, corrupting its
layout. To prevent this, we can make sure there is always a BIND_EXPR at
the top of the function body, and thus, always a place for our new
temporaries to go w
Hi Dave,
sorry about the strncpy thing, I should've been more careful. Below is the
patch with just the strcpy part.
- Tim
This patch adds modelling for the semantics of strcpy in the simple case
where the analyzer is able to infer a concrete string size.
Regrtested on Linux x86_64.
2022-09-04
On Tue, Aug 23, 2022 at 6:10 PM Alexander Monakov via Gcc-patches
wrote:
>
> The crc32q instruction takes 64-bit operands, but ignores high 32 bits
> of the destination operand, and zero-extends the result from 32 bits.
>
> Let's model this in the RTL pattern to avoid zero-extension when the
> _mm
Hi Martin,
> On 30 Aug 2022, at 11:53, Martin Liška wrote:
>
> On 5/4/22 10:59, Martin Liška wrote:
>> Hello.
> I've just done one more merge from upstream.
> Upstream revision: 84a71d5259c2682403cdbd8710592410a2f128ab.
Which (again) breaks bootstrap on Darwin (since upstream uses features
and
Dear all,
said PR was addressed by Jose in
https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html
but unfortunately his patch was never reviewed.
IMHO the patch is mostly fine, with one small exception that
it should use POINTER_TYPE_P (TREE_TYPE (tmp)), see PR and
attached adjusted pat
Le 04/09/2022 à 22:04, Harald Anlauf via Fortran a écrit :
Dear all,
said PR was addressed by Jose in
https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html
but unfortunately his patch was never reviewed.
IMHO the patch is mostly fine, with one small exception that
it should use POIN
Hi Arsen,
> On 4 Sep 2022, at 20:04, Arsen Arsenović wrote:
>
> In the edge case of a coroutine not containing any locals, the ifcd/swch
> temporaries would get added to the coroutine frame, corrupting its
> layout. To prevent this, we can make sure there is always a BIND_EXPR at
> the top of th
On Sun, 2022-09-04 at 21:17 +0200, Tim Lange wrote:
> Hi Dave,
>
> sorry about the strncpy thing, I should've been more careful. Below
> is the
> patch with just the strcpy part.
Thanks - this patch looks OK for trunk.
Dave
On Fri, Sep 2, 2022 at 4:08 PM Kong, Lingling wrote:
>
> Hi,
>
> I fixed it in a new patch. And added BF vector mode in SUBST_V and
> avx512fmaskhalfmode for @vec_interleave_high.
> Ok for trunk ?
Ok.
>
> > > Hi,
> > >
> > > Handle E_V8BFmode in expand_vec_perm_broadcast_1 and
> > ix86_expand_ve
LGTM!
Thanks!
在 2022/9/4 下午9:18, Xi Ruoyao 写道:
v1 -> v2:
Move TARGET_DIRECT_EXTERN_ACCESS check from loongarch_classify_symbol to
loongarch_symbol_binds_local_p, so "%plt" is not output if
-mdirect-extern-access used.
-- >8 --
As a new target, LoongArch does not use copy relocation as it's
on 2022/9/3 01:36, Segher Boessenkool wrote:
> On Fri, Sep 02, 2022 at 08:50:52AM +0800, Kewen.Lin wrote:
>> on 2022/9/1 22:57, Segher Boessenkool wrote:
>>> These two are independent, but apparently we have a bug here, which will
>>> make what you did malfunction in some cases -- the test will not
on 2022/9/3 01:44, Segher Boessenkool wrote:
> On Fri, Sep 02, 2022 at 08:51:01AM +0800, Kewen.Lin wrote:
>> on 2022/9/1 23:04, Segher Boessenkool wrote:
>>> On Thu, Sep 01, 2022 at 05:05:44PM +0800, Kewen.Lin wrote:
Without any explicit -mpowerpc64 (and -mno-), I think we all agree
that
zmm-version vcvtps2ph is special, it encodes {sae} in evex, but put
round control in the imm. For intrinsic _mm512_cvt_roundps_ph (a,
imm), imm contains both {sae} and round control, we need to separate
it in the assembly output since vcvtps2ph will ignore imm[3:7].
Corresponding llvm patch.
Intri
On Mon, Sep 5, 2022 at 10:44 AM liuhongt wrote:
>
> zmm-version vcvtps2ph is special, it encodes {sae} in evex, but put
> round control in the imm. For intrinsic _mm512_cvt_roundps_ph (a,
> imm), imm contains both {sae} and round control, we need to separate
> it in the assembly output since vcvtp
"Kewen.Lin" writes:
> Hi Jeff,
>
> Thanks for the patch, some comments on nits are inline.
>
> on 2022/9/1 11:24, Jiufu Guo wrote:
>> 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 p
Intersecting two ranges where one is a NAN is keeping the sign bit of
the NAN range. This is not correct as the sign bits may not match.
I think the only time we're absolutely sure about the intersection of
a NAN and something else, is when both are a NAN with exactly the same
properties (sign bi
Hi,
Segher Boessenkool writes:
> Hi!
>
> On Fri, Sep 02, 2022 at 02:56:21PM +0800, Jiufu Guo wrote:
>> >> + /* pli 9,high32 + sldi 9,32 + paddi 9,9,low32. */
>> >> + else
>> >> + {
>> >
>> > The comment goes here, in the block it refers to. Comments for a block
>> > are the first thi
After Joseph's comment wrt __builtin_signbit, I have been unable to
convince myself that arbitrarily folding __builtin_signbit () of a
negative number to 1 is correct.
For example, on the true side of x < -5.0 we know the sign bit is set,
but on the false side, we know nothing because X may be a N
Hi Segher,
Thanks for your review comments.
On 2/9/2022 下午 11:56, Segher Boessenkool wrote:
>> - const signed long __builtin_vsx_scalar_extract_exp (double);
>> + const unsigned long long __builtin_vsx_scalar_extract_exp (double);
>> VSEEDP xsxexpdp {}
>>
>> - const signed long __builtin
30 matches
Mail list logo
