Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 03 Jan 2016 02:30:29 +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-MT5TMvTy7E@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 #5 from Mark Millard <markmi@dsl-only.net> ---
I reported the following information on the llvm bugzilla:

To get a quick handle on the size of the investigation effort for alignment=
s 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 ty=
pes
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 | g=
rep
"^\.\/" | wc
     264     264   10517

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

(So 264-71=3D=3D193 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" {} \; | gr=
ep
-v char | grep -v int8 | wc
     132     739    8443

D) How many files is that?

# find -s . -exec grep -E "reinterpret_cast[ \t]*<[^>]*\*.*this" {} \; -pri=
nt |
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=3D=3D42 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 t=
he
places that do not currently deal with proper alignment for SCTLR bit[1]=3D=
=3D1
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]=3D=3D1 status: c=
ross
builds required from a host not requiring alignment, such as from amd64. (O=
nce
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]=3D=3D1 context. So far all the misalignments have happened in
compiling-c++ contexts, which is involved for buildworld and for building m=
any
ports.

--=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-MT5TMvTy7E>