search for: x84_64

Hello there, it seems that EPEL only provides mingw cross-compiler packages for aarch64. Aren't there x64_64 ones for CentOS 7, as there were for CentOS 6? Regards, -- wwp https://useplaintext.email/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL:

On 2/27/20 1:47 AM, wwp wrote: > Hello there, > > it seems that EPEL only provides mingw cross-compiler packages for > aarch64. Aren't there x64_64 ones for CentOS 7, as there were for > CentOS 6? Not quite sure why you are asking questions about EPEL on the CentOS list, but here is your answer: https://lists.fedoraproject.org/archives/list/epel-devel at

Hi David, > "LLVM type size doesn't match GCC type size!"' failed. this assertion checks that gcc types are converted into LLVM types of the same size. Try running cc1 in gdb. When you hit the assertion, go up a few stack frames until you get to ConvertType. Do call debug_tree(type) That will tell you what the gcc type was. From that and the LLVM type it should be clear

On Thursday 11 October 2007 11:24, David Greene wrote: > Somehow PointerType::get is returning a 64-bit pointer even though > -m32 was passed to llvm-gcc. > > I'll see if I can figure out where the 64-bit code warning is emitted and > what triggers it. Aha! I found this previous thread: http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-May/009177.html I am now trying to build

On Thursday 11 October 2007 02:39, Duncan Sands wrote: > Hi David, > > > "LLVM type size doesn't match GCC type size!"' failed. > > this assertion checks that gcc types are converted into > LLVM types of the same size. Try running cc1 in gdb. > When you hit the assertion, go up a few stack frames > until you get to ConvertType. Do > call

On Wednesday 10 October 2007 12:53, Chris Lattner wrote: > On Mon, 8 Oct 2007, Evan Cheng wrote: > > I am turning 32-bit add into 32-bit LEA on x86-64 but that's > > perfectly legal. Both > > leal (%esi,%edi), %eax > > leal (%rsi,%rdi), %eax > > are legal assembly. It's just the former requires a 67H prefix due to > > the 32-bit address size. >

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have so far avoided using the x86_64 distro, sticking to 32 bits on all my servers. My question for all using the 64bits distro is: is it really worth it ? What kind of applications are you running, and what kind of _real_ gain did you have ? Note: All my servers are 2GB RAM or less. - -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum

On Oct 8, 2007, at 12:50 PM, David Greene wrote: > I've been unable to bootstrap llvm-gcc-4.0 or -4.2 for x86_64 > for some weeks now. The current problem is this: > > [x86_64-mod-dbg]: ./xgcc -B./ > -B/install.modified.debug/x86_64-unknown-linux-gnu/x86_64-unknown- > linux-gnu/bin/ > -isystem /install.modified.debug/x86_64-unknown-linux-gnu/x86_64- >

On Wednesday 10 October 2007 17:12, David Greene wrote: > This particular problem is gone (thanks!) but I'm having other troubles. > I'm tracking those down now. This is the current problem: [x86_64-off-dbg]: ./xgcc -B./ -B/install.official.debug/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/ -isystem

On Oct 8, 2007, at 4:26 PM, Chris Lattner wrote: > On Mon, 8 Oct 2007, Evan Cheng wrote: >>> [x86_64-mod-dbg]: /tmp/ccxekXCc.s: Assembler messages: >>> [x86_64-mod-dbg]: /tmp/ccxekXCc.s:36: Error: `(%esi,%edi)' is not a >>> valid 64 >>> bit base/index expression >> >> Looks like llvm is generating invalid x86-64 assembly. Can you add

...i/makefile.hdr rm debian/gnu-efi/usr/include/efi/protocol/make.inf rm debian/gnu-efi/usr/include/efi/protocol/makefile.hdr rm debian/gnu-efi/usr/include/efi/protocol/readme.txt ifeq ($(buildarch),ia64) rm -rf debian/gnu-efi/usr/include/efi/ia32 rm -rf debian/gnu-efi/usr/include/efi/x84_64 else rm -rf debian/gnu-efi/usr/include/efi/ia64 endif [...] Debian will copy *everything* from inc. When it is an ia64 system, they will remove the ia32 and x84_64 headers (so you should be unable to build syslinux in ia64 on Debian, too). This will raise the question: Why does syslinux...

On Mon, 8 Oct 2007, Evan Cheng wrote: > I am turning 32-bit add into 32-bit LEA on x86-64 but that's > perfectly legal. Both > leal (%esi,%edi), %eax > leal (%rsi,%rdi), %eax > are legal assembly. It's just the former requires a 67H prefix due to > the 32-bit address size. > > This does point to a performance problem in the 3 address conversion > code (which I

On Mon, 8 Oct 2007, Evan Cheng wrote: >> [x86_64-mod-dbg]: /tmp/ccxekXCc.s: Assembler messages: >> [x86_64-mod-dbg]: /tmp/ccxekXCc.s:36: Error: `(%esi,%edi)' is not a >> valid 64 >> bit base/index expression > > Looks like llvm is generating invalid x86-64 assembly. Can you add a - > emit-llvm to the xgcc line and generate a reproducible test case? > Please

I've been unable to bootstrap llvm-gcc-4.0 or -4.2 for x86_64 for some weeks now. The current problem is this: [x86_64-mod-dbg]: ./xgcc -B./ -B/install.modified.debug/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/ -isystem /install.modified.debug/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/include -isystem

...tems mounted with "delaylog,inode64,logbsize=32k,logdev=/dev/sda2,nobarrier,quota" options, and I suspect that inode64 may have to do with the observed behaviour. The server is running CentOS 6.3 + all patches. The clients exhibiting the problem are running CentOS 5.4 and CentOS 5.8 x84_64. Interesting enough, the application (which is available in 32-bit only) appears to work fine on RHEL3 32-bit; we have no CentOS5 32-bit systems to test. I was wondering if anyone has seen such behaviour and whether it can be corrected using nfs mount options. The only other solution I have at...

I'm trying to build a bugfixed anaconda package for 5.3 x84_64, but there are some fairly basic failures, like pkg-config .pc files not being found. When I modify the spec file accordingly, linking fails because installed libraries are not found. $ rpmbuild -ba anaconda.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.25019 + umask 022 + cd /usr/src/redh...

Hi folks, Can someone tell me the latest version of clamav-milter x84_64? I just yum installed it but it is version 0.88.2.el4kb, and the version on my server is 0.93. Is the difference between the two due to being different platforms? Thanks.. Sam

Hi, I have just installed Mandrake linux x84_64 (64 bit version) on my new dell poweredge server (1850 SMP) I am getting core dumps when trying to join the 2003 AD domain. ie. I run net ads join administrator@MY.DOMAIN running kinit worked ok. I am running samba version 3.0.20 samba-client-3.0.20-3mdk samba-server-3.0.20-3mdk samba-common-...

...an/gnu-efi/usr/include/efi/protocol/make.inf > rm debian/gnu-efi/usr/include/efi/protocol/makefile.hdr > rm debian/gnu-efi/usr/include/efi/protocol/readme.txt > ifeq ($(buildarch),ia64) > rm -rf debian/gnu-efi/usr/include/efi/ia32 > rm -rf debian/gnu-efi/usr/include/efi/x84_64 > else > rm -rf debian/gnu-efi/usr/include/efi/ia64 > endif > > [...] > > Debian will copy *everything* from inc. When it is an ia64 system, > they will remove the ia32 and x84_64 headers (so you should be unable > to build syslinux in ia64 on Debian, too). To...

...ut the scsi_wait_scan Module signed with unknown public key. The Dell Poweredge 2950 is running the latest 2.7.0 BIOS and BMC Firmware v2.50 with PERC5/i integrated (running latest firmware 5.2.2-0072, A09) Error reported; FATAL: Error inserting scsi_wait_scan (/lib/modules/2.6.32-431-1.2.el6.x84_64/kernel/drivers/scsi/scsi_wait_scan.ko) Required Key not available Module signed with unknown public key Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: init Not tainted 2.6.32-431.1.2.el6.x86_64 #1 regards Tim -- Kindest Regards, Tim D'Cruz Network and Systems Administra...