On Mon, Feb 24, 2014 at 03:17:58PM -0800, Andrew Morton wrote:
> On Mon, 24 Feb 2014 09:02:35 +0100 Arnd Bergmann wrote:
>
> > On Saturday 22 February 2014, Josh Triplett wrote:
> > > When !CONFIG_BUG, WARN_ON and family become simple passthroughs of their
> > > condition argument; however, WARN_
On Mon, 24 Feb 2014 09:02:35 +0100 Arnd Bergmann wrote:
> On Saturday 22 February 2014, Josh Triplett wrote:
> > When !CONFIG_BUG, WARN_ON and family become simple passthroughs of their
> > condition argument; however, WARN_ON_ONCE and family still have
> > conditions and a boolean to detect one-
On Monday 24 February 2014 13:16:05 One Thousand Gnomes wrote:
>
> While I agree defining it as do {} while(1); would be a lot smarter,
> simply making it required that a platform provides an implementation of
> BUG() would be even better.
But how do we get there? The majority of architectures d
> BUG() normally causes a fault and we print helpful messages before killing
> the task, and gcc knows we never continue because of the
> __builtin_unreachable() annotation.
>
> If BUG() is defined as 'do { } while (0)' in the example above, we get
> a warning because the function may end without
On Monday 24 February 2014 12:09:11 David Howells wrote:
> Josh Triplett wrote:
>
> > > This means we actually want BUG() to end with __builtin_unreachable()
> > > as in the CONFIG_BUG=y case, and also ensure it actually is
> > > unreachable. As I have shown in [1], the there is a small overhead
Josh Triplett wrote:
> > This means we actually want BUG() to end with __builtin_unreachable()
> > as in the CONFIG_BUG=y case, and also ensure it actually is
> > unreachable. As I have shown in [1], the there is a small overhead
> > of doing this in terms of code size.
>
> I agree that allowing
On Monday 24 February 2014 00:44:37 Josh Triplett wrote:
>
> I agree that allowing BUG() to become a no-op seems suboptimal, if only
> because of the resulting warnings and mis-optimizations. However, I
> think the overhead could be cut down massively, such that BUG() just
> compiles down to a on
On Mon, Feb 24, 2014 at 09:02:35AM +0100, Arnd Bergmann wrote:
> On Saturday 22 February 2014, Josh Triplett wrote:
> > When !CONFIG_BUG, WARN_ON and family become simple passthroughs of their
> > condition argument; however, WARN_ON_ONCE and family still have
> > conditions and a boolean to detect
On Saturday 22 February 2014, Josh Triplett wrote:
> When !CONFIG_BUG, WARN_ON and family become simple passthroughs of their
> condition argument; however, WARN_ON_ONCE and family still have
> conditions and a boolean to detect one-time invocation, even though the
> warning they'd emit doesn't exi
On Sat, Feb 22, 2014 at 02:31:20PM -0800, Josh Triplett wrote:
> On Sat, Feb 22, 2014 at 01:54:49PM -0800, Randy Dunlap wrote:
> > On 02/22/2014 11:23 AM, Josh Triplett wrote:
> >
> > Hi Josh,
> >
> > If you redo these patches, please make while(0) not look like a
> > function call, i.e., use whi
On Sat, Feb 22, 2014 at 01:54:49PM -0800, Randy Dunlap wrote:
> On 02/22/2014 11:23 AM, Josh Triplett wrote:
>
> Hi Josh,
>
> If you redo these patches, please make while(0) not look like a
> function call, i.e., use while (0) instead.
Good catch. Fixing in v2.
- Josh Triplett
--
To unsubscrib
On 02/22/2014 11:23 AM, Josh Triplett wrote:
Hi Josh,
If you redo these patches, please make while(0) not look like a
function call, i.e., use while (0) instead.
> +#else /* !CONFIG_BUG */
> +#ifndef HAVE_ARCH_BUG
> +#define BUG() do {} while(0)
> +#endif
> +
> +#ifndef HAVE_ARCH_BUG_ON
> +#defi
When !CONFIG_BUG, WARN_ON and family become simple passthroughs of their
condition argument; however, WARN_ON_ONCE and family still have
conditions and a boolean to detect one-time invocation, even though the
warning they'd emit doesn't exist. Make the existing definitions
conditional on CONFIG_BU
13 matches
Mail list logo
