Re: CVS commit: src
In article , Adam Hamsik wrote: > >On Nov,Tuesday 22 2011, at 10:22 PM, Aleksey Cheusov wrote: > >> Module Name: src >> Committed By:cheusov >> Date:Tue Nov 22 20:22:10 UTC 2011 >> >> Modified Files: >> src/distrib/sets/lists/tests: mi >> src/tests/util/awk: Makefile t_awk.sh >> Added Files: >> src/tests/util/awk: d_assign_NF.awk d_assign_NF.in d_assign_NF.out >> >> Log Message: >> Regression tests for awk(1) (PR 44063) > >Can you please explain why are you adding non atfied tests to tree. >There are many devs how are trying to convert whole src/tests dir to atf >and you are just adding more work to them. He does not want to write atf tests. In my opinion non-atf tests is better than no tests. christos
Re: CVS commit: src
On Nov,Tuesday 22 2011, at 10:22 PM, Aleksey Cheusov wrote: > Module Name: src > Committed By: cheusov > Date: Tue Nov 22 20:22:10 UTC 2011 > > Modified Files: > src/distrib/sets/lists/tests: mi > src/tests/util/awk: Makefile t_awk.sh > Added Files: > src/tests/util/awk: d_assign_NF.awk d_assign_NF.in d_assign_NF.out > > Log Message: > Regression tests for awk(1) (PR 44063) Can you please explain why are you adding non atfied tests to tree. There are many devs how are trying to convert whole src/tests dir to atf and you are just adding more work to them. Regards Adam.
Re: CVS commit: src/sys/fs/union
In article <2022035848.ga17...@netbsd.org>, David Holland wrote: >On Tue, Nov 22, 2011 at 01:17:43AM +, YAMAMOTO Takashi wrote: > > hi, > > > > do you have any plan on fs/unionfs? eg. remove it > >My vote would be to remove it; it doesn't work and the only reason it >was ever brought in had to do with alleged locking improvements. Is anyone using it? christos
Re: CVS commit: src/lib/libc/arch/vax
On Nov 22, 9:26am, c...@chuq.com (Chuck Silvers) wrote:
-- Subject: Re: CVS commit: src/lib/libc/arch/vax
| I haven't looked into that since we talked about it before.
| I thought you were going to investigate?
I am investigating, but being a gcc internals novice it is taking some time.
I have made some progress, in final.c:
case PLUS:
/* Some assemblers need integer constants to appear last (eg masm). */
if (CONST_INT_P (XEXP (x, 0)))
{
output_addr_const (file, XEXP (x, 1));
if (INTVAL (XEXP (x, 0)) >= 0)
fprintf (file, "+");
output_addr_const (file, XEXP (x, 0));
}
else
{
->output_addr_const (file, XEXP (x, 0));
if (!CONST_INT_P (XEXP (x, 1))
|| INTVAL (XEXP (x, 1)) >= 0)
fprintf (file, "+");
output_addr_const (file, XEXP (x, 1));
}
Where the arrow is, XEXP(x, 0) is a register rtl. Now I am tracking down
where the PLUS rtl got generated.
| I've seen several other problems with gcc-4.5 on vax:
| - ld crashes (run natively, it works fine as a tool on an amd64 host)
| - vi dumps core on startup
| - c++ exceptions crash in the exception-handling code
|
| I haven't investigated any of these. it's rather depressing.
No worries, we'll fix them. I am thankful that you fixed the vfork()
problem because that was a show-stopper for me using the emulator.
Now that I can do that, I can probably get the new gdb working
which could be some help [as well as debug the native problems].
Best,
christos
Re: CVS commit: src/lib/libc/arch/vax
On Tue, Nov 22, 2011 at 09:26:42 -0800, Chuck Silvers wrote: > I've seen several other problems with gcc-4.5 on vax: [...] > - c++ exceptions crash in the exception-handling code This is probably port-vax/44155 -uwe
Re: CVS commit: src/lib/libc/arch/vax
On Mon, Nov 21, 2011 at 05:49:26PM +, Christos Zoulas wrote: > In article <2021161748.b09dd17...@cvs.netbsd.org>, > Chuck Silvers wrote: > >-=-=-=-=-=- > > > >gcc 4.5 on vax creates PLT stubs with an entry mask of 0xffc > >rather than 0 like gcc 4.1 did, so the sneaky assembly functions > >that "ret" without really returning now clobber their registers. > >adjust these functions to avoid this problem. > > Whee! This should fix all the vfork lossage! Any news on the addsi3 issue? I haven't looked into that since we talked about it before. I thought you were going to investigate? I've seen several other problems with gcc-4.5 on vax: - ld crashes (run natively, it works fine as a tool on an amd64 host) - vi dumps core on startup - c++ exceptions crash in the exception-handling code I haven't investigated any of these. it's rather depressing. -Chuck
