search for: _replaces_

...unsuffixed instructions are assumed to be long and alias bts to btsl and btr to btrl; or > 3. Always error even when there is no ambiguity. > > I have no opinion on which option LLVM should follow. Okay, so while digging through the history of the linux.git tree, I found this. The patch _replaces_ btrl instructions with btr instructions, for seemingly good reason. What is your opinion on the issue? commit 1c54d77078056cde0f195b1a982cb681850efc08 Author: Jeremy Fitzhardinge <jeremy at goop.org> Date: 5 years ago x86: partial unification of asm-x86/bitops.h This unifies the...

Eli Friedman wrote: > The reason it's the right thing to do is that the mem/imm forms of > btsw and btsl have exactly the same semantics. The Intel documentation implies that this is the case: > If the bit base operand specifies a memory location, it represents the address of the byte in memory that contains the bit base (bit 0 of the specified byte) of the bit string (see Figure

Hi All: I thought the default behaviour for Rsync was that it would only overwrite destination files that have a lesser date than the source file. Instead I have this: Source ibmhttpd@sch1p115 [/csapps115/IBMHTTPD/content-external/cna/html/meet]: ls -al meet.html -rwxr-xr-x 1 ibmhttpd ibmhttpd 30151 Jul 9 2002 meet.html Destination ibmhttpd@sch1p116

...'t used, build target isn't > x86-64, or --disable-sse2 was passed to configure) and prevent a > dependency on libstdc++. I've tested that part extensively but it > would be great if the maintainer (and others) could give this part a > close second look. > > This patch _replaces_ my previous submit, it does not build on top of it. > > GitHub: > > https://github.com/Chainfire/rsync/commit/ef3c13390601752ef652b37c15610e12e2309fea > > https://github.com/Chainfire/rsync/commit/ef3c13390601752ef652b37c15610e12e2309fea.patch > > Raw: > > From ef3c13...

hey fletcher, thanks for your input here. :+) and -- quite obviously -- your program will be whatever it is that _you_ think that it should be. of course. the thing is, i am certain that i have been clear that the feature that i believe will be "killer" is on-the-fly formatted display. that's my stand. and i'd say my reasoning has been equally clear, namely that this

What do you base this on? Per https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html : "For the x86-32 compiler, you must use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective. For the x86-64 compiler, these extensions are enabled by default." That reads to me like we're fine for SSE2. As stated in my comments, SSSE3 support must be

...ions are not enabled (g++ isn't used, build target isn't x86-64, or --disable-sse2 was passed to configure) and prevent a dependency on libstdc++. I've tested that part extensively but it would be great if the maintainer (and others) could give this part a close second look. This patch _replaces_ my previous submit, it does not build on top of it. GitHub: https://github.com/Chainfire/rsync/commit/ef3c13390601752ef652b37c15610e12e2309fea https://github.com/Chainfire/rsync/commit/ef3c13390601752ef652b37c15610e12e2309fea.patch Raw: >From ef3c13390601752ef652b37c15610e12e2309fea Mon Sep...