On Mon, Aug 19, 2019 at 12:15 PM Andrew Burgess
wrote:
> I don't see any reason why we couldn't add t1, and a0 to a7 into this
> set, and this is what this patch does.
SIBCALL_REGS already includes t1 and t2. It is t0 aka x5 that is
missing. I think this is wrong. As Andrew mentioned, this
* c-c++-common/pr65403-1.c: New test.
* c-c++-common/pr65403-2.c: New test.
---
gcc/testsuite/c-c++-common/pr65403-1.c | 10 ++
gcc/testsuite/c-c++-common/pr65403-2.c | 15 +++
2 files changed, 25 insertions(+)
create mode 100644
From: Manuel López-Ibáñez
* opts-common.c (ignored_wnoerror_options): New global variable.
* opts-global.c (print_ignored_options): Ignore
-Wno-error= except if there are other
diagnostics.
* opts.c (enable_warning_as_error): Record ignored -Wno-error
On 7/12/19 1:44 AM, Richard Sandiford wrote:
> Richard Sandiford writes:
>> This patch rewrites the way simplify_subreg handles constants.
>> It uses similar native_encode/native_decode routines to the
>> tree-level handling of VIEW_CONVERT_EXPR, meaning that we can
>> move between rtx constants
On Thu, Aug 22, 2019 at 3:09 PM Kewen.Lin wrote:
>
> Hi Bin,
>
> on 2019/8/22 下午1:46, Bin.Cheng wrote:
> > On Thu, Aug 22, 2019 at 11:18 AM Kewen.Lin wrote:
> >>
> >> Hi Bin,
> >>
> >> Thanks for your time!
> >>
> >> on 2019/8/21 下午8:32, Bin.Cheng wrote:
> >>> On Wed, Aug 14, 2019 at 3:23 PM
On 8/12/19 4:09 PM, Martin Sebor wrote:
>
> gcc-83431.diff
>
> PR tree-optimization/83431 - -Wformat-truncation may incorrectly report
> truncation
>
> gcc/ChangeLog:
>
> PR c++/83431
> * gimple-ssa-sprintf.c (pass_data_sprintf_length): Remove object.
>
Hi Richard,
On 2019/8/13 17:10, Richard Biener wrote:
On Tue, Aug 13, 2019 at 4:22 AM luoxhu wrote:
Hi Richard,
On 2019/8/12 16:51, Richard Biener wrote:
On Mon, Aug 12, 2019 at 8:50 AM luoxhu wrote:
Hi Richard,
Thanks for your comments, updated the v2 patch as below:
1. Define and use
On Thu, Aug 22, 2019 at 2:39 PM Jeff Law wrote:
>
> On 8/22/19 1:59 PM, Iain Sandoe wrote:
> > Hi,
> >
> > When we are parsing a source file, the very first token might
> > be a PRAGMA_GCC_PCH_PREPROCESS. This indicates that we are going
> > read in a PCH file (named as the value of the pragma).
On Wed, Aug 21, 2019 at 7:24 AM Marek Polacek wrote:
>
> Currently, we disregard prefix attributes in conditions, e.g.:
>
> if ([[maybe_unused]] int i = f()) { }
>
> The problem here is that although we've parsed the attribute, it
> was never passed down to start_decl, so the effects were lost.
F2018 states that ERRMSG in co_broadcast, co_max, co_min, co_reduce,
and co_sum is INTENT(INOUT). The committed patch makes this so.
2019-08-22 Steven G. Kargl
* intrinsic.c (add_subroutines): ERRMSG is INTENT(INOUT) in
co_broadcast, co_max, co_min, co_reduce, and co_sum.
On 8/22/19 4:37 PM, Jeff Law wrote:
On 8/22/19 4:23 PM, Martin Sebor wrote:
On 8/22/19 3:27 PM, Jeff Law wrote:
On 8/21/19 2:50 PM, Martin Sebor wrote:
This patch is a subset of the solution for PR 91457 whose main
goal is to eliminate inconsistencies in warnings issued for
out-of-bounds
On 8/15/19 1:47 PM, Bernd Edlinger wrote:
> Hi,
>
> this is the split out part from the "Fix not 8-byte aligned ldrd/strd on
> ARMv5 (PR 89544)"
> which is sanitizing the middle-end interface to the back-end for strict
> alignment,
> and a couple of bug-fixes that are necessary to survive
On 8/17/19 1:44 AM, Bernd Edlinger wrote:
> On 8/15/19 9:47 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> this is the split out part from the "Fix not 8-byte aligned ldrd/strd on
>> ARMv5 (PR 89544)"
>> which is sanitizing the middle-end interface to the back-end for strict
>> alignment,
>> and a
On 8/22/19 4:23 PM, Martin Sebor wrote:
> On 8/22/19 3:27 PM, Jeff Law wrote:
>> On 8/21/19 2:50 PM, Martin Sebor wrote:
>>> This patch is a subset of the solution for PR 91457 whose main
>>> goal is to eliminate inconsistencies in warnings issued for
>>> out-of-bounds accesses to the various
On 8/22/19 3:27 PM, Jeff Law wrote:
On 8/21/19 2:50 PM, Martin Sebor wrote:
This patch is a subset of the solution for PR 91457 whose main
goal is to eliminate inconsistencies in warnings issued for
out-of-bounds accesses to the various flavors of flexible array
members of constant objects.
On 8/22/19 3:55 PM, Martin Sebor wrote:
>>> diff --git a/gcc/expr.c b/gcc/expr.c
>>> index 92979289e83..d16e0982dcf 100644
>>> --- a/gcc/expr.c
>>> +++ b/gcc/expr.c
>>> @@ -11402,6 +11402,16 @@ is_aligning_offset (const_tree offset,
>>> const_tree exp)
>>> tree
>>> string_constant (tree arg,
On 8/21/19 4:28 PM, Jeff Law wrote:
On 8/21/19 2:50 PM, Martin Sebor wrote:
This patch is a subset of the solution for PR 91457 whose main
goal is to eliminate inconsistencies in warnings issued for
out-of-bounds accesses to the various flavors of flexible array
members of constant objects.
On 8/22/19 1:59 PM, Iain Sandoe wrote:
> Hi,
>
> When we are parsing a source file, the very first token might
> be a PRAGMA_GCC_PCH_PREPROCESS. This indicates that we are going
> read in a PCH file (named as the value of the pragma). If we don't
> see this pragma, then we know that it's OK to
On 8/20/19 8:10 PM, Martin Sebor wrote:
> Jeff,
>
> Please let me know if you agree/disagree and what I need to
> do to advance this work:
>
> https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00643.html
For the official record, I agree :-)
jeff
On 8/21/19 7:34 AM, Jozef Lawrynowicz wrote:
> As described in PR target/91306, the alignment of entries in CRT data
> structures
> as set in libgcc/crtstuff.c can be too large for msp430-elf.
>
> crtstuff.c assumes the correct alignment of entries with a type of (void *) or
> int32 is the
On 8/21/19 2:50 PM, Martin Sebor wrote:
> This patch is a subset of the solution for PR 91457 whose main
> goal is to eliminate inconsistencies in warnings issued for
> out-of-bounds accesses to the various flavors of flexible array
> members of constant objects. That patch was posted here:
>
Hi,
This is a full patch for the roundeven variants along with
documentation and additional testcases. The following code also
conforms to GNU's coding standards.
Thanks,
Tejas
2019-08-22 Tejas Joshi
Martin Jambor
* builtins.c (mathfn_built_in_2): Added CASE_MATHFN for
Hi,
When we are parsing a source file, the very first token might
be a PRAGMA_GCC_PCH_PREPROCESS. This indicates that we are going
read in a PCH file (named as the value of the pragma). If we don't
see this pragma, then we know that it's OK to release any resources
that the host might have set
Tested on powerpc64-linux {-m32,-m64}; committing to trunk.
Segher
2019-08-22 Segher Boessenkool
* config/rs6000/altivec.md (unspec): Delete UNSPEC_DARN, UNSPEC_DARN_32,
UNSPEC_DARN_RAW, UNSPEC_CMPRB, UNSPEC_CMPRB2, UNSPEC_CMPEQB; move to...
*
Every call to darn should deliver a *new* random number; such calls
shouldnot be CSEd together. So they should be unspec_volatile, not
plain unspec.
Tested on powerpc64-linux {-m32,-m64}. (New testcase coming soon).
Committing to trunk, and will backport to 9, 8, 7 as well.
Segher
Honza, Ricard,
I fell over this assert in dwarf2out.c, but the later comment says it
can happen?? does a checking build fail on LTO?
static inline void
add_AT_die_ref (dw_die_ref die, enum dwarf_attribute attr_kind,
dw_die_ref targ_die)
{
dw_attr_node attr;
gcc_checking_assert
On Thu, Aug 22, 2019 at 3:43 AM Richard Biener
wrote:
> On Wed, Aug 21, 2019 at 10:10 PM Martin Sebor wrote:
> > On 8/20/19 1:26 AM, Richard Biener wrote:
> > > On Tue, Aug 20, 2019 at 4:32 AM Martin Sebor wrote:
> > >> On 8/19/19 8:10 AM, Richard Biener wrote:
> > >>> On Sat, Aug 17, 2019 at
On Thu, Aug 22, 2019 at 08:50:20PM +0200, Thomas Koenig wrote:
> Am 20.08.19 um 22:32 schrieb Thomas König:
>
> > here is the next installment of checking for mismatched calls,
> > this time for mismatching CALLs.
>
> The reorganization of the code also means that
>
Am 20.08.19 um 22:32 schrieb Thomas König:
here is the next installment of checking for mismatched calls,
this time for mismatching CALLs.
The reorganization of the code also means that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91519 (a rejects-valid
regression) is fixed by this patch.
On Thu, Aug 22, 2019 at 11:01 AM Nathan Sidwell wrote:
>
> On 8/20/19 9:03 PM, Marek Polacek wrote:
>
> > and in cp_parser_nested_name_specifier_opt we simply don't know if we're
> > dealing with a function decl. Calling cp_warn_deprecated_use_scopes from
> > cp_parser_type_specifier resulted
On 8/20/19 9:03 PM, Marek Polacek wrote:
and in cp_parser_nested_name_specifier_opt we simply don't know if we're
dealing with a function decl. Calling cp_warn_deprecated_use_scopes from
cp_parser_type_specifier resulted int duplicated diagnostics so that one
is out too. So I did the
Dear all,
please find in attachment a preliminary patch that adds support to
co_broadcast for allocatable components of derived types.
The patch is currently ignoring the stat and errmsg arguments, mostly
because I am not sure how to handle them properly. I have created a
new data structure called
On 8/21/19 4:34 PM, Jeff Law wrote:
On 8/16/19 4:21 PM, Martin Sebor wrote:
On 8/16/19 12:15 PM, Jeff Law wrote:
On 8/16/19 12:09 PM, Marc Glisse wrote:
On Fri, 16 Aug 2019, Jeff Law wrote:
This patch improves our ability to detect dead stores by handling cases
where the size memcpy,
On 8/20/19 1:26 AM, Richard Biener wrote:
> On Tue, Aug 20, 2019 at 4:32 AM Martin Sebor wrote:
>>
>> On 8/19/19 8:10 AM, Richard Biener wrote:
>>> On Sat, Aug 17, 2019 at 12:43 AM Martin Sebor wrote:
With the recent enhancement to the strlen handling of multibyte
stores the
On 8/22/19 9:18 AM, Rainer Orth wrote:
> The new gcc.target/i386/minmax-4.c etc. testcases currently FAIL on
> 32-bit Solaris/x86:
>
> FAIL: gcc.target/i386/minmax-4.c scan-assembler-times pmaxsd 1
> FAIL: gcc.target/i386/minmax-4.c scan-assembler-times pmaxud 1
> FAIL: gcc.target/i386/minmax-4.c
Hi all,
We currently have a nasty error when trying to use the __crc* intrinsics
with an -mfloat-abi=hard.
That is because the target pragma guarding them uses armv8-a+crc that
does not include fp by default.
So we get errors like:
error: '-mfloat-abi=hard': selected processor lacks an FPU
Hi all,
This patch adds '-mcpu' options for following CPUs:
Cortex-M35P, Cortex-A77, Cortex-A76AE.
Related specifications are as following:
https://developer.arm.com/ip-products/processors/cortex-m
https://developer.arm.com/ip-products/processors/cortex-a
Bootstraped/Regtested for
The new gcc.target/i386/minmax-4.c etc. testcases currently FAIL on
32-bit Solaris/x86:
FAIL: gcc.target/i386/minmax-4.c scan-assembler-times pmaxsd 1
FAIL: gcc.target/i386/minmax-4.c scan-assembler-times pmaxud 1
FAIL: gcc.target/i386/minmax-4.c scan-assembler-times pminsd 1
FAIL:
The iorsi3_compare0 and iorsi3_compare0_scratch patterns can make use of
the 16-bit thumb orrs instruction if suitable registers are allocated.
This patch adds the alternative to allow this to happen.
* config/arm/arm.md (iorsi3_compare0): Add alternative for 16-bit thumb
insn.
On 8/21/19 4:47 PM, Jeff Law wrote:
On 8/19/19 7:57 AM, Richard Biener wrote:
+static tree
+objsize_from_type (tree object)
+{
+ if (TREE_CODE (object) != ADDR_EXPR)
+return NULL_TREE;
+
+ tree type = TREE_TYPE (object);
+ if (POINTER_TYPE_P (type))
that if looks suspicious... I'd
On Thu, 22 Aug 2019, Martin Jambor wrote:
> +/* Round X to nearest integer, rounding halfway cases towards even. */
> +
> +void
> +real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
> + const REAL_VALUE_TYPE *x)
> +{
> + if (is_halfway_below (x))
> + {
> +do_add (r, x, ,
On August 22, 2019 2:36:47 PM GMT+02:00, Joseph Myers
wrote:
>On Thu, 22 Aug 2019, Richard Biener wrote:
>
>> Not sure if that helps answering your question. In essence,
>> this function should tell whether we would emit an UNDEF
>> in the end and we want to know that early, at LTO IL
Hi,
On Wed, Jul 31 2019, Uros Bizjak wrote:
> On Wed, Jul 31, 2019 at 7:51 AM Tejas Joshi wrote:
>>
>> Hi.
>>
>> > > * gcc.target/i386/avx-vround-roundeven-1.c: New test.
>> > > * gcc.target/i386/avx-vround-roundeven-2.c: New test.
>> >
>> > roundss and roundsd are sse4_1 instructions,
Hi,
On Wed, Aug 21 2019, Joseph Myers wrote:
> On Wed, 21 Aug 2019, Martin Jambor wrote:
>
>> - I have listed roundeven variants in extend.texi. If I did not find
>> the right spot, I will gladly move to a more appropriate one.
>
> I don't think they should be documented with the
The DCache clean & ICache invalidation requirements for instructions
to be data coherence are discoverable through new fields in CTR_EL0.
Let's support the two bits if they are enabled, then we can get some
performance benefit from this feature.
2019-08-22 Shaokun Zhang
*
>> Am 02.07.2019 um 17:34 schrieb Ilya Leoshkevich :
>>
>> Bootstrap and regtest running on x86_64-redhat-linux, s390x-redhat-linux
>> and ppc64le-redhat-linux.
>>
>> Currently s390 emits the following sequence to store a frame_pc:
>>
>> a:
>> .LASANPC0:
>>
>> lg
gcc/testsuite/ChangeLog:
2019-08-09 Ilya Leoshkevich
* gcc.target/s390/s390.exp: Enable Fortran tests.
* gcc.target/s390/zvector/autovec-double-quiet-eq.c: New test.
* gcc.target/s390/zvector/autovec-double-quiet-ge.c: New test.
*
dg-torture.exp=inf-compare-1.c is failing, because (qNaN > +Inf)
comparison is compiled to CDB instruction, which does not signal an
invalid operation exception. KDB should have been used instead.
This patch introduces a new CCmode and a new pattern in order to
generate signaling instructions in
s390.md uses a lot of near-identical expanders that perform dispatching
to other expanders based on operand types. Since the following patch
would require even more of these, avoid copy-pasting the code by
generating these expanders using an iterator.
gcc/ChangeLog:
2019-08-09 Ilya Leoshkevich
vec_unordered is vec_ordered plus a negation at the end.
Reuse vec_unordered logic.
gcc/ChangeLog:
2019-08-13 Ilya Leoshkevich
* config/s390/vector.md (vec_unordered): Call
gen_vec_ordered.
---
gcc/config/s390/vector.md | 14 +++---
1 file changed, 7 insertions(+), 7
z13 supports only non-signaling vector comparisons. This means we
cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13. Notify
middle-end about this using more restrictive operator predicate in
vcond.
gcc/ChangeLog:
2019-08-21 Ilya Leoshkevich
* config/s390/vector.md
Currently gcc does not emit wf{c,k}* instructions when comparing long
double values. Middle-end actually adds them in the first place, but
then veclower pass replaces them with floating point register pair
operations, because the corresponding expander is missing.
gcc/ChangeLog:
2019-08-09
z13 supports only non-signaling vector comparisons. This means we
cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13.
However, we cannot express this restriction today: the code only checks
whether vcond$a$b optab exists, which does not contain information about
the operation.
Bootstrap and regtest running on x86_64-redhat-linux and
s390x-redhat-linux.
This patch series adds signaling FP comparison support (both scalar and
vector) to s390 backend.
Patch 1 documents the current behavior of MIN, MAX and LTGT operations
with respect to signaling.
Patches 2-4 make it
Currently it's not clear whether min, max and ltgt should raise floating
point exceptions when dealing with qNaNs.
Right now a lot of code assumes that LTGT is signaling: in particular,
with -fno-finite-math-only, which is the default, it's generated for
the signaling ((x < y) || (x > y)).
The
The next patch introducing can_vector_compare_p function needs to store
rtxes in a hash table and look them up using a special key type.
Currently pointer_hash requires value_type to be the same as
compare_type, so it would not be usable and one would have to implement
mark_deleted, mark_empty,
This fixes quadraticness in STV and makes
machine dep reorg : 89.07 ( 95%) 0.02 ( 18%) 89.10 (
95%) 54 kB ( 0%)
drop to zero. Anybody remembers why it is the way it is now?
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
OK?
Thanks,
Richard.
On Thu, 22 Aug 2019, Richard Biener wrote:
> Not sure if that helps answering your question. In essence,
> this function should tell whether we would emit an UNDEF
> in the end and we want to know that early, at LTO IL generation
> time to communicate this to the linker plugin. Given previous
Hi Wilco,
On 7/22/19 5:18 PM, Wilco Dijkstra wrote:
Remove the remaining Neon adddi3, subdi3 and negdi2 patterns. As a result
adddi3, subdi3 and negdi2 can now always be expanded early
irrespectively of
whether Neon is available. Also expand the extenddi patterns at the same
time. Several
Hi Wilco,
On 7/31/19 5:25 PM, Wilco Dijkstra wrote:
ping
Like the logical operations, expand all shifts early rather than only
sometimes. The Neon shift expansions are never emitted (not even with
-fneon-for-64bits), so they are not useful. So all the late expansions
and Neon shift
Hi Wilco,
On 7/19/19 12:30 PM, Wilco Dijkstra wrote:
Cleanup the logical DImode operations since the current implementation
is way
too complicated. Thumb-1, Thumb-2, VFP/Neon and iwMMXt all work
differently,
resulting in a bewildering number of expansions, patterns and splits
across
When compiling glibc we found that the GOT register was being allocated
r9 when the instruction was still set_got_tmp. That caused set_got to
clobber r9. We cannot simply say set_got_tmp clobbers r9 as this is the
reason for having the temporary set_got_tmp.
Fix by using a register class
On 8/19/19 5:18 PM, James Greenhalgh wrote:
On Thu, Aug 15, 2019 at 12:28:27PM +0100, Kyrill Tkachov wrote:
> Hi all,
>
> On 8/6/19 10:51 AM, Richard Earnshaw (lists) wrote:
> On 18/07/2019 18:18, James Greenhalgh wrote:
> > On Mon, Jun 10, 2019 at 06:21:05PM +0100, Sylvia Taylor wrote:
> >>
On Wed, Aug 21, 2019 at 8:24 PM Prathamesh Kulkarni
wrote:
>
> On Thu, 15 Aug 2019 at 01:50, Richard Sandiford
> wrote:
> >
> > Richard Biener writes:
> > > On Wed, Aug 14, 2019 at 6:49 PM Richard Biener
> > > wrote:
> > >>
> > >> On Wed, Aug 14, 2019 at 5:06 PM Prathamesh Kulkarni
> > >>
Hi Dennis,
On 8/21/19 10:27 AM, Dennis Zhang wrote:
Hi all,
This patch adds '-mcpu' options for following CPUs:
Cortex-A77, Cortex-A76AE, Cortex-A65, Cortex-A65AE, and Cortex-A34.
Related specifications are as following:
https://developer.arm.com/ip-products/processors/cortex-a
On Thu, Aug 22, 2019 at 06:26:57AM -0400, Hans-Peter Nilsson wrote:
> On Wed, 21 Aug 2019, Segher Boessenkool wrote:
> > On Tue, Aug 20, 2019 at 04:05:40PM -0400, Hans-Peter Nilsson wrote:
> > > On Tue, 20 Aug 2019, Jose E. Marchesi wrote:
> > > > > On Thu, Aug 15, 2019 at 12:22:46AM +0200,
On Wed, Aug 21, 2019 at 5:53 PM Jeff Law wrote:
>
> On 8/21/19 7:57 AM, Wilco Dijkstra wrote:
> > Hi Richard,
> >
> >>>
> >>> I think this should be in expand stage where there could be comparison
> >>> of the cost of the RTLs.
> >>
> >> I tend to agree here, if not then for the reason the
On Thu, Aug 22, 2019 at 12:48 AM Jeff Law wrote:
>
> On 8/19/19 7:57 AM, Richard Biener wrote:
>
> >
> > +static tree
> > +objsize_from_type (tree object)
> > +{
> > + if (TREE_CODE (object) != ADDR_EXPR)
> > +return NULL_TREE;
> > +
> > + tree type = TREE_TYPE (object);
> > + if
On Wed, Aug 21, 2019 at 10:10 PM Martin Sebor wrote:
>
> On 8/20/19 1:26 AM, Richard Biener wrote:
> > On Tue, Aug 20, 2019 at 4:32 AM Martin Sebor wrote:
> >>
> >> On 8/19/19 8:10 AM, Richard Biener wrote:
> >>> On Sat, Aug 17, 2019 at 12:43 AM Martin Sebor wrote:
>
> With the recent
I didn't expect this to be contested and not by a frequent
reviewer, but since you took the time to express yourself, I'll
do the same.
On Wed, 21 Aug 2019, Segher Boessenkool wrote:
> On Tue, Aug 20, 2019 at 04:05:40PM -0400, Hans-Peter Nilsson wrote:
> > On Tue, 20 Aug 2019, Jose E. Marchesi
On Thu, Aug 22, 2019 at 2:16 AM Kyrill Tkachov
wrote:
>
> Hi all,
>
> The optimisation to optimise:
> typedef unsigned long long u64;
>
> void bar(u64 *x)
> {
> *x = 0xabcdef10abcdef10;
> }
>
> from:
> mov x1, 61200
> movkx1, 0xabcd, lsl 16
>
On 21.08.19 10:02, Iain Buclaw wrote:
> Hi,
>
> This patch merges the libdruntime library with upstream druntime 5bb8ce19.
>
> Synchronizes extern(C) bindings with the latest release, mostly this
> is just Musl target support.
>
> Bootstrapped and regression tested on x86_64-linux-gnu and
Hi all,
The optimisation to optimise:
typedef unsigned long long u64;
void bar(u64 *x)
{
*x = 0xabcdef10abcdef10;
}
from:
mov x1, 61200
movk x1, 0xabcd, lsl 16
movk x1, 0xef10, lsl 32
movk x1, 0xabcd, lsl 48
str x1, [x0]
On Wed, Aug 21, 2019 at 9:56 PM Joseph Myers wrote:
>
> I'm afraid I'm not clear on the semantics of builtin_with_linkage_p (as in
> the current checked-in version). It says:
>
> /* Return true if the builtin DECL is implemented in a standard library.
>Otherwise returns false which doesn't
Prathamesh Kulkarni writes:
> Hi Richard,
> I screwed up while committing pr88839 fix, by not including the change
> to aarch64-sve.md
> that adds "@" to vcond_mask pattern, which resulted in trunk failing to build
> with: "gen_vcond_mask" was not declared in this scope -:/
> The attached patch
Hi!
On Thu, Aug 22, 2019 at 04:11:46AM +0200, Jose E. Marchesi wrote:
> A colleague (who actually _uses_ eBPF extensively, ahem) tells me that
> the kernel verifier allows to pass addresses of the caller's stack
> frame, tracking that it is a ptr to a stack location, and it knows which
> stack it
Hi Bin,
on 2019/8/22 下午1:46, Bin.Cheng wrote:
> On Thu, Aug 22, 2019 at 11:18 AM Kewen.Lin wrote:
>>
>> Hi Bin,
>>
>> Thanks for your time!
>>
>> on 2019/8/21 下午8:32, Bin.Cheng wrote:
>>> On Wed, Aug 14, 2019 at 3:23 PM Kewen.Lin wrote:
Hi!
Comparing to the previous versions
77 matches
Mail list logo
