We get that everywhere, unfortunately - it comes from flex and is outside our
control as the file it complains about is actually generated by flex itself.
Unfortunately, flex is no longer maintained, and so nothing has been done to
correct it.
On Feb 19, 2012, at 8:47 PM, Paul H. Hargrove
I've not checked any other systems, but building the trunk on OpenBSD
and FreeBSD (w/ flex-2.5.4) I see the following:
LEXshow_help_lex.c
"[srcdir]/opal/util/show_help_lex.l", line 65: warning, dangerous
trailing context
I found this message in the flex documentation, and it mentions
Creating nightly hwloc snapshot SVN tarball was a success.
Snapshot: hwloc 1.5a1r4323
Start time: Sun Feb 19 21:01:01 EST 2012
End time: Sun Feb 19 21:04:19 EST 2012
Your friendly daemon,
Cyrador
On 2/19/2012 12:45 PM, Samuel Thibault wrote:
[snip[
Ah, right, it's an inline, so we need to declare it first with the
attribute, and then define it:
static __hwloc_inline const char *
hwloc_obj_get_info_by_name(hwloc_obj_t obj, const char *name)
__hwloc_attribute_pure;
static
Paul H. Hargrove, le Sun 19 Feb 2012 21:37:50 +0100, a écrit :
> On 2/19/2012 10:54 AM, Samuel Thibault wrote:
> [snip]
> >Does it still complain if using the following?
> >>static __hwloc_inline const char *
> >> hwloc_obj_get_info_by_name(hwloc_obj_t obj, const char *name)
> >>
On 2/19/2012 10:54 AM, Samuel Thibault wrote:
[snip]
Does it still complain if using the following?
static __hwloc_inline const char *
hwloc_obj_get_info_by_name(hwloc_obj_t obj, const char *name)
__hwloc_attribute_pure
That'd be safer to make sure that the attribute is applied to the
Paul H. Hargrove, le Sat 18 Feb 2012 00:58:27 +0100, a écrit :
> I am not sure of the risk/reward on applying this change, however.
> Gcc seems to be happy enough either way as far as I could tell.
> -static __hwloc_inline const char * __hwloc_attribute_pure
> +static __hwloc_inline
