https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68932
--- Comment #1 from vries at gcc dot gnu.org ---
at r231665
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68932
Bug ID: 68932
Summary: FAIL: obj-c++.dg/property/at-property-23.mm
-fgnu-runtime (internal compiler error)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68931
Bug ID: 68931
Summary: gccgo fails to build using MUSL libc
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68930
Jan Hubicka changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68930
Bug ID: 68930
Summary: Aggregate replacements not applied to inline function
bodies.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68878
--- Comment #9 from Jan Hubicka ---
Author: hubicka
Date: Wed Dec 16 04:58:13 2015
New Revision: 231671
URL: https://gcc.gnu.org/viewcvs?rev=231671&root=gcc&view=rev
Log:
PR lto/68878
* lto-symtab.c (lto_symtab_prevailing_virtua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58101
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58117
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58149
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12095
Bernd Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68256
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65663
Martin Sebor changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68743
--- Comment #23 from Steve Kargl ---
On Wed, Dec 16, 2015 at 12:23:21AM +, dave.anglin at bell dot net wrote:
> >>
> >> The -fno-builtin option works and gives the best code:
> >>
> >>stw %r2,-20(%r30)
> >>ldo 64(%r30),%r30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66008
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68904
ivan.soleimanipour at oracle dot com changed:
What|Removed |Added
CC||ivan.soleimanipour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66720
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66153
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21273
Bernd Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66250
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66944
Martin Sebor changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68929
--- Comment #1 from Eric Fiselier ---
Created attachment 37044
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37044&action=edit
reproducer.cpp
standalone reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68929
Bug ID: 68929
Summary: GCC hangs in nested template instantiations even after
static_assert fails.
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68743
--- Comment #22 from dave.anglin at bell dot net ---
On 2015-12-15, at 7:02 PM, sgk at troutmask dot apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68743
>
> --- Comment #21 from Steve Kargl ---
> On Tue, Dec 15, 2015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68928
Bug ID: 68928
Summary: AVX loops on unaligned arrays could generate more
efficient startup/cleanup code when peeling
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68927
--- Comment #1 from Bill Long ---
The DEALLOCATE statement in subroutine SUB is attempting to deallocate
a static array with the SAVE attribute. The standard requires that a
non-zero status be returned in cases like this, and execution continues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68927
Bug ID: 68927
Summary: Code aborts in deallocate statement with a stat=
specified
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67669
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68743
--- Comment #21 from Steve Kargl ---
On Tue, Dec 15, 2015 at 08:58:23PM +, danglin at gcc dot gnu.org wrote:
>
> The -fno-builtin option works and gives the best code:
>
> stw %r2,-20(%r30)
> ldo 64(%r30),%r30
> .CAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68926
Bug ID: 68926
Summary: decltype and sfinae to check for template instance
availability
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61298
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68872
--- Comment #1 from Peter Bergner ---
As I mentioned in the binutils bug, I think -mcpu=powerpc64le should mimic
-mcpu=power8. I'll have a look at making that change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #39 from Bill Schmidt ---
I believe this work has been completed. Peter, do you concur?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68069
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867
--- Comment #15 from Steve Kargl ---
On Tue, Dec 15, 2015 at 10:50:35PM +, seurer at linux dot vnet.ibm.com
wrote:
>
> Disabling the test will indeed make it "pass". But it used to run OK and now
> no longer does so is disabling it the right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68775
Bill Seurer changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #15 from Bill Seurer -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867
--- Comment #14 from Bill Seurer ---
Disabling the test will indeed make it "pass". But it used to run OK and now
no longer does so is disabling it the right solution? Looking at pr23685 it
looks like this has gone back and forth several times.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
Tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68925
Bug ID: 68925
Summary: uniform_int_distribution needs not to be thread_local
in std::experimental::randint
Product: gcc
Version: unknown
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10396
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
--- Comment #8 from joseph at codesourcery dot com ---
I'm fine with making the front end smarter. Note that if either side of
the assignment is of floating-point type, you need to keep the existing
logic; if you're adding to / subtracting fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68743
--- Comment #20 from John David Anglin ---
In the ccp1 pass, we had:
;; Function floorf (floorf, funcdef_no=22, decl_uid=167, cgraph_uid=114,
symbol_order=114)
__attribute__((nothrow, leaf, const))
floorf (float x)
{
double _2;
double _3;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63185
--- Comment #6 from Marc Glisse ---
In addition to the issues already described, it seems that we generate better
code if I replace the VLAs with calls to alloca. Indeed, we assume that alloca
returns 16-aligned memory, while with __builtin_alloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68923
Peter Cordes changed:
What|Removed |Added
Keywords||missed-optimization, ssemmx
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68924
Bug ID: 68924
Summary: No intrinsic for x86 `MOVQ m64, %xmm` in 32bit mode.
Product: gcc
Version: 5.3.0
URL: http://stackoverflow.com/questions/34279513/loading-8-
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68923
Bug ID: 68923
Summary: SSE/AVX movq load (_mm_cvtsi64_si128) not being folded
into pmovzx
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68922
Bug ID: 68922
Summary: g++ fails to generate code for catch clause with
specific optimizations enabled
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68921
--- Comment #3 from torvald at gcc dot gnu.org ---
LGTM, thanks. Would be nice to backport this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61347
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 57600, which changed state.
Bug 57600 Summary: Turn 2 comparisons into 1 with the min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57600
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57600
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68921
Carlos O'Donell changed:
What|Removed |Added
CC||carlos at redhat dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55180
Bug 55180 depends on bug 16107, which changed state.
Bug 16107 Summary: missed optimization with some math function builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16107
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16107
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867
--- Comment #13 from Steve Kargl ---
On Tue, Dec 15, 2015 at 06:03:55PM +, seurer at linux dot vnet.ibm.com
wrote:
>
> FAIL: gfortran.dg/default_format_denormal_2.f90 -O0 execution test
> FAIL: gfortran.dg/default_format_denormal_2.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66248
--- Comment #8 from Andrew Pinski ---
Couldn't it be optimized as:
short func(short *a, int y)
{
short ret = 0;
unsigned int tmp = 0;
int i;
for(i = 0; i < y; i++)
tmp += (unsigned int)(int)a[i];
return (short)tmp;
}
Such that the addi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68921
--- Comment #1 from Jonathan Wakely ---
This fixes it:
--- a/libstdc++-v3/src/c++11/futex.cc
+++ b/libstdc++-v3/src/c++11/futex.cc
@@ -52,7 +52,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// we will fall back to spin-waiting. The only thing w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56309
--- Comment #35 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #26)
> Another analysis by Jake in PR54037:
Eh, PR 54073.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67736
Steve Ellcey changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68921
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867
Bill Seurer changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68920
--- Comment #1 from Uroš Bizjak ---
Another incarnation of PR 56309 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68921
Bug ID: 68921
Summary: [5/6 Regression] std::future::wait() makes invalid
futex calls and spins
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66248
Steve Ellcey changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66248
--- Comment #6 from Jon Beniston ---
-fstrict-overflow (which is the default at -O2) tells us that we can assume it
will not overflow.
Even if it did, on most targets it makes no difference to the result.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66616
--- Comment #15 from H.J. Lu ---
(In reply to H.J. Lu from comment #14)
> (In reply to H.J. Lu from comment #13)
> > I got
> >
> > FAIL: g++.dg/ipa/pr66616.C -std=gnu++11 execution test
> > FAIL: g++.dg/ipa/pr66616.C -std=gnu++14 execution tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66616
--- Comment #14 from H.J. Lu ---
(In reply to H.J. Lu from comment #13)
> I got
>
> FAIL: g++.dg/ipa/pr66616.C -std=gnu++11 execution test
> FAIL: g++.dg/ipa/pr66616.C -std=gnu++14 execution test
> FAIL: g++.dg/ipa/pr66616.C -std=gnu++98 exec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66248
--- Comment #5 from Steve Ellcey ---
If we did not truncate ret on each loop iteration then ret could get large
enough to overflow the maximum integer value before we truncate it at the end,
leading to undefined results. But if we truncate ret o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66248
--- Comment #4 from Jon Beniston ---
Well if it is just truncating the higher bits, why can't it be done at the end
of the loop?
What do you think will be different if it is done at the end of the loop? Can
you think of an example where the valu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57348
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66248
--- Comment #3 from Steve Ellcey ---
My understanding (I don't have a C/C++ standard handy) is that the addition
done by 'ret + a[i]' is done in integer mode (not as short). This results in
an integer value that may be outside the range of a sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56934
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62069
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
--- Comment #7 from Andrew Macleod ---
(In reply to Richard Henderson from comment #4)
> I think we should rather handle this in the front end than with
> quite complex pattern matching.
>
> If we want to do any complex logic with atomics in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63383
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63628
--- Comment #4 from Jason Merrill ---
(In reply to Paolo Carlini from comment #3)
> The second and third variants work in mainline.
Yes, they were fixed by the patch for bug 68309. We need a further fix to
handle the original testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68906
--- Comment #3 from Yuri Rumyantsev ---
I've prepared simple fix which cures ICE. I will send it for review tomorrow.
2015-12-15 12:50 GMT+03:00 jakub at gcc dot gnu.org :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68906
>
> Jakub Jelinek c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
--- Comment #6 from Martin Sebor ---
(In reply to Jakub Jelinek from comment #2)
> Doesn't seem to be ppc64le specific in any way, and doesn't affect just
> preincrement.
The inefficiency I was pointing out was the redundant syncs above the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763
Marek Polacek changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|WORKSFORME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68920
Bug ID: 68920
Summary: [6 Regression] Undesirable if-conversion for a rarely
taken branch
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68591
--- Comment #3 from torvald at gcc dot gnu.org ---
This might be related to bug 68616.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
Marek Polacek changed:
What|Removed |Added
Component|target |c
--- Comment #5 from Marek Polacek ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
--- Comment #4 from Richard Henderson ---
I think we should rather handle this in the front end than with
quite complex pattern matching.
If we want to do any complex logic with atomics in the middle-end,
we should change their representation so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674
--- Comment #5 from chrbr at gcc dot gnu.org ---
Created attachment 37041
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37041&action=edit
testcase without arm_neon parts
more concise to avoid mixing the arm_neon intrinsincs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68907
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Tue Dec 15 15:13:49 2015
New Revision: 231656
URL: https://gcc.gnu.org/viewcvs?rev=231656&root=gcc&view=rev
Log:
PR c/68907
* c-typeck.c (build_atomic_assign): Set TREE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908
Marek Polacek changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68907
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #2 from Markus Trippelsdorf ---
While bisecting I also observed gcc spinning when building libgcc during
phase-profile-feedback.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66616
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #13 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
Markus Trippelsdorf changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68919
Bug ID: 68919
Summary: Null-pointer store not removed
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68918
Bug ID: 68918
Summary: spurious "invalid use of incomplete type" in trailing
return type
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21273
--- Comment #2 from Bernd Schmidt ---
Author: bernds
Date: Tue Dec 15 14:34:01 2015
New Revision: 231654
URL: https://gcc.gnu.org/viewcvs?rev=231654&root=gcc&view=rev
Log:
Fix PR21273
PR middle-end/21273
* gensupport.c (collect_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66259
Roger Orr changed:
What|Removed |Added
CC||rogero at howzatt dot
demon.co.uk
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68912
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Tue Dec 15 14:17:17 2015
New Revision: 231652
URL: https://gcc.gnu.org/viewcvs?rev=231652&root=gcc&view=rev
Log:
Fix cv-qualifiers in std::bind invocation
PR libstdc++/68912
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796
--- Comment #10 from Bill Schmidt ---
Apologies, Jonathan, I didn't see that. I was led here from some internal
tracking and wasn't previously CC'd on the bug. Sorry for the noise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781
--- Comment #8 from Thomas Preud'homme ---
Looking more into find_bswap_or_nop, it became clear that the rsize loop is
fine for both endianness because it operates on the result of the expression
being analyzed and that result lies in register.
1 - 100 of 176 matches
Mail list logo
