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 __attribute__((no
On Tue, Feb 06, 2007 at 04:44:50PM -0200, Alexandre Oliva wrote:
> > * You can add a return 0 or an exit(1) at the end of the function or
> > in a default label. Since in your case the code is unreachable, the
> > optimiser may remove it or it will never be executed.
>
> But this would generate a
On Mon, Feb 21, 2011 at 07:45:41PM +, Richard Sandiford wrote:
> David Daney writes:
> > Background:
> >
> > Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of
> > user virtual memory space. This is due the way MIPS32 memory space is
> > segmented. Only the range from 0..2
On Fri, Nov 21, 2008 at 07:46:43PM +0100, Geert Uytterhoeven wrote:
> > up with a couple of options:
> >
> > 1) Enhance the _builtin_trap() function so that we can specify the
> > break code that is emitted. This would allow us to do something
> > like:
> >
> > static inline void __attribut
On Thu, Jun 12, 2008 at 01:10:10PM -0700, David Daney wrote:
>>> Among the versions of GCC that can build the current kernel, will any
>>> fail on this code because the "i" constraint cannot be matched when
>>> expanded to RTL?
>>
>> Someone will point this out if I don't, so for avoidance of doub
On Tue, Sep 18, 2007 at 05:12:48PM -0700, David Daney wrote:
> There seems to be a small problem with the MIPS atomic memory operations
> patch I recently committed
> (http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01290.html), in that on a
> dual CPU machine it does not quite work.
>
> You can
On Wed, Sep 19, 2007 at 07:12:33PM +0100, Thiemo Seufer wrote:
> >> Another option is to depend on the setting of -mbranch-likely. By
> >> default it is on only for the processors which implement it and do not
> >> discourage it, i.e. these of the MIPS II, MIPS III and MIPS IV ISAs.
All MIPS
On Tue, Nov 13, 2007 at 11:48:53AM +, Andrew Haley wrote:
> David Daney writes:
> > With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> > impossible for GCC's exception unwinding machinery to unwind through
> > signal frames. The cause of the problems is the
> > ICACHE_R
On Tue, Nov 13, 2007 at 02:14:58PM +0100, Franck Bui-Huu wrote:
> > > David Daney writes:
> > > > With the current kernel (2.6.23.1) in my R5000 based O2 it seems
> > > > impossible for GCC's exception unwinding machinery to unwind through
> > > > signal frames. The cause of the problems is th
On Tue, Nov 13, 2007 at 03:22:33PM +0100, Franck Bui-Huu wrote:
> > > And the stack wouldn't need to have exec permission anymore.
> >
> > Oh?
> >
> > extern void frob(void (*)(void));
> >
> > int foo(void)
> > {
> > int x;
> >
> > void bar(void)
> > {
> > x
On Tue, Nov 13, 2007 at 03:37:39PM +0100, Kevin D. Kissell wrote:
> True, though it should perhaps be noted that currently it's only on 4KSc/Sd
> systems (which I know you work on) where it's even possible for the stack
> *not* to have exec permissions, since the classical MIPS MMU gives
> execute
11 matches
Mail list logo
