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
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->n
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 s
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 #11 from mimamer at gmail dot com ---
In short form,
template class list2
{
public:
struct node {
T*next;
T*prev;
};
nodeanchor;
public:
/* API */
}
struct Obj : list2::node
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. In
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 #7 from mimamer at gmail dot com ---
Violation of aliasing or not, the problem arises prior to the downcasting from
list2::node* to T*:
T *head = anchor.next;
anchor.next = head->next;
head->next->prev = (T
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 #5 from mimamer at gmail dot com ---
T is derived from list2::node, and yes, I'm "up"casting 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&#
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 on this
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.n
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
++
Assignee: unassigned at gcc dot gnu.org
Reporter: mimamer at gmail dot com
Created attachment 32895
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32895&action=edit
disassembly of faulty binary snippet
It seems that C++ carries out an invalid optimization when compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61395
mimamer at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Resolution
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
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
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
18 matches
Mail list logo
