If your code is sensitive to the size of long long, can you use the predefine:
__SIZEOF_LONG_LONG__
If that doesn't work, then you can use:
gcc -dM -E - < /dev/null
to tell you what predefines a gcc compiler has (I would probably look for predefines more specific to what your code is sensitive to than look for a particular compiler).
I also wonder a little about your original problem statement since "%lld" should be a way to always print "long long" and if you have a matched set of compiler and library, then it should adjust both together. If you are using "%ld" instead, this works in situations where "long" is the same size as "long long" but may not work when these are different sizes.
--mev, Mike Vermeulen
Hi there!
On Linaro gcc 4.6, I am facing an issue due to "long long" integers
not being 64 bit as they are on other platforms I'm targeting,
which causes different issues, most importantly with printf format
strings. I am now circumventing these by using the C/C++ preprocessor
in order to choose the right format strings. In order to minimize the
necessity for users to manually configure things, I'm wondering if
there is a way to detect the Linaro gcc compiler through preprocessor
macros. Is this possible?
Thanks.
Best regards,
Isidor
Hi all,
We are using Linaro 13.03 toolchain(
gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux We are trying to
execute a simple test code to check whether ARM assembly code executes on
board or not. Execution is on Arndale Board. Every time We include assembly
function, We get segmentation fault. Kindly check if I We are missing any
arm related flags in makefile.
We have attached the ‘helloworld’ test code and makefile.
Regards,
Vishwa
Is that supposed to be possible? When I add --disable-multilib to the
configure options, the build fails on the install, because it hasn't built
any of src/gcc-linaro-4.8-2014.02/libgcc:
/bin/sh ../../../../src/gcc-linaro-4.8-2014.02/libgcc/../mkinstalldirs
/home/ubuntu/work483/build/sysroot/home/ubuntu/opt/cross-gcc-linaro/lib/gcc/arm-linux-gnueabi/4.8.3
/usr/bin/install -c -m 644 libgcc_eh.a
/home/ubuntu/work483/build/sysroot/home/ubuntu/opt/cross-gcc-linaro/lib/gcc/arm-linux-gnueabi/4.8.3/
/usr/bin/install: cannot stat `libgcc_eh.a': No such file or directory
make[3]: *** [install-shared] Error 1
make[3]: Leaving directory
`/home/ubuntu/work483/build/gcc/arm-linux-gnueabi/libgcc'
make[2]: *** [install-target-libgcc] Error 2
make[2]: Leaving directory `/home/ubuntu/work483/build/gcc'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/home/ubuntu/work483/build/gcc'
make: *** [stamp/gcc-install] Error 2
I don't want or need multilib, so I'd rather build the toolchain without
it, but before I try to make that happen, I wanted to make sure it's
supposed to be able to get built correctly that way.
Thanks,
Diane
== Progress ==
* IAS (TCWG-377)
- Long discussions about magic in inline asm
- Bottomline is: we're still validating anyway
* AArch64 (TCWG-387)
- Making it build with CMake, discarding some tests
- Similar changes to the test-suite
- All green except sphereflake
* Buildbots
- Investigating one failure on test-suite due
to register allocator changes
- Will continue this during or after Connect
* Background
- Connect preparations
- EuroLLVM 14 sync call, paper discussions
- Researching some kernel C/ASM syntax
- Studying __builtin_constant_p usage
- Patch reviews, etc.
* Time
- CARD-862 8/10
- Others 2/10
== Plan ==
* Connect
(slightly delayed)
== Progress ==
* 3 day week (annual leave Thursday and Friday)
* QEMU ARMv8 CRC instructions (4/10, TCWG-52)
* Slides for Connect (1/10)
* Further work on longjmp/setjmp Systemtap probes on ARM (1/10, TCWG-378)
== Issues ==
* None
== Plan ==
* Complete QEMU CRC instruction work
* Preparation for Connect
--
Will Newton
Toolchain Working Group, Linaro
== This week ==
- US Holiday on Monday, January 17th
- Backported 202407 - Fix parameter to vrsqte_f64
- Backported 202259 (on read/write branch) - AARCH64, fix return types
for vaddvq_s64, vaaddvq_u64
- Backported 202321 - Fix vdup<bhsd>_lane<q>_* instrinsics' lane parameter
- Backported 202322 - Fox register constraints for lane intrinsics
- Installed Qemu64 simulator and attempted to test aarch64 backports.
- Shared library issue is preventing qemu64 from executing; Rob Savoy
is investigating
== Next week ==
- Test pending git review backports with Qemu64 if issues resolved
- Test backports completed this week on Qemu64
- New backports
== Future ==
--
Michael Collison
Linaro Toolchain Working Group
michael.collison(a)linaro.org
== Issues ==
* none
== Progress ==
* LRA on AArch32:
o TCWG-343 : Make LRA the default for the ARM backend (0/10)
- No progress this week on my side.
o TCWG-345 : Analyse performance of LRA for ARM. (4/10)
- Analysed Spec2K figures on Cortex-a15.
* Backports review: (1/10)
o Start to look at the Gerrit review process.
o Lack of testsuite results
* Misc:
o LCA'14 : AArch64 toolchain status session. (3/10)
o Various meetings. (2/10)
== Next ==
* Backports review
* https://bugs.launchpad.net/bugs/1169164
* Connect
== Progress ==
* Completed testing and submitted patches upstream. [TCWG-251] [TCWG-252] [1/10]
* Travel to capital Islamabad for Macau visa follow up. [3/10]
* Shifting to new office space and setting up office [6/10]
== Plan ==
* Study aarch64 code and create task breakdown for record/replay
support. [TCWG-389]
* Setup gdb for aarch64 and try to run a demo application. [TCWG-389]
* Write how-to for using scripts to compare two gdb testsuite runs. [TCWG-96]
* Setup network and internet etc in new office space.