[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 --- 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 c/83597] New: Compilation error reg multiple declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83597
Bug ID: 83597
Summary: Compilation error reg multiple declaration
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sbansal at ciena dot com
Target Milestone: ---
While compiling the 4.8.1 tool chain, getting the following error. It would be
really appreciated if some one can help us on this.
Tool chain is configured like :
../configure \
LDFLAGS="-L${BUILD_OUTPUT}/lib" \
--build=i686-pc-linux-gnu \
--host=i686-pc-linux-gnu \
--target=powerpc-wrs-vxworks \
--disable-libmudflap \
--disable-libssp \
--disable-libstdcxx-pch \
--disable-symvers \
--disable-fixed-point \
--disable-decimal-float \
--disable-lto \
--disable-nls \
--disable-doc \
--disable-libgomp \
--enable-threads=vxworks \
--enable-poison-system-directories \
--enable-version-specific-runtime-libs \
--enable-languages=c,c++ \
--exec-prefix="${BUILD_OUTPUT}/x86-linux2" \
--libdir="${BUILD_OUTPUT}/lib" \
--program-transform-name='s,^gcc$,cc,;s,$,ppc,' \
--prefix=${BUILD_OUTPUT} \
--with-gmp=${BUILD_OUTPUT} \
--with-mpfr=${BUILD_OUTPUT} \
--with-isl=${BUILD_OUTPUT} \
--with-mpc=${BUILD_OUTPUT} \
--with-gxx-include-dir="${BUILD_OUTPUT}/include/c++/4.8.1" \
--with-build-time-tools=${BUILD_OUTPUT}/x86-linux2/powerpc-wrs-vxworks/bin \
--with-cloog=${BUILD_OUTPUT} \
--with-gnu-ld \
--with-dwarf2 \
--enable-__cxa_atexit \
--enable-shared \
--enable-sjlj-exceptions
In file included from
../../../../../libstdc++-v3/libsupc++/atexit_thread.cc:25:0:
/localdisk/sbansal/4.8.1_26122017/6500_gnu_4_8_1/wrs_gcc-4.8.1/build/powerpc-wrs-vxworks/mrtp/libstdc++-v3/include/cstdlib:
In function 'long int std::abs(long int)':
/localdisk/sbansal/4.8.1_26122017/6500_gnu_4_8_1/wrs_gcc-4.8.1/build/powerpc-wrs-vxworks/mrtp/libstdc++-v3/include/cstdlib:166:15:
error: 'long int std::abs(long int)' conflicts with previous using declaration
'long int abs(long int)'
abs(long __i) { return __builtin_labs(__i); }
^
/localdisk/sbansal/4.8.1_26122017/6500_gnu_4_8_1/wrs_gcc-4.8.1/build/powerpc-wrs-vxworks/mrtp/libstdc++-v3/include/cstdlib:
In function 'ldiv_t std::div(long int, long int)':
/localdisk/sbansal/4.8.1_26122017/6500_gnu_4_8_1/wrs_gcc-4.8.1/build/powerpc-wrs-vxworks/mrtp/libstdc++-v3/include/cstdlib:169:25:
error: 'ldiv_t std::div(long int, long int)' conflicts with previous using
declaration 'ldiv_t div(long int, long int)'
div(long __i, long __j) { return ldiv(__i, __j); }
^
In file included from ../../../../../libstdc++-v3/libsupc++/eh_alloc.cc:29:0:
/localdisk/sbansal/4.8.1_26122017/6500_gnu_4_8_1/wrs_gcc-4.8.1/build/powerpc-wrs-vxworks/mrtp/libstdc++-v3/include/cstdlib:
In function 'long int std::abs(long int)':
/localdisk/sbansal/4.8.1_26122017/6500_gnu_4_8_1/wrs_gcc-4.8.1/build/powerpc-wrs-vxworks/mrtp/libstdc++-v3/include/cstdlib:166:15:
error: 'long int std::abs(long int)' conflicts with previous using declaration
'long int abs(long int)'
abs(long __i) { return __builtin_labs(__i); }
^
/localdisk/sbansal/4.8.1_26122017/6500_gnu_4_8_1/wrs_gcc-4.8.1/build/powerpc-wrs-vxworks/mrtp/libstdc++-v3/include/cstdlib:
In function 'ldiv_t std::div(long int, long int)':
/localdisk/sbansal/4.8.1_26122017/6500_gnu_4_8_1/wrs_gcc-4.8.1/build/powerpc-wrs-vxworks/mrtp/libstdc++-v3/include/cstdlib:169:25:
error: 'ldiv_t std::div(long int, long int)' conflicts with previous using
declaration 'ldiv_t div(long int, long int)'
div(long __i, long __j) { return ldiv(__i, __j); }
^
In file included from ../../../../../libstdc++-v3/libsupc++/eh_alloc.cc:31:0:
/localdisk/sbansal/4.8.1_26122017/6500_gnu_4_8_1/wrs_gcc-4.8.1/build/powerpc-wrs-vxworks/mrtp/libstdc++-v3/include/cstring:
In function 'void* std::memchr(void*, int, std::size_t)':
/localdisk/sbansal/4.8.1_26122017/6500_gnu_4_8_1/wrs_gcc-4.8.1/build/powerpc-wrs-vxworks/mrtp/libstdc++-v3/include/cstring:100:40:
error: 'void* std::memchr(void*, int, std::size_t)' conflicts with previous
using declaration 'void* memchr(void*, int, size_t)'
memchr(void* __s, int __c, size_t __n)
^
/localdisk/sbansal/4.8.1_26122017/6500_gnu_4_8_1/wrs_gcc-4.8.1/build/powerpc-wrs-vxworks/mrtp/libstdc++-v3/include/cstring:
In function 'char* std::strchr(char*, int)':
/localdisk/sbansal/4.8.1_2
[Bug c/83748] New: Local variables not aligned to word boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748 Bug ID: 83748 Summary: Local variables not aligned to word boundary Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sbansal at ciena dot com Target Milestone: --- 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_tnvsFacData; 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 uint16index = 0; 386 GBB_rc_t gbbrc = GBB_SUCCESS_rc; 387 GBB_FAC_ROLE_tfacRole = GBB_FAC_ROLE_UNKNOWN; 388 ALA_eqpt_tplug_type, otm_eqpt; 389 GBB_DISP_BasicPortInfoList_t portInfoList; 390 CFGM_PecInfo_tPecInfo; 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_toduFacData; 405 TSM_featInfo_tfeatInfo; 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.
[Bug c/83748] Local variables not aligned to word boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748
--- Comment #2 from Sumit ---
(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))
[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 #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 c/84054] New: seems -fno-bounds-checking no longer supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84054 Bug ID: 84054 Summary: seems -fno-bounds-checking no longer supported Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sbansal at ciena dot com Target Milestone: --- Hi, We are migrating from 3.4.5 to 4.8.1 compiler and some of our code is using "-fno-bounds-checking" option to avoid doing bounds check on a special piece of code. This was working good in 3.4.5 but it seems not supported on 4.8.1 giving compilation error. Please suggest any possible resolution. Regards, Sumit
[Bug c/79573] New: binutils make install fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79573 Bug ID: 79573 Summary: binutils make install fails Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sbansal at ciena dot com Target Milestone: --- Host machine gcc version : -bash-4.2$ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC) -bash-4.2$ I am compiling binutils 2.23.52.20130219 but getting below errors while doing make install. rm -rf $backupdir; exit $rc ../../../binutils-2013.11/gas/doc/c-arc.texi:223: table requires an argument: the formatter for @item ../../../binutils-2013.11/gas/doc/c-arm.texi:391: command @bullet not accepting argument in brace should not be on @table line ../../../binutils-2013.11/gas/doc/c-arm.texi:392: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-arm.texi:395: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-arm.texi:400: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-arm.texi:405: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-arm.texi:410: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-arm.texi:413: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-cr16.texi:49: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-cr16.texi:51: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-cr16.texi:53: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-cr16.texi:58: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-cr16.texi:63: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-cr16.texi:65: warning: @item missing argument ../../../binutils-2013.11/gas/doc/c-tic54x.texi:113: @code expected braces ../../../binutils-2013.11/gas/doc/c-tic54x.texi:130: @code expected braces ../../../binutils-2013.11/gas/doc/c-tic54x.texi:137: @code expected braces ../../../binutils-2013.11/gas/doc/c-tic54x.texi:313: @code expected braces ../../../binutils-2013.11/gas/doc/as.texinfo:4406: warning: node `Byte' is next for `Bundle directives' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/as.texinfo:4462: warning: node `Bundle directives' is prev for `Byte' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/as.texinfo:4470: warning: node `Comm' is next for `CFI directives' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/as.texinfo:4626: warning: node `CFI directives' is prev for `Comm' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/c-arm.texi:445: warning: node next `ARM-Regs' in menu `ARM-Relocations' and in sectioning `ARM-Neon-Alignment' differ ../../../binutils-2013.11/gas/doc/c-arm.texi:452: warning: node prev `ARM-Neon-Alignment' in menu `ARM-Relocations' and in sectioning `ARM-Regs' differ ../../../binutils-2013.11/gas/doc/c-arm.texi:474: warning: node `ARM-Neon-Alignment' is next for `ARM-Relocations' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/c-arm.texi:474: warning: node `ARM-Regs' is prev for `ARM-Relocations' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/c-arm.texi:474: warning: node up `ARM-Relocations' in menu `ARM Syntax' and in sectioning `ARM Floating Point' differ ../../../binutils-2013.11/gas/doc/c-arm.texi:467: node `ARM Floating Point' lacks menu item for `ARM-Relocations' despite being its Up target ../../../binutils-2013.11/gas/doc/c-i386.texi:411: warning: node `i386-Regs' is next for `i386-Mnemonics' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/c-i386.texi:511: warning: node `i386-Mnemonics' is prev for `i386-Regs' in menu but not in sectioning ../../../binutils-2013.11/gas/doc/c-i386.texi:926: war
[Bug target/79623] New: error building a cross compiler for powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79623 Bug ID: 79623 Summary: error building a cross compiler for powerpc Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sbansal at ciena dot com Target Milestone: --- Created attachment 40778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40778&action=edit config.log GCC version being compiled : 4.8.1 Host machine GCC version : 4.8.5 Compiled binUtils and all the pre-requisties packages like gmp, mpfr, mpc, isl. make[1]: Entering directory `/home/sbansal/compiler/build-gcc/libiberty' if [ x"-fpic" != x ] && [ ! -d pic ]; then \ mkdir pic; \ else true; fi touch stamp-picdir if [ x"-fpic" != x ]; then \ gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.8/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -fpic ../../gcc-4.8/libiberty/regex.c -o pic/regex.o; \ else true; fi In file included from /usr/include/stdlib.h:314:0, from ../../gcc-4.8/libiberty/regex.c:130: /usr/include/sys/types.h:98:17: error: two or more data types in declaration specifiers typedef __pid_t pid_t; ^ /usr/include/sys/types.h:109:19: error: two or more data types in declaration specifiers typedef __ssize_t ssize_t; ^ make[1]: *** [regex.o] Error 1 make[1]: Leaving directory `/home/sbansal/compiler/build-gcc/libiberty' make: *** [all-libiberty] Error 2 Please let me know if more info is needed in this regard. Regards, Sumit
[Bug target/79623] error building a cross compiler for powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79623 --- Comment #2 from Sumit --- Thanks Richard for the quick response. I understand your point but actually it has been decided to be at 4.8.1 as far as our current project is concerned. Is it possible for you to at least give me some pointers which would have caused these errors? Thanks. Sumit
[Bug target/79623] error building a cross compiler for powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79623 --- Comment #3 from Sumit --- Hi Richard, I think this could be the root cause. checking for intptr_t... no checking for uintptr_t... no checking for ssize_t... no checking for pid_t... no Could you please help me understanding this behaviour? I am trying compiling the same GCC tool chainversion(4.8.1) on another host machine (running GCC 4.4.6) and I am not seeing this error there. Please help in this regard. Regards, Sumit
[Bug target/79623] error building a cross compiler for powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79623 --- Comment #5 from Sumit --- Below error log indicates that the C standard library headers are found in /usr/include. Isn't? In file included from /usr/include/stdlib.h:314:0, from ../../gcc-4.8/libiberty/regex.c:130: /usr/include/sys/types.h:98:17: error: two or more data types in declaration specifiers typedef __pid_t pid_t;
[Bug target/79623] error building a cross compiler for powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79623 --- Comment #6 from Sumit --- Hi Richard, Do you have any more suggestion for me? Regards, Sumit
[Bug c++/79862] New: Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 Bug ID: 79862 Summary: Compilation error while building libstdc++ Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sbansal at ciena dot com Target Milestone: --- Dear Team, I am trying to build 4.8.1 libstdc++-v3 library and I am seeing some compilation errors. Please help. Also, I was able to compile libgcc successfully. GCC configuration used as : === $../gcc-4.8/configure \ --build=i686-pc-linux-gnu \ --host=i686-pc-linux-gnu \ --target=powerpc-wrs-vxworks \ --disable-libmudflap \ --disable-libssp \ --disable-libstdcxx-pch \ --disable-sjlj-exceptions \ --disable-symvers \ --disable-fixed-point \ --disable-decimal-float \ --disable-lto \ --disable-hosted-libstdcxx \ --disable-nls \ --disable-libgomp --enable-threads=vxworks \ --enable-poison-system-directories --enable-version-specific-runtime-libs \ --enable-__cxa_atexit \ --enable-languages=c,c++ \ --enable-shared \ --exec-prefix='/opt/cross/x86-linux2' \ --libdir='/opt/cross/lib' \ --program-transform-name='s,^gcc$,cc,;s,$,ppc,' \ --prefix=/opt/cross \ --with-gmp=/opt/cross \ --with-mpfr=/opt/cross \ --with-isl=/opt/cross \ --with-gxx-include-dir=''\''/opt/cross/'\''include/c++/4.8' --with-build-time-tools=/opt/cross/x86-linux2/powerpc-wrs-vxworks/bin --with-cloog=/opt/cross --with-gnu-as \ --with-gnu-ld \ ../../../../gcc-4.8/libstdc++-v3/libsupc++/tinfo.h:25:20: fatal error: typeinfo: No such file or directory I checked but typeinfo file does not physically exist at below location. gcc-4.8/libstdc++-v3/libsupc++/ I also tried to copy this file "typeinfo" from my older toolchain 4.3.3 but it starts to fail further for "exception" file not found. I again copied "exception" file from my older toolchain 4.3.3 but it again fails further at : error: '_GLIBCXX_END_NAMESPACE' does not name a type. Any help in this regard will be appreciated. Thanks. Sumit
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 --- Comment #2 from Sumit --- (In reply to Richard Biener from comment #1) > Note GCC 4.8.1 is no longer maintained. Hi Richard, I understand that 4.8.1 is no longer supported. Actually, our project in current state can't move to any version beyond 4.8.1 for some maintainability reasons. At least can you share some pointers by which I can try to debug this issue myself. That would be appreciated. Thanks. Sumit
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 --- Comment #4 from Sumit --- (In reply to Andrew Pinski from comment #3) > --disable-hosted-libstdcxx \ > > That is more likely the cause. non-hosted libstdc++ is not well tested. Hi Andrew, Thanks for the comments. Actually, when we say "--disable-hosted-libstdcxx", we mean that we only want a limited set of headers (same as the one in "freestanding" mode). But as per the info below, "freestanding" mode supports typeinfo and exception headers. In "freestanding" mode only the following headers can be safely used: •cstdarg •cstddef •cstdlib •exception •limits •new •exception •typeinfo
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 --- Comment #5 from Sumit --- (In reply to Sumit from comment #4) > (In reply to Andrew Pinski from comment #3) > > --disable-hosted-libstdcxx \ > > > > That is more likely the cause. non-hosted libstdc++ is not well tested. > Hi Andrew, I have tried without --disable-hosted-libstdcxx and still the same error. In file included from ../../../../gcc-4.8/libstdc++-v3/libsupc++/array_type_info.cc:24:0: ../../../../gcc-4.8/libstdc++-v3/libsupc++/tinfo.h:25:20: fatal error: typeinfo: No such file or directory #include "typeinfo"
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 --- Comment #6 from Sumit --- Hi Andrew, Somehow these files were missing in my package. I have recopied them back and things have moved further. Now, I am seeing compilation error at : ../../../../../gcc-4.8/libstdc++-v3/src/c++11/debug.cc -o debug.o In file included from /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/cassert:43:0, from ../../../../../gcc-4.8/libstdc++-v3/src/c++11/debug.cc:31: ../../../../../gcc-4.8/libstdc++-v3/src/c++11/debug.cc: In member function 'void __gnu_debug::_Error_formatter::_Parameter::_M_print_field(const __gnu_debug::_Error_formatter*, const char*) const': ../../../../../gcc-4.8/libstdc++-v3/src/c++11/debug.cc:523:5: error: unable to find string literal operator 'operator"" _ASSERT_STR' assert(this->_M_kind != _Parameter::__unused_param); ^ ../../../../../gcc-4.8/libstdc++-v3/src/c++11/debug.cc:531:6: error: unable to find string literal operator 'operator"" _ASSERT_STR' assert(_M_variant._M_iterator._M_name); ^ ../../../../../gcc-4.8/libstdc++-v3/src/c++11/debug.cc:577:6: error: unable to find string literal operator 'operator"" _ASSERT_STR' assert(_M_variant._M_iterator._M_sequence);
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 Sumit changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #8 from Sumit --- (In reply to Andrew Pinski from comment #7) > (In reply to Sumit from comment #6) > > Hi Andrew, > > > > Somehow these files were missing in my package. I have recopied them back > > and things have moved further. > > > > Now, I am seeing compilation error at : > > > ../../../../../gcc-4.8/libstdc++-v3/src/c++11/debug.cc:523:5: error: unable > > to find string literal operator 'operator"" _ASSERT_STR' > > assert(this->_M_kind != _Parameter::__unused_param); > > Looks like the assert in assert.h vxworks has is not C++11 friendly. Add a > space before the _ASSERT_STR. Thanks Andrew. Adding a space before _ASSERT_STR helped. Now there are further errors seen : In file included from /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/atomic:41:0, from /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/future:43, from ../../../../../gcc-4.8/libstdc++-v3/src/c++11/functexcept.cc:31: /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:166:25: error: 'int_least8_t' was not declared in this scope typedef __atomic_baseatomic_int_least8_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:166:37: error: template argument 1 is invalid typedef __atomic_baseatomic_int_least8_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:166:61: error: invalid type in declaration before ';' token typedef __atomic_baseatomic_int_least8_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:169:25: error: 'uint_least8_t' was not declared in this scope typedef __atomic_base atomic_uint_least8_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:169:38: error: template argument 1 is invalid typedef __atomic_base atomic_uint_least8_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:169:68: error: invalid type in declaration before ';' token typedef __atomic_base atomic_uint_least8_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:172:25: error: 'int_least16_t' was not declared in this scope typedef __atomic_base atomic_int_least16_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:172:38: error: template argument 1 is invalid typedef __atomic_base atomic_int_least16_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:172:68: error: invalid type in declaration before ';' token typedef __atomic_base atomic_int_least16_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:175:25: error: 'uint_least16_t' was not declared in this scope typedef __atomic_base atomic_uint_least16_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:175:39: error: template argument 1 is invalid typedef __atomic_base atomic_uint_least16_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:175:70: error: invalid type in declaration before ';' token typedef __atomic_base atomic_uint_least16_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:178:25: error: 'int_least32_t' was not declared in this scope typedef __atomic_base atomic_int_least32_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:178:38: error: template argument 1 is invalid typedef __atomic_base atomic_int_least32_t; ^ /home/sbansal/compiler/build-gcc/powerpc-wrs-vxworks/libstdc++-v3/include/bits/atomic_base.h:178:68: error: invalid type in declaration before ';' token typedef __atomic_base atomic_int_least32_t;
[Bug preprocessor/80231] New: Error missing binary operator before token "("
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80231
Bug ID: 80231
Summary: Error missing binary operator before token "("
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: sbansal at ciena dot com
Target Milestone: ---
My product is being migrating from GCC 4.4.1 to 4.8.1 and while compiling the
existing code with newer tool chain, I am seeing below error :
In file included from
/vobs/optnet_comms/comms_applications/3rdparty/appweb/current/src/mpr/mprLib.c:5:0:
/vobs/optnet_comms/comms_applications/3rdparty/appweb/current/src/mpr/mpr.h:207:74:
error: missing binary operator before token "("
#elif (LINUX || ME_BSD_LIKE) && (LINUX_VERSION_CODE >=
KERNEL_VERSION(2,6,0))
[Bug preprocessor/80231] Error missing binary operator before token "("
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80231 --- Comment #2 from Sumit --- (In reply to Andrew Pinski from comment #1) > Looks like a dup of bug 36453. Hi Andrew, yes I did check that and modified the code like below : #elif (LINUX || ME_BSD_LIKE) && defined(KERNEL_VERSION) && (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0)) but no help. Am I doing something wrong here?
[Bug c++/80247] New: 'nullptr' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80247
Bug ID: 80247
Summary: 'nullptr' was not declared in this scope
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbansal at ciena dot com
Target Milestone: ---
I am migrating my code from 3.4.5 to 4.8.1 and enabled c++11 using -std=C++11
but I am getting below error :
In file included from
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc-current/include/grpc++/impl/codegen/security/auth_context.h:41:0,
from
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc-current/include/grpc++/impl/codegen/create_auth_context.h:43,
from
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc-current/include/grpc++/impl/codegen/server_context.h:45,
from
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc-current/include/grpc++/server_context.h:37,
from
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc_ciena/server/request_mgr.h:35,
from
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc_ciena/secu_framework/session_mgmt.cc:13:
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc-current/include/grpc++/impl/codegen/string_ref.h:
In constructor 'grpc::string_ref::string_ref()':
/vobs/optnet_comms/comms_applications/3rdparty/google/grpc-current/include/grpc++/impl/codegen/string_ref.h:70:24:
error: 'nullptr' was not declared in this scope
string_ref() : data_(nullptr), length_(0) {}
What Can I do to fix that?
Thanks.
[Bug c++/80247] 'nullptr' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80247
--- Comment #3 from Sumit ---
(In reply to Richard Biener from comment #1)
> Provide a testcase. It works for me. Testcase:
>
> void *p = nullptr;
>
> > g++-4.8 t.C -S -std=c++11
>
> Note that GCC 4.8 is no longer maintained, please use at least GCC 5.4.
The use case is :
060 class string_ref {
061 public:
062 // types
063 typedef const char* const_iterator;
064 typedef std::reverse_iterator const_reverse_iterator;
065
066 // constants
067 const static size_t npos;
068
069 // construct/copy.
070 string_ref() : data_(nullptr), length_(0) {}
[Bug c++/80247] 'nullptr' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80247 --- Comment #4 from Sumit --- (In reply to Jonathan Wakely from comment #2) > (In reply to Sumit from comment #0) > > I am migrating my code from 3.4.5 to 4.8.1 and enabled c++11 using > > Why would you choose 4.8.1 and not 4.8.5 ? There are lots of bug fixes in > later 4.8.x releases, especially if you're trying to use C++11 (which was > not fully supported by GCC 4.8.x and so labelled experimental, and under > heavy development with lots of fixes in later releases). > > > -std=C++11 > > The correct option is -std=c++11 not -std=C++11 Yes, I am using -std=c++11. Actually, we need to use 4.8.1 specifically. Do we have the list of C++11 patches based upon 4.8.5 which we can apply upon 4.8.1
[Bug c++/80247] 'nullptr' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80247 Sumit changed: What|Removed |Added Status|RESOLVED|WAITING Resolution|INVALID |--- --- Comment #6 from Sumit --- Actually, once I have -std=c++11 included in CPPFLAGS, I am able to get rid of nullptr problem. But still in the same compilation environment, one another file is complaining about nullptr not found. I have ensured that both the files compiles with -std=c++11. What can I check?
[Bug c++/80247] 'nullptr' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80247 --- Comment #8 from Sumit --- (In reply to Markus Trippelsdorf from comment #7) > (In reply to Sumit from comment #6) > > Actually, once I have -std=c++11 included in CPPFLAGS, I am able to get rid > > of nullptr problem. > > > > But still in the same compilation environment, one another file is > > complaining about nullptr not found. > > > > I have ensured that both the files compiles with -std=c++11. > > > > What can I check? > > If there are several -std= in the command line, the last one wins. > But really this is not the right place to discuss these issues. > Try the gcc-help mailing list. Thanks Markus for the pointer. I closely checked that besides -std=c++11, -nostdinc was also being passed which was causing this problem. Thanks. Sumit
[Bug c++/80314] New: Undefined reference to __dso_handle & __cxa_atexit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80314 Bug ID: 80314 Summary: Undefined reference to __dso_handle & __cxa_atexit Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sbansal at ciena dot com Target Milestone: --- I am seeing undefined reference to __dso_handle and __cxa_texit during linking stage. BinUtils version : 2.23.52.20130219 What could be the possible problem? hax-dgera-1|
[Bug libgcc/80314] Undefined reference to __dso_handle & __cxa_atexit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80314 --- Comment #2 from Sumit --- (In reply to Jonathan Wakely from comment #1) > I think these both need to come from either libc or libgcc. I have checked my libgcc and it does not have that either. onx-sbansal-01|
[Bug libgcc/80314] Undefined reference to __dso_handle & __cxa_atexit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80314 --- Comment #3 from Sumit --- (In reply to Jonathan Wakely from comment #1) > I think these both need to come from either libc or libgcc. Is it something that I have missed while compiling the tool chain? Please suggest.
[Bug libgcc/80319] New: Support for floatundidf and floatundisf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80319 Bug ID: 80319 Summary: Support for floatundidf and floatundisf Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: sbansal at ciena dot com Target Milestone: --- While migrating to a newer tool chain, corresponding to float and double data types, __floatundisf and __floatundidf are being generated in assembly respectively. Checking the GCC code, these functions are defined in libgcc2.c. Do I need to pass on certain flags while compiling libgcc? Please suggest. Thanks. Sumit
[Bug libstdc++/80340] New: error: 'write' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80340
Bug ID: 80340
Summary: error: 'write' was not declared in this scope
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbansal at ciena dot com
Target Milestone: ---
While building GCC, I am seeing below error :
../../../../gcc-4.8/libstdc++-v3/libsupc++/pure.cc: In function 'void
__cxxabiv1::__cxa_pure_virtual()':
../../../../gcc-4.8/libstdc++-v3/libsupc++/pure.cc:32:53: error: 'write' was
not declared in this scope
# define writestr(str) write(2, str, sizeof(str) - 1)
^
../../../../gcc-4.8/libstdc++-v3/libsupc++/pure.cc:49:3: note: in expansion of
macro 'writestr'
writestr ("pure virtual method called\n");
^
../../../../gcc-4.8/libstdc++-v3/libsupc++/pure.cc: In function 'void
__cxxabiv1::__cxa_deleted_virtual()':
../../../../gcc-4.8/libstdc++-v3/libsupc++/pure.cc:32:53: error: 'write' was
not declared in this scope
# define writestr(str) write(2, str, sizeof(str) - 1)
^
../../../../gcc-4.8/libstdc++-v3/libsupc++/pure.cc:56:3: note: in expansion of
macro 'writestr'
writestr ("deleted virtual method called\n");
[Bug libstdc++/80340] error: 'write' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80340 --- Comment #3 from Sumit --- ../gcc-4.8/configure LDFLAGS="-L/opt/sp2/lib" --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=powerpc-wrs-vxworks --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --disable-sjlj-exceptions --disable-symvers --disable-fixed-point --disable-decimal-float --disable-lto --disable-nls --disable-libgomp --disable-multilib --disable-shared --enable-threads=vxworks --enable-poison-system-directories --enable-version-specific-runtime-libs --enable-__cxa_atexit --enable-languages=c,c++ --exec-prefix='/opt/sp2/x86-linux2' --libdir='/opt/sp2/lib' --program-transform-name='s,^gcc$,cc,;s,$,ppc,' --prefix=/opt/sp2 --with-gmp=/opt/sp2 --with-mpfr=/opt/sp2 --with-isl=/opt/sp2 --with-gxx-include-dir=''\''/opt/sp2/'\''include/c++/4.8.1' --with-build-time-tools=/opt/sp2/x86-linux2/powerpc-wrs-vxworks/bin --with-cloog=/opt/sp2 --with-gnu-ld I understand 4.8.1 is no longer supported. But our project has to use it. Any help in this regard will be appreciated. Thanks.
[Bug libgcc/80314] Undefined reference to __dso_handle & __cxa_atexit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80314 --- Comment #7 from Sumit --- (In reply to Jonathan Wakely from comment #6) > Your configure options include: --enable-__cxa_atexit > > Why are you using that if your system doesn't support it? We are upgrading from 4.3.3 to 4.8.1. We had this option enabled in 4.3.3 and was working. Just wondering, why it is not in 4.8.1?
[Bug libstdc++/80340] error: 'write' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80340 --- Comment #5 from Sumit --- (In reply to Jonathan Wakely from comment #4) > (In reply to Jonathan Wakely from comment #2) > > Configuring GCC with --disable-libstdcxx-verbose will remove the use of > > write in that file Is this flag --disable-libstdcxx-verbose enabled because "--disable-libstdcxx-pch" is configured in my configuration?
[Bug libstdc++/80340] error: 'write' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80340 Sumit changed: What|Removed |Added Status|RESOLVED|WAITING Resolution|INVALID |--- --- Comment #6 from Sumit --- If I do not configure for hosted environment by using --disable-hosted-libstdcxx, I did not see this error. Any clues?
[Bug c/83175] New: compiler optimizing the code corresponding to double precision operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83175 Bug ID: 83175 Summary: compiler optimizing the code corresponding to double precision operations Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sbansal at ciena dot com Target Milestone: --- I am migrating my tool chain from 3.4.5 to 4.8.1. Migration to 4.8.1 is working great till now but the only problem I am recently encountering is about code getting optimized when some "double" operations are done. Source code : = 553 unlockAddr1_f64 = (double*) thisVars(vol)->unlockAddr1; 554 unlockAddr2_f64 = (double*) thisVars(vol)->unlockAddr2; 555 cmd.word32[0] = ((command<<16) | command); 556 cmd.word32[1] = cmd.word32[0]; 557 unlockAddr1_f64[0] = unlock1_cmd.fword64; 558 unlockAddr2_f64[0] = unlock2_cmd.fword64; 559 unlockAddr1_f64[0] = cmd.fword64; Corresponding assembly with 3.4.5 (working good) /vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:553 13adb0: 81 23 00 18 lwz r9,24(r3) 13adb4: 81 69 00 00 lwz r11,0(r9) /vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:554 13adb8: 81 49 00 04 lwz r10,4(r9) /vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:555 13adbc: 54 a0 80 1e rlwinm r0,r5,16,0,15 13adc0: 7c 00 2b 78 or r0,r0,r5 13adc4: 7c 07 03 78 mr r7,r0 /vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:556 13adc8: 7c 08 03 78 mr r8,r0 /vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:557 13adcc: 3d 20 00 67 lis r9,103 13add0: c8 09 7d 08 lfd f0,32008(r9) 13add4: d8 0b 00 00 stfdf0,0(r11) /vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:558 13add8: 3d 20 00 67 lis r9,103 13addc: c8 09 7d 10 lfd f0,32016(r9) 13ade0: d8 0a 00 00 stfdf0,0(r10) /vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:559 13ade4: 90 e1 00 08 stw r7,8(r1) 13ade8: 91 01 00 0c stw r8,12(r1) 13adec: c9 a1 00 08 lfd f13,8(r1) 13adf0: d9 ab 00 00 stfdf13,0(r11) Corresponding assembly with 4.8.1 (not working well) : /vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:554 138e04: 81 0a 00 04 lwz r8,4(r10) /vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:555 138e08: 54 aa 80 1e rlwinm r10,r5,16,0,15 138e0c: 7d 45 2b 78 or r5,r10,r5 /vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:557 138e10: 3c e0 00 66 lis r7,102 /vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:558 138e14: c8 07 01 c8 lfd f0,456(r7) 138e18: d8 08 00 00 stfdf0,0(r8) /vobs/equinox_ne_bsp/kernel/sources/drivers/ffs/amd16x4mtdome.c:559 138e1c: 90 a9 00 00 stw r5,0(r9) 138e20: 90 a9 00 04 stw r5,4(r9) The problem I see is that, no assembly instructions (lfd, stfd) are generated corresponding to line 557 & 559. It seems compiler is doing some optimization. Surprisingly, If I add some printf or debug code after line 558, these instructions are getting generated and code works well. I know 4.8.1 is no longer supported by GCC, but I would appreciate if you could give some directions which I can look. Probably some flags etc which I can set. let me know if you need more information. Thanks. Sumit
[Bug c/83175] compiler optimizing the code corresponding to double precision operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83175 --- Comment #2 from Sumit --- (In reply to Andrew Pinski from comment #1) > Try -fno-strict-aliasing as it looks like the code is violating C/C++ > aliasing rules. Thanks for the quick response. I am trying that and will let you know.
[Bug c/83175] compiler optimizing the code corresponding to double precision operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83175 --- Comment #3 from Sumit --- (In reply to Andrew Pinski from comment #1) > Try -fno-strict-aliasing as it looks like the code is violating C/C++ > aliasing rules. Hi Andrew, It does not have any effect. Still the same problem.
