https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413
--- Comment #5 from Andrew Pinski ---
GCC has the following in it:
::= sr# dependent name
::= sr*/
Hmm, maybe the ABI changed and GCC did not change with it ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58318
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88416
Bug ID: 88416
Summary: [8/9 Regression] ICE in in df_uses_record, at
df-scan.c:3013
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88414
Bug ID: 88414
Summary: [9 Regression] ICE in lra_assign, at
lra-assigns.c:1624
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88415
Bug ID: 88415
Summary: [7/8/9 Regression] ICE: verify_gimple failed (error:
dead STMT in EH table)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79636
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69899
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80540
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413
--- Comment #4 from brennan at umanwizard dot com ---
Investigating a bit more, it seems Apple patched their c++filt to just call
into __cxa_demangle in their own libc++abi , so it makes sense that c++filt on
macOS matches clang and on Linux match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413
--- Comment #3 from Andrew Pinski ---
[apinski@linux gcc]$ c++filt _Z1gIiEvP2S1IXsr2S2IT_EE3valEE
_Z1gIiEvP2S1IXsr2S2IT_EE3valEE
[apinski@linux gcc]$ c++filt _Z1gIiEvP2S1IXsr2S2IT_E3valEE
void g(S1::val>*)
[apinski@linux gcc]$ c++filt --version
G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413
--- Comment #2 from brennan at umanwizard dot com ---
I find the opposite, on whatever ancient version of c++filt ships with macOS:
$ c++filt --version
GNU c++filt 070207 20070207
Copyright 2005 Free Software Foundation, Inc.
This program is free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413
--- Comment #1 from Andrew Pinski ---
Hmm, interesting because the C++ demanager that is part of GCC is able to
demanage GCC's and not clang's.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413
Bug ID: 88413
Summary: g++ mangles names involving unresolved names in
function argument template parameters differently from
the ABI standard.
Product: gcc
Versi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88412
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331
--- Comment #5 from mateuszb at poczta dot onet.pl ---
Bug started with r266345
Both files pixel.ii and slicetype.ii could be compile by gcc 9 r266344 and both
files ICE gcc 9 r266345.
I've attached xz archive with both *.ii files (maybe it helps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88396
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #17 from Jan Hubicka ---
I am re-doing benchmarks now to see where we are standing with gcc9.
I have checked reducing max-inline-insns-single as Richard mentioned, reducing
to 200 or 300 basically brings one regression and that is Cac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401
--- Comment #5 from Ulya ---
(In reply to Jakub Jelinek from comment #4)
Right, I see.
Bugzilla forced me to add the previous comment when I changed the status. ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #16 from Pat Haugen ---
>
> Do you observe the same slowdown if you restore either of the params to
> the value before the r257582 change?
>
--param max-inline-insns-auto=40 results in the same degradation.
--param inline-min-spee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185
Jeffrey A. Law changed:
What|Removed |Added
Summary|[7/8/9 Regression] register |[7/8 Regression] register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77499
--- Comment #17 from Jeffrey A. Law ---
So if one manually does the sinking I suggest in c#14, we get the key insns
into their own block (it's not *that* convoluted). That's still not enough to
address the regression in this BZ. We lose the und
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88412
Bug ID: 88412
Summary: Associate segmentation fault assigning to derived type
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Keywords: easyhack
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 87449, which changed state.
Bug 87449 Summary: -Wunused-variable and associate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87449
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87449
Martin Diehl changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411
--- Comment #1 from Harald Anlauf ---
Further data points:
- removing the asynchronous='yes' for the first OPEN has no effect,
- removing the asynchronous='yes' for the second OPEN makes the problem
disappear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
--- Comment #3 from Alexander Monakov ---
However, this may be worthwhile when one of operands is an immediate, as in
that case there's no register pressure increase, and the xor just mutates the
immediate.
Essentially, we'd change e.g.
(sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411
Bug ID: 88411
Summary: [9 Regression] Random crashes for ASYNCHRONOUS writes
(bad locking?)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288
--- Comment #16 from Segher Boessenkool ---
Many things in combine assume that they can move an earlier insn to later,
if none of the registers it uses is set in the intermediate insns (etc.)
This isn't correct if you make combine work on EBBs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88410
Bug ID: 88410
Summary: internal compiler error: output_operand: invalid
expression as operand
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #15 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69633
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #13 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
--- Comment #13 from Segher Boessenkool ---
Yeah, that's not going to happen.
Will it help to do some define_split or define_insn_and_split for this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88316
--- Comment #4 from pc at gcc dot gnu.org ---
SSSE3 is still broken. Working on it...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87496
--- Comment #10 from Peter Bergner ---
Author: bergner
Date: Fri Dec 7 17:33:55 2018
New Revision: 266899
URL: https://gcc.gnu.org/viewcvs?rev=266899&root=gcc&view=rev
Log:
gcc/
PR target/87496
* config/rs6000/rs6000.c (rs6000_o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
--- Comment #6 from H.J. Lu ---
(In reply to Nick Clifton from comment #5)
> (In reply to H.J. Lu from comment #4)
>
> > I am expecting that
> >
> > [hjl@gnu-cfl-1 libiberty]$ c++filt
> > _ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861
--- Comment #9 from Jeffrey A. Law ---
Jakub -- with your patch and qsort checking hacked off I got a successful ia64
bootstrap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87995
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88408
pc at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87813
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88408
pc at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
--- Comment #5 from Nick Clifton ---
(In reply to H.J. Lu from comment #4)
> I am expecting that
>
> [hjl@gnu-cfl-1 libiberty]$ c++filt
> _ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS0_9ParserRefINS2_UlRN
> S2_16TokenParserInputEE_EE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
--- Comment #4 from H.J. Lu ---
(In reply to Nick Clifton from comment #3)
> (In reply to H.J. Lu from comment #2)
>
> Hi H.J.
>
> > > The attached patch resolves the problem by adding a --no-recurse-limit
> > > option to the demangler testser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88349
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
Nick Clifton changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Nick Clifton
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88408
--- Comment #2 from pc at gcc dot gnu.org ---
Author: pc
Date: Fri Dec 7 16:32:34 2018
New Revision: 266895
URL: https://gcc.gnu.org/viewcvs?rev=266895&root=gcc&view=rev
Log:
[rs6000] mmintrin.h: fix use of "vector"
A recent patch inadvertently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
Nick Clifton changed:
What|Removed |Added
CC||nickc at gcc dot gnu.org
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88408
seurer at gcc dot gnu.org changed:
What|Removed |Added
Target|powerpc64-unknown-linux-gnu |powerpc64*-unknown-linux-gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
Bug ID: 88409
Summary: [9 Regression] FAIL at line 4429, options
--format=gnu-v3:
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88271
--- Comment #9 from Daniel Fruzynski ---
I have idea about alternate approach to this. gcc could try to look for
relations between loop control statement, and other statements which modify
variables used in that control statement. With such knowl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88349
--- Comment #2 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Dec 7 16:08:17 2018
New Revision: 266894
URL: https://gcc.gnu.org/viewcvs?rev=266894&root=gcc&view=rev
Log:
2018-12-07 Vladimir Makarov
PR rtl-optimization/88349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861
--- Comment #8 from Jeffrey A. Law ---
We certainly get further with your patch -- we fail qsort checking during the
stage2 build, but that's nothing new. ia64 has run afoul of the qsort checking
since the day qsort checking was introduced. I'l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88259
--- Comment #4 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #3)
> The vectorizer does not like
>
>[local count: 955630224]:
> # best_i_25 = PHI
> # best_26 = PHI
> # i_27 = PHI
> _1 = (long unsign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242
--- Comment #21 from Wilco ---
(In reply to Rainer Orth from comment #20)
> The new testcase also FAILs on sparc-sun-solaris2.11 (both 32 and 64-bit):
>
> +FAIL: gcc.c-torture/execute/pr64242.c -O2 execution test
> +FAIL: gcc.c-torture/execut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88408
Bug ID: 88408
Summary: [9 regression] r266868 breaks
gcc.target/powerpc/undef-bool-2.c on powerpc64 LE
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37637
Eric Gallager changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86669
Jakub Jelinek changed:
What|Removed |Added
Summary|[7/8/9 regression] Complete |[7/8 regression] Complete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861
--- Comment #7 from Jeffrey A. Law ---
I've still got my ia64 beaker box from yesterday provisioned. I'll spin your
patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87506
Jakub Jelinek changed:
What|Removed |Added
Summary|[7/8/9 Regression] ICE with |[7/8 Regression] ICE with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88367
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88377
--- Comment #3 from Jakub Jelinek ---
Fixed on GCC trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593
--- Comment #15 from Jakub Jelinek ---
ARM maintainers - feel free to add some ARM test for naked vs. IPA-RA too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86753
--- Comment #6 from Jeffrey A. Law ---
Sorry, my misunderstanding. I thought you had indicated the resulting code was
better.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86669
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 7 15:20:04 2018
New Revision: 266893
URL: https://gcc.gnu.org/viewcvs?rev=266893&root=gcc&view=rev
Log:
PR c++/86669
* call.c (make_temporary_var_for_ref_to_temp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88407
Thomas Schwinge changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88407
Bug ID: 88407
Summary: [OpenACC] Correctly handle unseen async-arguments
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: openacc, patch
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88214
--- Comment #7 from Martin Jambor ---
I have posted the patch to the mailing list for review:
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00460.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88406
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88406
Bug ID: 88406
Summary: [9 regression] Many 64-bit Solaris 10/SPARC execution
tests FAIL
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88405
Bug ID: 88405
Summary: Missed DSE opportunity
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88404
Bug ID: 88404
Summary: [9 Regression] ICE (tree check) with -fsanitize=thread
on Fortran2003 code
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615
--- Comment #12 from Martin Jambor ---
I have just posted the patch for review in:
https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00456.html
With it the compile time of the testcase goes down from approximately
340 seconds to about 160 seconds (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87551
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Jakub Jelinek ---
> So fixed with r265025 ? That commit should have referenced this PR...
Yes to both. I've now added the forgotten PR marker.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401
--- Comment #4 from Jakub Jelinek ---
That is not that easy, because what is considered invalid heavily depends on
the FE (and standard version), e.g. the above is completely valid in C++20.
Furthermore, warning too late in the middle-end could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Martin Liška ---
> Can the bug be marked as resolved?
No, the Solaris/x86 problem persists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401
Ulya changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401
--- Comment #2 from Ulya ---
(In reply to Jakub Jelinek from comment #1)
> It is a front-end warning, so there is no constant propagation possible.
> You can use -fsanitize=shift to detect this stuff at runtime.
Ok, understood. Maybe someday it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82890
Nick Clifton changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85122
Nick Clifton changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88403
Bug ID: 88403
Summary: [Mips,AArch64] The gcse prevents if-conversion
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
Bug 86656 depends on bug 85122, which changed state.
Bug 85122 Summary: Stack Overflow(Stack Exhaustion) in demangle related
functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85122
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37637
Matthias Klose changed:
What|Removed |Added
CC||doko at debian dot org
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335
Nick Clifton changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350
Nick Clifton changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
Bug ID: 88402
Summary: inefficient code generation for mask from CC
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87681
Nick Clifton changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87675
Nick Clifton changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87636
Nick Clifton changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87620
Nick Clifton changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86664
Nick Clifton changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85454
Nick Clifton changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
Bug 86656 depends on bug 85454, which changed state.
Bug 85454 Summary: Multiple memory corruptions in objdump / C++ name demangler
(binuitils-2.30-15ubuntu1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85454
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88401
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589
--- Comment #12 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #11)
> Unless the combiner grows the possibility to split into 3 functions, I'm
I mean 3 instructions when trying to combine 4.
> afraid this would need to be solved
1 - 100 of 139 matches
Mail list logo
