Thanks again for talking it through & the documentation update - it's a
great reference point to keep in mind for future reviews, etc.
On Tue, Mar 24, 2020 at 1:08 PM Aaron Ballman
wrote:
> Thank you for the discussion on IRC about this topic. For reference,
> this generated https://reviews.llvm
Thank you for the discussion on IRC about this topic. For reference,
this generated https://reviews.llvm.org/D76721 to clarify the
documentation. I've also reverted the change in this thread in commit
7339fca25facb566e969b6ce01f23ac96499d574, so we're back to
llvm_unreachable in this case.
~Aaron
On Mon, Mar 23, 2020 at 5:24 AM Aaron Ballman
wrote:
> On Sun, Mar 22, 2020 at 3:31 PM David Blaikie wrote:
> >
> > On Sun, Mar 22, 2020 at 9:34 AM Aaron Ballman
> wrote:
> >>
> >> On Sun, Mar 22, 2020 at 12:19 PM David Blaikie
> wrote:
> >> >
> >> > On Sun, Mar 22, 2020 at 6:34 AM Aaron Ballm
On Mon, Mar 23, 2020 at 1:41 PM Craig Topper wrote:
>
> If its relatively common for someone making a plugin to mess this up, maybe
> it should be report_fatal_error instead of only catching it in asserts build?
I think that would also be a reasonable solution if that's the preference.
~Aaron
If its relatively common for someone making a plugin to mess this up, maybe
it should be report_fatal_error instead of only catching it in asserts
build?
~Craig
On Mon, Mar 23, 2020 at 5:24 AM Aaron Ballman
wrote:
> On Sun, Mar 22, 2020 at 3:31 PM David Blaikie wrote:
> >
> > On Sun, Mar 22,
On Sun, Mar 22, 2020 at 3:31 PM David Blaikie wrote:
>
> On Sun, Mar 22, 2020 at 9:34 AM Aaron Ballman wrote:
>>
>> On Sun, Mar 22, 2020 at 12:19 PM David Blaikie wrote:
>> >
>> > On Sun, Mar 22, 2020 at 6:34 AM Aaron Ballman
>> > wrote:
>> >>
>> >> On Sat, Mar 21, 2020 at 11:31 PM David Blaik
On Sun, Mar 22, 2020 at 9:34 AM Aaron Ballman
wrote:
> On Sun, Mar 22, 2020 at 12:19 PM David Blaikie wrote:
> >
> > On Sun, Mar 22, 2020 at 6:34 AM Aaron Ballman
> wrote:
> >>
> >> On Sat, Mar 21, 2020 at 11:31 PM David Blaikie
> wrote:
> >> >
> >> > Why the change? this seems counter to LLVM
Hi Dave, Aaron,
and I spent a lot more time debugging than I should have because I was using
> a release + asserts build and the semantics of llvm_unreachable made
> unfortunate codegen (switching to an assert makes the issue
> immediately obvious).
Huh. I think we should be using llvm_unreachab
On Sun, Mar 22, 2020 at 12:19 PM David Blaikie wrote:
>
> On Sun, Mar 22, 2020 at 6:34 AM Aaron Ballman wrote:
>>
>> On Sat, Mar 21, 2020 at 11:31 PM David Blaikie wrote:
>> >
>> > Why the change? this seems counter to LLVM's style which pretty
>> > consistently uses unreachable rather than ass
On Sun, Mar 22, 2020 at 6:34 AM Aaron Ballman
wrote:
> On Sat, Mar 21, 2020 at 11:31 PM David Blaikie wrote:
> >
> > Why the change? this seems counter to LLVM's style which pretty
> consistently uses unreachable rather than assert(false), so far as I know?
>
> We're not super consistent (at lea
On Sat, Mar 21, 2020 at 11:31 PM David Blaikie wrote:
>
> Why the change? this seems counter to LLVM's style which pretty consistently
> uses unreachable rather than assert(false), so far as I know?
We're not super consistent (at least within Clang), but the rules as
I've generally understood th
Why the change? this seems counter to LLVM's style which pretty
consistently uses unreachable rather than assert(false), so far as I know?
On Tue, Mar 10, 2020 at 11:22 AM Aaron Ballman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> Author: Aaron Ballman
> Date: 2020-03-10T14:22:21-04:0
12 matches
Mail list logo
