'noreturn' warning in libcruft

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

'noreturn' warning in libcruft

Rik-4
8/7/12

All,

When compiling libcruft/misc/f77-fcn.c I get the following warning:

../../octave-dev/libcruft/misc/f77-fcn.c: In function ‘xstopx_’:
../../octave-dev/libcruft/misc/f77-fcn.c:63: warning: function declared
‘noreturn’ has a ‘return’ statement

If I look in libcruft/misc/f77-fcn.h I find the following prototype:

extern CRUFT_API F77_RET_T
F77_FUNC (xstopx, XSTOPX) (F77_CONST_CHAR_ARG_DECL
                           F77_CHAR_ARG_LEN_DECL) GCC_ATTR_NORETURN;

The 'noreturn' attribute is being explicitly set for this function so that
seems okay.

The actual function is

F77_RET_T
#if defined (F77_USES_CRAY_CALLING_CONVENTION)
F77_FUNC (xstopx, XSTOPX) (octave_cray_ftn_ch_dsc desc)
#elif defined (F77_USES_VISUAL_FORTRAN_CALLING_CONVENTION)
F77_FUNC (xstopx, XSTOPX) (const char *s, int slen)
#else
F77_FUNC (xstopx, XSTOPX) (const char *s, long slen)
#endif
{
#if defined (F77_USES_CRAY_CALLING_CONVENTION)
  const char *s = desc.const_ptr = ptr_arg;
  unsigned long slen = desc.mask.len;
#endif

  f77_exception_encountered = 1;

  /* Skip printing message if it is just a single blank character.  */
  if (s && slen > 0 && ! (slen == 1 && *s == ' '))
    (*current_liboctave_error_handler) ("%.*s", slen, s);

  octave_jump_to_enclosing_context ();

  F77_RETURN (0)
}

So the function is declared 'noreturn' and yet has a return statement.  The
function before the return, octave_jump_to_enclosing_context(), does indeed
do a longjmp so it seems like the F77_RETURN(0) can just be eliminated from
the code.

Any objections to that deletion?

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

Michael Goffioul
On Tue, Aug 7, 2012 at 5:22 PM, Rik <[hidden email]> wrote:
8/7/12

All,

When compiling libcruft/misc/f77-fcn.c I get the following warning:

../../octave-dev/libcruft/misc/f77-fcn.c: In function ‘xstopx_’:
../../octave-dev/libcruft/misc/f77-fcn.c:63: warning: function declared
‘noreturn’ has a ‘return’ statement

If I look in libcruft/misc/f77-fcn.h I find the following prototype:

extern CRUFT_API F77_RET_T
F77_FUNC (xstopx, XSTOPX) (F77_CONST_CHAR_ARG_DECL
                           F77_CHAR_ARG_LEN_DECL) GCC_ATTR_NORETURN;

The 'noreturn' attribute is being explicitly set for this function so that
seems okay.

The actual function is

F77_RET_T
#if defined (F77_USES_CRAY_CALLING_CONVENTION)
F77_FUNC (xstopx, XSTOPX) (octave_cray_ftn_ch_dsc desc)
#elif defined (F77_USES_VISUAL_FORTRAN_CALLING_CONVENTION)
F77_FUNC (xstopx, XSTOPX) (const char *s, int slen)
#else
F77_FUNC (xstopx, XSTOPX) (const char *s, long slen)
#endif
{
#if defined (F77_USES_CRAY_CALLING_CONVENTION)
  const char *s = desc.const_ptr = ptr_arg;
  unsigned long slen = desc.mask.len;
#endif

  f77_exception_encountered = 1;

  /* Skip printing message if it is just a single blank character.  */
  if (s && slen > 0 && ! (slen == 1 && *s == ' '))
    (*current_liboctave_error_handler) ("%.*s", slen, s);

  octave_jump_to_enclosing_context ();

  F77_RETURN (0)
}

So the function is declared 'noreturn' and yet has a return statement.  The
function before the return, octave_jump_to_enclosing_context(), does indeed
do a longjmp so it seems like the F77_RETURN(0) can just be eliminated from
the code.

Any objections to that deletion?

Deleting it would assume that GCC_ATTR_NORETURN is always defined properly. Would it be a problem to leave it in place?

Michael.


Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

Rik-4
On 08/07/2012 09:26 AM, Michael Goffioul wrote:
On Tue, Aug 7, 2012 at 5:22 PM, Rik <[hidden email]> wrote:
8/7/12

All,

When compiling libcruft/misc/f77-fcn.c I get the following warning:

../../octave-dev/libcruft/misc/f77-fcn.c: In function ‘xstopx_’:
../../octave-dev/libcruft/misc/f77-fcn.c:63: warning: function declared
‘noreturn’ has a ‘return’ statement

If I look in libcruft/misc/f77-fcn.h I find the following prototype:

extern CRUFT_API F77_RET_T
F77_FUNC (xstopx, XSTOPX) (F77_CONST_CHAR_ARG_DECL
                           F77_CHAR_ARG_LEN_DECL) GCC_ATTR_NORETURN;

The 'noreturn' attribute is being explicitly set for this function so that
seems okay.

The actual function is

F77_RET_T
#if defined (F77_USES_CRAY_CALLING_CONVENTION)
F77_FUNC (xstopx, XSTOPX) (octave_cray_ftn_ch_dsc desc)
#elif defined (F77_USES_VISUAL_FORTRAN_CALLING_CONVENTION)
F77_FUNC (xstopx, XSTOPX) (const char *s, int slen)
#else
F77_FUNC (xstopx, XSTOPX) (const char *s, long slen)
#endif
{
#if defined (F77_USES_CRAY_CALLING_CONVENTION)
  const char *s = desc.const_ptr = ptr_arg;
  unsigned long slen = desc.mask.len;
#endif

  f77_exception_encountered = 1;

  /* Skip printing message if it is just a single blank character.  */
  if (s && slen > 0 && ! (slen == 1 && *s == ' '))
    (*current_liboctave_error_handler) ("%.*s", slen, s);

  octave_jump_to_enclosing_context ();

  F77_RETURN (0)
}

So the function is declared 'noreturn' and yet has a return statement.  The
function before the return, octave_jump_to_enclosing_context(), does indeed
do a longjmp so it seems like the F77_RETURN(0) can just be eliminated from
the code.

Any objections to that deletion?

Deleting it would assume that GCC_ATTR_NORETURN is always defined properly. Would it be a problem to leave it in place?
Leaving the code in place is what provokes the warning that I am trying to silence.  Note that regardless of whether GCC_ATTR_NORETURN is declared for this function, the particular line of code F77_RETURN(0) will never be executed.  The noreturn attribute is merely warning us that we're being redundant since there is no way to get to the return statement because the longjmp in octave_jum_to_enclosing_context() will always intervene.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

Michael Goffioul
On Tue, Aug 7, 2012 at 5:45 PM, Rik <[hidden email]> wrote:
On 08/07/2012 09:26 AM, Michael Goffioul wrote:
On Tue, Aug 7, 2012 at 5:22 PM, Rik <[hidden email]> wrote:
8/7/12

All,

When compiling libcruft/misc/f77-fcn.c I get the following warning:

../../octave-dev/libcruft/misc/f77-fcn.c: In function ‘xstopx_’:
../../octave-dev/libcruft/misc/f77-fcn.c:63: warning: function declared
‘noreturn’ has a ‘return’ statement

If I look in libcruft/misc/f77-fcn.h I find the following prototype:

extern CRUFT_API F77_RET_T
F77_FUNC (xstopx, XSTOPX) (F77_CONST_CHAR_ARG_DECL
                           F77_CHAR_ARG_LEN_DECL) GCC_ATTR_NORETURN;

The 'noreturn' attribute is being explicitly set for this function so that
seems okay.

The actual function is

F77_RET_T
#if defined (F77_USES_CRAY_CALLING_CONVENTION)
F77_FUNC (xstopx, XSTOPX) (octave_cray_ftn_ch_dsc desc)
#elif defined (F77_USES_VISUAL_FORTRAN_CALLING_CONVENTION)
F77_FUNC (xstopx, XSTOPX) (const char *s, int slen)
#else
F77_FUNC (xstopx, XSTOPX) (const char *s, long slen)
#endif
{
#if defined (F77_USES_CRAY_CALLING_CONVENTION)
  const char *s = desc.const_ptr = ptr_arg;
  unsigned long slen = desc.mask.len;
#endif

  f77_exception_encountered = 1;

  /* Skip printing message if it is just a single blank character.  */
  if (s && slen > 0 && ! (slen == 1 && *s == ' '))
    (*current_liboctave_error_handler) ("%.*s", slen, s);

  octave_jump_to_enclosing_context ();

  F77_RETURN (0)
}

So the function is declared 'noreturn' and yet has a return statement.  The
function before the return, octave_jump_to_enclosing_context(), does indeed
do a longjmp so it seems like the F77_RETURN(0) can just be eliminated from
the code.

Any objections to that deletion?

Deleting it would assume that GCC_ATTR_NORETURN is always defined properly. Would it be a problem to leave it in place?
Leaving the code in place is what provokes the warning that I am trying to silence.  Note that regardless of whether GCC_ATTR_NORETURN is declared for this function, the particular line of code F77_RETURN(0) will never be executed.  The noreturn attribute is merely warning us that we're being redundant since there is no way to get to the return statement because the longjmp in octave_jum_to_enclosing_context() will always intervene.


I know what you're trying to do and I know why the return statement will never get reached. But I also know that with no-GCC compilers, GCC_ATTR_NORETURN will not be defined and this then may generate a compiler error as the return statement will now be missing.

So it's basically a choice between getting rid of a GCC warning and (possibly) introducing a compilation error with other compilers.

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

John W. Eaton
Administrator
In reply to this post by Rik-4
On  7-Aug-2012, Rik wrote:

| On 08/07/2012 09:26 AM, Michael Goffioul wrote:
|
|     On Tue, Aug 7, 2012 at 5:22 PM, Rik <[hidden email]> wrote:
|
|         8/7/12
|
|         All,
|
|         When compiling libcruft/misc/f77-fcn.c I get the following warning:
|
|         ../../octave-dev/libcruft/misc/f77-fcn.c: In function ‘xstopx_’:
|         ../../octave-dev/libcruft/misc/f77-fcn.c:63: warning: function declared
|         ‘noreturn’ has a ‘return’ statement
|
|         If I look in libcruft/misc/f77-fcn.h I find the following prototype:
|
|         extern CRUFT_API F77_RET_T
|         F77_FUNC (xstopx, XSTOPX) (F77_CONST_CHAR_ARG_DECL
|                                    F77_CHAR_ARG_LEN_DECL)
|         GCC_ATTR_NORETURN;
|
|         The 'noreturn' attribute is being explicitly set for this function so
|         that
|         seems okay.
|
|         The actual function is
|
|         F77_RET_T
|         #if defined (F77_USES_CRAY_CALLING_CONVENTION)
|         F77_FUNC (xstopx, XSTOPX) (octave_cray_ftn_ch_dsc desc)
|         #elif defined (F77_USES_VISUAL_FORTRAN_CALLING_CONVENTION)
|         F77_FUNC (xstopx, XSTOPX) (const char *s, int slen)
|         #else
|         F77_FUNC (xstopx, XSTOPX) (const char *s, long slen)
|         #endif
|         {
|         #if defined (F77_USES_CRAY_CALLING_CONVENTION)
|           const char *s = desc.const_ptr = ptr_arg;
|           unsigned long slen = desc.mask.len;
|         #endif
|
|           f77_exception_encountered = 1;
|
|           /* Skip printing message if it is just a single blank character.  *
|         /
|           if (s && slen > 0 && ! (slen == 1 && *s == ' '))
|             (*current_liboctave_error_handler) ("%.*s", slen, s);
|
|           octave_jump_to_enclosing_context ();
|
|           F77_RETURN (0)
|         }
|
|         So the function is declared 'noreturn' and yet has a return statement.
|          The
|         function before the return, octave_jump_to_enclosing_context(), does
|         indeed
|         do a longjmp so it seems like the F77_RETURN(0) can just be eliminated
|         from
|         the code.
|
|         Any objections to that deletion?
|
|
|     Deleting it would assume that GCC_ATTR_NORETURN is always defined properly.
|     Would it be a problem to leave it in place?
|
| Leaving the code in place is what provokes the warning that I am trying to
| silence.  Note that regardless of whether GCC_ATTR_NORETURN is declared for
| this function, the particular line of code F77_RETURN(0) will never be
| executed.  The noreturn attribute is merely warning us that we're being
| redundant since there is no way to get to the return statement because the
| longjmp in octave_jum_to_enclosing_context() will always intervene.

Deleting the F77_RETURN(0) will avoid the warning if GCC_ATTR_NORETURN
is defined because octave_jump_to_enclosing_context is tagged with
GCC_ATTR_NORETURN.

But if you delete the F77_RETURN (0) line and GCC_ATTR_NORETURN is not
defined, you will likely get a warning about "control reaches end of
non-void function".

So how about using

  #ifndef GCC_ATTR_NORETURN
    F77_RETURN (0)
  #endif

?

Note that this only matters if F77_RET_T is int.  If it is void, then
F77_RETURN expands to nothing and there is no inconsistency about
return type and falling off the end of the function without a return
statement.

Thinking about this again though, maybe it is confusing to have
F77_RETURN expand to nothing (shouldn't it return?).  But the point
of it was just to provide a way to define a C function that would
behave like a Fortran subroutine and to avoid GCC's "control reaches
end of non-void function" warning.  Maybe we should really have a few
different types of F77_RETURN macros?

  F77_RETURN (retval)    ! same as we have now, except that it should
                         ! be defined to "return;" if F77_RET_T is
                         ! defined as "void".

  F77_NORETURN (retval)  ! expands to nothing if either
                         ! GCC_ATTR_NORETURN is defined or if
                         ! F77_RET_T is defined as "void".  Otherwise,
                         ! expand to "return retval;"

Then the xstopx function should use F77_NORETURN instead of
F77_RETURN.  Does that make sense?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

Rik-4
In reply to this post by Michael Goffioul

>
>
> I know what you're trying to do and I know why the return statement will
> never get reached. But I also know that with no-GCC compilers,
> GCC_ATTR_NORETURN will not be defined and this then may generate a
> compiler error as the return statement will now be missing.
>
> So it's basically a choice between getting rid of a GCC warning and
> (possibly) introducing a compilation error with other compilers.
If it is a specific compiler behavior that we are using then why not test
for it as is already done for the GCC_ATTR_NORETURN macro?  The following
silences the warning for me and should work with the other compilers that
want a return statement.

#ifndef __GNUC__
  F77_RETURN (0)
#endif

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

John W. Eaton
Administrator
On  7-Aug-2012, Rik wrote:

|
| >
| >
| > I know what you're trying to do and I know why the return statement will
| > never get reached. But I also know that with no-GCC compilers,
| > GCC_ATTR_NORETURN will not be defined and this then may generate a
| > compiler error as the return statement will now be missing.
| >
| > So it's basically a choice between getting rid of a GCC warning and
| > (possibly) introducing a compilation error with other compilers.
| If it is a specific compiler behavior that we are using then why not test
| for it as is already done for the GCC_ATTR_NORETURN macro?  The following
| silences the warning for me and should work with the other compilers that
| want a return statement.
|
| #ifndef __GNUC__
|   F77_RETURN (0)
| #endif

The attached diff is what I had in mind.

jwe


diff --git a/libcruft/misc/f77-fcn.c b/libcruft/misc/f77-fcn.c
--- a/libcruft/misc/f77-fcn.c
+++ b/libcruft/misc/f77-fcn.c
@@ -60,5 +60,5 @@
 
   octave_jump_to_enclosing_context ();
 
-  F77_RETURN (0)
+  F77_NORETURN (0)
 }
diff --git a/libcruft/misc/f77-fcn.h b/libcruft/misc/f77-fcn.h
--- a/libcruft/misc/f77-fcn.h
+++ b/libcruft/misc/f77-fcn.h
@@ -108,6 +108,11 @@
 
 #define F77_RET_T int
 #define F77_RETURN(retval) return retval;
+#if defined (GCC_ATTR_NORETURN)
+#define F77_NORETURN(retval)
+#else
+#define F77_NORETURN(retval) return retval;
+#endif
 
 /* FIXME -- these should work for SV1 or Y-MP systems but will
    need to be changed for others.  */
@@ -176,7 +181,8 @@
 #define F77_CHAR_ARG_LEN_USE(s, len) len
 
 #define F77_RET_T void
-#define F77_RETURN(retval)
+#define F77_RETURN(retval) return;
+#define F77_NORETURN(retval)
 
 #else
 
@@ -203,6 +209,11 @@
 
 #define F77_RET_T int
 #define F77_RETURN(retval) return retval;
+#if defined (GCC_ATTR_NORETURN)
+#define F77_NORETURN(retval)
+#else
+#define F77_NORETURN(retval) return retval;
+#endif
 
 #endif
 
Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

Michael Goffioul
On Tue, Aug 7, 2012 at 7:14 PM, John W. Eaton <[hidden email]> wrote:
On  7-Aug-2012, Rik wrote:

|
| >
| >
| > I know what you're trying to do and I know why the return statement will
| > never get reached. But I also know that with no-GCC compilers,
| > GCC_ATTR_NORETURN will not be defined and this then may generate a
| > compiler error as the return statement will now be missing.
| >
| > So it's basically a choice between getting rid of a GCC warning and
| > (possibly) introducing a compilation error with other compilers.
| If it is a specific compiler behavior that we are using then why not test
| for it as is already done for the GCC_ATTR_NORETURN macro?  The following
| silences the warning for me and should work with the other compilers that
| want a return statement.
|
| #ifndef __GNUC__
|   F77_RETURN (0)
| #endif

The attached diff is what I had in mind.

jwe


diff --git a/libcruft/misc/f77-fcn.c b/libcruft/misc/f77-fcn.c
--- a/libcruft/misc/f77-fcn.c
+++ b/libcruft/misc/f77-fcn.c
@@ -60,5 +60,5 @@

   octave_jump_to_enclosing_context ();

-  F77_RETURN (0)
+  F77_NORETURN (0)
 }
diff --git a/libcruft/misc/f77-fcn.h b/libcruft/misc/f77-fcn.h
--- a/libcruft/misc/f77-fcn.h
+++ b/libcruft/misc/f77-fcn.h
@@ -108,6 +108,11 @@

 #define F77_RET_T int
 #define F77_RETURN(retval) return retval;
+#if defined (GCC_ATTR_NORETURN)
+#define F77_NORETURN(retval)
+#else
+#define F77_NORETURN(retval) return retval;
+#endif

 /* FIXME -- these should work for SV1 or Y-MP systems but will
    need to be changed for others.  */
@@ -176,7 +181,8 @@
 #define F77_CHAR_ARG_LEN_USE(s, len) len

 #define F77_RET_T void
-#define F77_RETURN(retval)
+#define F77_RETURN(retval) return;
+#define F77_NORETURN(retval)

 #else

@@ -203,6 +209,11 @@

 #define F77_RET_T int
 #define F77_RETURN(retval) return retval;
+#if defined (GCC_ATTR_NORETURN)
+#define F77_NORETURN(retval)
+#else
+#define F77_NORETURN(retval) return retval;
+#endif

 #endif



Won't GCC_ATTR_NORETURN always be defined, to something relevant or the empty string (otherwise you'd get a compilation error)? In that case, the above change won't have the expected result.

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

Michael Goffioul
In reply to this post by Rik-4
On Tue, Aug 7, 2012 at 6:43 PM, Rik <[hidden email]> wrote:

>
>
> I know what you're trying to do and I know why the return statement will
> never get reached. But I also know that with no-GCC compilers,
> GCC_ATTR_NORETURN will not be defined and this then may generate a
> compiler error as the return statement will now be missing.
>
> So it's basically a choice between getting rid of a GCC warning and
> (possibly) introducing a compilation error with other compilers.
If it is a specific compiler behavior that we are using then why not test
for it as is already done for the GCC_ATTR_NORETURN macro?  The following
silences the warning for me and should work with the other compilers that
want a return statement.

#ifndef __GNUC__
  F77_RETURN (0)
#endif

That's consistent with what's in dumped into config.h (we don't test for the feature, it's solely based on __GNUC__ definition).

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

John W. Eaton
Administrator
In reply to this post by Michael Goffioul
On  7-Aug-2012, Michael Goffioul wrote:

| Won't GCC_ATTR_NORETURN always be defined, to something relevant or the empty
| string (otherwise you'd get a compilation error)? In that case, the above
| change won't have the expected result.

Oops, right.  Do we need a corresponding HAVE_GCC_ATTR_NORETURN macro?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

John W. Eaton
Administrator
In reply to this post by Michael Goffioul
On  7-Aug-2012, Michael Goffioul wrote:

| That's consistent with what's in dumped into config.h (we don't test for the
| feature, it's solely based on __GNUC__ definition).

I think it was probably done that way out of laziness.  I hesitate to
test for __GNUC__ in more places.  I think it would be better to use
HAVE_ATTR_NORETURN, even if that is (due to more laziness) also
defined in the config.h header based solely on __GNUC__.  Maybe also
we should rename the HAVE_GCC_ATTR_NORETURN to be HAVE_ATTR_NORETURN,
since this might eventually be a feature of more than one compiler.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

Michael Goffioul
On Tue, Aug 7, 2012 at 8:21 PM, John W. Eaton <[hidden email]> wrote:
On  7-Aug-2012, Michael Goffioul wrote:

| That's consistent with what's in dumped into config.h (we don't test for the
| feature, it's solely based on __GNUC__ definition).

I think it was probably done that way out of laziness.  I hesitate to
test for __GNUC__ in more places.  I think it would be better to use
HAVE_ATTR_NORETURN, even if that is (due to more laziness) also
defined in the config.h header based solely on __GNUC__.  Maybe also
we should rename the HAVE_GCC_ATTR_NORETURN to be HAVE_ATTR_NORETURN,
since this might eventually be a feature of more than one compiler.

Why not use the _Noreturn macro already part of generated config.h (coming from gnulib)? This does not solve the problem of the return statement, but allows to remove octave's own handling of noreturn.

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

John W. Eaton
Administrator
On  7-Aug-2012, Michael Goffioul wrote:

| On Tue, Aug 7, 2012 at 8:21 PM, John W. Eaton <[hidden email]> wrote:
|
|     On  7-Aug-2012, Michael Goffioul wrote:
|
|     | That's consistent with what's in dumped into config.h (we don't test for
|     the
|     | feature, it's solely based on __GNUC__ definition).
|
|     I think it was probably done that way out of laziness.  I hesitate to
|     test for __GNUC__ in more places.  I think it would be better to use
|     HAVE_ATTR_NORETURN, even if that is (due to more laziness) also
|     defined in the config.h header based solely on __GNUC__.  Maybe also
|     we should rename the HAVE_GCC_ATTR_NORETURN to be HAVE_ATTR_NORETURN,
|     since this might eventually be a feature of more than one compiler.
|
|
| Why not use the _Noreturn macro already part of generated config.h (coming from
| gnulib)? This does not solve the problem of the return statement, but allows to
| remove octave's own handling of noreturn.

I have no objection to replacing GCC_ATTR_NORETURN with _Noreturn from
gnulib.  I didn't know that gnulib provided _Noreturn.  We defined
GCC_ATTR_NORETURN before we started using gnulib.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

Rik-4
In reply to this post by John W. Eaton
On 08/07/2012 12:21 PM, John W. Eaton wrote:

> On  7-Aug-2012, Michael Goffioul wrote:
>
> | That's consistent with what's in dumped into config.h (we don't test for the
> | feature, it's solely based on __GNUC__ definition).
>
> I think it was probably done that way out of laziness.  I hesitate to
> test for __GNUC__ in more places.  I think it would be better to use
> HAVE_ATTR_NORETURN, even if that is (due to more laziness) also
> defined in the config.h header based solely on __GNUC__.  Maybe also
> we should rename the HAVE_GCC_ATTR_NORETURN to be HAVE_ATTR_NORETURN,
> since this might eventually be a feature of more than one compiler.
This seems fine.  It is a niggling little warning so I didn't want to spend
too much time constructing the generalizable solution.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

John W. Eaton
Administrator
On  7-Aug-2012, Rik wrote:

| This seems fine.  It is a niggling little warning so I didn't want to spend
| too much time constructing the generalizable solution.

Do you want to work on this, or would you like for me to do it?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

Rik-4
On 08/07/2012 02:28 PM, John W. Eaton wrote:
> On  7-Aug-2012, Rik wrote:
>
> | This seems fine.  It is a niggling little warning so I didn't want to spend
> | too much time constructing the generalizable solution.
>
> Do you want to work on this, or would you like for me to do it?
Can you do this?  I'd still like to work on removing the possibly useless
INCFLAGS variable and then there is another issue with XTRA_CXXFLAGS that
I'll post about soon.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: 'noreturn' warning in libcruft

John W. Eaton
Administrator
On  7-Aug-2012, Rik wrote:

| On 08/07/2012 02:28 PM, John W. Eaton wrote:
| > On  7-Aug-2012, Rik wrote:
| >
| > | This seems fine.  It is a niggling little warning so I didn't want to spend
| > | too much time constructing the generalizable solution.
| >
| > Do you want to work on this, or would you like for me to do it?
| Can you do this?

OK, I checked in the following changes:

  http://hg.savannah.gnu.org/hgweb/octave/rev/87411930d6c4
  http://hg.savannah.gnu.org/hgweb/octave/rev/4d52239daef5

I didn't use the gnulib stdnoreturn module because it wasn't clear to
me how best to do that *and* get the HAVE_ATTR_NORETURN macro that we
need without duplicating the logic of the module.

jwe