https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108086
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107991
--- Comment #5 from rsandifo at gcc dot gnu.org
---
>From a slightly old build, but it looks like we have a redundant move:
(insn 4 27 28 2 (set (reg/v:SI 85 [ i ])
(reg:SI 91)) "foo.c":9:31 83 {*movsi_internal}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107812
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-11-22
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96844
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108571
Bug ID: 108571
Summary: Fix for PR96373 regresses fabd_1.c with
-ftrapping-math
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #6 from rsandifo at gcc dot gnu.org
---
(In reply to Tamar Christina from comment #3)
> The vectorizer has this context but since we didn't want a new IFN the
> context should instead be derivable in
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108608
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #9 from rsandifo at gcc dot gnu.org
---
Are we sure this is a vectoriser vs. C vectors thing?
The equivalent vectoriser test:
void __attribute__((noipa))
f (unsigned *v)
{
for (int i = 0; i < 4; ++i)
v[i] /= 0x;
}
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #13 from rsandifo at gcc dot gnu.org
---
OK, hopefully I understand now. Sorry for being slow.
But what specific constraints do we want to apply to the optimisation?
(In reply to Tamar Christina from comment #3)
> Right, so this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108508
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108086
--- Comment #16 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #13)
> (In reply to Richard Biener from comment #12)
> > A regression from GCC 10 which compiles this in 90s at -O1.
> >
> > Richard? Can you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #10 from rsandifo at gcc dot gnu.org
---
(In reply to rguent...@suse.de from comment #9)
> Please you do it, as far as I understand Richard S. no further adjustment
> is necessary but we could simplify some code after the change(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #7)
> Whatever you do with cost heuristics you'll find a testcase where that
> regresses.
Yep. That's the one true invariant of costing :-)
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
--- Comment #3 from rsandifo at gcc dot gnu.org
---
(In reply to Tamar Christina from comment #2)
> I thought the SLP algorithm was bottom up and stores were
> already sinks?
Yeah, they are. But the point is that we're vectorising
the stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
--- Comment #5 from rsandifo at gcc dot gnu.org
---
Following an off-list discussion: maybe one option (for now) would
be to make the aarch64 builtins lowering code look for vld1s whose
arguments are ADDR_EXPRs of local VAR_DECLs (or maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Known to work|12.2.1 |
--- Comment #14 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108430
--- Comment #4 from rsandifo at gcc dot gnu.org
---
Fixed on trunk, but the underlying bug is present in GCC 12 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108979
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108979
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #19 from rsandifo at gcc dot gnu.org
---
I completely agree with comment 18. See:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601472.html
for some more on a similar theme.
make_compound_operation_int already has code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
--- Comment #2 from rsandifo at gcc dot gnu.org
---
The assert in question fires if the pass creates an instruction
whose pattern uses a register or memory and if the pass doesn't
provide associated use information. Let me know if it looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
--- Comment #10 from rsandifo at gcc dot gnu.org
---
Might be a daft question, but which cases besides
INTEGER_CST are supposed to be captured by the CONSTANT_CLASS_P?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
--- Comment #12 from rsandifo at gcc dot gnu.org
---
(In reply to Andrew Pinski from comment #11)
> For bit_and/bit_ior, VECTOR_CST (I would assume).
Ah, yeah. But then I don't think a top-level POLY_INT_CST_P
cuts it. We'd have the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505
--- Comment #15 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #13)
> (In reply to rsand...@gcc.gnu.org from comment #12)
> > (In reply to Andrew Pinski from comment #11)
> > > For bit_and/bit_ior, VECTOR_CST (I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109535
--- Comment #8 from rsandifo at gcc dot gnu.org
---
Can you quote a dump of the new insn pattern? Or just:
dump(change);
in function_info::finalize_new_accesses should do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #5 from rsandifo at gcc dot gnu.org
---
Created attachment 54941
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54941=edit
hacky proof-of-concept patch
This is a very hacky proof of concept patch. Don't try it on
anything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #7 from rsandifo at gcc dot gnu.org
---
Thinking more about it, it would probably be better to defer the
split until around lower_complex time, after IPA (especially inlining),
NRV and tail-recursion. Doing it there should also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109636
--- Comment #6 from rsandifo at gcc dot gnu.org
---
Ugh. I guess we've got no option but to force the original
subreg into a fresh register, but that's going to pessimise
cases where arithmetic is done on tuple types.
Perhaps we should just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #7)
> In patch form what I wrote above (completely untested):
Sorry in advance for the overly verbose comment, but the timeline here was
that:
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109661
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109661
--- Comment #4 from rsandifo at gcc dot gnu.org
---
Yeah, I'd come up with essentially the same fix locally. Was just trying
to see whether it is an ABI problem. And I think it is. For:
typedef unsigned long U __attribute__ ((aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109661
--- Comment #6 from rsandifo at gcc dot gnu.org
---
I'm working on a patch (though not literally right now).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #10 from rsandifo at gcc dot gnu.org
---
After prototyping this further, I no longer think that lowering
at the gimple level is the best answer. (I should have listened
to Richi.) Although it works, its major drawback is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510
--- Comment #12 from rsandifo at gcc dot gnu.org
---
(In reply to Eric Botcazou from comment #10)
> Created attachment 54859 [details]
> Tentative fix
>
> To be tested.
Thanks! This works for me locally and gives clean Ada test results.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108508
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[12 Regression] ICE in |[11 Backport] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108430
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108608
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108603
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109436
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[12/13 Regression] SLP |[12 Regression] SLP costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109498
Bug ID: 109498
Summary: SVE support for ctz
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499
--- Comment #4 from rsandifo at gcc dot gnu.org
---
(In reply to rguent...@suse.de from comment #3)
> AVX512 masking allows merge and zero modes, zero being cheaper
> (obviously). I think "zero" is what all targets support so we could
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[12/13 Regression] Further |[12 Regression] Further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109269
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499
Bug ID: 109499
Summary: Unnecessary zeroing in SVE loops
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499
--- Comment #2 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #1)
> Is there not enough info to catch this on the RTL level with a peephole?
That works for simple cases like the first loop. But in general, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108316
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105383
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108603
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-02-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108430
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108750
Bug ID: 108750
Summary: Loop unswitching fails for poly_int conditions
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108748
Bug ID: 108748
Summary: Enhancement: track ranges of poly_int indeterminates
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #3 from rsandifo at gcc dot gnu.org
---
The explanation is in the SET_TYPE_VECTOR_SUBPARTS code:
/* We have two coefficients that are each in the range 1 << [0, 63],
so supporting all combinations would require 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108748
--- Comment #2 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #1)
> That said, we'd track a "virtual" variables range here. For the above
> I wonder why we cannot constant fold it - [16, 16] can never be 2, no?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
--- Comment #5 from rsandifo at gcc dot gnu.org
---
ivopts does have code to treat ifn pointer arguments specially,
see get_mem_type_for_internal_fn But like Kewen says,
it's still only based on the mode.
Personally I'd prefer an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150
--- Comment #32 from rsandifo at gcc dot gnu.org
---
(In reply to Xi Ruoyao from comment #31)
> Richard: is it allowed to backport them (or the entire
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613093.html series) for
> gcc-12?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110485
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110495
--- Comment #2 from rsandifo at gcc dot gnu.org
---
The point of the builder is that, if you know the pattern,
you don't need to supply every element value to the builder.
(And indeed you can't when the vector is variable length.)
So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625
--- Comment #7 from rsandifo at gcc dot gnu.org
---
The current issue rate framework was originally written for Neoverse V1 and
Neoverse V2. For those cores, it wasn't necessary to make a distinction
between scalar integer operations and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110039
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109940
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109964
--- Comment #4 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #3)
> So the bug in the vectorizer is that it does
>
> t.ii:14:5: note: can narrow to signed:16 without loss of precision: _31 =
> 1 >> _30;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109940
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109632
--- Comment #12 from rsandifo at gcc dot gnu.org
---
The patch in comment 11 is just a related spot improvement.
The PR itself is still unfixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110105
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Looking at the mddump file, the output predicate and constraint
seem to have gone AWOL:
;; /home/ricsan01/gnu/src/gcc/gcc/config/aarch64/aarch64-simd.md: 1554
(define_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109855
--- Comment #4 from rsandifo at gcc dot gnu.org
---
I guess the problem is that the define_subst output template has:
(match_operand: 0)
which creates a new operand 0 with an empty predicate and constraint,
as opposed to a (match_dup 0),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #20 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #19)
> Sure, I can kind of see the usefulness elsewhere. Just for this particular
> issue it doesn't seem necessary to sit down and design this when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #18 from rsandifo at gcc dot gnu.org
---
I'd understood LLVM's undef as essentially being “unspecified”, or “unspecified
bit-pattern” to quote the docs. It doesn't indicate undefined behaviour in the
C/C++ sense:
Undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106081
--- Comment #14 from rsandifo at gcc dot gnu.org
---
FWIW, changing:
if (!STMT_VINFO_GROUPED_ACCESS (dr_stmt))
continue;
to:
if (!STMT_VINFO_GROUPED_ACCESS (dr_stmt))
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106081
--- Comment #13 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #12)
> Btw, I see we actually materialize a permute before the splat:
>
> t.c:14:24: note: node 0x5b311c0 (max_nunits=1, refcnt=2) vector(2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106081
--- Comment #10 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #9)
> So I can adjust change_layout_cost in a bit awkward way, but it seems that
> internal_node_cost would already work out that a permute can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625
--- Comment #10 from rsandifo at gcc dot gnu.org
---
Created attachment 55654
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55654=edit
Candidate patch (part 2)
Sorry for the delay. I'm testing the attached two patches to fix the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625
--- Comment #9 from rsandifo at gcc dot gnu.org
---
Created attachment 55653
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55653=edit
Candidate patch (part 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110780
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #12 from rsandifo at gcc dot gnu.org
---
(In reply to JuzheZhong from comment #11)
> You can see "_9 = _5 >> _8;". We should vectorize SImode instead of HImode.
> The correct follow should be first extend HI -> SImode, Then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #10 from rsandifo at gcc dot gnu.org
---
(In reply to JuzheZhong from comment #9)
> I seems that we must support widen shift pattern in RISCV port even though
> we don't have widen shift instructions ?
I doubt it. Seems like one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110449
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenth at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106081
--- Comment #7 from rsandifo at gcc dot gnu.org
---
I don't think the splat creates a new layout, but instead a
splat should be allowed to change its layout at zero cost.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109661
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[13/14 Regression] ICE in |[13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109929
--- Comment #7 from Richard Sandiford ---
Hmm, yeah, like you say, neither of those commits should have made a different
to whether bootstrap works. I guess the problem is just latent now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113485
Richard Sandiford changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113572
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #11 from Richard Sandiford ---
Currently away so can't try it myself, but how about just using an ad-hoc
structure instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #14 from Richard Sandiford ---
AFAIK, the constructor shouldn't be necessary. (And without it, the whole
thing would fit on one line.) LGTM (and preapproved) otherwise. Thanks for
doing this.
401 - 500 of 633 matches
Mail list logo
