[Xen-devel] [PATCH 1/2] Compile errors with gcc 4.8

[M A Young <m.a.young@xxxxxxxxxxxx>]

On Thu, 7 Feb 2013, Keir Fraser wrote:

> On 07/02/2013 09:57, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>
> > Actually, I'm of the opposite opinion - it should be in other places
> > too that handles don't get needlessly defined by the public
> > headers. They should get defined only when there actually is a
> > use for them. Everything else can be defined where actually
> > consumed, as in this case: For one, a handle of a compat_*
> > type can't be defined in a public header anyway, as the compat
> > types don't get defined there. And then, as you say, the oddity
> > of this type makes it desirable to scope restrict it as much as
> > possible.
> >
> > Now, for the actual solution, I'd prefer the -Wno-... Option
> +1. It's not a compiler warning that I care about.
>
> -- Keir
>
> > suggested above, or as a second best choice generalizing the
> > solution suggested by Michael, applying the attribute in
> > DEFINE_XEN_GUEST_HANDLE() itself. This is the more that
> > attaching it in to the use of the macro just happens to work,
> > but isn't guaranteed to in the future: Switching around the
> > order of the two lines of the expansion
> >
> > #define __DEFINE_XEN_GUEST_HANDLE(name, type) \
> >     ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
> >     ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
> >
> > or adding a third (say, volatile) one would re-expose the
> > problem.
> >
> > Jan
I am attaching a patch that turns off this check.

        Michael Young

Attachment: gcc48.build.1.patch
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel