similar to: [LLVMdev] llvm-gcc4_2, llvm-gcc4_2-fixed-point

hi > > i fixed some major bugs in the llvm-gcc4_2 patch since my last post. > > this brings me to an interesting question: > > > > what are your criteria to use my patch for further development? > > I have no fixed criteria. I think the best solution is for the work to be > checked into the (forthcoming) public SVN server. When it is available, > you can

> > i was working on an llvm-gcc4_2 version, which i used as a starting-point for > > a fixed-point c-datatype implementation. > > i read that the svn repos is up now, and so i remembered the following lines: > > > >> On Fri, 23 Mar 2007, Peter Wiedermann wrote: > >>> i fixed some major bugs in the llvm-gcc4_2 patch since my last post. >

> > > On Jul 3, 2007, at 8:04 AM, Peter Wiedermann wrote: > > > yes. > > for a detailed llvm-gcc4 to llvm-gcc4.2 failure comparison see: > > > > http://geldspeicher.entenhausen.at/dl/llvm-gcc4_2_stat.ps.gz > > or > > http://geldspeicher.entenhausen.at/dl/llvm-gcc4_2_stat.pdf > > You have lots of failures, even for llvm-gcc-4.0. Which

hi! i fixed some major bugs in the llvm-gcc4_2 patch since my last post. this brings me to an interesting question: what are your criteria to use my patch for further development? at the moment i use the llvm-test1.9 suite for testing, because the actual llvm-test trunk in the repository seems to be broken. in my configuration the official llvm-gcc4 does not run completely error free against

hi! i was working on an llvm-gcc4_2 version, which i used as a starting-point for a fixed-point c-datatype implementation. i read that the svn repos is up now, and so i remembered the following lines: > On Fri, 23 Mar 2007, Peter Wiedermann wrote: > > i fixed some major bugs in the llvm-gcc4_2 patch since my last post. > > this brings me to an interesting question: > >

On Wed, 28 Mar 2007, Peter Wiedermann wrote: > ok, thats fine to me. > i think the worst part of the work is done. wow, you look quite far along. >> Hrm, that's strange. llvm-test doesn't pass 100% (e.g. some of the EH >> stuff is now working yet), but it should ahve basic functionality. What >> is broken? >> > > major error causes: > > the

On Thu, 29 Mar 2007, Reid Spencer wrote: > On Thu, 2007-03-29 at 23:47 -0800, Chris Lattner wrote: > >> Very nice. Reid/Anton, do you guys have an idea when the svn server will >> be available? > > Mid April. > > The SVN server is getting installed tomorrow. Anton and I are still > testing the automated conversion script (almost there). > > We will probably

On Thu, 2007-03-29 at 23:47 -0800, Chris Lattner wrote: > Very nice. Reid/Anton, do you guys have an idea when the svn server will > be available? Mid April. The SVN server is getting installed tomorrow. Anton and I are still testing the automated conversion script (almost there). We will probably make a beta svn server available (via my machine) for anyone that wants a preview. One

Hello List Samba Version :3.0.2 (Debian Woody) Kernel Verion :2.4.27 I had to reinstall a Windows XP-Professional-Box at work. When I got to the point where you add the box to the domain, it wouldn't let me to. (I also disabled the settings in secpol.msc) I deleted the entry in smbpasswd using smbpasswd -x -m trick$, added it new and still the same problem. (The UID are right) Out of

Hi, I read at least 100 different documentations during the last week and didn't get it. So I decided to ask the list for help :) Unfortunately we have to move to a Windows 2008 Server ADS in our company as this is required for some other projects. But we want to keep our nice 5+ samba-server providing fast 50TB+ of storage. So we have to find a way to nicely integrate the storage with the

Some debugging tools don't like if a code uses unitialized variables. The code in cpu.c uses the value of fxsr.buff[50], so it makes sense to explicitely initialize it (because fxsave can fail to do it). -------------- next part -------------- A non-text attachment was scrubbed... Name: cpu_init_val.patch Type: application/octet-stream Size: 409 bytes Desc: not available Url :

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-06:14.fpu Security Advisory The FreeBSD Project Topic: FPU information disclosure Category: core Module: sys Announced: 2006-04-19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-06:14.fpu Security Advisory The FreeBSD Project Topic: FPU information disclosure Category: core Module: sys Announced: 2006-04-19

Hi Mark, Code below: int16_t* samples; int16_t* fbSilenceFrame; void *fSpeexState; float eng(0.f); int speexFrameSize(0); speex_encoder_ctl(speexState, SPEEX_GET_FRAME_SIZE, &speexFrameSize); for (int i = 0; i < speexFrameSize; i++) { eng += samples[i] * samples[i]; } if (eng / speexFrameSize < 3.f) { memcpy(samples, silenceFrame, speexFrameSize * sizeof(int16_t)); } where

Hi Tanmay, >Does compiling speex API with DISABLE_FLOAT_API and DISABLE_VBR solve the >problem? I remember that this fixed the problem. But at that time I also needed VBR so this was not an option. As far as I know, it is related to some calculations that involve float denormals that cause the high CPU usage. Today I'm still using the following code before speex_encoder_init and

This patch tries to simplify the code that tries to detect whether OS supports SSE instructions. a) Linux: "old" vs "new" sigaction OBSOLETE_SIGCONTEXT_FLAVOR was disabled in Mar 2007 in commit <http://git.xiph.org/?p=flac.git;a=commit;h=1ca3a445f832be5e8a99364fb38d9e2ea9a3a772> According to <http://unixhelp.ed.ac.uk/CGI/man-cgi?sigaction>: "Support for

With the only bit in CR0 permitted to be changed by PV guests being TS, optimize the handling towards that: Keep a cached value in a per-CPU variable, and issue HYPERVISOR_fpu_taskswitch hypercalls for updates in all but the unusual case should something in the system still try to modify another bit (the attempt of which would then be logged by the hypervisor). This removes the need to have the

The first patch really isn''t as much of a follow-up than what triggered the security issues to be noticed in the first place. 1: x86: preserve FPU selectors for 32-bit guest code 2: x86: fix XCR0 handling 3: x86/xsave: adjust state management 4: x86/fxsave: bring in line with recent xsave adjustments The first two I would see as candidates for 4.3 (as well as subsequent backporting,

IF guest CR0.wp is 0 and the destination address is ReadOnly, we have to emulate it. Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Disheng Su <disheng.su.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

This patch adds a number of fp instructions needed for OS/2 to boot as a HVM guest on Intel/VT hardware. It appears to work fine, and OS/2 is now finally working on Intel/VT as well as AMD/SVM. I''m a little concerned about the "correctness" of the FSTSW emulation and the use of inline assembly directly using the corresponding ops for emulation. Wrt FSTSW, it is really two ops