Jan Hubicka <[EMAIL PROTECTED]> writes:
[...]
>> static inline void __attribute__((noreturn)) BUG(void)
>> {
>> __asm__ __volatile__("trap");
>> __builtin_unreached();
>
> This is bit dificult to do in general since it introduces new kind of
> control flow construct. It would be better t
On Feb 6, 2007, at 5:06 PM, Joe Buck wrote:
On Tue, Feb 06, 2007 at 04:14:30PM -0800, Ian Lance Taylor wrote:
I also think it would be good to have one option affecting it: turn
__builtin_unreachable() into an abort(), or turn it into a "cannot be
reached" marker. I think the former should be
Joe Buck <[EMAIL PROTECTED]> writes:
> On Tue, Feb 06, 2007 at 04:14:30PM -0800, Ian Lance Taylor wrote:
> > I also think it would be good to have one option affecting it: turn
> > __builtin_unreachable() into an abort(), or turn it into a "cannot be
> > reached" marker. I think the former should
On Tue, Feb 06, 2007 at 04:14:30PM -0800, Ian Lance Taylor wrote:
> I also think it would be good to have one option affecting it: turn
> __builtin_unreachable() into an abort(), or turn it into a "cannot be
> reached" marker. I think the former should be the default at -O0, the
> latter at -O1 an
"Zack Weinberg" <[EMAIL PROTECTED]> writes:
> Back in 2000 I wrote a really simple patch that caused gcc to treat an
> ASM_OPERANDS that clobbered "pc" as a control flow barrier, exactly
> for this problem.
>
> http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html
>
> I still think it was a go
Zack Weinberg wrote:
> Back in 2000 I wrote a really simple patch that caused gcc to treat an
> ASM_OPERANDS that clobbered "pc" as a control flow barrier, exactly
> for this problem.
>
> http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html
>
> I still think it was a good idea, but at the time
Back in 2000 I wrote a really simple patch that caused gcc to treat an
ASM_OPERANDS that clobbered "pc" as a control flow barrier, exactly
for this problem.
http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html
I still think it was a good idea, but at the time it was received
unenthusiasticall
> In an OS kernel functions that do not return are commonly used and
> practically always their code is beyond gcc's ability to recognize
> noreturn functions. A typical example would for example be the BUG()
> function in Linux which is implemented as something like:
>
> static inline void __att
