Re: Clang 6.0.[01]: UNREACHABLE executed

2018-07-13 Thread Dimitry Andric
On 13 Jul 2018, at 18:45, Dimitry Andric  wrote:
> 
> On 13 Jul 2018, at 14:30, Jonathan Anderson  wrote:
>> 
>> I recently ran into an unreachable statement execution in Clang 6, both
>> with v6.0.0 from the llvm60 package and v6.0.1 from HEAD (FreeBSD
>> r335799 / LLVM r335540). I don't see this issue in Clang 5 or in the
>> version that ships with macOS High Sierra (which they're calling 9.1.0,
>> but that's apparently more of a "marketing version" than a true version
>> number).
>> 
>> creduce managed to shrink my 2.8 MiB preprocessed sources down to a 604
>> B test case:
>> 
>> https://gist.github.com/trombonehero/2da555bd1292be973f9d14c843c56ae5
>> 
>> This isn't a valid C++ file (e.g., it cuts off after `return o` on line
>> 23), but I would expect it to cause compiler errors rather than a
>> compiler crash. You can see the output from the crash at:
>> 
>> https://gist.github.com/trombonehero/8fce4a8f39ae121a2f9f14b45b0b65a1
>> 
>> Any thoughts?
> 
> It doesn't crash for me, at least not with the command line you provided
> in the gist.

Ah, I had a clang without assertions, but with assertions enabled, it
indeed results in:

Invalid operator call kind
UNREACHABLE executed at 
/usr/src/contrib/llvm/tools/clang/lib/AST/StmtProfile.cpp:1250!
Abort trap

This looks very much like https://bugs.llvm.org/show_bug.cgi?id=28793,
which is also something about a lamdba function with an invalid or
incomplete syntax.

I will dig a bit further; if it is the same bug, and reproduces with
clang trunk, I can bump the upstream bug, and/or ping a few people that
might be able to fix it.

-Dimitry



signature.asc
Description: Message signed with OpenPGP


Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3

2018-07-13 Thread Mark Millard via freebsd-toolchain



On 2018-Jul-13, at 3:15 AM, tech-lists  wrote:

> On 12/07/2018 19:32, Dimitry Andric wrote:
>> No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes
>> , an intrinsics header, which in turn requires .
>> This was introduced inhttps://svnweb.freebsd.org/changeset/base/308921,
>> and at the time resulted in similar build failures, specifically when
>> one attempted to build a new kernel, without building world or a new
>> toolchain first.
> 
> Hi,
> 
> Ok, it's finished building and installing. The command I used was this:
> 
> # make -j10 buildworld && make -j10 buildkernel KERNCONF=RPI3

make -j10 buildworld buildkernel KERNCONF=RPI3

would have worked.

> and it all built, (so I'll close the PR I opened). Then I did make 
> installkernel KERNCONF=RPI3 and because I thought might as well install 
> everything now it's built, mergemaster -p and make installworld && 
> mergemaster -Ui.
> 
> So I take it then, that every time I want to build a kernel, I either have to 
> do the above or use make kernel-toolchain. Is this correct?

If you first clear out the old build, then such would be true.
(Where, for targeting aarch64, kernel-toolchain needs to be
avoided.)

But you can buildkernel using the results of the existing
buildworld (or kernel-toolchain if it applies) when it is
okay to not clear out the old build first. (kernel
developers doing kernel development likely do this a lot.)

Another way to make tradeoffs is to use META_MODE so that
partial rebuilds are done, avoiding some of the strictly
unnecessary rebuild activity. This would involve
buildworld or kernel-toolchain (as appropriate for the
target architecture).


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
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"


Clang 6.0.[01]: UNREACHABLE executed

2018-07-13 Thread Jonathan Anderson
Hi all,

I recently ran into an unreachable statement execution in Clang 6, both
with v6.0.0 from the llvm60 package and v6.0.1 from HEAD (FreeBSD
r335799 / LLVM r335540). I don't see this issue in Clang 5 or in the
version that ships with macOS High Sierra (which they're calling 9.1.0,
but that's apparently more of a "marketing version" than a true version
number).

creduce managed to shrink my 2.8 MiB preprocessed sources down to a 604
B test case:

https://gist.github.com/trombonehero/2da555bd1292be973f9d14c843c56ae5

This isn't a valid C++ file (e.g., it cuts off after `return o` on line
23), but I would expect it to cause compiler errors rather than a
compiler crash. You can see the output from the crash at:

https://gist.github.com/trombonehero/8fce4a8f39ae121a2f9f14b45b0b65a1

Any thoughts?


Jonathan Anderson
--
jonat...@freebsd.org
___
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: aarch64-arm64 fails to build kernel 12-current raspberry pi 3

2018-07-13 Thread tech-lists

On 12/07/2018 19:32, Dimitry Andric wrote:

No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes
, an intrinsics header, which in turn requires .

This was introduced inhttps://svnweb.freebsd.org/changeset/base/308921,
and at the time resulted in similar build failures, specifically when
one attempted to build a new kernel, without building world or a new
toolchain first.


Hi,

Ok, it's finished building and installing. The command I used was this:

# make -j10 buildworld && make -j10 buildkernel KERNCONF=RPI3

and it all built, (so I'll close the PR I opened). Then I did make 
installkernel KERNCONF=RPI3 and because I thought might as well install 
everything now it's built, mergemaster -p and make installworld && 
mergemaster -Ui.


So I take it then, that every time I want to build a kernel, I either 
have to do the above or use make kernel-toolchain. Is this correct?


thanks,
--
J.
___
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"