* when (not) use bugzilla for GCC?
@ 2009-10-25 18:48 Basile STARYNKEVITCH
2009-10-26 7:11 ` Joseph S. Myers
0 siblings, 1 reply; 10+ messages in thread
From: Basile STARYNKEVITCH @ 2009-10-25 18:48 UTC (permalink / raw)
To: GCC Mailing List
Hello All,
Please accept my apologies if the questions below are too naive!
I have several questions about bugzilla and GCC. I am not very familiar
with bugzilla, and I am not familiar with the configuration of GCC
bugzilla in particular.
I cannot understand when should I use or not bugzilla. More precisely, I
have several examples of "bugs" but I didn't use bugzilla for them
1. I regularily test the latest gcc trunk with -flto on a medium sized
program. And it always crashes, with a sisegv fatal error. My feeling is
that it should not crash that way (at least, I would prefer a message
such as not enough memory to compile with -flto). Should I report that
as a bug on bugzilla? I am not able at all to reduce that example to
something smaller.
For the record, that program is Jacques Pitrat's MALICE system
http://pagesperso-orange.fr/jacques.pitrat/MALICE.html
about 370KLOC (less than 14Mbytes total) of C files (all 2947 C files
are generated and usually short, MALICE is bootstrapped that is
generates all its C code; the C code is not understandable!). I would
imagine that it is not big enough to reach the limits of my 8Gb desktop!
Should I report that as a bug?
2. a couple of weeks ago, I submitted a patch regarding gengtype for
plugins (the patch was greatly improved by Rafael Espindola
espindola@google.com) and the patch did correct a bug.
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00379.html
but I never bothered registering it (since making the initial patch was
easier than reporting a bug). This is also the case of
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00809.html
(fatal error when failing to register a pass)
3. On the MELT branch, I regularily find bugs & correct them, and it did
happen that someone registered a MELT bug on the bugzilla; I did correct
it but AFAIR was not permitted to close the bug. Sometimes I am sad of
not being able to report MELT bugs on bugzilla and to close them when I
feel I have covered them.
My current intuition is that bugzilla might be reserved for bugs of the
trunk mostly for which a small testcase is available, and which is a
bug affecting many users (this is not the case of all the bugs
mentionned above).
So when should I use bugzilla? I am a bit "scared" to use it!
I hope I am not offending anyone, and I admit that I am not familiar
with bugzilla in general and its GCC policy & setting in particular.
I also am guessing that bugzilla is less important for the GCC community
than in some other big free software communities. It does not seem to be
a major communication channel.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: when (not) use bugzilla for GCC?
2009-10-25 18:48 when (not) use bugzilla for GCC? Basile STARYNKEVITCH
@ 2009-10-26 7:11 ` Joseph S. Myers
2009-10-26 11:57 ` Basile STARYNKEVITCH
0 siblings, 1 reply; 10+ messages in thread
From: Joseph S. Myers @ 2009-10-26 7:11 UTC (permalink / raw)
To: Basile STARYNKEVITCH; +Cc: GCC Mailing List
On Sun, 25 Oct 2009, Basile STARYNKEVITCH wrote:
> I cannot understand when should I use or not bugzilla. More precisely, I have
> several examples of "bugs" but I didn't use bugzilla for them
If something is a bug in trunk then you should report it, but do not
submit reports that do not contain sufficient information to convince the
reader that there is a bug. For example, a report should not rely on
source files on a third-party website, installed system headers, or on the
hypothetical correctness of some unreduced code (if you are claiming wrong
code, reduce it to a single function or a minimal set of functions).
For development branches, it's up to the branch maintainer. If they wish
to use Bugzilla for bugs in them, they should add appropriate versions so
the bugs can be accurately reported as bugs against the branch.
> 2. a couple of weeks ago, I submitted a patch regarding gengtype for plugins
> (the patch was greatly improved by Rafael Espindola espindola@google.com) and
> the patch did correct a bug.
> http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00379.html
> but I never bothered registering it (since making the initial patch was easier
> than reporting a bug). This is also the case of
> http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00809.html
> (fatal error when failing to register a pass)
If you want a regression to be tracked as such, it needs a Bugzilla entry,
even if there is also a patch submission. Any bug with a patch can be
filed if desired, but do not use Bugzilla as a patch submission mechanism;
send patches to gcc-patches and use the "patch URL" field in the bugs.
Ping patches on gcc-patches weekly until they are reviewed. If you attach
a patch in progress to Bugzilla, make clear that it is a work in progress
and that a final version will be submitted to gcc-patches.
If you stop working on a bug, do not leave yourself assigned to it;
ASSIGNED should only be for bugs where you are genuinely working on them.
> 3. On the MELT branch, I regularily find bugs & correct them, and it did
> happen that someone registered a MELT bug on the bugzilla; I did correct it
> but AFAIR was not permitted to close the bug. Sometimes I am sad of not being
> able to report MELT bugs on bugzilla and to close them when I feel I have
> covered them.
Log in to Bugzilla with your gcc.gnu.org address to get access to close
bugs, add versions and milestones, etc.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: when (not) use bugzilla for GCC?
2009-10-26 7:11 ` Joseph S. Myers
@ 2009-10-26 11:57 ` Basile STARYNKEVITCH
2009-10-26 14:39 ` Ian Lance Taylor
0 siblings, 1 reply; 10+ messages in thread
From: Basile STARYNKEVITCH @ 2009-10-26 11:57 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: GCC Mailing List
Joseph S. Myers wrote:
> On Sun, 25 Oct 2009, Basile STARYNKEVITCH wrote:
>
>> I cannot understand when should I use or not bugzilla. More precisely, I have
>> several examples of "bugs" but I didn't use bugzilla for them
A big thanks to your reply. However, you did not answer to my example 1.
J.Pitrat's MALICE system on
http://pagesperso-orange.fr/jacques.pitrat/MALICE.html
The point is that I cannot reduce that example, because it is almost
3000 usually small files of generated C (totalizing 370865 lines or
13862311 bytes) like eg its TRIPLETS2.c file which contains
#include "dx.h"
void TRIPLETS2(void )
/*generated C source file TRIPLETS2.c of the CAIA system - Copyright
Jacques Pitrat 2009 - GPLv3 license. See COPYING3*/
{int N;
int NNNE;
int WZ1,WZ2,WZ3,WZ4,WZ5;
int jvj;
jvj=v[0];
v[0]+=11;
x[jvj+1]=26199;z[jvj+1]=(-100);
if(v[0]>99700) (*f[6])();
if(v[90]==2441&&v[97]==0) {
(*f[4])();x[jvj+1]=incon;v[0]=jvj;return;
}
N=pile[v[22]];NNNE=pile[v[22]+1];v[22]+=2;
WZ5=v[22]+5;WZ4=v[22]+4;WZ3=v[22]+3;WZ2=v[22]+2;WZ1=v[22]+1;
x[jvj+2]=0;z[jvj+2]=0;
pile[v[22]]=100;pile[WZ1]=20;pile[WZ2]=101;pile[WZ3]=29;pile[WZ4]=jvj+4;
(*f[175])(); /*QUADRI2(100,20,101,29,jvj+4)*/
pile[WZ1]=41;pile[WZ2]=130;pile[WZ3]=N;pile[WZ4]=jvj+8;
(*f[256])(); /*QUADRI7(100,41,130,N,jvj+8)*/
pile[WZ1]=21;pile[WZ2]=140;pile[WZ3]=(-632);pile[WZ4]=jvj+9;
(*f[255])(); /*QUADRI6(100,21,140,(-632),jvj+9)*/
pile[WZ1]=41;pile[WZ2]=130;pile[WZ3]=0;pile[WZ4]=jvj+11;
(*f[256])(); /*QUADRI7(100,41,130,0,jvj+11)*/
pile[v[22]]=jvj+9;pile[WZ1]=111;pile[WZ2]=jvj+10;
(*f[68])(); /*TRI4(jvj+9,111,jvj+10)*/
pile[v[22]]=100;pile[WZ1]=484;pile[WZ2]=102;pile[WZ3]=jvj+11;pile[WZ4]=jvj+10;pile[WZ5]=jvj+6;
(*f[254])(); /*QUADRI5(100,484,102,jvj+11,jvj+10,jvj+6)*/
pile[v[22]]=jvj+4;pile[WZ1]=111;pile[WZ2]=jvj+5;
(*f[68])(); /*TRI4(jvj+4,111,jvj+5)*/
pile[v[22]]=jvj+5;pile[WZ1]=jvj+6;pile[WZ2]=103;pile[WZ3]=jvj+7;
(*f[58])(); /*TRI2(jvj+5,jvj+6,103,jvj+7)*/
pile[v[22]]=100;pile[WZ1]=22;pile[WZ2]=102;pile[WZ3]=jvj+8;pile[WZ4]=jvj+7;pile[WZ5]=jvj+3;
(*f[254])(); /*QUADRI5(100,22,102,jvj+8,jvj+7,jvj+3)*/
pile[v[22]]=jvj+2;pile[WZ1]=jvj+3;
(*f[503])(); /*PLUB2(jvj+2,jvj+3)*/
x[NNNE]=x[jvj+2];z[NNNE]=z[jvj+2];
l1:x[jvj+1]=incon;v[0]=jvj;v[22]-=2;return;
}
Every such C file starts with #include "dx.h" and dx.h itself includes
some system headers <stdio.h> <ctype.h> <signal.h> <dlfcn.h> <time.h>
<unistd.h> <sys/mman.h> <errno.h> <stdlib.h>
and declare nearly 3000 functions like
void TRANSFORMC0(void ); and also a dozen arrays like int sk[201][401];
int tu[600000]; short int ts[600000];
As you can see, the C source file above is not human-understandable. It
is generated. And there are almost three thousand files like this.
I am definitely not able to reduce that to a smaller example.
For what it is worth, MALICE is a reflexive constraint solving system.
It manages it own stacks. I think that v[22] is used as a "top of
argument stack" index into pile[] used as its argument stack, and I was
hoping that with -flto -O2, gcc could perhaps share a little better that
index.
Are you suggesting me to upload to bugzilla the nearly 3000 preprocessed
forms of the files? I could do that, but the *.i files totalize more
than one gigabyte. A bzip2 compressed tar archive of them is almost
80Mbytes.
I was trying to compile that stuff with
gcc-trunk -flto -O2 [A-Z]*.c -rdynamic -ldl -o malice
and there is a sigsegv in the lto2 process. I don't even know how to
debug that (just how to start in the gdb debugger the lto process with
the correct invocation).
I agree that this example is perhaps contrived or at least unusual, but
LTO bugs probably all involve several files (that what is LTO about),
and there are situations where reducing an example to something
manageable is not easy. I was with the intuition that this MALICE
example should be compilable by LTO. It is not that big by today's
standards (it is at least 10 times smaller than GCC). And the sigsegv
does not occur when memory is rare (I have 8Gb RAM and not all of it is
used when lto crashes.).
>
>> 3. On the MELT branch, I regularily find bugs & correct them, and it did
>> happen that someone registered a MELT bug on the bugzilla; I did correct it
>> but AFAIR was not permitted to close the bug. Sometimes I am sad of not being
>> able to report MELT bugs on bugzilla and to close them when I feel I have
>> covered them.
>
> Log in to Bugzilla with your gcc.gnu.org address to get access to close
> bugs, add versions and milestones, etc.
Did I understand correctly that GCC bugzilla treats magically the
*@gcc.gnu.org email adresses matching accounts usable for SVN write
access? This is great news!
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: when (not) use bugzilla for GCC?
2009-10-26 11:57 ` Basile STARYNKEVITCH
@ 2009-10-26 14:39 ` Ian Lance Taylor
2009-10-26 14:41 ` Richard Guenther
2009-10-26 20:46 ` Basile STARYNKEVITCH
0 siblings, 2 replies; 10+ messages in thread
From: Ian Lance Taylor @ 2009-10-26 14:39 UTC (permalink / raw)
To: Basile STARYNKEVITCH; +Cc: Joseph S. Myers, GCC Mailing List
Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
> Are you suggesting me to upload to bugzilla the nearly 3000
> preprocessed forms of the files? I could do that, but the *.i files
> totalize more than one gigabyte. A bzip2 compressed tar archive of
> them is almost 80Mbytes.
That is a difficulty, but without a self-contained test case it's
pretty hard to fix the bug. You can try reporting the bug with a URL
for where to download the sources. Since LTO is fairly new a
maintainer may be willing to download them and try it. Otherwise, go
ahead and upload that 80M tar ball. gcc.gnu.org will cope.
> Did I understand correctly that GCC bugzilla treats magically the
> *@gcc.gnu.org email adresses matching accounts usable for SVN write
> access? This is great news!
Yes, that is how it works.
Ian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: when (not) use bugzilla for GCC?
2009-10-26 14:39 ` Ian Lance Taylor
@ 2009-10-26 14:41 ` Richard Guenther
2009-10-26 14:56 ` Basile STARYNKEVITCH
2009-10-26 20:46 ` Basile STARYNKEVITCH
1 sibling, 1 reply; 10+ messages in thread
From: Richard Guenther @ 2009-10-26 14:41 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Basile STARYNKEVITCH, Joseph S. Myers, GCC Mailing List
On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor <iant@google.com> wrote:
> Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
>
>> Are you suggesting me to upload to bugzilla the nearly 3000
>> preprocessed forms of the files? I could do that, but the *.i files
>> totalize more than one gigabyte. A bzip2 compressed tar archive of
>> them is almost 80Mbytes.
>
> That is a difficulty, but without a self-contained test case it's
> pretty hard to fix the bug. You can try reporting the bug with a URL
> for where to download the sources. Since LTO is fairly new a
> maintainer may be willing to download them and try it. Otherwise, go
> ahead and upload that 80M tar ball. gcc.gnu.org will cope.
Please don't. Bi-sect the list of object files by adding -r -nostdlib
to the link line. This should result in a two or three file testcase.
Either attach those or reduce them with delta.
Richard.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: when (not) use bugzilla for GCC?
2009-10-26 14:41 ` Richard Guenther
@ 2009-10-26 14:56 ` Basile STARYNKEVITCH
2009-10-26 15:39 ` Richard Guenther
2009-10-29 5:35 ` Basile STARYNKEVITCH
0 siblings, 2 replies; 10+ messages in thread
From: Basile STARYNKEVITCH @ 2009-10-26 14:56 UTC (permalink / raw)
To: Richard Guenther; +Cc: Ian Lance Taylor, Joseph S. Myers, GCC Mailing List
Richard Guenther wrote:
> On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor <iant@google.com> wrote:
>> Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
>>
>>> Are you suggesting me to upload to bugzilla the nearly 3000
>>> preprocessed forms of the files? I could do that, but the *.i files
>>> totalize more than one gigabyte. A bzip2 compressed tar archive of
>>> them is almost 80Mbytes.
>> That is a difficulty, but without a self-contained test case it's
>> pretty hard to fix the bug. You can try reporting the bug with a URL
>> for where to download the sources. Since LTO is fairly new a
>> maintainer may be willing to download them and try it. Otherwise, go
>> ahead and upload that 80M tar ball. gcc.gnu.org will cope.
>
> Please don't. Bi-sect the list of object files by adding -r -nostdlib
> to the link line. This should result in a two or three file testcase.
> Either attach those or reduce them with delta.
I am not sure to understand what that means technically.
The sisegv is gotten by running
gcc -flto -O2 [A-Z]*.c -rdynamic -ldl -o malice-lto
where the [A-Z]*.c file glob pattern expand to nearly 3000 files.
Exactly those from
http://pagesperso-orange.fr/jacques.pitrat/malice-2009.tar.bz2
What command to you suggest me to run? How will I find the faulty files...
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: when (not) use bugzilla for GCC?
2009-10-26 14:56 ` Basile STARYNKEVITCH
@ 2009-10-26 15:39 ` Richard Guenther
2009-10-29 5:35 ` Basile STARYNKEVITCH
1 sibling, 0 replies; 10+ messages in thread
From: Richard Guenther @ 2009-10-26 15:39 UTC (permalink / raw)
To: Basile STARYNKEVITCH; +Cc: Ian Lance Taylor, Joseph S. Myers, GCC Mailing List
On Mon, Oct 26, 2009 at 3:39 PM, Basile STARYNKEVITCH
<basile@starynkevitch.net> wrote:
> Richard Guenther wrote:
>>
>> On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor <iant@google.com> wrote:
>>>
>>> Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
>>>
>>>> Are you suggesting me to upload to bugzilla the nearly 3000
>>>> preprocessed forms of the files? I could do that, but the *.i files
>>>> totalize more than one gigabyte. A bzip2 compressed tar archive of
>>>> them is almost 80Mbytes.
>>>
>>> That is a difficulty, but without a self-contained test case it's
>>> pretty hard to fix the bug. You can try reporting the bug with a URL
>>> for where to download the sources. Since LTO is fairly new a
>>> maintainer may be willing to download them and try it. Otherwise, go
>>> ahead and upload that 80M tar ball. gcc.gnu.org will cope.
>>
>> Please don't. Bi-sect the list of object files by adding -r -nostdlib
>> to the link line. This should result in a two or three file testcase.
>> Either attach those or reduce them with delta.
>
>
> I am not sure to understand what that means technically.
>
> The sisegv is gotten by running
>
> gcc -flto -O2 [A-Z]*.c -rdynamic -ldl -o malice-lto
>
> where the [A-Z]*.c file glob pattern expand to nearly 3000 files. Exactly
> those from http://pagesperso-orange.fr/jacques.pitrat/malice-2009.tar.bz2
>
> What command to you suggest me to run? How will I find the faulty files...
See the LTO section in http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
Richard.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: when (not) use bugzilla for GCC?
2009-10-26 14:39 ` Ian Lance Taylor
2009-10-26 14:41 ` Richard Guenther
@ 2009-10-26 20:46 ` Basile STARYNKEVITCH
2009-10-26 21:42 ` Ian Lance Taylor
1 sibling, 1 reply; 10+ messages in thread
From: Basile STARYNKEVITCH @ 2009-10-26 20:46 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Joseph S. Myers, GCC Mailing List
Ian Lance Taylor wrote:
> Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
>
>> Did I understand correctly that GCC bugzilla treats magically the
>> *@gcc.gnu.org email adresses matching accounts usable for SVN write
>> access? This is great news!
>
> Yes, that is how it works.
May I respectfully suggest to the person maintaining the bugzilla a
notice in the login page saying something like:
GCC maintainers having write after approval (or better) access to the
GCC trunk should preferably login with their XXXXX@gcc.gnu.org email
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: when (not) use bugzilla for GCC?
2009-10-26 20:46 ` Basile STARYNKEVITCH
@ 2009-10-26 21:42 ` Ian Lance Taylor
0 siblings, 0 replies; 10+ messages in thread
From: Ian Lance Taylor @ 2009-10-26 21:42 UTC (permalink / raw)
To: Basile STARYNKEVITCH; +Cc: Joseph S. Myers, GCC Mailing List
Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
> May I respectfully suggest to the person maintaining the bugzilla a
> notice in the login page saying something like:
>
> GCC maintainers having write after approval (or better) access to the
> GCC trunk should preferably login with their XXXXX@gcc.gnu.org email
Good idea, but nobody maintains bugzilla these days, at least beyond
the bare minimum of taking a look if something breaks. If anybody
wants to tackle this and knows what to do, let me know.
Ian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: when (not) use bugzilla for GCC?
2009-10-26 14:56 ` Basile STARYNKEVITCH
2009-10-26 15:39 ` Richard Guenther
@ 2009-10-29 5:35 ` Basile STARYNKEVITCH
1 sibling, 0 replies; 10+ messages in thread
From: Basile STARYNKEVITCH @ 2009-10-29 5:35 UTC (permalink / raw)
To: Richard Guenther; +Cc: Ian Lance Taylor, Joseph S. Myers, GCC Mailing List
Basile STARYNKEVITCH wrote:
> Richard Guenther wrote:
>> On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor <iant@google.com>
>> wrote:
>>> Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
>>>
>>>> Are you suggesting me to upload to bugzilla the nearly 3000
>>>> preprocessed forms of the files? I could do that, but the *.i files
>>>> totalize more than one gigabyte. A bzip2 compressed tar archive of
>>>> them is almost 80Mbytes.
I actually found that the bug is triggered by any gcc -flto -O2
compilation of a lot of files.
I submitted PRµ41858 with a tiny C-source file generator. So the example
main.c in the bugzilla is tiny, but able to generate a lot of source code.
I hope that this helps.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2009-10-28 21:44 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-25 18:48 when (not) use bugzilla for GCC? Basile STARYNKEVITCH
2009-10-26 7:11 ` Joseph S. Myers
2009-10-26 11:57 ` Basile STARYNKEVITCH
2009-10-26 14:39 ` Ian Lance Taylor
2009-10-26 14:41 ` Richard Guenther
2009-10-26 14:56 ` Basile STARYNKEVITCH
2009-10-26 15:39 ` Richard Guenther
2009-10-29 5:35 ` Basile STARYNKEVITCH
2009-10-26 20:46 ` Basile STARYNKEVITCH
2009-10-26 21:42 ` Ian Lance Taylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).