https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
Hanoch Haim changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #22 from Hanoch Haim ---
"Of course it does, because without aligning the container you cannot have
aligned members. Maximum alignment always propagates outwards."
Sorry, your answer is still not clear, so let give a short example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #20 from Hanoch Haim ---
One more thing. I would expect that the issue would be in CTimeHistogram
functions (defined as aligned) but the code generation issue was in the parent
object ( CCPortLatency)
Why the compiler assumed that if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #19 from Hanoch Haim ---
After some investigation, I think it is not a gcc issue, please verify.
One of the internal object does not include a 64B alignment.
#define __rte_cache_aligned __attribute__((__aligned__(64)));
class CTim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #16 from Hanoch Haim ---
The global/parent object CGlobalTRex is aligned (64B) as expected:
(gdb) p &g_trex
$1 = (CGlobalTRex *) 0xc365c0
Could you explain why it is a problem to define the internal objects with the
aligment like t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #13 from Hanoch Haim ---
One more thing, The parent object is defined with 64Byte alignment
class CGlobalTRex {
..
} __rte_cache_aligned;
static CGlobalTRex trex;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
Hanoch Haim changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #11 from Hanoch Haim ---
thanks for the quick answer.
The parent object is static (bss) and wasn't dynmicly allocated using
new/malloc.
gcc set the address of the parent object and the childs.
Is there a way to solve it without re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #9 from Hanoch Haim ---
Attached. I hope this is what you are looking for.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #8 from Hanoch Haim ---
Created attachment 46542
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46542&action=edit
stateful_rx_core.ss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #7 from Hanoch Haim ---
Created attachment 46541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46541&action=edit
stateful_rx_core.ii
compress ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #5 from Hanoch Haim ---
It was fast.
The way to build are here
https://github.com/cisco-system-traffic-generator/trex-core/wiki#how-to-build-trex
```
$ git clone g...@github.com:cisco-system-traffic-generator/trex-core.git
$cd lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #3 from Hanoch Haim ---
With Ubuntu gcc7.4 package, there is no bug.
I've built the gcc from source and it has an issue. There are a diffrent
configuration values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
--- Comment #2 from Hanoch Haim ---
/usr/local/gcc-8.3/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-8.3/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-8.3/libexec/gcc/x86_64-pc-linux-gnu/8.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
Hanoch Haim changed:
What|Removed |Added
Target||x86
Host|
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hhaim at cisco dot com
Target Milestone: ---
**The project**:
https://github.com/cisco-system-traffic-generator/trex-core
**how to compile**:
https://github.com/cisco-system-traffic-generator/trex-core/wiki#how-to
16 matches
Mail list logo
