https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #43
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #42 from Eric Botcazou ---
Author: ebotcazou
Date: Tue Nov 7 17:37:29 2017
New Revision: 254503
URL: https://gcc.gnu.org/viewcvs?rev=254503=gcc=rev
Log:
PR c/53037
* stor-layout.c: Include attribs.h.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #41 from Aldy Hernandez ---
Author: aldyh
Date: Wed Sep 13 17:08:36 2017
New Revision: 252478
URL: https://gcc.gnu.org/viewcvs?rev=252478=gcc=rev
Log:
Add warn_if_not_aligned attribute
Add warn_if_not_aligned attribute as well as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
John David Anglin changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #39 from Eric Botcazou ---
> i don't quite understand this reasoning, i would
> not expect the internal STRICT_ALIGNMENT setting
> to change how types behave (e.g. it might mean
> some code errors out, but the semantics of packed
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #37 from H.J. Lu ---
(In reply to Andreas Schwab from comment #35)
> On m68k:
>
> FAIL: gcc.dg/pr53037-1.c (test for warnings, line 42)
> FAIL: gcc.dg/pr53037-1.c (test for warnings, line 75)
> FAIL: gcc.dg/pr53037-1.c (test for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #36 from H.J. Lu ---
(In reply to Andreas Schwab from comment #34)
> On ia64:
>
> FAIL: g++.dg/pr53037-4.C -std=gnu++11 (test for excess errors)
> Excess errors:
> /usr/local/gcc/gcc-20170821/gcc/testsuite/g++.dg/pr53037-4.C:9:1:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #35 from Andreas Schwab ---
On m68k:
FAIL: gcc.dg/pr53037-1.c (test for warnings, line 42)
FAIL: gcc.dg/pr53037-1.c (test for warnings, line 75)
FAIL: gcc.dg/pr53037-1.c (test for excess errors)
Excess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #34 from Andreas Schwab ---
On ia64:
FAIL: g++.dg/pr53037-4.C -std=gnu++11 (test for excess errors)
Excess errors:
/usr/local/gcc/gcc-20170821/gcc/testsuite/g++.dg/pr53037-4.C:9:1: error:
alignment for 'void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #33 from H.J. Lu ---
(In reply to Eric Botcazou from comment #32)
> > Sparc defines STRICT_ALIGNMENT which leads to
> >
> > unsigned mode_align = GET_MODE_ALIGNMENT (TYPE_MODE (type));
> >
> > /* Don't override a larger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #32 from Eric Botcazou ---
> Sparc defines STRICT_ALIGNMENT which leads to
>
> unsigned mode_align = GET_MODE_ALIGNMENT (TYPE_MODE (type));
>
> /* Don't override a larger alignment requirement coming from a user
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
Rainer Orth changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #30 from H. Peter Anvin ---
On August 18, 2017 3:52:12 PM CDT, "hjl.tools at gmail dot com"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
>
>--- Comment #29 from H.J. Lu ---
>(In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #29 from H.J. Lu ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #28)
> > --- Comment #27 from H.J. Lu ---
>
> > What are error messages?
>
> None, the warnings are simply missing.
>
> Rainer
Sparc defines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #27 from H.J. Lu ---
> What are error messages?
None, the warnings are simply missing.
Rainer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #27 from H.J. Lu ---
(In reply to Rainer Orth from comment #26)
> Several of the new tests FAIL on Solaris/SPARC (both 32 and 64-bit):
>
> +FAIL: g++.dg/pr53037-2.C -std=gnu++11 (test for warnings, line 16)
> +FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #24 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri Aug 18 09:38:38 2017
New Revision: 251180
URL: https://gcc.gnu.org/viewcvs?rev=251180=gcc=rev
Log:
Add warn_if_not_aligned attribute
Add warn_if_not_aligned attribute as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #23 from H.J. Lu ---
(In reply to Martin Sebor from comment #22)
> The warning on the test case in comment #21 looks good to me. Thanks!
>
> From reading comment #1 I'm not sure your patch does quite what you
> described there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #22 from Martin Sebor ---
The warning on the test case in comment #21 looks good to me. Thanks!
>From reading comment #1 I'm not sure your patch does quite what you described
there. It doesn't warn on the declaration of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
H.J. Lu changed:
What|Removed |Added
Attachment #27198|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #20 from Martin Sebor ---
It would be useful to have the ability to trigger a warning when an object of a
type with an explicitly specified alignment (even if the alignment matches its
own native one) is defined in a way that would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #19 from H.J. Lu ---
(In reply to Martin Sebor from comment #18)
> This seems like a useful enhancement. H.J., what is the status of the
> patch? Do you have plans to submit it?
I was not sure if there were enough interests. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-04-19 15:47:14
UTC ---
Given
typedef unsigned long long __u64 __attribute__((aligned(4)));
all most all __u64 will be aligned at 4. The only case we may
do something about is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #3 from H. Peter Anvin hpa at zytor dot com 2012-04-19 15:51:35
UTC ---
Logically, about half of u64's will be properly aligned at the moment... Linus'
request is that we flag the currently misaligned __[su]64's as __compat_[su]64
and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-04-19 16:00:41
UTC ---
(In reply to comment #3)
Logically, about half of u64's will be properly aligned at the moment...
Linus'
No necessarily. For
u64 x;
int y;
u64 z;
both x and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #5 from H. Peter Anvin hpa at zytor dot com 2012-04-19 16:05:29
UTC ---
On 04/19/2012 09:00 AM, hjl.tools at gmail dot com wrote:
request is that we flag the currently misaligned __[su]64's as
__compat_[su]64
and make __[su]64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-04-19 16:53:18
UTC ---
For a global or local 64bit variable, x, inside kernel,
why should it be 4 byte aligned if it isn't part of system
call interface?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #7 from H. Peter Anvin hpa at zytor dot com 2012-04-19 16:57:14
UTC ---
The __u64/__s64 types are used for interfaces only. The kernel itself is
x86-64 and uses aligned types for internal uses.
The mismatch between i386 and x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2012-04-19 17:07:20
UTC ---
Shouldn't
typedef unsigned long long __u64 __attribute__((aligned(4)));
only be used in system call interface?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #9 from H. Peter Anvin hpa at zytor dot com 2012-04-19 17:11:00
UTC ---
Yes.
The point is: WE WANT TO MIGRATE THE SYSTEM CALL INTERFACE TO AN ALIGNED
__[us]64 INTERFACE, mostly so that new interfaces are properly aligned from the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com 2012-04-19 17:20:42
UTC ---
Isn't checking alignment of x in:
typedef unsigned long long __u64
__attribute__((aligned(4),warn_if_not_aligned(8)));
struct foo
{
int i1;
int i2;
int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #11 from H. Peter Anvin hpa at zytor dot com 2012-04-19 17:42:28
UTC ---
Sorry, that should be sufficient. I'm not awake today, it seems.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2012-04-19 20:15:55
UTC ---
Created attachment 27197
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27197
A patch
I got
[hjl@gnu-6 pr53037]$ cat x.i
typedef unsigned long long __u64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Attachment #27197|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #14 from H. Peter Anvin hpa at zytor dot com 2012-04-19 20:24:25
UTC ---
Are the last two warnings in bits (as opposed to bytes)? It looks a little
confusing...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #15 from H.J. Lu hjl.tools at gmail dot com 2012-04-19 20:41:47
UTC ---
(In reply to comment #14)
Are the last two warnings in bits (as opposed to bytes)? It looks a little
confusing...
It is fixed by the updated patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #16 from H.J. Lu hjl.tools at gmail dot com 2012-04-19 21:06:49
UTC ---
Created attachment 27199
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27199
A smaller patch
There is no point to support
struct foo
{
int i1;
long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037
--- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-04-19 00:33:55
UTC ---
We need to add another field to tree_type_common and tree_decl_common to
store the warn_if_not_aligned value.
43 matches
Mail list logo