The present use of -Wcast-align causes the build to blow up on SH due to
generating a "cast increases required alignment of target type" error on
each invocation of list_for_each_entry().
It seems that this was previously reported and killed off in the ia64
support patch, but nothing seems to have happened with that. Presumably
the same problem still remains there, too.
Signed-off-by: Paul Mundt <[email protected]>
---
tools/perf/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 88c51b8..39a84be 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -177,8 +177,7 @@ endif
# Include saner warnings here, which can catch bugs:
#
-EXTRA_WARNINGS := -Wcast-align
-EXTRA_WARNINGS := $(EXTRA_WARNINGS) -Wformat
+EXTRA_WARNINGS := -Wformat
EXTRA_WARNINGS := $(EXTRA_WARNINGS) -Wformat-security
EXTRA_WARNINGS := $(EXTRA_WARNINGS) -Wformat-y2k
EXTRA_WARNINGS := $(EXTRA_WARNINGS) -Wshadow
* Paul Mundt <[email protected]> wrote:
> The present use of -Wcast-align causes the build to blow up on SH due to
> generating a "cast increases required alignment of target type" error on
> each invocation of list_for_each_entry().
>
> It seems that this was previously reported and killed off in the ia64
> support patch, but nothing seems to have happened with that. Presumably
> the same problem still remains there, too.
>
> Signed-off-by: Paul Mundt <[email protected]>
Is this a GCC bug producing false positive warnings? The GCC manpage
says:
-Wcast-align
Warn whenever a pointer is cast such that the required alignment of the
target is increased. For example, warn if a "char *" is cast to an
"int *" on machines where integers can only be accessed at two- or
four-byte boundaries.
Which looks moderately useful - if it works.
Ingo
On Mon, Oct 26, 2009 at 07:25:20AM +0100, Ingo Molnar wrote:
>
> * Paul Mundt <[email protected]> wrote:
>
> > The present use of -Wcast-align causes the build to blow up on SH due to
> > generating a "cast increases required alignment of target type" error on
> > each invocation of list_for_each_entry().
> >
> > It seems that this was previously reported and killed off in the ia64
> > support patch, but nothing seems to have happened with that. Presumably
> > the same problem still remains there, too.
> >
> > Signed-off-by: Paul Mundt <[email protected]>
>
> Is this a GCC bug producing false positive warnings? The GCC manpage
> says:
>
> -Wcast-align
> Warn whenever a pointer is cast such that the required alignment of the
> target is increased. For example, warn if a "char *" is cast to an
> "int *" on machines where integers can only be accessed at two- or
> four-byte boundaries.
>
> Which looks moderately useful - if it works.
>
Well, both ia64 and sh have hit this in the current compilers, and it
doesn't seem to pose any code generation issues. In the areas where it is
generated it seems to relate to 64-bit data types in the data structures,
which in itself doesn't seem inherently problematic.
I'll submit a bug report to the GCC folks, but for the time being given
that multiple architectures are hitting this and it doesn't seem to be
causing any issues, it would be better to have this flag dropped.
* Paul Mundt <[email protected]> wrote:
>> > The present use of -Wcast-align causes the build to blow up on SH due to
>> > generating a "cast increases required alignment of target type" error on
>> > each invocation of list_for_each_entry().
>> >
>> > It seems that this was previously reported and killed off in the ia64
>> > support patch, but nothing seems to have happened with that. Presumably
>> > the same problem still remains there, too.
>> >
>> > Signed-off-by: Paul Mundt <[email protected]>
On Mon, Oct 26, 2009 at 07:25:20AM +0100, Ingo Molnar wrote:
>> Is this a GCC bug producing false positive warnings? The GCC manpage
>> says:
>>
>> ? ? ? ?-Wcast-align
>> ? ? ? ? ? ?Warn whenever a pointer is cast such that the required alignment of the
>> ? ? ? ? ? ?target is increased. ?For example, warn if a "char *" is cast to an
>> ? ? ? ? ? ?"int *" on machines where integers can only be accessed at two- or
>> ? ? ? ? ? ?four-byte boundaries.
>>
>> Which looks moderately useful - if it works.
On Mon, Oct 26, 2009 at 11:47 AM, Paul Mundt <[email protected]> wrote:
> Well, both ia64 and sh have hit this in the current compilers, and it
> doesn't seem to pose any code generation issues. In the areas where it is
> generated it seems to relate to 64-bit data types in the data structures,
> which in itself doesn't seem inherently problematic.
>
> I'll submit a bug report to the GCC folks, but for the time being given
> that multiple architectures are hitting this and it doesn't seem to be
> causing any issues, it would be better to have this flag dropped.
Can we disable the flag for affected architectures but keep it enabled for x86?
* Pekka Enberg <[email protected]> wrote:
> * Paul Mundt <[email protected]> wrote:
> >> > The present use of -Wcast-align causes the build to blow up on SH due to
> >> > generating a "cast increases required alignment of target type" error on
> >> > each invocation of list_for_each_entry().
> >> >
> >> > It seems that this was previously reported and killed off in the ia64
> >> > support patch, but nothing seems to have happened with that. Presumably
> >> > the same problem still remains there, too.
> >> >
> >> > Signed-off-by: Paul Mundt <[email protected]>
>
> On Mon, Oct 26, 2009 at 07:25:20AM +0100, Ingo Molnar wrote:
> >> Is this a GCC bug producing false positive warnings? The GCC manpage
> >> says:
> >>
> >> ? ? ? ?-Wcast-align
> >> ? ? ? ? ? ?Warn whenever a pointer is cast such that the required alignment of the
> >> ? ? ? ? ? ?target is increased. ?For example, warn if a "char *" is cast to an
> >> ? ? ? ? ? ?"int *" on machines where integers can only be accessed at two- or
> >> ? ? ? ? ? ?four-byte boundaries.
> >>
> >> Which looks moderately useful - if it works.
>
> On Mon, Oct 26, 2009 at 11:47 AM, Paul Mundt <[email protected]> wrote:
>
> > Well, both ia64 and sh have hit this in the current compilers, and
> > it doesn't seem to pose any code generation issues. In the areas
> > where it is generated it seems to relate to 64-bit data types in the
> > data structures, which in itself doesn't seem inherently
> > problematic.
> >
> > I'll submit a bug report to the GCC folks, but for the time being
> > given that multiple architectures are hitting this and it doesn't
> > seem to be causing any issues, it would be better to have this flag
> > dropped.
>
> Can we disable the flag for affected architectures but keep it enabled
> for x86?
For now i've applied Paul's fix - x86 doesnt have such type restrictions
and i dont remember this warning having flagged some real data structure
alignment bug anywhere.
Ingo
Commit-ID: ec29b8d2af01912bb79adda8aeab4293539f29ac
Gitweb: http://git.kernel.org/tip/ec29b8d2af01912bb79adda8aeab4293539f29ac
Author: Paul Mundt <[email protected]>
AuthorDate: Mon, 26 Oct 2009 14:40:01 +0900
Committer: Ingo Molnar <[email protected]>
CommitDate: Mon, 26 Oct 2009 09:43:06 +0100
perf tools: Remove -Wcast-align
The present use of -Wcast-align causes the build to blow up on
SH due to generating a "cast increases required alignment of
target type" error on each invocation of list_for_each_entry().
It seems that this was previously reported and killed off in the
ia64 support patch, but nothing seems to have happened with
that. Presumably the same problem still remains there, too.
Signed-off-by: Paul Mundt <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
tools/perf/Makefile | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 46e877b..7e190d5 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -177,8 +177,7 @@ endif
# Include saner warnings here, which can catch bugs:
#
-EXTRA_WARNINGS := -Wcast-align
-EXTRA_WARNINGS := $(EXTRA_WARNINGS) -Wformat
+EXTRA_WARNINGS := -Wformat
EXTRA_WARNINGS := $(EXTRA_WARNINGS) -Wformat-security
EXTRA_WARNINGS := $(EXTRA_WARNINGS) -Wformat-y2k
EXTRA_WARNINGS := $(EXTRA_WARNINGS) -Wshadow
From: Paul Mundt <[email protected]>
Date: Mon, 26 Oct 2009 18:47:30 +0900
> On Mon, Oct 26, 2009 at 07:25:20AM +0100, Ingo Molnar wrote:
>>
>> * Paul Mundt <[email protected]> wrote:
>>
>> > The present use of -Wcast-align causes the build to blow up on SH due to
>> > generating a "cast increases required alignment of target type" error on
>> > each invocation of list_for_each_entry().
>> >
>> > It seems that this was previously reported and killed off in the ia64
>> > support patch, but nothing seems to have happened with that. Presumably
>> > the same problem still remains there, too.
>> >
>> > Signed-off-by: Paul Mundt <[email protected]>
>>
>> Is this a GCC bug producing false positive warnings? The GCC manpage
>> says:
>>
>> -Wcast-align
>> Warn whenever a pointer is cast such that the required alignment of the
>> target is increased. For example, warn if a "char *" is cast to an
>> "int *" on machines where integers can only be accessed at two- or
>> four-byte boundaries.
>>
>> Which looks moderately useful - if it works.
>>
> Well, both ia64 and sh have hit this in the current compilers, and it
> doesn't seem to pose any code generation issues. In the areas where it is
> generated it seems to relate to 64-bit data types in the data structures,
> which in itself doesn't seem inherently problematic.
sparc64 hits this too when building 32-bit perf binary, the first
thing I do after a pull is remove this warning option from the
Makefile :-)
* David Miller <[email protected]> wrote:
> From: Paul Mundt <[email protected]>
> Date: Mon, 26 Oct 2009 18:47:30 +0900
>
> > On Mon, Oct 26, 2009 at 07:25:20AM +0100, Ingo Molnar wrote:
> >>
> >> * Paul Mundt <[email protected]> wrote:
> >>
> >> > The present use of -Wcast-align causes the build to blow up on SH due to
> >> > generating a "cast increases required alignment of target type" error on
> >> > each invocation of list_for_each_entry().
> >> >
> >> > It seems that this was previously reported and killed off in the ia64
> >> > support patch, but nothing seems to have happened with that. Presumably
> >> > the same problem still remains there, too.
> >> >
> >> > Signed-off-by: Paul Mundt <[email protected]>
> >>
> >> Is this a GCC bug producing false positive warnings? The GCC manpage
> >> says:
> >>
> >> -Wcast-align
> >> Warn whenever a pointer is cast such that the required alignment of the
> >> target is increased. For example, warn if a "char *" is cast to an
> >> "int *" on machines where integers can only be accessed at two- or
> >> four-byte boundaries.
> >>
> >> Which looks moderately useful - if it works.
> >>
> > Well, both ia64 and sh have hit this in the current compilers, and it
> > doesn't seem to pose any code generation issues. In the areas where it is
> > generated it seems to relate to 64-bit data types in the data structures,
> > which in itself doesn't seem inherently problematic.
>
> sparc64 hits this too when building 32-bit perf binary, the first
> thing I do after a pull is remove this warning option from the
> Makefile :-)
Generally if you run into such issues in Sparc let us know so we can fix
it :-)
Paul's fix is queued up for Linus.
Ingo
From: Ingo Molnar <[email protected]>
Date: Tue, 27 Oct 2009 14:50:25 +0100
> Generally if you run into such issues in Sparc let us know so we can fix
> it :-)
Sorry, I wanted to do a thorough analysis to make sure I understood
why it was warning, but I was too busy to do so.
In the end the issue is the kernel list.h macros like list_entry(),
and it would similarly trigger for things like container_of().
If you have a pointer to a structure with objects other than "long
double" then cast it to a pointer to a structure that does have a
"long double" in it, this increases the alignment of the type (from 8
to 16 bytes on sparc 32-bit).