[musl] [PATCH] loongarch64: Add lsx and lasx regset definition

[musl] [PATCH] loongarch64: Add lsx and lasx regset definition

[Xing Li]

Fix the upstream binutils-gdb building error caused by
the lack of lsx and lasx regset definition.
---
 arch/loongarch64/bits/user.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/loongarch64/bits/user.h b/arch/loongarch64/bits/user.h
index fd9b7b22..10e1be45 100644
--- a/arch/loongarch64/bits/user.h
+++ b/arch/loongarch64/bits/user.h
@@ -22,3 +22,15 @@ typedef union {
 	float f;
 } elf_fpreg_t;
 typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
+
+typedef union
+{
+	double d[2];
+	float f[4];
+} elf_lsxregset_t[32] __attribute__((__aligned__(16)));
+
+typedef union
+{
+	double d[4];
+	float f[8];
+} elf_lasxregset_t[32] __attribute__((__aligned__(32)));
-- 
2.27.0

[musl] [PATCH] loongarch64: Add lsx and lasx regset definition

[Xing Li]

Fix the upstream binutils-gdb building error caused by
the lack of lsx and lasx regset definition.
---
 arch/loongarch64/bits/user.h | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/loongarch64/bits/user.h b/arch/loongarch64/bits/user.h
index fd9b7b22..10e1be45 100644
--- a/arch/loongarch64/bits/user.h
+++ b/arch/loongarch64/bits/user.h
@@ -22,3 +22,15 @@ typedef union {
 	float f;
 } elf_fpreg_t;
 typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
+
+typedef union
+{
+	double d[2];
+	float f[4];
+} elf_lsxregset_t[32] __attribute__((__aligned__(16)));
+
+typedef union
+{
+	double d[4];
+	float f[8];
+} elf_lasxregset_t[32] __attribute__((__aligned__(32)));
-- 
2.27.0

Re: [musl] [PATCH] loongarch64: Add lsx and lasx regset definition

[Rich Felker]

On Tue, Sep 10, 2024 at 09:17:57AM +0800, Xing Li wrote:
> Fix the upstream binutils-gdb building error caused by
> the lack of lsx and lasx regset definition.
> ---
>  arch/loongarch64/bits/user.h | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/loongarch64/bits/user.h b/arch/loongarch64/bits/user.h
> index fd9b7b22..10e1be45 100644
> --- a/arch/loongarch64/bits/user.h
> +++ b/arch/loongarch64/bits/user.h
> @@ -22,3 +22,15 @@ typedef union {
>  	float f;
>  } elf_fpreg_t;
>  typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
> +
> +typedef union
> +{
> +	double d[2];
> +	float f[4];
> +} elf_lsxregset_t[32] __attribute__((__aligned__(16)));
> +
> +typedef union
> +{
> +	double d[4];
> +	float f[8];
> +} elf_lasxregset_t[32] __attribute__((__aligned__(32)));
> -- 
> 2.27.0

I don't like having the alignment directive bound to the whole type
like this where it's depending on weird GNUC-isms that can't be
represented in standard C alignas, but I think it's ok for now and we
can find a better way to express it later if needed. I know this is
another patch that distros have been carrying for a long time so I'd
like to merge it for release.

Rich

Re: [musl] [PATCH] loongarch64: Add lsx and lasx regset definition

[lixing]

在 2026/3/11 下午12:07, Rich Felker 写道:
> On Tue, Sep 10, 2024 at 09:17:57AM +0800, Xing Li wrote:
>> Fix the upstream binutils-gdb building error caused by
>> the lack of lsx and lasx regset definition.
>> ---
>>   arch/loongarch64/bits/user.h | 12 ++++++++++++
>>   1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/loongarch64/bits/user.h b/arch/loongarch64/bits/user.h
>> index fd9b7b22..10e1be45 100644
>> --- a/arch/loongarch64/bits/user.h
>> +++ b/arch/loongarch64/bits/user.h
>> @@ -22,3 +22,15 @@ typedef union {
>>   	float f;
>>   } elf_fpreg_t;
>>   typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
>> +
>> +typedef union
>> +{
>> +	double d[2];
>> +	float f[4];
>> +} elf_lsxregset_t[32] __attribute__((__aligned__(16)));
>> +
>> +typedef union
>> +{
>> +	double d[4];
>> +	float f[8];
>> +} elf_lasxregset_t[32] __attribute__((__aligned__(32)));
>> -- 
>> 2.27.0
> I don't like having the alignment directive bound to the whole type
> like this where it's depending on weird GNUC-isms that can't be
> represented in standard C alignas, but I think it's ok for now and we
> can find a better way to express it later if needed. I know this is
> another patch that distros have been carrying for a long time so I'd
> like to merge it for release.
thanks.
> Rich

Re: [musl] [PATCH] loongarch64: Add lsx and lasx regset definition

[James Y Knight]

On Wed, Mar 11, 2026 at 12:07 AM Rich Felker <dalias@libc.org> wrote:
>
> On Tue, Sep 10, 2024 at 09:17:57AM +0800, Xing Li wrote:
> > Fix the upstream binutils-gdb building error caused by
> > the lack of lsx and lasx regset definition.
> > ---
> >  arch/loongarch64/bits/user.h | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/arch/loongarch64/bits/user.h b/arch/loongarch64/bits/user.h
> > index fd9b7b22..10e1be45 100644
> > --- a/arch/loongarch64/bits/user.h
> > +++ b/arch/loongarch64/bits/user.h
> > @@ -22,3 +22,15 @@ typedef union {
> >       float f;
> >  } elf_fpreg_t;
> >  typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
> > +
> > +typedef union
> > +{
> > +     double d[2];
> > +     float f[4];
> > +} elf_lsxregset_t[32] __attribute__((__aligned__(16)));
> > +
> > +typedef union
> > +{
> > +     double d[4];
> > +     float f[8];
> > +} elf_lasxregset_t[32] __attribute__((__aligned__(32)));
> > --
> > 2.27.0
>
> I don't like having the alignment directive bound to the whole type
> like this where it's depending on weird GNUC-isms that can't be
> represented in standard C alignas, but I think it's ok for now and we
> can find a better way to express it later if needed. I know this is
> another patch that distros have been carrying for a long time so I'd
> like to merge it for release.


That code looks weird. Why does it apply the alignment attribute on
the _array_ type, rather than the union type? E.g. why is this not
just:

typedef union
{
     double d[2];
     float f[4];
} __attribute__((__aligned__(16))) elf_lsxregset_t[32];

And once you have that, it's easy to take it one step further and move
the alignment onto the union field, at which point you can have
standard C code:

typedef union
{
     _Alignas(16) double d[2];
     _Alignas(16) float f[4];
} elf_lsxregset_t[32];

Re: [musl] [PATCH] loongarch64: Add lsx and lasx regset definition

[Rich Felker]

On Wed, Mar 11, 2026 at 10:49:15AM -0400, James Y Knight wrote:
> On Wed, Mar 11, 2026 at 12:07 AM Rich Felker <dalias@libc.org> wrote:
> >
> > On Tue, Sep 10, 2024 at 09:17:57AM +0800, Xing Li wrote:
> > > Fix the upstream binutils-gdb building error caused by
> > > the lack of lsx and lasx regset definition.
> > > ---
> > >  arch/loongarch64/bits/user.h | 12 ++++++++++++
> > >  1 file changed, 12 insertions(+)
> > >
> > > diff --git a/arch/loongarch64/bits/user.h b/arch/loongarch64/bits/user.h
> > > index fd9b7b22..10e1be45 100644
> > > --- a/arch/loongarch64/bits/user.h
> > > +++ b/arch/loongarch64/bits/user.h
> > > @@ -22,3 +22,15 @@ typedef union {
> > >       float f;
> > >  } elf_fpreg_t;
> > >  typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
> > > +
> > > +typedef union
> > > +{
> > > +     double d[2];
> > > +     float f[4];
> > > +} elf_lsxregset_t[32] __attribute__((__aligned__(16)));
> > > +
> > > +typedef union
> > > +{
> > > +     double d[4];
> > > +     float f[8];
> > > +} elf_lasxregset_t[32] __attribute__((__aligned__(32)));
> > > --
> > > 2.27.0
> >
> > I don't like having the alignment directive bound to the whole type
> > like this where it's depending on weird GNUC-isms that can't be
> > represented in standard C alignas, but I think it's ok for now and we
> > can find a better way to express it later if needed. I know this is
> > another patch that distros have been carrying for a long time so I'd
> > like to merge it for release.
> 
> 
> That code looks weird. Why does it apply the alignment attribute on
> the _array_ type, rather than the union type? E.g. why is this not
> just:
> 
> typedef union
> {
>      double d[2];
>      float f[4];
> } __attribute__((__aligned__(16))) elf_lsxregset_t[32];

I'm not sure how GNU C __attribute__((__aligned__(...))) even binds,
which is part of why I don't like it and prefer the clearer ISO C
form. But..

> And once you have that, it's easy to take it one step further and move
> the alignment onto the union field, at which point you can have
> standard C code:
> 
> typedef union
> {
>      _Alignas(16) double d[2];
>      _Alignas(16) float f[4];
> } elf_lsxregset_t[32];

Does that work? Or would that be trying to apply the alignment to
double where the alignment is larger than the type and thereby
invalid? This is totally on me, but I don't understand well how the
binding works.

Rich

Re: [musl] [PATCH] loongarch64: Add lsx and lasx regset definition

[lixing]

在 2026/3/12 上午12:24, Rich Felker 写道:
> On Wed, Mar 11, 2026 at 10:49:15AM -0400, James Y Knight wrote:
>> On Wed, Mar 11, 2026 at 12:07 AM Rich Felker <dalias@libc.org> wrote:
>>> On Tue, Sep 10, 2024 at 09:17:57AM +0800, Xing Li wrote:
>>>> Fix the upstream binutils-gdb building error caused by
>>>> the lack of lsx and lasx regset definition.
>>>> ---
>>>>   arch/loongarch64/bits/user.h | 12 ++++++++++++
>>>>   1 file changed, 12 insertions(+)
>>>>
>>>> diff --git a/arch/loongarch64/bits/user.h b/arch/loongarch64/bits/user.h
>>>> index fd9b7b22..10e1be45 100644
>>>> --- a/arch/loongarch64/bits/user.h
>>>> +++ b/arch/loongarch64/bits/user.h
>>>> @@ -22,3 +22,15 @@ typedef union {
>>>>        float f;
>>>>   } elf_fpreg_t;
>>>>   typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
>>>> +
>>>> +typedef union
>>>> +{
>>>> +     double d[2];
>>>> +     float f[4];
>>>> +} elf_lsxregset_t[32] __attribute__((__aligned__(16)));
>>>> +
>>>> +typedef union
>>>> +{
>>>> +     double d[4];
>>>> +     float f[8];
>>>> +} elf_lasxregset_t[32] __attribute__((__aligned__(32)));
>>>> --
>>>> 2.27.0
>>> I don't like having the alignment directive bound to the whole type
>>> like this where it's depending on weird GNUC-isms that can't be
>>> represented in standard C alignas, but I think it's ok for now and we
>>> can find a better way to express it later if needed. I know this is
>>> another patch that distros have been carrying for a long time so I'd
>>> like to merge it for release.
>>
>> That code looks weird. Why does it apply the alignment attribute on
>> the _array_ type, rather than the union type? E.g. why is this not
>> just:
>>
>> typedef union
>> {
>>       double d[2];
>>       float f[4];
>> } __attribute__((__aligned__(16))) elf_lsxregset_t[32];
> I'm not sure how GNU C __attribute__((__aligned__(...))) even binds,
> which is part of why I don't like it and prefer the clearer ISO C
> form. But..
>
>> And once you have that, it's easy to take it one step further and move
>> the alignment onto the union field, at which point you can have
>> standard C code:
>>
>> typedef union
>> {
>>       _Alignas(16) double d[2];
>>       _Alignas(16) float f[4];
>> } elf_lsxregset_t[32];
> Does that work? Or would that be trying to apply the alignment to
> double where the alignment is larger than the type and thereby
> invalid? This is totally on me, but I don't understand well how the
> binding works.

I've made a simple test on my 3A5000 platform,  The modification seems work

with this situation, each lsxregset and lasxregset array member aligned 
to16/32.


thanks.

> Rich

Re: [musl] [PATCH] loongarch64: Add lsx and lasx regset definition

[James Y Knight]

On Wed, Mar 11, 2026 at 12:24 PM Rich Felker <dalias@libc.org> wrote:
> I'm not sure how GNU C __attribute__((__aligned__(...))) even binds,
> which is part of why I don't like it and prefer the clearer ISO C
> form.

The rules for where GNU C attributes are indeed somewhat tricky. But
in this case: the original was applied to the typedef (the entity
immediately to the left), and in my first suggestion, it applied to
the union type (again, the entity immediately to the left).

> > typedef union
> > {
> >      _Alignas(16) double d[2];
> >      _Alignas(16) float f[4];
> > } elf_lsxregset_t[32];
>
> Does that work? Or would that be trying to apply the alignment to
> double where the alignment is larger than the type and thereby
> invalid? This is totally on me, but I don't understand well how the
> binding works.

Yep, it works. And the standard rules are quite simple: in C, alignas
may _only_ be applied to structure fields or local/global variables --
not to types (or parts of types), at all. In C++, it may also be
applied to an entire struct/class/union, so, e.g. `struct alignas(64)
Foo { int x; };` is valid only in C++. Neither standard permits it to
be applied to a typedef, or other such "interesting" usage.

Re: [musl] [PATCH] loongarch64: Add lsx and lasx regset definition

[Rich Felker]

On Thu, Mar 12, 2026 at 03:09:59PM -0400, James Y Knight wrote:
> On Wed, Mar 11, 2026 at 12:24 PM Rich Felker <dalias@libc.org> wrote:
> > I'm not sure how GNU C __attribute__((__aligned__(...))) even binds,
> > which is part of why I don't like it and prefer the clearer ISO C
> > form.
> 
> The rules for where GNU C attributes are indeed somewhat tricky. But
> in this case: the original was applied to the typedef (the entity
> immediately to the left), and in my first suggestion, it applied to
> the union type (again, the entity immediately to the left).
> 
> > > typedef union
> > > {
> > >      _Alignas(16) double d[2];
> > >      _Alignas(16) float f[4];
> > > } elf_lsxregset_t[32];
> >
> > Does that work? Or would that be trying to apply the alignment to
> > double where the alignment is larger than the type and thereby
> > invalid? This is totally on me, but I don't understand well how the
> > binding works.
> 
> Yep, it works. And the standard rules are quite simple: in C, alignas
> may _only_ be applied to structure fields or local/global variables --
> not to types (or parts of types), at all. In C++, it may also be
> applied to an entire struct/class/union, so, e.g. `struct alignas(64)
> Foo { int x; };` is valid only in C++. Neither standard permits it to
> be applied to a typedef, or other such "interesting" usage.

OK, sounds good. However, I think I'll just take the patch as-is for
now. Using _Alignas would require some refactoring work to make it
available in pre-C11 context via features.h or whatever rather than
depending on stdalign.h which we can't include here. And that in turn
would require consideration of whether there are any bad consequences
of mismatched semantics between _Alignas and the GNUC stuff.

Hopefully we can clean this up sometime after release.

Rich

Re: [musl] [PATCH] loongarch64: Add lsx and lasx regset definition

[Rich Felker]

On Thu, Mar 12, 2026 at 08:35:43PM -0400, Rich Felker wrote:
> On Thu, Mar 12, 2026 at 03:09:59PM -0400, James Y Knight wrote:
> > On Wed, Mar 11, 2026 at 12:24 PM Rich Felker <dalias@libc.org> wrote:
> > > I'm not sure how GNU C __attribute__((__aligned__(...))) even binds,
> > > which is part of why I don't like it and prefer the clearer ISO C
> > > form.
> > 
> > The rules for where GNU C attributes are indeed somewhat tricky. But
> > in this case: the original was applied to the typedef (the entity
> > immediately to the left), and in my first suggestion, it applied to
> > the union type (again, the entity immediately to the left).
> > 
> > > > typedef union
> > > > {
> > > >      _Alignas(16) double d[2];
> > > >      _Alignas(16) float f[4];
> > > > } elf_lsxregset_t[32];
> > >
> > > Does that work? Or would that be trying to apply the alignment to
> > > double where the alignment is larger than the type and thereby
> > > invalid? This is totally on me, but I don't understand well how the
> > > binding works.
> > 
> > Yep, it works. And the standard rules are quite simple: in C, alignas
> > may _only_ be applied to structure fields or local/global variables --
> > not to types (or parts of types), at all. In C++, it may also be
> > applied to an entire struct/class/union, so, e.g. `struct alignas(64)
> > Foo { int x; };` is valid only in C++. Neither standard permits it to
> > be applied to a typedef, or other such "interesting" usage.
> 
> OK, sounds good. However, I think I'll just take the patch as-is for
> now. Using _Alignas would require some refactoring work to make it
> available in pre-C11 context via features.h or whatever rather than
> depending on stdalign.h which we can't include here. And that in turn
> would require consideration of whether there are any bad consequences
> of mismatched semantics between _Alignas and the GNUC stuff.
> 
> Hopefully we can clean this up sometime after release.

Hmm, maybe we could just go ahead and put the
__attribute__((__aligned__(...))) inside the struct now tho? That
would at least avoid the dependency on it applying to the typedef in a
confusing way that mismatches the C behavior.

Rich

Re: [musl] [PATCH] loongarch64: Add lsx and lasx regset definition

[Rich Felker]

[-- Attachment #1: Type: text/plain, Size: 2540 bytes --]

On Thu, Mar 12, 2026 at 08:37:05PM -0400, Rich Felker wrote:
> On Thu, Mar 12, 2026 at 08:35:43PM -0400, Rich Felker wrote:
> > On Thu, Mar 12, 2026 at 03:09:59PM -0400, James Y Knight wrote:
> > > On Wed, Mar 11, 2026 at 12:24 PM Rich Felker <dalias@libc.org> wrote:
> > > > I'm not sure how GNU C __attribute__((__aligned__(...))) even binds,
> > > > which is part of why I don't like it and prefer the clearer ISO C
> > > > form.
> > > 
> > > The rules for where GNU C attributes are indeed somewhat tricky. But
> > > in this case: the original was applied to the typedef (the entity
> > > immediately to the left), and in my first suggestion, it applied to
> > > the union type (again, the entity immediately to the left).
> > > 
> > > > > typedef union
> > > > > {
> > > > >      _Alignas(16) double d[2];
> > > > >      _Alignas(16) float f[4];
> > > > > } elf_lsxregset_t[32];
> > > >
> > > > Does that work? Or would that be trying to apply the alignment to
> > > > double where the alignment is larger than the type and thereby
> > > > invalid? This is totally on me, but I don't understand well how the
> > > > binding works.
> > > 
> > > Yep, it works. And the standard rules are quite simple: in C, alignas
> > > may _only_ be applied to structure fields or local/global variables --
> > > not to types (or parts of types), at all. In C++, it may also be
> > > applied to an entire struct/class/union, so, e.g. `struct alignas(64)
> > > Foo { int x; };` is valid only in C++. Neither standard permits it to
> > > be applied to a typedef, or other such "interesting" usage.
> > 
> > OK, sounds good. However, I think I'll just take the patch as-is for
> > now. Using _Alignas would require some refactoring work to make it
> > available in pre-C11 context via features.h or whatever rather than
> > depending on stdalign.h which we can't include here. And that in turn
> > would require consideration of whether there are any bad consequences
> > of mismatched semantics between _Alignas and the GNUC stuff.
> > 
> > Hopefully we can clean this up sometime after release.
> 
> Hmm, maybe we could just go ahead and put the
> __attribute__((__aligned__(...))) inside the struct now tho? That
> would at least avoid the dependency on it applying to the typedef in a
> confusing way that mismatches the C behavior.

Is this ok?

BTW, I was thinking this was in signal.h, where this stuff would
matter more. user.h is pretty much only for gdb and similar, so it's
probably not worth spending much effort on making it "nice".

Rich

[-- Attachment #2: 0001-loongarch64-add-lsx-and-lasx-regset-definition.patch --]
[-- Type: text/plain, Size: 814 bytes --]

From 9355c443116969d93c920b57b3f8f3252a912ca5 Mon Sep 17 00:00:00 2001
From: Xing Li <lixing@loongson.cn>
Date: Tue, 10 Sep 2024 09:17:57 +0800
Subject: [PATCH] loongarch64: add lsx and lasx regset definition

---
 arch/loongarch64/bits/user.h | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/loongarch64/bits/user.h b/arch/loongarch64/bits/user.h
index fd9b7b22..e4aee0d3 100644
--- a/arch/loongarch64/bits/user.h
+++ b/arch/loongarch64/bits/user.h
@@ -22,3 +22,17 @@ typedef union {
 	float f;
 } elf_fpreg_t;
 typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
+
+typedef union
+{
+	__attribute__((__aligned__(16)))
+	double d[2];
+	float f[4];
+} elf_lsxregset_t[32];
+
+typedef union
+{
+	__attribute__((__aligned__(32)))
+	double d[4];
+	float f[8];
+} elf_lasxregset_t[32];
-- 
2.21.0

Re: [musl] [PATCH] loongarch64: Add lsx and lasx regset definition

[lixing]

在 2026/3/13 上午9:24, Rich Felker 写道:
> On Thu, Mar 12, 2026 at 08:37:05PM -0400, Rich Felker wrote:
>> On Thu, Mar 12, 2026 at 08:35:43PM -0400, Rich Felker wrote:
>>> On Thu, Mar 12, 2026 at 03:09:59PM -0400, James Y Knight wrote:
>>>> On Wed, Mar 11, 2026 at 12:24 PM Rich Felker <dalias@libc.org> wrote:
>>>>> I'm not sure how GNU C __attribute__((__aligned__(...))) even binds,
>>>>> which is part of why I don't like it and prefer the clearer ISO C
>>>>> form.
>>>> The rules for where GNU C attributes are indeed somewhat tricky. But
>>>> in this case: the original was applied to the typedef (the entity
>>>> immediately to the left), and in my first suggestion, it applied to
>>>> the union type (again, the entity immediately to the left).
>>>>
>>>>>> typedef union
>>>>>> {
>>>>>>       _Alignas(16) double d[2];
>>>>>>       _Alignas(16) float f[4];
>>>>>> } elf_lsxregset_t[32];
>>>>> Does that work? Or would that be trying to apply the alignment to
>>>>> double where the alignment is larger than the type and thereby
>>>>> invalid? This is totally on me, but I don't understand well how the
>>>>> binding works.
>>>> Yep, it works. And the standard rules are quite simple: in C, alignas
>>>> may _only_ be applied to structure fields or local/global variables --
>>>> not to types (or parts of types), at all. In C++, it may also be
>>>> applied to an entire struct/class/union, so, e.g. `struct alignas(64)
>>>> Foo { int x; };` is valid only in C++. Neither standard permits it to
>>>> be applied to a typedef, or other such "interesting" usage.
>>> OK, sounds good. However, I think I'll just take the patch as-is for
>>> now. Using _Alignas would require some refactoring work to make it
>>> available in pre-C11 context via features.h or whatever rather than
>>> depending on stdalign.h which we can't include here. And that in turn
>>> would require consideration of whether there are any bad consequences
>>> of mismatched semantics between _Alignas and the GNUC stuff.
>>>
>>> Hopefully we can clean this up sometime after release.
>> Hmm, maybe we could just go ahead and put the
>> __attribute__((__aligned__(...))) inside the struct now tho? That
>> would at least avoid the dependency on it applying to the typedef in a
>> confusing way that mismatches the C behavior.
> Is this ok?
>
> BTW, I was thinking this was in signal.h, where this stuff would
> matter more. user.h is pretty much only for gdb and similar, so it's
> probably not worth spending much effort on making it "nice".
>
> Rich


Thanks, that's ok.