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