__sync_-builtins cause undefined references on some sparc targets
Hello, I compiled the gcc 6.3.0 for the leon2 processor for RTEMS (i.e. sparc-rtems4.12-*). When linking a fortran program for the leon2 processor I get undefined references for `__sync_bool_compare_and_swap_4' (see below). According to the discussion on the rtems mailinglist the __sync_*-operations are legacy and __atomic_*-operations should be used instead or to quote: "This __sync_() stuff seems to be used in several places in GCC. So, changing libbacktrace is probably not enough. We need a general solution for the __sync_() builtins on RTEMS. I don't think GCC can be changed to emit __atomic_() calls for the __sync_() builtins (I would still try to ask). The libgcc or libatomic is probably a good place to add them for RTEMS as functions implemented via __atomic_() builtins." Could someone give me some recommendations on what would be the best solution to fix the problem and maybe some pointers on how to start? I put the rtems mailinglist CC, so they can comment as well. sparc-rtems4.12-gcc -B../../../../../leon2/lib/ -specs bsp_specs -qrtems -mcpu=cypress -mhard-float -O2 -g -ffunction-sections -fdata-sections -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -Wl,--gc-sections -mcpu=cypress -mhard-float -o ticker.exe init.o tasks.o -L/localdata/somm_ja/rtems-fortran/install/bsps/4.12/sparc/sparc-rtems4.12/leon2/lib/ -llapack -lrefblas -ltmglib -lcblas -lm -lgfortran -lgcc /localdata/somm_ja/rtems-fortran/install/tools/4.12/sparc/lib/gcc/sparc-rtems4.12/6.3.0/libgfortran.a(elf.o): In function `backtrace_initialize': /localdata/somm_ja/rtems-fortran/rtems-source-builder/rtems/build/sparc-rtems4.12-gcc-6.3.0-newlib-2.5.0-x86_64-linux-gnu-1/build/sparc-rtems4.12/libbacktrace/../../../gcc-6.3.0/libbacktrace/elf.c:960: undefined reference to `__sync_bool_compare_and_swap_4' /localdata/somm_ja/rtems-fortran/install/tools/4.12/sparc/lib/gcc/sparc-rtems4.12/6.3.0/libgfortran.a(elf.o): In function `elf_add_syminfo_data': /localdata/somm_ja/rtems-fortran/rtems-source-builder/rtems/build/sparc-rtems4.12-gcc-6.3.0-newlib-2.5.0-x86_64-linux-gnu-1/build/sparc-rtems4.12/libbacktrace/../../../gcc-6.3.0/libbacktrace/elf.c:456: undefined reference to `__sync_bool_compare_and_swap_4' /localdata/somm_ja/rtems-fortran/install/tools/4.12/sparc/lib/gcc/sparc-rtems4.12/6.3.0/libgfortran.a(dwarf.o): In function `backtrace_dwarf_add': /localdata/somm_ja/rtems-fortran/rtems-source-builder/rtems/build/sparc-rtems4.12-gcc-6.3.0-newlib-2.5.0-x86_64-linux-gnu-1/build/sparc-rtems4.12/libbacktrace/../../../gcc-6.3.0/libbacktrace/dwarf.c:3030: undefined reference to `__sync_bool_compare_and_swap_4' collect2: error: ld returned 1 exit status Makefile:627: recipe for target 'ticker.exe' failed make: *** [ticker.exe] Error 1 Best regards, Jan Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR) German Aerospace Center Simulation and Software Technology | Software for Space Systems and Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany Jan Sommer Telephone +49 531 295-2494 | Telefax 0531 295-2767 | jan.som...@dlr.de DLR.de/SC
Test announcement
test http://tracking.desktop.al/tracking/unsubscribe?msgid=xuZXM1pE-Fzjv0SRTEY2-Q2
Fwd: Test announcement
I guessed correctly - .al is Albania. What's my prize ? Forwarded Message Subject: Test announcement Date: Mon, 27 Feb 2017 16:21:04 + From: Noreply via gcc Reply-To: Noreply , Noreply To: gcc@gcc.gnu.org test http://tracking.desktop.al/tracking/unsubscribe?msgid=xuZXM1pE-Fzjv0SRTEY2-Q2
Re: __sync_-builtins cause undefined references on some sparc targets
> "This __sync_() stuff seems to be used in several places in GCC. So, > changing libbacktrace is probably not enough. We need a general solution > for the __sync_() builtins on RTEMS. I don't think GCC can be changed to > emit __atomic_() calls for the __sync_() builtins (I would still try to > ask). The libgcc or libatomic is probably a good place to add them for > RTEMS as functions implemented via __atomic_() builtins." > > Could someone give me some recommendations on what would be the best > solution to fix the problem and maybe some pointers on how to start? I'm not sure backtrace support has much interest on embedded platforms and I don't think implementing atomic operations makes any sense on LEON2, so the best thing to do is probably to kludge around it in libgfortran. -- Eric Botcazou
Re: __sync_-builtins cause undefined references on some sparc targets
On Montag, 27. Februar 2017 22:07:56 CET Eric Botcazou wrote: > > "This __sync_() stuff seems to be used in several places in GCC. So, > > changing libbacktrace is probably not enough. We need a general solution > > for the __sync_() builtins on RTEMS. I don't think GCC can be changed to > > emit __atomic_() calls for the __sync_() builtins (I would still try to > > ask). The libgcc or libatomic is probably a good place to add them for > > RTEMS as functions implemented via __atomic_() builtins." > > > > Could someone give me some recommendations on what would be the best > > solution to fix the problem and maybe some pointers on how to start? > > I'm not sure backtrace support has much interest on embedded platforms and I > don't think implementing atomic operations makes any sense on LEON2, so the > best thing to do is probably to kludge around it in libgfortran. > Is there an easy way to remove the libbacktrace dependency? Might something like that work?: https://patchwork.ozlabs.org/patch/553017/
Re: __sync_-builtins cause undefined references on some sparc targets
> Is there an easy way to remove the libbacktrace dependency? > Might something like that work?: https://patchwork.ozlabs.org/patch/553017/ Yes, even better, simply arrange for the __sync and __atomic support tests of libbacktrace to fail on your target, possibly by using the same trick as HPUX. -- Eric Botcazou
Re: IEEE 128-bit floating point support for PowerPC RTEMS
On Tue, Jan 24, 2017 at 11:21:27AM +0100, Sebastian Huber wrote: > Hello, > > some time ago IEEE 128-bit floating point support for PowerPC was > added to GCC: > > https://gcc.gnu.org/wiki/Ieee128PowerPC > > I noticed some issues for RTEMS in this area. Firstly, RTEMS had no > __powerpc__ builtin define, so some source files were effectively > disabled, e.g. ibm-ldouble.c. With __powerpc__ defined, the > ibm-ldouble.c didn't compile due to: > > In file included from > /home/EB/sebastian_h/archive/gcc-git/libgcc/config/rs6000/ibm-ldouble.c:374:0: > /home/EB/sebastian_h/archive/gcc-git/libgcc/soft-fp/quad.h:72:1: > error: unable to emulate 'TF' > typedef float TFtype __attribute__ ((mode (TF))); > ^~~ > > I added > > #define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128 > > #undef TARGET_IEEEQUAD > #define TARGET_IEEEQUAD 1 > > This fixed the problem above and changes the long double type from 8 > bytes to 16 bytes. > > The new compiler defines now (powerpc-rtems target): > > #define __LONG_DOUBLE_128__ 1 > #define __LONGDOUBLE128 1 > #define __LONG_DOUBLE_IEEE128__ 1 > > However, the libgcc multilib build fails due to several ICEs. See > attached errors.log. > > Is this supposed to work for 32-bit PowerPC. Did I miss some magic > configuration switch? Please check this patch: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00861.html It has fixes for building on a 32-bit systems and non-VSX systems. Now, when I did the initial float128 work, as far as I could tell, long double was not enabled to be 128-bits on RTEMS. If it is now enabled, there may be gotchas, since RTEMS would be the only PowerPC system to use 128-bit floating point and use IEEE 128-bit instead of IBM double-double that the other PowerPC systems currently use. So it may be your call whether you want to enable it, and get it to work, or default back to long double == double. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
signed int performance question
Hello,
I wanted to ask a question regarding the compilation of code samples
like the following:
"
int a = fetch_value();
int b = fetch_value();
int c = SOME_BIG_CONSTANT;
if ( c - b < a)
{
...
}
pass_value(a + b);
return a + b;
"
The value "a + b" is used 3 times in this snippet, while the first use
is hidden in the if check. It seems that changing the if check to "if
( c < a + b ) " will allow the compiler to generate a more efficient
assembly code: 1 addition, used 3 times. However in all of my checks,
all GCC versions will prefer to calculate both the subtraction and the
addition, and to only use the addition's result 2 times.
I know that the case with unsigned integers is that all operations are
done in a modulu 2 ^ 32, and so changing the condition will change the
logical meaning of the check.
However, in signed integers, the logical meaning of any relation check
is only the theoretical meaning of the order relation between the
numbers in the group Z. Meaning that in a purely theoretical manner "a
+ b < c" is a relation order that is equivalent to "a < c - b" or even
" 0 < c - b - a". The only exception here is about any possible
integer overflow (above MAX_INT) or underflow (below MIN_INT), however
such cases are specified to be undefined in the C standard, and should
not harm the possible efficiency of the code generation.
Since a C programmer that follows the standard, and writes such a code
check, means only to check relations between 3 signed numbers in the
group Z, is there a reason why not to update the if check and to
generate a more efficient code? In addition, is there a way to
optionally raise warning in similar cases, so to warn against possible
signed integer overflows, in case the programmer is not aware of the
dangers in his code.
Thanks for your time,
Eyal.
