From: Adrian Moreno <amorenoz@redhat.com>
To: David Brown <david.brown@hesbynett.no>,
Stefan Ring <stefanrin@gmail.com>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: broken code only when optimized "-O2"
Date: Wed, 22 Dec 2021 10:24:28 +0100 [thread overview]
Message-ID: <9b28799e-71f8-2ef9-1cc9-01345993cc11@redhat.com> (raw)
In-Reply-To: <f9e0c1c0-7a8b-2b63-eab4-ec0c7eb1b56c@hesbynett.no>
On 12/21/21 18:05, David Brown wrote:
> On 21/12/2021 17:05, Stefan Ring via Gcc-help wrote:
>> On Tue, Dec 21, 2021 at 4:40 PM Adrian Moreno via Gcc-help
>> <gcc-help@gcc.gnu.org> wrote:
>>>
>>> I'd really appreciate any hint or idea to try to understand this problem.
>>
>> I guess the compiler doesn't like the dereferencing of uninitialized
>> pointers (in the sizeof expressions). I am not 100% sure that this
>> counts as dereferencing, but I would assume so. Because of this the
>> compiler will be free to behave however it likes to.
>>
>
> The operand of a sizeof expression is not evaluated (unless it is a
> VLA). So there is no problem with the "member1 = malloc(sizeof
> *member1);" lines. (Which is fortunate, because it is a very common idiom!)
>
> I think the next step would be to start pulling in some of the
> definitions for the various macros here, and then trying to reduce the
> code further to get a smaller test case.
>
Yes, that's the road I'm taking. Thanks for the suggestion.
One of the things that originally felt smelly was that the fact that the macros
that iterate the list elements assume the "struct ovs_list" element is embedded
into another "struct member":
struct member *pos = 0;
for ((((pos) = ((struct member *) (void *) ((uintptr_t)(void *)((&start)->next)
- __builtin_offsetof (struct member, elem)))));
&(pos)->elem != (&start);
((pos) = ((struct member *) (void *) ((uintptr_t)(void
*)((pos)->elem.next) - __builtin_offsetof (struct member , elem)
)))) {
[... use pos ]
however, the beginning of the list is a "struct ovs_list" defined in the stack
and not embedded into a "struct member".
Therefore, "(&start)->next - __builtin_offsetof (struct member, elem)" actually
points to somewhere in the stack that contains who knows what. (Note: initially
start->next = start)
In fact, if I make the struct offsets zero:
struct member {
struct ovs_list elem;
[ ... ]
int order;
};
... the code works. However if I use:
struct member {
int padding[10];
struct ovs_list elem;
[ ... ]
int order;
};
... the code fails.
Does anything of what I'm saying make sense so far?
If the code inside the loop just made use of "pos" through "(&pos->elem)" then
the compiler could(?) be ok with it but the loop actually contains:
if (member->order > pos->order) {
break;
}
So here I do not know what the compiler would think about "pos" if it happens to
point to some invalid stack address.
Thanks for the help.
--
Adrián Moreno
next prev parent reply other threads:[~2021-12-22 9:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-21 15:40 Adrian Moreno
2021-12-21 16:05 ` Stefan Ring
2021-12-21 16:13 ` Adrian Moreno
2021-12-21 16:39 ` Segher Boessenkool
2021-12-21 17:05 ` David Brown
2021-12-22 9:24 ` Adrian Moreno [this message]
2021-12-22 10:27 ` Florian Weimer
2021-12-22 10:34 ` Adrian Moreno
2021-12-22 10:36 ` Xi Ruoyao
2021-12-22 16:05 ` Adrian Moreno
2021-12-22 15:32 ` LIU Hao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b28799e-71f8-2ef9-1cc9-01345993cc11@redhat.com \
--to=amorenoz@redhat.com \
--cc=david.brown@hesbynett.no \
--cc=gcc-help@gcc.gnu.org \
--cc=stefanrin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).