llvm dev - Feb 2017 - this ir code segfaults llvm in trunk

https://is.gd/PrmYlA

clang-4.0: error: unable to execute command: Segmentation fault (core
dumped)
clang-4.0: error: clang frontend command failed due to signal (use -v to
see invocation)
clang version 4.0.0 (trunk 291576)
Target: armv7
Thread model: posix
InstalledDir: /opt/compiler-explorer/clang-trunk/bin
clang-4.0: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source,
and associated run script.
clang-4.0: note: diagnostic msg: Error generating preprocessed source(s) -
no preprocessable inputs.
Compiler exited with result code 254
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170206/ce955859/attachment-0001.html>

On Mon, Feb 06, 2017 at 02:41:47AM -0500, Andrew Kelley via llvm-dev
wrote:
> https://is.gd/PrmYlA
> 
> clang-4.0: error: unable to execute command: Segmentation fault (core
> dumped)
> clang-4.0: error: clang frontend command failed due to signal (use -v to
> see invocation)
> clang version 4.0.0 (trunk 291576)
I can't reproduce it with r292463 from the 4.0 release branch.
Please don't post files on third party sites, it breaks the mail
archive.

Joerg

On 5 February 2017 at 23:41, Andrew Kelley via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Target: armv7
On a debug compiler it looks like only x86 supports "coldcc" so you
need to either implement ARM support or stop using that.

Cheers.

Tim.

On 6 February 2017 at 09:36, Tim Northover <t.p.northover at gmail.com>
wrote:
> On 5 February 2017 at 23:41, Andrew Kelley via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Target: armv7
>
> On a debug compiler it looks like only x86 supports "coldcc" so
you
> need to either implement ARM support or stop using that.
Oh, and I noticed you're targeting "armv8" in the actual .ll file.
That's actually 32-bit ARM, which *may* be what you intended (RPi3 is
a 64-bit v8 CPU but their provided OS runs in 32-bit mode for example)
but is slightly odd.

What you probably want is a full triple (specifying a sane ABI as
well), in Thumb mode if you really do want 32-bit code. One of these
for example:

  + aarch64-linux-gnu (64-bit mode).
  + thumbv8-linux-gnueabihf (32-bit mode).

Even if you're not actually targeting Linux, those make for a
known-sane starting point for ELF-based code.

Cheers.

Tim.

On Mon, Feb 6, 2017 at 12:36 PM, Tim Northover <t.p.northover at
gmail.com>
wrote:
> On 5 February 2017 at 23:41, Andrew Kelley via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Target: armv7
>
> On a debug compiler it looks like only x86 supports "coldcc" so
you
> need to either implement ARM support or stop using that.
>
Thanks Tim and apologies for my sloppy bug report.

Here is the text from the language reference
<http://llvm.org/docs/LangRef.html#calling-conventions>:

“coldcc” - The cold calling convention
This calling convention attempts to make code in the caller as efficient as
possible under the assumption that the call is not commonly executed. As
such, these calls often preserve all registers so that the call does not
break any live ranges in the caller side. This calling convention does not
support varargs and requires the prototype of all callees to exactly match
the prototype of the function definition. Furthermore the inliner doesn’t
consider such function calls for inlining.

The phrasing of "attempts", "often", and the fact that it
provides hints to
the inliner makes it sound like coldcc is:

 * useful for optimization purposes regardless of an ABI
 * not necessarily the same ABI on every target - and some ABI will be
chosen even if it is just the c calling convention
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170206/de5b7a0e/attachment.html>