search for: ismetadata

Devang, I see the cause for confusion. Your message from this morning was specifically referring to this assert: Assertion `ExtVNI == VNI && "Unexpected existing value number"' failed. That assertion was fixed in the r144547. The PR shows this assert: Assertion failed: (isMetadata() && "Wrong MachineOperand accessor"), function Bisect fails until the beginning of time (or really r125140), so I'm not sure where to go with this now. If an outstanding issue still exists I'm hopeful something with show up with tonight's nightly tests. Chad On No...

...n! defm ADD : basic_sse2_fp_binop_rm<0x58, "add", fadd, int_x86_sse2_add_sd, 1>; ^ I'm hoping someone with backend experience understands why this would happen. I've looked over the definition of basic_sse2_fp_binop_rm and can't see any way in which adding MVT::isMetadata should impact it or the type inference step. I'm stumped. Does anyone have any suggestions? Nick -------------- next part -------------- A non-text attachment was scrubbed... Name: mvt-metadata.patch Type: text/x-patch Size: 7893 bytes Desc: not available URL: <http://lists.llvm.org/piper...

On Nov 14, 2011, at 4:52 PM, Chad Rosier wrote: > Devang, > I believe this has been fixed with llvm r144547. See: <rdar://problem/10441389>. It is likely that r144546 fixed some other bug. I just checked, this still fails with r144602. - Devang -------------- next part -------------- An HTML attachment was scrubbed... URL:

In that case I'll see if I can't bisect. Chad On Nov 14, 2011, at 5:32 PM, Devang Patel wrote: > > On Nov 14, 2011, at 4:52 PM, Chad Rosier wrote: > >> Devang, >> I believe this has been fixed with llvm r144547. See: <rdar://problem/10441389>. > > It is likely that r144546 fixed some other bug. I just checked, this still fails with r144602. > -

On Fri, Jul 1, 2011 at 4:09 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > I want to report a problem with an inline assembly instruction from a code generator pass? > > How can I do that with the proper diagnostic format and source location? > > Right now we only get: > > clang -c /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c > fatal

I want to report a problem with an inline assembly instruction from a code generator pass? How can I do that with the proper diagnostic format and source location? Right now we only get: clang -c /d/g/clang-tests/gcc-4_2-testsuite/src/gcc.target/i386/pr30848.c fatal error: error in backend: Inline asm output regs must be last on the x87 stack But gcc-4-2 can: $ gcc-4.2 -c

...I) + : AArch64AsmBackend(T, TT) {} + bool mayNeedRelaxation(const MCInst &) const { return false; } + + virtual bool doesSectionRequireSymbols(const MCSection &Section) const { + SectionKind kind = Section.getKind(); + return kind.isDataRel() || kind.isReadOnlyWithRel() || kind.isMetadata() || + kind.isMergeableConst(); + } + + unsigned int getNumFixupKinds() const { return AArch64::NumTargetFixupKinds; } + + bool fixupNeedsRelaxation(const MCFixup &Fixup, uint64_t Value, + const MCRelaxableFragment *DF, + const...