Bug 205663 - clang++ 3.7.1 gets Bus Errors during compilation on arm that has SCTLR bit[1]==1 (alignment required)
Summary: clang++ 3.7.1 gets Bus Errors during compilation on arm that has SCTLR bit[1]...
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: arm Any
: --- Affects Many People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-28 12:55 UTC by Mark Millard
Modified: 2016-06-17 04:10 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Millard 2015-12-28 12:55:24 UTC
# more /tmp/main-5dac8d.cpp
# 1 "<built-in>"
# 1 "main.cc"
template <class _Tp, class _Up>
struct __has_rebind
{
    template <class _Xp> static char __test(typename _Xp::template rebind<_Up>* = 0);
};

int
main ()
{
return 0;
}

# more /tmp/main-5dac8d.sh
# Crash reproducer for FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225
# Driver args: "--driver-mode=g++" "main.cc"
# Original command:  "/usr/bin/clang++" "-cc1" "-triple" "armv6k--freebsd11.0-gnueabi" "-emit-obj" "-mrelax-all" "-disable-free" "-main-file-name" "main.cc" "-mrelocation-model" "static" "-mthread-model" "posix" "-mdisable-fp-elim" "-masm-verbose" "-mconstructor-aliases" "-target-cpu" "arm1176jzf-s" "-target-feature" "+soft-float" "-target-feature" "+soft-float-abi" "-target-feature" "-neon" "-target-feature" "-crypto" "-target-abi" "aapcs-linux" "-msoft-float" "-mfloat-abi" "soft" "-dwarf-column-info" "-resource-dir" "/usr/bin/../lib/clang/3.7.1" "-internal-isystem" "/usr/include/c++/v1" "-fdeprecated-macro" "-fdebug-compilation-dir" "/root/c_tests" "-ferror-limit" "19" "-fmessage-length" "338" "-mstackrealign" "-fno-signed-char" "-fobjc-runtime=gnustep" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "/tmp/main-e20b38.o" "-x" "c++" "main.cc"
 "/usr/bin/clang++" "-cc1" "-triple" "armv6k--freebsd11.0-gnueabi" "-emit-obj" "-mrelax-all" "-disable-free" "-main-file-name" "main.cc" "-mrelocation-model" "static" "-mthread-model" "posix" "-mdisable-fp-elim" "-masm-verbose" "-mconstructor-aliases" "-target-cpu" "arm1176jzf-s" "-target-feature" "+soft-float" "-target-feature" "+soft-float-abi" "-target-feature" "-neon" "-target-feature" "-crypto" "-target-abi" "aapcs-linux" "-msoft-float" "-mfloat-abi" "soft" "-dwarf-column-info" "-fdeprecated-macro" "-ferror-limit" "19" "-fmessage-length" "338" "-mstackrealign" "-fno-signed-char" "-fobjc-runtime=gnustep" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-x" "c++" "main-5dac8d.cpp"

The code involved is from lib/AST/Type.cpp :

DependentTemplateSpecializationType::DependentTemplateSpecializationType(
                        ElaboratedTypeKeyword Keyword,
                        NestedNameSpecifier *NNS, const IdentifierInfo *Name,
                        unsigned NumArgs, const TemplateArgument *Args,
                        QualType Canon)
 : TypeWithKeyword(Keyword, DependentTemplateSpecialization, Canon, true, true,
                   /*VariablyModified=*/false,
                   NNS && NNS->containsUnexpandedParameterPack()),
   NNS(NNS), Name(Name), NumArgs(NumArgs) {
 assert((!NNS || NNS->isDependent()) &&
        "DependentTemplateSpecializatonType requires dependent qualifier");
 for (unsigned I = 0; I != NumArgs; ++I) {
   if (Args[I].containsUnexpandedParameterPack())
     setContainsUnexpandedParameterPack();

   new (&getArgBuffer()[I]) TemplateArgument(Args[I]);
 }
}

The failing code is for the "placement new" in the loop:

A) &getArgBuffer()[I] is not always an address for which the vst1.64 instruction gets an aligned address.

but. . .

B) TemplateArgument(Args[I])'s copy construction activity has code (such as the vst1.64) requiring a specific alignment when SCTLR bit[1]==1.

C) Nothing here has any explicitly packed data structures.

As for (A):

class DependentTemplateSpecializationType :
 public TypeWithKeyword, public llvm::FoldingSetNode {
. . .
 const TemplateArgument *getArgBuffer() const {
   return reinterpret_cast<const TemplateArgument*>(this+1);
 }
 TemplateArgument *getArgBuffer() {
   return reinterpret_cast<TemplateArgument*>(this+1);
 }

clang++ is over-allocating the space for the DependentTemplateSpecializationType objects and using the extra space that is afterwards to hold (a somewhat C-style array of) TemplateArgument instances. But the logic for this does nothing explicit about alignment of the TemplateArgument instance pointers, not even partially via explicitly controlling sizeof(DependentTemplateSpecializationType).

sizeof(TemplateArgument) also needs to be controlled in order to have the notation &getArgBuffer()[I] maintain alignment in its results when &getArgBuffer()[0] is well aligned.

The existing code does not explicitly force any specific minimum TemplateArgument alignment, other than 1. (Implicit ABI rules might get some alignment --if some of those rules are being applied.

Separately there is the issue that the code produced did not treat the pointers returned from getArgBuffer() methods as "opaque pointer" examples but they are. Having compiled with -fmax-type-align=4 the code should have not have required 8 byte alignment (vst1.64). It should have produced code that required 4 (or 2 or 1). Quoting for -fmax-type-align=?:

Instruct the code generator to not enforce a higher alignment than the given number (of bytes) when accessing memory via an opaque pointer or reference

Those pointers certainly are opaque and should be treated as such. The "reinterpret_cast" use is a big clue that clang++ should respect.

In other words: I see two clang++ defects in the overall evidence, one of which directly leads to the Bus Errors being possible.
Comment 1 Mark Millard 2015-12-28 12:58:34 UTC
I forgot to include the asked-for stack backtrace and some related information:

Program terminated with signal 10, Bus error.
#0  0x00c404d0 in clang::DependentTemplateSpecializationType::DependentTemplateSpecializationType ()
[New Thread 22a18000 (LWP 100173/<unknown>)]
(gdb) bt
#0  0x00c404d0 in clang::DependentTemplateSpecializationType::DependentTemplateSpecializationType ()
#1  0x00d86634 in clang::ASTContext::getDependentTemplateSpecializationType ()
#2  0x00d865d8 in clang::ASTContext::getDependentTemplateSpecializationType ()
#3  0x00d862d4 in clang::ASTContext::getDependentTemplateSpecializationType ()
#4  0x00553b7c in clang::Sema::ActOnTypenameType ()
#5  0x0040cb68 in clang::Parser::TryAnnotateTypeOrScopeToken ()
#6  0x00471198 in $a.28 ()
#7  0x00471198 in $a.28 ()
(gdb) x/1i 0x00c404d0
0xc404d0 <_ZN5clang35DependentTemplateSpecializationTypeC2ENS_21ElaboratedTypeKeywordEPNS_19NestedNameSpecifierEPKNS_14IdentifierInfoEjPKNS_16TemplateArgumentENS_8QualTypeE+356>:	
  vst1.64	{d16-d17}, [r4]!
(gdb) info all-registers
r0             0xbfbf9778	-1077962888
r1             0x22ac59c4	581720516
r2             0xc45ff8	12869624
r3             0x2	2
r4             0x22ac59ac	581720492
. . .
Comment 2 Mark Millard 2015-12-28 21:07:18 UTC
I've submitted the compiler crash to llmv.org as:

https://llvm.org/bugs/show_bug.cgi?id=25958

It is  basically a duplicate by content of this submittal.
Comment 3 Mark Millard 2015-12-28 23:02:13 UTC
Below is what llvm-org's James Molloy reports about needing -mno-unaligned-access when building clang and clang++ for use in a SCTLR bit[1]==1 context:

From: bugzilla-daemon@llvm.org
Subject: [Bug 25958] FreeBSD 11.0-CURRENT clang++ 3.7.1 gets Bus Errors during compilation on arm that has SCTLR bit[1]==1 (alignment required)
Date: December 28, 2015 at 1:28:28 PM PST
To: <markmi@dsl-only.net>

James Molloy changed bug 25958 
What	Removed	Added
CC	 	james.molloy@arm.com

Comment # 2 on bug 25958 from James Molloy
Hi Mark,

Thanks for raising this. Before checking the specifics of what you found - did
you compile Clang with -mno-unaligned-access? We will by default compile
assuming SCTLR.A is 0. -mno-unaligned-access switches this assumption off and
enables strict alignment mode.

Cheers,

James


More notes:

I've answered with the example compilation command for the specific clang source file, extracted from a script log of my build: I had used -mno-unaligned-access.
Comment 4 Mark Millard 2015-12-30 21:12:14 UTC
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
Comment 5 Mark Millard 2016-01-03 02:30:29 UTC
I reported the following information on the llvm bugzilla:

To get a quick handle on the size of the investigation effort for alignments of reinterpret_casts to pointer types in llvm/clang I've tried to get *approximations* of:

A) count of reinterpret_cast's to pointer types that do not involve base types with "char" or "int8" text (on the same line).

and

B) How many files have such reinterpret_cast's.


# pwd
/usr/src/contrib/llvm

# find -s . -exec grep -E "reinterpret_cast[ \t]*<[^>]*\*" {} \; | grep -v char | grep -v int8 | wc
     789    3453   51918

# find -s . -exec grep -E "reinterpret_cast[ \t]*<[^>]*(char|int8)[^>]*\*" {} \; | wc
     171     854   11326

(Some files may have a mix of both with and without char/int8.)

# find -s . -exec grep -E "reinterpret_cast[ \t]*<[^>]*\*" {} \; -print | grep "^\.\/" | wc
     264     264   10517

# find -s . -exec grep -E "reinterpret_cast[ \t]*<[^>]*(char|int8)[^>]*\*" {} \; -print | grep "^\.\/" | wc
      71      71    2781

(So 264-71==193 to 264 files.)

And also:

C) How many reinterpret_cast's directly involve the text "this" (on the same line):

# find -s . -exec grep -E "reinterpret_cast[ \t]*<[^>]*\*.*this" {} \; | grep -v char | grep -v int8 | wc
     132     739    8443

D) How many files is that?

# find -s . -exec grep -E "reinterpret_cast[ \t]*<[^>]*\*.*this" {} \; -print | grep "^\.\/" | wc
      47      47    1914
# find -s . -exec grep -E "reinterpret_cast[ \t]*<[^>]*(char|int8)[^>]*\*.*this" {} \; -print | grep "^\.\/" | wc
       5       5     185

(So 47-5==42 to 47 files.)

E) How many reinterpret_cast's do not mention "this", "char", or "int8" (on the same line):

# find -s . -exec grep -E "reinterpret_cast[ \t]*<[^>]*\*" {} \; | grep -v this | grep -v char | grep -v int8 | wc
     647    2663   42647

This is the majority of the reinterpret_cast's, by far.

It looks non-trivial to find and adjust the llvm/clang source so that all the places that do not currently deal with proper alignment for SCTLR bit[1]==1 contexts instead do so.

So it is not likely to be happen time soon, much less finish any time soon.

This will limit FreeBSD 11.0's "self hosting on arm" c++ support via the system/clang++ tool chain greatly based on the CTLR bit[1]==1 status: cross builds required from a host not requiring alignment, such as from amd64. (Once some other C++ tool chain is in place on an arm more native work may then be possible.)

The C part of clang does appear to compile okay for buildkernel use in the SCTRL bit[1]==1 context. So far all the misalignments have happened in compiling-c++ contexts, which is involved for buildworld and for building many ports.
Comment 6 Mark Millard 2016-01-05 18:22:42 UTC
llvm.org's Bugzilla reports that clang trunk has been fixed and clang 3.8 will contain the fixes:

James Molloy changed bug 25958 
What	Removed	Added
Status	NEW	RESOLVED
Resolution	---	FIXED
Comment # 8 on bug 25958 from James Molloy
Hi Mark,

Thanks for your detailed investigation. I can confirm that this is fixed on
trunk and therefore will be fixed for LLVM 3.8.

The fixes were done for SPARC, which requires strict accesses much as ARM does
with SCTLR=1.

There was a sequence of commits by James Knight that fixed these, but an
example is http://reviews.llvm.org/rL242554 .

The fixes were in a similar vein to yours, but required changes in fewer places
and there were a few more sticky issues to solve too. I'll CC James here in
case he wants to comment on the current state of the clang codebase for
self-hosting in a strict alignment environment.

Cheers,

James
Comment 7 Mark Millard 2016-06-17 04:10:52 UTC
Clang 3.8.0 does not have this problem.

And also recently 11.0 enabled more misalignments: SCTLR bit[1]==1 is no longer in use.

Clang 3.8.0 was in use  for some time before this change and was not getting bus errors.

3.7.1 is no longer relevant for 11.0.