[Bug target/83748] Local variables not aligned to word boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748 --- Comment #10 from Sumit --- (In reply to Segher Boessenkool from comment #9) Thanks Segher for your comment. I have gone through the changes and seems like they are relevant to "volatile bitfield". Just wanted to confirm (double check) if the changes are relevant to my problem as well? My original problem was that the structures in the stack were not allocated even address causing the Alignment exception. Also, what could cause the addresses to be allocated a odd address?
[Bug target/83748] Local variables not aligned to word boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748 --- Comment #9 from Segher Boessenkool --- [ Please remove irrelevant parts of the email when replying to bugzilla mail ]. https://gcc.gnu.org/r205896 tells you this commit resolved four PRs: PR middle-end/23623 PR middle-end/48784 PR middle-end/56341 PR middle-end/56997 You can access those at https://gcc.gnu.org/PR23623 etc. You'll have to dig a bit to see what GCC 4.8 version has this patch (if any).
[Bug target/83748] Local variables not aligned to word boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748 --- Comment #8 from Sumit --- Hi Segher, I somehow missed the below update from your side. Can you help me understand if this was some known issue in GCC which got fixed in r205896? If yes, can you let us know if got fixed in 4.8.1 version? Thanks. Regards, Sumit -Original Message- From: segher at gcc dot gnu.org Sent: Wednesday, March 07, 2018 12:12 AM To: Bansal, Sumit Subject: [**EXTERNAL**] [Bug target/83748] Local variables not aligned to word boundary https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748 Segher Boessenkool changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Segher Boessenkool --- Closing this now. This was fixed in 2013, in r205896 -- so should be fixed in 4.9 already. That commit added this to the documentation: In some cases, such as when the 'packed' attribute is applied to a structure field, it may not be possible to access the field with a single read or write that is correctly aligned for the target machine. In this case GCC falls back to generating multiple accesses rather than code that will fault or truncate the result at run time. (and also added the code to implement it; as you noticed, older compilers will do misaligned loads if you're not careful). -- You are receiving this mail because: You reported the bug.
[Bug target/83748] Local variables not aligned to word boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748 Segher Boessenkool changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Segher Boessenkool --- Closing this now. This was fixed in 2013, in r205896 -- so should be fixed in 4.9 already. That commit added this to the documentation: In some cases, such as when the 'packed' attribute is applied to a structure field, it may not be possible to access the field with a single read or write that is correctly aligned for the target machine. In this case GCC falls back to generating multiple accesses rather than code that will fault or truncate the result at run time. (and also added the code to implement it; as you noticed, older compilers will do misaligned loads if you're not careful).
[Bug target/83748] Local variables not aligned to word boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748 --- Comment #6 from Sumit --- mstrict-align does not seems to help. Only aligning them forcefully does work. ome_CardCfgPxfp_t xfpPecInfo __attribute__((aligned(4))); ome_CardCfgPsfp_t sfpPecInfo __attribute__((aligned(4))); ome_CardCfgPcfp_t cfpPecInfo __attribute__((aligned(4))); Looks like that the base address of the structure itself is misaligned causing all its elements to be misaligned as well. In the below assembly, clearly an odd value is being pushed into r26 and r31 /vobs/viking_tsam/tsamgbb/fac/gbbotmntg.c:807 3b53920: 3b 21 01 27 addir25,r1,295 /vobs/viking_tsam/tsamgbb/fac/gbbotmntg.c:806 3b53924: 3b e1 01 23 addir31,r1,291 /vobs/viking_tsam/tsamgbb/fac/gbbotmntg.c:805 3b53928: 3b 41 01 1f addir26,r1,287 /vobs/viking_tsam/tsamgbb/fac/gbbotmntg.c:808 Later, r26 and r31 being pushed to floating point register. /vobs/viking_tsam/tsamgbb/fac/gbbotmntg.c:838 3b539f0: c0 3a 00 00 lfs f1,0(r26) 3b539f4: c0 1f 00 00 lfs f0,0(r31) Can the sequence of local elements in this function can cause some issue, because there are couple of elements which are of odd bytes in size such as GBB_FAC_ROLE_t = 1 byte GBB_DISP_BasicPortInfoList_t = 117 bytes But as per my understanding, proper padding would have been added in between to nullify their effects.
[Bug target/83748] Local variables not aligned to word boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748 --- Comment #5 from Sumit --- PACK_SUFFIX_ALWAYS_PACK is defined as __attribute__ ((__packed__)). But each individual element in the structure is of 4 bytes. I understand that 4.8.x is not supported any more but we have progressed our development on 4.8.1 so at least in near future we do not have any plans to shift. I can try adding -mstrict-align in my application Makefile and check.
[Bug target/83748] Local variables not aligned to word boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748 --- Comment #4 from Richard Biener --- If PACK_PREFIX_ALWAYS_PACK is containing __attribute__((packed)) this bug is invalid if the pointers wvlgthMin do not have packed pointed-to type. As always without a full testcase it's hard to guess.
[Bug target/83748] Local variables not aligned to word boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748 Andrew Pinski changed: What|Removed |Added Target||powerpc Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-09 Component|c |target Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Can you specify the exact target triplet? And attach the preprocessed source. Also 4.8.x is no longer supported, Can you try a newer compiler like say GCC 5 or GCC 6? Also what is PACK_SUFFIX_ALWAYS_PACK defined to? Can you try adding -mstrict-align because GCC for powerpc defaults to allowing unaligned accesses?
