[llvm-bugs] [Bug 25958] New: FreeBSD 11.0-CURRENT clang++ 3.7.1 gets Bus Errors during compilation on arm that has SCTLR bit[1]==1 (alignment required)
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Dec 28 12:54:50 PST 2015
https://llvm.org/bugs/show_bug.cgi?id=25958
Bug ID: 25958
Summary: FreeBSD 11.0-CURRENT clang++ 3.7.1 gets Bus Errors
during compilation on arm that has SCTLR bit[1]==1
(alignment required)
Product: clang
Version: 3.7
Hardware: Other
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangbugs at nondot.org
Reporter: markmi at dsl-only.net
CC: llvm-bugs at lists.llvm.org
Classification: Unclassified
The program being compiled is all of 11 lines or so:
# 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.
backtraces and such follow. . .
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
. . .
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20151228/2186fbdc/attachment.html>
More information about the llvm-bugs
mailing list