ARM unwinding bug

Hi all,

I’m working on the CoreCLR project, coordinating a community effort to produce an Android port of Microsoft’s open-source version of the CLR. A major part of that is getting everything to run on the ARM32 architecture, which is by far the most common CPU for Android devices.

A couple weeks ago, Ben Pye, a developer working on the ARM32 stuff, found and reported a bug related to incorrect generation of stack unwinding info. ( https://llvm.org/bugs/show_bug.cgi?id=24146 ) Apparently it only occurs under a highly specific set of circumstances, which might look like a minor corner case, except that that just happens to be exactly the configuration needed to build CoreCLR for ARM32. This is a blocking problem for us, and I was just wondering how things are coming on it? Has anyone been looking into this, who might be able to provide some sort of estimate as to what’s going on and when we might expect to see a fix?

I totally understand that sometimes working on a project gets to be more important than talking about it, but it would be nice to at least get some feedback. :slight_smile:

Thanks,

Mason Wheeler

A couple weeks ago, Ben Pye, a developer working on the ARM32 stuff, found
and reported a bug related to incorrect generation of stack unwinding info.
( https://llvm.org/bugs/show_bug.cgi?id=24146 ) Apparently it only occurs
under a highly specific set of circumstances, which might look like a minor
corner case, except that that just happens to be exactly the configuration
needed to build CoreCLR for ARM32.

Hi Mason,

I did see the bug, but I have to say that, as priorities go, that's
way too low on my list to go past the initial look.

I compiled your test on a Cortex-A15 / Linux with Clang-3.8 (trunk)
and GCC 4.8.2 and on both occasions, the program crashes on
_Unwind_VRS_Pop() while stepping.

I, then, left it for the unwinding experts, which I'm not.

This is a blocking problem for us, and I
was just wondering how things are coming on it? Has anyone been looking
into this, who might be able to provide some sort of estimate as to what's
going on and when we might expect to see a fix?

I think you're looking at it from the wrong angle...

I seriously doubt that anyone besides your group will care much about
CLR on Android. So, unless this bug affects other people, not much
will progress without your help.

Posting a bug on bugzilla is the first step. Having a source file,
some command lines to try out and some expected results is the second.
Adding the right people (Anton, me, Logan) is the third step.
Excellent. But it doesn't stop there.

You have to continue to investigate, step through, disassemble, check
the unwind sources, give us some ideas. The closer you get to a
recognisably obvious problem, the easier it will be to get someone
else's attention.

We all got an email from that bug (because you CC us), and we probably
all looked at it and thought: "hum, that's weird. Let me try". Because
that's so far off our current priorities, when it failed at the very
step, you think, "I'll wait until the OP provides more info". This
would go a long way to motivate people to reply, even with a simple
"have you tried this?". As it stands, I don't even know what to say,
honestly.

For example, I also found a bug in the unwinder:

https://llvm.org/bugs/show_bug.cgi?id=24273

I did more or less what you did, put some info on how to reproduce.
But I'm not expecting anyone to look at it. That's for me to keep
there, in case I have some more time to investigate it. If either
Logan or Anton had a look, that'd be awesome! But I don't expect them
to. If I want that one to progress, I'll have to do a lot more than
what I did.

cheers,
--renato

From: Renato Golin <renato.golin@linaro.org>

> A couple weeks ago, Ben Pye, a developer working on the ARM32 stuff, found
> and reported a bug related to incorrect generation of stack unwinding info.
> ( https://llvm.org/bugs/show_bug.cgi?id=24146 ) Apparently it only occurs
> under a highly specific set of circumstances, which might look like a minor
> corner case, except that that just happens to be exactly the configuration
> needed to build CoreCLR for ARM32.

Hi Mason,

I did see the bug, but I have to say that, as priorities go, that's
way too low on my list to go past the initial look.

I compiled your test on a Cortex-A15 / Linux with Clang-3.8 (trunk)
and GCC 4.8.2 and on both occasions, the program crashes on
_Unwind_VRS_Pop() while stepping.

I, then, left it for the unwinding experts, which I'm not.

Well, yes, an unwinding expert *was* who I was really hoping to hear from. But
if I understand correctly, you're saying that rather than seeing the values Ben
reported, the sample code crashes on you on both compilers? I do notice that
you're using different versions of both compilers than he was, which may or may
not be relevant. What hardware was this on? Ben said he's been using a
Raspberry Pi, not sure which model.

I'll ask him to weigh in on here with additional details. Unfortunately he's
in a different time zone and probably asleep at the moment, so it might be a
while. In the meantime, can you provide details of the crash you're observing?
Just saying "it crashes on FooBarBaz," which is not even mentioned anywhere in
the source of the test case, doesn't provide much useful information. At the
risk of trotting out one of the oldest cliches in the book, this works (or at
least breaks as described) on our end! :stuck_out_tongue:

> This is a blocking problem for us, and I
> was just wondering how things are coming on it? Has anyone been looking
> into this, who might be able to provide some sort of estimate as to what's
> going on and when we might expect to see a fix?

I think you're looking at it from the wrong angle...

I seriously doubt that anyone besides your group will care much about

CLR on Android.

Just off the top of my head, everyone using Xamarin and a significant fraction
of the Unity3D community will care about this. Plus a non-trivial percentage
of approximately 20 million existing .NET devs, the ones who would like to
produce mobile apps if the existing "solutions" weren't either horribly expensive
or barely workable and low-quality. I can definitely say this is not something
that no one will care about!

So, unless this bug affects other people, not much will progress without
your help.

Very well. What help do you need? I'd be happy to provide any assistance
necessary.

Posting a bug on bugzilla is the first step. Having a source file,

some command lines to try out and some expected results is the second.
Adding the right people (Anton, me, Logan) is the third step.
Excellent. But it doesn't stop there.

You have to continue to investigate, step through, disassemble, check
the unwind sources, give us some ideas. The closer you get to a
recognisably obvious problem, the easier it will be to get someone
else's attention.

We all got an email from that bug (because you CC us), and we probably
all looked at it and thought: "hum, that's weird. Let me try". Because
that's so far off our current priorities, when it failed at the very

step, you think, "I'll wait until the OP provides more info".

Yeah, I wondered if it might not be something like that. We were all waiting
to hear back from you, because from our perspective we've provided a complete,
reproducible test case, and if anything more is needed, we'd expect
someone to respond to the Bugzilla post asking about it. Good thing I
checked, then! :slight_smile:

> would go a long way to motivate people to reply, even with a simple
"have you tried this?". As it stands, I don't even know what to say,
honestly.

What I would say, in your position, is I'd post a response to the Bugzilla
entry detailing my problems so that the original author would see it and
be able to improve the bug report.

For example, I also found a bug in the unwinder:

https://llvm.org/bugs/show_bug.cgi?id=24273

I did more or less what you did, put some info on how to reproduce.
But I'm not expecting anyone to look at it. That's for me to keep
there, in case I have some more time to investigate it. If either
Logan or Anton had a look, that'd be awesome! But I don't expect them
to. If I want that one to progress, I'll have to do a lot more than

what I did.

Forgive my saying so, but that seems like a bizarre attitude, as you've
already admitted that you don't know much about unwinding. Isn't that the
entire point of specialization? Having people who have their own area that
they know well and become expert in, all working together, is what lifted
mankind out of the subsistence agrarian lifestyle and enabled us to build
our way up to the modern age.

If something went wrong with my car, I certainly wouldn't attempt to diagnose
it myself and figure out the root cause so the guys at the dealership would
have an easier job of it, because tracking down the problem when I lack the
training, experience and tools to do so would waste a great deal of my time
on something that the dealership's experts could presumably figure out far
more quickly and accurately than I could. Everyone can agree that this is
perfectly reasonable when talking about cars, so why, when it comes to code,
does the exact opposite philosophy tend to appear?

Mason

Well, yes, an unwinding expert *was* who I was really hoping to hear from. But
if I understand correctly, you're saying that rather than seeing the values Ben
reported, the sample code crashes on you on both compilers? I do notice that
you're using different versions of both compilers than he was, which may or may
not be relevant. What hardware was this on? Ben said he's been using a
Raspberry Pi, not sure which model.

Yes, so, that's yet another missing info. Which ARM? RaspberyPi,
although popular, is a very old and somewhat deprecated architecture
(ARMv6). Most people work on ARMv7 and ARMv8 nowadays, so if you can't
reproduce the bugs on those, you'll have a hard time finding people to
help you.

Also, Clang 3.6 is not that old, but we don't really provide
maintenance to non-trunk versions of the compiler, so if you want a
bug looked into, you need to reproduce it in trunk. If you can't, than
the problem is fixed, and you either wait for the new release to come
out, or build your own from trunk.

It goes back to the priorities argument... There's no support
contracts in open source software. :slight_smile:

I'll ask him to weigh in on here with additional details. Unfortunately he's
in a different time zone and probably asleep at the moment, so it might be a
while.

That's ok. We're all in a different time zone, anyway. :slight_smile:

In the meantime, can you provide details of the crash you're observing?
Just saying "it crashes on FooBarBaz," which is not even mentioned anywhere in
the source of the test case, doesn't provide much useful information. At the
risk of trotting out one of the oldest cliches in the book, this works (or at
least breaks as described) on our end! :stuck_out_tongue:

That's the catch.

I know that unw_step() calls _Unwind_VRS_Pop() while loading the stack
frame, because you need the context of that frame, so for me that
looked like a good thing to say. If you report a bug in the unwinder,
I expect you to either understand a bit about it (like me), or to have
someone at your disposal that do. I cannot dig the problem for you,
first because I don't have your setup or your hardware, but also
because my priorities are not aligned to solving issues with the
unwinder on .NET.

You can't expect people to have the same environment as you have, or
even to share your enthusiasm with the things you're trying to build.

Just off the top of my head, everyone using Xamarin and a significant fraction
of the Unity3D community will care about this. Plus a non-trivial percentage
of approximately 20 million existing .NET devs, the ones who would like to
produce mobile apps if the existing "solutions" weren't either horribly expensive
or barely workable and low-quality. I can definitely say this is not something
that no one will care about!

I don't know what Xamarin is, but if Unity3D and .NET developers are
concerned, I'm sure they could lend us a hand to fix this problem. If
a company is really interested in getting that to work, they could
even pay a developer to fix this.

If out of those 20 million developers, not a single one can help you,
then maybe it's not that important for them...

Yeah, I wondered if it might not be something like that. We were all waiting
to hear back from you, because from our perspective we've provided a complete,
reproducible test case, and if anything more is needed, we'd expect
someone to respond to the Bugzilla post asking about it. Good thing I
checked, then! :slight_smile:

I understand, and for that, I apologise. Even though that wasn't
anywhere near my priorities, I did have a look, so I should have said
it failed for me, asking for more details.

I'll update the bug with some more info, but you need to reproduce it
in trunk and in a hardware that I have access to. RPI is just not
relevant enough for me, that I don't even have one. Perhaps I should
buy one...

Forgive my saying so, but that seems like a bizarre attitude, as you've
already admitted that you don't know much about unwinding. Isn't that the
entire point of specialization?

I have worked with unwinding some years ago, but the knowledge is very
specific and I forgot most of it. That's why I still have a look
around, but I'm no specialist, by far. Logan and Anton are the guys
you're looking for.

Would you rather I didn't look at it, or replied to your email, if I'm
not the specialist? (this is a genuine question)

If something went wrong with my car, I certainly wouldn't attempt to diagnose
it myself and figure out the root cause so the guys at the dealership would
have an easier job of it, because tracking down the problem when I lack the
training, experience and tools to do so would waste a great deal of my time
on something that the dealership's experts could presumably figure out far
more quickly and accurately than I could. Everyone can agree that this is
perfectly reasonable when talking about cars, so why, when it comes to code,
does the exact opposite philosophy tend to appear?

Simply because you're paying the dealership to fix your car. That's
their job, to fix *your* car.

If, on the other hand, you found a blueprint in a magazine, say
"Popular Mechanics" to build a Demoiselle[1], and you procured the
parts, built it on your barn, and the thing wouldn't fly, would you
expect Dumont to fix it for you? For free?

In open source, the only thing that works is effort. If you put the
effort to learn the technology I care about, I'll put the effort to
help you find the solution. I'd never find it for you, especially if
you expect me to do it on my own.

If you don't care about the technology and just want the bloody thing
to work, then you're free to hire a developer to do it for you. That's
what most companies do. Mine included. :slight_smile:

There is no such thing as free lunch. But if you want to share your
lunch with me, and if I would like to have half of your sandwich, I'd
be glad to give half of mine to you.

Makes sense?

cheers,
--renato

[1] Santos-Dumont Demoiselle - Wikipedia

Yes, so, that’s yet another missing info. Which ARM? RaspberyPi,
although popular, is a very old and somewhat deprecated architecture
(ARMv6). Most people work on ARMv7 and ARMv8 nowadays, so if you can’t
reproduce the bugs on those, you’ll have a hard time finding people to
help you.

Also, Clang 3.6 is not that old, but we don’t really provide
maintenance to non-trunk versions of the compiler, so if you want a
bug looked into, you need to reproduce it in trunk. If you can’t, than
the problem is fixed, and you either wait for the new release to come
out, or build your own from trunk.

Not sure if you got the other message, I think I managed to split the topic as I wasn’t subscribed to receive the previous message. This error has been on the Raspberry Pi 2, so that’s a Cortex A7 I believe, certainly ARMv7. I haven’t yet built trunk as on the device I run out of memory and do not have enough disk space to allocate a large enough swap space, and it’s too slow to wait for it to fail, so I’d have to cross compile which is not something I have yet attempted, unfortunately LLVM/Clang only provides AMD64 packages for nightly builds, despite building it for a vast matrix.

I don’t believe this to be an unwinder bug, but a generation bug (of the unwind information). I do find the crash you experience curious, but it’s not something I have had occur here. Unfortunately I can’t say I have great experience with the ARM unwind information, but really got to that conclusion by eliminating libunwind as GCC does generate unwind information that results in PC being restored.

I’ll update the bug with some more info, but you need to reproduce it
in trunk and in a hardware that I have access to. RPI is just not
relevant enough for me, that I don’t even have one. Perhaps I should
buy one…

I think you could reproduce this on scaleway.io 's hosted service, which offer a free month, but I’d be happy to provide access to something if that’s what it took. As I said though, RPi 2 should be a pretty vanilla Cortex A7 core.

Ben.

From: Renato Golin <renato.golin@linaro.org>

> Well, yes, an unwinding expert *was* who I was really hoping to hear from. But
> if I understand correctly, you're saying that rather than seeing the values Ben
> reported, the sample code crashes on you on both compilers? I do notice that
> you're using different versions of both compilers than he was, which may or may
> not be relevant. What hardware was this on? Ben said he's been using a
> Raspberry Pi, not sure which model.

Yes, so, that's yet another missing info. Which ARM? RaspberyPi,
although popular, is a very old and somewhat deprecated architecture
(ARMv6). Most people work on ARMv7 and ARMv8 nowadays, so if you can't
reproduce the bugs on those, you'll have a hard time finding people to
help you.

I asked Ben, and he says he's using the Raspberry Pi 2 (ARM 7) model.

Also, Clang 3.6 is not that old, but we don't really provide
maintenance to non-trunk versions of the compiler, so if you want a
bug looked into, you need to reproduce it in trunk. If you can't, than
the problem is fixed, and you either wait for the new release to come
out, or build your own from trunk.

OK, we'll try that.

> In the meantime, can you provide details of the crash you're observing?
> Just saying "it crashes on FooBarBaz," which is not even mentioned anywhere in
> the source of the test case, doesn't provide much useful information. At the
> risk of trotting out one of the oldest cliches in the book, this works (or at
> least breaks as described) on our end! :stuck_out_tongue:

That's the catch.

I know that unw_step() calls _Unwind_VRS_Pop() while loading the stack
frame, because you need the context of that frame, so for me that
looked like a good thing to say. If you report a bug in the unwinder,
I expect you to either understand a bit about it (like me), or to have

someone at your disposal that do.

That would be Ben. :slight_smile:

If out of those 20 million developers, not a single one can help you,> then maybe it's not that important for them...

Meh. It's more of a "if you build it, they will come" thing. We haven't
finished building it yet, but when we do, they *will* come! :smiley:

> Forgive my saying so, but that seems like a bizarre attitude, as you've
> already admitted that you don't know much about unwinding. Isn't that the
> entire point of specialization?

I have worked with unwinding some years ago, but the knowledge is very
specific and I forgot most of it. That's why I still have a look
around, but I'm no specialist, by far. Logan and Anton are the guys
you're looking for.

Awesome. I hope one of them sees this then. :slight_smile:

Would you rather I didn't look at it, or replied to your email, if I'm
not the specialist? (this is a genuine question)

Genuine answer: If you do know something, I'd rather you reply with that
and contribute what you can, even if you don't know everything. Every
little contribution can be helpful.

There is no such thing as free lunch. But if you want to share your
lunch with me, and if I would like to have half of your sandwich, I'd
be glad to give half of mine to you.

Makes sense?

Makes perfect sense to me. Share with me a fix for this bug, and in return
I'll happily share with you my ARM32 CLR, and the Android support, once we
get them working. :smiley:

Mason

Not sure if you got the other message, I think I managed to split the topic
as I wasn't subscribed to receive the previous message. This error has been
on the Raspberry Pi 2, so that's a Cortex A7 I believe, certainly ARMv7.

Excellent!

I
haven't yet built trunk as on the device I run out of memory and do not have
enough disk space to allocate a large enough swap space, and it's too slow
to wait for it to fail, so I'd have to cross compile which is not something
I have yet attempted, unfortunately LLVM/Clang only provides AMD64 packages
for nightly builds, despite building it for a vast matrix.

Exactly. It's just not good enough yet. Even gold has problems with
the huge debug objects... :frowning:

I don't believe this to be an unwinder bug, but a generation bug (of the
unwind information). I do find the crash you experience curious, but it's
not something I have had occur here. Unfortunately I can't say I have great
experience with the ARM unwind information, but really got to that
conclusion by eliminating libunwind as GCC does generate unwind information
that results in PC being restored.

Yeah, that's where unwinding gets tough...

Unwinding the stack, either for debug or profile purposes, is composed
of two independent parts: the compiler (generating
prologues/epilogues, as well as unwind tables) and the library (doing
the actual unwinding, using the table as reference and relying on the
pushes and pops to be correct).

If you include C++ exception handling, there's a third actor in play:
user code, which needs to get throw/catch in the right places, and
more libraries to implement those builtins, and more compiler work to
produce cleanups, landing pads and other stuff.

So, it's not because libunwind (from pathscale) works with GCC that
it's not a bug in libunwind. It's entirely possible that GCC is being
lenient where it shouldn't, or that pathscale's libunwind is abusing
of some GCC bug, there doesn't exist in Clang. We have seen those by
the bucket loads in the kernel, android and other large projects.

I think you could reproduce this on scaleway.io 's hosted service, which
offer a free month, but I'd be happy to provide access to something if
that's what it took. As I said though, RPi 2 should be a pretty vanilla
Cortex A7 core.

Right, so that's the other missing piece of information. One that you
are extremely forgiven for not realising... :slight_smile:

libunwind is the name of at least 3 different libraries: LLVM's,
Pathscale's and SourceForge's. It's possible that the last two are the
same, or have the same root, but LLVM's is a brand new one, and the
idea to name it "libunwind" did NOT get my vote. Alas, it is what it
is now... :slight_smile:

You should also realise that using another libunwind makes matters
more complex, because now it's far less likely that the LLVM's
libunwind folks will be interested in fixing that...

cheers,
--renato

That would be Ben. :slight_smile:

We'll get there, eventually... :slight_smile:

Meh. It's more of a "if you build it, they will come" thing. We haven't
finished building it yet, but when we do, they *will* come! :smiley:

Thought so. Ben will have to learn a lot about unwinding, then... :smiley:

Genuine answer: If you do know something, I'd rather you reply with that
and contribute what you can, even if you don't know everything. Every
little contribution can be helpful.

Right, good, that's how I see it, too.

Makes perfect sense to me. Share with me a fix for this bug, and in return
I'll happily share with you my ARM32 CLR, and the Android support, once we
get them working. :smiley:

Yeah, about that... I'm not sure I want a piece of *your* sandwich, though... :smiley:

But don't worry, with Ben on the case, we'll eventually get to the
bottom of things, and get a fix.

Meanwhile, have you thought about using LLVM's libunwind?

cheers,
--renato

You should also realise that using another libunwind makes matters
more complex, because now it’s far less likely that the LLVM’s
libunwind folks will be interested in fixing that…

I certainly understand the issue in using PathScale’s libunwind, but the lack of unw_get_save_loc is somewhat problematic and means that it is preferable to use the other libunwind within coreclr. I do think I tried to use the LLVM libunwind however with my repro, as a static library, and got the same behaviour with both GCC and Clang (certainly with the full coreclr I tried and had the same issue), so again your crash seems strange, have you tried with LLVMs libunwind with a static library? There was some further issue that prompted me to use that instead of a shared library, but this was over a week ago so sorry for forgetting exactly what it is I tried.

I do wish there was some better way to build code for the platform, but short of spending more money than I can really afford for an open source project, I am somewhat stuck for the time being, so apologies for not trying on trunk as I said.

Ben.

From: Renato Golin <renato.golin@linaro.org>

> That would be Ben. :slight_smile:

We'll get there, eventually... :slight_smile:

...

But don't worry, with Ben on the case, we'll eventually get to the
bottom of things, and get a fix.

Meanwhile, have you thought about using LLVM's libunwind?

Yes, I have. To me, that looks like the obvious solution, but that's from
the perspective of a guy on the outside looking in. I'm the guy who hated
every minute of having C++ and Linux command-line barbarism inflicted upon
me in college, and has avoided ever touching either one whenever possible
ever since then. And I know low-level x86 pretty well, but low-level ARM
is pretty far outside my experience. All I know is, it was done that way
for a reason.

I asked Ben why his port isn't using LLVM's libunwind, and he said "I'm
replying," so I assume the rationale for it will be forthcoming
momentarily. :slight_smile:

Mason

I certainly understand the issue in using PathScale's libunwind, but the
lack of unw_get_save_loc is somewhat problematic and means that it is
preferable to use the other libunwind within coreclr.

Or, you could try to persuade people to implement that in LLVM?

There are a lot of Windows folks in LLVM, and certainly good support
for it, including on ARM, so maybe that would get more traction and
even get done quicker than trying to debug here a problem in an
external library. Even though you want your CoreCLR to work on
Android, I assume this will be mainly developed from a Windows IDE, so
IDE folks that know a thing or two about unwinding in this list might
have a better chance at getting interested and fixing it than command
line folks like me.

I do think I tried to
use the LLVM libunwind however with my repro, as a static library, and got
the same behaviour with both GCC and Clang (certainly with the full coreclr
I tried and had the same issue), so again your crash seems strange, have you
tried with LLVMs libunwind with a static library?

Hum, no, that was with shared libraries. I'll try with static.

There was some further
issue that prompted me to use that instead of a shared library, but this was
over a week ago so sorry for forgetting exactly what it is I tried.

The bug I reported was on the shared version of it, so that might be
related to your problem.

I do wish there was some better way to build code for the platform, but
short of spending more money than I can really afford for an open source
project, I am somewhat stuck for the time being, so apologies for not trying

What's the GCC version you're using?

cheers,
--renato

There are a lot of Windows folks in LLVM, and certainly good support
for it, including on ARM, so maybe that would get more traction and
even get done quicker than trying to debug here a problem in an
external library. Even though you want your CoreCLR to work on
Android, I assume this will be mainly developed from a Windows IDE, so
IDE folks that know a thing or two about unwinding in this list might
have a better chance at getting interested and fixing it than command
line folks like me.

My initial focus certainly isn’t Android, it’s probably the biggest application of an ARM port sure, but currently plain ARMv7 Linux is what I’m targeting. Windows uses it’s own unwinder from the OS and so libunwind is cross-plat specific thing. Perhaps it’d be worth trying to get it implemented, I did look and it looked not too difficult, but that was me glancing over the code in a few minutes.

What’s the GCC version you’re using?

4.8.4, again packaged from Ubuntu 14.04 LTS, not sure if they include any patches that’d change this behaviour.

Ben.

This should be similar to 4.8.2 that I have, so no worries there.

cheers,
--renato

Hi Ben,

I am aware of the bug. I have downloaded the test case and look around few days ago. However, I am still trying to figure out the situation. Thus, I have no further comments at the moment.

BTW, as an amateur LLVM developer, I am fixing the issues with my spare time, thus I have to prioritize the tasks (3.7 release gets much higher priority currently) and sorry for not being responsive. I will look into this soon. But there is no estimation on the work time.

Regards,

Logan

Hi Logan,
Just wanted to see if you did successfully repro the issue now that 3.7 has been released. I know Renato had some issues, and I will try and look into it again, I now also have an A15 board here to try on in case that is the issue.

Hi Ben,

I have just investigated the test case. It seems that your test case exploits the undefined behaviors.

Please check the issue tracker for more details:
https://llvm.org/bugs/show_bug.cgi?id=24146#c9

Sincerely,
Logan