https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421
--- Comment #19 from mimamer at gmail dot com ---
One last comment on strict aliasing rules: It is ironic that these rules are
supposed to make programs faster, but those developers that really care about
speed are prevented from implementing
++
Assignee: unassigned at gcc dot gnu.org
Reporter: mimamer at gmail dot com
Created attachment 32895
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32895action=edit
disassembly of faulty binary snippet
It seems that C++ carries out an invalid optimization when compiled with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421
--- Comment #1 from mimamer at gmail dot com ---
A minimalistic version that breaks with all -O2 flags set:
Starting from an empty main_list:
Node *node;
//asm volatile(:::memory);
while ( (node = main_list.dequeue()) != main_list.end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421
--- Comment #2 from mimamer at gmail dot com ---
Turns out the problems arise in different places but only in the
list2::dequeue() function:
inline T *dequeue() {
//asm volatile(:::memory);
T *head = anchor.next;
anchor.next = head
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421
--- Comment #4 from mimamer at gmail dot com ---
Indeed, this is alias-related. Two questions:
(1) What is a concrete solution for this problem when -fstrict-aliasing is
being used? How should I change my code? (Sorry, I am no expert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421
--- Comment #5 from mimamer at gmail dot com ---
T is derived from list2T::node, and yes, I'm upcasting from node to T.
There is no other way around it in the implementation, and if this causes a
problem with aliasing then I don't know what it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421
--- Comment #6 from mimamer at gmail dot com ---
Btw, C++ doesn't give me any aliasing warnings even with -Wstrict-aliasing=1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421
--- Comment #7 from mimamer at gmail dot com ---
Violation of aliasing or not, the problem arises prior to the downcasting from
list2T::node* to T*:
T *head = anchor.next;
anchor.next = head-next;
head-next-prev = (T *)anchor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421
--- Comment #8 from mimamer at gmail dot com ---
As concerns -fno-strict-aliasing, I have to put it before -O2. Sorry for the
mixup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421
--- Comment #9 from mimamer at gmail dot com ---
Now that I have read enough about aliasing rules I realize that they are
considerably fucked up and that their is no way to efficiently downcast without
violating strict aliasing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421
--- Comment #11 from mimamer at gmail dot com ---
In short form,
templateclass T class list2
{
public:
struct node {
T*next;
T*prev;
};
nodeanchor;
public:
/* API */
}
struct Obj : list2Obj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421
--- Comment #14 from mimamer at gmail dot com ---
Can you explain what you mean by use type node inside the struct node?
Because I still cannot see an (efficient) way for solving this problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421
--- Comment #16 from mimamer at gmail dot com ---
Ah ok, but that doesn't solve my problem as I will eventually need to cast a
node pointer back to T (either at the caller or the callee side). So there _is_
no efficient solution with strict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61421
--- Comment #18 from mimamer at gmail dot com ---
Ah? I didn't figure that was allowed per strict aliasing rules. But it still
doesn't solve one problem:
inline T *dequeue() {
node *head = anchor.next;
anchor.next = head-next;
head
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mimamer at gmail dot com
Apologies in advance for any mistakes in posting this bug report. If what I am
describing is not a bug in GCC please direct me to a place where I can ask for
help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61395
mimamer at gmail dot com changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61395
--- Comment #4 from mimamer at gmail dot com ---
I'm sorry to bother you one more time. All symbols are marked as hidden in
libgcc.a, true. But they become local default when I create a shared
libgcc.so from it. Just to help me understand what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61395
mimamer at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Resolution
18 matches
Mail list logo
