similar to: [LLVMdev] strict aliasing warning in x86 land

Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] strict aliasing warning in x86 land"

2007 Dec 15
0
[LLVMdev] strict aliasing warning in x86 land
On Saturday 15 December 2007 08:36:02 Mike Stump wrote: > /Volumes/mrs5/net/llvm/llvm/llvm/lib/Target/X86/X86ISelLowering.cpp: > In member function 'llvm::SDOperand > llvm::X86TargetLowering::LowerTRAMPOLINE(llvm::SDOperand, > llvm::SelectionDAG&)': > /Volumes/mrs5/net/llvm/llvm/llvm/lib/Target/X86/X86ISelLowering.cpp: > 5305: warning: dereferencing type-punned
2007 Dec 15
1
[LLVMdev] strict aliasing warning in x86 land
On Dec 15, 2007, at 2:15 AM, Duncan Sands wrote: > Can you please paste the line (line number 5305 isn't in > LowerTRAMPOLINE > in my tree...). You have to run svn update for it to have that line... :-) unsigned char N86Reg = ((X86RegisterInfo&)RegInfo).getX86RegNum(NestReg); I've not thought long or hard about the validity of the warning... I'm hoping
2007 Dec 15
1
[LLVMdev] strict aliasing in SPU land
/Volumes/mrs5/net/llvm/llvm/llvm/lib/Target/CellSPU/ SPUISelDAGToDAG.cpp: In function 'bool<unnamed>::isFPS16Immediate(llvm::ConstantFPSDNode*, short int&)': /Volumes/mrs5/net/llvm/llvm/llvm/lib/Target/CellSPU/ SPUISelDAGToDAG.cpp:141: warning: dereferencing type-punned pointer will break strict-aliasing rules In file included from
2007 Dec 20
2
[LLVMdev] random warnings
They looked real enough to me: /Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/SPUISelDAGToDAG.cpp: In function ‘bool<unnamed>::isFPS16Immediate(llvm::ConstantFPSDNode*, short int&)’: /Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/SPUISelDAGToDAG.cpp: 148: warning: dereferencing type-punned pointer will break strict- aliasing rules
2008 Jan 30
2
[LLVMdev] no build, no joy
llvm[3]: Compiling SPUISelDAGToDAG.cpp for Debug build In file included from /Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/ SPUISelDAGToDAG.cpp:334: /Volumes/mrs5/net/llvm/llvm-build/lib/Target/CellSPU/ SPUGenDAGISel.inc: In member function ‘llvm::SDNode* SPUDAGToDAGISel::Emit_5(const llvm::SDOperand&, unsigned int, unsigned int, llvm::MVT::ValueType, llvm::MVT::ValueType)’:
2007 Dec 22
0
[LLVMdev] random warnings
On Dec 20, 2007, at 3:56 PM, Mike Stump wrote: > They looked real enough to me: Fixed, thanks. -Chris > > > /Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/SPUISelDAGToDAG.cpp: In > function ‘bool<unnamed>::isFPS16Immediate(llvm::ConstantFPSDNode*, > short int&)’: > /Volumes/mrs5/net/llvm/llvm/lib/Target/CellSPU/SPUISelDAGToDAG.cpp: > 148: warning:
2008 Jan 30
0
[LLVMdev] no build, no joy
On Jan 30, 2008, at 2:10 PM, Mike Stump wrote: > /Volumes/mrs5/net/llvm/llvm-build/lib/Target/CellSPU/ > SPUGenDAGISel.inc: In member function ‘llvm::SDNode* > SPUDAGToDAGISel::Emit_5(const llvm::SDOperand&, unsigned int, unsigned > int, llvm::MVT::ValueType, llvm::MVT::ValueType)’: Merely rming the file makes it work again. Would be nice if the rules were always incremental
2008 Sep 26
4
[LLVMdev] build failure in Attributes.h
I'm seeing a build failure... In file included from /Volumes/mrs5/net/llvm/llvm/lib/VMCore/ Attributes.cpp:14: /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h: In member function 'llvm::Attributes llvm::AttrListPtr::getParamAttributes(unsigned int) const': /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h:152: error: 'assert' was not declared in this scope
2008 Jan 02
1
[LLVMdev] problems found with make check on x86 darwin9
FAIL: /Volumes/mrs5/net/llvm/llvm/test/CFrontend/2007-09-20- GcrootAttribute.c Failed with exit(1) at line 3 while running: /Volumes/mrs5/Packages/llvm-2/bin/llvm-gcc -emit-llvm - S -emit-llvm /Volumes/mrs5/net/llvm/llvm/test/CFrontend/2007-09-20- GcrootAttribute.c -o - | llvm-as llvm-as: assembly parsed, but does not verify as correct! Enclosing function does not specify a collector algorithm.
2008 Sep 24
1
[LLVMdev] llvm broken?
/Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/CodeGenPrepare.cpp: In member function ‘bool<unnamed>::CodeGenPrepare::OptimizeInlineAsmInst (llvm::Instruction*, llvm::CallSite, llvm::DenseMap<llvm::Value*, llvm::Value*, llvm::DenseMapInfo<llvm::Value*>, llvm::DenseMapInfo<llvm::Value*> >&)’:
2008 Sep 26
0
[LLVMdev] build failure in Attributes.h
Works for me. Presumably #including <cassert> will fix it though? On Sep 26, 2008, at 4:30 PMPDT, Mike Stump wrote: > I'm seeing a build failure... > > In file included from /Volumes/mrs5/net/llvm/llvm/lib/VMCore/ > Attributes.cpp:14: > /Volumes/mrs5/net/llvm/llvm/include/llvm/Attributes.h: In member > function 'llvm::Attributes >
2009 Jan 02
2
[LLVMdev] new warnings in -r61596
2 new warnings in llvm: /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp: In member function 'bool llvm::LLParser::ParseGlobal(const std::string&, const char*, unsigned int, bool, unsigned int)': /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp:446: warning: 'IsConstant' may be used uninitialized in this function
2008 Aug 20
1
[LLVMdev] new warning in InstructionCombining.cpp
/Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/ InstructionCombining.cpp: In member function ‘llvm::Instruction*<unnamed>::InstCombiner::visitAnd (llvm::BinaryOperator&)’: /Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/ InstructionCombining.cpp:3597: warning: ‘RHSCC’ may be used uninitialized in this function /Volumes/mrs5/net/llvm/llvm/lib/Transforms/Scalar/
2007 Dec 15
4
[LLVMdev] fix warning with newer g++ compilers
Newer g++ compilers can emit: /Volumes/mrs5/net/llvm/llvm/llvm/lib/AsmParser/LLLexer.cpp: In member function 'int llvm::LLLexer::LexAt()': /Volumes/mrs5/net/llvm/llvm/llvm/lib/AsmParser/LLLexer.cpp:287: warning: suggest a space before ';' or explicit braces around empty body in 'for' statement /Volumes/mrs5/net/llvm/llvm/llvm/lib/AsmParser/LLLexer.cpp: In member
2008 Jan 09
1
[LLVMdev] icing on LiveIntervalAnalysis
On darwin x86, I'm seeing: $ make ENABLE_OPTIMIZED=1 llvm[2]: Compiling LiveIntervalAnalysis.cpp for Release build Assertion failed: (MVT::isInteger(LVT)), function MeetsMaxMemopRequirement, file /Volumes/mrs5/net/llvm/llvm/lib/CodeGen/ SelectionDAG/SelectionDAGISel.cpp, line 4230. /Volumes/mrs5/net/llvm/llvm/lib/CodeGen/LiveIntervalAnalysis.cpp:1466: internal compiler error: Abort trap
2009 Jan 24
1
[LLVMdev] new warnings
A new warning: /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp: In member function 'bool llvm::LLParser::ParseGlobal(const std::string&, const char*, unsigned int, bool, unsigned int)': /Volumes/mrs5/net/llvm/llvm/lib/AsmParser/LLParser.cpp:448: warning: 'IsConstant' may be used uninitialized in this function
2009 Mar 12
2
[LLVMdev] llvm no build?
llvm no build? llvm/llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp: In member function ‘bool llvm::PIC16AsmPrinter::printMachineInstruction(const llvm::MachineInstr*)’: llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp:80: error: ‘CurBank’ was not declared in this scope llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp: In member function ‘virtual bool llvm::PIC16AsmPrinter::runOnMachineFunction
2009 Mar 12
0
[LLVMdev] llvm no build?
Mike Stump wrote: > llvm no build? > > llvm/llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp: In member function > ‘bool llvm::PIC16AsmPrinter::printMachineInstruction(const > llvm::MachineInstr*)’: > llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp:80: error: ‘CurBank’ was not > declared in this scope > llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp: In member function ‘virtual >
2008 Apr 16
3
[LLVMdev] Being able to know the jitted code-size before emitting
> > How about a default GetInstSize() as well? Return 1 for every > instruction except for some special TargetInstrInfo instructions, e.g. > PHI, IMPLICIT_DEF, LABEL. I don't know if it's useful or not. But > perhaps we can default most targets to it? > > I prefer not giving a default implementation and aborting with a message that says the target did not
2008 Apr 15
4
[LLVMdev] Being able to know the jitted code-size before emitting
OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And