[lld] r258499 - Use of llvm_unreachable instead of warning in EhFrameHeader<ELFT>::assignEhFrame().

[George Rimar via llvm-commits]

>On Fri, Jan 22, 2016 at 8:27 AM, George Rimar <grimar at accesssoftek.com<mailto:grimar at accesssoftek.com>> wrote:

>>This should probably be written with an assert instead:

>>
> > assert((!this->Sec || this->Sec == Sec) && "multiple .eh_frame sections ....");
>
> This should never happen, and if will due to a bug or something then result is completely unknown, because
> code does not suppose that. So it is fatal error actually.
>
>If it's never meant to happen (if it does happen, it's a programmer error) then that's entirely appropriate for an assertion.
>
> That why I think unreachable fits better than assert and also there is no asserts in release usually.
>
> That's correct - assertions are used to test for programmatic errors/mistakes.
>
> unreachable is roughly equivalent - if not worse, with unreachable, in an -O0 build the unreachable behaves something like an assert (the program will fail hard, print an error, > etc) but in anything else, LLVM will optimize assuming the condition is true. This means if the condition is not true, the behavior may be worse than just continuing without > having done anything. LLVM will deduce that the condition /must/ be true.
>
> - Dave

So If we have unreachable it will work as assert for us here for all cases except release with optimizations. Then if we realy want to be safe then its probably better to call error() here to cover everything. I dont think that assert is better in case of -Ox because code just does not support that case, it can crash or hang or whatever, I dont know what will be and assert is not better for "final" release here because will be just skipped.

George.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160122/dd0bc526/attachment.html>