https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #61 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri Jan 18 13:05:18 2019
New Revision: 268075
URL: https://gcc.gnu.org/viewcvs?rev=268075&root=gcc&view=rev
Log:
c-family: Update unaligned adress of packed member check
Check un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #60 from Jakub Jelinek ---
Author: jakub
Date: Wed Jan 16 14:18:47 2019
New Revision: 267970
URL: https://gcc.gnu.org/viewcvs?rev=267970&root=gcc&view=rev
Log:
PR c/51628
PR target/88682
* c-c++-common/pr51628
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #59 from H.J. Lu ---
A missing warning:
[hjl@gnu-cfl-1 pr51628-7]$ cat pr51628-33.c
struct pair_t
{
char x;
int i[4];
} __attribute__ ((packed, aligned (4)));
extern struct pair_t p;
extern void bar (int *);
void
foo (struct pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #58 from Christophe Lyon ---
No, I haven't reproduced it manually yet. The log only says:
Execution returned 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #57 from H.J. Lu ---
(In reply to Christophe Lyon from comment #56)
> The updated testcase pr51628-10 fails at execution on aarch64
> FAIL: c-c++-common/pr51628-10.c -Wc++-compat execution test
Do you know why it fails?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #54 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Thu Dec 20 21:41:48 2018
New Revision: 267313
URL: https://gcc.gnu.org/viewcvs?rev=267313&root=gcc&view=rev
Log:
C/C++: Add -Waddress-of-packed-member
When address of packed memb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #52 from W.H. Ding ---
(In reply to rguent...@suse.de from comment #48)
So, is there an old bug that covers my problem, or should I file a new one?
Thank you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #51 from W.H. Ding ---
(In reply to Sven from comment #49)
> This doesn't work. The aligned attribute is for providing additional
> alignment hints. The GCC documentation clearly states, that aligned can
> increase the alignment. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #50 from Sven ---
(In reply to Sven from comment #49)
> This doesn't work. The aligned attribute is for providing additional
> alignment hints. The GCC documentation clearly states, that aligned can
> increase the alignment. So g_d is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #49 from Sven ---
(In reply to W.H. Ding from comment #47)
> Hi, everyone
>
> I wonder if this issue has to do with the bug-like problem I encountered
> when accessing an unaligned stand-alone global variable (rather than a
> member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #48 from rguenther at suse dot de ---
On Thu, 12 Apr 2018, dingcurie at icloud dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
>
> W.H. Ding changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
W.H. Ding changed:
What|Removed |Added
CC||dingcurie at icloud dot com
--- Comment #47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #46 from Alexey Salmin ---
Tested the latest patch, behavior looks very reasonable even in tricky cases.
1) No warning, gcd(12, 8) == 4
struct tuple_t {
char c[12];
__int128_t i;
} __attribute__((packed, align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #45 from H.J. Lu ---
(In reply to Sven from comment #44)
>
> You can combine the packed attribute with the aligned attribute. Then you
> can define one struct with aligned(4) and one with aligned(8). Does the
> warning trigger if you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #44 from Sven ---
(In reply to Alexey Salmin from comment #42)
> typedef struct unaligned_int128_t_ {
> __int128_t value;
> } __attribute__((packed)) unaligned_int128_t;
You can combine the packed attribute with the aligned attri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #43 from H.J. Lu ---
(In reply to Alexey Salmin from comment #42)
>
> I was trying to say that I'm glad that the "address-of-packed-member"
> warning isn't triggered by this code. It still relies on the "address of
> packed member" b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #42 from Alexey Salmin ---
Sorry for being unclear.
When I need a pointer to an unaligned type I wrap it in a struct. E.g. a fix
for SIGSEGV from comment#36 would look like this:
struct pair_t {
char c;
__int128_t i;
} __att
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #41 from Sven ---
(In reply to Alexey Salmin from comment #39)
> .. when the packed attribute is preserved in the pointer.
What do you mean by that? GCC documentation explicitly forbids to use the
packed attribute for anything but st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #40 from H.J. Lu ---
(In reply to Alexey Salmin from comment #39)
> Thank you, this patch works for me.
>
> Gives a warning in the attached test case, but still allows to take an
> addre of a packed struct members when the packed att
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #39 from Alexey Salmin ---
Thank you, this patch works for me.
Gives a warning in the attached test case, but still allows to take an address
of a packed struct members when the packed attribute is preserved in the
pointer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #38 from H.J. Lu ---
A patch is posted at
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01237.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #37 from H.J. Lu ---
Created attachment 43120
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43120&action=edit
Add -Waddress-of-packed-member to C/C++ FE
Please try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
Alexey Salmin changed:
What|Removed |Added
CC||alexey.salmin at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #35 from Sven ---
(In reply to Sven from comment #34)
> That is to be
> expected, hence gcc should warn about the fact, and the address of a
> (potentially) unaligned int is assigned to a regular int* pointer.
Sorry, typo:
That is to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #34 from Sven ---
(In reply to H.J. Lu from comment #32)
> long long is aligned to 4 bytes in struct for i386.
Understood. So the aligned(4) was just added to explicitly restating the
alignment?
Anyhow, the two warnings added by tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #33 from H.J. Lu ---
[hjl@gnu-skl-1 gcc]$ cat x.c
#include
#include
typedef int aligned_int __attribute__((warn_if_not_aligned(4)));
int main(void)
{
struct foo {
char c;
aligned_int x;
} __attribute__((packe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #32 from H.J. Lu ---
(In reply to Sven from comment #31)
> https://gcc.gnu.org/viewcvs/gcc/trunk/?view=log&pathrev=251180
>
> I am reading the commit message, and the example doesn't make any sense.
> The aligned attribute is for pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #31 from Sven ---
https://gcc.gnu.org/viewcvs/gcc/trunk/?view=log&pathrev=251180
I am reading the commit message, and the example doesn't make any sense.
The aligned attribute is for providing additional alignment guarantees in
addit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #30 from H.J. Lu ---
(In reply to Eric Gallager from comment #29)
>
> I don't remember the exact commit number but HJ Lu added it; I added him on
> cc with my previous comment, so maybe he can explain.
It is r251180.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #29 from Eric Gallager ---
(In reply to Sven from comment #28)
> (In reply to Eric Gallager from comment #27)
> > gcc 8 adds -Wpacked-not-aligned; does that fix this bug?
>
> I couldn't find documentation on what this switch is suppo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #28 from Sven ---
(In reply to Eric Gallager from comment #27)
> gcc 8 adds -Wpacked-not-aligned; does that fix this bug?
I couldn't find documentation on what this switch is supposed to do. Can you
point me in the right direction? I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
Eric Gallager changed:
What|Removed |Added
CC||egall at gwmail dot gwu.edu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
See A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #24 from Sven ---
Comment #4 mentions typedef int myint __attribute__((aligned(1)));
That shouldn't even work. The GCC documentation on Type Attributes mentions
that "The aligned attribute can only increase the alignment". It goes on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #23 from Sven ---
FYI: I have asked the llvm folks to add a warning to their compiler for the
when a pointer to a member of a packed struct is assigned to an "ordinary"
pointer with higher alignment guarantees. Clearly, I agree with c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #22 from rguenther at suse dot de
2013-04-03 09:20:21 UTC ---
On Wed, 3 Apr 2013, ebotcazou at gcc dot gnu.org wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
>
> --- Comment #21 from Eric Botcazou 2013-04-0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #21 from Eric Botcazou 2013-04-03
08:51:44 UTC ---
> One of the C frontend issues is that the type of the address of
> the field of the packed struct is int *, not int attribute((aligned(1)))
> *. And this is so because nothi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #20 from rguenther at suse dot de
2013-04-03 07:55:34 UTC ---
On Wed, 3 Apr 2013, ebotcazou at gcc dot gnu.org wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
>
> --- Comment #19 from Eric Botcazou 2013-04-0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #19 from Eric Botcazou 2013-04-03
07:29:51 UTC ---
> Not sure if I can agree with (or understand) this comment. If we use my
> example
> of the address of an int in a packed structure being assigned to an int* then
> one could
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #18 from incrediball 2013-04-02 20:21:06
UTC ---
Not sure if I can agree with (or understand) this comment. If we use my example
of the address of an int in a packed structure being assigned to an int* then
one could argue that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #17 from Richard Biener 2013-04-02
08:30:54 UTC ---
(In reply to comment #15)
> I believe the discussion here is missing the point. Currently (at least with
> version 4.5 and ARM, which I am currently using) the situation is th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #16 from Richard Biener 2013-04-02
08:30:16 UTC ---
(In reply to comment #14)
> > What Ada does looks just like a workaround for what should be done properly
> > in
> > the expander. So no, IMHO we shouldn't be changing all o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
incrediball changed:
What|Removed |Added
CC||peter at axium dot co.nz
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #14 from Eric Botcazou 2011-12-20
17:43:07 UTC ---
> What Ada does looks just like a workaround for what should be done properly in
> the expander. So no, IMHO we shouldn't be changing all other FEs and the
> middle-end (when it want
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #13 from rguenther at suse dot de
2011-12-20 13:21:02 UTC ---
On Tue, 20 Dec 2011, ebotcazou at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
>
> --- Comment #11 from Eric Botcazou 2011-12-20
> 12:25:1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #11 from Eric Botcazou 2011-12-20
12:25:13 UTC ---
> You can. Just check what you get with that aligned(1) int typedef.
Well, we're going in circles as this example precisely doesn't work.
> Is it documented anywhere that you can't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #10 from rguenther at suse dot de
2011-12-20 11:56:22 UTC ---
On Tue, 20 Dec 2011, ebotcazou at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
>
> --- Comment #9 from Eric Botcazou 2011-12-20
> 11:34:00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #9 from Eric Botcazou 2011-12-20
11:34:00 UTC ---
> You mean that handling the TYPE_ALIGN != MODE_ALIGN case when
> expanding a MEM_REF (thus, INDIRECT_REF on old branches) won't work?
But you cannot have TYPE_ALIGN < MODE_ALIGN (TYP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #8 from rguenther at suse dot de
2011-12-20 11:23:48 UTC ---
On Tue, 20 Dec 2011, ebotcazou at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
>
> --- Comment #7 from Eric Botcazou 2011-12-20
> 11:18:24
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #7 from Eric Botcazou 2011-12-20
11:18:24 UTC ---
> Huh, it's not. It's the same as a packed struct or enum type.
No, it isn't, the mode is integral instead of BLKmode. In Ada we do support
misaligned integers, but we simply wrap t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #6 from rguenther at suse dot de
2011-12-20 11:04:37 UTC ---
On Tue, 20 Dec 2011, ebotcazou at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
>
> --- Comment #5 from Eric Botcazou 2011-12-20
> 10:52:19
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #5 from Eric Botcazou 2011-12-20
10:52:19 UTC ---
> The point is that even if you use sth like
>
> typedef int myint __attribute__((aligned(1)));
>
> to capture the misaligned pointer to the packed structure element:
>
> myint *p =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
Richard Guenther changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #3 from Keith Thompson
2011-12-20 00:36:52 UTC ---
I see no "-Walign" option, either in the versions of gcc I'm using or in the
online documentation. Were you thinking of a different option?
What I'm suggesting, primarily, is that t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #2 from Andrew Pinski 2011-12-19
23:27:24 UTC ---
I think this is just undefined at runtime which means we can only warn about
it. Which we do with -Walign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #1 from Keith Thompson
2011-12-19 23:05:50 UTC ---
A commenter on stackoverflow points out that a possible fix would be to permit
the address of a member of a packed structure to be assigned only to a pointer
object that is itself dec
61 matches
Mail list logo
