I've had it in a successful test run, and committed it with a minor
tweak (__builtin_abort vs return 1).
It didn't find anything, but it's probably good to have.
As for the docs, I think you are unnecessarily worried about things
that are never going to be a problem in practice.
Perhaps so
This patch makes the c, c++ and fortran FEs duplicate the reduction
clauses in a combined 'acc parallel loop' directive when it splits that
directive into separate parallel and loop directives. So given something
like
#pragma acc parallel loop reduction(+:var)
for (i = 0; i < 10; i++)
var+
> On Apr 4, 2016, at 5:00 AM, Senthil Kumar Selvaraj
> wrote:
> This patch add dg-require-effective-target directives to a few tests
> that were failing unnecessarily for the AVR target.
So the branch has been cut. We’re now in RM only mode. The change looks
reasonably safe for the branch.
Ping on this; what are the next steps?
Thanks
Aaron Conole writes:
> The previous gcov behavior was to always output errors on the stderr channel.
> This is fine for most uses, but some programs will require stderr to be
> untouched by libgcov for certain tests. This change allows configuring
>
We didn't have __builtin_swap16 on all targets before GCC 4.8; hsa-brig
tries to use it if the host GCC is 4.6 or up though, breaking bootstrap.
This trivial patch fixes it.
Noticed on gcc22.
Is this okay for trunk and gcc-6?
Segher
2016-04-15 Segher Boessenkool
* has-brig.c (lend
The problem here was that instantiation_dependent_r considered the
instantiated TEMPLATE_ID_EXPR to be type-dependent because it had no
type, rather than unknown_type_node like those built by
lookup_template_function.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 77dfecd59a3f96830d0465
Hi Bernd,
>>> index = d_compact_number (di) + 1; if (index == 0) return NULL;
>>>
>>> which probably ought to have the same kind of check (I'll note that
>>> at this point we've accumulated two "+1"s, I'll assume that's what
>>> we want).
>> Yes. There should be an overflow check here.
>
> Could
On Fri, 15 Apr 2016, Michael Matz wrote:
> On Thu, 14 Apr 2016, Maxim Kuvyrkov wrote:
>
> > It appears that implementing -fprolog-pad=N option in GCC will not
> > enable kernel live-patching support for AArch64. The proposal for the
> > option was to make GCC output a given number of NOPs at th
On Fri, Apr 15, 2016 at 07:05:25PM +0200, Olivier Hainque wrote:
> > But don't you run the risk that the stack could be deallocated before the
> > restores are done? This came up on the PA port a long time ago. IIRC the
> > situations was something like this:
> >
> > We had a frame pointer and
> On Apr 15, 2016, at 18:42 , Jeff Law wrote:
>> /* (mem:BLK (scratch)) is a special mechanism to conflict with everything.
>> This is used in epilogue deallocation functions. */
> *That's* the one I was looking for :-)
:-)
>> Yes, I pondered this one and thought that a memory barrier
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1896,10 +1896,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(for cmp (simple_comparison)
scmp (swapped_simple_comparison)
(simplify
- (cmp (bit_not@2 @0) CONSTANT_CLASS_P@1)
+ (cmp (convert?@3 (bit_not@2 @0)) CONSTANT_CLASS_P@1)
(if (single_use
On 04/14/2016 11:10 AM, Olivier Hainque wrote:
On 14 Apr 2016, at 18:50, Jeff Law wrote:
I thought we had code to handle this case specially, but I can't immediately
find it in sched-deps.c.
Unless I misunderstood what you were exactly looking for,
the special code is in alias.c. E.g. writ
On Fri, Apr 15, 2016 at 03:12:58PM +0100, Kyrill Tkachov wrote:
>
> On 15/04/16 15:10, Kyrill Tkachov wrote:
> >Hi all,
> >
> >This is a repost of Andrew's fix for PR target/64971 that was originally
> >posted at:
> >https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00502.html
> >
> >The only change
On Thu, 14 Apr 2016, Hurugalawadi, Naveen wrote:
I think we should handle at least INTEGER_CST and SSA_NAME
with VRP, and it seems natural to add a VRP check
The check should be added in the tree_single_nonzero_warnv_p
for SSA_NAME case for tree_expr_nonzero_p.
I think so.
However, for tre
On 04/15/2016 10:20 AM, Kyrill Tkachov wrote:
This was resolved with:
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00724.html
Sorry, I should have replied to this thread...
No worries. I probably should have checked the testcase before replying
to the older email thread.
jeff
On 15/04/16 17:18, Jeff Law wrote:
On 04/15/2016 05:06 AM, Kyrill Tkachov wrote:
On 05/04/16 23:35, Segher Boessenkool wrote:
On Tue, Apr 05, 2016 at 10:48:58AM +0100, Kyrill Tkachov wrote:
So for the test gcc.dg/pr10474.c on arm with -marm -O3 before this
patch we
perform shrink-wrapping:
On 04/15/2016 05:06 AM, Kyrill Tkachov wrote:
On 05/04/16 23:35, Segher Boessenkool wrote:
On Tue, Apr 05, 2016 at 10:48:58AM +0100, Kyrill Tkachov wrote:
So for the test gcc.dg/pr10474.c on arm with -marm -O3 before this
patch we
perform shrink-wrapping:
cmpr0, #0
bxeqlr
On 04/15/2016 08:10 AM, Kyrill Tkachov wrote:
Hi all,
This is a repost of Andrew's fix for PR target/64971 that was originally
posted at:
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00502.html
The only change is that I substituted DImode for Pmode and added a FIXME
comment
to remind us to rev
On Fri, Apr 15, 2016 at 01:41:25PM +0200, Jakub Jelinek wrote:
> On Fri, Apr 15, 2016 at 01:37:07PM +0200, Bernd Schmidt wrote:
> > On 04/15/2016 02:35 AM, Segher Boessenkool wrote:
> > >This now also shows up on GCC 5, see PR70672. It there happens in
> > >the jump1 pass already.
> > >
> > >Is th
Hi,
On Thu, 14 Apr 2016, Maxim Kuvyrkov wrote:
> It appears that implementing -fprolog-pad=N option in GCC will not
> enable kernel live-patching support for AArch64. The proposal for the
> option was to make GCC output a given number of NOPs at the beginning of
> each function, and then the
On Fri, Apr 15, 2016 at 06:21:56PM +0300, Kirill Yukhin wrote:
> Hi,
> On 15 Apr 06:43, H.J. Lu wrote:
> > [hjl@gnu-6 gcc]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
> > -B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -mx32 -mtune=slm
> > -fno-diagnostics-show-caret -fdiagnostics-
On Thu, Apr 14, 2016 at 11:34 AM, Thomas Schwinge
wrote:
> Hi!
>
> On Tue, 15 Apr 2014 09:58:41 +0200, Richard Biener
> wrote:
>> On Mon, Apr 14, 2014 at 4:48 PM, Patrick Palka wrote:
>> > This patch marks "static" a bunch of locally-used, non-debug functions
>> > within the GCC sources. Doing
Hi,
On 15 Apr 06:43, H.J. Lu wrote:
> [hjl@gnu-6 gcc]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
> -B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -mx32 -mtune=slm
> -fno-diagnostics-show-caret -fdiagnostics-color=never -Og
> -fschedule-insns -fno-tree-fre -mavx512vbmi
> --param
> On Apr 15, 2016, at 00:42 , Segher Boessenkool
> wrote:
>
>>
>> Something like the attached patch, at least for next stage1 until the
>> more general issue is sorted out ?
>
> It's a bit heavy; as a workaround, we may want this clobber in the stack
> deallocation in the epilogue, but not in
On 04/15/16 10:42, Jason Merrill wrote:
OK, let's go ahead with this.
Thanks for committing Jakub. I've just moved the changelog to cp/ChangeLog
though.
nathan
OK, let's go ahead with this.
Jason
On Fri, Apr 15, 2016 at 04:38:27PM +0200, Marek Polacek wrote:
> This patch improves the location of the error message about taking the address
> of a bit-field. While at it, I also fixed two other similar spots.
>
> Not a regression, but given its extreme triviality I thought this could have
> g
This patch improves the location of the error message about taking the address
of a bit-field. While at it, I also fixed two other similar spots.
Not a regression, but given its extreme triviality I thought this could have
gone in even at this time.
Bootstrapped/regtested on x86_64-linux, ok for
Hello,
I have committed to trunk as obvious the following patch to add a missing
period at the end of help text for the '-moptimize' NVPTX backend option.
Alexander
* config/nvptx/nvptx.opt (moptimize): Add a period at end of help text.
--- gcc/config/nvptx/nvptx.opt
+++ gcc/config/nvpt
Hi!
On Fri, 15 Apr 2016 14:15:42 +0200, Jakub Jelinek wrote:
> On Fri, Apr 15, 2016 at 02:11:45PM +0200, Thomas Schwinge wrote:
> > On Fri, 15 Apr 2016 13:57:05 +0200, Jakub Jelinek wrote:
> > > On Fri, Apr 15, 2016 at 01:53:14PM +0200, Thomas Schwinge wrote:
> > > > For all the other splitting
On 04/15/2016 06:31 AM, Jakub Jelinek wrote:
On Thu, Apr 14, 2016 at 09:26:11AM -0600, Martin Sebor wrote:
/daten/aranym/gcc/gcc-20160414/gcc/testsuite/g++.dg/cpp1y/vla11.C: In instantiation
of 'struct TestType<32u>':
/daten/aranym/gcc/gcc-20160414/gcc/testsuite/g++.dg/cpp1y/vla11.C:201:1:
r
On 15/04/16 15:10, Kyrill Tkachov wrote:
Hi all,
This is a repost of Andrew's fix for PR target/64971 that was originally posted
at:
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00502.html
The only change is that I substituted DImode for Pmode and added a FIXME comment
to remind us to revisi
Hi all,
This is a repost of Andrew's fix for PR target/64971 that was originally posted
at:
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00502.html
The only change is that I substituted DImode for Pmode and added a FIXME comment
to remind us to revisit this (see the PR in bugzilla for more inf
On Fri, Apr 15, 2016 at 12:57 AM, Kirill Yukhin wrote:
> Hello,
> Patch in the bottom fixes memory operand modifiers
> for Intel syntax on broadcast patter.
>
> Bootstrapped and regtested on 32,64b x86 target.
>
> I'll check it into main trunk and gcc-5 branch.
>
> gcc/
> PR target/70662
>
On 08/04/16 10:28, Richard Earnshaw (lists) wrote:
On 01/03/16 16:17, Kyrill Tkachov wrote:
Hi all,
For GCC 6 we want to deprecate architecture revisions prior to ARMv4T.
This patch implements this by documenting the deprecation in invoke.texi
and adding
a warning whenever the user specifies a
On 04/15/2016 10:32 AM, Uros Bizjak wrote:
This fixes possible wrong code with a tricky failure mode, so OK now.
Thanks.
[...]
While changing this part, it can be rewritten using dg-additional options, e.g.:
/* { dg-options "-Os -fomit-frame-pointer -fasynchronous-unwind-tables
-mno-red-zon
On Wed, Apr 13, 2016 at 04:14:03PM +0200, Marek Polacek wrote:
> I revamped the warning so that it follows what the C++ FE does (i.e. passing
> IF_P bools here and there) and it seems to work quite well. I didn't mean to
> tackle the OMP bits but I bet it would be just a matter of passing IF_P
>
On Fri, Apr 15, 2016 at 02:58:21PM +0200, Marek Polacek wrote:
> Hopefully one of the last P1s for GCC 6. The problem in this PR was that we
> were triggering an assert in build_va_arg on invalid code which used wrong
> type
> of va_arg. We should rather error out than ICE; this patch thus turns
On 04/15/16 05:57, Richard Biener wrote:
On Thu, Apr 14, 2016 at 3:45 PM, Jakub Jelinek wrote:
On Thu, Apr 14, 2016 at 09:43:26AM -0400, Jason Merrill wrote:
On 04/14/2016 09:25 AM, Nathan Sidwell wrote:
On 04/13/16 15:41, Jason Merrill wrote:
The fini_constexpr stuff is OK immediately.
A
Hopefully one of the last P1s for GCC 6. The problem in this PR was that we
were triggering an assert in build_va_arg on invalid code which used wrong type
of va_arg. We should rather error out than ICE; this patch thus turns asserts
into errors. Only removing the assert would probably work as w
Bernd Schmidt writes:
> On 04/07/2016 01:52 PM, Senthil Kumar Selvaraj wrote:
>>The below patch fixes PR 60040 by not halting with a hard error on
>>a spill failure, if reload knows that it has to run again anyway.
>
> Some additional information as to how this situation creates a spill
On Fri, 15 Apr 2016, Jakub Jelinek wrote:
> Hi!
>
> The testcase in the PR (too large for the testsuite) fails -fcompare-debug,
> because do_niy doesn't honor dump flags (TDF_NOUID in this case).
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
Ok.
Richa
On 15/04/16 13:40, Jakub Jelinek wrote:
On Fri, Apr 15, 2016 at 01:38:57PM +0100, Kyrill Tkachov wrote:
Hi Jakub,
On 15/04/16 13:26, Jakub Jelinek wrote:
On Fri, Apr 15, 2016 at 01:22:52PM +0100, Kyrill Tkachov wrote:
As reported (https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00094.html)
the
On Fri, Apr 15, 2016 at 01:38:57PM +0100, Kyrill Tkachov wrote:
> Hi Jakub,
>
> On 15/04/16 13:26, Jakub Jelinek wrote:
> >On Fri, Apr 15, 2016 at 01:22:52PM +0100, Kyrill Tkachov wrote:
> >>As reported (https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00094.html)
> >>these two tests now fail to perf
Hi Jakub,
On 15/04/16 13:26, Jakub Jelinek wrote:
On Fri, Apr 15, 2016 at 01:22:52PM +0100, Kyrill Tkachov wrote:
As reported (https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00094.html)
these two tests now fail to perform shrinkwrapping after a regalloc change,
but at least on arm the resulting
On Thu, Apr 14, 2016 at 09:26:11AM -0600, Martin Sebor wrote:
> >/daten/aranym/gcc/gcc-20160414/gcc/testsuite/g++.dg/cpp1y/vla11.C: In
> >instantiation of 'struct TestType<32u>':
> >/daten/aranym/gcc/gcc-20160414/gcc/testsuite/g++.dg/cpp1y/vla11.C:201:1:
> >required from here
> >/daten/aranym/g
On Fri, Apr 15, 2016 at 01:22:52PM +0100, Kyrill Tkachov wrote:
> As reported (https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00094.html)
> these two tests now fail to perform shrinkwrapping after a regalloc change,
> but at least on arm the resulting code is not worse (not clear if better
> either
Hi all,
As reported (https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00094.html)
these two tests now fail to perform shrinkwrapping after a regalloc change,
but at least on arm the resulting code is not worse (not clear if better
either).
They have also been reported to fail on powerpc
One of th
Hi!
The testcase in the PR (too large for the testsuite) fails -fcompare-debug,
because do_niy doesn't honor dump flags (TDF_NOUID in this case).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2016-04-15 Jakub Jelinek
PR c++/70675
* tree-pr
On Fri, Apr 15, 2016 at 02:11:45PM +0200, Thomas Schwinge wrote:
> Hi!
>
> On Fri, 15 Apr 2016 13:57:05 +0200, Jakub Jelinek wrote:
> > On Fri, Apr 15, 2016 at 01:53:14PM +0200, Thomas Schwinge wrote:
> > > For all the other splitting patches that I have posted/proposed, the idea
> > > then is to
Hi!
On Fri, 15 Apr 2016 13:57:05 +0200, Jakub Jelinek wrote:
> On Fri, Apr 15, 2016 at 01:53:14PM +0200, Thomas Schwinge wrote:
> > For all the other splitting patches that I have posted/proposed, the idea
> > then is to commit these onto both gcc-6-branch and trunk?
>
> If we branch today, then
On Fri, Apr 15, 2016 at 01:53:14PM +0200, Thomas Schwinge wrote:
> Hi!
>
> On Fri, 15 Apr 2016 13:15:07 +0200, Jakub Jelinek wrote:
> > On Thu, Apr 14, 2016 at 10:27:40PM +0200, Thomas Schwinge wrote:
> > > On Thu, 14 Apr 2016 18:01:13 +0200, I wrote:
> > > > "simdclone" pass, with the
> > > > re
Hi!
On Fri, 15 Apr 2016 13:15:07 +0200, Jakub Jelinek wrote:
> On Thu, Apr 14, 2016 at 10:27:40PM +0200, Thomas Schwinge wrote:
> > On Thu, 14 Apr 2016 18:01:13 +0200, I wrote:
> > > "simdclone" pass, with the
> > > respective supporting code. I will certainly submit line-diff patches if
> > > w
On Fri, Apr 15, 2016 at 01:37:07PM +0200, Bernd Schmidt wrote:
> On 04/15/2016 02:35 AM, Segher Boessenkool wrote:
> >This now also shows up on GCC 5, see PR70672. It there happens in
> >the jump1 pass already.
> >
> >Is this okay to backport to 5 and 4.9?
>
> Ok.
Can you please also create a ru
On 04/13/2016 03:04 PM, Marcel Böhme wrote:
Hi Bernd,
Shouldn't we check for overflows before performing the +1 addition
(i.e. 0 <= num < INT_MAX)? Ideally we'd also have a way to signal
from d_number if we had an overflow while parsing that number.
Without an overflow signal, d_number will alr
On 04/15/2016 02:35 AM, Segher Boessenkool wrote:
This now also shows up on GCC 5, see PR70672. It there happens in
the jump1 pass already.
Is this okay to backport to 5 and 4.9?
Ok.
Bernd
> On Thu, Apr 14, 2016 at 10:40:43AM -0600, Jeff Law wrote:
> > Given the BZ & list discussion, I'd consider the patch approved.
> >
> > I *think* the way to deal with the BZ is to change the regression marker to
> > 7 and the target milestone as well. I think leaving it as a P1 would be
> > fine
On Thu, Apr 14, 2016 at 10:27:40PM +0200, Thomas Schwinge wrote:
> On Thu, 14 Apr 2016 18:01:13 +0200, I wrote:
> > "simdclone" pass, with the
> > respective supporting code. I will certainly submit line-diff patches if
> > we agree that this is sound -- these two may actually be good candidates
>
On 05/04/16 23:35, Segher Boessenkool wrote:
On Tue, Apr 05, 2016 at 10:48:58AM +0100, Kyrill Tkachov wrote:
So for the test gcc.dg/pr10474.c on arm with -marm -O3 before this patch we
perform shrink-wrapping:
cmpr0, #0
bxeqlr
push{r4, lr}
movr4, r0
...
On 15/04/16 12:23, Richard Biener wrote:
On Fri, Apr 15, 2016 at 11:44 AM, Sebastian Huber
wrote:
>I work currently on a better FreeBSD compatibility for Newlib. For
>RTEMS we use the network, USB, SD/MMC stacks from FreeBSD. It would be
>nice to use , etc. from Newlib directly to compile
As pointed out by Richard, for signed & sign-bit-CST value range should
be [-INF, 0] range, not a [-INF, INF] range as happens now.
This patch fixes this. I bootstrapped and regression tested for
x86-64-linux-gnu with no new regression. Is this OK for statege-1.
Thanks,
Kugan
gcc/ChangeLog:
On Fri, Apr 15, 2016 at 11:44 AM, Sebastian Huber
wrote:
> I work currently on a better FreeBSD compatibility for Newlib. For
> RTEMS we use the network, USB, SD/MMC stacks from FreeBSD. It would be
> nice to use , etc. from Newlib directly to compile FreeBSD
> user and kernel space files.
>
> V
TLS mods for ARC backend.
OK to apply?
Claudiu
gcc/
2016-04-15 Claudiu Zissulescu
Joern Rennecke
* config/arc/arc-protos.h (arc_legitimize_pic_address): Remove
declaration.
(emit_pic_move): Remove.
(arc_eh_uses, insn_is_tls_gd_dispatch): Declare.
TLS mods for libgcc.
OK to apply?
Claudiu
libgcc/
2016-04-15 Claudiu Zissulescu
Joern Rennecke
* config/arc/crttls.S: New file.
* config/arc/t-arc: New rule.
* config.host (arc*-*-elf*, arc*-*-linux*): Add crttls.o.
---
libgcc/config.host | 2 ++
Hi,
This series of two patches are adding TLS support for ARC
processors. The first patch is changing libgcc, the second patch is
changing the ARC' backend. I've tested the mods using dg.exp,
compile.exp, tls.exp, and execute.exp.
Ok to apply?
Claudiu
Claudiu Zissulescu (2):
[ARC/LIBGCC] Add T
On Thu, Apr 14, 2016 at 3:45 PM, Jakub Jelinek wrote:
> On Thu, Apr 14, 2016 at 09:43:26AM -0400, Jason Merrill wrote:
>> On 04/14/2016 09:25 AM, Nathan Sidwell wrote:
>> >On 04/13/16 15:41, Jason Merrill wrote:
>> >
>> >>The fini_constexpr stuff is OK immediately.
>> >
>> >As those two objects ar
I work currently on a better FreeBSD compatibility for Newlib. For
RTEMS we use the network, USB, SD/MMC stacks from FreeBSD. It would be
nice to use , etc. from Newlib directly to compile FreeBSD
user and kernel space files.
Various FreeBSD source and header files need a typedef __size_t via
.
Hi!
On Thu, 14 Apr 2016 14:21:33 -0700, Cesar Philippidis
wrote:
> This patch fixes a segfault in libgomp.oacc-fortran/non-scalar-data.f90.
> The problem here is that 'n' is a parameter, and the kernels region
> implicitly adds a copy clause to n. Naturally, the test segfaults when
> it comes ti
On 15 Apr 10:57, Kirill Yukhin wrote:
> Hello,
> Patch in the bottom fixes memory operand modifiers
> for Intel syntax on broadcast patter.
>
> Bootstrapped and regtested on 32,64b x86 target.
>
> I'll check it into main trunk and gcc-5 branch.
>
> gcc/
> PR target/70662
> * config/i
Hello,
Patch in the bottom fixes memory operand modifiers
for Intel syntax on broadcast patter.
Bootstrapped and regtested on 32,64b x86 target.
I'll check it into main trunk and gcc-5 branch.
gcc/
PR target/70662
* config/i386/sse.md: Use proper memory operand
modifiers.
> On Apr 15, 2016, at 06:37 , Andreas Krebbel
> wrote:
>> /* (mem:BLK (scratch)) is a special mechanism to conflict with everything.
>> This is used in epilogue deallocation functions. */
>> ...
>
> Ok thanks. I've verified that the dependencies are also generated when
> using this expre
The previous "fix" for the PR just fixed the testcase by chance. The
following (more dangerous at this point I thought) fix instead attacks
the issue correctly, fixing the DF problem to be no longer unstable.
Hopefully - the events are that while everything is sound value-wise
(which is where we
On 14 April 2016 at 17:26, Martin Sebor wrote:
> On 04/14/2016 04:39 AM, Andreas Schwab wrote:
>>
>> Martin Sebor writes:
>>
>>> diff --git a/gcc/testsuite/g++.dg/cpp1y/vla11.C
>>> b/gcc/testsuite/g++.dg/cpp1y/vla11.C
>>> new file mode 100644
>>> index 000..af9624a
>>> --- /dev/null
>>> +++ b
Hi All,
I'm trying to port GCC 5.2.0 (with intention to send it here later)
for new target OS - Phoenix-RTOS. However I'm experiencing compilation
error and I can't figure out why. Port is supposed to work for ARM
Cortex-A5.
Here is my patch, that I try to apply:
-
74 matches
Mail list logo
