Re: [Sbcl-devel] [Sbcl-commits] master: x86-64, struct-by-value: correctly pass small structs on the stack

[Stas B. <sta...@gm...>]

Another issue, nested struts are not flattened correctly:
SB-VM> (classify-struct (parse-alien-type '(struct nil (inner (struct
nil (d double) (i int)))) nil))
#S(SB-ALIEN::STRUCT-CLASSIFICATION :REGISTER-SLOTS (:INTEGER :INTEGER)
:SIZE 16 :ALIGNMENT 64 :MEMORY-P NIL)
SB-VM> (classify-struct (parse-alien-type '(struct nil (d double) (i int)) nil))
#S(SB-ALIEN::STRUCT-CLASSIFICATION :REGISTER-SLOTS (:DOUBLE :INTEGER)
:SIZE 16 :ALIGNMENT 64 :MEMORY-P NIL)

And callbacks seem to suffer from over-reads/writes.

On Fri, Apr 24, 2026 at 12:40 AM Jesse Bouwman
<jes...@pr...> wrote:
>
> Stas, if you want to send me a list of findings and test gaps, I will put time into closing them out -- just raw notes or LLM findings are enough.
>
> Jesse
>
> > On Apr 23, 2026, at 2:25 PM, Stas Boukarev <sta...@gm...> wrote:
> >
> > The struct-by-value issues keep coming and coming, I'm already tired
> > of fixing them, have no strength to add proper tests.
> > And it also needs to test for over-reading input structures, I have
> > some scaffolding from the time of writing simd routines which mmaps
> > data at the edges of a protected region.
> >
> > On Thu, Apr 23, 2026 at 11:17 PM Christophe Rhodes <cs...@ca...> wrote:
> >>
> >> Stas Boukarev <sta...@gm...> writes:
> >>
> >>> I just send c-call.lisp to various free LLMs and say "find bugs here".
> >>> And also make them generate test cases.
> >>> I didn't include any specific test because they won't find new
> >>> problems.
> >>
> >> Sure, but they'll help the day someone wants to make struct-by-value
> >> work on platforms that don't support it yet.  (Maybe in this grand
> >> future that's less necessary because we'll just send riscv's c-call to
> >> some LLM and say "now implement the struct-by-value ABI please".)
> >>
> >>> A test that performs an exhaustive combination of different foreign
> >>> types is needed.
> >>> But I'm not eager to make that yet.
> >>
> >> ... that would work too, sure.  I can be patient.
> >>
> >> Thanks,
> >>
> >> Christophe
> >
> >
> > _______________________________________________
> > Sbcl-devel mailing list
> > Sbc...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbcl-devel
>
>