similar to: [LLVMdev] How to get rid of "xxx not a recognized feature for this target" warning?

Hi, In the following instruction sequence, llvm.objectsize.i64(p) returns 6 (the entire *.ll is attached to the mail). Is this correct? Shouldn't the "object" refer to the entire block of memory being allocated? (char*) p = malloc(56) llvm.objectisize.i32(p+50); Thanks Shuxin This question is related to PR14988 (failure in bootstrap build with LTO). Part of the

I have this code, which works fine on MacOS and Linux hosts: const char *target_specific_cpu_args; const char *target_specific_features; if (g->is_native_target) { target_specific_cpu_args = ZigLLVMGetHostCPUName(); target_specific_features = ZigLLVMGetNativeFeatures(); } else { target_specific_cpu_args = ""; target_specific_features =

Chris Webb <chris at arachsys.com> wrote: > My CPU flags inside the crashing guest look like this: > > fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush > mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb lm rep_good nopl > extd_apicid pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic popcnt aes xsave > avx f16c hypervisor lahf_lm

Chris Webb <chris at arachsys.com> wrote: > My CPU flags inside the crashing guest look like this: > > fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush > mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb lm rep_good nopl > extd_apicid pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic popcnt aes xsave > avx f16c hypervisor lahf_lm

I suspect that there are 2 issues here: * I have incorrect alignment somewhere * MSVC / .pdb / CodeView debugging is not working correctly. I think the latter would help solve the former. I will send out a new email later talking about the issues I'm having debugging llvm-generated binaries with MSVC. On Sat, Sep 30, 2017 at 3:33 PM, Andrew Kelley <superjoe30 at gmail.com> wrote:

Paolo Bonzini <pbonzini at redhat.com> wrote: > Il 29/05/2014 19:45, Chris Webb ha scritto: >> Chris Webb <chris at arachsys.com> wrote: >> >>> My CPU flags inside the crashing guest look like this: >>> >>> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush >>> mmx fxsr sse sse2 ht syscall nx mmxext

Paolo Bonzini <pbonzini at redhat.com> wrote: > Il 29/05/2014 19:45, Chris Webb ha scritto: >> Chris Webb <chris at arachsys.com> wrote: >> >>> My CPU flags inside the crashing guest look like this: >>> >>> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush >>> mmx fxsr sse sse2 ht syscall nx mmxext

Il 29/05/2014 19:45, Chris Webb ha scritto: > Chris Webb <chris at arachsys.com> wrote: > >> My CPU flags inside the crashing guest look like this: >> >> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush >> mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb lm rep_good nopl >> extd_apicid pni pclmulqdq ssse3 fma cx16

Running a 3.14.4 x86-64 SMP guest kernel on qemu-2.0, with kvm enabled and -cpu host on a 3.14.4 AMD Opteron host, I'm seeing a reliable kernel panic from the guest shortly after boot. I think is happening in kvm_unlock_kick() in the paravirt_ops code: divide error: 0000 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.4-guest #16 Hardware name: QEMU

Running a 3.14.4 x86-64 SMP guest kernel on qemu-2.0, with kvm enabled and -cpu host on a 3.14.4 AMD Opteron host, I'm seeing a reliable kernel panic from the guest shortly after boot. I think is happening in kvm_unlock_kick() in the paravirt_ops code: divide error: 0000 [#1] PREEMPT SMP Modules linked in: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.4-guest #16 Hardware name: QEMU

I figured it out. I was using this implementation of __chkstk from compiler-rt: DEFINE_COMPILERRT_FUNCTION(___chkstk) push %rcx cmp $0x1000,%rax lea 16(%rsp),%rcx // rsp before calling this routine -> rcx jb 1f 2: sub $0x1000,%rcx test %rcx,(%rcx) sub $0x1000,%rax cmp $0x1000,%rax ja 2b 1:

Better be quick! I am adding FMA4 and XOP now, and if you contribute code before I do, you can spare yourself some XOP merging. - Jan ----- Original Message ----- > From: David A. Greene <greened at obbligato.org> > To: Benjamin Kramer <benny.kra at googlemail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Thursday, December 1, 2011 12:19 PM > Subject: Re: [LLVMdev]

> On Aug 12, 2017, at 3:50 PM, Fred Smith <fredex at fcshome.stoneham.ma.us> wrote: > > I had a series of kernel hardware error reports today while I was away > from my computer: > > Message from syslogd at fcshome at Aug 12 10:12:24 ... > kernel:[Hardware Error]: MC2 Error: VB Data ECC or parity error. > > Message from syslogd at fcshome at Aug 12 10:12:24 ...

Jan Sjodin <jan_sjodin at yahoo.com> writes: > Better be quick! I am adding FMA4 and XOP now, and if you contribute > code before I do, you can spare yourself some XOP merging. Go ahead. We're not going to get there soon enough. :( -Dave

Hi Frank, I recommend trying trunk LLVM. AVX-512 development has been very active recently. -Hal ----- Original Message ----- > From: "Frank Winter via llvm-dev" <llvm-dev at lists.llvm.org> > To: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, June 29, 2016 2:41:39 PM > Subject: [llvm-dev] avx512 JIT backend generates wrong code on <4

Hi Hal! Thanks, but unfortunately it didn't help. The exact same assembler instructions are generated for both 3.8 (yesterday) and trunk (from today). So, this really looks like a bug. Best, Frank On 06/29/2016 03:48 PM, Hal Finkel wrote: > Hi Frank, > > I recommend trying trunk LLVM. AVX-512 development has been very active recently. > > -Hal > > ----- Original

I had a series of kernel hardware error reports today while I was away from my computer: Message from syslogd at fcshome at Aug 12 10:12:24 ... kernel:[Hardware Error]: MC2 Error: VB Data ECC or parity error. Message from syslogd at fcshome at Aug 12 10:12:24 ... kernel:[Hardware Error]: Error Status: Corrected error, no action required. Message from syslogd at fcshome at Aug 12 10:12:24 ...

That is too bad. :(  You can always review the patches, and if you see something that can be done better let me know. - Jan ----- Original Message ----- > From: David A. Greene <greened at obbligato.org> > To: Jan Sjodin <jan_sjodin at yahoo.com> > Cc: David A. Greene <greened at obbligato.org>; Benjamin Kramer <benny.kra at googlemail.com>; "llvmdev at

On Sat, Aug 12, 2017 at 05:51:33PM -0400, Steven Tardy wrote: > > > On Aug 12, 2017, at 3:50 PM, Fred Smith <fredex at fcshome.stoneham.ma.us> wrote: > > > > I had a series of kernel hardware error reports today while I was away > > from my computer: > > > > Message from syslogd at fcshome at Aug 12 10:12:24 ... > > kernel:[Hardware Error]:

Hello, I run into a problem that llvm can't write the correct ELFHeaderEFlags for hexagonv4. The following patch can fix it. Index: lib/Target/Hexagon/MCTargetDesc/HexagonMCTargetDesc.cpp =================================================================== --- lib/Target/Hexagon/MCTargetDesc/HexagonMCTargetDesc.cpp (revision 265917) +++