Hi Jackson
On Tuesday 10 July 2018 09:37 AM, Jackson Woodruff wrote:
Hi all,
This patch removes some duplicated code. Since this method deals with
four loads or stores, there is a lot of duplicated code that can
easily be replaced with smaller loops.
Regtest and bootstrap OK.
OK for
Hi Jackson,
On 10/07/18 09:37, Jackson Woodruff wrote:
Hi all,
This patch removes some duplicated code. Since this method deals with
four loads or stores, there is a lot of duplicated code that can easily
be replaced with smaller loops.
Regtest and bootstrap OK.
OK for trunk?
This looks
Ho hum, more abstractions.
No change in functionality.
OK for trunk?
gcc/
* vr-values.c (gimple_stmt_nonzero_p): Abstract common code to...
* gimple.c (gimple_call_nonnull_result_p): ...here...
(gimple_call_nonnull_arg): ...and here.
* gimple.h
On 10/07/18 11:10, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 10:39 AM Richard Earnshaw (lists)
> wrote:
>>
>> On 10/07/18 08:19, Richard Biener wrote:
>>> On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw
>>> wrote:
The patches I posted earlier this year for mitigating against
On Tue, Jul 10, 2018 at 12:53 PM Richard Earnshaw (lists)
wrote:
>
> On 10/07/18 11:10, Richard Biener wrote:
> > On Tue, Jul 10, 2018 at 10:39 AM Richard Earnshaw (lists)
> > wrote:
> >>
> >> On 10/07/18 08:19, Richard Biener wrote:
> >>> On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw
> >>>
On Tue, Jul 10, 2018 at 10:39 AM Richard Earnshaw (lists)
wrote:
>
> On 10/07/18 08:19, Richard Biener wrote:
> > On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw
> > wrote:
> >>
> >>
> >> The patches I posted earlier this year for mitigating against
> >> CVE-2017-5753 (Spectre variant 1)
I believe[1][2] that the C++ standard says that
std::condition_variable::wait_for should be implemented to be equivalent
to:
return wait_until(lock, chrono::steady_clock::now() + rel_time);
But the existing implementation uses chrono::system_clock. Now that
wait_until has potentially-different
As currently implemented, condition_variable always ultimately waits
against std::chrono::system_clock. This clock can be changed in arbitrary
ways by the user which may result in us waking up too early or too late
when measured against the caller-supplied clock.
We can't (yet) do much about
On Mon, 2018-07-09 at 15:00 +0200, Richard Biener wrote:
> On Mon, Jul 2, 2018 at 10:51 PM David Malcolm
> wrote:
> >
> > This patch implements a way to consolidate dump_* calls into
> > optinfo objects, as enabling work towards being able to write out
> > optimization records to a file, or emit
I believe I missed this companion patch when I submitted...
Subject: jump threading multiple paths that start from the same BB
The attached patch changes thread_through_all_blocks to allow threads
that start from the same basic block as another thread.
OK for trunk?
gcc/
*
On Tue, Jul 10, 2018 at 1:00 PM David Malcolm wrote:
>
> On Mon, 2018-07-09 at 15:00 +0200, Richard Biener wrote:
> > On Mon, Jul 2, 2018 at 10:51 PM David Malcolm
> > wrote:
> > >
> > > This patch implements a way to consolidate dump_* calls into
> > > optinfo objects, as enabling work towards
On 07/10/2018 12:05 AM, Richard Biener wrote:
> On Mon, Jul 9, 2018 at 9:05 PM Richard Henderson wrote:
>>
>> At the same time, merge several related frame computing functions.
>> Recall that HWI is now always 64-bit, so merge IMASK and FMASK,
>> which allows merging of several loops within
On Tue, Jul 10, 2018 at 2:50 PM Richard Henderson wrote:
>
> On 07/10/2018 12:05 AM, Richard Biener wrote:
> > On Mon, Jul 9, 2018 at 9:05 PM Richard Henderson wrote:
> >>
> >> At the same time, merge several related frame computing functions.
> >> Recall that HWI is now always 64-bit, so merge
On Tue, 10 Jul 2018, Richard Biener wrote:
> On Tue, 10 Jul 2018, Trevor Saunders wrote:
>
> > On Tue, Jul 10, 2018 at 10:43:20AM +0200, Richard Biener wrote:
> > >
> > > The following makes the hash-map iterator dereference return a pair > > Value&> rather than a copy of Value. This matches
The following fixes PR86457. I also removed some leftover tests
of dwarf2out_as_loc_support in favor of output_asm_line_debug_info.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2018-07-10 Richard Biener
PR debug/86457
* dwarf2out.c
Hi,
Jeff told me that the recent popcount built-in detection is causing
kernel build issues as
ERROR: "__popcountsi2"
[drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko] undefined!
I could also reproduce this. AFIK, we should check if the libfunc is
defined while checking popcount?
I
The following avoids constant propagating both on a loop and its
children.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
I'm going to remove the checking code I added before committing
(and I will of course re-test).
Richard.
2018-07-10 Richard Biener
*
On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
wrote:
>
> Hi,
>
> Jeff told me that the recent popcount built-in detection is causing
> kernel build issues as
> ERROR: "__popcountsi2"
> [drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko] undefined!
>
> I could also reproduce
On Tue, Jul 10, 2018 at 03:17:48PM +0200, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
> > Jeff told me that the recent popcount built-in detection is causing
> > kernel build issues as
> > ERROR: "__popcountsi2"
> >
Hi Jackson
On Tuesday 10 July 2018 09:37 AM, Jackson Woodruff wrote:
Hi all,
This patch resolves PR86014. It does so by noticing that the last
load may clobber the address register without issue (regardless of
where it exists in the final ldp/stp sequence). That check has been
changed so
> On Jul 10, 2018, at 2:10 AM, Richard Biener
> wrote:
>
> On Mon, Jul 9, 2018 at 9:08 PM Will Schmidt wrote:
>>
>> Hi,
>> Re-posting. Richard provided feedback on a previous version of this
>> patch, I wanted to make sure he was/is OK with the latest. :-)
>>
>> Add support for Gimple
On Tue, Jul 10, 2018 at 3:27 PM Jakub Jelinek wrote:
>
> On Tue, Jul 10, 2018 at 03:17:48PM +0200, Richard Biener wrote:
> > On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
> > > Jeff told me that the recent popcount built-in detection is causing
> > > kernel build issues as
> > > ERROR:
On Mon, Jul 9, 2018 at 11:26 PM Martin Sebor wrote:
>
> On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
> >{ dg-do run }
> >{ do-options "-O2 -fno-tree-strlen" } */
> >
> > I don't think this is doing anything.
> >
> > If you look at the test run you can see that -fno-tree-strlen is
On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw
wrote:
>
>
> The patches I posted earlier this year for mitigating against
> CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
> which it became obvious that a rethink was needed. This mail, and the
> following patches attempt
Hi!
cp_maybe_instrument_return is looking for a return stmt at the end of
function to decide whether to omit -fsanitize=return instrumentation or
__builtin_unreachable addition. If a STATEMENT_LIST has a return followed
by DEBUG_BEGIN_STMT (or multiple of them), it doesn't find the return
Hi!
This patch (in a backwards compatible way) handles saving and restoring of
linear clause modifiers.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2018-07-10 Jakub Jelinek
PR fortran/86421
* module.c (omp_declare_simd_clauses): Add LINEAR with
On Tue, Jul 10, 2018 at 10:01:10AM +0200, Richard Biener wrote:
> On Tue, 10 Jul 2018, Jakub Jelinek wrote:
> > cp_maybe_instrument_return is looking for a return stmt at the end of
> > function to decide whether to omit -fsanitize=return instrumentation or
> > __builtin_unreachable addition. If
Howdy!
Attached are more cleanups to VRP getting rid of some repetitive code,
as well as abstracting wide int handling code into their own functions.
There should be no change to existing functionality.
You may notice that I have removed the PLUS/MINUS_EXPR handling in
vrp_int_const_binop,
On Mon, Jul 9, 2018 at 9:05 PM Richard Henderson wrote:
>
> At the same time, merge several related frame computing functions.
> Recall that HWI is now always 64-bit, so merge IMASK and FMASK,
> which allows merging of several loops within prologue and epilogue.
Btw, if you're not using these
On Mon, Jul 9, 2018 at 9:08 PM Will Schmidt wrote:
>
> Hi,
> Re-posting. Richard provided feedback on a previous version of this
> patch, I wanted to make sure he was/is OK with the latest. :-)
>
> Add support for Gimple folding for unaligned vector loads and stores.
>
> Regtest completed
Hi!
While working on OpenMP 5.0 range-for support, I've discovered that even for
normal class iterators distribute parallel for gimplification ICEs in
several ways (other composite loop constructs work only because class
iterators are not allowed on them). The problem is that the FEs emit the
On Tue, 10 Jul 2018, Jakub Jelinek wrote:
> Hi!
>
> cp_maybe_instrument_return is looking for a return stmt at the end of
> function to decide whether to omit -fsanitize=return instrumentation or
> __builtin_unreachable addition. If a STATEMENT_LIST has a return followed
> by DEBUG_BEGIN_STMT
On 09/07/18 09:11, Martin Liška wrote:
> Hi.
>
> I'm putting back what I accidentally removed.
>
> Martin
>
> gcc/ChangeLog:
>
> 2018-07-09 Martin Liska
>
> * common.opt: Add back wrongly removed attribute.
> ---
> gcc/common.opt | 2 +-
> 1 file changed, 1 insertion(+), 1
Hi all,
This patch removes some duplicated code. Since this method deals with
four loads or stores, there is a lot of duplicated code that can easily
be replaced with smaller loops.
Regtest and bootstrap OK.
OK for trunk?
Thanks,
Jackson
Changelog:
gcc/
2018-06-28 Jackson Woodruff
Hi all,
This patch resolves PR86014. It does so by noticing that the last load
may clobber the address register without issue (regardless of where it
exists in the final ldp/stp sequence). That check has been changed so
that the last register may be clobbered and the testcase
On 10/07/18 08:19, Richard Biener wrote:
> On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw
> wrote:
>>
>>
>> The patches I posted earlier this year for mitigating against
>> CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
>> which it became obvious that a rethink was
On 07/09/2018 03:56 PM, Jeff Law wrote:
On 07/09/2018 01:19 AM, Aldy Hernandez wrote:
I'd like decisions about how to expand branches deferred until rtl
expansion. Kai was poking at this in the past but never really got any
traction.
For the record, the problem in this testcase is that
The following makes the hash-map iterator dereference return a pair rather than a copy of Value. This matches the hash-table iterator
behavior and avoids issues with
hash_map >
where iterating over the hash-table will call the auto_vec destructor
when dereferencing the iterator. I note
On 10/07/18 00:13, Jeff Law wrote:
> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>>
>> The patches I posted earlier this year for mitigating against
>> CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
>> which it became obvious that a rethink was needed. This mail, and
Adding Jeff and Eric since the patch adds an RTL target hook.
Best regards,
Thomas
On Thu, 5 Jul 2018 at 15:48, Thomas Preudhomme
wrote:
>
> In case of high register pressure in PIC mode, address of the stack
> protector's guard can be spilled on ARM targets as shown in PR85434,
> thus
On Tue, Jul 10, 2018 at 10:43:20AM +0200, Richard Biener wrote:
>
> The following makes the hash-map iterator dereference return a pair Value&> rather than a copy of Value. This matches the hash-table iterator
> behavior and avoids issues with
>
> hash_map >
Eventually somebodies probably
On Tue, 10 Jul 2018, Trevor Saunders wrote:
> On Tue, Jul 10, 2018 at 10:43:20AM +0200, Richard Biener wrote:
> >
> > The following makes the hash-map iterator dereference return a pair > Value&> rather than a copy of Value. This matches the hash-table iterator
> > behavior and avoids issues
On 07/10/2018 01:12 AM, Richard Biener wrote:
On Mon, Jul 9, 2018 at 11:26 PM Martin Sebor wrote:
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
{ dg-do run }
{ do-options "-O2 -fno-tree-strlen" } */
I don't think this is doing anything.
If you look at the test run you can see
On 07/10/2018 08:25 AM, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 4:10 PM Martin Sebor wrote:
>>
>> On 07/10/2018 01:12 AM, Richard Biener wrote:
>>> On Mon, Jul 9, 2018 at 11:26 PM Martin Sebor wrote:
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
>{ dg-do run }
>
On 10/07/18 12:21, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 12:53 PM Richard Earnshaw (lists)
> wrote:
>>
>> On 10/07/18 11:10, Richard Biener wrote:
>>> On Tue, Jul 10, 2018 at 10:39 AM Richard Earnshaw (lists)
>>> wrote:
On 10/07/18 08:19, Richard Biener wrote:
> On Mon,
On Tue, Jul 10, 2018 at 3:33 PM Bill Schmidt wrote:
>
>
> > On Jul 10, 2018, at 2:10 AM, Richard Biener
> > wrote:
> >
> > On Mon, Jul 9, 2018 at 9:08 PM Will Schmidt
> > wrote:
> >>
> >> Hi,
> >> Re-posting. Richard provided feedback on a previous version of this
> >> patch, I wanted to
> On Jul 10, 2018, at 3:49 AM, Richard Earnshaw (lists)
> wrote:
>
> On 10/07/18 00:13, Jeff Law wrote:
>> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>>>
>>> The patches I posted earlier this year for mitigating against
>>> CVE-2017-5753 (Spectre variant 1) attracted some useful
> On Jul 10, 2018, at 8:48 AM, Richard Biener
> wrote:
>
> On Tue, Jul 10, 2018 at 3:33 PM Bill Schmidt wrote:
>>
>>
>>> On Jul 10, 2018, at 2:10 AM, Richard Biener
>>> wrote:
>>>
>>> On Mon, Jul 9, 2018 at 9:08 PM Will Schmidt
>>> wrote:
Hi,
Re-posting. Richard
On 10/07/18 14:48, Bill Schmidt wrote:
>
>> On Jul 10, 2018, at 3:49 AM, Richard Earnshaw (lists)
>> wrote:
>>
>> On 10/07/18 00:13, Jeff Law wrote:
>>> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
The patches I posted earlier this year for mitigating against
CVE-2017-5753
On Tue, Jul 10, 2018 at 4:10 PM Martin Sebor wrote:
>
> On 07/10/2018 01:12 AM, Richard Biener wrote:
> > On Mon, Jul 9, 2018 at 11:26 PM Martin Sebor wrote:
> >>
> >> On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
> >>>{ dg-do run }
> >>>{ do-options "-O2 -fno-tree-strlen" } */
> >>>
>
On Tue, Jul 10, 2018 at 3:51 PM Bill Schmidt wrote:
>
>
> > On Jul 10, 2018, at 8:48 AM, Richard Biener
> > wrote:
> >
> > On Tue, Jul 10, 2018 at 3:33 PM Bill Schmidt wrote:
> >>
> >>
> >>> On Jul 10, 2018, at 2:10 AM, Richard Biener
> >>> wrote:
> >>>
> >>> On Mon, Jul 9, 2018 at 9:08 PM
On 07/10/2018 07:17 AM, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
> wrote:
>>
>> Hi,
>>
>> Jeff told me that the recent popcount built-in detection is causing
>> kernel build issues as
>> ERROR: "__popcountsi2"
>>
On 07/10/2018 07:27 AM, Jakub Jelinek wrote:
> On Tue, Jul 10, 2018 at 03:17:48PM +0200, Richard Biener wrote:
>> On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
>>> Jeff told me that the recent popcount built-in detection is causing
>>> kernel build issues as
>>> ERROR: "__popcountsi2"
>>>
On 07/10/2018 10:01 AM, Andre Vieira (lists) wrote:
> On 09/07/18 09:11, Martin Liška wrote:
>> Hi.
>>
>> I'm putting back what I accidentally removed.
>>
>> Martin
>>
>> gcc/ChangeLog:
>>
>> 2018-07-09 Martin Liska
>>
>> * common.opt: Add back wrongly removed attribute.
>> ---
>>
On 07/10/2018 08:34 AM, Jeff Law wrote:
On 07/10/2018 08:25 AM, Richard Biener wrote:
On Tue, Jul 10, 2018 at 4:10 PM Martin Sebor wrote:
On 07/10/2018 01:12 AM, Richard Biener wrote:
On Mon, Jul 9, 2018 at 11:26 PM Martin Sebor wrote:
On 07/09/2018 08:36 AM, Aldy Hernandez wrote:
{
> On Jul 9, 2018, at 3:25 PM, Martin Sebor wrote:
>
> check_access() calls warning_at() to issue warnings, and that
> function only issues warnings if they are enabled, so the guard
> isn't necessary to make it work this way.
Okay I see.
then, in the current code: (for routine
On 07/10/2018 04:53 AM, Richard Earnshaw (lists) wrote:
> On 10/07/18 11:10, Richard Biener wrote:
>> On Tue, Jul 10, 2018 at 10:39 AM Richard Earnshaw (lists)
>> wrote:
>>>
>>> On 10/07/18 08:19, Richard Biener wrote:
On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw
wrote:
>
>
On 07/10/2018 08:14 AM, Richard Earnshaw (lists) wrote:
> On 10/07/18 14:48, Bill Schmidt wrote:
>>
>>> On Jul 10, 2018, at 3:49 AM, Richard Earnshaw (lists)
>>> wrote:
>>>
>>> On 10/07/18 00:13, Jeff Law wrote:
On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>
> The patches I
"mode" is documented as a variable attribute but not as a type attribute. This
fixes that omission. I simply copied the other text, it seemed suitable as it
stands.
The attributes are normally listed in alphabetical order but "mode" was out of
order in the variable attributes.
Ok for trunk?
On Mon, Jul 09, 2018 at 04:50:03PM -0700, Carl Love wrote:
> The following patch is a back port for a commit to mainline prior to
> GCC 8 release. Note, the code fixed by this patch was later modified
> in commit 256798 as part of adding vec_xst_len support. The sldi
> instruction gets replaced
On 07/10/2018 02:49 AM, Richard Earnshaw (lists) wrote:
> On 10/07/18 00:13, Jeff Law wrote:
>> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>>>
>>> To address all of the above, these patches adopt a new approach, based
>>> in part on a posting by Chandler Carruth to the LLVM developers list
On 10/07/18 16:42, Jeff Law wrote:
> On 07/10/2018 02:49 AM, Richard Earnshaw (lists) wrote:
>> On 10/07/18 00:13, Jeff Law wrote:
>>> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
To address all of the above, these patches adopt a new approach, based
in part on a posting by
On Tue, 2018-07-10 at 16:23 +0200, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 3:51 PM Bill Schmidt wrote:
> >
> >
> > > On Jul 10, 2018, at 8:48 AM, Richard Biener
> > > wrote:
> > >
> > > On Tue, Jul 10, 2018 at 3:33 PM Bill Schmidt
> > > wrote:
> > >>
> > >>
> > >>> On Jul 10, 2018, at
On 07/10/2018 09:14 AM, Qing Zhao wrote:
On Jul 9, 2018, at 3:25 PM, Martin Sebor wrote:
check_access() calls warning_at() to issue warnings, and that
function only issues warnings if they are enabled, so the guard
isn't necessary to make it work this way.
Okay I see.
then, in the current
On July 10, 2018 5:14:37 PM GMT+02:00, Qing Zhao wrote:
>
>> On Jul 9, 2018, at 3:25 PM, Martin Sebor wrote:
>>
>> check_access() calls warning_at() to issue warnings, and that
>> function only issues warnings if they are enabled, so the guard
>> isn't necessary to make it work this way.
>
Hi,
Add support for Gimple folding for unaligned vector loads and stores.
Regtest completed across variety of systems, P6,P7,P8,P9.
[v2] Added the type for the MEM_REF, per feedback.
Testcases for gimple-folding of the same are currently in-tree
as powerpc/fold-vec-load-*.c and
Richard and Martin,
thanks for the info.
> On Jul 10, 2018, at 11:29 AM, Richard Biener wrote:
>> Is the above condition on variable warn_stringop_overflow unnecessary?
>> all the warnings inside check_access are controlled by
>> OPT_Wstringop_overflow_.
>
> Well, the condition certainly saves
There was a typo in the output_macinfo_op gcc_assert.
The function is called dwarf_FORM, not dwarf_form.
Add the provided testcase from the bug to test -gsplit-dwarf -g3.
gcc/ChangeLog:
PR debug/86459
* dwarf2out.c (output_macinfo_op): Fix dwarf_FORM typo in gcc_assert.
On Wed, Jul 11, 2018 at 12:20:08AM +0200, Mark Wielaard wrote:
> There was a typo in the output_macinfo_op gcc_assert.
> The function is called dwarf_FORM, not dwarf_form.
> Add the provided testcase from the bug to test -gsplit-dwarf -g3.
>
> gcc/ChangeLog:
>
> PR debug/86459
> *
This patch alphabetizes the list of AltiVec built-in function prototypes that
consume about 15 pages of the gcc.pdf file. As part of the alphabetization
effort, certain functions that should not be documented in this section of the
manual are separated from the others and moved to the end of
On Tue, Jul 10, 2018 at 6:14 PM Kugan Vivekanandarajah
wrote:
>
> On 10 July 2018 at 23:17, Richard Biener wrote:
> > On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
> > wrote:
> >>
> >> Hi,
> >>
> >> Jeff told me that the recent popcount built-in detection is causing
> >> kernel build
Hi Andrew,
On 11 July 2018 at 11:19, Andrew Pinski wrote:
> On Tue, Jul 10, 2018 at 6:14 PM Kugan Vivekanandarajah
> wrote:
>>
>> On 10 July 2018 at 23:17, Richard Biener wrote:
>> > On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> Jeff told me
On Tue, Jul 10, 2018 at 6:35 PM Kugan Vivekanandarajah
wrote:
>
> Hi Andrew,
>
> On 11 July 2018 at 11:19, Andrew Pinski wrote:
> > On Tue, Jul 10, 2018 at 6:14 PM Kugan Vivekanandarajah
> > wrote:
> >>
> >> On 10 July 2018 at 23:17, Richard Biener
> >> wrote:
> >> > On Tue, Jul 10, 2018 at
On 10 July 2018 at 23:17, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 3:06 PM Kugan Vivekanandarajah
> wrote:
>>
>> Hi,
>>
>> Jeff told me that the recent popcount built-in detection is causing
>> kernel build issues as
>> ERROR: "__popcountsi2"
>>
74 matches
Mail list logo
