Date: Wed, 30 Dec 2015 21:12:14 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 205663] clang++ 3.7.1 gets Bus Errors during compilation on arm that has SCTLR bit[1]==1 (alignment required) Message-ID: <bug-205663-8-McO6fXl7TG@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-205663-8@https.bugs.freebsd.org/bugzilla/> References: <bug-205663-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205663 --- Comment #4 from Mark Millard <markmi@dsl-only.net> --- I've added the following new information on llvm's bugzilla report. Basical= ly alignas use can avoid the alignment problems but there are lots of places t= hat would need it in order for clang++ to work overall for SCTLR bit[1]=3D=3D1. The following change eliminates the specific Bus Error in clang and allows = the 11 line program to compile on an rpi2 --but causes include/clang/AST/Type.h= to pollute a namespace via <cstddef> use: # svnlite diff /usr/src/contrib/llvm/ Index: /usr/src/contrib/llvm/tools/clang/include/clang/AST/Type.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/contrib/llvm/tools/clang/include/clang/AST/Type.h (revision 292858) +++ /usr/src/contrib/llvm/tools/clang/include/clang/AST/Type.h (working co= py) @@ -14,6 +14,8 @@ #ifndef LLVM_CLANG_AST_TYPE_H #define LLVM_CLANG_AST_TYPE_H +#include <cstddef> // for std::max_align_t + #include "clang/AST/NestedNameSpecifier.h" #include "clang/AST/TemplateName.h" #include "clang/Basic/AddressSpaces.h" @@ -4336,7 +4338,7 @@ /// DependentTemplateSpecializationType - Represents a template /// specialization type whose template cannot be resolved, e.g. /// A<T>::template B<T> -class DependentTemplateSpecializationType : +class alignas(alignof(std::max_align_t)) DependentTemplateSpecializationTy= pe : public TypeWithKeyword, public llvm::FoldingSetNode { /// \brief The nested name specifier containing the qualifier. alignof(TemplateArgument) is not used because Types.h is used in contexts w= here TemplateArgument is an incomplete type and the notation would be rejected. The command that built a Type.o that worked was (from the script log of the build): --- Type.o --- /usr/bin/clang++ -target armv6--freebsd11.0-gnueabi -march=3Darmv7a -mno-unaligned-access -target armv6-gnueabi-freebsd11.0 --sysroot=3D/usr/obj/clang/arm.armv6/usr/src/tmp -B/usr/local/arm-gnueabi-f= reebs d/bin/ --sysroot=3D/usr/obj/clang/arm.armv6/usr/src/tmp -B/usr/local/arm-gnueabi-freebsd/bin/ -O -pipe -mfloat-abi=3Dsoftfp -I/usr/src/lib/clang/libclangast/../../../contrib/llvm/include -I/usr/src/l= ib/c lang/libclangast/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST = -I. -I/usr/src/lib/clang/libclangast/../../../contrib/llvm/../../l ib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=3D\ "armv6-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=3D\"armv6-unknown-freebsd11= .0\" -DDEFAULT_SYSROOT=3D\"\" -MD -MP -MF.depend.Type.o -MTType.o -Qunused-argum= ents=20 -std=3Dc++11 -fno-exceptions -fno-rtti -stdli b=3Dlibc++ -Wno-c++11-extensions -c /usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/Ty= pe.cpp -o Type.o So it used (in order): -target armv6--freebsd11.0-gnueabi -march=3Darmv7a -mno-unaligned-access -target armv6-gnueabi-freebsd11.0 (The first -target is what I supplied, the 2nd is from the FreeBSD build environment.) STILL FAILS OVERALL HOWEVER. . . Unfortunately clang++ on the rpi2 with SCTLR bit[1]=3D=3D1 dies for other c= ++ syntax when trying to build part of llvm (early in FreeBSD's buildworld): Program terminated with signal 10, Bus error. #0 0x00c43d28 in clang::ASTTemplateArgumentListInfo::initializeFrom () [New Thread 22a18000 (LWP 100079/<unknown>)] (gdb) bt #0 0x00c43d28 in clang::ASTTemplateArgumentListInfo::initializeFrom () #1 0x00c43f10 in clang::ASTTemplateKWAndArgsInfo::initializeFrom () #2 0x00cdc788 in clang::CXXDependentScopeMemberExpr::CXXDependentScopeMemberExpr () #3 0x00cdc99c in clang::CXXDependentScopeMemberExpr::Create () #4 0x00685384 in clang::Sema::ActOnDependentMemberExpr () #5 0x0068abec in clang::Sema::ActOnMemberAccessExpr () #6 0x0044a938 in clang::Parser::ParsePostfixExpressionSuffix () #7 0x00000000 in ?? () (gdb) x/i 0x00c43d28 0xc43d28 <_ZN5clang27ASTTemplateArgumentListInfo14initializeFromERKNS_24TemplateArgu= mentListInfoERbS4_S4_+396>: vst1.64 {d16-d17}, [r0]! (gdb) info all-regsisters Undefined info command: "all-regsisters". Try "help info". (gdb) info all-registers r0 0x234b96dc 592156380 . . . There are lots of places using "this + 1" and reinterpret_cast that therefo= re have the potential for a mis-matched alignment between the two types involv= ed, just like the one I initially reported (some of the below might not be at r= isk, I've not inspected all the details of each): # grep "reinterpret_cast.*this" lib/*/* lib/AST/Decl.cpp: SourceLocation *StoredLocs =3D reinterpret_cast<SourceLo= cation *>(this + 1); lib/AST/Decl.cpp: *reinterpret_cast<SourceLocation *>(this + 1) =3D EndLoc; lib/AST/Decl.cpp: =3D reinterpret_cast<const SourceLocation *>(this + 1); lib/AST/Decl.cpp: *reinterpret_cast<const SourceLocat= ion *>(this + 1)); lib/AST/DeclCXX.cpp: VarDecl **MyIndices =3D reinterpret_cast<VarDecl **> = (this + 1); lib/AST/DeclOpenMP.cpp: Expr **Vars =3D reinterpret_cast<Expr **>(this + 1= ); lib/AST/DeclTemplate.cpp: void **TypesAndInfos =3D reinterpret_cast<void **>(this + 1); lib/AST/DeclTemplate.cpp: std::memcpy(reinterpret_cast<void*>(this + 1), Expansions, lib/AST/Expr.cpp: return reinterpret_cast<CXXBaseSpecifier**>(static_cast<Type*>(this)+1); lib/AST/Expr.cpp: Stmt *const *SubExprs =3D reinterpret_cast<Stmt *const *= >(this + 1); lib/AST/Expr.cpp: Stmt *const *SubExprs =3D reinterpret_cast<Stmt *const *= >(this + 1); lib/AST/Expr.cpp: Stmt *const *SubExprs =3D reinterpret_cast<Stmt *const *= >(this + 1); lib/AST/Expr.cpp: begin =3D reinterpret_cast<Stmt **>(this + 1); lib/AST/ExprCXX.cpp: Stmt **StoredArgs =3D reinterpret_cast<Stmt **>(this = + 1); lib/AST/ExprCXX.cpp:=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 reinterpret_cast<Decl**>(this+1)); lib/AST/Stmt.cpp: Stmt **Stmts =3D reinterpret_cast<Stmt **>(this + 1); lib/AST/Stmt.cpp: reinterpret_cast<char *>(const_cast<CapturedStmt *>(this)) lib/AST/Type.cpp: QualType *argSlot =3D reinterpret_cast<QualType*>(this+1= ); lib/AST/Type.cpp: =3D reinterpret_cast<TemplateArgument *>(this + 1); lib/AST/Type.cpp: TemplateArgument *Begin =3D reinterpret_cast<TemplateArgument *>(this + 1); lib/Basic/IdentifierTable.cpp: IdentifierInfo **KeyInfo =3D reinterpret_cast<IdentifierInfo **>(this+1); lib/Basic/IdentifierTable.cpp: return reinterpret_cast<keyword_iterator>(this+1); lib/CodeGen/CGCleanup.h: return reinterpret_cast<Handler*>(this+1); lib/CodeGen/CGCleanup.h: return reinterpret_cast<const Handler*>(this+1); lib/CodeGen/CGCleanup.h: return reinterpret_cast<llvm::Value**>(this+1); lib/CodeGen/CGCleanup.h: return reinterpret_cast<llvm::Value* const *>(this+1); lib/CodeGen/CGExprCXX.cpp: RValue *getPlacementArgs() { return reinterpret_cast<RValue*>(this+1); } lib/CodeGen/CGExprCXX.cpp: return reinterpret_cast<DominatingValue<RValue>::saved_type*>(this+1); lib/Sema/CodeCompleteConsumer.cpp: Chunk *StoredChunks =3D reinterpret_cast<Chunk *>(this + 1); But there is lots more use of reinterpret_cast where "this" is not involved that might also have problems. Compare: # grep -l "reinterpret_cast.*this" lib/*/* lib/AST/Decl.cpp lib/AST/DeclCXX.cpp lib/AST/DeclOpenMP.cpp lib/AST/DeclTemplate.cpp lib/AST/Expr.cpp lib/AST/ExprCXX.cpp lib/AST/Stmt.cpp lib/AST/Type.cpp lib/Basic/IdentifierTable.cpp lib/CodeGen/CGCleanup.h lib/CodeGen/CGExprCXX.cpp lib/Sema/CodeCompleteConsumer.cpp vs. # grep -l "reinterpret_cast" lib/*/* lib/AST/APValue.cpp lib/AST/ASTDiagnostic.cpp lib/AST/Decl.cpp lib/AST/DeclCXX.cpp lib/AST/DeclOpenMP.cpp lib/AST/DeclTemplate.cpp lib/AST/DeclarationName.cpp lib/AST/Expr.cpp lib/AST/ExprCXX.cpp lib/AST/ExprConstant.cpp lib/AST/ItaniumMangle.cpp lib/AST/NestedNameSpecifier.cpp lib/AST/ParentMap.cpp lib/AST/Stmt.cpp lib/AST/StmtIterator.cpp lib/AST/Type.cpp lib/AST/TypeLoc.cpp lib/Analysis/CFG.cpp lib/Basic/Diagnostic.cpp lib/Basic/FileManager.cpp lib/Basic/IdentifierTable.cpp lib/CodeGen/CGBlocks.h lib/CodeGen/CGCleanup.cpp lib/CodeGen/CGCleanup.h lib/CodeGen/CGExpr.cpp lib/CodeGen/CGExprCXX.cpp lib/CodeGen/CodeGenModule.cpp lib/CodeGen/MicrosoftCXXABI.cpp lib/Driver/MSVCToolChain.cpp lib/Driver/Tools.h lib/Format/Encoding.h lib/Frontend/CacheTokens.cpp lib/Frontend/DependencyFile.cpp lib/Frontend/TextDiagnostic.cpp lib/Lex/HeaderMap.cpp lib/Lex/LiteralSupport.cpp lib/Parse/ParseExpr.cpp lib/Parse/ParseExprCXX.cpp lib/Parse/ParseObjc.cpp lib/Parse/ParsePragma.cpp lib/Parse/ParseTentative.cpp lib/Parse/Parser.cpp lib/Rewrite/RewriteRope.cpp lib/Sema/CodeCompleteConsumer.cpp lib/Sema/IdentifierResolver.cpp lib/Sema/SemaCast.cpp lib/Sema/SemaCodeComplete.cpp lib/Sema/SemaDecl.cpp lib/Sema/SemaDeclCXX.cpp lib/Sema/SemaDeclObjC.cpp lib/Sema/SemaExprMember.cpp lib/Sema/SemaExprObjC.cpp lib/Sema/SemaInit.cpp lib/Sema/SemaLookup.cpp lib/Sema/SemaStmt.cpp lib/Sema/SemaStmtAsm.cpp lib/Sema/TreeTransform.h lib/Serialization/ASTReader.cpp lib/Serialization/ASTReaderDecl.cpp lib/Serialization/ASTReaderStmt.cpp lib/Serialization/ASTWriter.cpp --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-205663-8-McO6fXl7TG>