[Bug 205663] clang++ 3.7.1 gets Bus Errors during compilation on arm that has SCTLR bit[1]==1 (alignment required)
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Wed Dec 30 21:12:13 UTC 2015
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205663
--- Comment #4 from Mark Millard <markmi at dsl-only.net> ---
I've added the following new information on llvm's bugzilla report. Basically
alignas use can avoid the alignment problems but there are lots of places that
would need it in order for clang++ to work overall for SCTLR bit[1]==1.
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
===================================================================
--- /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 copy)
@@ -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)) DependentTemplateSpecializationType :
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 where
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=armv7a
-mno-unaligned-access -target armv6-gnueabi-freebsd11.0
--sysroot=/usr/obj/clang/arm.armv6/usr/src/tmp -B/usr/local/arm-gnueabi-freebs
d/bin/ --sysroot=/usr/obj/clang/arm.armv6/usr/src/tmp
-B/usr/local/arm-gnueabi-freebsd/bin/ -O -pipe -mfloat-abi=softfp
-I/usr/src/lib/clang/libclangast/../../../contrib/llvm/include -I/usr/src/lib/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=\
"armv6-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"armv6-unknown-freebsd11.0\"
-DDEFAULT_SYSROOT=\"\" -MD -MP -MF.depend.Type.o -MTType.o -Qunused-arguments
-std=c++11 -fno-exceptions -fno-rtti -stdli
b=libc++ -Wno-c++11-extensions -c
/usr/src/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/Type.cpp
-o Type.o
So it used (in order):
-target armv6--freebsd11.0-gnueabi
-march=armv7a
-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]==1 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_24TemplateArgumentListInfoERbS4_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 therefore
have the potential for a mis-matched alignment between the two types involved,
just like the one I initially reported (some of the below might not be at risk,
I've not inspected all the details of each):
# grep "reinterpret_cast.*this" lib/*/*
lib/AST/Decl.cpp: SourceLocation *StoredLocs = reinterpret_cast<SourceLocation
*>(this + 1);
lib/AST/Decl.cpp: *reinterpret_cast<SourceLocation *>(this + 1) = EndLoc;
lib/AST/Decl.cpp: = reinterpret_cast<const SourceLocation *>(this + 1);
lib/AST/Decl.cpp: *reinterpret_cast<const SourceLocation
*>(this + 1));
lib/AST/DeclCXX.cpp: VarDecl **MyIndices = reinterpret_cast<VarDecl **> (this
+ 1);
lib/AST/DeclOpenMP.cpp: Expr **Vars = reinterpret_cast<Expr **>(this + 1);
lib/AST/DeclTemplate.cpp: void **TypesAndInfos = 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 = reinterpret_cast<Stmt *const *>(this
+ 1);
lib/AST/Expr.cpp: Stmt *const *SubExprs = reinterpret_cast<Stmt *const *>(this
+ 1);
lib/AST/Expr.cpp: Stmt *const *SubExprs = reinterpret_cast<Stmt *const *>(this
+ 1);
lib/AST/Expr.cpp: begin = reinterpret_cast<Stmt **>(this + 1);
lib/AST/ExprCXX.cpp: Stmt **StoredArgs = reinterpret_cast<Stmt **>(this + 1);
lib/AST/ExprCXX.cpp:
reinterpret_cast<Decl**>(this+1));
lib/AST/Stmt.cpp: Stmt **Stmts = reinterpret_cast<Stmt **>(this + 1);
lib/AST/Stmt.cpp: reinterpret_cast<char *>(const_cast<CapturedStmt
*>(this))
lib/AST/Type.cpp: QualType *argSlot = reinterpret_cast<QualType*>(this+1);
lib/AST/Type.cpp: = reinterpret_cast<TemplateArgument *>(this + 1);
lib/AST/Type.cpp: TemplateArgument *Begin =
reinterpret_cast<TemplateArgument *>(this + 1);
lib/Basic/IdentifierTable.cpp: IdentifierInfo **KeyInfo =
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 =
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
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list