search for: nexgo

On Tue, Dec 4, 2018 at 3:58 PM Daniel Sanders via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Dec 4, 2018, at 15:11, Stefan Kanthak <stefan.kanthak at nexgo.de> wrote: > No, I understand his intent. I just doesn't align with my intent, > including the hoops he/LLVM wants me to jump through. > > He's not saying they're your bugs, he's just saying they need > to be reported in the correct place. > > > Go ahead,...

...tps://llvm.org/docs/Contributing.html LLVM also have code of conduct : https://llvm.org/docs/CodeOfConduct.html On Sun, 23 Aug 2020 at 23:28, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Sun, Aug 23, 2020 at 10:54 AM Stefan Kanthak <stefan.kanthak at nexgo.de> > wrote: > >> "David Blaikie" <dblaikie at gmail.com> wrote: >> >> > Context is everything. >> >> I'm willing to accept your humble apologies. >> > > Sarcasm and snark are not appreciated. Your repeated interest in > a...

...c msg: C:\Windows\Temp\crash-74a40f.sh >> clang: note: diagnostic msg: >> >> ******************** >> >> --- crash-74a40f.c --- >> # 1 "<built-in>" >> # 1 "crash.c" >> // Copyright (C) 2020 Stefan Kanthak <stefan.kanthak at nexgo.de> >> >> long dummy; >> >> __attribute__((naked)) >> long function(void) >> { >> __asm__(".data\n" >> "dummy:\n" >> ".quad\t0\n" >> ".text\n" >>...

...diagnostic msg: C:\Windows\Temp\crash-74a40f.c clang: note: diagnostic msg: C:\Windows\Temp\crash-74a40f.sh clang: note: diagnostic msg: ******************** --- crash-74a40f.c --- # 1 "<built-in>" # 1 "crash.c" // Copyright (C) 2020 Stefan Kanthak <stefan.kanthak at nexgo.de> long dummy; __attribute__((naked)) long function(void) { __asm__(".data\n" "dummy:\n" ".quad\t0\n" ".text\n" ".intel_syntax noprefix\n" "\tmov\trax, dummy\n" &qu...

Objects compiled for the MS-ABI don't conform to it! Data types beyond 64 bit MUST BE returned by the callee via the hidden first argument allocated by the caller, NOT in XMM0! Demo/proof: from this source --- llvm-bug.c --- #ifndef __clang__ typedef struct { unsigned __int64 low; unsigned __int64 high; } __uint128_t; #else __attribute__((ms_abi)) #endif __uint128_t

"Tim Northover" <t.p.northover at gmail.com> wrote: > Hi, > > On Sat, 1 Dec 2018 at 17:37, Stefan Kanthak via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Compile the following functions with "-O3 -target amd64" > > You've been advised before, but you really need to start reporting > these as bugs[*] if you actually care about

...I'm one of the moderators there & any email sent there that doesn't come from the bug database will get automatically or manually rejected with the suggestion/request that the bug database is used instead. > > On Tue, Nov 27, 2018 at 4:37 PM Stefan Kanthak <stefan.kanthak at nexgo.de> > wrote: > >> "Sanjay Patel" <spatel at rotateright.com> wrote: >> >> > IIUC, you want to use x86-specific bit-hacks (sbb masking) in cases like >> > this: >> > unsigned int foo(unsigned int crc) { >> > if (crc & 0x...

...kages UDP/138 can't reach for the client. Hint: In another network in other buildings I have a simliary installation. In that nmbd sends to 127.0.0.1 and in tcpdump is seen the rigth sender-IP for each adapter. What can I do? with regards Andreas Matthus -- Andreas Matthus <matthus at nexgo.de> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4847 bytes Desc: not available URL: <http://lists.samba.org/pipermail/samba/attachments/20150110/9aa369b5/attachment.bin>

running redhat 7.1 with wine 20010313 it seems to work okay but it just refuses to make folders. Im trying to install counter-strike but when i set the install directory and the program asks if i want to create it i click ok but nothing happens. if i make the directory myself everything goes fine, the files are copied and everything. all the permissions seem to be set correctly.. any help?

Hi, I don't really know if it is the reason but when i tried tu run my explorer.exe with wine (without success) It removed all i had in 'Program Files' directory and added a folder 'Uninstall Information ...'. Does anyone know about it ... anyway it would be a warning. -- Omar

...xplorer, for instance, if you don't have a proper backup, as it renames/cripples several directories sometimes. Not even other MS apps such as e.g. Messenger are safe, as they launch Explorer somehow. This particular corruption (!$!$!$!$.pfr) can at least partially be fixed by using http://home.nexgo.de/andi.mohr/download/decorrupt_explorer" ---- Do you have any idea how to protect original Windows without backup? Or is the backup the only solution in this time? Thanks for hints, Petr

Hello, I'm new to using WINE (and to these lists), so I apologize if this has been asked and answered already: Has anyone been able to get Ghost Recon to at least install? The autorun program came up just fine, but when I click the button to install, it promptly quits. I tried running the setup.exe program directly, and it gets as far as trying to setup and install shield wizard, and then

"Tim Northover" <t.p.northover at gmail.com> wrote: > Hi Stefan, > > On Mon, 26 Nov 2018 at 12:37, Stefan Kanthak via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> LLVM/clang generates wrong code for the following program >> (see <https://godbolt.org/z/UZrrkG>): > > It looks like all of these issues come down to mismatched

Hi, I am using Speex to compress speech samples used for dictation. I am thrilled by the compression ratios Speex achieves with almost no loss in quality. However, I have come across a few files which Speex (I use the Windows variant) refuses to compress. I have put a sample file at http://leggewie.biz/test.wav. The error message I receive is "Unsupported WAVE file fmt chunk, not

"H. Peter Anvin" <hpa at zytor.com> wrote August 20, 2019 12:51 AM: > On 8/14/19 9:42 PM, Stefan Kanthak wrote: >> Hi, >> >> both >> https://git.kernel.org/pub/scm/libs/klibc/klibc.git/plain/usr/klibc/arch/i386/libgcc/__ashldi3.S >> and >> https://git.kernel.org/pub/scm/libs/klibc/klibc.git/plain/usr/klibc/arch/i386/libgcc/__lshrdi3.S

"Sanjay Patel" <spatel at rotateright.com> wrote: > IIUC, you want to use x86-specific bit-hacks (sbb masking) in cases like > this: > unsigned int foo(unsigned int crc) { > if (crc & 0x80000000) > crc <<= 1, crc ^= 0xEDB88320; > else > crc <<= 1; > return crc; > } To document this for x86 too: rewrite the function

...5 pushl %ebp 1f71: 89 e5 movl %esp, %ebp 1f73: 8b 55 08 movl 8(%ebp), %edx 1f76: 8b 45 0c movl 12(%ebp), %eax 1f79: 0f c8 bswapl %eax 1f7b: 0f ca bswapl %edx 1f7d: 5d popl %ebp 1f7e: c3 retl ~Craig On Sun, Nov 25, 2018 at 11:39 AM Stefan Kanthak <stefan.kanthak at nexgo.de> wrote: > "Craig Topper" <craig.topper at gmail.com> wrote: > > > bswapdi2 for i386 is correct > > OUCH! > > > Bits 31:0 of the source are loaded into edx. Bits 63:32 are loaded into > > eax. Those are each bswapped. > > This exchanges t...

bswapdi2 for i386 is correct Bits 31:0 of the source are loaded into edx. Bits 63:32 are loaded into eax. Those are each bswapped. The ABI for the return is edx contains bits [63:32] and eax contains [31:0]. This is opposite of how the register were loaded. ~Craig On Sun, Nov 25, 2018 at 10:36 AM Craig Topper <craig.topper at gmail.com> wrote: > bswapsi2 on the x86-64 isn't using

"Craig Topper" <craig.topper at gmail.com> wrote: > None of the "si" division routines will be used by x86. That was my expectation too. > They exist for targets that don't support the operations natively. > X86 supports them natively so will never use the library functions. So they SHOULD not be built (or at least not shipped) with the builtins library

...> Philippe Rétornaz <philippe.retornaz@epfl.ch> Phillip Lougher <phillip@squashfs.org.uk> Phillip Susi <psusi@ubuntu.com> Pierangelo Terzulli <pierigno@gmail.com> Piergiorgio Beruto <piergiorgio.beruto@gmail.com> Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> Pierre Carrier <pierre@spotify.com> Pierre Sauter <pierre.sauter@gmail.com> Pierre Tardy <pierre.tardy@intel.com> Pierre-Eric Pelloux-Prayer <pelloux@gmail.com> Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Pierre-Loup A. Griffais <p...