https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103971
--- Comment #1 from avieira at gcc dot gnu.org ---
seurer could you check whether
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588237.html fixes this?
I don't have easy access to a powerpc target for bootstrap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
--- Comment #5 from avieira at gcc dot gnu.org ---
Thanks Kewen, that seems worrying, I'll have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
--- Comment #7 from avieira at gcc dot gnu.org ---
Yeah I'm with Richard on this one, I just checked and the generated assembly is
the same for before and after my patch, so this looks like a testism.
And yeah I agree, if we were to decide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015
--- Comment #3 from avieira at gcc dot gnu.org ---
Hi Kewen,
Thanks for the analysis. The param_vect_partial_vector_usage suggestion seems
valid, but that shouldn't be the root cause.
I would expect an unpredicated V8HI epilogue to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103977
--- Comment #7 from avieira at gcc dot gnu.org ---
Thanks for confirming that Jeff :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103977
--- Comment #8 from avieira at gcc dot gnu.org ---
The patch Jeff mentioned is this:
[vect] PR103971, PR103977: Fix epilogue mode selection for autodetect only
gcc/ChangeLog:
* tree-vect-loop.c (vect-analyze-loop): Handle scenario where target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103971
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104498
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104498
--- Comment #7 from avieira at gcc dot gnu.org ---
And I was thinking it didn't know how to handle anchor + offset...
Anyway if I just record the swap and use it to invert the distance calculation
that seems to 'work' for the testcase. I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104498
--- Comment #1 from avieira at gcc dot gnu.org ---
Forgot to mention, this happens during the sched1 pass.
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
Whilst working on a tuning structure I saw a correctness regression that I
believe is a result of the alias attribute not working properly.
You can reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104498
--- Comment #5 from avieira at gcc dot gnu.org ---
You mean this https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294
it only works for direct symbols I think it never enters
the block under: if (GET_CODE (x) == SYMBOL_REF && GET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104498
--- Comment #3 from avieira at gcc dot gnu.org ---
Sorry some confusion there, I thought it was base_alias_check bailing out
early, but that seems to return true, it is the memrefs_conflict_p that returns
0.
I suspect rtx_equal_for_memref_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
--- Comment #10 from avieira at gcc dot gnu.org ---
Hi Levy,
I did a quick experiment, compiled exchange2_r with trunk and with trunk + all
my epilogue and unroll vector patches reverted, with '-march=alderlake -Ofast
-flto -funroll_loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
--- Comment #12 from avieira at gcc dot gnu.org ---
Right and did you happen to see a perf increase on these benchmarks with any of
the patches I mentioned the hash of in the previous comment?
Just to explain a bit further what I think is going
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
--- Comment #7 from avieira at gcc dot gnu.org ---
Hmm thinking out loud here. As vector sizes (or ISAs) change vectorization
strategies could indeed change. Best that I can think of is things like
rounding, where you might need to do operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103997
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157
--- Comment #9 from avieira at gcc dot gnu.org ---
Found the issue, it's due to the way we encode TARGET_CPU_DEFAULT in aarch64,
it is only able to support 64 cores and we have 65 now.
Testing a work around for now and we have plans to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112282
--- Comment #10 from avieira at gcc dot gnu.org ---
So I had a look at that u_lsm.72_510 variable and it's only undefined if we
don't loop, but if we don't loop then u_lsm_flag is set to 0 and we don't use
u_lsm. So it's OK. I also checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112282
--- Comment #11 from avieira at gcc dot gnu.org ---
So I had a look at that u_lsm.72_510 variable and it's only undefined if we
don't loop, but if we don't loop then u_lsm_flag is set to 0 and we don't use
u_lsm. So it's OK. I also checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112282
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111882
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105157
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
--- Comment #18 from avieira at gcc dot gnu.org ---
(In reply to Richard Biener from comment #16)
> (In reply to rsand...@gcc.gnu.org from comment #15)
> > (In reply to Richard Biener from comment #14)
> > > diff --git a/gcc/t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107275
avieira at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |avieira at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107275
avieira at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107275
--- Comment #3 from avieira at gcc dot gnu.org ---
The prodding helped! The problem is that dce was indeed removing the ASM as it
wasn't recognizing it as a stmt that was live. This is because ifcvt would have
normally bailed out when
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
As reported by Eric in
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603356.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107338
--- Comment #3 from avieira at gcc dot gnu.org ---
Hi Kewen,
I believe you are right. I was waiting for a powerpc machine in the board farm,
but I suspect I can reproduce this with an aarch64 BE target and I should be
able to confirm.
But your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107346
--- Comment #3 from avieira at gcc dot gnu.org ---
I am wondering whether I should try to support this, or bail out of
vect_check_gather_scatter if pbitpos is not a multiple of BITS_PER_UNIT. The
latter obviously feels safer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107346
--- Comment #6 from avieira at gcc dot gnu.org ---
> There are no differences between gnat1 and cc1/cc1plus as far as dumps are
> concerned, e.g. -fdump-tree-optimized creates the .optimized dump.
This was my bad, I'm not used to usi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107346
avieira at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |avieira at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107346
--- Comment #4 from avieira at gcc dot gnu.org ---
Funnily enough, if I transform the Int24 into a 32-bit integer in the testcase
and disable all bitfield lowering just to make sure, I get the same failure. I
tried using __attribute__((packed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107326
--- Comment #2 from avieira at gcc dot gnu.org ---
Hi Arseny,
Apologies for this, I thought I had caught this with testing, but seems I had
not. I am testing a fix right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107346
--- Comment #9 from avieira at gcc dot gnu.org ---
Hi Eric,
I realised the same, got a patch pending here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604139.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240
--- Comment #2 from avieira at gcc dot gnu.org ---
Hi Seurer, Peter,
Adding something like: { xfail { powerpc*-*-* && { ! powerpc_vsx_ok } } } }
should xfail all powerpc architectures that don't support this no?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107229
--- Comment #2 from avieira at gcc dot gnu.org ---
So it seems I should have taken DECL_FIELD_OFFSET into account when computing
the bitpos in get_bitfield_rep (tree-if-conv.cc).
I am testing a patch for this whilst I also look at the failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107226
avieira at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-10-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240
--- Comment #4 from avieira at gcc dot gnu.org ---
Might be worth posting the output of -fdump-tree-vect-all might be failing to
vectorize due to some specific lack of feature that we can test for.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
Using the following testcase
$ cat t.c
#include
uint32x4_t foo (uint32x4_t a, uint32x4_t b)
{
mve_pred16_t p = vcmpneq_n_u32 (vandq_u32
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
GCC currently generates wrong code for predicated MVE stores to the same
address. Like:
#include
uint8x16_t foo (uint8x16_t a, uint8_t *pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108177
--- Comment #1 from avieira at gcc dot gnu.org ---
I noticed that for SVE stores seem to be marked as volatile memory accesses, I
suspect it's because they are represented using masked stores which probably
are by definition volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108177
--- Comment #3 from avieira at gcc dot gnu.org ---
The architecture describes it as only writing the true-predicated bytes and
leaving the others untouched. I guess reading and writting to the same memory
is the best we can do to 'mimic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107808
--- Comment #2 from avieira at gcc dot gnu.org ---
Hi Rainer,
I suspect this means SPARC should be added to the list of targets that fail
check_effective_target_vect_long_long. From the dump it looks like the target
doesn't support a long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108442
--- Comment #1 from avieira at gcc dot gnu.org ---
This fails equally for any vld1* vstr1* intrinsic.
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
When compiling:
$ cat t.c
#include
uint32x4_t foo (uint32_t *p)
{
return __arm_vld1q_u32 (p
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
compiling:
$ cat t.c
#include
uint32x4_t foo (uint32_t *a)
{
mve_pred16_t p = 0x00cc;
return vldrwq_z_u32 (a, p);
}
with:
$ arm-none-eabi-gcc -march=armv8.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107987
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107326
--- Comment #5 from avieira at gcc dot gnu.org ---
It looks that way on my end, but I'll let Arseny confirm.
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
Hi,
We ran into a segfault when running SPEC 2017 Parest for aarch64-none-linux-gnu
on a Neoverse V1 target after g:146e45914032
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107326
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #15 from avieira at gcc dot gnu.org ---
@richi: Yeah and as I mentioned on IRC I can confirm it fixes the issue, I also
bootstrapped and regression tested the change on aarch64-unknown-linux-gnu.
Simon, I can't compile your minimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98850
--- Comment #2 from avieira at gcc dot gnu.org ---
I failed to reproduce it with a trunk build of arm-none-linux-gnueabihf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #20 from avieira at gcc dot gnu.org ---
It's probably obvious to people that know Ada, so I just have to apologize for
my ignorance in that area :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #21 from avieira at gcc dot gnu.org ---
Something else that might be obvious, how do I create a minimal ifcvt_demo.adb
file that uses the .ads, so that I can add it as a testcase to gcc, as the
testsuite seems to pick up .adb files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #5 from avieira at gcc dot gnu.org ---
Im slightly confused here, on entry to BB 5 we know the opposite of _1 < 0.0
no? if we branch to BB 5 we know !(_1 < 0.0) so we can't fold _1 <= 1.0, we
just know that the range of _1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
--- Comment #6 from avieira at gcc dot gnu.org ---
Thanks!
My initial investigation has lead me to think the change is being caused at
vrp2, which is the only time the pattern gets triggered with -O2, the tree
before the pass (at the place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #7 from avieira at gcc dot gnu.org ---
I'm still trying to build ADA to reproduce this.
Could you try 'p debug_tree (var)'
if var is a SSA_NAME debug won't print anything. If it comes back as not 0
could you also do p debug_tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #8 from avieira at gcc dot gnu.org ---
Oh nvm... you did.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109543
--- Comment #3 from avieira at gcc dot gnu.org ---
Err that should be 'double d[4];' so:
typedef struct
{
float __attribute__ ((vector_size(16))) v[2];
} STRUCT;
#ifdef GOOD
typedef STRUCT TYPE;
#else
typedef union
{
STRUCT s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109543
--- Comment #2 from avieira at gcc dot gnu.org ---
Sorry for the delay. Here's the typedefs with GNU vectors.
typedef struct
{
float __attribute__ ((vector_size(16))) v[2];
} STRUCT;
#ifdef GOOD
typedef STRUCT TYPE;
#else
typedef union
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
Hi,
So with the following C-code:
$ cat t.c
#include
#ifdef GOOD
typedef float64x2x2_t TYPE;
#else
typedef union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
--- Comment #9 from avieira at gcc dot gnu.org ---
Hmm I was seeing the change in opus_ifft but that does look like different
codegen :/ I might not be looking at the right thing.
That transformation looks definitely wrong though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96342
--- Comment #10 from avieira at gcc dot gnu.org ---
yang I assume you are no longer working on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110142
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110557
--- Comment #5 from avieira at gcc dot gnu.org ---
Hi Xi,
Feel free to test your patch and submit it to the list for review. I had a look
over and it looks correct to me.
I feel like it also addresses the cases where the bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110610
--- Comment #7 from avieira at gcc dot gnu.org ---
> I guess you mean insn-opinit.h, not internal-fn.h. internal-fn.h is in the
> GCC Git repo.
Yeah sorry! I did mean insn-opinit.h
> We are already installing insn-{addr,attr-co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110610
--- Comment #5 from avieira at gcc dot gnu.org ---
intenral-fn.h is generated at gcc build-time. I'm not sure we want to 'install'
it with a gcc install. Might make more sense to trigger a the generation of it
when building this gcc-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110610
--- Comment #8 from avieira at gcc dot gnu.org ---
I'll try adding to one of the header file lists in gcc's makefile. Probably the
INTERNAL_FN_H one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110610
avieira at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-07-10
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110610
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110610
avieira at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110557
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110142
--- Comment #1 from avieira at gcc dot gnu.org ---
Found the issue to be with passing a subtype to vect_recog_widen_op_pattern in
vect_recog_widen_{plus,minus}_pattern where we didn't before. Removing those
and letting it default to a NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110310
--- Comment #2 from avieira at gcc dot gnu.org ---
I can't remember the exact reason either, though I do vaguely remember niter
updating being something that we felt 'needed more future work' at the time.
Just a side question, AVX512 has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110310
--- Comment #4 from avieira at gcc dot gnu.org ---
> OK, so I take away from this that you don't think this is done the way
it is on purpose.
I don't think so, I think I just found a place where it was safe to do so, i.e.
where we k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110436
avieira at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |avieira at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110436
--- Comment #4 from avieira at gcc dot gnu.org ---
Meant to say I'll look at it ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026
--- Comment #4 from avieira at gcc dot gnu.org ---
Drive by comments as it's been a while since I looked at this. I'm also
surprised we didn't adjust the bounds. But why do we only subtract VF? Like you
say, if there's no loop around edge, can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113229
--- Comment #5 from avieira at gcc dot gnu.org ---
Oh forgot to mention, this is triggering because of the div optimization in:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=c69db3ef7f7d82a50f46038aa5457b7c8cc2d643
But I suspect that too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113229
--- Comment #6 from avieira at gcc dot gnu.org ---
Oh forgot to mention, this is triggering because of the div optimization in:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=c69db3ef7f7d82a50f46038aa5457b7c8cc2d643
But I suspect that too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113229
avieira at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2024-01-05
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113040
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
avieira at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
When compiling:
typedef int __attribute__((__vector_size__ (64))) vec;
vec fn (vec a, vec b)
{
return a + b;
}
with '-O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111478
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
--- Comment #10 from avieira at gcc dot gnu.org ---
First of all, apologies for this! I don't know why I didn't test this on x86_64
too, I usually do for such backports.
Anyway I checked locally and backporting:
r14-2821
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
--- Comment #12 from avieira at gcc dot gnu.org ---
Sorry, missed that comment, thanks! I'll test backporting both.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
--- Comment #13 from avieira at gcc dot gnu.org ---
They have both been backported, @Eric the tests should be passing again now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111882
avieira at gcc dot gnu.org changed:
What|Removed |Added
Summary|[13/14/15 Regression] : |[13 Regression] : internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #18 from avieira at gcc dot gnu.org ---
Sorry to be clear, the 'here' in the last sentence refers to supporting masks
as 0x to control the writing of the output register as the ISA allows,
rather than interpret 0x and 0x
101 - 195 of 195 matches
Mail list logo
