On powerpc64 10.1-STABLE portmaster indirectly building devel/powerpc64-gcc fails

2015-01-28 Thread Mark Millard
to make the kernel more aggressive about RPMs for cooling. I move the SSD between G5's and so it is just part of my general builds for now.) === Mark Millard mar...@dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman

contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h's IntrusiveRefCntPtr and its use violates C++ privacy rules

2015-03-14 Thread Mark Millard
... IntrusiveRefCntPtrExternalSemaSource clang::createChainedIncludesSource( CompilerInstance CI, IntrusiveRefCntPtrExternalSemaSource Reader) { ... IntrusiveRefCntPtrChainedIncludesSource source(new ChainedIncludesSource()); ... return source; } === Mark Millard markmi at dsl-only.net

powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared

2015-03-16 Thread Mark Millard
: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=clang-cpp #CC=clang #CXX=clang++ WRKDIRPREFIX=/usr/obj/portswork #WITH_DEBUG= MALLOC_PRODUCTION= === Mark

powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project)

2015-03-16 Thread Mark Millard
: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=clang-cpp #CC=clang #CXX=clang++ WRKDIRPREFIX=/usr/obj/portswork #WITH_DEBUG= MALLOC_PRODUCTION= === Mark Millard markmi at dsl-only.net

Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared

2015-03-16 Thread Mark Millard
Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, Mark Millard markmi at dsl-only.net wrote: Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 19:23:14 PDT

powerpc64-xtoolchain-gcc (gcc 4.9.1) reports: /usr/srcC/lib/libnv/tests/dnv_tests.cc:453:2: error: ambiguous overload

2015-03-16 Thread Mark Millard
by Dimitry Andric: this hack is not appropriate to the FreeBSD code base since it would only set up -std=c++11 for clang contexts were CXXFLAGS+=${CXXFLAGS.${COMPILER_TYPE}} was also in use. === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain

Re: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists

2015-03-16 Thread Mark Millard
} .endfor I've reverted to trying CROSS_TOOLCHAIN=powerpc64-gcc using WITHOUT_CLANG_BOOTSTRAP= and WITHOUT_CLANG= since even without the -std=c++11 issue (via my experiment) it tries gcc 4.2.1 for compiling part of clang during stage 1.2 --and that fails. === Mark Millard markmi at dsl-only.net

Re: powerpc64-xtoolchain-gcc (gcc 4.9.1) reports: /usr/srcC/lib/libnv/tests/dnv_tests.cc:453:2: error: ambiguous overload

2015-03-16 Thread Mark Millard
. === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project)

2015-03-17 Thread Mark Millard
of only cstdio where an include of stdio.h would be required to be involved in order to guarantee the :: (global) declaration/definition. The way the C++ standard (all vintages) is written gcc 4.8.4 and gcc5 could be this different and both be valid/conforming.) === Mark Millard markmi at dsl

Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared

2015-03-16 Thread Mark Millard
is on the folks including the headers. Otherwise just because it works in one valid toolchain does not mean it is guaranteed to work in another valid one. gcc5 may well provide fewer of the optional declarations/definitions for some headers. === Mark Millard markmi at dsl-only.net On 2015

Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared

2015-03-17 Thread Mark Millard
included. We will see what that shows. === Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 10:36 PM, Mark Millard markmi at dsl-only.net wrote: The last powerpc (non-64) build test to complete ran where only built-in-world compilers originally existed (gcc 4.2.1 and clang 3.4.1

Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared

2015-03-17 Thread Mark Millard
that guarantees to declare/define ::sscanf. But it should. An alternative to the #include is to instead use std::sscanf notation. That will be the next experiment to check if cstdio had been included somewhere or not. It might be that neither header had been included. === Mark Millard markmi

Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project)

2015-03-17 Thread Mark Millard
', + 'powerpc' : 'PowerPC', ++ 'powerpc64' : 'PowerPC', + 'sparc64' : 'Sparc', + 'x86' : 'X86', 'x86_64' : 'X86', === Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 11:00 PM

Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared

2015-03-17 Thread Mark Millard
/ErrorHandling.h #include llvm/Support/FileSystem.h #include llvm/Support/Process.h #include stdio.h // Include the necessary headers to interface with the Windows registry and // environment. ... === Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 10:57 AM, Mark Millard markmi at dsl-only.net

Re: powerpc64 11.0-CURRENT: CROSS_TOOLCHAIN=powerpc64-gcc rejects -m elf32ppc_fbsd for linking boot1.elf

2015-03-18 Thread Mark Millard
../Makefile.inc === Mark Millard markmi at dsl-only.net On 2015-Mar-18, at 02:38 PM, Mark Millard markmi at dsl-only.net wrote: Basic context (more details given later): # freebsd-version -ku; uname -apKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0

On using powerpc64-xtoolchain-gcc for buildworld buildkernel on a powerpc64 11.0-CURRENT -r279514 variant

2015-03-18 Thread Mark Millard
/local/bin/clang36 #CXX=/usr/local/bin/clang++36 WRKDIRPREFIX=/usr/obj/portswork #WITH_DEBUG= MALLOC_PRODUCTION= === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd

Re: On using powerpc64-xtoolchain-gcc for buildworld buildkernel on a powerpc64 11.0-CURRENT -r279514 variant

2015-03-19 Thread Mark Millard
Millard markmi at dsl-only.net On 2015-Mar-18, at 09:28 PM, Mark Millard markmi at dsl-only.net wrote: Basic starting context: # freebsd-version -ku; uname -apKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 19:23:14 PDT 2015 root

lib/csu/powerpc64/ requires/uses gcc command; does not use CC, XCC, or the like; its Makefile explains what caused the choice...

2015-03-19 Thread Mark Millard
WITH_GCC_BOOTSTRAP= and WITH_GCC= and WITH_GNUCXX= but avoiding their use. === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail

powerpc64 11.0-CURRENT CROSS_TOOLSCHAIN=powerpc64-gcc when building with WITH_CLANG= defined: include/c++/v1/ problems...

2015-03-20 Thread Mark Millard
and complete via postmaster with -C (as long as powerpc64-gcc was not in use rebuilding itself: some other compiler was in use for that activity instead). === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list http

powerpc64 context for clang36 use: /usr/bin/ld too old(?) but is used by clang36

2015-03-21 Thread Mark Millard
Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) # more /etc/make.conf WRKDIRPREFIX=/usr/obj/portswork #WITH_DEBUG= MALLOC_PRODUCTION= === Mark Millard markmi at dsl-only.net

11.0-CURRENT -r276514's ncurses .vs gcc5-based buildworld: the generated lib_gen.c has problems

2015-03-22 Thread Mark Millard
-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) === Mark Millard markmi at dsl-only.net

powerpc64 11.0-CURRENT CROSS_TOOLSCHAIN=powerpc64-gcc: -pg compile gets ../libcxxrt/terminate.cc:36:7: internal compiler error: Segmentation fault

2015-03-20 Thread Mark Millard
into staging. I copied appropriate files to the missing names and place and from that status the installation was able to continue and complete via postmaster with -C (as long as powerpc64-gcc was not in use rebuilding itself: some other compiler was in use for that activity instead). === Mark Millard

Re: powerpc64 10.1-STABLE [WITH_DEBUG] context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it

2015-03-09 Thread Mark Millard
+0xa8 lwz r0,1(r1) === Mark Millard markmi at dsl-only.net On 2015-Mar-8, at 06:35 PM, Mark Millard markmi at dsl-only.net wrote: Thanks for the note. It is useful to know the variation from my context. You were not explicit but because you mention POWER8 I'd guess that you were

powerpc/powerpc64 11.0-CURRENT not building clang by default: src.opt.mk not equivalent to 10.1-STABLE bsd.own.mk on the issue

2015-03-12 Thread Mark Millard
.endif .else # If clang is not cc, then build gcc by default __DEFAULT_NO_OPTIONS+=CLANG_IS_CC __DEFAULT_YES_OPTIONS+=GCC # And if g++ is c++, build the rest of the GNU C++ stack .if defined(WITHOUT_CXX) __DEFAULT_NO_OPTIONS+=GNUCXX .else __DEFAULT_YES_OPTIONS+=GNUCXX .endif .endif === Mark Millard

powerpc/powerpc64 11.0-CURRENT not building clang by default: src.opt.mk not equivalent to 10.1-STABLE bsd.own.mk on the issue

2015-03-12 Thread Mark Millard
.endif .else # If clang is not cc, then build gcc by default __DEFAULT_NO_OPTIONS+=CLANG_IS_CC __DEFAULT_YES_OPTIONS+=GCC # And if g++ is c++, build the rest of the GNU C++ stack .if defined(WITHOUT_CXX) __DEFAULT_NO_OPTIONS+=GNUCXX .else __DEFAULT_YES_OPTIONS+=GNUCXX .endif .endif === Mark Millard

powerpc (non-64) 10.1-STABLE context: CXXLD mesa_dri_drivers.la gets c++: Internal error: Segmentation fault (program ld)

2015-03-08 Thread Mark Millard
|x86_64|amd64|' \ ${WRKSRC}/configure === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain

Re: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists

2015-03-13 Thread Mark Millard
for powerpc64-xtoolchain-gcc. === Mark Millard markmi at dsl-only.net On 2015-Mar-12, at 03:13 PM, Mark Millard markmi at dsl-only.net wrote: Warner wrote: Is cc1plus the g++ compiler that is installed on your bootstrapped system, or is it the one that the powerpc64-gcc toolchain built? cc1plus -v

Re: powerpc64 10.1-STABLE [WITH_DEBUG] context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it

2015-03-10 Thread Mark Millard
on _get_stl_prime_list.) Once propagated the updates will make KWSys and CMake's code again match in this area. So eventually FreeBSD should pick up a fix that should allow WITH_DEBUG= to be better behaved for CMake's programs that use it's hashtable.hxx . === Mark Millard markmi at dsl-only.net On 2015-Mar-9

Re: powerpc/powerpc64 11.0-CURRENT not building clang by default: src.opt.mk not equivalent to 10.1-STABLE bsd.own.mk on the issue

2015-03-12 Thread Mark Millard
. powerpc64 10.1-STABLE had no such problems building and installing those two libraries. === Mark Millard markmi at dsl-only.net On 2015-Mar-12, at 10:01 AM, Mark Millard markmi at dsl-only.net wrote: Well there is an entry but when I read it I did not find it clear about the 10.x status. I think

Re: powerpc/powerpc64 11.0-CURRENT not building clang by default: src.opt.mk not equivalent to 10.1-STABLE bsd.own.mk on the issue

2015-03-12 Thread Mark Millard
++ will not be enabled by default, so libc++ should be built (with clang) and installed first. If both clang and libc++ are missing, build clang first, then use it to build libc++. === Mark Millard mar...@dsl-only.net On 2015-Mar-12, at 05:00 AM, Warner Losh i...@bsdimp.com wrote: On Mar 12, 2015

On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists

2015-03-12 Thread Mark Millard
. === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

Re: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists

2015-03-12 Thread Mark Millard
. ^C $ /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus -std=c++11 ^C $ /usr/libexec/cc1plus -std=c++11 cc1plus: error: unrecognized command line option -std=c++11 ^C === Mark Millard markmi at dsl-only.net On 2015-Mar-12, at 02:33 PM, Warner Losh imp at bsdimp.com wrote

Trying to bootstrap libc++ from 11.0-CURRENT with clang 3.4.1 still around from 10.1-STABLE: ld unable to build shared library libcxxrt.so.1

2015-03-12 Thread Mark Millard
= #WITHOUT_CLANG === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

FYI: Things that I've noticed for powerpc64-xtoolchain-gcc...

2015-03-29 Thread Mark Millard
procedure that avoided backtracking, pondering, retries, and so on. In some respects I've been lucky that certain types of changes did not happen between my original and upgraded vintages: things would not have worked that did work. === Mark Millard markmi at dsl-only.net

CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import

2015-03-22 Thread Mark Millard
is if it is simple but each version/variant needs to release with the change. === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd

Fwd: 11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c -r279859 vs. updating to head snaphot -r280598

2015-03-27 Thread Mark Millard
=== Mark Millard markmi at dsl-only.net Begin forwarded message: From: Mark Millard markmi at dsl-only.net Subject: 11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c -r279859 vs. updating to head snaphot -r280598 Date: 2015-March-26 at 07:36:01 PM PDT Cc: FreeBSD PowerPC ML freebsd

Fwd: 11.0-CURRENT: SBUF_INCLUDENUL, /head/sys/kern/subr_sbuf.c -r280193 vs. updating to head snaphot -r280598

2015-03-27 Thread Mark Millard
anything about the xtoolchain stuff. In any case, there doesn't seem to be anything wrong with the base build using the supported build mechanisms. === Mark Millard markmi at dsl-only.net Begin forwarded message: Subject: 11.0-CURRENT: SBUF_INCLUDENUL, /head/sys/kern/subr_sbuf.c -r280193 vs

Re: powerpc64 10.1-STABLE [WITH_DEBUG] context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it

2015-03-18 Thread Mark Millard
: KWSys 2015-03-10 (4a698414) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9a427f86 Merge branch 'upstream-kwsys' into update-kwsys http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e433223d -Brad === Mark Millard markmi at dsl-only.net On 2015-Mar-10, at 01:11 PM, Mark Millard

Re: On powerpc64 10.1-STABLE portmaster indirectly building devel/powerpc64-gcc fails

2015-01-29 Thread Mark Millard
them means the experiment has provided a useful result already. === Mark Millard markmi at dsl-only.net On 2015-Jan-29, at 04:56 PM, Baptiste Daroussin bapt at FreeBSD.org wrote: On Wed, Jan 28, 2015 at 04:30:14PM -0800, Mark Millard wrote: I tried to portmaster devel/powerpc64-xtoolchain-gcc

Re: Shorter report: powerpc64-xtoolchain-gcc use fails from powerpc (non-64)

2015-04-01 Thread Mark Millard
[I've omitted history going in a different direction than this note.] On 2015-Apr-1, at 02:49 PM, Warner Losh imp at bsdimp.com wrote: On Apr 1, 2015, at 4:37 PM, Mark Millard mar...@dsl-only.net wrote: From a powerpc (non-64) 11.0-CURRENT boot is the following supposed to work

Re: Shorter version: -m elf32ppc_fbsd (and elf_i386_fbsd ?) vs. -Wl, -m, elf32ppc_fbsd problems (11.0-CURRENT and 10.1-STABLE)

2015-04-18 Thread Mark Millard
(revision 281630) +++ sys/boot/uboot/Makefile.inc (working copy) @@ -2,7 +2,7 @@ .if ${MACHINE_ARCH} == powerpc64 CFLAGS+= -m32 -mcpu=powerpc -LDFLAGS+= -m elf32ppc_fbsd +LDFLAGS+= -Wl,-m -Wl,elf32ppc_fbsd .endif .include ../Makefile.inc === Mark Millard markmi at dsl-only.net

Re: gcc-4.9.1/gcc/config/rs6000/freebsd64.h vs. FreeBSD's powerpc (non-64) L... and wchar_t (other gcc ports too?)

2015-04-18 Thread Mark Millard
in a way that neither the system nor the port gdb can report on where. For now it looks like I'm not going to have the time to work on figuring out any of the issues involved. === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org

Re: powerpc64-xtoolchain-gcc/powerpc64-gcc gets libcxxrt/guard.cc:104:15: error: expected constructor, destructor, . . . for lib32 (clang 3.6.1 context)

2015-10-14 Thread Mark Millard
David Chisnall wrote (Mon Oct 12 08:21:28 UTC 2015): > On 12 Oct 2015, at 03:17, Mark Millard wrote: > > > > /usr/src/lib/libcxxrt/../../contrib/libcxxrt/guard.cc:104:15: error: > > expected constructor, destructor, or type conversion before '(' token > > _S

powerpc64-xtoolchain-gcc gets ". . . include/c++/v1/utility:284:28: error: use of deleted function . . ." (llvm-cov 3.6.1's CodeCoverage.cpp)

2015-10-11 Thread Mark Millard
PE:=gcc +#CC:= gcc +#COMPILER_TYPE:= gcc FILES= ${OBJS} FILESMODE= ${LIBMODE} === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebs

powerpc64-xtoolchain/powerpc64-gcc lacks lib32 support, so fails boot1.elf link (for example)

2015-10-09 Thread Mark Millard
xed ld, this can be revisited. -CC:= gcc -COMPILER_TYPE:=gcc +#CC:= gcc +#COMPILER_TYPE:= gcc FILES= ${OBJS} FILESMODE= ${LIBMODE} === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org m

bt_split.c error: dereferencing type-punned pointer will break strict-aliasing rules (powerpc64-xtoolchain use)

2015-10-04 Thread Mark Millard
mpiled with gcc. Once # clang supports -mlongcall, or we get a fixed ld, this can be revisited. -CC:= gcc -COMPILER_TYPE:=gcc +CC?= $(XCC) +#COMPILER_TYPE:= gcc FILES= ${OBJS} FILESMODE= ${LIBMODE} === Mark Millard markmi at dsl-on

Re: bt_split.c error: dereferencing type-punned pointer will break strict-aliasing rules (powerpc64-xtoolchain use)

2015-10-04 Thread Mark Millard
I should have also reported as context details what does not exist: /etc/make.conf and /etc/src.conf do not even exist and so do not contribute anything. The original message follows. === Mark Millard markmi at dsl-only.net On 2015-Oct-4, at 04:06 AM, Mark Millard <mar...@dsl-only.net>

svn commit: r291739 - head/share/mk vs. /usr/src/lib/libc/tests/ssp for powerpc64/gcc builds

2015-12-03 Thread Mark Millard
tests/ssp: Invalid LIBADD used which may need to be added > to src.libnames.mk: > ssp via head/lib/libc/tests/ssp/Makefile having: > .elif ${COMPILER_TYPE} == "gcc" > CFLAGS.h_raw+= --param ssp-buffer-size=1 > LIBADD+=ssp &

11.0-CURRENT (on powerpc64) WITH_CCACHE_BUILD= : example failure

2015-12-06 Thread Mark Millard
ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 402906 > Node Kind: directory > Schedule: normal > Last Changed Author: wen > Last Changed Rev: 402906 > Last Changed Date: 2015-12-03 18:06:07 -0800 (Thu, 03 Dec 2015) === Mark Millard markmi a

Re: 11.0-CURRENT (on powerpc64) WITH_CCACHE_BUILD= : example failure

2015-12-06 Thread Mark Millard
I'm adding a note about the missing "\" being just an E-mail editing error, not an original command error. . . On 2015-Dec-6, at 8:32 AM, Mark Millard <mar...@dsl-only.net> wrote: > Mostly just an FYI: This means that for my own purposes I'll tend to avoid > WITH

Re: powerpc64-gcc 5.2 vintages get L". . ." type wrong compared to Char for FreeBSD for lib32 compiling

2015-12-09 Thread Mark Millard
if such a build actually works for installworld and reboot.)] > On 2015-Dec-6, at 2:44 PM, Andreas Tobler <andreast-l...@fgznet.ch> wrote: > > On 06.12.15 22:34, Mark Millard wrote: >> [I picked the lists that I did because powerpc64-gcc is the external >> toolchain created to al

bug 205183: powerpc64's 11.0-CURRENT clang 3.7 crashes compiling atf-check.cpp during buildworld

2015-12-10 Thread Mark Millard
atus might need to change if others also see the crash. In my context it is reproducible. === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe

Re: powerpc64 11.0-CURRENT's clang binds -m32 -mcpu=powerpc a.out to /libexec/ld-elf.so.1

2015-12-15 Thread Mark Millard
On 2015-Dec-15, at 4:36 AM, Konstantin Belousov <kostik...@gmail.com> wrote: > On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wrote: > . . . >> By contrast powerpc64-gcc binds the a.out produced to /libexec/ld-elf32.so.1 >> instead: >> >> # ls -l `whi

Re: 11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix

2015-12-15 Thread Mark Millard
On 2015-Dec-15, at 10:37 AM, Bryan Drewery <bdrew...@freebsd.org> wrote: > > On 12/8/15 2:14 PM, Bryan Drewery wrote: >> On 12/7/15 1:33 PM, Mark Millard wrote: >>> >>>> On 2015-Dec-7, at 12:48 PM, Simon J. Gerraty <s...@juniper.net> wrote: >&g

powerpc64 11.0-CURRENT's clang binds -m32 -mcpu=powerpc a.out to /libexec/ld-elf.so.1

2015-12-14 Thread Mark Millard
vel . . . === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

11.0-CURRENT Bug 205904 "unresolvable R_ARM_MOVW_ABS_NC relocation" vs. forced -fPIC use

2016-01-04 Thread Mark Millard
things after Ian Lepore's -r292964 for the /usr/bin/ binutils. I picked on textproc/expat2 initially as something fairly simple and limited to C. (clang++ has problems under SCTLR bit[1]==1 [alignment required] on arm that make clang++ Bus Error during most C++ compiles). === Mark Millard mark

Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

2016-01-05 Thread Mark Millard
=== Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

2016-01-08 Thread Mark Millard
g/../../../lib/clang/libllvmsupport/libllvmsupport.a > -lz -lncursesw -lpthread > FreeBSD clang version 3.8.0 (trunk 256945) (based on LLVM 3.8.0svn) > Target: armv6--freebsd11.0-gnueabi > Thread model: posix > InstalledDir: /usr/bin > "/usr/obj/clang/arm.armv6/usr/src/tm

Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error?

2015-12-25 Thread Mark Millard
On 2015-Dec-24, at 10:39 PM, Mark Millard <mar...@dsl-only.net> wrote: > [I do not know if this partial crash analysis related to on-arm > clang-associated activity is good enough and appropriate to submit or not.] > > The /usr/local/arm-gnueabi-freebsd/bin/ar on the rpi2b i

11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error?

2015-12-24 Thread Mark Millard
.0-CURRENT #0 r292413M: Tue Dec 22 > 22:02:21 PST 2015 > root@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG arm 1100091 > 1100091 I will note that world and kernel are my own build of -r292413 (earlier experiment) --a build made from an amd64 host context and put i

Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error?

2015-12-25 Thread Mark Millard
[Good News Summary: Rebuilding buildworld/buildkernel for rpi2 11.0-CURRENT 292413 from amd64 based on adding -fmax-type-align=4 has so far removed the crashes during the toolchain activity: no more misaligned accesses in libc's _fseeko or elsewhere.] On 2015-Dec-25, at 12:31 AM, Mark Millard

Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error?

2015-12-25 Thread Mark Millard
[Good News Summary: Rebuilding buildworld/buildkernel for rpi2 11.0-CURRENT 292413 from amd64 based on adding -fmax-type-align=4 has so far removed the crashes during the toolchain activity: no more misaligned accesses in libc's _fseeko or elsewhere.] On 2015-Dec-25, at 12:31 AM, Mark Millard

Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error?

2015-12-25 Thread Mark Millard
> On 2015-Dec-25, at 3:42 PM, Warner Losh <i...@bsdimp.com> wrote: > > >> On Dec 25, 2015, at 3:14 PM, Mark Millard <mar...@dsl-only.net> wrote: >> >> [I'm going to break much of the earlier "original material" text to tail of >> the mes

Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error?

2015-12-26 Thread Mark Millard
On 2015-Dec-26, at 9:00 AM, Ian Lepore <i...@freebsd.org> wrote: > On Fri, 2015-12-25 at 17:21 -0800, Mark Millard wrote: >> In my view "-mno-unaligned-access" is an even bigger hammer than I >> used. I find no clang statement about what its ABI consequences wou

Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error?

2015-12-25 Thread Mark Millard
have a direct compare and contrast at this point. Older material: On 2015-Dec-25, at 5:21 PM, Mark Millard <mar...@dsl-only.net> wrote: > On 2015-Dec-25, at 3:42 PM, Warner Losh <i...@bsdimp.com> wrote: > > >> On Dec 25, 2015, at 3:14 PM, Mark Millard <mar...@dsl-onl

Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error?

2015-12-28 Thread Mark Millard
h CPUTYPE=armv7a or some such, right? > > Warner > >> On Dec 25, 2015, at 9:32 PM, Mark Millard <mar...@dsl-only.net> wrote: >> >> [I am again breaking off another section of older material.] >> >> Mixed news I'm afraid. >> >> The specific

Re: 11.0-CURRENT (r292413) on a rpi2b: arm-gnueabi-freebsd/bin/ar, _fseeko, and memset vs memory alignment (SCTRL bit[1]=1?): Explains the Bus error?

2015-12-28 Thread Mark Millard
liasing -DLLVM_DEFA > ULT_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-exceptio > ns -fno-rtti -stdlib=libc

llvm.org's James Molloy on the need for -mno-unaligned-access for SCTLR bit[1]==1 arm contexts

2015-12-28 Thread Mark Millard
h -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 === Mark Millard markmi at dsl-only.net ___

Re: head/kerberos5/lib/libkrb5/Makefile vs. it finding /usr/obj/usr/src/tmp/usr/lib/libprivateheimipcc.so

2015-11-24 Thread Mark Millard
On 2015-Nov-24, at 7:49 AM, Mark Millard wrote: > I had been away from the PowerMac's that I have access to for more than 5 > months. When I tried my prior rebuild procedure to get from: > > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD

lang/gcc5 vs. devel/powerpc64-gcc: conflict for /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc-5.2.0

2015-11-28 Thread Mark Millard
-gcc.1.gz > > cp -ax > /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/man1/gcov.1.gz > > /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/man1/powerpc64-portbld-freebsd11.0-gcov.1.gz > > portmaster --no-confirm -CtDK lang/pow

head/kerberos5/lib/libkrb5/ and libhdb/ not looking in /usr/obj/usr/src/tmp/usr/lib/ for linking

2015-11-29 Thread Mark Millard
gt; Revision: 402562 > Node Kind: directory > Schedule: normal > Last Changed Author: rene > Last Changed Rev: 402562 > Last Changed Date: 2015-11-28 15:08:03 -0800 (Sat, 28 Nov 2015) === Mark Millard markmi at dsl-only.net ___ freebs

More 11.0-CURRENT: without adding -lmd linking various programs are getting undefined references

2015-11-29 Thread Mark Millard
d.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 402562 > Node Kind: directory > Schedule: normal > Last Changed Author: rene > Last Changed Rev: 402562 > Last

11.0-CURRENT powerpc64 cont'd: without adding to LIBADD linking various programs are getting undefined references

2015-11-29 Thread Mark Millard
bj/usr/src/tmp/usr/include/. > -I/usr/obj/usr/src/tmp/usr/include/c++/v1/. -I/usr/include/c++/v1/. > L/usr/obj/usr/src/tmp/usr/lib/lib32/. > CFLAGS+=-isystem /usr/obj/usr/src/tmp/usr/include/. > -L/usr/obj/usr/src/tmp/usr/lib/. -L/usr/obj/usr/src/tmp/lib/. > LDFLAGS+=-L/usr/obj/usr/src

Re: 11.0-CURRENT powerpc64 cont'd: without adding to LIBADD linking various programs are getting undefined references

2015-11-29 Thread Mark Millard
rc/tmp/usr/include/c++/v1/. -I/usr/include/c++/v1/. > L/usr/obj/usr/src/tmp/usr/lib/lib32/. > CFLAGS+=-isystem /usr/obj/usr/src/tmp/usr/include/. > -L/usr/obj/usr/src/tmp/usr/lib/. -L/usr/obj/usr/src/tmp/lib/. > LDFLAGS+=-L/usr/obj/usr/src/tmp/usr/lib/. -L/usr/obj/usr/src/tmp/lib/. > CX

- j 6 buildworld: -lcapsicum use before libcapsicum.so.0 /usr/obj/usr/src/tmp/lib/ install

2015-11-29 Thread Mark Millard
tps://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 402562 > Node Kind: directory > Schedule: normal > Last Changed Author: rene > Last

Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

2016-01-11 Thread Mark Millard
On 2016-Jan-10, at 9:59 AM, Mark Millard wrote: > > [A top post of my so far successful experiment. . .] > > amd64 -> rpi2 cross build: buildworld buildkernel installkernel installworld > mergemaster delete-old then boot the result on an rpi2 worked ( -march=armv7a > -m

Re: lang/gcc6 (as of /usr/ports -r416711) does not build on 11.0 -r301815 on an rpi2 [armv7-a, cortex-a7]: a.out uses VFP register arguments, . . . does not

2016-06-12 Thread Mark Millard
On 2016-Jun-12, at 5:43 PM, Mark Millard wrote: > Just a quick top-posted note: lang/gcc5 (as of /usr/ports -r416711) built > fine, unlike the lang/gcc6 noted before/below. [I happened to try lang/gcc5 > with the bootstrap configuration item disabled.] > > I may try lang/gc

lang/gcc6 (as of /usr/ports -r416711) does not build on 11.0 -r301815 on an rpi2 [armv7-a, cortex-a7]: a.out uses VFP register arguments, . . . does not

2016-06-12 Thread Mark Millard
TH_CLANG_BOOTSTRAP= > WITH_CLANG= > WITH_CLANG_IS_CC= > WITH_CLANG_FULL= > WITH_CLANG_EXTRAS= > WITH_LLDB= > # > WITH_BOOT= > WITHOUT_LIB32= > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP= > WITHOUT_GCC_BOOTSTRAP= > WITHOUT_GCC= > WITHOUT_GCC_IS_CC= > WITHOUT_GNUCXX= > # >

Re: lang/gcc6 (as of /usr/ports -r416711) does not build on 11.0 -r301815 on an rpi2 [armv7-a, cortex-a7]: a.out uses VFP register arguments, . . . does not

2016-06-12 Thread Mark Millard
Just a quick top-posted note: lang/gcc5 (as of /usr/ports -r416711) built fine, unlike the lang/gcc6 noted before/below. [I happened to try lang/gcc5 with the bootstrap configuration item disabled.] I may try lang/gcc6-devel to see what it does. === Mark Millard markmi at dsl-only.net On 2016

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-05-27 Thread Mark Millard
On 2016-May-27, at 7:04 PM, Mark Millard wrote: > FYI. . . > > I expect that building gcc49 with: > > + --with-local-prefix=/usr \ > > will help with system build activities via gcc49/g++49 by avoiding > /usr/local/include interfering. > > But I

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-05-28 Thread Mark Millard
c . But I have at times also cross-built from an amd64 FreeBSD context and it also can have the "wrong files for buildworld" problem for /usr/local/include/ in FreeBSD. I've never tried buildworld/buildkernel from a non-FreeBSD context and so have never built devel/powerpc64-gcc or anything

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

2016-05-28 Thread Mark Millard
using C_INCLUDE_PAPTH and CPLUS_INCLUDE_PATH to avoid /usr/local/include based paths from finding files. In part this is because I expect port building problems if I use lang/gcc49 to build ports without lang/gcc49 having /usr/local/include implicitly. I do not use devel/powerpc64-gcc

Re: 11.0-CURRENT: lang/gcc, lang/gcc5, lang/gcc6-devel, lang/llvm38, etc. do not build on/for armv6 (now implicitly hard float)

2016-05-29 Thread Mark Millard
On 2016-May-28, at 9:50 PM, Warner Losh wrote: > On Wed, May 25, 2016 at 10:12 AM, Mark Millard <mar...@dsl-only.net> wrote: >> I'm not sure that Gerald or Brooks were CC'd on a report made to the arm >> list about armv6 builds of gcc and llvm being broken now because

11.0 -r300944 buildworld attempt failed [amd64 targeting powerpc or armv6 via system clang use]

2016-05-30 Thread Mark Millard
[This adds armv6 information to a prior note that was just powerpc based. The powerpc example material is listed first then it is noted that armv6 ended up similar in my attempt.] On 2016-May-29, at 11:32 PM, Mark Millard wrote: > [It may well be that powerpc is not an intended cross comp

11.0 -r300944 buildworld amd64 -> armv6/armv7a cross build: Some XCPP and XCC use without -target specified so it rejects -march=armv7a

2016-05-30 Thread Mark Millard
PE}-freebsd/bin/strings XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # # # From based on clang (via system)... # #COMPILER_TYPE=clang .if ${.MAKE.LEV

Re: 11.0 -r300944 buildworld attempt failed [amd64 targeting powerpc or armv6 via system clang use]

2016-05-30 Thread Mark Millard
On 2016-May-30, at 5:40 PM, Mark Millard wrote: > [This adds armv6 information to a prior note that was just powerpc based. The > powerpc example material is listed first then it is noted that armv6 ended up > similar in my attempt.] > > On 2016-May-29, at 11:32 PM, Mark

Re: xorg broken on Beaglebone black revision 300438 [some armv7 instructions do not match new kernel code?]

2016-05-26 Thread Mark Millard
) & ~3) but for sizeof(*p)==8 the result can be an odd multiple of 4 which would get an "Alignment fault" under "SCTLR.A is 0" for LRDEXD and/or STREXD instructions. (I've not worded the above to be explicit about : (or @) notation use that would have similar issues.) === Mark Millard

Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses]

2016-05-26 Thread Mark Millard
if my archivers/lzo2 submittal in question should survive because of SPARC even if the problem is validated to go away for the updated rpi2 like contexts (with armv7-a/cortex-a7 tailoring possibly involved). I have some other submittals that might face the same type of question. === Mark Millard

Re: 11.0 -r300944 build attempted WITH_META_MODE failed [amd64 targeting powerpc64 via devel/powerpc64-gcc use]

2016-05-30 Thread Mark Millard
On 2016-May-30, at 8:29 AM, Bryan Drewery wrote: > This failure is not likely related to META_MODE. > > I should have mentioned that to enable META_MODE after not having it on > you should do a 'make cleanworld' first. > > On 5/29/2016 9:19 PM, Mark Millard wrote: >>

(beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]

2016-06-21 Thread Mark Millard
pu matter to the code generation and explain my lack of problems. The builds also have INVARIANTS and WITNESS off. === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

2016-01-10 Thread Mark Millard
On 2016-Jan-9, at 10:55 AM, Ian Lepore <i...@freebsd.org> wrote: > > On Sat, 2016-01-09 at 15:03 +0100, Dimitry Andric wrote: >> On 09 Jan 2016, at 04:46, Mark Millard <mar...@dsl-only.net> wrote: >>> >>> On 2016-Jan-7, at 2:57 PM, Dimitry Andric >&

Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

2016-01-10 Thread Mark Millard
-gcc/powerpc64-gcc must be used, even if clang is built. (Last I knew gcc5 variations/vintages would reject some of the WITH_CLANG_EXTRAS= code --but I've not tried based on clang 3.8.0 materials.) === Mark Millard markmi at dsl-only.net On 2016-Jan-10, at 3:55 AM, Mark Millard wrote: > > > On 2016

Re: clang 3.8.0 amd64 targeting powerpc64 accepts -mlong-calls (instead of -mlongcall)

2016-01-15 Thread Mark Millard
On 2016-Jan-15, at 9:08 AM, Roman Divacky wrote: > > On Thu, Jan 14, 2016 at 01:54:06AM -0800, Mark Millard wrote: >> Context: projects/clang380-import based amd64 FreeBSD used to try building >> for powerpc64 >> >> In csu/powerpc64/Makefile I replaced: >&

base/projects/clang3.8.0-import -r294096 buildworld targeting arm (for rpi2): assertion failed

2016-01-15 Thread Mark Millard
nsKDB_TRACE # Print a stack trace for a panic > options DDB # Enable the kernel debugger > > nooptions INVARIANTS # Enable calls of extra sanity > checking > nooptions INVARIANT_SUPPORT # Extra sanity

libstand's -msoft-float use vs. clang 3.8.0 targeting powerpc64: 'not supported for ppc64'

2016-01-14 Thread Mark Millard
clang 3.8.0 on amd64 cross building for powerpc64 stopped in libstand's build based on 'soft float is not supported for ppc64'. Apparently for modern clang -msoft-float is a no-no. === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain

clang 3.8.0 amd64 targeting powerpc64 accepts -mlong-calls (instead of -mlongcall)

2016-01-14 Thread Mark Millard
the slightest complaint about it. (It later reported that 'soft float is not supported for ppc64' from the -msoft-float that is always used for libstand.) === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list https://list

-mllvm -disable-ppc-float-in-variadic=true not recognized by clang 3.8.0; used in kern.mk for TARGET_ARCH=powerpc; more

2016-01-15 Thread Mark Millard
rpc > CFLAGS+=-mlongcall -fno-omit-frame-pointer > .endif results in: > --- depend_subdir_dtrace --- > cc: error: unknown argument: '-mlongcall' . . . > --- depend_subdir_dtrace --- > *** [genassym.o] Error code 1 (no surprise). I stopped experimenting with this

clang -msoft-float for powerpc (ppc32) is very new; powerpc64 (ppc64) does not have it yet

2016-01-17 Thread Mark Millard
-15. The commit for powerpc (non-64) ( http://reviews.llvm.org/rL255515 ) was on 2015-Dec-14. === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe

clang 3.8.0 based powerpc (32 bit) buildworld runs on a PowerMac!

2016-01-19 Thread Mark Millard
I've never manage to get powerpc64-xtoolchain-gcc/powerpc64-gcc to produce working 32-bit code. So I've never gotten this far via that path. === Mark Millard markmi at dsl-only.net ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.o

Re: powerpc (32-bit) clang 3.8.0 vs. gcc 4.2.1 routine preamble mismatches: contributions to SEGV's differences

2016-02-06 Thread Mark Millard
r-address side of the stack. This should still be compatible with gcc 4.2.1 style code, although it "wastes" more bytes temporarily in that context. === Mark Millard markmi at dsl-only.net On 2016-Feb-5, at 1:59 AM, Mark Millard wrote: > > Clang 3.8.0 produced code uses r31 as a fr

  1   2   3   4   5   6   7   >