While migrating from 3.4.5 to 4.8.1 tool chain, seeing issues with unaligned address. The same code did not produce unaligned address in 3.4.5 but in 4.8.1 seeing such an issue. Below variables are declared in a function body : 377 FACOTMn_parms_t *OTMnData = (FACOTMn_parms_t * )data; 378 TSM_desc_t nvsFacData; 379 CS_result_t rc = CS_SSTP_rc; 380 uint8 *otmn_ptr = NULL, *sc_ptr = NULL; 381 uint8 *tr_ptr = NULL, *och_ptr = NULL, *faccfg_ptr = NULL; 382 uint8 slot = 0; 383 uint8 port = 0; 384 ALA_obj_t object = ALA_nil_obj; 385 uint16 index = 0; 386 GBB_rc_t gbbrc = GBB_SUCCESS_rc; 387 GBB_FAC_ROLE_t facRole = GBB_FAC_ROLE_UNKNOWN; 388 ALA_eqpt_t plug_type, otm_eqpt; 389 GBB_DISP_BasicPortInfoList_t portInfoList; 390 CFGM_PecInfo_t PecInfo; 391 ome_CardCfgPxfp_t xfpPecInfo; 392 ome_CardCfgPsfp_t sfpPecInfo; 393 ome_CardCfgPcfp_t cfpPecInfo; 394 float *wvlgthMin, *wvlgthMax; 395 OCH_wavelength_t *wvlgthSpacing; 396 TSM_service_mgr_t tsam; 397 CS_internal_AID_t slotAID; 398 uint8 numObj; 399 uint8 indx; 400 uint8 scIndx = 0; 401 CS_AID_t tempAID; 402 uint8 assignedTS = 0; 403 ODUn_sbf_parms_t FwParms; 404 TSM_desc_t oduFacData; 405 TSM_featInfo_t featInfo; 406 GBB_SERV_TYPE_t servType; 407 boolean isQSFP = FALSE; Seeing issues when accessing elements of xfpPecInfo, sfpPecInfo and cfpPecInfo and deference them. However, when forcefully aligned the addresses to 4 byte boundary for all these three, there was no unaligned addresses created such as : ome_CardCfgPxfp_t xfpPecInfo __attribute__((aligned(4))); ome_CardCfgPsfp_t sfpPecInfo __attribute__((aligned(4))); ome_CardCfgPcfp_t cfpPecInfo __attribute__((aligned(4))); Please suggest. Let me know if more information is needed.
What target is this for? Also what type is ome_CardCfgPxfp_t ?
(In reply to Andrew Pinski from comment #1) > What target is this for? > > Also what type is ome_CardCfgPxfp_t ? The target is powerpc. Structure definition is : typedef PACK_PREFIX_ALWAYS_PACK struct ome_CardCfgPxfp_t { float txPwrMin; float txPwrMax; float rxPwrMin; float rxPwrMax; float wavelengthMin; float wavelengthMax; uint32 wvlgthSpacing; SupportedObjects_l SupportedObjects; SupportedRates_l SupportedRates; } PACK_SUFFIX_ALWAYS_PACK ome_CardCfgPxfp_t; The code being accessed is : 806 wvlgthMin = &(cfpPecInfo.wavelengthMin); 807 wvlgthMax = &(cfpPecInfo.wavelengthMax); Alignment exception at below line : 829 if ((*wvlgthMin) == (*wvlgthMax))
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?
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.
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.
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 addi r25,r1,295 /vobs/viking_tsam/tsamgbb/fac/gbbotmntg.c:806 3b53924: 3b e1 01 23 addi r31,r1,291 /vobs/viking_tsam/tsamgbb/fac/gbbotmntg.c:805 3b53928: 3b 41 01 1f addi r26,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.
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).
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 <gcc-bugzilla@gcc.gnu.org> Sent: Wednesday, March 07, 2018 12:12 AM To: Bansal, Sumit <sbansal@ciena.com> Subject: [**EXTERNAL**] [Bug target/83748] Local variables not aligned to word boundary https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748 Segher Boessenkool <segher at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Segher Boessenkool <segher at gcc dot gnu.org> --- 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.
[ 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).
(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?